[Xfce4-commits] r19947 - in xfce-utils/trunk: . xfrun

Brian J. Tarricone bjt23 at cornell.edu
Sat Feb 18 21:55:24 CET 2006

Hash: SHA1

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
available, though...


Version: GnuPG v1.4.2 (GNU/Linux)


More information about the Xfce4-dev mailing list