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

[Benedikt Meurer]

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.

> Jani

Benedikt