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). <div class="gmail_quote">On Tue, Nov 11, 2008 at 4:20 PM, 洪任諭 <<a href="http://pcman.tw">pcman.tw</a>@<a href="http://gmail.com">gmail.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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 <a href="http://freedesktop.org" target="_blank">freedesktop.org</a> spec and force all desktop environments to share the same config file for defining default browser and mail client. <div><div></div><div class="Wj3C7c"> On Tue, Nov 11, 2008 at 3:58 PM, Zhe Su <<a href="http://james.su" target="_blank">james.su</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>> 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 <<a href="mailto:astrand@cendio.se">astrand@cendio.se</a>> 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               <a href="http://www.cendio.com" target="_blank">http://www.cendio.com</a> >> Wallenbergs gata 4 >> 583 30 Linköping        Phone: +46-13-21 46 00 > </div></div><div><div></div><div class="Wj3C7c">> _______________________________________________ > Portland mailing list > <a href="mailto:Portland@lists.freedesktop.org">Portland@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/portland" target="_blank">http://lists.freedesktop.org/mailman/listinfo/portland</a> > > _______________________________________________ Portland mailing list <a href="mailto:Portland@lists.freedesktop.org">Portland@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/portland" target="_blank">http://lists.freedesktop.org/mailman/listinfo/portland</a> </div></div></blockquote></div>