Gnome-panel-handles do not accept transparency
I'm sure lots of people have raised the issue that although most of the panel can be made transparent, when the panel is resized not to cover the entire width, the handles that show up do not accept transparency values. This is unacceptable, right? these handles look pretty much like gtk1.0 boxes. Please, tell me someone is willing to patch this for me, I've got $10 in my paypal account I'll give them, plus a cookie. I saw a bug report on the ubuntu launchpad site submitted about this in 2006! And don't tell me you are getting rid of gnome-panel, this can be fixed anyway, please? Joshuah Kuttenkuler --- Processed at location stamped in INVISIBLE INK MADE FROM NON-FAT SOY CHEESE AND CHEAP TOASTER STRUDEL at top of message. Your compliance with *all* of my terms and conditions, expressed or implied,unexpressed or unimplied, is automatic upon viewing, opening, receiving, or deleting this message. P.S.: I did it for the lulz Long live the Zaftian empire. P.P.S. This signature is a sign that I have auspergers and should be ignored entirely. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Planning for GNOME 3.0
During the first few months of 2008, a few Release Team members discussed here and there about the state of GNOME. This was nothing official, and it could actually have been considered as some friends talking together about things they deeply care about. There were thoughts that GNOME could stay with the 2.x branch for a very long time given our solid development methods, but that it was not the future that our community wants to see happening. Because of lack of excitement. Because of lack of vision. Slowly, a plan started to emerge. It evolved, changed, was trimmed a bit, made more solid. We started discussing with a few more people, got more feedback. And then, at GUADEC, the Release Team proposed an initial plan to the community that would lead the project to GNOME 3.0. Quite some time passed; actually, too much time passed because too many people were busy with other things. But it's never too late to do the right thing, so let's really be serious about GNOME 3.0 now! Let's first diverge a bit and discuss the general impression that GNOME is lacking a vision. If you look closely at our community, it'd be wrong to say that people are lacking a vision; but the project as a whole does indeed have this issue. What we are missing is people blessing one specific vision and making it official, giving goals to the community so we can all work together in the same direction. In the pre-2.x days, the community accepted as a whole one specific vision, and such an explicit blessing wasn't needed. But during the 2.x cycle, with our six months schedules, it appeared that everything (community, development process, etc.) was just working very well, and as the vision got more and more fulfilled, the long-term plans became less important as we focused on polishing our desktop. But we've now reached a point where our next steps should be moving to another level, and those next steps require important decisions. This is part of what the Release Team should do. Please note that Release Team members don't have to be the ones who have the vision; we just have to be the voice of the community. (As a sidenote, the roadmap process [1] that we tried to re-establish two years ago was a first attempt to fix this. Unfortunately, it turned out that we were missing the most important side of things: a project-wide roadmap. This is because a collection of individual roadmaps isn't enough to create a project-wide roadmap.) So let's go to the core topic and discuss what the GNOME 3.0 effort should be. We propose the following list of areas to focus our efforts on: - Revamp our User Experience - Streamlining of the Platform - Promotion of GNOME There are also other potential areas that are worth exploring if there is enough interest from the community. From a release management perspective, there are various questions that are raised in the GNOME 3.0 context. We definitely need a plan to organize the development (see below for details on it), but we might also want to take this opportunity to rethink how we ship GNOME: are the module sets still the best way to deliver GNOME? There is no obvious answer to this, but the way we will present GNOME in the future will certainly have an impact on this. Revamp our User Experience When talking with some great people at GUADEC about GNOME 3.0, one concern that came more than once was that it would be an error to do GNOME 3.0 without any big user-visible change. While some of us didn't necessarily agree with this concern, it was still a fairly valid one. But it turns out that if you tell the community that there's something after 2.x, then the community will stop vaguely thinking about future ideas and start working on concrete plans. It seems pretty clear now that there are two important ideas that can have a real positive impact on the user experience: - GNOME Shell [2]: the shell idea is not just about changing the panel and the window manager. It's about changing the way you start an activity and how you switch between two different activities. Or more generally, how you manage your different activities on the desktop. - Changing the way we access documents (via a journal, like GNOME Zeitgeist [3]): having to deal with a filesystem in their daily work is not what makes users happy -- on the contrary, they generally just want to access their documents and not to browse their hard disk. Providing new solutions to this problem (using timelines, tags, bookmarks, etc.) is something that has been of interest in our community for a long time, but we never completely jumped in. We simply should. These two ideas can form the basis of an overhauled GNOME user experience; they are not the only changes that we can and will do, but they definitely are the most advanced projects to help us move forward in terms of user experience. The GNOME Shell and the GNOME Zeitgeist projects are indeed already well underway, with working code
GNOME 3.0 Schedule draft; Streamlining of the Platform.
Ahoj, a draft for the GNOME 2.27 2.29 schedule is now available at http://live.gnome.org/TwoPointTwentyseven . The schedule also includes a plan to clean up the platform by getting rid of deprecated modules. Maintainers can see the GNOME 3 readiness of their modules on Frederic's awesome status page at http://www.gnome.org/~fpeters/299.html . Comments discussion welcome. Notes: * 2.30.0 is planned to be 3.0.0, if the QA agrees (For a general GNOME 3 debate, please see other threads like Vincent's recent posting at http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg4.html and http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg5.html ). I don't plan to cover everything+1 in this schedule, it's just that I concentrated on platform streamlining.) * Only two maintenance releases for 2.28.x * Early module freeze for 2.30 * More earlier 2.29.x releases than normally (better testing) * Two weeks hardcode freeze before 2.30.0 - late release at the last day of march 2010 * Still to discuss: dconf vs gconf. This is not yet covered by this plan, but crucial to discuss (as gconf depends on Bonobo) - robtaylor and/or desrt will probably elaborate its current state. * Still to discuss: a11y plan for GNOME3 - see http://live.gnome.org/Accessibility/BonoboDeprecation Already know some 2.28 plans for the module you maintain? Add them to http://live.gnome.org/RoadMap now! andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.
2009/4/2 Andre Klapper ak...@gmx.net: Ahoj, a draft for the GNOME 2.27 2.29 schedule is now available at http://live.gnome.org/TwoPointTwentyseven . The schedule also includes a plan to clean up the platform by getting rid of deprecated modules. Maintainers can see the GNOME 3 readiness of their modules on Frederic's awesome status page at http://www.gnome.org/~fpeters/299.html . Comments discussion welcome. Notes: * 2.30.0 is planned to be 3.0.0, if the QA agrees (For a general GNOME 3 debate, please see other threads like Vincent's recent posting at http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg4.html and http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg5.html ). I don't plan to cover everything+1 in this schedule, it's just that I concentrated on platform streamlining.) * Only two maintenance releases for 2.28.x * Early module freeze for 2.30 * More earlier 2.29.x releases than normally (better testing) * Two weeks hardcode freeze before 2.30.0 - late release at the last day of march 2010 * Still to discuss: dconf vs gconf. This is not yet covered by this plan, but crucial to discuss (as gconf depends on Bonobo) - robtaylor and/or desrt will probably elaborate its current state. * Still to discuss: a11y plan for GNOME3 - see http://live.gnome.org/Accessibility/BonoboDeprecation How does the release of Gtk+ 3.0 fits with this schedule. Is this something totally independent? Already know some 2.28 plans for the module you maintain? Add them to http://live.gnome.org/RoadMap now! andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Un saludo, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
Hi! - create a staging area in the platform for libraries that aim to be in our platform but do not offer enough guarantees at the moment (like GStreamer): this will send a clear message on what should be used; - include new exciting technologies that we're starting to see used in our desktop. Some obvious examples are 3D effects (with Clutter) and geolocalization (with GeoClue and libchamplain). - rework the way we present the platform to also integrate some of the external dependencies: while, say, D-Bus or Avahi are external dependencies, they are definitely what we want developers to use. And it's easy to be more explicit about this. What about gconf/dconf? Or in other words - does GNOME 3.0 depend on dconf and is gconf deprecated (soon!) or not? Regards, Johannes 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: Planning for GNOME 3.0
Am Donnerstag, den 02.04.2009, 14:06 +0200 schrieb Johannes Schmid: What about gconf/dconf? Or in other words - does GNOME 3.0 depend on dconf and is gconf deprecated (soon!) or not? No decisions yet, but definitely should be discussed after desrt and/or robtaylor have posted a follow-up mail describing the current state of dconf. andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Promotion (was Planning for GNOME 3.0)
Vincent Untz wrote: During the first few months of 2008, a few Release Team members discussed here and there about the state of GNOME. This was nothing Wow, long interesting email! I'll limit myself to one area: - Promotion of GNOME This does seems to be lacking. If you go to http://www.gnome.org, you will see NOTHING about WHY an average person would want to use Gnome. If you click on http://www.gnome.org/about, you'll find a list of noble attributes of Gnome, but that page really is 100% excitement-free. It looks like it was typed into a wiki by an engineer. Which I'm sure it was... Could I suggest that someone (yes, I can help) develop a few key Gnome is concepts and illustrate them with memorable graphics (sorry, I can't help beyond stick figures). They should be things that appeal to the mythical grandma user. Like: Gnome - Don't Need No Stinkin' Anti-Virus Software! Gnome - Free Software - Why Pay More? Gnome - In Your Language! Gnome - Where the Code Isn't Secret! That's just off the top of my head. I'm sure better ones could be developed. I don't see anything on gnome.org promoting Gnome's security. This would be especially compelling in the age of conficker! Us coders know that gnome isn't perfect either, but it really is a million times better than that other OS... Also: Every computer seems to come with a Designed for Windows sticker. Can the Foundation promote Gnome logo stickers with those manufacturers who do offer pre-installed linux/gnome? - Mike ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
On Thu, Apr 2, 2009 at 8:14 AM, Andre Klapper ak...@gmx.net wrote: Am Donnerstag, den 02.04.2009, 14:06 +0200 schrieb Johannes Schmid: What about gconf/dconf? Or in other words - does GNOME 3.0 depend on dconf and is gconf deprecated (soon!) or not? No decisions yet, but definitely should be discussed after desrt and/or robtaylor have posted a follow-up mail describing the current state of dconf. I might suggest that the rule of thumb should be 'if a platform is ready for the 2.28 timeframe, then it can be required in 3.0, otherwise it has to wait.' This would allow six whole months to port, debug, etc. But (among other things) gtk is not going to be ready in that timeframe. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
On Thu, Apr 2, 2009 at 3:04 PM, Natan Yellin aan...@gmail.com wrote: On Thu, Apr 2, 2009 at 2:17 PM, Vincent Untz vu...@gnome.org wrote: - Changing the way we access documents (via a journal, like GNOME Zeitgeist [3]): having to deal with a filesystem in their daily work is not what makes users happy -- on the contrary, they generally just want to access their documents and not to browse their hard disk. Providing new solutions to this problem (using timelines, tags, bookmarks, etc.) is something that has been of interest in our community for a long time, but we never completely jumped in. We simply should. Thanks for mentioning the project. We're in the middle of a major rewrite right now, and it's great to know that people have noticed the project and liked it. We're currently looking for mockups and new ideas related to the user interface. If anyone is interested in helping out, we'd love to see you in the #zeitgeist channel on irc.gnome.org. :) Whoops. That should be #gnome-zeitgeist. Sorry for any confusion that might have caused. :( ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
On Thu, Apr 2, 2009 at 8:14 AM, Andre Klapper ak...@gmx.net wrote: Am Donnerstag, den 02.04.2009, 14:06 +0200 schrieb Johannes Schmid: What about gconf/dconf? Or in other words - does GNOME 3.0 depend on dconf and is gconf deprecated (soon!) or not? No decisions yet, but definitely should be discussed after desrt and/or robtaylor have posted a follow-up mail describing the current state of dconf. I might suggest that the rule of thumb should be 'if a platform is ready for the 2.28 timeframe, then it can be required in 3.0, otherwise it has to wait.' This would allow six whole months to port, debug, etc. But (among other things) gtk is not going to be ready in that timeframe. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.
On Thu, 2009-04-02 at 13:20 +0200, Andre Klapper wrote: * Still to discuss: dconf vs gconf. This is not yet covered by this plan, but crucial to discuss (as gconf depends on Bonobo) There is gconf-dbus, the long-standing port of GConf to DBus that Imendio did for Maemo. Moblin also ships it and it shouldn't be *too* difficult to merge it back[1]. Ross [1] I may regret saying this -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: GNOME 3.0 Schedule draft; Streamlining of the Platform.
2009/4/2 Ross Burton r...@burtonini.com: On Thu, 2009-04-02 at 13:20 +0200, Andre Klapper wrote: * Still to discuss: dconf vs gconf. This is not yet covered by this plan, but crucial to discuss (as gconf depends on Bonobo) There is gconf-dbus, the long-standing port of GConf to DBus that Imendio did for Maemo. Moblin also ships it and it shouldn't be *too* difficult to merge it back[1]. My understanding on this after talking with Richard Hult, is that there is no GConf maintainer, and the DBus port is a huge hack and not really suitable for the main branch, and that a proper merge would need a lot of work. Ross [1] I may regret saying this -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Un saludo, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.
On Thu, 2009-04-02 at 13:41 +0100, Alberto Ruiz wrote: My understanding on this after talking with Richard Hult, is that there is no GConf maintainer, and the DBus port is a huge hack and not really suitable for the main branch, and that a proper merge would need a lot of work. There being no GConf maintainer makes this easy for a suitably willing person to do the merge. I prefer the phrasing needs cleaning up to a huge hack myself though. :) Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: GNOME 3.0 Schedule draft; Streamlining of the Platform.
2009/4/2 Ross Burton r...@burtonini.com: On Thu, 2009-04-02 at 13:41 +0100, Alberto Ruiz wrote: My understanding on this after talking with Richard Hult, is that there is no GConf maintainer, and the DBus port is a huge hack and not really suitable for the main branch, and that a proper merge would need a lot of work. There being no GConf maintainer makes this easy for a suitably willing person to do the merge. I prefer the phrasing needs cleaning up to a huge hack myself though. :) Well, at this point we have someone willing to write a piece of software with loads of benefits and some code available over GConf and none volunteering on doing the merge. Unless you are volunteering yourself :-) Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com -- Un saludo, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.
On Thu, 2009-04-02 at 13:41 +0100, Alberto Ruiz wrote: 2009/4/2 Ross Burton r...@burtonini.com: On Thu, 2009-04-02 at 13:20 +0200, Andre Klapper wrote: * Still to discuss: dconf vs gconf. This is not yet covered by this plan, but crucial to discuss (as gconf depends on Bonobo) There is gconf-dbus, the long-standing port of GConf to DBus that Imendio did for Maemo. Moblin also ships it and it shouldn't be *too* difficult to merge it back[1]. My understanding on this after talking with Richard Hult, is that there is no GConf maintainer, and the DBus port is a huge hack and not really suitable for the main branch, and that a proper merge would need a lot of work. Is it more or less work than finishing the replacement, and porting all the apps and developer documentation, as well as writing porting documentation? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.
On Thu, 2009-04-02 at 14:26 +0100, Alberto Ruiz wrote: Well, at this point we have someone willing to write a piece of software with loads of benefits and some code available over GConf and none volunteering on doing the merge. Unless you are volunteering yourself :-) Actually, looking at the state of gconf vs gconf-dbus was on my todo list. But if dconf is more than vapourware then I'm all for deprecating gconf! Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Promotion (was Planning for GNOME 3.0)
Mike, We'd love to have your help. We really need help defining what GNOME is to non-hackers and promoting it appropriately on the website and in presentations people give. You are right that the about page doesn't actually say what GNOME is! The marketing list[1] would be a good place to discuss this. Thanks! Stormy [1] http://mail.gnome.org/mailman/listinfo/marketing-list On Thu, Apr 2, 2009 at 6:21 AM, Dr. Michael J. Chudobiak m...@avtechpulse.com wrote: Vincent Untz wrote: During the first few months of 2008, a few Release Team members discussed here and there about the state of GNOME. This was nothing Wow, long interesting email! I'll limit myself to one area: - Promotion of GNOME This does seems to be lacking. If you go to http://www.gnome.org, you will see NOTHING about WHY an average person would want to use Gnome. If you click on http://www.gnome.org/about, you'll find a list of noble attributes of Gnome, but that page really is 100% excitement-free. It looks like it was typed into a wiki by an engineer. Which I'm sure it was... Could I suggest that someone (yes, I can help) develop a few key Gnome is concepts and illustrate them with memorable graphics (sorry, I can't help beyond stick figures). They should be things that appeal to the mythical grandma user. Like: Gnome - Don't Need No Stinkin' Anti-Virus Software! Gnome - Free Software - Why Pay More? Gnome - In Your Language! Gnome - Where the Code Isn't Secret! That's just off the top of my head. I'm sure better ones could be developed. I don't see anything on gnome.org promoting Gnome's security. This would be especially compelling in the age of conficker! Us coders know that gnome isn't perfect either, but it really is a million times better than that other OS... Also: Every computer seems to come with a Designed for Windows sticker. Can the Foundation promote Gnome logo stickers with those manufacturers who do offer pre-installed linux/gnome? - Mike ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.
On Thu, 2009-04-02 at 14:30 +0100, Bastien Nocera wrote: On Thu, 2009-04-02 at 13:41 +0100, Alberto Ruiz wrote: 2009/4/2 Ross Burton r...@burtonini.com: On Thu, 2009-04-02 at 13:20 +0200, Andre Klapper wrote: * Still to discuss: dconf vs gconf. This is not yet covered by this plan, but crucial to discuss (as gconf depends on Bonobo) There is gconf-dbus, the long-standing port of GConf to DBus that Imendio did for Maemo. Moblin also ships it and it shouldn't be *too* difficult to merge it back[1]. My understanding on this after talking with Richard Hult, is that there is no GConf maintainer, and the DBus port is a huge hack and not really suitable for the main branch, and that a proper merge would need a lot of work. Is it more or less work than finishing the replacement, and porting all the apps and developer documentation, as well as writing porting documentation? I add another question here, as a complete dconf/GConf newbie: is depending on Bonobo/Corba vs DBus the only thing that makes GConf not useful towards GNOME 3.0 or are there some other design/preformance/whatever issues requiring a full rewrite to be solved? We learned, with the GIO transition, that porting lots of applications isn't fun, and is something which takes much time to be completed project-wide. As GConf is probably even more widely used than gnome-vfs was, porting could be an even bigger effort. Ciao, Cosimo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.
Cosimo Cecchi wrote: On Thu, 2009-04-02 at 13:20 +0200, Andre Klapper wrote: * Still to discuss: dconf vs gconf. This is not yet covered by this plan, but crucial to discuss (as gconf depends on Bonobo) There is gconf-dbus, the long-standing port of GConf to DBus that Imendio did for Maemo. Moblin also ships it and it shouldn't be *too* difficult to merge it back[1]. My understanding on this after talking with Richard Hult, is that there is no GConf maintainer, and the DBus port is a huge hack and not really suitable for the main branch, and that a proper merge would need a lot of work. Of course, if nothing else is going to depend on Bonobo and GConf doesn't expose Bonobo in its API (which I think it doesn't) then we could just move libbonobo into the gconf source tree, as a private library, and then complete the D-Bus fixup/merge at our leisure after that. We learned, with the GIO transition, that porting lots of applications isn't fun, and is something which takes much time to be completed project-wide. As GConf is probably even more widely used than gnome-vfs was, porting could be an even bigger effort. GConf-DConf seems like it might be less work per module than gnome-vfs-gio though... -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
2009/4/2 Vincent Untz vu...@gnome.org: - include new exciting technologies that we're starting to see used in our desktop. Some obvious examples are 3D effects (with Clutter) and geolocalization (with GeoClue and libchamplain). Thanks for mentionning libchamplain. Just in case anyone never heard of it: http://projects.gnome.org/libchamplain/ A proposed widget to display maps in your applications. Geoclue: http://www.freedesktop.org/wiki/Software/GeoClue A modular geoinformation service to make creating location-aware applications as simple as possible. With Geoclue, get your position and convert addresses into positions, with libchamplain display that information! Pierre-Luc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.
On Thu, Apr 2, 2009 at 7:20 AM, Andre Klapper ak...@gmx.net wrote: a draft for the GNOME 2.27 2.29 schedule is now available at http://live.gnome.org/TwoPointTwentyseven . The libglade/GtkBuilder transition is on the plan to begin at the end of this month. Currently the transition documentation is pretty pitiful. Has someone volunteered to update it/flesh it out between now and then? Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.
For the accessibility portion, here's some strawman stuff that will be solidified soon (I hope): 1) Luke Yelavich at Canonical is planning on looking at speech dispatcher as a proposed replacement for gnome-speech. If he gets support from his management to do the work and is successful at meeting the sundry of requirements being placed on a speech synthesis solution, we can deprecate/remove gnome-speech. Note that speech dispatcher will likely end up as a cross platform project under the Linux Foundation Open A11y community. 2) We are working with another organization right now to investigate magnification solutions. This may involve picking up on http://projects.gnome.org/outreach/a11y/tasks/magnification/, and I suspect the ultimate solution will be a combination of improvements to Compiz's eZoom plugin plus a D-Bus API. If so, this may end up as a Compiz project. 3) In two weeks, Sun is hosting a meeting between Sun, Codethink, and Novell to develop a go forward plan to get the AT-SPI/D-Bus work to a point where the existing Bonobo/CORBA solution can be supplanted. This includes figuring out what to do about applications that currently depend upon cspi. Since it is cross platform, this may also end up as a project under the Linux Foundation's Open A11y group. I'd also like to organize something at GUADEC around this since it is basically a rewrite of the entire accessibility infrastructure for GNOME. In the end, we will have also created a solution that is compatible with KDE desktops and is also more amenable to mobile devices. Keep an eye on http://live.gnome.org/Accessibility/BonoboDeprecation for details. Hope this ties you over until we can solidify things more, Will On Apr 2, 2009, at 7:20 AM, Andre Klapper wrote: Ahoj, a draft for the GNOME 2.27 2.29 schedule is now available at http://live.gnome.org/TwoPointTwentyseven . The schedule also includes a plan to clean up the platform by getting rid of deprecated modules. Maintainers can see the GNOME 3 readiness of their modules on Frederic's awesome status page at http://www.gnome.org/~fpeters/299.html . Comments discussion welcome. Notes: * 2.30.0 is planned to be 3.0.0, if the QA agrees (For a general GNOME 3 debate, please see other threads like Vincent's recent posting at http://mail.gnome.org/archives/desktop-devel-list/2009-April/ msg4.html and http://mail.gnome.org/archives/desktop-devel-list/2009-April/ msg5.html ). I don't plan to cover everything+1 in this schedule, it's just that I concentrated on platform streamlining.) * Only two maintenance releases for 2.28.x * Early module freeze for 2.30 * More earlier 2.29.x releases than normally (better testing) * Two weeks hardcode freeze before 2.30.0 - late release at the last day of march 2010 * Still to discuss: dconf vs gconf. This is not yet covered by this plan, but crucial to discuss (as gconf depends on Bonobo) - robtaylor and/or desrt will probably elaborate its current state. * Still to discuss: a11y plan for GNOME3 - see http://live.gnome.org/Accessibility/BonoboDeprecation Already know some 2.28 plans for the module you maintain? Add them to http://live.gnome.org/RoadMap now! andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
dconf
Hello, d-d-l. I'm a long-time listener, first time caller. Many of you are probably aware of two things about me: 0) I'm that guy who is working on that weird cloud of dbus-ish stuff involving GVariant and dconf and GSettings, etc. 1) A few months ago I started working for Codethink This email is a statement of status, of direction and of intention. A lot of people have been asking what is going on, so this is an update. It's not really an attempt to start a discussion, but if that happens, then I'm happy to answer any questions. :) first: GVariant. GVariant has been in an essentially-complete state for quite a long time now. I recently rolled a tarball of it and announced it to the announcement list. It is available here: http://www.gnome.org/~ryanl/src/ GVariant is currently hosted as a totally separate project in a git repository on git.desrt.ca: https://desrt.ca/gitweb/?p=gvariant The intention is that it be merged with glib (into the base libglib library). Now that glib is in git I will be making a branch and performing the merge. This should be complete within a couple of days. I will then propose it for inclusion in the next release of glib. GVariant is reasonably well-tested and is being used in a number of other projects that I'm working on. Of course, it surely has some bugs hiding in it. I believe that the API is more or less stable at this point, but I welcome constructive criticism and feedback. There are plans to add more functionality (such as the ability to print/parse pythonic text strings). You can read more details about how GVariant works in the release announcement here: http://mail.gnome.org/archives/gnome-announce-list/2009-March/msg00103.html second: dconf and GSettings For some time I've been talking about these pair of projects as a proposed replacement for GConf. The reasons that we might want to replace GConf are well understood and widely documented and I won't talk about them here. A while ago there was even a reasonably-working implementation of dconf. This was based on a different value system (ie: before I started writing the more-generally-useful GVariant). I stopped working on dconf when I shifted focus to GVariant and when school started consuming a lot of my time. Recently, sponsored by Codethink (now my employer), I have resumed work on dconf. This has come in the form of a total rewrite (and simplification) based on GVariant. This rewrite (along with another project, GBus) is doing a lot to convince me of the stability and usability of GVariant. Briefly, dconf is a simple untyped hierarchy of keys. It is used as the backend storage for GSettings which is a very strictly typed high-level settings system intended to be used by GNOME applications. The API is much nicer than GConf. dconf is very efficient. The majority case in accessing settings is reading (think about desktop login: 1000s of settings read, none written). Reading in dconf is done directly from a memory-mapped file containing the settings in an efficient tree format and doesn't require an extra service to be running. The service is only needed for writes. Communication occurs over DBus, of course. :) The rewrite of dconf is currently extremely unstable and incomplete, but it is currently being hacked on (along with GSettings) full-time. Progress is good. In a week or two I will have something to show for this and I intend to have a stable release to go along with 2.28. Stay tuned. :) Ideally, I'd like to see GNOME using GSettings for 3.0. Rob Taylor (my boss) has indicated that I will definitely be able to spend time addressing issues that may arise with dconf and GSettings in the lead-up to 3.0. So that's it. That's what I'm up to. Have a good day :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
I'm really excited about GNOME 3.0. There are a lot of great ideas that people have come up with. As people work on new GUI designs, I request that people engage the GNOME accessibility team on their designs. Accessibility is a big selling point for GNOME and I'd really hate to see it take a step back. Too often, GUI designers and developers forget about important details such as keyboard access, theming, and support for the AT-SPI. It's a lot easier to develop for accessibility from the beginning than to retrofit later. Engaging earlier than later also helps us act more like a team than adversaries. For developers local to the Boston area, I'm happy to take a visit to your sight to go over accessibility considerations and to discuss your new UI's with you from an accessibility standpoint. I promise to focus solely on accessibility considerations and will avoid general armchair HCI quarterbacking. For those outside the Boston area, we can try to find someone to visit you for a face-to-face and/or we could do conference calls with screenshots or just shared desktops via VNC. Thanks! Will (your friendly GNOME a11y guy) On Apr 2, 2009, at 7:17 AM, Vincent Untz wrote: During the first few months of 2008, a few Release Team members discussed here and there about the state of GNOME. This was nothing official, and it could actually have been considered as some friends talking together about things they deeply care about. There were thoughts that GNOME could stay with the 2.x branch for a very long time given our solid development methods, but that it was not the future that our community wants to see happening. Because of lack of excitement. Because of lack of vision. Slowly, a plan started to emerge. It evolved, changed, was trimmed a bit, made more solid. We started discussing with a few more people, got more feedback. And then, at GUADEC, the Release Team proposed an initial plan to the community that would lead the project to GNOME 3.0. Quite some time passed; actually, too much time passed because too many people were busy with other things. But it's never too late to do the right thing, so let's really be serious about GNOME 3.0 now! Let's first diverge a bit and discuss the general impression that GNOME is lacking a vision. If you look closely at our community, it'd be wrong to say that people are lacking a vision; but the project as a whole does indeed have this issue. What we are missing is people blessing one specific vision and making it official, giving goals to the community so we can all work together in the same direction. In the pre-2.x days, the community accepted as a whole one specific vision, and such an explicit blessing wasn't needed. But during the 2.x cycle, with our six months schedules, it appeared that everything (community, development process, etc.) was just working very well, and as the vision got more and more fulfilled, the long-term plans became less important as we focused on polishing our desktop. But we've now reached a point where our next steps should be moving to another level, and those next steps require important decisions. This is part of what the Release Team should do. Please note that Release Team members don't have to be the ones who have the vision; we just have to be the voice of the community. (As a sidenote, the roadmap process [1] that we tried to re-establish two years ago was a first attempt to fix this. Unfortunately, it turned out that we were missing the most important side of things: a project-wide roadmap. This is because a collection of individual roadmaps isn't enough to create a project-wide roadmap.) So let's go to the core topic and discuss what the GNOME 3.0 effort should be. We propose the following list of areas to focus our efforts on: - Revamp our User Experience - Streamlining of the Platform - Promotion of GNOME There are also other potential areas that are worth exploring if there is enough interest from the community. From a release management perspective, there are various questions that are raised in the GNOME 3.0 context. We definitely need a plan to organize the development (see below for details on it), but we might also want to take this opportunity to rethink how we ship GNOME: are the module sets still the best way to deliver GNOME? There is no obvious answer to this, but the way we will present GNOME in the future will certainly have an impact on this. Revamp our User Experience When talking with some great people at GUADEC about GNOME 3.0, one concern that came more than once was that it would be an error to do GNOME 3.0 without any big user-visible change. While some of us didn't necessarily agree with this concern, it was still a fairly valid one. But it turns out that if you tell the community that there's something after 2.x, then the community will stop vaguely thinking about future ideas and start working on concrete plans. It seems
Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.
On Thu, Apr 2, 2009 at 10:57 AM, Adam Schreiber sa...@clemson.edu wrote: On Thu, Apr 2, 2009 at 7:20 AM, Andre Klapper ak...@gmx.net wrote: a draft for the GNOME 2.27 2.29 schedule is now available at http://live.gnome.org/TwoPointTwentyseven . The libglade/GtkBuilder transition is on the plan to begin at the end of this month. Currently the transition documentation is pretty pitiful. Has someone volunteered to update it/flesh it out between now and then? I was refering to [1] linked from [2]. Cheers, Adam [1] http://library.gnome.org/devel/gtk/stable/gtk-migrating-GtkBuilder.html [2] http://live.gnome.org/GnomeGoals/RemoveLibGladeUseGtkBuilder ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.
On Thu, Apr 2, 2009 at 11:48 AM, Adam Schreiber sa...@clemson.edu wrote: On Thu, Apr 2, 2009 at 10:57 AM, Adam Schreiber sa...@clemson.edu wrote: On Thu, Apr 2, 2009 at 7:20 AM, Andre Klapper ak...@gmx.net wrote: a draft for the GNOME 2.27 2.29 schedule is now available at http://live.gnome.org/TwoPointTwentyseven . The libglade/GtkBuilder transition is on the plan to begin at the end of this month. Currently the transition documentation is pretty pitiful. Has someone volunteered to update it/flesh it out between now and then? I was refering to [1] linked from [2]. It would be really helpful for this to get some feedback from people who have already done a conversion to GtkBuilder. What were the gotchas ? What are the tricks that one needs to know ? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.
Hi! I add another question here, as a complete dconf/GConf newbie: is depending on Bonobo/Corba vs DBus the only thing that makes GConf not useful towards GNOME 3.0 or are there some other design/preformance/whatever issues requiring a full rewrite to be solved? Performance (especially on Desktop login, see some blog posts by Micheal Meeks). And the code base is rather old and wasn't really maintained for some time now which could make a bad base for hacking. It is also not very tied to Glib/GObject (GValue vs. GConfValue, etc.). But after Ryan's mail I guess the discussion could become obsolete. Having someone working on dconf full-time is certainly better than having noone working on gconf. Regards, Johannes 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: dconf
Hi, On Thu, Apr 2, 2009 at 11:37 AM, Ryan Lortie de...@desrt.ca wrote: first: GVariant. For those of us who are ignorant, like me: what is GVariant, how does it relate to GValue, will it deprecate GValue and if so, why is it not possible to just fix GValue instead? It's not in your email which I am responding to, and it's not in the email which announces the existence of GVariant either. (The answer might be long and inappropriate for this mailinglist, so how about a blog post instead?) Thanks for your work, Ronald ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dconf
Ross Burton wrote: Is a GConf compatibility layer possible, or are there too many semantic differences? The type system of dbus (and therefore GVariant and dconf) is a superset of the type system of GConf -- any value that can be stored in GConf can be stored in dconf. Due to the simple nature of GConfValue, making this bridge would be trivial. The namespace is also essentially the same: a hierarchy of keys with no particular restrictions. It would be very easy to use dconf with the GConf API with a very thin client-side compatibility layer. One thing that dconf is missing that GConf gives you, however, is schemas. You could get this by using dconf as a backend from the gconf daemon. It seems like this is sort of missing the point, though. It might be possible to come up with a temporary hack to deal with schemas. Something like having the compatibility layer insert responses from the schema files where appropriate and dealing with dynamic application-installed schema entries (think: panel) with extra keys in the dconf database. Like if you add a schema for some foo key maybe you could get a .foo.schema extra entry that contains all of the information required... This is honestly a problem space that I haven't spent too much time exploring, but there are certainly possibilities here. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.
Am Donnerstag, den 02.04.2009, 16:56 + schrieb Stef Walter: Matthias Clasen wrote: It would be really helpful for this to get some feedback from people who have already done a conversion to GtkBuilder. What were the gotchas ? What are the tricks that one needs to know ? I've worked with GtkBuilder some in gnome-keyring. So far the big gotcha have been the lack of support in glade for saving in the builder format directly. Maybe this has been fixed by now, haven't checked. This should be fixed by http://bugzilla.gnome.org/show_bug.cgi?id=490678 andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dconf
I think dconf is a great project, but I do have one question. Will the new dconf address the sorts of D-Bus problems raised in these GConf bugs? http://bugzilla.gnome.org/show_bug.cgi?id=555745 http://bugs.freedesktop.org/show_bug.cgi?id=17970 Thanks, Brian On 04/02/09 10:37, Ryan Lortie wrote: Hello, d-d-l. I'm a long-time listener, first time caller. Many of you are probably aware of two things about me: 0) I'm that guy who is working on that weird cloud of dbus-ish stuff involving GVariant and dconf and GSettings, etc. 1) A few months ago I started working for Codethink This email is a statement of status, of direction and of intention. A lot of people have been asking what is going on, so this is an update. It's not really an attempt to start a discussion, but if that happens, then I'm happy to answer any questions. :) first: GVariant. GVariant has been in an essentially-complete state for quite a long time now. I recently rolled a tarball of it and announced it to the announcement list. It is available here: http://www.gnome.org/~ryanl/src/ GVariant is currently hosted as a totally separate project in a git repository on git.desrt.ca: https://desrt.ca/gitweb/?p=gvariant The intention is that it be merged with glib (into the base libglib library). Now that glib is in git I will be making a branch and performing the merge. This should be complete within a couple of days. I will then propose it for inclusion in the next release of glib. GVariant is reasonably well-tested and is being used in a number of other projects that I'm working on. Of course, it surely has some bugs hiding in it. I believe that the API is more or less stable at this point, but I welcome constructive criticism and feedback. There are plans to add more functionality (such as the ability to print/parse pythonic text strings). You can read more details about how GVariant works in the release announcement here: http://mail.gnome.org/archives/gnome-announce-list/2009-March/msg00103.html second: dconf and GSettings For some time I've been talking about these pair of projects as a proposed replacement for GConf. The reasons that we might want to replace GConf are well understood and widely documented and I won't talk about them here. A while ago there was even a reasonably-working implementation of dconf. This was based on a different value system (ie: before I started writing the more-generally-useful GVariant). I stopped working on dconf when I shifted focus to GVariant and when school started consuming a lot of my time. Recently, sponsored by Codethink (now my employer), I have resumed work on dconf. This has come in the form of a total rewrite (and simplification) based on GVariant. This rewrite (along with another project, GBus) is doing a lot to convince me of the stability and usability of GVariant. Briefly, dconf is a simple untyped hierarchy of keys. It is used as the backend storage for GSettings which is a very strictly typed high-level settings system intended to be used by GNOME applications. The API is much nicer than GConf. dconf is very efficient. The majority case in accessing settings is reading (think about desktop login: 1000s of settings read, none written). Reading in dconf is done directly from a memory-mapped file containing the settings in an efficient tree format and doesn't require an extra service to be running. The service is only needed for writes. Communication occurs over DBus, of course. :) The rewrite of dconf is currently extremely unstable and incomplete, but it is currently being hacked on (along with GSettings) full-time. Progress is good. In a week or two I will have something to show for this and I intend to have a stable release to go along with 2.28. Stay tuned. :) Ideally, I'd like to see GNOME using GSettings for 3.0. Rob Taylor (my boss) has indicated that I will definitely be able to spend time addressing issues that may arise with dconf and GSettings in the lead-up to 3.0. So that's it. That's what I'm up to. Have a good day :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dconf
Ryan: I was not familiar with these bugs. I'm glad to bring them to your attention, then, since I think it relates to the work in dconf. One thing is definitely true: for reading from the configuration settings, these bugs will not be an issue because you don't need to use the bus or launch the service at all for this to work. For writing, it's really hard to say. This seems like a wider DBus issue affecting all things that use it. Depending on how those bugs are resolved upstream, the result will be different for dconf. It seems, in general, we need to have a better-defined idea of what a session is. I assume the reason that these bugs bother you is because GConf used to work properly under 'su' when it was straight-up CORBA? Many people have complained to me about the fact that the configuration management can't start unless D-Bus is running. People don't understand the need to run dbus-launch when they just want to run some program which uses GConf or dconf. It makes it awkward to run programs outside of normal D-Bus enabled user sessions. The fact that this causes problems with su is just an example of a wider problem and probably the most annoying aspect of the bug to normal users. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dconf
Brian Cameron wrote: Ryan: I was not familiar with these bugs. I'm glad to bring them to your attention, then, since I think it relates to the work in dconf. One thing is definitely true: for reading from the configuration settings, these bugs will not be an issue because you don't need to use the bus or launch the service at all for this to work. For writing, it's really hard to say. This seems like a wider DBus issue affecting all things that use it. Depending on how those bugs are resolved upstream, the result will be different for dconf. It seems, in general, we need to have a better-defined idea of what a session is. I assume the reason that these bugs bother you is because GConf used to work properly under 'su' when it was straight-up CORBA? Many people have complained to me about the fact that the configuration management can't start unless D-Bus is running. People don't understand the need to run dbus-launch when they just want to run some program which uses GConf or dconf. It makes it awkward to run programs outside of normal D-Bus enabled user sessions. My question would be is why do these People have a desktop in which there isn't a DBus session bus? Its been there for a very long time now in most distros, afact. For gnome 3.0, running without a session bus is going to be like running gnome 2.0 without orbit2. i.e. it ain't gonna work right. The fact that this causes problems with su is just an example of a wider problem and probably the most annoying aspect of the bug to normal users. Actually, no, the su problem is completely orthogonal, this is something that needs addressing in DBus itself and is fixable. Thanks, Rob Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Rob Taylor, Codethink Ltd. - http://codethink.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dconf
Rob: My question would be is why do these People have a desktop in which there isn't a DBus session bus? Its been there for a very long time now in most distros, afact. For gnome 3.0, running without a session bus is going to be like running gnome 2.0 without orbit2. i.e. it ain't gonna work right. I monitor opensolaris user list discussions, and it does cause some confusion and problems for users when they are working in certain setups. As an example, I remember one user who was setting up a multi-user kiosk environment, and only wanted the browser and a few other applications launched with particular geometries. They had some trouble figuring out they needed to use dbus-launch to run one of the programs that was GConf based. It isn't the worst bug in the world, and the workaround is usually not bad. I just wanted to find out if there were any plans to make dconf autostart itself and the services it needs more nicely than what we have today. However, if you want to discuss this bug more, lets discuss it in the bug report rather than clutter this discussion further. The fact that this causes problems with su is just an example of a wider problem and probably the most annoying aspect of the bug to normal users. Actually, no, the su problem is completely orthogonal, this is something that needs addressing in DBus itself and is fixable. Yes, they are two different bug reports. Just something I wanted to highlight to people's attention. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dconf
On 04/02/2009 02:39 PM, Rob Taylor wrote: My question would be is why do these People have a desktop in which there isn't a DBus session bus? The case were people in corporate Microdows environment have to manage a Linux box, and have to run UI application to the X11 server on the Windows PC they use to do that. In that case you don't have a session. FWIW, my Debian server does not have dbus running. I never use any X program from it, but I wonder how it would behave in that situation. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dconf
Le jeudi 02 avril 2009 à 19:39 +0100, Rob Taylor a écrit : My question would be is why do these People have a desktop in which there isn't a DBus session bus? Its been there for a very long time now in most distros, afact. For gnome 3.0, running without a session bus is going to be like running gnome 2.0 without orbit2. i.e. it ain't gonna work right. How about running application remotely through ssh -Y ? I do it daily, and I really hate when it feils because of dbus (but I must confess lately things got better, like if apps autostart dbus or something). Xav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dconf
On Thu, Apr 2, 2009 at 4:47 PM, Xavier Bestel xavier.bes...@free.fr wrote: Le jeudi 02 avril 2009 à 19:39 +0100, Rob Taylor a écrit : My question would be is why do these People have a desktop in which there isn't a DBus session bus? Its been there for a very long time now in most distros, afact. For gnome 3.0, running without a session bus is going to be like running gnome 2.0 without orbit2. i.e. it ain't gonna work right. How about running application remotely through ssh -Y ? I do it daily, and I really hate when it feils because of dbus (but I must confess lately things got better, like if apps autostart dbus or something). (sorry to divert to a slightly different topic, but since we're all on the gnome-3.0 wagon today...) On a similar note, how will gtk's client-side windows affect performance of remote X windows, if at all? Does anyone have any thoughts or prediction on that? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dconf
Can current gconf settings be easily loaded into dconf? e.g. can someone launching into a gnome 3.0, dconf-based, system for the first time still have the same wallpaper settings as they did before? I'm assuming that a) the settings still make sense and b) that the application can provide a mapping between old and new settings. Gnome 3.0 is of course an invitation to break everything, but I'm wondering if its possible to not break absolutely everything from the users perspective? - Callum ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.
On 4/2/09, Stef Walter stef-l...@memberwebs.com wrote: Matthias Clasen wrote: It would be really helpful for this to get some feedback from people who have already done a conversion to GtkBuilder. What were the gotchas ? What are the tricks that one needs to know ? I've worked with GtkBuilder some in gnome-keyring. So far the big gotcha have been the lack of support in glade for saving in the builder format directly. Maybe this has been fixed by now, haven't checked. It does now, at least in a quick trip to migration land in gnome-panel[0] I was able to load the .glade files and save them in .ui (well, GtkBuilder) format. Simple, and the new Project Preferences even allowed me to select the target GTK+ version. Great work, Glade team :-) 0 - http://bugzilla.gnome.org/show_bug.cgi?id=474080 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-keyring branched for GNOME 2.26
Stable releases will be made from branches/gnome-2-26. Development will happen on trunk. Cheers, Stef Walter ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Regression: How to get gnome-keyring-daemon to run before gvfsd in the session
I need the help of a Desktop session genius (is there a gnome-session mailing list?). - gvfs has an SSH module which uses OpenSSH. - OpenSSH checks for the presence of the SSH_AUTH_SOCK environment variable in order to integrate with SSH agents. - gnome-keyring-daemon is started from by /etc/xdg/autostart - gnome-keyring-daemon sets the SSH_AUTH_SOCK environment variable. - gvfsd is auto started by DBus. The end result of the above is that the SSH_AUTH_SOCK environment variable is not set in gvfsd. This has regressed [1] in GNOME 2.26.0 however this may be a race condition or heisenbug. I've received a suggestion to use 'UpdateActivationEnvironment'. Where is this mythical creature implemented and/or documented? Any interesting [2] ideas or suggestions on how to fix this? Are strange hacks inevitable because gnome-keyring deals with stuff like OpenSSH and GnuPG? Cheers, Stef [1] http://bugzilla.gnome.org/show_bug.cgi?id=577614 [2] Suggesting that OpenSSH should use DBus is not interesting, unless it comes with a plan of how to accomplish it. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Regression: How to get gnome-keyring-daemon to run before gvfsd in the session
On Fri, Apr 3, 2009 at 12:20 AM, Stef Walter stef-l...@memberwebs.com wrote: I've received a suggestion to use 'UpdateActivationEnvironment'. Where is this mythical creature implemented and/or documented? It is part of the org.freedesktop.DBus interface since dbus 1.2.3. You can see it in action here: http://svn.gnome.org/viewvc/gnome-session/trunk/gnome-session/gsm-util.c?revision=5355view=markup#l433 gnome-sessions org.gnome.SessionManager interface has its own Setenv method which has the same effect and might be more natural to use. It is documented here: http://svn.gnome.org/viewvc/gnome-session/trunk/gnome-session/org.gnome.SessionManager.xml?view=markup ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
