Planned GNOME Shell UI changes (was Re: String and UI Change Announcement)
On Sun, 2011-01-09 at 23:31 +0100, Vincent Untz wrote: It probably makes sense at least for the shell team and for the people working on the default theme to tell gnome-doc-list how much of the UI can be expected to still change during that period. It'd be a shame to have people starting to take many screenshots if they'll all be outdated a few weeks after. Here's what I'm aware of in the pipeline. I would expect various changes in addition to this, but nothing very major. - Owen Patches in the process of landing = * The default font will be changing to Cantarell and font sizes for the top panel will change. (Should land in the next couple of days.) https://bugzilla.gnome.org/show_bug.cgi?id=634226 * A completely revised calendar popdown. https://bugzilla.gnome.org/show_bug.cgi?id=632109 * The shutdown/logout dialogs will be changing from GTK+ dialogs to shell-themed dialogs https://bugzilla.gnome.org/show_bug.cgi?id=637187 * The way that the dash (left bar in the overview) resizes when there are more thing than fit is getting some improvements and will look prettier. (So for now screenshot it when icons are at the largest size.) Stuff less far along * UI will be added for displaying information about fallback mode and forcing fallback mode when the system seems capable of doing a full composited desktop. (This is my biggest area of concern going into GNOME 3.0 - not having the final design or much code for this.) * A native network indicator applet will be added that works with NetworkManager 0.9 will be landing. (So don't screenshot the current nm-applet which doesn't even have symbolic icons for the panel) ? We may be implementing the workspace mockups from http://jimmac.musichall.cz/log/ - I'd really like to get these in - the current workspace management just isn't very good - but we don't have code started on them so it's a stretch. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planned GNOME Shell UI changes (was Re: String and UI Change Announcement)
Il giorno lun, 10/01/2011 alle 12.33 -0500, Owen Taylor ha scritto: On Sun, 2011-01-09 at 23:31 +0100, Vincent Untz wrote: It probably makes sense at least for the shell team and for the people working on the default theme to tell gnome-doc-list how much of the UI can be expected to still change during that period. It'd be a shame to have people starting to take many screenshots if they'll all be outdated a few weeks after. Here's what I'm aware of in the pipeline. I would expect various changes in addition to this, but nothing very major. - Owen [...] * A native network indicator applet will be added that works with NetworkManager 0.9 will be landing. (So don't screenshot the current nm-applet which doesn't even have symbolic icons for the panel) I'm not sure it will make it in 3.0. I have alpha quality code for that indicator (better than the one I posted half a year ago), but I cannot really test it since it depends on libnm-glib 0.9 with rm-userset, which is incompatible with NetworkManager 0.8.990. You could run the jhbuilt daemon but, ignoring security issues, is not really workable, given that it is not compatible with nm-applet and does not load configs from either GConf or rhcfg-plugin. Also, a lot of features are missing, like asking for a wireless key or creating adhoc connections. (Of course, if someone has another indicator patch, it would be a totally different story) Giovanni ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planned GNOME Shell UI changes (was Re: String and UI Change Announcement)
Le lundi 10 janvier 2011 à 12:33 -0500, Owen Taylor a écrit : * UI will be added for displaying information about fallback mode and forcing fallback mode when the system seems capable of doing a full composited desktop. (This is my biggest area of concern going into GNOME 3.0 - not having the final design or much code for this.) Is it really necessary? wouldn’t it be simpler to let the user choose in GDM, provided the packages necessary for fallback mode are installed? -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planned GNOME Shell UI changes (was Re: String and UI Change Announcement)
On Mon, 2011-01-10 at 19:03 +0100, Josselin Mouette wrote: Le lundi 10 janvier 2011 à 12:33 -0500, Owen Taylor a écrit : * UI will be added for displaying information about fallback mode and forcing fallback mode when the system seems capable of doing a full composited desktop. (This is my biggest area of concern going into GNOME 3.0 - not having the final design or much code for this.) Is it really necessary? wouldn’t it be simpler to let the user choose in GDM, provided the packages necessary for fallback mode are installed? I'd say yes - if the login will not work out-of-box [new] user will say that Linux is not working and switch back to Windows. Unfortunately from user perspective Windows works out of box (read someone have installed it and configured but user haven't seen it) and Linux requires configuration and is hard. Even more advanced user wouldn't want to track what is wrong with setup that broke after update. Regards 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: Planned GNOME Shell UI changes (was Re: String and UI Change Announcement)
It should be simple to enhance GDM to detect when OpenGL is not available, and avoid showing session-types that require it when it cannot be used. A general interface could eventually be implemented to support this, but it might be reasonable to just hardcode this behavior for known sessions that do not work with OpenGL initially for GNOME 3. Brian On 01/10/11 12:17, Maciej Piechotka wrote: On Mon, 2011-01-10 at 19:03 +0100, Josselin Mouette wrote: Le lundi 10 janvier 2011 à 12:33 -0500, Owen Taylor a écrit : * UI will be added for displaying information about fallback mode and forcing fallback mode when the system seems capable of doing a full composited desktop. (This is my biggest area of concern going into GNOME 3.0 - not having the final design or much code for this.) Is it really necessary? wouldn’t it be simpler to let the user choose in GDM, provided the packages necessary for fallback mode are installed? I'd say yes - if the login will not work out-of-box [new] user will say that Linux is not working and switch back to Windows. Unfortunately from user perspective Windows works out of box (read someone have installed it and configured but user haven't seen it) and Linux requires configuration and is hard. Even more advanced user wouldn't want to track what is wrong with setup that broke after update. Regards ___ 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: Planned GNOME Shell UI changes (was Re: String and UI Change Announcement)
On Mon, 2011-01-10 at 18:52 +0100, Giovanni Campagna wrote: * A native network indicator applet will be added that works with NetworkManager 0.9 will be landing. (So don't screenshot the current nm-applet which doesn't even have symbolic icons for the panel) I'm not sure it will make it in 3.0. I have alpha quality code for that indicator (better than the one I posted half a year ago), but I cannot really test it since it depends on libnm-glib 0.9 with rm-userset, which is incompatible with NetworkManager 0.8.990. You could run the jhbuilt daemon but, ignoring security issues, is not really workable, given that it is not compatible with nm-applet and does not load configs from either GConf or rhcfg-plugin. Also, a lot of features are missing, like asking for a wireless key or creating adhoc connections. The way I see it, someone who is using GNOME 3 with NetworkManager 0.8 will certainly have the option of using the old nm-applet icon. This probably is going to be the configuration most people will need to use if they've jhbuilt GNOME 3 on top of an existing distro and don't want to go out of their way to replace the system NetworkManager daemon. But NetworkManager 0.9 has the features we need to properly integrate with our plans for GNOME 3, so that's what anything we implement in the UI should be targeting. I'll let Dan Williams follow up here to describe where that is currently and how it relates to the items you mention above. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planned GNOME Shell UI changes (was Re: String and UI Change Announcement)
On Mon, 2011-01-10 at 13:47 -0500, Owen Taylor wrote: On Mon, 2011-01-10 at 18:52 +0100, Giovanni Campagna wrote: * A native network indicator applet will be added that works with NetworkManager 0.9 will be landing. (So don't screenshot the current nm-applet which doesn't even have symbolic icons for the panel) I'm not sure it will make it in 3.0. I have alpha quality code for that indicator (better than the one I posted half a year ago), but I cannot really test it since it depends on libnm-glib 0.9 with rm-userset, which is incompatible with NetworkManager 0.8.990. You could run the jhbuilt daemon but, ignoring security issues, is not really workable, given that it is not compatible with nm-applet and does not load configs from either GConf or rhcfg-plugin. Also, a lot of features are missing, like asking for a wireless key or creating adhoc connections. The way I see it, someone who is using GNOME 3 with NetworkManager 0.8 will certainly have the option of using the old nm-applet icon. This probably is going to be the configuration most people will need to use if they've jhbuilt GNOME 3 on top of an existing distro and don't want to go out of their way to replace the system NetworkManager daemon. But NetworkManager 0.9 has the features we need to properly integrate with our plans for GNOME 3, so that's what anything we implement in the UI should be targeting. I'll let Dan Williams follow up here to describe where that is currently and how it relates to the items you mention above. I'm finishing up a patch to NM for AddAndActivate, which given an incomplete connection dict (or even just an object path to an AP or WiMAX NSP from the scan list) will fill in all the missing connection details for you, add that connection to backing storage, and then start activating it. That's a huge win for developers since it removes about 50 steps that used to be necessary to connect to an AP. (Well, except for 802.1x and GSM where we need additional information like the EAP details or the APN, but NM would still fill in the rest of the stuff for you). To decrease instability in git master I've kept all the huge NM 0.9 API changes in rm-userset until they are mostly done. The next steps for merging rm-userset to master are: 1) finish writing a bunch of testcases for AddAndActivate 2) complete the network-manager-applet port over to NM 0.9 to show any holes that might be left in the NM 0.9 API 3) add the user-connection import code to the applet to move existing user connections from GConf to system settings 4) merge rm-userset I'm very optimistic that will all happen this week, including your GOI patch for libnm-glib (thanks!). At that point we can also discuss ways to make the libnm-glib API easier to bind for GOI, where I think the usage of dbus-glib types as GObject property types is making things slightly harder. Cheers, Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planned GNOME Shell UI changes (was Re: String and UI Change Announcement)
On Mon, 2011-01-10 at 19:03 +0100, Josselin Mouette wrote: Le lundi 10 janvier 2011 à 12:33 -0500, Owen Taylor a écrit : * UI will be added for displaying information about fallback mode and forcing fallback mode when the system seems capable of doing a full composited desktop. (This is my biggest area of concern going into GNOME 3.0 - not having the final design or much code for this.) Is it really necessary? wouldn’t it be simpler to let the user choose in GDM, provided the packages necessary for fallback mode are installed? There are multiple ways that GDM could be involved here: * We could get GDM involved in figuring out whether we want to run in normal mode or fallback mode. * We could implement normal mode and fallback mode as two separate independent session types. * We could simply use the existing session selector to select between two independent session types. The first two are definitely possible, I'm not sure if they buy a lot compared to doing the selection in gnome-session after we start the login process. The third one - which I understand to be your proposal - I don't think it works. I'd like us to be designing for the set of users for whom that choice simply wouldn't make sense. People should be able to expect that you click on your user, you log in, and the right thing happens. So we need to have logic that automatically chooses what to do (Vincent has already added some of this to gnome-session) and then we need a way for the user to override in the cases that I mentioned. That is the config part of the equation. The other part of the equation displaying information about fallback mode comes into play, if say, I plug a new video card into my system, reboot, and suddenly we no longer support 3D. We can't just throw the user into a quite radically different experience with no explanation. We need some sort of dialog/troubleshooting to say: - Here's what happened - Here's the information about your system you might need to figure out what you need to do to get working drivers. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planned GNOME Shell UI changes (was Re: String and UI Change Announcement)
Le lundi 10 janvier 2011 à 14:00 -0500, Owen Taylor a écrit : On Mon, 2011-01-10 at 19:03 +0100, Josselin Mouette wrote: Is it really necessary? wouldn’t it be simpler to let the user choose in GDM, provided the packages necessary for fallback mode are installed? There are multiple ways that GDM could be involved here: * We could get GDM involved in figuring out whether we want to run in normal mode or fallback mode. * We could implement normal mode and fallback mode as two separate independent session types. * We could simply use the existing session selector to select between two independent session types. The first two are definitely possible, I'm not sure if they buy a lot compared to doing the selection in gnome-session after we start the login process. The third one - which I understand to be your proposal - I don't think it works. I’m not sure I understand the difference between 2 and 3. What I’m proposing is two different .desktop files in /usr/share/xsessions, and possibly GDM being able to select a different default based on the presence of suitable 3D acceleration. I'd like us to be designing for the set of users for whom that choice simply wouldn't make sense. People should be able to expect that you click on your user, you log in, and the right thing happens. So we need to have logic that automatically chooses what to do (Vincent has already added some of this to gnome-session) and then we need a way for the user to override in the cases that I mentioned. Doing this in gnome-session makes 2 places where you can configure which session to run: GDM (to choose between GNOME and other session types if they are installed) and gnome-session itself. I think that’s a bit confusing. The other part of the equation displaying information about fallback mode comes into play, if say, I plug a new video card into my system, reboot, and suddenly we no longer support 3D. We can't just throw the user into a quite radically different experience with no explanation. Certainly. I think there’s a third part of the equation, it’s the saved sessions. If you restore a session saved with GNOME 2 and select the GNOME 3 session, the old applications will start instead. The opposite is the same: even if you start in GNOME 2 mode, if mutter is in the saved applications it will start instead of metacity. Currently, in Debian we tell gnome-session to use a different session saving directory when starting a GNOME 3 session to avoid that. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planned GNOME Shell UI changes (was Re: String and UI Change Announcement)
Le lundi 10 janvier 2011 à 10:29 -0600, Brian Cameron a écrit : It should be simple to enhance GDM to detect when OpenGL is not available, and avoid showing session-types that require it when it cannot be used. A general interface could eventually be implemented to support this, but it might be reasonable to just hardcode this behavior for known sessions that do not work with OpenGL initially for GNOME 3. I can imagine detection being harder, though. Some cards will seem/pretend to work, but won't, either because they are too slow or because Mutter triggers major bugs on them. So it might get much more messy than checking for OpenGL. Maybe a whitelist of supported cards would have to be created, just like it was required for Compiz (at least in Ubuntu). But I'm sure Owen can tell us how this could work... Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planned GNOME Shell UI changes (was Re: String and UI Change Announcement)
On Mon, 2011-01-10 at 12:33 -0500, Owen Taylor wrote: * The default font will be changing to Cantarell Cantarell? If Cantarell is this, http://abattis.org/cantarell/ which says As my very first typeface design... designed for on-screen reading; in particular, reading web pages on an HTC Dream mobile phone ... font file currently contains 391 glyphs then at first glance it seems an odd choice. DejaVu serves us well with outstanding coverage across the Unicode space and one of the only fonts with complimentary Serif, Sans, and Sans Mono families. Do we need to replace it? AfC Sydney 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
