Re: Rules for design in Gnome
On Tue, Apr 24, 2012 at 15:10, Alberto Ruiz wrote: > I would like to take a moment to make a reflection. > > Maintainers only get to decide what's done in their modules back then when > GNOME was organized in a maintainer centric fashion. However with 3.0 we > have moved towards a model where yet another force is included in the > decision making process, that is, the design team. So far they have done a > huge amount of good quality work, GNOME 3.0 wouldn't be what it is without > them and without this approach. > > You don't find many open source communities where a pipeline for design > driven development is implemented, in fact, very few companies implement > this either. I think we should embrace this concept. I think giving ALL the > decision making power to the maintainers is a bad idea, in fact I think it's > harming to do so. I'm afraid that interfering in the maintainer's responsibilities is a very big can of worms, more likely to do harm than good. There's something powerful in how a maintainer feels responsible about his module and the community that surrounds it. Instead, what if maintainers keep having the last word on individual decisions, including those disagreeing with the design team, but have the formal duty of cooperating with the design team? That way, if a module is consistently ignoring the design team and delivering generally-perceived bad UX, the maintainer can be asked to reconsider her stance and maybe eventually replaced by someone else. I believe that maintainer removal may not be needed ever, in the same way that, to my knowledge, no maintainer has been stripped yet from her responsibilities because of not respecting the freezes, reviewing patches, breaking the code of conduct, etc. Regards, Tomeu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
On Wed, Apr 25, 2012 at 20:51, Jason D. Clinton wrote: > > My question to you would be, why didn't agreement ever get reached? Why, > four years later, are we still arguing about desktop activity? I see a > failure of cooperation; not of the design team's but rather of the whole > project's. Wonder if besides improving in-project cooperation, we shouldn't make it easier as well for people with diverging ideas to prove that they are right. I see how it can be a problem for the GNOME brand if individual distros ship too big modifications to the upstream, official GNOME releases, but giving the chance to people to push forward their ideas if they believe in them has also its value. Innovation happens as convergence after divergence, if we stress the first too much, our capacity to innovate slows down. Regards, Tomeu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
On Wed, 2012-04-25 at 21:04 -0400, Shaun McCance wrote: > On Wed, 2012-04-25 at 18:38 -0400, Marina Zhurakhinskaya wrote: > > Hi! > > > > I'd like to propose a new lock screen as a 3.6 feature. The new lock screen > > will > > > > - be styled to have a uniform look and feel as the rest of GNOME Shell > > - be visually consistent with the look of the authentication > > components on the login screen > > - have a limited number of status icons displayed > > - show an indication that there are notifications or show the > > notifications themselves depending on the user’s preferences > > - allow user authentication with a password, pin, fingerprint, or > > smartcard > > > > The designs for the lock screen are available here: > > https://live.gnome.org/GnomeOS/Design/Whiteboards/ScreenLock > > I *love* the idea of showing notifications and allowing control of > media playback. It's something I've wanted for a very, very long > time. > > But I share Bhaavan's concern with having to physically drag the > screen up. It's very cumbersome with a mouse. And aside from being > inconvenient, without keyboard-only use it's not accessible. > > How is the PIN supposed to be set? Will that involve changes to > the User Accounts panel? Adding to Shaun's questions: what's the purpose of the PIN? Is it designed as a replacement for passwords for use with keyboardless devices? Philip > And while we're dealing with User Accounts and passwords, could we > manage to do something about the password hint? You can set it, but > it doesn't do anything useful in any software anywhere. It's kind > of embarrassing to have to write that in the help. > > -- > Shaun > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list 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: 3.6 Feature: Lock Screen
On Wed, 2012-04-25 at 21:04 -0400, Shaun McCance wrote: > On Wed, 2012-04-25 at 18:38 -0400, Marina Zhurakhinskaya wrote: > > Hi! > > > > I'd like to propose a new lock screen as a 3.6 feature. The new lock screen > > will > > > > - be styled to have a uniform look and feel as the rest of GNOME Shell > > - be visually consistent with the look of the authentication > > components on the login screen > > - have a limited number of status icons displayed > > - show an indication that there are notifications or show the > > notifications themselves depending on the user’s preferences > > - allow user authentication with a password, pin, fingerprint, or > > smartcard > > > > The designs for the lock screen are available here: > > https://live.gnome.org/GnomeOS/Design/Whiteboards/ScreenLock > > I *love* the idea of showing notifications and allowing control of > media playback. It's something I've wanted for a very, very long > time. > +1 > But I share Bhaavan's concern with having to physically drag the > screen up. It's very cumbersome with a mouse. And aside from being > inconvenient, without keyboard-only use it's not accessible. > Random thought - maybe the unlock should happen on enter as you can log in on gdm? Also - will the scroll from bottom be used in gdm/gnome-shell? If yes - what about 'normal' desktops, if no - why introduce new 'widget'. PS. Sorry if in second point I sound "threatening". I am just curious and I am sure there is good answer to it I just don't know. > How is the PIN supposed to be set? Will that involve changes to > the User Accounts panel? > Why use PIN at all? (Apparently that is question for Windows 8 as well). Or is it for smartcards? > And while we're dealing with User Accounts and passwords, could we > manage to do something about the password hint? You can set it, but > it doesn't do anything useful in any software anywhere. It's kind > of embarrassing to have to write that in the help. > > -- > Shaun > Best regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tentative feature: Custom activities
Hello Phil, On Wed, 2012-04-25 at 21:54 +0100, Phil Housley wrote: > Hello Gnome, > > (This is a bit long. Summary: Combine good bits of Gnome and Android > application models.) > > I know there has already been a lot of discussion around the new style > of Gnome applications, with the maximised by default windows and all > that, but I want to suggest a different way of thinking about the > issue. I see nowhere in your explanations who the owner of the feature is. It's a requirement to have somebody to develop the proposed features, as noted in Andre's mail: http://mail.gnome.org/archives/devel-announce-list/2012-March/msg5.html Is that developer you? Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
As I understand it, typing the password will switch to the password "dialog", which is about as keyboard/non-touch friendly as it gets :-) Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: IBus/XKB integration
On Wed, Apr 25, 2012 at 2:42 PM, Federico Mena Quintero wrote: > On Wed, 2012-04-25 at 15:31 +0100, Sergey Udaltsov wrote: > >> no way to find the audience that would be unbiased? Are you just >> implying that the current userbase of GNOME is so geekish that fair >> survey among existing users would only represent the POV of geeks? > > It would be very instructive to see how non-geek people configure their > keyboards (if they do at all!), and how they manage to survive on an > everyday basis. ... It isn't so much how people configure their keyboards as how they (a) switch between different languages/alphabets and (b) insert special characters. For (a) the CJK languages are particularly complex, and I've done a lot of talking with i18n folk (who seem to have a pretty good handle on this) for that reason. (b) is varied because there are so many ways to do the same thing, from alt codes on Windows (seem to be popular, for some reason) and option codes on Mac, to the use of character maps and the web (how else can I find that snowman unicode character [1]?). To me, this feature is the first step in a wider effort to make it easier to use different languages on GNOME and to make it easy to insert special characters. Once we've established some good defaults and sanitised our configuration options, we can start to look at other ways we can improve the experience for our users [2]. Allan ☃ [1] http://unicodesnowmanforyou.com/ [2] https://live.gnome.org/GnomeOS/Design/Whiteboards/ExtraCharacters -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: IBus/XKB integration
> It isn't so much how people configure their keyboards as how they (a) > switch between different languages/alphabets So, this means the option group grp:* is included. Which is obvious anyway... > (b) insert special characters. Thus, misc:typo should be there, right? It was mentioned in your survey as well. Also, the groups nbsp:* and euro:* are probably applicable (well, I would not insist on those two - but it is just IMHO). Sergey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
On Wed, 2012-04-25 at 18:38 -0400, Marina Zhurakhinskaya wrote: > Hi! > > I'd like to propose a new lock screen as a 3.6 feature. The new lock screen > will > > - allow user authentication with a password, pin, fingerprint, or smartcard Looking forward to that! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tentative feature: Custom activities
On 26 April 2012 10:12, Bastien Nocera wrote: > Hello Phil, > > On Wed, 2012-04-25 at 21:54 +0100, Phil Housley wrote: >> Hello Gnome, >> >> (This is a bit long. Summary: Combine good bits of Gnome and Android >> application models.) >> >> I know there has already been a lot of discussion around the new style >> of Gnome applications, with the maximised by default windows and all >> that, but I want to suggest a different way of thinking about the >> issue. > > > I see nowhere in your explanations who the owner of the feature is. It's > a requirement to have somebody to develop the proposed features, as > noted in Andre's mail: > http://mail.gnome.org/archives/devel-announce-list/2012-March/msg5.html > > Is that developer you? > > Cheers > This is all just ideas at the moment, perhaps I shouldn't have even put the word "feature" in the subject. If there's any interest at all I will try and put together a spec, and see if there's enough to make a real proposal, but I didn't like to do that speculatively when I know I would need so many people to buy in to it. Thanks, -- Phil Housley ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/04/12 03:04, Shaun McCance wrote: > But I share Bhaavan's concern with having to physically drag the > screen up. It's very cumbersome with a mouse. And aside from being > inconvenient, without keyboard-only use it's not accessible. When a password has been set, maybe widgets and the password entry could be presented in the same view, rather than requiring the extra step of "lifting the curtain". I understand that typing the password directly would work, but there is no affordance in the proposed UI that indicates so. In a system where the password has not been set, this "courtain" adds an extra step between unblanking the screen and actually returning to work. This makes sense in a touch device to prevent accidental input, but in a desktop I am afraid that it would just get in the way of the user. (It might be that I am not understanding the proposed interaction correctly, apologies if that's the case) Felipe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk+ZNzMACgkQ3e5RNKzod9fw6gCggQLpa+qyUe85wYVj9NqLJlU6 pYsAnRWeDXLBjspCj/y+w43P5Zq1ItHs =PPnQ -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
Hi Allan On Wed, 2012-04-25 at 14:27 +0100, Allan Day wrote: > Hi all, > > Apologies in advance for the long mail - there was no other way. > > > There have been a few design-related threads on the list recently. I’m > going to try and reboot those discussions in a slightly different and, > I hope, more constructive mode. > yes, very constructive, so thanks a lot for stepping in and getting the discussion to a constructive way! > Now, there have been some initiatives in GNOME to try and help make > design more successful within the community. Some of those are > well-known, like the design wiki pages and the IRC channel, but there > have been other things too, like design office hours (remember those? > nobody came), UX Advocates (also suffered from a lack of take up) and > Every Detail Matters. We are also working to attract more design > contributors, which the Outreach Program for Women is really helping > with right now (yay!) > I think a lot of people complain about not having an archive of what has been discussed in design land, so even though I know you are all busy, maybe it would be great to use the usability list to notify of ongoing work. Just a mail linking to the design wiki pages when something new is added/updated would be a great step. And I think it would make all the people that complain about this have a "central point" of information. just something that came to mind after seeing your very constructive mail, so just ignore it if it doesn't make sense :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME Goal Proposal: Port to GMenu
Hi all, Last release we introduced the ability for applications to define a GMenu (or 'application menu'). This means that applications now have a place to locate global application (as opposed to per window) menu items. Some applications have already started to use a GMenu, and while this is great, it has also introduced some inconsistency (since some app menus have several items in them and some just have Quit). It would be great if we could improve on the current situation and ensure that all our applications present an appropriate set of items in their GMenu. I've started a GNOME Goal page [1] which we can use to coordinate this work, if people think it's a good idea. Allan [1] https://live.gnome.org/GnomeGoals/PortToGMenu -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On Thu, 2012-04-26 at 13:55 +0100, Allan Day wrote: > Hi all, > > Last release we introduced the ability for applications to define a > GMenu (or 'application menu'). This means that applications now have a > place to locate global application (as opposed to per window) menu > items. Some applications have already started to use a GMenu, and > while this is great, it has also introduced some inconsistency (since > some app menus have several items in them and some just have Quit). > > It would be great if we could improve on the current situation and > ensure that all our applications present an appropriate set of items > in their GMenu. I've started a GNOME Goal page [1] which we can use to > coordinate this work, if people think it's a good idea. I'm not sure how good an idea this is given that the use of the app menu means that the application itself will require redesign. It would only be really useful for smaller applications with a very limited number of menu items, without a redesign. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On Thu, Apr 26, 2012 at 2:02 PM, Bastien Nocera wrote: > On Thu, 2012-04-26 at 13:55 +0100, Allan Day wrote: >> Hi all, >> >> Last release we introduced the ability for applications to define a >> GMenu (or 'application menu'). This means that applications now have a >> place to locate global application (as opposed to per window) menu >> items. Some applications have already started to use a GMenu, and >> while this is great, it has also introduced some inconsistency (since >> some app menus have several items in them and some just have Quit). >> >> It would be great if we could improve on the current situation and >> ensure that all our applications present an appropriate set of items >> in their GMenu. I've started a GNOME Goal page [1] which we can use to >> coordinate this work, if people think it's a good idea. > > I'm not sure how good an idea this is given that the use of the app menu > means that the application itself will require redesign. It would only > be really useful for smaller applications with a very limited number of > menu items, without a redesign. > If an app has a complex menu bar, I'm recommending that it just moves a small number of items to the app menu (eg. new window, preferences, help, about, quit). That way we can ensure at least some consistency and prevent those "oh, there's nothing there" moments. Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On 26 April 2012 09:35, Allan Day wrote: > On Thu, Apr 26, 2012 at 2:02 PM, Bastien Nocera wrote: >> On Thu, 2012-04-26 at 13:55 +0100, Allan Day wrote: >>> Hi all, >>> >>> Last release we introduced the ability for applications to define a >>> GMenu (or 'application menu'). This means that applications now have a >>> place to locate global application (as opposed to per window) menu >>> items. Some applications have already started to use a GMenu, and >>> while this is great, it has also introduced some inconsistency (since >>> some app menus have several items in them and some just have Quit). >>> >>> It would be great if we could improve on the current situation and >>> ensure that all our applications present an appropriate set of items >>> in their GMenu. I've started a GNOME Goal page [1] which we can use to >>> coordinate this work, if people think it's a good idea. >> >> I'm not sure how good an idea this is given that the use of the app menu >> means that the application itself will require redesign. It would only >> be really useful for smaller applications with a very limited number of >> menu items, without a redesign. >> > > If an app has a complex menu bar, I'm recommending that it just moves > a small number of items to the app menu (eg. new window, preferences, > help, about, quit). That way we can ensure at least some consistency > and prevent those "oh, there's nothing there" moments. I don't know if Unity supports having both regular menus and a Gmenu at the same time. Also, it's not consistent with the HIG (or much of anything) to have Preferences be moved from the Edit menu. Maybe Preferences could be *copied* to the app menu but that's not necessarily a good idea either. Jeremy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On Thu, Apr 26, 2012 at 10:04 AM, Jeremy Bicha wrote: > On 26 April 2012 09:35, Allan Day wrote: >> On Thu, Apr 26, 2012 at 2:02 PM, Bastien Nocera wrote: >>> On Thu, 2012-04-26 at 13:55 +0100, Allan Day wrote: Hi all, Last release we introduced the ability for applications to define a GMenu (or 'application menu'). This means that applications now have a place to locate global application (as opposed to per window) menu items. Some applications have already started to use a GMenu, and while this is great, it has also introduced some inconsistency (since some app menus have several items in them and some just have Quit). It would be great if we could improve on the current situation and ensure that all our applications present an appropriate set of items in their GMenu. I've started a GNOME Goal page [1] which we can use to coordinate this work, if people think it's a good idea. >>> >>> I'm not sure how good an idea this is given that the use of the app menu >>> means that the application itself will require redesign. It would only >>> be really useful for smaller applications with a very limited number of >>> menu items, without a redesign. >>> >> >> If an app has a complex menu bar, I'm recommending that it just moves >> a small number of items to the app menu (eg. new window, preferences, >> help, about, quit). That way we can ensure at least some consistency >> and prevent those "oh, there's nothing there" moments. > > I don't know if Unity supports having both regular menus and a Gmenu > at the same time. Also, it's not consistent with the HIG (or much of > anything) to have Preferences be moved from the Edit menu. Maybe > Preferences could be *copied* to the app menu but that's not > necessarily a good idea either. As I understood it, app menus were for all app-global things. If Preferences is app-global, it should be moved into the app menu. And I thought that desrt and Colin worked very hard to have this work with Ubuntu. I remember Colin talking about how hard this was because of integration between GNOME 2, GNOME 3 and Unity. > Jeremy > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On Thu, 2012-04-26 at 10:04 -0400, Jeremy Bicha wrote: > On 26 April 2012 09:35, Allan Day wrote: > > On Thu, Apr 26, 2012 at 2:02 PM, Bastien Nocera wrote: > >> On Thu, 2012-04-26 at 13:55 +0100, Allan Day wrote: > >>> Hi all, > >>> > >>> Last release we introduced the ability for applications to define a > >>> GMenu (or 'application menu'). This means that applications now have a > >>> place to locate global application (as opposed to per window) menu > >>> items. Some applications have already started to use a GMenu, and > >>> while this is great, it has also introduced some inconsistency (since > >>> some app menus have several items in them and some just have Quit). > >>> > >>> It would be great if we could improve on the current situation and > >>> ensure that all our applications present an appropriate set of items > >>> in their GMenu. I've started a GNOME Goal page [1] which we can use to > >>> coordinate this work, if people think it's a good idea. > >> > >> I'm not sure how good an idea this is given that the use of the app menu > >> means that the application itself will require redesign. It would only > >> be really useful for smaller applications with a very limited number of > >> menu items, without a redesign. > >> > > > > If an app has a complex menu bar, I'm recommending that it just moves > > a small number of items to the app menu (eg. new window, preferences, > > help, about, quit). That way we can ensure at least some consistency > > and prevent those "oh, there's nothing there" moments. > > I don't know if Unity supports having both regular menus and a Gmenu > at the same time. If it doesn't, there's fallback code in GTK+. But you should really point that out to Unity developers. On the GNOME lists, we tend to focus on GNOME itself. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On 26 April 2012 10:10, Jasper St. Pierre wrote: > On Thu, Apr 26, 2012 at 10:04 AM, Jeremy Bicha wrote: >> On 26 April 2012 09:35, Allan Day wrote: >>> On Thu, Apr 26, 2012 at 2:02 PM, Bastien Nocera wrote: On Thu, 2012-04-26 at 13:55 +0100, Allan Day wrote: > Hi all, > > Last release we introduced the ability for applications to define a > GMenu (or 'application menu'). This means that applications now have a > place to locate global application (as opposed to per window) menu > items. Some applications have already started to use a GMenu, and > while this is great, it has also introduced some inconsistency (since > some app menus have several items in them and some just have Quit). > > It would be great if we could improve on the current situation and > ensure that all our applications present an appropriate set of items > in their GMenu. I've started a GNOME Goal page [1] which we can use to > coordinate this work, if people think it's a good idea. I'm not sure how good an idea this is given that the use of the app menu means that the application itself will require redesign. It would only be really useful for smaller applications with a very limited number of menu items, without a redesign. >>> >>> If an app has a complex menu bar, I'm recommending that it just moves >>> a small number of items to the app menu (eg. new window, preferences, >>> help, about, quit). That way we can ensure at least some consistency >>> and prevent those "oh, there's nothing there" moments. >> >> I don't know if Unity supports having both regular menus and a Gmenu >> at the same time. Also, it's not consistent with the HIG (or much of >> anything) to have Preferences be moved from the Edit menu. Maybe >> Preferences could be *copied* to the app menu but that's not >> necessarily a good idea either. > > As I understood it, app menus were for all app-global things. If > Preferences is app-global, > it should be moved into the app menu. I believe we were talking about keeping File/Edit/View while adding a GMenu. If so, the UI would be quite confusing if some things were taken out of the normal File/Edit/View menus. If all we're talking about is how Epiphany 3.4 works, then that's fine but that's not how I read what was written. > And I thought that desrt and Colin worked very hard to have this work > with Ubuntu. I remember > Colin talking about how hard this was because of integration between > GNOME 2, GNOME 3 > and Unity. Unity supports GMenus as a replacement for the traditional File/Edit/View menus, but I don't think it works as an addition at this time. No app does that yet anyway. On 26 April 2012 10:14, Bastien Nocera wrote: > If it doesn't, there's fallback code in GTK+. But you should really > point that out to Unity developers. On the GNOME lists, we tend to focus > on GNOME itself. Of course, GNOME decisions affect Ubuntu & Unity. I'm interested in GNOME (Shell), GNOME Fallback (not for me personally but I help to maintain it for Ubuntu users that want it), and Unity. Jeremy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On Thu, Apr 26, 2012 at 4:04 PM, Jeremy Bicha wrote: > I don't know if Unity supports having both regular menus and a Gmenu > at the same time. > I don't know either, but I don't think it is relevant here - there is GMenu support for *both* app menu and window menu in GtkApplication/GtkApplicationWindow, so as long as the entire menubar is ported, all of Unity, GNOME 3 and fallback should work as expected. It might be a good idea to clarify the goal with regard to window menubars though :-) Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
On Thu, 2012-04-26 at 11:32 +0200, Florian Müllner wrote: > As I understand it, typing the password will switch to the password > "dialog", which is about as keyboard/non-touch friendly as it gets :-) If the implementation is just like the screenshots, I would never know that's the case without having read this email. That's not friendly. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On Thu, Apr 26, 2012 at 10:23 AM, Jeremy Bicha wrote: ... > I believe we were talking about keeping File/Edit/View while adding a > GMenu. If so, the UI would be quite confusing if some things were > taken out of the normal File/Edit/View menus. If all we're talking > about is how Epiphany 3.4 works, then that's fine but that's not how I > read what was written. ... In some cases there will be a GMenu and a menu bar (with File/Edit/View...) for the same app, at least in the short term. I think that's less confusing than the current situation, in which: * some apps have items in their GMenu and some don't * global application options don't fit well into existing menu bar structures (eg. 'Quit' in 'File', 'Preferences' in 'Edit') We were criticised for the lack of consistency between app menus in several reviews of the 3.4 release. I would like to avoid that for 3.6. Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
Hey Maciej, > Why use PIN at all? (Apparently that is question for Windows 8 as > well). > Or is it for smartcards? PIN entry is an alternative authorization method for form factors where a typically long text entry (especially with numerals thrown in) is too much of a burden, like on a tablet device. I can see some additional methods, like using swipe patterns or face detection viable, but this seemed like the easiest approach. cheers -- Jakub Steiner http://jimmac.musichall.cz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
Hi Shaun, > I *love* the idea of showing notifications and allowing control of > media playback. It's something I've wanted for a very, very long > time. > > But I share Bhaavan's concern with having to physically drag the > screen up. It's very cumbersome with a mouse. And aside from being > inconvenient, without keyboard-only use it's not accessible. We briefly touch (pun intended) on keyboard interaction at the bottom of the page. You should be able to unroll the curtain with Esc. > How is the PIN supposed to be set? Will that involve changes to > the User Accounts panel? The login options in the user settings panel is the obvious place place for customizing that. We are also working on the initial setup*, which would also be the place where this is exposed (but we don't have anything to point to at this stage). > And while we're dealing with User Accounts and passwords, could we > manage to do something about the password hint? You can set it, but > it doesn't do anything useful in any software anywhere. It's kind > of embarrassing to have to write that in the help. Thanks for bringing that up. I imagine this becomes useful after several failed attempts to authorize. cheers * https://live.gnome.org/GnomeOS/Design/Whiteboards/InitialSetup ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
OT: Unity handling of Application menus (was: Re: GNOME Goal Proposal: Port to GMenu)
On Thu, 2012-04-26 at 10:23 -0400, Jeremy Bicha wrote: > On 26 April 2012 10:10, Jasper St. Pierre wrote: > > And I thought that desrt and Colin worked very hard to have this work > > with Ubuntu. I remember > > Colin talking about how hard this was because of integration between > > GNOME 2, GNOME 3 > > and Unity. > > Unity supports GMenus as a replacement for the traditional > File/Edit/View menus, but I don't think it works as an addition at > this time. No app does that yet anyway. Slightly off topic for the GNOME lists, but just to clear up any confusion. In indicator-appmenu we watch for applications that both application menus and window menus and display both in the Unity menu bar. So an application that has both would get something like: [Application Name] [File] [Edit] But then, perhaps obviously, if there are no window menus only the application menu will be shown (and vice-versa). It's true that not many applications do this, so bloatpad was the biggest test case, but that's the idea :-) While there are few today, our goal here was to ensure that as new applications are developed it is expected that they'd use GMenuModel instead of traditional GTK menus. We expect that some developers would want to target the Ubuntu 12.04 release via myapps[1] and we want those applications to work for the full lifecycle of the release. We want to encourage usage of GMenuModel in all applications, much better than the Dbusmenu parser we have for the traditional menus. --Ted [1] http://myapps.developer.ubuntu.com (slow today, sorry) 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: 3.6 Feature: Lock Screen
On Thu, 2012-04-26 at 10:55 -0400, Jakub Steiner wrote: > Hey Maciej, > > > Why use PIN at all? (Apparently that is question for Windows 8 as > > well). > > Or is it for smartcards? > > PIN entry is an alternative authorization method for form factors where a > typically long text entry (especially with numerals thrown in) is too much of > a burden, like on a tablet device. I can see some additional methods, like > using swipe patterns or face detection viable, but this seemed like the > easiest approach. Makes sense. I think it might be better to invest some more time in coming up with an alternative to PINs, though. Something like swipe patterns would be more usable (though I believe they might be patented). Though PINs are easy to implement, they place a memory burden on the user just the same as passwords do. There's also the risk of users re-using PINs between security domains, though iirc users do generally understand the difference between "really valuable PIN used for banking" and "less valuable mobile phone PIN". Philip > cheers > > -- > Jakub Steiner > http://jimmac.musichall.cz > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list 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 Goal Proposal: Port to GMenu
On Thu, Apr 26, 2012 at 4:35 PM, Allan Day wrote: > In some cases there will be a GMenu and a menu bar (with > File/Edit/View...) for the same app, at least in the short term. > There is some confusion about terminology here, so Ryan asked me to clarify :-) "GMenu" is a newly introduced technology to implement *both* 'app menus' (the shell's application menu) and 'menubars' (which looks like a traditional menubar, but is set with gtk_application_set_menubar()). The goal should be to port existing menubars to GMenu, either only providing an app menu, or splitting actions between app menu and menubar. The benefit will be menus that behave as expected by the environment - GNOME 3 will display the app menu in the top bar and keep the menubar in the windows, GNOME Fallback (and Windows) will display both in windows and Mac OS X / Unity will merge them into the global menu. Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: OT: Unity handling of Application menus (was: Re: GNOME Goal Proposal: Port to GMenu)
On Thu, Apr 26, 2012 at 10:53 AM, Ted Gould wrote: > On Thu, 2012-04-26 at 10:23 -0400, Jeremy Bicha wrote: >> On 26 April 2012 10:10, Jasper St. Pierre wrote: >> > And I thought that desrt and Colin worked very hard to have this work >> > with Ubuntu. I remember >> > Colin talking about how hard this was because of integration between >> > GNOME 2, GNOME 3 >> > and Unity. >> >> Unity supports GMenus as a replacement for the traditional >> File/Edit/View menus, but I don't think it works as an addition at >> this time. No app does that yet anyway. > > Slightly off topic for the GNOME lists, but just to clear up any > confusion. In indicator-appmenu we watch for applications that both > application menus and window menus and display both in the Unity menu > bar. So an application that has both would get something like: > > [Application Name] [File] [Edit] > > But then, perhaps obviously, if there are no window menus only the > application menu will be shown (and vice-versa). It's true that not > many applications do this, so bloatpad was the biggest test case, but > that's the idea :-) > > While there are few today, our goal here was to ensure that as new > applications are developed it is expected that they'd use GMenuModel > instead of traditional GTK menus. We expect that some developers would > want to target the Ubuntu 12.04 release via myapps[1] and we want those > applications to work for the full lifecycle of the release. We want to > encourage usage of GMenuModel in all applications, much better than the > Dbusmenu parser we have for the traditional menus. Does GMenuModel support window-specific menus? > --Ted > > [1] http://myapps.developer.ubuntu.com (slow today, sorry) > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
GMenu is a very good idea. The menu system has remained stagnant since the early software design days, and has become archaic. There is ambiguity as to location of various options (read Preferences in Edit or Tools, Select in Edit or elsewhere), For a new user, this is an evil which can be done away with. The root cause of this is each app developer has a different opinion on this and develops accordingly. Having GMenu like system, will eventually transfer this problem to be handled by the Shell, and the shell will handle menus in a consistent manner as per agreed guidelines. This reinforces the principle of gnome shell of providing a consistent interface across its applications. Yes, porting all the applications to use gmenu will not be an easy task. as it will require app level redesign. But the redesign is minimal in nature and should be an affordable one. At the same time, even if a large chunk of apps wont change, atleast it should be a standard for future app designs, so that atleast the new applications do not still follow a real old technique established in early GUI days. IMO, at a later stage this could be evolved into a HUD system, which will not only be content aware, but will display smart and relevant results. Again, the main reason being that what is not an apps main purpose, should be handled by the shell (whose main purpose is to provide a neat, elegant and consistent user experience). Even though not a direct part of gnome, many applications like libreoffice, inkscape, gimp, blender etc. IMHO are suffering from poor menu designs cause of constraints. Having them integrated through a gmenu, and to allow them the flexibility of a shell-takes-care system, will benefit all. Ofcourse, there may be tasks they would want to handle themselves, but the gmenu will be non-intrusive to that. Regards, Bhaavan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
2012/4/25 Allan Day :
>
>
> But there are challenges and things we can do better. Among those
> obstacles, I see:
> * giving people a stake in the project - the danger of design-led
> development is that people feel that the project is no longer theirs.
> They want to feel they can have an impact and that they can express
> themselves through their activities in the community.
> * design disagreements can sour relationships and lead to discord
> * letting people stay in touch with and understand design activities,
> and therefore the activities of the project as a whole
>From my point of view the main issue (at least perceived as issue) in
current design->develop workflow is explanation.
While our design/ux team is able to produce great ideas, frequently
the only visible product of design work is a wiki page with poor info.
Or, at least, poor compared with documents and info provided by
others. You can compare, for instance, our document about proposed
changes for unlock screen [1] or initial setup [2] with a similar
document from Canonical about changes for multiple monitor stuff[3].
In [1] and [2] I can see only hints about how features could work. In
[3] you have a fully detailed explanation of each phase or action or
reaction of the system. Of course you'll have to spend more time
writing and reading it, but people will be able to understand without
guessing. This should be helpful to maintainers ("I know what I've to
do, no need to ping designers"), casual contributors ("this piece is
not yet implemented, maybe I can work on it"), other teams ("I've to
document this feature, and I know how it will work"). And design team
too, people will be able to give a quicker, more precise, and better
feedback.
So basically: why do I've to agree with your design and apply those
changes? or say this new stuff is better? The proposed unlock screen
is gorgeous, but... wait, _guessing_ from mockups is seems I've to use
mouse and drag the little triangle before I can type my password...
slow... boring... current unlock dialog is better, faster, stronger,
harder... design team sucks, they want to break _my own_ workflow with
no actual reason or gain.
There are too many images and too few words in [1]. I've to scroll to
the end of the page before I can read "lock is removed by [...] Esc
key on keyboard" (BTW I usually type "Ctrl" to wake up monitor before
starting to type my passoword, it's closer than Esc). You are still
trying to change my workflow, but at least it seems I will not need to
use both mouse and keyboard.
So, IMHO a design driven GNOME needs good desing documents. The
"design document is a written contract"[4] between designers and other
teams, more time you spend writing it, less time you'll spend explaing
here on desktop devel list :)
[1] https://live.gnome.org/GnomeOS/Design/Whiteboards/ScreenLock
[2] https://live.gnome.org/GnomeOS/Design/Whiteboards/InitialSetup
[3]
https://docs.google.com/document/d/1aHvJ-iIw-59bXTYBmIhQqEx0za2h9jpFE_RhZ2VOvJc/edit
[4]
https://blog.slickedit.com/2007/05/how-to-write-an-effective-design-document/
PS
> * a process for resolving design disagreements - perhaps maintainers
> or the release team could mediate if a dispute seems intractable?
hmm disagreement between ... ? designers and maintainers?
designers and contributors? designers and i18n/doc/a11y team?
designers and users? designers and release team itself?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tentative feature: Custom activities
On Thu, Apr 26, 2012 at 7:07 AM, Phil Housley wrote: > On 26 April 2012 10:12, Bastien Nocera wrote: >> Hello Phil, >> >> On Wed, 2012-04-25 at 21:54 +0100, Phil Housley wrote: >>> Hello Gnome, >>> >>> (This is a bit long. Summary: Combine good bits of Gnome and Android >>> application models.)be >>> >>> I know there has already been a lot of discussion around the new style >>> of Gnome applications, with the maximised by default windows and all >>> that, but I want to suggest a different way of thinking about the >>> issue. >> >> >> I see nowhere in your explanations who the owner of the feature is. It's >> a requirement to have somebody to develop the proposed features, as >> noted in Andre's mail: >> http://mail.gnome.org/archives/devel-announce-list/2012-March/msg5.html >> >> Is that developer you? >> >> Cheers >> > > This is all just ideas at the moment, perhaps I shouldn't have even > put the word "feature" in the subject. If there's any interest at all > I will try and put together a spec, and see if there's enough to make > a real proposal, but I didn't like to do that speculatively when I > know I would need so many people to buy in to it. > > Thanks, > I love the concept! I feel like it may still need some things figured out, maybe if you could get some input from design people to work out the kinks, but something like this would definitely improve my gnome experience. > -- > Phil Housley > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Diego Fernandez - 爱国 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
Hi all, Sorry in advance for the long e-mail and any eventual harsher remark :) For some time now it seems that the way to create, lets say a new core GNOME application has been to get someone from the design team to publish rude mockups for a couple of screens in that App and then passing it on for developers to implement it. I think this is fundamentally wrong. Not because most developers would create better designs but because the entire process gets fragmented. Ideally, every developer and designer should have an intuitive and creative sense of design and usability, have a strong understanding of the technology and its future capabilities and be able to grasp the bigger picture. And looking at the bigger picture, quite a few things are flagrant: - First of, to create beautifully designed and intuitive user interfaces there needs to be great technology. When the iPhone was first introduced in early 2007, everyone felt a punch in their stomach with how great the user interfaces and experiences were. And even on the desktop, OSX featured applications with user interfaces that were easy to use, full of carefully crafted widgets, user interactions that responded with subtle animations and a general feel that huge amounts of dedication went into creating those. In 2007 GNOME hadn't anything compared to that, and it still doesn't. Were the iPhone to be introduced today, applications with GTK3 interfaces would look almost as antiquated as they looked back then. - In 2007 it should have become clear that in the future, a significant part of computing would become mobile, with touch input. It's now mid 2012. GNOME is galaxies away from providing a touch experience even worth advertising. As an example, the people at Palm weren't very successful from a commercial perspective, but to their credit, I think they created something really interesting and more refined than Android, all of this faster than the average time it takes to get a patch through. And the first time someone used this new era of smartphones, either from Apple or the Android vendors, it should have been obvious that all mobile devices, or actually all devices, would eventually feature really high density screens. Yet there's still nothing close to full resolution independence in GNOME as a whole. - For a couple of years "netbooks" sold like free beer. Everyone on this camp got excited at all those vendors that shipped some sort of Linux (to lower their costs) but eventually, it wasn't even good enough to compete against the familiarity of Windows XP and most of us didn't realize how crappy of a form factor the "netbook" actually was. So again, GNOME stalled on delivering innovation to the desktop or a new and creative approach to touch. - I think there are many ways to tackle the same problem, but great design is Universal. When one sees great design, the immediate reaction is of WOW. When the "Shell" was first publicly introduced, a face of near terror was prevalent in the eyes of most. The Shell appeared as a design decision set in concrete, yet with a guarantee that it would eventually "get better". At the time, most felt GNOME needed a new face, but there wasn't any logic rationale as to why the chosen design was the "Shell", but not "Awn", or "Docky", or "Unity". Well, actually there was, and it's the same rationale that inhibits GNOME from integrating some beautiful Apps such as "Lingo", "Postler" or "Dexter", Apps that I didn't even know existed but are really beautiful and slick. And the rationale seems to be to not even consider stuff that doesn't originate from a core set of people working for a core set of companies. Well, It seems likely that no one from those projects ever proposed them for inclusion in GNOME, but would they sincerely even stand a chance due to the simple fact that someone from the design team submitted a mockup for a similar application? The lack of internal competition is astonishing. - Finally, great applications. With maybe a few rare exceptions, for every GNOME application, there is a Windows counterpart that is as good or better, and an OS X counterpart that is way, way better. From an user experience point of view (I'm not talking feature-wise), comparing "Totem" to "QuickTime", "AbiWord" to "Pages" or "any photo App for GNOME" to "iPhoto" might even sound embarrassing. So it would be crucial that people spent effort in creating "the best application in the World", but of course, the core technology to make this happen needs to be present and even small details need to be thought through, such as the default font in GNOME3, which I swear the quality should not even be regarded as a matter of taste but rather as a matter of eyesight health :) So I find it really an issue that designers and developers aren't working as one. The new mockups look like an attempt to make applications look better, but not great. Yet better isn't remotely enough. For those who haven't yet got a chance, I urge you to try
Re: Rules for design in Gnome
Tomeu: On 04/26/12 02:06 AM, Tomeu Vizoso wrote: On Tue, Apr 24, 2012 at 15:10, Alberto Ruiz wrote: I'm afraid that interfering in the maintainer's responsibilities is a very big can of worms, more likely to do harm than good. There's something powerful in how a maintainer feels responsible about his module and the community that surrounds it. Some of my thoughts about the GNOME maintainer community, aside from the fact that they do a great job. 1) There really are not any good forums for communicating with core GNOME maintainers as a group. Looking at MaintainersCorner I see that GNOME only requires maintainers to subscribe to devel-announce-list. I suppose much communication happens on desktop-devel-list and foundation-list, but it seems hard to figure out how to have a dialog with the maintainers as a group or how to make decisions. A lot of problems might solve themselves if we made it easier for maintainers to focus on decision making when needed. 2) Many distros are currently supporting GNOME 2 based distros. While I think it is good that our development community is focused on GNOME 3, it is also important to encourage distros to cooperate as they maintain GNOME 2 and keep it working well so that the brand is strong and positive. I remember Vincent suggesting that core GNOME 2 modules might need additional maintainers in order to provide ongoing support to do cooperative efforts like this. To make something like this work well requires coordination and decision making amongst maintainers. Providing more support for more branches might require more infrastructure. It seems it should be possible to strike a better balance between focusing energy on new development while providing more impressive support for those who continue to depend on GNOME 2. I'd say there is probably enough topics to warrant having a Maintainers BOF or something at GUADEC where topics like this might be discussed. I think it would be great if we could find new ways to augment our maintainer community, or to make our decision-making processes easier and more transparent. And probably a good forum to discuss what sorts of Usability rules resonate most with maintainers. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
2012/4/26 Jakub Steiner > > We briefly touch (pun intended) on keyboard interaction at the bottom of > the page. You should be able to unroll the curtain with Esc. If there is a sign on the curtain which says: "Press Esc to roll up the curtain" this will be easily discoverable and all fine. -- www.twitter.com/Rovanion ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: OT: Unity handling of Application menus (was: Re: GNOME Goal Proposal: Port to GMenu)
On Thu, 2012-04-26 at 11:54 -0400, Jasper St. Pierre wrote: > On Thu, Apr 26, 2012 at 10:53 AM, Ted Gould wrote: > > While there are few today, our goal here was to ensure that as new > > applications are developed it is expected that they'd use GMenuModel > > instead of traditional GTK menus. We expect that some developers would > > want to target the Ubuntu 12.04 release via myapps[1] and we want those > > applications to work for the full lifecycle of the release. We want to > > encourage usage of GMenuModel in all applications, much better than the > > Dbusmenu parser we have for the traditional menus. > > Does GMenuModel support window-specific menus? GMenuModel supports menu structures, what specifies what type of menus those are is the GtkApplication object. So if you want to create window menus you'd build the model and set it on the application window using gtk_application_set_menubar(). --Ted 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: 3.6 Feature: Lock Screen
Hi, On 25/04/12 23:38, Marina Zhurakhinskaya wrote: > Technically, the code for fading out the screen and displaying the > lock screen when the user becomes active again will be added to GNOME > Shell, and the gnome-screensaver will no longer be used. There are security implications of this proposed change. In the event the Shell crashes, you cannot make any assumptions, and therefore any guarantees, about how much of the state will be recovered, and hence that lock will not be compromised. Even if the Shell does restart successfully, the content of the desktop is visible for the time it takes the Shell to restart, which is by no means negligible. Considering how often Mutter crashes (I see about 3-4 crashes an hour), the WM is a completely unsuitable process to be endowed with any security responsibilities. I think the screen lock needs to remain a separate process with a singular focus rather yet another thing for the WM to deal with. Tomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
On Thu, Apr 26, 2012 at 12:16 PM, Luca Ferretti wrote: > 2012/4/25 Allan Day : > From my point of view the main issue (at least perceived as issue) in > current design->develop workflow is explanation. > > While our design/ux team is able to produce great ideas, frequently > the only visible product of design work is a wiki page with poor info. > Or, at least, poor compared with documents and info provided by > others. You can compare, for instance, our document about proposed > changes for unlock screen [1] or initial setup [2] with a similar > document from Canonical about changes for multiple monitor stuff[3]. But in reality there is no such workflow where the design team delivers a 'visible product' that is than taken by developers as-is and converted into code. Design is a process that involves frequent communication between the people who are doing the design and the people who are writing the code. The wiki pages you cite are merely notes that help you remember the most important points from those discussions. At least that is how all my interactions with the designers have gone. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
On Thu, Apr 26, 2012 at 6:41 PM, Tomas Frydrych wrote: > Hi, > > On 25/04/12 23:38, Marina Zhurakhinskaya wrote: >> Technically, the code for fading out the screen and displaying the >> lock screen when the user becomes active again will be added to GNOME >> Shell, and the gnome-screensaver will no longer be used. > > There are security implications of this proposed change. In the event > the Shell crashes, you cannot make any assumptions, and therefore any > guarantees, about how much of the state will be recovered, and hence > that lock will not be compromised. Even if the Shell does restart > successfully, the content of the desktop is visible for the time it > takes the Shell to restart, which is by no means negligible. > > Considering how often Mutter crashes (I see about 3-4 crashes an hour), Bug references? We should not be crashing 3-4 times per hour. > the WM is a completely unsuitable process to be endowed with any > security responsibilities. I think the screen lock needs to remain a > separate process with a singular focus rather yet another thing for the > WM to deal with. > > Tomas > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/04/12 18:16, Luca Ferretti wrote: > > While our design/ux team is able to produce great ideas, > frequently the only visible product of design work is a wiki page > with poor info. Or, at least, poor compared with documents and info > provided by others. You can compare, for instance, our document > about proposed changes for unlock screen [1] or initial setup [2] > with a similar document from Canonical about changes for multiple > monitor stuff[3]. IMHO, that's mainly because Canonical, like e.g. Mozilla, have more design resources focused on a smaller set of problems. This allows them to spend time documenting in more detail, conducting user testing of design proposals before they are published, researching in detail how their solutions are actually being used, etc. Felipe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk+Z2DAACgkQ3e5RNKzod9eWPQCgwi7aiIJjWdkhn35v7+tXanjY VxMAoLvlUJfYfjd35xnEKG8wSLYFUFwi =LK34 -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
On 04/27/2012 01:00 AM, Jasper St. Pierre wrote: > On Thu, Apr 26, 2012 at 6:41 PM, Tomas Frydrych > wrote: >> Hi, >> >> On 25/04/12 23:38, Marina Zhurakhinskaya wrote: >>> Technically, the code for fading out the screen and displaying the >>> lock screen when the user becomes active again will be added to GNOME >>> Shell, and the gnome-screensaver will no longer be used. >> >> There are security implications of this proposed change. In the event >> the Shell crashes, you cannot make any assumptions, and therefore any >> guarantees, about how much of the state will be recovered, and hence >> that lock will not be compromised. Even if the Shell does restart >> successfully, the content of the desktop is visible for the time it >> takes the Shell to restart, which is by no means negligible. >> >> Considering how often Mutter crashes (I see about 3-4 crashes an hour), > > Bug references? We should not be crashing 3-4 times per hour. 3-4 times a day for me. Here are some bugs, they're in the Red Hat bugzilla because they were filed with Fedora Abrt. These hardly represent the number of crashes though, because nearly always "the backtrace isn't usable". https://bugzilla.redhat.com/show_bug.cgi?id=791130 https://bugzilla.redhat.com/show_bug.cgi?id=809365 FWIW on some of my machines, the screensaver is already pretty funny security-wise. When coming back from sleep. It shows the desktop screen for several seconds before locking the screen. Sometimes it only locks one monitor. Sometimes the lock dialog isn't visible. I haven't started to try and debug these issues. I guess one way of looking at that is that hopefully the Lock screen refresh will solve some of these problems :P Cheers, Stef ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
On Fri, Apr 27, 2012 at 12:45 AM, Stef Walter wrote: > On 04/27/2012 01:00 AM, Jasper St. Pierre wrote: >> On Thu, Apr 26, 2012 at 6:41 PM, Tomas Frydrych >> wrote: >>> Hi, >>> >>> On 25/04/12 23:38, Marina Zhurakhinskaya wrote: Technically, the code for fading out the screen and displaying the lock screen when the user becomes active again will be added to GNOME Shell, and the gnome-screensaver will no longer be used. >>> >>> There are security implications of this proposed change. In the event >>> the Shell crashes, you cannot make any assumptions, and therefore any >>> guarantees, about how much of the state will be recovered, and hence >>> that lock will not be compromised. Even if the Shell does restart >>> successfully, the content of the desktop is visible for the time it >>> takes the Shell to restart, which is by no means negligible. >>> >>> Considering how often Mutter crashes (I see about 3-4 crashes an hour), >> >> Bug references? We should not be crashing 3-4 times per hour. > > 3-4 times a day for me. Here are some bugs, they're in the Red Hat > bugzilla because they were filed with Fedora Abrt. These hardly > represent the number of crashes though, because nearly always "the > backtrace isn't usable". > > https://bugzilla.redhat.com/show_bug.cgi?id=791130 This is fixed in 3.4.1. http://git.gnome.org/browse/gnome-shell/commit/?id=0a7968a2e55cb9c7063d65663d5bff504724f7a8 > https://bugzilla.redhat.com/show_bug.cgi?id=809365 Looks like it was an accountsservice bug that's been fixed? > FWIW on some of my machines, the screensaver is already pretty funny > security-wise. When coming back from sleep. It shows the desktop screen > for several seconds before locking the screen. Sometimes it only locks > one monitor. Sometimes the lock dialog isn't visible. I haven't started > to try and debug these issues. If I remember correctly, this was a SELinux policy issue. It should be fixed in upgrades-testing. > I guess one way of looking at that is that hopefully the Lock screen > refresh will solve some of these problems :P > > Cheers, > > Stef -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
