Re: GAppInfo and the working directory

On Thu, Jan 28, 2010 at 3:34 AM, Alexander Larsson <alexl redhat com> wrote:
> On Wed, 2010-01-27 at 19:25 +0100, Jannis Pohlmann wrote:
>> Hey,
>> I've found little information on how to set the working directory for
>> applications started via GAppInfo on the net. The only mail I stumbled
>> across was this one:
>> It says there are no plans at all to support modifying the working
>> directory through GAppLaunchContext because the result of the
>> launch operation is unpredictable due of the variety of ways to spawn
>> applications (fork, exec, D-Bus, crazy Windows stuff).
> Its not just the "protocol" used to spawn. Its also the fact that
> launching may not start a new application but rather activate some
> existing one, and in that case its not really a good idea to change the
> current directory of the running process.

just a footnote: i've been hacking on the implementation of similar
stuff for the OS X backend. it has some similar issues. so far, the
only things i've come across that really feel as they are better off
being handled by GTK rather than the app itself are:

  * discovering the file(s) used to spawn the application (by dbl-click)
  * noticing requests to open new files driven by dbl-clicking in a file manager
  * handling requests to quit that come from sources other than the
apps own menus/shortcuts or the WM. OS X has several such sources.

on OS X, the first two are pretty much equivalent, and handled by what
is referred to as a cocoa delegate, which in essence is just an object
that implements a couple of methods (openFile and openFiles). the
latter is similar, except that the method returns a value indicating
whether the app really should exit.

it would be nice to have a single GTK object that covers this kind of
thing in as x-platform a way as possible.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]