[Portland] Proposal: Rework the current xdg-utils. (with implementation details)
John Carlyle-Clarke
john at wormdrive.net
Tue Nov 11 02:31:20 PST 2008
I really like the ideas proposed. It seems like a great way to solve a
number of problems.
The Portland project was originally intended to include some cross
platform DAPI framework for application developers to use, which uses
dbus, but it seems that this part was never released. See
http://webcvs.freedesktop.org/portland/portland/dapi/. It's 2 years old.
There is a problem here in that the xdg-utils seem like abandonware.
1.0 was released in Oct 06, with 1.0.1 in Nov 06 fixing a couple of
minor bugs, and an even smaller bugfix release 1.0.2 in Jun 07.
The wiki seems to be overrun by spam (I just cleaned some myself) and
most pages have not been changed in any real way for a year or more.
I've been subscribed to the list since I found a bug with the fallback
generic xdg-open code regarding quoting of paths with spaces, and
submitted a patch, but the bug has never been acted on and mine and
other posts to the list receive no response.
I'd love to see someone take the lead on these utils. I had a few
suggestions for changes which I would like to try and contribute, and
I've seen a few others pop up on the list with similar suggestions
(patches for integrating with rox, better way to choose a link handler
for items other than http:// and file://, and so on). There are also
some good ideas at http://portland.freedesktop.org/wiki/IntegrationTasks
I believe some distros make their own changes to xdg-utils, for better
or for worse. The nice thing about your solution is that even if
Portland remains unresponsive and slow moving, it would allow distros,
desktop environment devs, and indeed end-users to modify the behaviour
to their own requirements in a simple and clean way. Also, additions
and patches would be more easily reviewed and tested for inclusion as
the code would be more modular.
In the last year, there have been 28 bugs reported on the bugzilla, of
which 1 was fixed and and one marked won't fix.
It looks like Rex Dieter has been active in the CVS adding support for
KDE4 based on patches submitted by a user via Bugzilla. However, even
the last bug marked fixed (in January 08) has not been released yet.
Most freedesktop.org projects have moved to the git repositories but
Portland has not. Even the last release (1.0.2) contains a Changelog
which has not been correctly updated. It all feels very unloved!
I'm a newcomer to the Linux and Open Source development. I'd love to
contribute something here (patches, ideas) but lack the experience to
deal with the bigger issues this project seems to have.
Can anyone help get this moving again? Perhaps a fork is required?
Best regards,
John
Zhe Su wrote:
> Agree. And I like the solution proposed by you. In that way, when we
> have dbus interface defined, we can simply add a script to handle it,
> such as 00-dbus (which has the highest priority).
>
> On Tue, Nov 11, 2008 at 4:20 PM, 洪任諭 <pcman.tw
> <http://pcman.tw>@gmail.com <http://gmail.com>> wrote:
>
> 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
> <http://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
> <http://james.su>@gmail.com <http://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 <mailto: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
> <mailto:Portland at lists.freedesktop.org>
> > http://lists.freedesktop.org/mailman/listinfo/portland
> >
> >
> _______________________________________________
> Portland mailing list
> Portland at lists.freedesktop.org <mailto:Portland at lists.freedesktop.org>
> http://lists.freedesktop.org/mailman/listinfo/portland
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Portland mailing list
> Portland at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/portland
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/portland/attachments/20081111/486c70b4/attachment.html
More information about the Portland
mailing list