Re: Consolidating Core Desktop libraries
On Mon, Nov 22, 2010 at 11:38 PM, Ivan Frade ivan.fr...@gmail.com wrote: Hi On Sun, Nov 14, 2010 at 4:21 PM, Zeeshan Ali zee...@gmail.com wrote: One could also think about reanimating the once proposed d-bus-based thumbnailer[1] if more users show up. Rygel also needs this. Currently we just serve the thumbails if they've been already created by another app but its very much desired to be able to create them ourselves or request another entity to do that. [1]: http://live.gnome.org/ThumbnailerSpec That spec is over-engineered, and far too complicated for what we want to use it for. True and one reason I'm not using it already in Rygel. Another reason to not use this spec is that IMHO we should have one service for both thumbnail and albumart extraction/download with simple APIs (get the thumbnail/albumart for this URI/album/artist and notify me when its done). Maybe the spec is too verbose, but the API itself is simple for application developers: a Queue method to request the thumbnail, Just as an example there is a 'mime_types' parameter to that method which IMO doesn't make any sense. To complicate the matters more, there is ways to 'register' specialized thumbnailers. We need thumbnails for pictures and videos, both of which can be handled by gstreamer in a dynamic way by a single thumbnailer. On top of that, there is more parameters of this simple Queue method (flavor and scheduler) that really doesn't need to be exposed to application developer. Album art is a different issue, and you depend there on external providers. That does't mean we can't have the same service (application) handling both. Not that is not possible, but requires a second thought. Sure, what doesn't? :) -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Consolidating Core Desktop libraries
Hi On Sun, Nov 14, 2010 at 4:21 PM, Zeeshan Ali zee...@gmail.com wrote: One could also think about reanimating the once proposed d-bus-based thumbnailer[1] if more users show up. Rygel also needs this. Currently we just serve the thumbails if they've been already created by another app but its very much desired to be able to create them ourselves or request another entity to do that. [1]: http://live.gnome.org/ThumbnailerSpec That spec is over-engineered, and far too complicated for what we want to use it for. True and one reason I'm not using it already in Rygel. Another reason to not use this spec is that IMHO we should have one service for both thumbnail and albumart extraction/download with simple APIs (get the thumbnail/albumart for this URI/album/artist and notify me when its done). Maybe the spec is too verbose, but the API itself is simple for application developers: a Queue method to request the thumbnail, and a Ready signal with the URI of the result. This is really what needs to be wrapped in a nice GObject-based library (GThumbnail?) Then, as optimization, there are also the methods to avoid the recreation of the thumbnails when the images are moved/copied. There is a third part in the spec, to extend the thumbnailer daemon with out-of-process plugins accessible via DBus. These APIs are implemented by tumbler (open source, coming from the XFCE project) and it is used also in MeeGo. Album art is a different issue, and you depend there on external providers. Not that is not possible, but requires a second thought. In any case a common thumbnail system in the platform is good. Probably it deserves its own thread to discuss if somebody else is interested. Regards, Ivan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Consolidating Core Desktop libraries
Hi, - Original message - On Sat, 2010-11-13 at 13:55 +0100, Felix Riemann wrote: GNOME 3. And nautilus could move the thumbnailer code to use itself. *raiseshand* Eye of GNOME uses the thumbnailer as well (we need to be able to thumbnail without nautilus). But it should be no problem to CP this bit (just 2 files I think) between nautilus and eog. Ok. One could also think about reanimating the once proposed d-bus-based thumbnailer[1] if more users show up. Rygel also needs this. Currently we just serve the thumbails if they've been already created by another app but its very much desired to be able to create them ourselves or request another entity to do that. [1]: http://live.gnome.org/ThumbnailerSpec That spec is over-engineered, and far too complicated for what we want to use it for. True and one reason I'm not using it already in Rygel. Another reason to not use this spec is that IMHO we should have one service for both thumbnail and albumart extraction/download with simple APIs (get the thumbnail/albumart for this URI/album/artist and notify me when its done). -- Regards Zeeshan Ali (Khattak) Sent from Nokia N900___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Consolidating Core Desktop libraries
Hi! Am Freitag, den 12.11.2010, 20:54 + schrieb Bastien Nocera: snip There's currently RandR helpers (g-s-d and control-center), wallpaper handling code (g-s-d, control-center and nautilus), and the thumbnailer (nautilus only, afaik). The RandR stuff could be moved in g-s-d, and the wallpaper code as well, when nautilus stops handling the desktop at some point in GNOME 3. And nautilus could move the thumbnailer code to use itself. *raiseshand* Eye of GNOME uses the thumbnailer as well (we need to be able to thumbnail without nautilus). But it should be no problem to CP this bit (just 2 files I think) between nautilus and eog. One could also think about reanimating the once proposed d-bus-based thumbnailer[1] if more users show up. Regards, Felix [1]: http://live.gnome.org/ThumbnailerSpec ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Consolidating Core Desktop libraries
On Sat, 2010-11-13 at 13:55 +0100, Felix Riemann wrote: *raiseshand* Eye of GNOME uses the thumbnailer as well (we need to be able to thumbnail without nautilus). But it should be no problem to CP this bit (just 2 files I think) between nautilus and eog. One could also think about reanimating the once proposed d-bus-based thumbnailer[1] if more users show up. Evolution also uses the thumbnailer for email attachments. We too can copy and paste those bits if needed (hell, we already copied and pasted gnome-canvas), but the proposed D-Bus thumbnailer would be preferable. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Consolidating Core Desktop libraries
On Sat, 2010-11-13 at 13:55 +0100, Felix Riemann wrote: Hi! Am Freitag, den 12.11.2010, 20:54 + schrieb Bastien Nocera: snip There's currently RandR helpers (g-s-d and control-center), wallpaper handling code (g-s-d, control-center and nautilus), and the thumbnailer (nautilus only, afaik). The RandR stuff could be moved in g-s-d, and the wallpaper code as well, when nautilus stops handling the desktop at some point in GNOME 3. And nautilus could move the thumbnailer code to use itself. *raiseshand* Eye of GNOME uses the thumbnailer as well (we need to be able to thumbnail without nautilus). But it should be no problem to CP this bit (just 2 files I think) between nautilus and eog. Ok. One could also think about reanimating the once proposed d-bus-based thumbnailer[1] if more users show up. Regards, Felix [1]: http://live.gnome.org/ThumbnailerSpec That spec is over-engineered, and far too complicated for what we want to use it for. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Consolidating Core Desktop libraries
Il giorno ven, 12/11/2010 alle 20.54 +, Bastien Nocera ha scritto: There are reasons why all those are separate, and I think we should remember that. I see two reasons: - they have different purposes. - they have been developed by different people at different times. IMHO, reason 1 is not enough, given the example set by Gio (has GFile, GIcon, GAppInfo, GDBusConnection, all in a library), and reason 2 doesn't really hold. We're in the middle of moduleset reorganization, drawing a stricter line on what is core, and thus is expected to work only in GNOME and requires GNOME and is required by GNOME, such wm, the panels, the control center, the session daemons, and what is just an app using the GPlatform (GLib - GIO - Gtk), which therefore will work on every G- desktop environment. I believe this is the time for consolidating shared code used by this core modules into a libgnome-desktop, the same way we killed libgnome and merged useful features in Gtk / Gio. There is a lot of code which is copy-pasted around our desktop. For example, the GsdOsdWindow class, used by gnome-settings-daemon and gnome-power-manager, had to be updated several times because of Gtk breakages. That's 2 users of the library, there's a similar one in Totem. But those will be going away when we get those sort of notifications into the shell directly. IIRC, it is not planned to port GsdOsdWindow in gnome-shell, not in this cycle at least. Another piece of copy-pasted code is gdmuser, which lives in gnome-panel, gdm and gnome-shell, and is constantly being updated because of accountsservice instability. Then we need to make accountsservice more stable. And it could probably ship a small library as well. But why having a separate library when the only possible users already link to gnome-desktop? (It is not that KDE would use libaccountsservice-glib...) I'm really not interested in seeing library aggregation of that sort. We're striving to get rid of most of those, and they will disappear in due time. But why getting rid of what works, and works cleanly and beautifully? Instead we should make it more powerful and more used. This is the point of having an Extended Platform, and a similar point goes for libgnome-desktop. And if it were me, we'd kill gnome-desktop (as a library), and copy/paste the very few bits between the modules that need it. And if it were me, I'd ship gnome-desktop and link it statically. No really, copy/pasting makes it difficult to track changes, to fix bugs, to port code, and results in duplicated object code in our users' hard drives. There's currently RandR helpers (g-s-d and control-center), wallpaper handling code (g-s-d, control-center and nautilus), and the thumbnailer (nautilus only, afaik). Add gnome-shell to the users of GnomeRR (pending bug 634332). The RandR stuff could be moved in g-s-d, and the wallpaper code as well, when nautilus stops handling the desktop at some point in GNOME 3. And nautilus could move the thumbnailer code to use itself. Then gnome-desktop would only be a location for gnome-about. And we will invent a new tiny module every time we need some feature across the desktop (I'm thinking of gsettings-desktop-schemas) or we will hope for maintainers to be kind and update their code. I'm not sure this is really the way forward. (But in the end, it's not that I maintain anything, just I would find it cleaner to have some sort of desktop platform with everything you need.) Giovanni ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Consolidating Core Desktop libraries
On Tue, 2010-11-09 at 22:33 +0100, Giovanni Campagna wrote: Vincent asked me to send a mail to d-d-l aboutdb82a33 in gnome-desktop, that is: all libgnome-desktop include files have been moved to $(includedir)/gnome-desktop-3.0/libgnome-desktop. This is part of an other API break which is related to GnomeRR and introspection. I consider this an occasion for a bigger discussion on redesigning libgnome-desktop, moving forward from being the container of useful libgnome parts, to the One Desktop Library. There are reasons why all those are separate, and I think we should remember that. We're in the middle of moduleset reorganization, drawing a stricter line on what is core, and thus is expected to work only in GNOME and requires GNOME and is required by GNOME, such wm, the panels, the control center, the session daemons, and what is just an app using the GPlatform (GLib - GIO - Gtk), which therefore will work on every G- desktop environment. I believe this is the time for consolidating shared code used by this core modules into a libgnome-desktop, the same way we killed libgnome and merged useful features in Gtk / Gio. There is a lot of code which is copy-pasted around our desktop. For example, the GsdOsdWindow class, used by gnome-settings-daemon and gnome-power-manager, had to be updated several times because of Gtk breakages. That's 2 users of the library, there's a similar one in Totem. But those will be going away when we get those sort of notifications into the shell directly. Another piece of copy-pasted code is gdmuser, which lives in gnome-panel, gdm and gnome-shell, and is constantly being updated because of accountsservice instability. Then we need to make accountsservice more stable. And it could probably ship a small library as well. Then there are microlibraries, killing which would help performance. These include for example libgtop, libgweather and libgnomekbd, but also libgweather is small, but the data it drags in isn't. liboobs if the system tool backends are not dead. I can't find an use for them outside core desktop, while on the other hand there are already core desktop packages that depend on them. My proposal is then to take the classes included in these libraries or copy pasted sources, move them to the Gnome C namespace (GnomeDesktop GIR namespace) and add to libgnome-desktop. API stability is not an issue, as we all know that GNOME_DESKTOP_IS_UNSTABLE_API, and the only users of libgnome-desktop should live in the desktop modulesets, so that if we ever break API, we'll file patches before the affected maintainers even notices. I'm looking forward to read your comments on this. I'm really not interested in seeing library aggregation of that sort. We're striving to get rid of most of those, and they will disappear in due time. And if it were me, we'd kill gnome-desktop (as a library), and copy/paste the very few bits between the modules that need it. There's currently RandR helpers (g-s-d and control-center), wallpaper handling code (g-s-d, control-center and nautilus), and the thumbnailer (nautilus only, afaik). The RandR stuff could be moved in g-s-d, and the wallpaper code as well, when nautilus stops handling the desktop at some point in GNOME 3. And nautilus could move the thumbnailer code to use itself. Then gnome-desktop would only be a location for gnome-about. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Consolidating Core Desktop libraries
On Tue, 2010-11-09 at 22:33 +0100, Giovanni Campagna wrote: There is a lot of code which is copy-pasted around our desktop. For example, the GsdOsdWindow class, used by gnome-settings-daemon and gnome-power-manager, had to be updated several times because of Gtk breakages. Another piece of copy-pasted code is gdmuser, which lives in gnome-panel, gdm and gnome-shell, and is constantly being updated because of accountsservice instability. Then there are microlibraries, killing which would help performance. These include for example libgtop, libgweather and libgnomekbd, but also liboobs if the system tool backends are not dead. I can't find an use for them outside core desktop, while on the other hand there are already core desktop packages that depend on them. I'd say no, as I think you mix quite different things here. Libraries such as libgtop and libgweather already have no API guarantees, and have never been part of the core desktop, so I can't really see the benefit of mixing them all into a single giant module (not counting the coordination issues you might have in a library module with dozens of completely different submodules, each one with a different maintainer and so on). It might be useful instead to create a shared libgnome-core-kitchen-sink library for those widgets or useful pieces of code that are shared across multiple core desktop components but are not generic enough to go into the platform; but we should also make it very clear that such a library should not be used by applications outside of the core desktop, otherwise we have another libgnome/libgnome-ui which we tried really hard to get rid of in the last years :) Cheers, Cosimo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Consolidating Core Desktop libraries
On Tue, Nov 9, 2010 at 4:33 PM, Giovanni Campagna scampa.giova...@gmail.com wrote: I consider this an occasion for a bigger discussion on redesigning libgnome-desktop, moving forward from being the container of useful libgnome parts, to the One Desktop Library. Makes sense to me. The one concern I have is whether or not we should be continually bumping the SONAME. I'd vote for yes - more pain, but also more correct. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Consolidating Core Desktop libraries
Le mardi 09 novembre 2010 à 17:31 -0500, Colin Walters a écrit : Makes sense to me. The one concern I have is whether or not we should be continually bumping the SONAME. I'd vote for yes - more pain, but also more correct. Yes please. Shared libraries without correct versioning are *much* more pain. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Consolidating Core Desktop libraries
On 11/09/10 16:33, Giovanni Campagna wrote: Then there are microlibraries, killing which would help performance. These include for example libgtop, libgweather and libgnomekbd, but also liboobs if the system tool backends are not dead. I can't find an use for them outside core desktop, while on the other hand there are already core desktop packages that depend on them. I'd say no. If it's already in a library that does not break its API every other week, let it be there. That's the correct design anyway. Something like libgweather does not belong in a generic desktop library. behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Consolidating Core Desktop libraries
Behdad: I'd say no. If it's already in a library that does not break its API every other week, let it be there. That's the correct design anyway. Something like libgweather does not belong in a generic desktop library. libgweather is GPL, so it is probably not something that could be integrated into a generic desktop library anyway. I suspect that there are not enough desktop GPL libraries around to do much consolidation with them. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
