Re: New module proposal: Clutter core
On Mon, 2009-08-10 at 20:38 +0200, Jaap A. Haitsma wrote: On Mon, Aug 10, 2009 at 17:37, Emmanuele Bassieba...@gmail.com wrote: hi everyone; I'm proposing to move Clutter (core) from the external dependencies to the Desktop modules. Are you planning on using GNOME resources? (git, bugzilla, ftp on gnome.org) Clutter already has a Git repository, there's no need to switch over to GNOME's (GStreamer, which is in the Desktop library does the same, being hosted on freedesktop.org); same goes for Bugzilla. I can definitely willing to push release tarballs on ftp.gnome.org and push a copy of the API reference on library.gnome.org. I actually wanted to do so for 1.0, so I'll probably contact the library.g.o maintainer for that. http://live.gnome.org/ReleasePlanning/ModuleProposing says that you need to do this it says: Modules must use GNOME FTP for releases. Modules ought to use GNOME Bugzilla and GNOME Git (there had better be a very good reason for not doing so, such as freedesktop.org hosted libraries designed to be used by both GNOME and KDE). which I daresay Clutter falls under the good reason for not doing so as in we already have infrastructure in place for it[0]. ciao, Emmanuele. +++ [0] Though I must admit that switching to GNOME's Bugzilla would be pretty nice, we do have some Clutter-specific bits in our own Bugzilla that would make the transition problematic -- first and foremost the copyright waiver attachment flag for patches. -- Emmanuele Bassi, W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Bump gtk-vnc dependency
Hello, folks. I want to update vinagre dependency on gtk-vnc to 0.3.9, which was released today. It has some key features that I really would like to see in vinagre 2.28. Okay? -- 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 -- 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
Evolution branched for GNOME 2.28
Hi, We have made a early branching for evolution for GNOME 2.28. We have been discussing on this in the past and to have the context, please go through the following threads, http://mail.gnome.org/archives/evolution-hackers/2009-August/msg8.html and http://mail.gnome.org/archives/release-team/2009-June/msg00018.html The following modules have been branched, gtkhtml, evolution-data-server, evolution and evolution-exchange. The branch is gnome-2-28. Only critical fixes will be made for evolution-2.28. By critical fixes, I mean blockers and important bugs identified as must-fix by module maintainers. All freezes would apply for gnome-2-28 branch. Please note that these patches needs to be committed to master and gnome-2-28 branch. The kill-bonobo-branch and eds-dbus-port will be merged into master. So it means master will not have any freezes. Most of the active work will be going on master branch to get it usable for evolution 2.29.1. Once the branches are merged to trunk, we would be replying back to this thread mentioning the same. We have made a rough road-map for Evolution 3.0 - http://www.go-evolution.org/Evo3.0 which will be discussed and modified further. We will also be discussing over some pending tasks from Evolution 2.28 and include the ones which are possible for http://www.go-evolution.org/Evo2.28 . Thanks, Chenthill. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Signalling when the desktop is loaded
Hello, So I was talking briefly to vuntz in irc yesterday about wanting to have some kind of mechanism to find out when the desktop session is ready (ie, not once Nautilus and panel are launched, but when they are actually pretty usable and done loading stuff). In terms of the panel, vuntz suggested maybe adding a signal in panel_applet_queue_initial_unhide_toplevels() under org.gnome.Panel. In Nautilus there is FMDesktopIconView end_loading signal that seems to work well. It would be nice to have a single signal that could be emitted once both of these are finished, so I wanted to post here and see what others think and get suggestions on where this might be done. / Cody ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Signalling when the desktop is loaded
Cody Russell wrote: So I was talking briefly to vuntz in irc yesterday about wanting to have some kind of mechanism to find out when the desktop session is ready (ie, not once Nautilus and panel are launched, but when they are actually pretty usable and done loading stuff). In terms of the panel, vuntz suggested maybe adding a signal in panel_applet_queue_initial_unhide_toplevels() under org.gnome.Panel. In Nautilus there is FMDesktopIconView end_loading signal that seems to work well. It would be nice to have a single signal that could be emitted once both of these are finished, so I wanted to post here and see what others think and get suggestions on where this might be done. I don't know your precise usecase, but perhaps gnome-session could signal over D-Bus when it changes phase ? (it already has a SessionRunning signal, sent once it's done) Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Signalling when the desktop is loaded
2009/8/11 Alexey Rusakov kt...@altlinux.org: В Втр, 11/08/2009 в 11:55 -0500, Cody Russell пишет: So I was talking briefly to vuntz in irc yesterday about wanting to have some kind of mechanism to find out when the desktop session is ready (ie, not once Nautilus and panel are launched, but when they are actually pretty usable and done loading stuff). In terms of the panel, vuntz suggested maybe adding a signal in panel_applet_queue_initial_unhide_toplevels() under org.gnome.Panel. In Nautilus there is FMDesktopIconView end_loading signal that seems to work well. What if I don't run Nautilus at the start of the session (don't use it to draw the desktop)? I mean /apps/nautilus/preferences/show_desktop GConf key. See below... It would be nice to have a single signal that could be emitted once both of these are finished, so I wanted to post here and see what others think and get suggestions on where this might be done. Maybe add a startup inhibit-like semaphore on the session interface so apps like panel and nautilus can get a lock on start and release it when they are done. Other apps would just wait for the no more lockers signal on the session interface. Bonus: we could share this interface with other freedesktop members. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Signalling when the desktop is loaded
Hi, 2009/8/11 Frederic Peters fpet...@gnome.org: Cody Russell wrote: So I was talking briefly to vuntz in irc yesterday about wanting to have some kind of mechanism to find out when the desktop session is ready (ie, not once Nautilus and panel are launched, but when they are actually pretty usable and done loading stuff). In terms of the panel, vuntz suggested maybe adding a signal in panel_applet_queue_initial_unhide_toplevels() under org.gnome.Panel. In Nautilus there is FMDesktopIconView end_loading signal that seems to work well. It would be nice to have a single signal that could be emitted once both of these are finished, so I wanted to post here and see what others think and get suggestions on where this might be done. I don't know your precise usecase, but perhaps gnome-session could signal over D-Bus when it changes phase ? (it already has a SessionRunning signal, sent once it's done) The change of phase in gnome-session only means all apps from that phase are successfully running. It doesn't mean the apps are already usable. At some point I added a SessionRunning signal to session manager to announce gnome-session entered RUNNING phase. This change got lost somehow when merging the new code to master... This is not what is being proposed here anyway. --lucasr ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-keyring API Migration
As posted here previously, KDE and GNOME developers are working together on a new DBus based API for storing secrets [1]. I'm working hard to implement this new API in gnome-keyring, while we're finalizing it. It contains many beneficial changes, and lessons learned. You can join in on the discussion on the XDG mailing list [2]. It's very likely that there will be a new client side library which wraps this DBus API. The current libgnome-keyring.so will be probably be replaced by compatibility shims. These shims would be distributed separately from the gnome-keyring distribution. This library would eventually be deprecated. The current (undocumented, unstable, private) binary protocol that gnome-keyring-daemon and libgnome-keyring speak to each other will go away. It's grown crufty and hard to extend. The DBus based secrets API is the future. Migration Effort: * Most normal applications using libgnome-keyring will have almost no immediate migration needed, due to the compatibility shims. * Module packagers may need to update dependencies. * Patches will be contributed to seahorse, gnome-session, gnome-power-manager and any others that interact with gnome-keyring in unique ways. * Parts of java-gnome and gnome-sharp and any others who talk to gnome-keyring using the unsupported private binary protocol will need to be rewritten by their developers. We're working hard to finish all this by 2.30 (ie: 3.0), but that's pretty soon. It'd be awesome if 2.30 was a 9 month cycle. Cheers, Stef [1] http://www.gnome.org/~stefw/secrets/html/ [2] http://lists.freedesktop.org/mailman/listinfo/authentication ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
