xfrun4 D-BUS service

Brian J. Tarricone bjt23 at cornell.edu
Tue Aug 1 20:29:16 CEST 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/1/2006 5:42 AM, Jannis Pohlmann wrote:
> On Mon, 31 Jul 2006 15:14:59 -0700, Brian J. Tarricone wrote:
> 
>>
>> On 7/31/2006 12:19 PM, Jannis Pohlmann wrote:
>>> Hey Brian,
>>>
>>> I noticed that Verve doesn't work with the xfrun D-BUS
>>> implementation you commited a few days ago. This is because you
>>> implement a different OpenDialog method. AFAIK, we agreed on using
>>> this:
>>>
>>>   OpenDialog (dir : STRING, display : STRING) : VOID
>>>
>>>   dir     : either a file:-URI or an absolute path.
>>>   display : the screen on which to display the file properties
>>>             or "" to use the default screen of the current panel
>>>             instance.
>>>
>>> In xfrun-dbus.c, you pass three arguments to this method
>>> (the third one is a variable named "run_argument"). Also, you pass
>>> them in wrong order (display, dir, run_argument) instead of (dir,
>>> display). Is the run_argument really needed? If so, we might want
>>> to add it to the interface but if not, I can write a patch for
>>> removing it from xfrun4.
>> Oops.  Yeah, I forgot we actually agreed on an interface.  I don't
>> care about the order, so feel free to change it.  I just feel it's
>> more consistent to have the display first.
>>
>> The run_arugment is needed to support old xfrun behavior: If you run
>> "xfrun4 file.txt" from the cmdline, the box pops open to ask you what
>> you want to open "file.txt" with.  So if you put, say, 'mousepad' in
>> the xfrun box, "mousepad file.txt" gets launched.  There's no way to
>> do that without adding an argument.
>>
>> Is there any way to do optional arguments with dbus?  It would be nice
>> to make run_argument optional...  I found that passing NULL to
>> dbus_message_add_args() (or whatever it is) doesn't work.
> 
> No, I couldn't find anything about optional arguments for D-BUS
> methods. So if run_argument is required, we should add it to the
> interface.

That's a shame.  So can we agree on a three-argument interface?  The
lazy part of me wants to declare it (display, cwd, run_arg) so I don't
have to change anything ^_~.

>>> Another thing I noticed is that no DBUS_NAME_FLAGs are passed to
>>> dbus_bus_request_name() in line 230. Ideally, you'd pass
>>> DBUS_NAME_FLAG_ALLOW_REPLACEMENT (only when using D-BUS >= 0.60) in
>>> order to allow other services to take over the ownership for
>>> org.xfce.RunDialog. This is important because programs like Verve
>>> are likely to be started after the xfrun4 (as invoked by the D-BUS
>>> daemon).
>> I'm not convinced we *want* other things to be able to steal the
>> service ownership.  That sounds like bad, unpredictable UI.  At any
>> rate, I didn't really do much with the d-bus stuff other than
>> reformat it: that code is mostly verbatim from what either you or
>> Jani wrote and posted to bugzilla.
> 
> Maybe you're right and programs like Verve should not implement the
> org.xfce.RunDialog interface in order to gain ownership for this
> service. But then again, if they (almost) provide the same features
> (command history, auto-completion), they also might suit as an
> org.xfce.RunDialog service provider. Dunno.

True.

> Normally, if people don't use Verve, the service will be owned by
> xfrun4.

No it won't.  The xfrun4 daemon does not start on session startup.  It
only starts the first time you use xfrun4.  If your panel loads a verve
plugin, it'll take ownership of the service, no problem.  xfrun4 then
*won't* take ownership if it's accidentally loaded later.  (At least, I
don't think it will.)

> People using Verve don't really need xfrun4, so it would be
> nice for them to be able to call it in the same way (and with the same
> shortcut) as others call xfrun4 with.

Right, and if verve is already running, and the xfrun4 binary is called,
it'll just talk to the current verve instance owning the service.

> IMHO, being able to switch services provides as you like is one of the
> major advantages of D-BUS. 

Sure, but some arbitrary programmatic method that the user has no
control over is not very usable.  Not that killing the xfrun4 daemon or
removing your verve plugin is really usable either, but at least it's
something the user has control over.

	-brian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)

iD8DBQFEz5176XyW6VEeAnsRAuxLAKDg758Xu5yUfUPGeWYoBYgghDG+lwCfcE1h
76axv/1mV0jkoET/W+8M1GE=
=xmEZ
-----END PGP SIGNATURE-----



More information about the Xfce4-dev mailing list