Re: Holes in GNOME 3 process
On Wed, Dec 01, 2010 at 05:21:48PM +0100, Piñeiro wrote: > In the same way, when this RHEL5 build-slave was running, it was not > clear who should review the builds. I randomly checked that, but > pragmatically was not the best, as I can't install new packages on > that machine (ie [1], I just modify the slave and master > configuration). Just ping #sysadmin. > Sometimes I feel that the review of the builds on the machine provided > by GNOME should be reviewed by GNOME sysadmin, but not sure > anyway. > > Olav, any opinion of my attempt of assigning two tasks to sys-admin > group? Not many in the sysadmin group are developers. Packages can be installed, etc, but we need to be notified. The build machine should be updated to RHEL6 now that it is out. This will allow the use of cgroups. Latter will allow to cleanup all the processes after a build cleanly. Anyway, I want all machines to be on RHEL6 and I'll try to focus on that once I am back from vacation. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity towards GNOME 3.0
On Wed, Dec 01, 2010 at 04:29:56PM -0500, Owen Taylor wrote: > Port to GSettings [..] > So our options here are: > > - Leave everything in Metacity, keep requiring Metacity as a dependency >of Mutter. This isn't really a problem for GNOME 3.0, but we'd >like to drop this dependency eventually and the migration to >GSettings is a natural time to move things around. > > - Have a separate module like gnome-wm-data with the GSettings schemas, >XML files and keys. > > - Move the GSettings schemas and the closely linked keybinding XML >to gsettings-desktop-schemas and do something else for the theme >for Mutter. We could just switch Mutter to depend on >gnome-themes-standard and default to Adwaita. - Make Metacity depend on mutter? In a GNOME 3 world, Metacity is the fallback, so it could depend on Mutter (need to call it 3.0 anyway with gtk3 port). Perhaps a bit weird. > I'm most in favor of the third option though there is some issue with With 3rd option I wonder what gsettings-desktop-schemas should be 'desktop' as in GNOME or not. E.g. called desktop, but what about XFCE. Anyway if you think my proposed option is ugly, then I'm in favour of #3. > Port to GTK+ 3.0 > > - We could just make it require GTK+ 3.0. This is my suggestion - >GNOME 3 is a GTK+ 3.0-based desktop. Metacity is the GNOME >(fallback) window manager. GTK+ 3.0 will be released as a >stable toolkit before Metacity 3.0 is released. If people need >to Metacity build against older GTK+, the older tarballs aren't >going to be removed from the website. +1 -- Regards, Olav (on vacation) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity towards GNOME 3.0
On Wed, 2010-12-01 at 16:29 -0500, Owen Taylor wrote: > Metacity is an important component of GNOME 3 as the window manager in > fallback mode. There's a couple of major things that need doing to make > it work in the GNOME 3 stack that I wanted to bring up here. Both of > them already have patches but we need to figure out exactly we want > to do. > > Port to GSettings > = > https://bugzilla.gnome.org/show_bug.cgi?id=621204 > > Mutter and Metacity share most of their configuration keys and these > keys are also accessed by gnome-control-center and > gnome-settings-daemon. > > In order to meaningfully make GNOME 3 a GSettings-based desktop; > something that can be managed in one place through one system, we need > to migrate these keys over to GSettings. > > The main question in my mind is where they live. Right now, Mutter > requires Metacity. > > - For the GConf schemas > - For: > gnome-control-center/keybindings/50-metacity-desktop-key.xml > gnome-control-center/keybindings/50-metacity-key.xml > - For the default theme Atlanta > > So our options here are: > > - Leave everything in Metacity, keep requiring Metacity as a dependency >of Mutter. This isn't really a problem for GNOME 3.0, but we'd >like to drop this dependency eventually and the migration to >GSettings is a natural time to move things around. > > - Have a separate module like gnome-wm-data with the GSettings schemas, >XML files and keys. > > - Move the GSettings schemas and the closely linked keybinding XML >to gsettings-desktop-schemas and do something else for the theme >for Mutter. We could just switch Mutter to depend on >gnome-themes-standard and default to Adwaita. > I'm most in favor of the third option though there is some issue with > either the second or third option in terms of the way key bindings work > in Metacity the Metacity GConf schema has the keys for key bindings > generated and inserted via a program working from the same header files > that are used in the code. > We have been moving all desktop-wide settings to gsettings-desktop-schemas, so I guess it makes sense to have them there, under org.gnome.window-manager (or something similar), and just have metacity and mutter depend on it ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity towards GNOME 3.0
On Thu, Dec 2, 2010 at 5:29 AM, Owen Taylor wrote: > Metacity is an important component of GNOME 3 as the window manager in > fallback mode. There's a couple of major things that need doing to make > it work in the GNOME 3 stack that I wanted to bring up here. Both of > them already have patches but we need to figure out exactly we want > to do. > > > Port to GTK+ 3.0 > > https://bugzilla.gnome.org/show_bug.cgi?id=622285 > > GNOME 3 is supposed to be built with GTK+-3.0. Metacity currently can > only built with GTK+ 2.0. > > Couple of choices here: > > - We could leave it building with GTK+ 2 and ship both toolkits in > GNOME 3 (we might have to do that anyways; practically speaking > any OS shipping GNOME 3.0 will be including GTK+ 2 as well.) > > - We could support dual building. This is tricky, but there exist > patches developed for Mutter to do this that could be ported > over. (Benjamin Otte spent quite a bit of time working on this, > and then a week or so after the changes landed, we realized there was > nobody still building Mutter against GTK+ 2, so it was pointless > to carry the complexity.) > > - We could just make it require GTK+ 3.0. This is my suggestion - > GNOME 3 is a GTK+ 3.0-based desktop. Metacity is the GNOME > (fallback) window manager. GTK+ 3.0 will be released as a > stable toolkit before Metacity 3.0 is released. If people need > to Metacity build against older GTK+, the older tarballs aren't > going to be removed from the website. > > If someone wants to use Metacity 3.0 in a legacy environment - > on an older operating system - the GSettings requirement, which we > can't get away from, would be a big problem. > Hi Owen, Does this mean that libmetacity-private will also depend on GTK+ 3.0 ? Compiz currently uses this library to handle frame drawing from metacity themes and I need to know whether I need to update the deps there. Cheers, Sam > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- Sam Spilsbury ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity towards GNOME 3.0
On Wed, 2010-12-01 at 16:29 -0500, Owen Taylor wrote: > - We could just make it require GTK+ 3.0. This is my suggestion - >GNOME 3 is a GTK+ 3.0-based desktop. Metacity is the GNOME >(fallback) window manager. GTK+ 3.0 will be released as a >stable toolkit before Metacity 3.0 is released. If people need >to Metacity build against older GTK+, the older tarballs aren't >going to be removed from the website. +1 from me as well. There's another thing which came up on IRC - the theme format has been extended in mutter, and it may be nice to port these changes to Metacity as well. It would allow the fallback environment to use the new GNOME 3 default theme without the art people having to support two versions (the theme format is ... not very nice). Porting the changes should be pretty straight-forward, though the change to version 3.2 raises another question - it adds a new frame type for attached dialogs, which is a Mutter-only feature. It is optional, so we could just #define meta_prefs_get_attach_modal_dialogs() FALSE and only port the theme change, rather than porting the feature itself. Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity towards GNOME 3.0
On 2 December 2010 09:13, Rodrigo Moya wrote: > We have been moving all desktop-wide settings to > gsettings-desktop-schemas, so I guess it makes sense to have them there, > under org.gnome.window-manager (or something similar), and just have > metacity and mutter depend on it Yes, this is what I've done in gnome-power-manager, gnome-settings-daemon and the control center, as they share keys. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: UI Mockup for Gnome 3.XX "Share" section of System Settings
Hi Sebastien! On 12/01/2010 12:33 PM, Gendre Sebastien wrote: I don't know if it's good, but I have make a UI mockup for the Share section of System Settings for Gnome 3.XX. It's just a first idea and it probably need more work. Link to mockup: https://bugzilla.gnome.org/show_bug.cgi?id=636206 Link to "System Settings" design wiki for Gnome 3.XX: http://live.gnome.org/Design/SystemSettings What do you think? I'm no UX expert, and I'd really like to get the take of an Allan Day, mpt, the Calums or Andreas on the details, but I do have some comments on the mock-up (which are similar to some of the comments Wouter had in Bugzilla): I *really* like that sharing files & browsing other people's file shares is just integrated into Nautilus - that's where it should be, for the most part, and not in system settings. I also like that the interface for sharing is right click->Share this folder, and the interface for finding other shares on the intranet is "Network places" in Nautilus. SMB is a de facto standard now. For anything which (a) requires manual sharing because it's a non-default protocol or (b) requires manual mounting, it also seems like Nautilus is the best place for this to happen. I'm not sure exactly what a good interface for creating a CIFS or NFS share might be, but I think the interface for SparkleShare, Ubuntu One or Dropbox is pretty good for cloud storage (that is, a special folder where we share things, with an online interface for handling ACLs for contacts) Once you take that away, the system file sharing sessions come down to: "Allow users to share folders" and "Allow users to view other people's shares" (as security options, presumably) - and I would argue that both of those are unnecessary & should be yes by default. I do like your idea of having conditional sharing enabled, but I am not sure what the UI should look like (how do you define "Home", for example? I know how it might be implemented (wifi ESSID, I guess) but how would you expose that to the user?). Then there's bluetooth file sharing, which I don't see in your mock-up. And this is an opportunity, I think, to do better than everyone else - I have yet to see a nice UI for transfering files over Bluetooth (Mac OS X comes closest). For DAAP, I'd expect that to be in the music player. Although there's an argument for all music players to share the settings... I would expect the "share this printer" option to be in printer configuration, not sharing configuration. As Wouter said, Zeroconf really isn't something to expose to the user - a checkbox along the lines of "Automatically search for shares on the local network" covers the only option you'll need for that. It should be possible to turn off, and should be on by default. I don't think there's much else to say about that. (I'm copying the comments to Bugzilla, but since you started this discussion here...) Cheers, Dave. -- Dave Neary GNOME Foundation member dne...@gnome.org Jabber: nea...@gmail.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity towards GNOME 3.0
On Thu, 2010-12-02 at 17:23 +0800, Sam Spilsbury wrote: > > - We could just make it require GTK+ 3.0. This is my suggestion - > > GNOME 3 is a GTK+ 3.0-based desktop. Metacity is the GNOME > > (fallback) window manager. GTK+ 3.0 will be released as a > > stable toolkit before Metacity 3.0 is released. If people need > > to Metacity build against older GTK+, the older tarballs aren't > > going to be removed from the website. > > > > If someone wants to use Metacity 3.0 in a legacy environment - > > on an older operating system - the GSettings requirement, which we > > can't get away from, would be a big problem. > > > > Hi Owen, > > Does this mean that libmetacity-private will also depend on GTK+ 3.0 ? > Compiz currently uses this library to handle frame drawing from > metacity themes and I need to know whether I need to update the deps > there. Yes, that would be a consequence. (If we made it dual build then you'd have to handle both which would be no fun at all.) - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity towards GNOME 3.0
On 02/12/10 17:54, Owen Taylor wrote: On Thu, 2010-12-02 at 17:23 +0800, Sam Spilsbury wrote: - We could just make it require GTK+ 3.0. This is my suggestion - GNOME 3 is a GTK+ 3.0-based desktop. Metacity is the GNOME (fallback) window manager. GTK+ 3.0 will be released as a stable toolkit before Metacity 3.0 is released. If people need to Metacity build against older GTK+, the older tarballs aren't going to be removed from the website. If someone wants to use Metacity 3.0 in a legacy environment - on an older operating system - the GSettings requirement, which we can't get away from, would be a big problem. Hi Owen, Does this mean that libmetacity-private will also depend on GTK+ 3.0 ? Compiz currently uses this library to handle frame drawing from metacity themes and I need to know whether I need to update the deps there. Yes, that would be a consequence. (If we made it dual build then you'd have to handle both which would be no fun at all.) When switching to gtk+3, since the SONAME will need to change, maybe you could rename the library to libmetacity, since it doesn't seem to be private at all... :) Regards, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity towards GNOME 3.0
On 02/12/10 17:54, Owen Taylor wrote: Does this mean that libmetacity-private will also depend on GTK+ 3.0 ? Compiz currently uses this library to handle frame drawing from metacity themes and I need to know whether I need to update the deps there. Yes, that would be a consequence. (If we made it dual build then you'd have to handle both which would be no fun at all.) When switching to gtk+3, since the SONAME will need to change, maybe you could rename the library to libmetacity, since it doesn't seem to be private at all... :) Regards, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity towards GNOME 3.0
On 1 December 2010 21:29, Owen Taylor wrote: > Metacity is an important component of GNOME 3 as the window manager in > fallback mode. There's a couple of major things that need doing to make > it work in the GNOME 3 stack that I wanted to bring up here. Both of > them already have patches but we need to figure out exactly we want > to do. > Port to GTK+ 3.0 > > https://bugzilla.gnome.org/show_bug.cgi?id=622285 > > - We could support dual building. This is tricky, but there exist > patches developed for Mutter to do this that could be ported > over. (Benjamin Otte spent quite a bit of time working on this, > and then a week or so after the changes landed, we realized there was > nobody still building Mutter against GTK+ 2, so it was pointless > to carry the complexity.) There are various MeeGo projects at Intel where mutter is serious player; we'd like to move away from our "fork" to the GNOME version so Benjamin's work is certainly appreciated since despite trying hard I don't think we'll get GTK3 into the distribution in time for 1.2 (release date scheduled for April.) Cheerio, Rob ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity towards GNOME 3.0
On Thu, 2010-12-02 at 19:04 +, Rob Bradford wrote: > On 1 December 2010 21:29, Owen Taylor wrote: > > Metacity is an important component of GNOME 3 as the window manager in > > fallback mode. There's a couple of major things that need doing to make > > it work in the GNOME 3 stack that I wanted to bring up here. Both of > > them already have patches but we need to figure out exactly we want > > to do. > > > Port to GTK+ 3.0 > > > > https://bugzilla.gnome.org/show_bug.cgi?id=622285 > > > > > - We could support dual building. This is tricky, but there exist > > patches developed for Mutter to do this that could be ported > > over. (Benjamin Otte spent quite a bit of time working on this, > > and then a week or so after the changes landed, we realized there was > > nobody still building Mutter against GTK+ 2, so it was pointless > > to carry the complexity.) > > There are various MeeGo projects at Intel where mutter is serious > player; we'd like to move away from our "fork" to the GNOME version so > Benjamin's work is certainly appreciated since despite trying hard I > don't think we'll get GTK3 into the distribution in time for 1.2 > (release date scheduled for April.) Mutter was already switched over to be GTK+ 3.0-only a while ago (after consultation with you guys.) If there was a strong need, we could revert that out but it would be far from the first choice. GTK+ 3.0 will be out long before April, so I don't think there is a problem with shipping it in something released in April. Obviously, porting everything over to GTK+ 3.0 would be a different issue. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Holes in GNOME 3 process
On Tue, Nov 30, 2010 at 4:26 PM, Owen Taylor wrote: > So, we have a nice schedule for GNOME 3 at: > > http://live.gnome.org/TwoPointNinetyone/ > > That's not in itself going to get us to a good solid GNOME 3. There > seems to a lot more stuff that needs doing on the coordination side, and > if it's happening, it's not being very well advertised, because I > couldn't find any evidence of it looking around. A few things that jump > to mind listed below. To repeat what I said in my blog post earlier: I think we should get together with interested parties and make some concrete plans to ensure a smooth landing for GNOME 3. My proposal is: Tuesday December 7, 14:00EST / 19:00 UTC in #release-team on GimpNet To discuss questions like • What are the gaps that we have to fill for 3.0 • How do we track blockers • How do we monitor and avoid build breakages • How do we get things tested daily Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
More GTK breakage
Hey everyone, If you read this mail, it's probably because GTK made your compile fail. Again. It might be because the final part of the GTK3 rendering cleanup has landed. This part only touches GDK APIs, so most applications should not be affected at all. If your app has been affected nonetheless, it's often one of these issues: - GdkDrawable has been removed. In that case, just replace all occurences of GdkDrawable with GdkWindow and you should be fine. - The GDK_DRAWABLE() macro is gone. Oftentimes, it can just be omitted. Otherwise, you likely want to use the GDK_WINDOW() macro. - GDK_WINDOW_XWINDOW() is gone. Use the gdk_x11_window_get_xid() to get it. I'm transitioning all code to provide a gdk_x11_foo_get_xid() function exclusively, so futureproof code should use that function. - A few remaining calls (mostly in gdkx.h) that were called gdk_drawable_foo() are now called gdk_window_foo(). Most prominently gdk_x11_drawable_get_xid() is now called gdk_x11_window_get_xid(). As always, if you have any issues, feel free to poke me. Benjamin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: More GTK breakage
On Thu, 2010-12-02 at 20:45 +0100, Benjamin Otte wrote: > Hey everyone, > > If you read this mail, it's probably because GTK made your compile > fail. Again. It might be because the final part of the GTK3 rendering > cleanup has landed. This part only touches GDK APIs, so most > applications should not be affected at all. > > If your app has been affected nonetheless, it's often one of these issues: > > - GdkDrawable has been removed. In that case, just replace all > occurences of GdkDrawable with GdkWindow and you should be fine. > > - The GDK_DRAWABLE() macro is gone. Oftentimes, it can just be > omitted. Otherwise, you likely want to use the GDK_WINDOW() macro. > > - GDK_WINDOW_XWINDOW() is gone. Use the gdk_x11_window_get_xid() to > get it. I'm transitioning all code to provide a gdk_x11_foo_get_xid() > function exclusively, so futureproof code should use that function. > > - A few remaining calls (mostly in gdkx.h) that were called > gdk_drawable_foo() are now called gdk_window_foo(). Most prominently > gdk_x11_drawable_get_xid() is now called gdk_x11_window_get_xid(). > > As always, if you have any issues, feel free to poke me. > > Benjamin Just a small nitpick - while reading I spotted that gdk_x11_window_get_xid() should return XID, not Window as it is written in gdkx.h, even if Window is just a typedef of XID. Krzesimir ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Holes in GNOME 3 process
Dnia 2010-11-30, wto o godzinie 16:26 -0500, Owen Taylor pisze: > Standard ways to test GNOME 3 as an OS > == > If someone wanted to test their application on GNOME 3 or hack on GNOME > 3, the options are slim: > > - You can jhbuild GNOME 3 on top of something. Figuring >out for yourself: > > - What dependencies you need to install (gnome-shell-build-setup.sh > gets you partially there) > - How to get past the modules that are red on build.gnome.org > - How to log in to the session you built. (There are some hints in > the jhbuild manual, but they aren't sufficient. > > This isn't going to materially change before we get GNOME 3 out, but we > need documented clarity .. _this_ is how you test GNOME 3. Well, a working jhbuild tutorial would be a great thing IMNSHO. Gathering information from search engines is all fine and good, that is if you can find them all at once. I for one, have utterly failed on getting jhbuild to work reasonably, despite giving it a few shots and pestering people on IRC... Regards, -- Łukasz [DeeJay1] Jernaś 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: Metacity towards GNOME 3.0
On 2 December 2010 19:15, Owen Taylor wrote: > On Thu, 2010-12-02 at 19:04 +, Rob Bradford wrote: >> On 1 December 2010 21:29, Owen Taylor wrote: >> > Metacity is an important component of GNOME 3 as the window manager in >> > fallback mode. There's a couple of major things that need doing to make >> > it work in the GNOME 3 stack that I wanted to bring up here. Both of >> > them already have patches but we need to figure out exactly we want >> > to do. >> >> > Port to GTK+ 3.0 >> > >> > https://bugzilla.gnome.org/show_bug.cgi?id=622285 >> > >> >> > - We could support dual building. This is tricky, but there exist >> > patches developed for Mutter to do this that could be ported >> > over. (Benjamin Otte spent quite a bit of time working on this, >> > and then a week or so after the changes landed, we realized there was >> > nobody still building Mutter against GTK+ 2, so it was pointless >> > to carry the complexity.) >> >> There are various MeeGo projects at Intel where mutter is serious >> player; we'd like to move away from our "fork" to the GNOME version so >> Benjamin's work is certainly appreciated since despite trying hard I >> don't think we'll get GTK3 into the distribution in time for 1.2 >> (release date scheduled for April.) > > Mutter was already switched over to be GTK+ 3.0-only a while ago (after > consultation with you guys.) If there was a strong need, we could revert > that out but it would be far from the first choice. > Ah. I was under that impression too ... so I was surprised to see you mention 2+3 support. Cheerio, Rob ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity towards GNOME 3.0
On Thu, 2010-12-02 at 19:04 +, Rob Bradford wrote: > > - We could support dual building. This is tricky, but there exist > > patches developed for Mutter to do this that could be ported > > over. (Benjamin Otte spent quite a bit of time working on this, > > and then a week or so after the changes landed, we realized there was > > nobody still building Mutter against GTK+ 2, so it was pointless > > to carry the complexity.) > > There are various MeeGo projects at Intel where mutter is serious > player; we'd like to move away from our "fork" to the GNOME version so > Benjamin's work is certainly appreciated since despite trying hard I > don't think we'll get GTK3 into the distribution in time for 1.2 > (release date scheduled for April.) gtk+ 3.0 is slated to be released at the end of this month, so there should be time to actually have it in time for MeeGo 1.2; what's most likely not going to make it are the rest of the components of GNOME we do still use on the Netbook UX. I'd rather not have Mutter be complicated and burdened by ifdefs, if that's going to cost the time (and sanity) of the maintainers. ciao, Emmanuele. -- 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
