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

[洪任諭]

Shouldn't dbus being slightly over-kill here?
If simple scripts can do it, using dbus here only brings complexity.
Besides, currently there are many "org.gnome.xxxx" services which I
don't think KDE will adopt.
Moreover, if we choose this approach, that means, all desktop
environments which want to be compatible with freedesktop.org/portland
will have to depend on dbus and create dbus services.
I don't think most of the authors of lightweight desktops will agree
on this, hence this can inhibit the spreading of freedesktop.org
specs.
Cross-desktop doesn't means "making GNOME and KDE talk to each other".
There are still many other desktop environments for different needs.
GNOME + KDE != all desktop environments.

Please keep this in mind when making specs.

On Tue, Nov 11, 2008 at 1:41 PM, Zhe Su <james.su at gmail.com> wrote:
> I'm wondering if it's possible to design a set of standard dbus interface
> for xdg-utils, then different desktop environments can implement their own
> dbus services to provide identical functionalities through dbus interface.
>
> Regards
> James Su
>
> On Tue, Nov 11, 2008 at 12:13 PM, 洪任諭 <pcman.tw at gmail.com> wrote:
>>
>> Hello the authors/maintainers of xdg-utils,
>> I'm the lead developer of LXDE. < http://lxde.org/ >
>> I have some thoughts regarding to some limitations of current xdg-utils.
>> Here are some proposals to rework it and make it totally extensible.
>>
>> Limitations of current implementation:
>> 1. It only recognize gnome, xfce, and kde and is far from being truely
>> cross-desktop.
>> 2. Authors of new desktop environment need to hack xdg-utils to support
>> their
>> desktop environments, and hope someday Portland project will include
>> their patch.
>> 3. The number of desktop environments is still increasing, and in this
>> way,
>> xdg-utils will finally become very complicated and full of dirty hacks.
>> 4. Even if I only get xfce installed on my distro, xdg-utils still
>> needs to check all the others.
>> 5. Portland project is hard to participate. I sent mails to the
>> mailing list, and they just got ignored.
>>
>> Easy and backward-compatible solution for all the preceding problems -
>> Let desktop environments install their own scripts.
>>
>> Implementation Details (Advantages and disadvantages are listed later
>> in this mail)
>> Taking xdg-utils for example, it should work like this:
>>
>> Looking for scripts in "/usr/share/xdg-utils/xdg-open.d" (or other
>> places are ok).
>> Scripts from various desktop environments can be installed there.
>> 50-gnome
>> 50-kde
>> 60-kde3
>> 50-xfce
>> 99-generic
>> The numbers means "priority". The generic one, of course, has the
>> lowest priority.
>> This is common practice on UNIX systems.
>> Then, run the scripts installed by various desktop environments one by
>> one.
>> Every script in that dir checks if current desktop session is theirs.
>> If it is, the script opens the file/url with their own mechanism, and
>> returns 0.
>> Otherwise, it returns an error codes.
>> Once failed, the next script with lower priority will be tried.
>>
>> Advantages:
>> 1. Highly extensible.
>> 2. Won't break any compatibility with current implementation.
>> 3. Easy to maintain. (The scripts are all maintained by authors from
>> respective desktop environments, not you guys from Portland)
>> It's impossible for Portland developers to maintain hacks for all kinds of
>> desktop environment and constantly fix them for future versions of those
>> desktop environment. It's quite inefficient and hard to get things right.
>> 4. Don't need to hard code detection for all kinds of desktop
>> environments in one
>> very large and complicated xdg-* script.
>> 5. Only the desktop environments *really* installed on the system are
>> checked since those scripts are provided by the DEs themselves. So you'll
>> never always try to find gnome or kde, like the current xdg-utils,
>> even if they are not installed.
>>
>> Disadvantages:
>> 1. The performance is slightly worse. (Since this command won't be
>> executed continuously in a large loop, it's not a real issue.)
>> 2. Potential conflicts between scripts installed by various desktops.
>> (This is not possible if those scripts are well-written)
>>
>> For xdg-mime and others, the same method can be used.
>>
>> This can solve all of the problems in current implementation.
>> Any comments? Is it possible to get this new design into Portland
>> xdg-utils?
>>
>> Thank you all in advance.
>> _______________________________________________
>> Portland mailing list
>> Portland at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/portland
>
>