[Portland] Proposal: Rework the current xdg-utils. (with implementation details)

[洪任諭]

Back to the original topic.
We still need a better solution than the current one.
As a application developer, it's a real pain to know that even I call
the 'cross-desktop' xdg-utils, nothing will work if there is no gnome,
kde, or xfce.
For example, if I only use openbox, fluxbox, or icewm, I still have to
have other DEs installed, or at least have their related services
installed. Otherwise nothing will work.
The smallest one of them might be exo-open, which is included in
libexo. But it won't work properly, and cannot be configured without
xfce.

So the point of my proposal is, xdg-utils should be extensible, not
hard-coded to support gnome, kde, and xfce only. Waiting for patches
from various DEs and adding them to xdg-utils is not an acceptable
solution since there are too many, and xdg-utils can get bloated and
complicated.

As for dbus, I agree that having dbus services is great, but it should
be optional.
However, even if we have dbus, we still won't know if a application
fail to start or not, unless the services for various desktop
environment support this. For now, the dbus service can call
underlying scripts, or vice versa.

Another solution will be write a freedesktop.org spec and force all
desktop environments to share the same config file for defining
default browser and mail client.

On Tue, Nov 11, 2008 at 3:58 PM, Zhe Su <james.su at gmail.com> wrote:
> Having standard dbus interface doesn't mean that those shell scripts must be
> removed. If we have the standard dbus interface, we can modify those scripts
> to use it directly when it's avaiable, and fallback to current solution if
> the dbus service is not available. End users and existing applications won't
> be affected. But newly developed applications can take advantage of the new
> dbus service.
>
> Regards
> James Su
>
> On Tue, Nov 11, 2008 at 3:36 PM, Peter Åstrand <astrand at cendio.se> wrote:
>>
>> On Tue, 11 Nov 2008, Zhe Su wrote:
>>
>> > As an application developer, calling a shell script inside an
>> >application to do something is really bad. For example, my application
>> >needs open url or local file by external applications, currently there is
>> >only way to do it: execute xdg-open shell script by using system() or
>> >exec() system call. But this approach has many limitations, such as, it's
>> >impossible to know if and when the application is started successfully.
>>
>> I disagree. Calling an external program is an easy and universal solution.
>> The return value from xdg-open indicates errors. From the man page:
>>
>> "An exit code of 0 indicates success ..."
>
> xdg-open's exit code is not reliable. The open operation is actually async,
> returning 0 doesn't mean the operation has finished successfully, it only
> means the corresponding open command exits without error. And with xdg-open
> there is no way for the application to know when the external application is
> successfully started up.
> And it's not guaranteed that xdg-open will run in async mode. It might be
> blocked when calling the real open command until the external application is
> launched successfully. We encountered such issue in one of our application.
>
>>
>>
>> The whole point of xdg-utils is that it should cover different
>> desktop environments. We should support current and future non-DBUS
>> environments, so xdg-utils itself shouldn't depend on DBUS.
>>
>> Regards,
>> ---
>> Peter Åstrand           ThinLinc Chief Developer
>> Cendio AB               http://www.cendio.com
>> Wallenbergs gata 4
>> 583 30 Linköping        Phone: +46-13-21 46 00
>
> _______________________________________________
> Portland mailing list
> Portland at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/portland
>
>