Re: libunique external dependency for 2.25?
Hi, Le jeudi 02 octobre 2008, à 23:23 +0100, Emmanuele Bassi a écrit : while the ultimate goal *is* to have this functionality inside gtk+ I'm nowhere near having the time to integrate it myself - not in the way I want it integrated[1], at the very least. another issue is that libunique is pretty much a testing ground for API and requirements and while the basic functionality is obviously already implemented I still receive requests[2] that make sense to add *before* putting the whole shebang in gtk+. we do put stuff in libegg to have it ready for later integration with a reasonable set of API, right? So, it seems nautilus now depends on libunique. I understand the plan is to fix this in gtk+ (hopefully in 2.16), but it will not happen for 2.26 since we'll have gtk+ 2.14. Does it make sense to use libunique for this now, only for 2.26? Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libunique external dependency for 2.25?
Em Qui, 2008-10-02 às 12:55 +0100, Richard Hughes escreveu: On Wed, 2008-10-01 at 19:09 +0200, Alexander Larsson wrote: Then what do you do if its not there? Don't do any of the unique application bits, i.e. start up another instance of the prefs capplet regardless. Richard. I am doing the same thing for vino capplet. LibUnique is used (if detected or forced by --enable-unique) to allow one single instance of capplet. For vinagre, as I *needed* the single instance feature, I just copied the bacon solution, from Bastien. As I already asked [1], it would be nice to have such a dependency, and a good GNOME Goal for 2.26 would be to patch all capplets to have single instance. [1]-http://mail.gnome.org/archives/desktop-devel-list/2007-July/msg00026.html Cheers, -- Jonh Wendell http://www.bani.com.br ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libunique external dependency for 2.25?
On Thu, 2008-10-02 at 11:28 +0200, Vincent Untz wrote:
Le mercredi 01 octobre 2008, à 14:51 +0200, Alexander Larsson a écrit :
I just commited some nautilus code to trunk (for 2.25) that makes use of
libunique for unique application functionallity (replacing the previous
code using bonobo-activation).
However, libunique isn't currently a blessed external dependency. So,
I'd like to propose it. (Another alternative is to put a cut-n-paste
copy in nautilus as fallback, its not a large piece of code anyway.)
I'd love to know what Emmanuele think :-)
while the ultimate goal *is* to have this functionality inside gtk+ I'm
nowhere near having the time to integrate it myself - not in the way I
want it integrated[1], at the very least.
another issue is that libunique is pretty much a testing ground for API
and requirements and while the basic functionality is obviously already
implemented I still receive requests[2] that make sense to add *before*
putting the whole shebang in gtk+. we do put stuff in libegg to have it
ready for later integration with a reasonable set of API, right?
so, as far as I'm concerned, I'll keep working on RFEs and bug fixes for
libunique; I'll try and get something ready to be included in gtk+,
after the problem space, the requiremens and the API have been correctly
defined - though I don't make any promises about it[3]; and I'll gladly
help people that want to do this job, if they think I can answer their
questions.
ciao,
Emmanuele.
+++
[1] a *proper* Application class for gtk+, with the ability to say this
application is also a single instance, so please do the black magic I
need. oh, and an implementation that has fallbacks for cases like ssh
tunnelling, or platforms without D-Bus. this would also help ridding us
of GnomeProgram and another piece of libgnome.
[2] like the small API additions that Alex requested for the usage of
libunique in Nautilus, or the pure X11 backend implementation I want to
finish for libunique 1.2 to be used on platforms *without* D-Bus.
[3] what time my ${DAY_JOB}, my other projects and, more importantly, my
SWMBO leave me, I'll gladly put into libunique and gtk+.
--
Emmanuele Bassi,
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libunique external dependency for 2.25?
Le jeudi 02 octobre 2008 à 23:23 +0100, Emmanuele Bassi a écrit : another issue is that libunique is pretty much a testing ground for API and requirements and while the basic functionality is obviously already implemented I still receive requests[2] that make sense to add *before* putting the whole shebang in gtk+. we do put stuff in libegg to have it ready for later integration with a reasonable set of API, right? Let me jump on this occasion to say that it is not nice at all to put stuff in libegg. This code is generally duplicated in a number of tarballs without any kind of control. When we distributors need to fix a bug, or worse, a security issue, in such a library, we have to find all packages that use it and then fix all of them, both of which are unrealistic. This is why our policy forbids code duplication. I’m speaking only with a Debian hat, but I guess it would be much easier for all distributors if these libraries were shipped in one or several specific tarballs. Even with a constantly changing API or ABI – libtool -release is here to manage that case. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libunique external dependency for 2.25?
2008/10/3 Josselin Mouette [EMAIL PROTECTED]: Le jeudi 02 octobre 2008 à 23:23 +0100, Emmanuele Bassi a écrit : another issue is that libunique is pretty much a testing ground for API and requirements and while the basic functionality is obviously already implemented I still receive requests[2] that make sense to add *before* putting the whole shebang in gtk+. we do put stuff in libegg to have it ready for later integration with a reasonable set of API, right? Let me jump on this occasion to say that it is not nice at all to put stuff in libegg. This code is generally duplicated in a number of tarballs without any kind of control. When we distributors need to fix a bug, or worse, a security issue, in such a library, we have to find all packages that use it and then fix all of them, both of which are unrealistic. This is why our policy forbids code duplication. I'm speaking only with a Debian hat, but I guess it would be much easier for all distributors if these libraries were shipped in one or several specific tarballs. Even with a constantly changing API or ABI – libtool -release is here to manage that case. The alternative is to ship a constantly api/abi changing library, which means you'll either have to constantly patch apps to work with the version you ship or you end up shipping multiple versions of the library. Which brings you back to having to fix stuff in multple places... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libunique external dependency for 2.25?
Le vendredi 03 octobre 2008 à 14:29 -0400, Matthias Clasen a écrit : The alternative is to ship a constantly api/abi changing library, which means you'll either have to constantly patch apps to work with the version you ship or you end up shipping multiple versions of the library. Which brings you back to having to fix stuff in multple places... If at least all packages of a single GNOME release used the same version, that would simplify a lot of things. This would also encourage a lot other applications to synchronize their private copy with the version you ship or to start using it. Bonus points would get to libraries shipping a document explaining how to port applications to the new API when non-trivial. In the end, even if we ship several versions, we will know where copies are. Currently we simply have no idea. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libunique external dependency for 2.25?
On Wed, 2008-10-01 at 19:09 +0200, Alexander Larsson wrote: Then what do you do if its not there? Don't do any of the unique application bits, i.e. start up another instance of the prefs capplet regardless. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libunique external dependency for 2.25?
Le mercredi 01 octobre 2008, à 14:51 +0200, Alexander Larsson a écrit : I just commited some nautilus code to trunk (for 2.25) that makes use of libunique for unique application functionallity (replacing the previous code using bonobo-activation). However, libunique isn't currently a blessed external dependency. So, I'd like to propose it. (Another alternative is to put a cut-n-paste copy in nautilus as fallback, its not a large piece of code anyway.) I'd love to know what Emmanuele think :-) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
libunique external dependency for 2.25?
I just commited some nautilus code to trunk (for 2.25) that makes use of libunique for unique application functionallity (replacing the previous code using bonobo-activation). However, libunique isn't currently a blessed external dependency. So, I'd like to propose it. (Another alternative is to put a cut-n-paste copy in nautilus as fallback, its not a large piece of code anyway.) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libunique external dependency for 2.25?
On Wed, 2008-10-01 at 14:51 +0200, Alexander Larsson wrote: I just commited some nautilus code to trunk (for 2.25) that makes use of libunique for unique application functionallity (replacing the previous code using bonobo-activation). However, libunique isn't currently a blessed external dependency. So, I'd like to propose it. (Another alternative is to put a cut-n-paste copy in nautilus as fallback, its not a large piece of code anyway.) Can't we add that to Gtk+ ? Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libunique external dependency for 2.25?
On Wed, 2008-10-01 at 14:51 +0200, Alexander Larsson wrote: I just commited some nautilus code to trunk (for 2.25) that makes use oflibunique for unique application functionallity (replacing the previous code using bonobo-activation). I already use conditionally in gnome-power-manager and gnome-packagekit. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libunique external dependency for 2.25?
On Wed, 2008-10-01 at 17:51 +0100, Richard Hughes wrote: On Wed, 2008-10-01 at 14:51 +0200, Alexander Larsson wrote: I just commited some nautilus code to trunk (for 2.25) that makes use oflibunique for unique application functionallity (replacing the previous code using bonobo-activation). I already use conditionally in gnome-power-manager and gnome-packagekit. Oh? Then what do you do if its not there? I'd rather not make unique-application functionallity optional, and while i could re-code the grotty dbus and startup notification stuff that libunique does myself I don't quite see the point. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
