[Xfce4-commits] r19947 - in xfce-utils/trunk: . xfrun
Brian J. Tarricone
bjt23 at cornell.edu
Sat Feb 18 21:55:24 CET 2006
-----BEGIN PGP SIGNED MESSAGE-----
Benedikt Meurer wrote:
> Jani Monoses wrote:
>>> But why making xfrun resident in memory? It's not an important tool at
>>> all which would require that either... I mean, if you need to use xfrun
>>> that often, then fire up a terminal and you'll be even faster!
>> Well those 20K don't do much harm being in memory :) Many mcs settings
>> which people very seldom use are in memory.
>> And the dbus solutions advantage besides speed, at least the reason
>> Benedikt proposed it would be choice between various UIs depending on
>> which app provides the service.
>> And while xfrun is not that commonly used when it is used it is good to
>> be as fast as possible that's where hot in hot-keys comes from ;) So
>> it's not about how often it is used.
>> As for firing up a terminal that takes more actually, whether you fire
>> it up and run the command, or switch to it using alt-tabs.
> Jani is right in that the real problem is the gtk icon loading code (in
> fact, that's what makes Thunar startup slow, as it stat()'s every icon
> file on startup, although an icon cache is present for every theme I use).
> The D-BUS service would be the easiest solution to this problem: For
> people using Thunar or Xffm, the Run Dialog will be provided by this
> file manager and it'll popup instantely. For all others, the fallback
> will be used, which will take longer to popup.
> This could be done pretty easily: Create an xfrun4 binary that tries to
> invoke org.xfce.RunDialog.Open() first and if not successfull, exec()
> $libexecdir/xfrun4-fallback. The xfrun4 binary would only need to link
> to D-BUS.
... which would unfortunately make the fallback path quite a bit slower.
Who knows how many people will have Thunar/Xffm installed and
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Xfce4-dev