Re: 3.6 Feature: IBus/XKB integration
On 24/04/2012, Owen Taylor otay...@redhat.com wrote: I'm worried about performance here as well - when the keyboard layout changes, there's a lot of work that has to be done. For GTK+, look at the usage of keymap_serial in x11/gdkkeys-x11.c. For Mutter, we, among other things may: - Get the keyboard geometry and iterate through it to identify the above tab key. - Ungrab all keys - Grab all keys again. Ouch, that looks nasty indeed. Thanks for the heads-up. A second issue is that toolkits need to have information about not-currently-active layouts in order to handle accelerators properly. If my UI language is English, and I have a Russian layout and an English layout, then Alt-F should give me the file menu, Control-C should copy without regard to the current layout. This is something that was a big improvement for users when we implemented it in GTK+. Didn't know that either. So, I don't think it really works to just ignore the group mechanism of XKB and always load a one-group layout... it makes more sense to me to identify what layouts are needed for all the input sources and load them into a single keymap ahead of time. Yes, that might limit the user to switching between 4 languages, but, really, how common is it to need more than that? Ok, that sounds like the best way forward then. And yes, I agree that users don't need to switch among more than 4 languages. Rui ___ 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, 2012-04-25 at 09:34 +0200, Rui Tiago Cação Matos wrote: On 24/04/2012, Owen Taylor otay...@redhat.com wrote: snip So, I don't think it really works to just ignore the group mechanism of XKB and always load a one-group layout... it makes more sense to me to identify what layouts are needed for all the input sources and load them into a single keymap ahead of time. Yes, that might limit the user to switching between 4 languages, but, really, how common is it to need more than that? Ok, that sounds like the best way forward then. And yes, I agree that users don't need to switch among more than 4 languages. The 4 layouts limit is an artificial limit that causes bug reports and raised eyebrows, and was one of the bugs that the ibus/xkb integration was supposed to fix. Missing out on it would be a great disappointment... ___ 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 Tue, 2012-04-24 at 20:24 +0100, Sergey Udaltsov wrote: snip I don't agree. If you know about all that stuff you can just as well configure everything yourself outside of GNOME and disable the keyboard g-s-d plugin. Well, that argument can go a very long way, down to twm environment, right? XKB is fully supported by GNOME till 3.4 - why do you insist on breaking that? Can the integration be done without destroying of what GNOME already has in place? Yes, for usability sake we could hide under the carpet the technical difference between IBus and XKB. But make it accessible still. IBus runs on top of XKB. Let average user experience the unified image of the keyboard world, that is the best approach. Most probably - with the single list of layouts etc. But if the user wants the truth, just pure power of XKB, and full xkeyboard-config layout database - give it to him... It does not cost much - because it is already there! Just do not break it, build on top of it please. It costs in terms of maintenance, certainly. There's exactly one person in GNOME that knows libgnomekbd and libxklavier, and that's you. We have the most dreadful options dialogue, with conflicting options[1], we have a X server imposed 4 layouts maximum limit[2], server-driven keyboard shortcuts with limited options[3]. We also lacking integration with input methods that a large number of users use (and if you want to compare those things, much larger than the number of people that use per window layouts). There will be small regressions, which we'll do our best to fix, and there will be design decisions made to ignore particular problems and settings (because I don't see CapsLock key placement as a requirement to the free desktop). We need to go forward (and you're merely pointing to problems that we didn't know existed because code isn't implemented yet!). I'm sure we'll sort those problems out in due time. Cheers [1]: https://bugzilla.gnome.org/show_bug.cgi?id=660924 [2]: https://bugzilla.gnome.org/show_bug.cgi?id=640774 [3]: https://bugzilla.gnome.org/show_bug.cgi?id=654616 ___ 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, 2012-04-25 at 11:15 +0100, Sergey Udaltsov wrote: I guess the solution would be in the smart approach - the ability to use 4 groups for most of the people who do not need more - and ability to call setxkbmap under the hood when the user needs 5+ groups. Calling setxkbmap is expensive - so its usage should be minimised. That's probably good enough. It removes an arbitrary limit, and would most likely be fixed by the time we get to use Wayland. ___ 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 costs in terms of maintenance, certainly. There's exactly one person in GNOME that knows libgnomekbd and libxklavier, and that's you. Well, considering that people submit useful patches to those libs, there is some shared knowledge. But in general you are right. We have the most dreadful options dialogue, with conflicting options[1], we have a X server imposed 4 layouts maximum limit[2], server-driven keyboard shortcuts with limited options[3]. That's XKB world, right. Something should be done to hide its oddities, as everyone agrees. All I am saying is that riches and flexibility of XKB world should not be lost, if possible. A couple of notes: [1]I am not sure which options are conflicting? [2]As I said earlier, there can be workaround. Not perfect, but the best you can do... [3]You cannot avoid that if you deal with server-based group switching. Well, if you move group switching to the client side, you can do everything of course... We also lacking integration with input methods that a large number of users use (and if you want to compare those things, much larger than the number of people that use per window layouts). +100500. There will be small regressions, which we'll do our best to fix, and there will be design decisions made to ignore particular problems and settings (because I don't see CapsLock key placement as a requirement to the free desktop). Filtering out some options/group is reasonable, even necessary - but if you are going to keep some of them visible anyway - let's allow people to turn the filter on/off. Costs nearly nothing, decreases the unhappiness of the advanced users. We need to go forward (and you're merely pointing to problems that we didn't know existed because code isn't implemented yet!). I'm sure we'll sort those problems out in due time. Agree! Sergey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal: Accessibility on by default
On 04/25/2012 02:37 AM, Colin Walters wrote: As the plugin does not do anything when no AT is loaded, OK; that seems to be a relatively recent change (from my admittedly distant perspective). If that's true, and recently the primary cost of a11y has (at least in theory) been deferred to when an AT is loaded, then I'm totally in favor of this change. This change was made the last year. It started with this commit [1], that prevented to add event listeners if no AT is listening. This also includes the creation of the accessible objects or the message forwarding to DBUS. Additionally, one student was making some tests to check if this leads to a real improvement of the performance/memory consumption when accessibility is on but no accessibility technology is listening [2]. This change was made the last year, tested and debugged since then. BR [1] http://git.gnome.org/browse/at-spi2-atk/commit/?id=d0f7dd49eebedc8c3993a116411f5a8320965968 [2] https://mail.gnome.org/archives/gnome-accessibility-devel/2011-October/msg4.html -- Alejandro Piñeiro Iglesias ___ 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 Mon, 2012-04-23 at 23:23 +0200, Rui Tiago Cação Matos wrote: The feature wiki page[2] has some more details and links to initial code to achieve this. [2] https://live.gnome.org/ThreePointFive/Features/IBus That page links to this design page: https://live.gnome.org/Design/SystemSettings/RegionAndLanguage It looks like Compose key is being pushed off to Tweak Tool. When Allan posted about this on Google+ last October, by far the most common thing people said they use is the Compose key: https://plus.google.com/u/0/100040579167442382687/posts/QTFCr48xNkj I think something that common should be easier to get to. -- Shaun ___ 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, 2012-04-25 at 09:13 -0400, Shaun McCance wrote: On Mon, 2012-04-23 at 23:23 +0200, Rui Tiago Cação Matos wrote: The feature wiki page[2] has some more details and links to initial code to achieve this. [2] https://live.gnome.org/ThreePointFive/Features/IBus That page links to this design page: https://live.gnome.org/Design/SystemSettings/RegionAndLanguage It looks like Compose key is being pushed off to Tweak Tool. When Allan posted about this on Google+ last October, by far the most common thing people said they use is the Compose key: https://plus.google.com/u/0/100040579167442382687/posts/QTFCr48xNkj I think something that common should be easier to get to. The Compose key is defined in the layouts. What is being dropped is the ability to override that. (Is Google+ full of anything but geeks nowadays?) ___ 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
https://plus.google.com/u/0/100040579167442382687/posts/QTFCr48xNkj I did not know about that interesting survey. Quite insightful. Would it make sense to make a formal research before pushing some options/groups out? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Design in the open
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. Let’s start with the big picture - design is important for GNOME. Our project’s success rests upon our ability to design and execute an outstanding user experience. It is in all our interests to make GNOME design work, therefore - to work together to produce a consistent, integrated, well-defined, high-quality, delightful user experience. So far we have made some great progress in this direction. We have a small but thriving design community. We have successfully reorganised our development processes around design - development tends to be design led, and we now have new feature proposals each release rather than module proposals. There are very few, if any, real community projects that have achieved this feat. Members of other projects have even approached me in the past to ask how they can replicate GNOME’s success in this area. But there are challenges and things we can do better. Among those obstacles, I see: * lack of design resources - we are always trailing behind where we want to be, and there are important tasks which we are unable to complete (a new HIG springs to mind) * improving the quality of design - we can always do better * getting the project behind a common vision - we sometimes lack focus * 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 * helping community members to participate in design activities 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!) But there is more we can do. The challenge for us as a community is to make design an even more successful part of what we do. This isn’t an easy challenge and I don’t think there are any quick fixes, but we have experience and a rich community on our side. It is important to recognise that improving the state of design in GNOME isn’t just the responsibility of designers. There are things that all of us can do to help - from the release team and maintainers, to individual developers and community advocates. Here are some of my ideas for things that all of us can do to make design work more effectively and harmoniously as a part of GNOME: * a more rigorous (and better documented) feature proposal process * new tools for displaying and discussing designs, such as something like Dribble or Design Hub * a process for resolving design disagreements - perhaps maintainers or the release team could mediate if a dispute seems intractable? * better communications about where GNOME is going and what the project is trying to achieve * some kind of active community management role to help soothe ruffled feathers * advertised designer playgrounds and discussion areas (for people wanting to stretch their design wings) * tackle bad behaviour across the project in a more proactive manner (will ensure that disagreements don’t get out of hand) * micro release-cycles in which new features are advertised, completed and tested * better testing facilities so people can test and give feedback on UX changes before release time * keep a running list of design tasks that are appropriate for newcomers * work to prevent design disputes - ensure early informal contact between designers and developers at the beginning of feature initiatives So there are lots of ways that we can do design better as a community, and contributors on this list can all play a part in helping to make us to be even more successful in this regard. It will take actions as well as words to move forward, of course - if you want to help, or have your own ideas, just get in touch. Allan tl;dr version GNOME design is a community-wide effort - it is not just the responsibility of designers. We’ve got a lot to be proud of in this area, but there are also challenges to overcome. There many things that can help to make GNOME design a success, but it will require people to step up and help out. -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___
Re: 3.6 Feature: IBus/XKB integration
On Wed, 2012-04-25 at 14:22 +0100, Bastien Nocera wrote: On Wed, 2012-04-25 at 09:13 -0400, Shaun McCance wrote: On Mon, 2012-04-23 at 23:23 +0200, Rui Tiago Cação Matos wrote: The feature wiki page[2] has some more details and links to initial code to achieve this. [2] https://live.gnome.org/ThreePointFive/Features/IBus That page links to this design page: https://live.gnome.org/Design/SystemSettings/RegionAndLanguage It looks like Compose key is being pushed off to Tweak Tool. When Allan posted about this on Google+ last October, by far the most common thing people said they use is the Compose key: https://plus.google.com/u/0/100040579167442382687/posts/QTFCr48xNkj I think something that common should be easier to get to. The Compose key is defined in the layouts. What is being dropped is the ability to override that. I don't know of a physical keyboard layout that has a Compose key. So are we just deciding that one of the keys will always behave differently than the printed keycap? I suppose if you use a modifier key (R_Alt seems popular) then it can still function as a modifier as well as Compose, though that will interact poorly with sticky keys. (Is Google+ full of anything but geeks nowadays?) No. :) -- Shaun ___ 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
What is being dropped is the ability to override that. That is exactly what that survey shown: people want to be able to override that. (Is Google+ full of anything but geeks nowadays?) The fallback argument this feature is useful for geeks only is going GNOME a bad job, all the time... It effectively invalidates any surveys among existing user base. How are you going to get the feedback then? I guess the good intentions of the usability specialists and designers are not enough, without reality checks, right? Could GNOME perform a real review on the XKB option groups - find out which ones are used, which ones are not? Of course, it would be difficult to eliminate the bias to geekness - but that's what GNOME user base is. ___ 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, 2012-04-25 at 11:10 +0100, Bastien Nocera wrote: On Wed, 2012-04-25 at 09:34 +0200, Rui Tiago Cação Matos wrote: On 24/04/2012, Owen Taylor otay...@redhat.com wrote: snip So, I don't think it really works to just ignore the group mechanism of XKB and always load a one-group layout... it makes more sense to me to identify what layouts are needed for all the input sources and load them into a single keymap ahead of time. Yes, that might limit the user to switching between 4 languages, but, really, how common is it to need more than that? Ok, that sounds like the best way forward then. And yes, I agree that users don't need to switch among more than 4 languages. The 4 layouts limit is an artificial limit that causes bug reports and raised eyebrows, and was one of the bugs that the ibus/xkb integration was supposed to fix. Missing out on it would be a great disappointment... But the main point of the exercise is to provide an integrated, well designed user interface for inputting languages with billions of users in total. Are people really reporting bugs because they need more than 4 layouts, or because the UI acts confusing when you try to add more than 4 layouts? I'm sure we can engineer a solution to enable more than 4 layouts if that's really a requirement ... if nothing else, revise the XKB protocol. But let's not confuse that with the actual goal here. - Owen ___ 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
That's the part of the user base that answers to polls in Google+. Right. That is why noone says use those answers from Google+ literally. It would be nice to find the way that would protect the results from the anti-geekness argument. But not having any survey results, making arbitrary decisions is even worse than making decisions based on Google+ surveys. ___ 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, 2012-04-25 at 14:32 +0100, Sergey Udaltsov wrote: What is being dropped is the ability to override that. That is exactly what that survey shown: people want to be able to override that. I don't think you can infer that from the answers. I'm one of the people who said they use Compose. I don't particularly care which key it is, as long as I can reach it without taking my hands away from home row. -- Shaun ___ 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 3:38 PM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: That's the part of the user base that answers to polls in Google+. Right. That is why noone says use those answers from Google+ literally. It would be nice to find the way that would protect the results from the anti-geekness argument. But not having any survey results, making arbitrary decisions is even worse than making decisions based on Google+ surveys. I cannot speak for the Design Team, but I'm pretty sure their decisions are not arbitrary. Xan ___ 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, 2012-04-25 at 09:28 -0400, Shaun McCance wrote: On Wed, 2012-04-25 at 14:22 +0100, Bastien Nocera wrote: snip The Compose key is defined in the layouts. What is being dropped is the ability to override that. I don't know of a physical keyboard layout that has a Compose key. So are we just deciding that one of the keys will always behave differently than the printed keycap? I suppose if you use a modifier key (R_Alt seems popular) then it can still function as a modifier as well as Compose, though that will interact poorly with sticky keys. The usual compose key for Western European keyboards is Alt-Gr. That's just one more data point to add to that whole list. ___ 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
I don't think you can infer that from the answers. I'm one of the people who said they use Compose. I don't particularly care which key it is, as long as I can reach it without taking my hands away from home row. Well, a number of people say they use Compose - a number of people say they map Compose to Menu, Capslock... ___ 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
I cannot speak for the Design Team, but I'm pretty sure their decisions are not arbitrary. My apologies, if the word arbitrary is offensive, I did not meant any offense. But without surveys, without explanation any filtering decision would be arbitrary by nature, right? Sergey ___ 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:43 PM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: I don't think you can infer that from the answers. I'm one of the people who said they use Compose. I don't particularly care which key it is, as long as I can reach it without taking my hands away from home row. Well, a number of people say they use Compose - a number of people say they map Compose to Menu, Capslock... Apologies, that page is a little out of date (my bad). We're currently aiming to have the compose key shortcut in the keyboard preferences, at least to begin with. I'm still keen to prioritise the 3rd level chooser, but I think we should probably move one step at a time. 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: IBus/XKB integration
Thank you Allan. It is always good to see that GNOME decision makers listen to users, really! Could you please list the options/groups that are currently going to be hidden as exotic/geekish? And, did you think about setting up the formal survey? Your idea to ask people was really good! On Wed, Apr 25, 2012 at 2:47 PM, Allan Day allanp...@gmail.com wrote: On Wed, Apr 25, 2012 at 2:43 PM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: I don't think you can infer that from the answers. I'm one of the people who said they use Compose. I don't particularly care which key it is, as long as I can reach it without taking my hands away from home row. Well, a number of people say they use Compose - a number of people say they map Compose to Menu, Capslock... Apologies, that page is a little out of date (my bad). We're currently aiming to have the compose key shortcut in the keyboard preferences, at least to begin with. I'm still keen to prioritise the 3rd level chooser, but I think we should probably move one step at a time. 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: Design in the open
So there are lots of ways that we can do design better as a community, and contributors on this list can all play a part in helping to make us to be even more successful in this regard. It will take actions as well as words to move forward, of course - if you want to help, or have your own ideas, just get in touch. Many of your suggestions seem designed to address or avoid conflict, or to convey design team decisions in a better manner. This is not the source of my confusion nor my uncertainty in how to interact with the design team. In order to piece together the rationale or even the process for design team decisions I currently browse commit logs on the gnome-design github repo, and look at comments made when changing live.gnome.org pages. Some of you tweet stuff, others scatter it on google+. You suggest even using $some_new_webapp to better collaborate on designs. While I cannot see the discussion and the evolution of design team thought (even if I have the time to piece together all these sources of information) all I see is a decision by decree when a live.gnome.org page is created which describes the final design. My suggestion is thus the same as it was the last time this thread was raised - if the design team does not want to archive discussions on a mailing list, may they please allow IRC logging on the gnome-design channel. You can even be proactive and send email updates to ddl or something. Of course if the canonical way to interact with the design is to show up on IRC at a specific hour then, IMO, you will lose contributors. I can hack any time of night when I have the motivation and the free time. But if I want to understand why the design team did something I have to... trust them? John ___ 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, 2012-04-25 at 09:37 -0400, Owen Taylor wrote: On Wed, 2012-04-25 at 11:10 +0100, Bastien Nocera wrote: On Wed, 2012-04-25 at 09:34 +0200, Rui Tiago Cação Matos wrote: On 24/04/2012, Owen Taylor otay...@redhat.com wrote: snip So, I don't think it really works to just ignore the group mechanism of XKB and always load a one-group layout... it makes more sense to me to identify what layouts are needed for all the input sources and load them into a single keymap ahead of time. Yes, that might limit the user to switching between 4 languages, but, really, how common is it to need more than that? Ok, that sounds like the best way forward then. And yes, I agree that users don't need to switch among more than 4 languages. The 4 layouts limit is an artificial limit that causes bug reports and raised eyebrows, and was one of the bugs that the ibus/xkb integration was supposed to fix. Missing out on it would be a great disappointment... But the main point of the exercise is to provide an integrated, well designed user interface for inputting languages with billions of users in total. Are people really reporting bugs because they need more than 4 layouts, or because the UI acts confusing when you try to add more than 4 layouts? It makes the UI confusing, and makes the whole system look antiquated. That means that the new system needs to work with the existing legacy system to remove those limitations, rather than provide a thin layer on top of the existing limitations. I don't see a problem adding a only the first 4 layouts are available to legacy applications message or something of that ilk. I'm sure we can engineer a solution to enable more than 4 layouts if that's really a requirement ... if nothing else, revise the XKB protocol. But let's not confuse that with the actual goal here. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal: Accessibility on by default
On Wed, 2012-04-25 at 13:12 +0200, Piñeiro wrote: On 04/25/2012 02:37 AM, Colin Walters wrote: As the plugin does not do anything when no AT is loaded, OK; that seems to be a relatively recent change (from my admittedly distant perspective). If that's true, and recently the primary cost of a11y has (at least in theory) been deferred to when an AT is loaded, then I'm totally in favor of this change. This change was made the last year. It started with this commit [1], that prevented to add event listeners if no AT is listening. This also includes the creation of the accessible objects or the message forwarding to DBUS. Additionally, one student was making some tests to check if this leads to a real improvement of the performance/memory consumption when accessibility is on but no accessibility technology is listening [2]. This change was made the last year, tested and debugged since then. I see, very nice work! Thanks for explaining this to me. ___ 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, 2012-04-25 at 14:50 +0100, Sergey Udaltsov wrote: snip And, did you think about setting up the formal survey? Your idea to ask people was really good! I think that our past experience with surveys done in the context of GNOME have shown that this sort of survey isn't useful. Asking people isn't about tallying who wants this option to stay, or absolutely needs the frobnicator to whirr clockwise, it's about defining requirements, and seeing how people use the current tools. Open questions are much more likely to bring in useful data for the design process than a survey ever would be. Taken to the extreme, as an example you'll be familiar with: if you asked how many people use more than 1 keyboard layout on a Russian Linux site, you'll get 90% positive responses. If you asked the same thing on a French end-user forum, you'd get close to zero, with none of them knowing what a compose key is, because it's just the Alt-Gr key. So any survey is likely to be biased, which makes surveys not so useful. Hopefully we can get Rui's code merged in early enough that we can catch most of the obvious problems before release, and work from there. ___ 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
Bastien Nocera wrote: I don't know of a physical keyboard layout that has a Compose key. So are we just deciding that one of the keys will always behave differently than the printed keycap? I suppose if you use a modifier key (R_Alt seems popular) then it can still function as a modifier as well as Compose, though that will interact poorly with sticky keys. The usual compose key for Western European keyboards is Alt-Gr. That's just one more data point to add to that whole list. On my totally standard french layout, AltGr is used to type the key ternary character; I just checked and setting it to be the Compose key breaks that access. Fred (using the right Ctrl key for Compose) ___ 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
I think that our past experience with surveys done in the context of GNOME have shown that this sort of survey isn't useful. How would you check the user's opinions then? To get some objective, measurable results, that would not depend on interpretation by biased (to non-geeks) decision makers? Taken to the extreme, as an example you'll be familiar with: if you Obviously, your survey results are only as good as your survey environment and audience. Does that mean that any effort in futile? So any survey is likely to be biased, which makes surveys not so useful. Sorry, I do not quite understand that remark. Are you saying there is 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? ___ 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 15:20, Frederic Peters fpet...@gnome.org wrote: Bastien Nocera wrote: I don't know of a physical keyboard layout that has a Compose key. So are we just deciding that one of the keys will always behave differently than the printed keycap? I suppose if you use a modifier key (R_Alt seems popular) then it can still function as a modifier as well as Compose, though that will interact poorly with sticky keys. The usual compose key for Western European keyboards is Alt-Gr. That's just one more data point to add to that whole list. On my totally standard french layout, AltGr is used to type the key ternary character; Same on my UK keyboard, where I use it quite a lot for | I just checked and setting it to be the Compose key breaks that access. Fred (using the right Ctrl key for Compose) rwin here :) ___ 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
Fred (using the right Ctrl key for Compose) rwin here :) So much for What is being dropped is the ability to override that. :) ___ 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, 2012-04-25 at 14:56 +0100, Bastien Nocera wrote: On Wed, 2012-04-25 at 09:37 -0400, Owen Taylor wrote: On Wed, 2012-04-25 at 11:10 +0100, Bastien Nocera wrote: On Wed, 2012-04-25 at 09:34 +0200, Rui Tiago Cação Matos wrote: On 24/04/2012, Owen Taylor otay...@redhat.com wrote: snip So, I don't think it really works to just ignore the group mechanism of XKB and always load a one-group layout... it makes more sense to me to identify what layouts are needed for all the input sources and load them into a single keymap ahead of time. Yes, that might limit the user to switching between 4 languages, but, really, how common is it to need more than that? Ok, that sounds like the best way forward then. And yes, I agree that users don't need to switch among more than 4 languages. The 4 layouts limit is an artificial limit that causes bug reports and raised eyebrows, and was one of the bugs that the ibus/xkb integration was supposed to fix. Missing out on it would be a great disappointment... But the main point of the exercise is to provide an integrated, well designed user interface for inputting languages with billions of users in total. Are people really reporting bugs because they need more than 4 layouts, or because the UI acts confusing when you try to add more than 4 layouts? It makes the UI confusing, and makes the whole system look antiquated. I have a hard time seeing how it makes the whole system look antiquated, unless you popped up a message containing the bit definitions from XKB.h. It's an artificial limitation, and artificial limitations make programmers sad, but... That means that the new system needs to work with the existing legacy system to remove those limitations, rather than provide a thin layer on top of the existing limitations. I don't see a problem adding a only the first 4 layouts are available to legacy applications message or something of that ilk. Isn't that a whole lot more confusing? Plus, do we have time in the 3.6 cycle to do a good job at inventing a replacement for non-legacy apps? Is that the best use of our resources? - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
Allan: I think it is pretty clear that the GNOME UX team is pretty amazing. As you say, though, I think we recognize that we need to improve in areas like engagement. With GUADEC around the corner, I think now is an important time to make progress on getting better engagement between the developer and usability communities within GNOME. Can we plan activities at GUADEC that could help? Aside from a BOF, I wonder if it might make sense to do some of the same sorts of activities that were done at the UX Hackfest in London. I think it would be interesting to do some usability testing while there, if it were possible to make that happen. Perhaps the next UX Hackfest could happen to coincide with GUADEC. Are plans being discussed on the usability mailing list? Are there any particular design-focused talks being planned? At the Desktop Summit in Berlin, it seemed a lot of talks were about basic design principles. Do you think we will be seeing that again, but perhaps more focused on GNOME 3? Brian On 04/25/12 08:27 AM, 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. Let’s start with the big picture - design is important for GNOME. Our project’s success rests upon our ability to design and execute an outstanding user experience. It is in all our interests to make GNOME design work, therefore - to work together to produce a consistent, integrated, well-defined, high-quality, delightful user experience. So far we have made some great progress in this direction. We have a small but thriving design community. We have successfully reorganised our development processes around design - development tends to be design led, and we now have new feature proposals each release rather than module proposals. There are very few, if any, real community projects that have achieved this feat. Members of other projects have even approached me in the past to ask how they can replicate GNOME’s success in this area. But there are challenges and things we can do better. Among those obstacles, I see: * lack of design resources - we are always trailing behind where we want to be, and there are important tasks which we are unable to complete (a new HIG springs to mind) * improving the quality of design - we can always do better * getting the project behind a common vision - we sometimes lack focus * 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 * helping community members to participate in design activities 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!) But there is more we can do. The challenge for us as a community is to make design an even more successful part of what we do. This isn’t an easy challenge and I don’t think there are any quick fixes, but we have experience and a rich community on our side. It is important to recognise that improving the state of design in GNOME isn’t just the responsibility of designers. There are things that all of us can do to help - from the release team and maintainers, to individual developers and community advocates. Here are some of my ideas for things that all of us can do to make design work more effectively and harmoniously as a part of GNOME: * a more rigorous (and better documented) feature proposal process * new tools for displaying and discussing designs, such as something like Dribble or Design Hub * a process for resolving design disagreements - perhaps maintainers or the release team could mediate if a dispute seems intractable? * better communications about where GNOME is going and what the project is trying to achieve * some kind of active community management role to help soothe ruffled feathers * advertised designer playgrounds and discussion areas (for people wanting to stretch their design wings) * tackle bad behaviour across the project in a more proactive manner (will ensure that disagreements don’t get out of hand) * micro release-cycles in which new features are advertised, completed and tested * better
Re: Design in the open
On Wed, Apr 25, 2012 at 9:55 AM, John Stowers john.stowers.li...@gmail.com wrote: So there are lots of ways that we can do design better as a community, and contributors on this list can all play a part in helping to make us to be even more successful in this regard. It will take actions as well as words to move forward, of course - if you want to help, or have your own ideas, just get in touch. Many of your suggestions seem designed to address or avoid conflict, or to convey design team decisions in a better manner. This is not the source of my confusion nor my uncertainty in how to interact with the design team. In order to piece together the rationale or even the process for design team decisions I currently browse commit logs on the gnome-design github repo, and look at comments made when changing live.gnome.org pages. Some of you tweet stuff, others scatter it on google+. You suggest even using $some_new_webapp to better collaborate on designs. While I cannot see the discussion and the evolution of design team thought (even if I have the time to piece together all these sources of information) all I see is a decision by decree when a live.gnome.org page is created which describes the final design. My suggestion is thus the same as it was the last time this thread was raised - if the design team does not want to archive discussions on a mailing list, may they please allow IRC logging on the gnome-design channel. I'm not sure how useful logging the channel will be (lots of noise, etc), but I'd be happy to give it a go. The main thing is that we shouldn't stop there. IRC logs aren't going to fix the whole gamut of challenges that we face in relation to community design. You can even be proactive and send email updates to ddl or something. I've lapsed in my design update blog posts, but I've got a new one in the works. You think emails would be better than blogging? Of course if the canonical way to interact with the design is to show up on IRC at a specific hour then, IMO, you will lose contributors. I can hack any time of night when I have the motivation and the free time. But if I want to understand why the design team did something I have to... trust them? Trust them, or ask them, or a combination of the two. (Trust comes best once you gain experience of working with people, of course.) 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: IBus/XKB integration
On Wed, 2012-04-25 at 16:00 +0100, Bastien Nocera wrote: Isn't that a whole lot more confusing? Plus, do we have time in the 3.6 cycle to do a good job at inventing a replacement for non-legacy apps? Is that the best use of our resources? That's an example. And from what I understood, given the need to mention the iBus chosen method through envvars system, I think we have part of the answer here. We're already effectively working on the non-legacy replacement. If I'm entering *text* into an text field, I need an input method If I'm pressing a hotkey, an accelerator, a mnemonic, etc, then input methods don't matter, and the toolkit needs to know something about the keyboard layout. (For example: there's no way that the code in gnome-settings-daemon can ever use an input method to figure out which keycode it needs to grab on the root window to implement a hotkey. And furthermore, if the user sets one of these hotkeys to Control-Alt-G, that hotkey can't stop working because the user switches to another layout without a G in it.) Just because we're using input methods now, doesn't mean that keyboard layout knowledge is legacy. So, if you declare XKB legacy, you need to invent something else. If somehow more than 4 keyboard layouts has become an essential feature, then I suspect the approach of filling the 4 XKB slots with: - The current layout - The layout for the UI language - The Latin layout - And one other layout Probably works close to OK. - Owen ___ 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, 2012-04-25 at 12:27 -0400, Owen Taylor wrote: On Wed, 2012-04-25 at 16:00 +0100, Bastien Nocera wrote: Isn't that a whole lot more confusing? Plus, do we have time in the 3.6 cycle to do a good job at inventing a replacement for non-legacy apps? Is that the best use of our resources? That's an example. And from what I understood, given the need to mention the iBus chosen method through envvars system, I think we have part of the answer here. We're already effectively working on the non-legacy replacement. If I'm entering *text* into an text field, I need an input method If I'm pressing a hotkey, an accelerator, a mnemonic, etc, then input methods don't matter, and the toolkit needs to know something about the keyboard layout. snip interesting technical details I'll rephrase what I was saying, because I don't think it's really come through. I don't care about implementation details. I care that there's a hard-coded limit that shouldn't be there, and that we're working on removing that barrier (hopefully). Calling anything that wouldn't work with whatever work-arounds we might come up with is what I call legacy. I'm fine with the idea that some applications that use other toolkits, or frameworks might not work as well, because the user has been warned. And that's a better way to do things than restrict the user with no good way of informing them about limits. ___ 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
Why did I write that mail? First of all, I'm very sorry for doing precisely what I was trying to prevent - alienating people. I wrote that mail in anger, always a bad idea. I owe everyone, and especially the design team, an explanation. In Gnome we are going through a period where there is a important group of developers that feel disenfranchised. These are not people on the fringe of Gnome, but hackers close to the core. We have been in a similar situation before. Not all of the people to whom I referred indirectly in my other mail were around at that time, so allow me to tell that story. The beginning of the Gnome 2.x series was a very painful time. The major companies involved in Gnome were in vicious competition, with everyone blaming the others for trying to gain control of Gnome. The first rounds of usability testing had happened late in the Gnome 1.x series, and everyone was starting to understand what easy to use software really meant. We had to kill or rewrite a lot of code from Gnome 1.x to achieve a simpler and more coherent system. Things just didn't work very well during the first Gnome 2.x releases. A big meme at that time was that software needed to be as simple as possible in its presentation to the user - as few options and commands as possible, and everything simplified so that beginners would not get confused. People wrote very enlightening essays about the virtues of simple user interfaces. We had a rather new Human Interface Guidelines document, which could be used as a reference for keeping things consistent (12 pixel spacing between widgets; such and such capitalization for menu items). We made Gnome 2.x work well; it was simple to use, the UI looked clean, and developers successfully internalized many of the ideas that we had struggled to push through earlier. It was a great victory to see that throughout Gnome, instead of random hacking we had people basing every decision on whether the resulting software would be consistent and easy to use. And then, people wanted to take Gnome further: add more functionality to existing software; integrate new things into the core; make things more complex but with good reason. However, the keep things simple and stable meme got taken too far. Proposals to add functionality got shot down. Modules couldn't be integrated. In trying to keep things simple and stable, and in trying to polish existing things rather than creating new ones, a loose and small group of people were inadvertently alienating those who wanted to do new kinds of development in Gnome. There was a lot of discomfort because Gnome seemed stagnant. Someone came up with the term UI Nazis and it stuck, Godwin's Law and all. Things got near to the breaking point when Nat Friedman gave a keynote address during GUADEC 2004, titled Swinging the Pendulum. You can see it at http://nat.org/NatFriedman-GUADEC-5-Pendulum.sxi One of the main points of Nat's talk was that we were at a point where Gnome was ignoring innovation for fear of losing simplicity. His presentation had a section called barriers to hacking, where he had items like lack of tools, but also items like lack of community, embarrassment (because your work is not seen as good enough), humiliation (because you get told that you are not up to Gnome's standards), and ridicule (you think *that* is a good UI? It doesn't even follow the HIG!). There is a big slide in that talk that says, We need the cultural freedom to innovate. From what I've seen happen since the start of Gnome 3, we are at a similar period right now, where groups of Gnome developers are in discomfort because the dynamics of the project are working against them. You could say that in Gnome 2 our meme was, keep things simple for the user, and in Gnome 3 our meme is, design first, then develop. BOTH ARE GOOD THINGS TO DO! The problem is when you do too much of each. We tried to keep things *too* simple, so we couldn't innovate. Now that design is at the forefront, we have these happening: * People feel like the design team has to give them permission to write things. * People feel like they can't come up with (visual/interaction) designs on their own because it is the design team that does that. * People write well-reasoned emails explaining things, and apologize at the end with ... but I'm not a designer.. * The feature proposal process is vague. We had a module proposal process that is not ideal for everything (especially horizontal changes that involve many modules), but at least there was a clear way to get a new module integrated. And the thing is, THE DESIGN TEAM DID NOT INTEND FOR ANY OF THIS TO HAPPEN! During Gnome 2, we had many of the top-tier hackers simply leave the project, one by one, because they got tired about all the bickering. They now contribute elsewhere where they don't have to bicker as much. I don't want to have situation in Gnome 3 where we lose good hackers due to the current situation.
Re: Design in the open
On Wed, April 25, 2012 9:27 am, Allan Day wrote: Echoing what Brian said, I like these suggestions for improvement! Are there any that we can turn into concrete initiatives that we can organize soon and perhaps fundraise for? Or build some initiatives for GUADEC? I include a few more detailed questions below along these lines. It is important to recognise that improving the state of design in GNOME isnt just the responsibility of designers. There are things that all of us can do to help - from the release team and maintainers, to individual developers and community advocates. Here are some of my ideas for things that all of us can do to make design work more effectively and harmoniously as a part of GNOME: * a more rigorous (and better documented) feature proposal process I think there's some confusion here - you're not talking about purely technical proposals here too, are you? I assume this is more focused on anything that interfaces with any elements of design... * new tools for displaying and discussing designs, such as something like Dribble or Design Hub * a process for resolving design disagreements - perhaps maintainers or the release team could mediate if a dispute seems intractable? I think we should definitely explore this more, it goes hand in hand with the other suggestions below - helping to stop bad behavior, soothing ruffled feathers and communicating better. * better communications about where GNOME is going and what the project is trying to achieve * some kind of active community management role to help soothe ruffled feathers * advertised designer playgrounds and discussion areas (for people wanting to stretch their design wings) * tackle bad behaviour across the project in a more proactive manner (will ensure that disagreements dont get out of hand) * micro release-cycles in which new features are advertised, completed and tested * better testing facilities so people can test and give feedback on UX changes before release time What would this entail? This sounds like it could be incredibly helpful if we could find the resources for it. * keep a running list of design tasks that are appropriate for newcomers * work to prevent design disputes - ensure early informal contact between designers and developers at the beginning of feature initiatives So there are lots of ways that we can do design better as a community, and contributors on this list can all play a part in helping to make us to be even more successful in this regard. It will take actions as well as words to move forward, of course - if you want to help, or have your own ideas, just get in touch. thanks, Allan! I'm glad we're having these discussions and hope that we can find ways for the Foundation to help too. karen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
I am happy Allan drafted the problem thoroughly and and also provided initial steps that could solve it. Well done. On Wed, Apr 25, 2012 at 7:45 PM, Karen Sandler ka...@gnome.org wrote: On Wed, April 25, 2012 9:27 am, Allan Day wrote: Echoing what Brian said, I like these suggestions for improvement! Are there any that we can turn into concrete initiatives that we can organize soon and perhaps fundraise for? Or build some initiatives for GUADEC? I include a few more detailed questions below along these lines. It is important to recognise that improving the state of design in GNOME isn’t just the responsibility of designers. There are things that all of us can do to help - from the release team and maintainers, to individual developers and community advocates. Here are some of my ideas for things that all of us can do to make design work more effectively and harmoniously as a part of GNOME: * a more rigorous (and better documented) feature proposal process I think there's some confusion here - you're not talking about purely technical proposals here too, are you? I assume this is more focused on anything that interfaces with any elements of design... I think Karen raises a good point here. I think there should be 2 kind of proposals. - A feature proposal: Where a feature is discussed and the technologies needed for it are decided, if the design team thinks the feature is not good then an detailed explanation would help. Also if the feature is a not accepted then there is no need to discuss the technology. - A technical proposal: Where libraries or services that could optimize performance/maintenance or prove to be beneficial in the future for existing modules can be suggested to be used. Technical proposals should not include any features, else it is a feature proposal. * new tools for displaying and discussing designs, such as something like Dribble or Design Hub * a process for resolving design disagreements - perhaps maintainers or the release team could mediate if a dispute seems intractable? I think we should definitely explore this more, it goes hand in hand with the other suggestions below - helping to stop bad behavior, soothing ruffled feathers and communicating better. * better communications about where GNOME is going and what the project is trying to achieve * some kind of active community management role to help soothe ruffled feathers I would like to propose that we contact the people at KDE, since they already formed a community task force that manages and handles day to day disputes and work on improving communication in the community in a professional manner. AFAIK (I might be mistaken) they were given some negotiation seminar during DS 2011. * advertised designer playgrounds and discussion areas (for people wanting to stretch their design wings) * tackle bad behaviour across the project in a more proactive manner (will ensure that disagreements don’t get out of hand) * micro release-cycles in which new features are advertised, completed and tested * better testing facilities so people can test and give feedback on UX changes before release time What would this entail? This sounds like it could be incredibly helpful if we could find the resources for it. * keep a running list of design tasks that are appropriate for newcomers * work to prevent design disputes - ensure early informal contact between designers and developers at the beginning of feature initiatives So there are lots of ways that we can do design better as a community, and contributors on this list can all play a part in helping to make us to be even more successful in this regard. It will take actions as well as words to move forward, of course - if you want to help, or have your own ideas, just get in touch. thanks, Allan! I'm glad we're having these discussions and hope that we can find ways for the Foundation to help too. karen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list Thanks Allan for taking the time to detail the problem as much as possible. It is nice to have this discussion going in a peaceful manner. Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
3.6 Feature: User panel improvements
This feature was originally targeted for 3.4, but didn't make it. Initially, it was only about making the user panel aware of Kerberos identities, and handling ticket expiration. It has grown in scope, as we are now also aiming for nicely integrated AD/LDAP enrollment. Thus, the title is a bit of a misnomer now. This mainly affects the user panel in the control center (where we want to show suitable things when we find ourselves in a centrally managed system), gnome-settings-daemon (which will grow a plugin to ask for passwords if a ticket expires and can't be automatically renewed) as well as gdm and the proposed initial-setup tool. You can read more details here: https://live.gnome.org/ThreePointFive/Features/UserPanel Ray Strode and Stef Walter are working on this. ___ 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, 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. However, even the geeky survey is useful to know what multilingual, touch-typey, have-to-write-a-lot people need in order to make things bearable. Some anecdotal data points: - In Mexico, (Windows) computers get shipped with a Latin American keyboard configuration. Most of the time, what you see on keys is what gets put on the screen - but not always. - People never know how to type @. Mostly everyone learns that AltGr-Q will do the trick, but if it's not that, they'll resort to cutting and pasting that single symbol from elsewhere. - No one has any idea that a character map program exists. When you show it to them, they understandably react like you opened a treasure chest and gave it to them. - My wife has learned the position of the third-level chooser key on her Mac laptop, and also the Compose key there. She has tons of trouble every time she has to use *my* laptop, as it uses AltGr, which is not on the same position as the Mac's key. I have tons of trouble when using *her* laptop, as I can never remember if that key is the one to the left of the cloverleaf key or two apart (AFAICT this key doesn't have a label that indicates this is the key you use to type characters not present in the keyboard labels). (If my wife has to use my laptop and it happens to be in the English keyboard layout (which I use for programming), she has to ask me to change the layout to Latin American, which is the one she knows.) I *think* touch typists and hunt-and-peck typists suffer in equal amounts with keyboard layouts, just in different ways :) Federico ___ 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
Will probably regret writing this email, but here it goes, anyway. On Wed, Apr 25, 2012 at 11:09 AM, Federico Mena Quintero feder...@gnome.org wrote: One of the main points of Nat's talk was that we were at a point where Gnome was ignoring innovation for fear of losing simplicity. His presentation had a section called barriers to hacking, where he had items like lack of tools, but also items like lack of community, embarrassment (because your work is not seen as good enough), humiliation (because you get told that you are not up to Gnome's standards), and ridicule (you think *that* is a good UI? It doesn't even follow the HIG!). There is a big slide in that talk that says, We need the cultural freedom to innovate. From what I've seen happen since the start of Gnome 3, we are at a similar period right now, where groups of Gnome developers are in discomfort because the dynamics of the project are working against them. On the topic of history, I think that we can say with hindsight that the later days of GNOME 2's lifespan (and the disjointed OS/tech stack underneath it) cannot be held on a pedestal. We were handed a golden market opportunity on a silver platter in the form of netbooks from ISV's who actively sought *us* out, went about shipping, and offered support for GNOME pre-installed on them--well in advance of the march of the Tablet Empire. Just think about all of the thousands of people in the supply chain from multiple vendors that were required to make that happen and then think about trying to pull that off again. I hope that you feel that our failure there was a tragedy. The market flat-out rejected what we had to offer. Sure, any module proposal could get accepted in to GNOME at that time but to what end? Technology that a user or a platform developer cannot use because it isn't usable isn't technology at all: it's techurbation. But there is, as there always has been, a way forward: the people who have a passion for a technology that they have brought in to this world obviously envision a way for it to become accessible to users. I know that you and Seif have that vision: I saw your presentation on Journal at the 2008 Hackfest and thought to myself, Fuck, yes! We *can* get there and indeed I have watched multiple threads over the past four years on this and related desktop activity logs topics propose ways forward. What I have seen from the outside, though, is that the discussions always fizzled with disagreement. 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. (My views do not in any way represent those of Google.) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Seif Lotfy wrote: So I would still like to have my question answered. How is the policy on using Zeitgeist for non-feature and non-UX related optimization and maintenance distribution? Do note this was not discussed by the release team, we'll have a meeting soon and we can add that to the agenda if you want an official answer, but in my opinion there is no problem if a maintainer wants to use zeitgeist because it helps in whatever s/he is coding. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Tentative feature: Custom activities
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. Here's the history as I see it: 1. Past shells have taken no interest in what the user is trying to achieve - their intent. Instead they provided a heap of tools (window lists, application switchers, virtual desktops, etc) and the user just made whatever use they wanted of these. 2. This was ok for users with only one intent (call it use computer,) i.e. the people who often only have one application running, and whose projects are rarely more than a couple of files. The only real problem for these people was in the initial learning curve: for example, learning the difference between a file and that same file open in an application. 3. For advanced users, with many intents (personal stuff, media, work stuff, projectx, projecty...) , it was manageable but imperfect: some applications provided profile support, some didn't; the shell wouldn't know how to open a file in the right app instance anyway, or which browser instance a link was meant for, and so on. Each user developed their own system for separating their concerns, based on whatever their shell and apps happened to support. 4. Then Android et al. arrived, with the principle that the user _must_ only have one intent. This simplified model removed the learning curve: there was no longer a difference between a file and the app that displayed it, or an app and an instance of it. It also made it impossible to divide web browsing between personal and work; prevented using the same tool with different settings for different tasks; discouraged using multiple applications together; and generally made the user reliant on app developers anticipating their exact needs. I worry a little that Gnome is drifting too far towards the Android mode. The idea that a tool and task are interchangeable makes no sense to me: My intents are not 1:1 aligned with the tools I use, so I will always need to combine tools. This means lots of running apps, lots of visible windows, lots of terminals, and lots of switching. I think it may be possible to reach a compromise - bring more facilities to application developers to help them make standardised applications, (and so let them hand off common tasks to the system,) while not removing too many possibilities for the user. This is the briefest possible outline of my idea: 1. Make the idea of intent explicit in the shell. An intent is a set of application instances and application profiles, a history of actions, a bunch of files, and anything else required to create a loose boundary around some part of the user's world. 2. Give each user a default intent, and leave them to discover they can have more when they are ready. While intent makes sense logically, it's a rather cumbersome expression, so I propose referring to them as custom activities. The Activities button in the shell could then be re-purposed, with the current view relating to the default activity, and more controls being added to create and manage custom activities. Most of the UI would be unchanged - starting an app or choosing a virtual desktop is applicable in any activity. Required changes would include adding controls to change focused activity, and to see what customisations exist in the current activitity; an example optional change would be to highlight which current windows are associated with the activity. Some users will never need to know about custom activities, they will just get a simple, Android-esque shell, where every time they click the browser icon they get their single browser instance, and their music collection is the same thing as their music player. The rest of us get that same thing, multiplied as many times as we want it. We get the advantages of a rigid application model, such as automatic suspending of applications (done with work for the day? just close that activity, it can be exactly restored tomorrow,) but infinitely many times. The job of the shell would be to help the user attach things to their activities. Application instances could be attached, perhaps by dragging their icon into a group on the dash. Files in projectx's file browser instance will open in the projectx text editor instance, and those files can be marked as related to projectx, and their use logged as such to help the user find them later. Of course the shell won't always get this right, so there's no question that the user must have final say. It should be possible for the user to examine their custom activities, assign files to them, control which applications have custom settings within the intent, and so on. I think this could work, but maybe it would be impractical to implement, or too complex to use. Regardless, the important thing I want to
Re: Design in the open
On Wed, Apr 25, 2012 at 6:45 PM, Karen Sandler ka...@gnome.org wrote: On Wed, April 25, 2012 9:27 am, Allan Day wrote: Echoing what Brian said, I like these suggestions for improvement! Are there any that we can turn into concrete initiatives that we can organize soon and perhaps fundraise for? Or build some initiatives for GUADEC? I include a few more detailed questions below along these lines. It'd be great to have a BoF on design at GUADEC. I'm not sure what availability would be like for doing a UX hackfest there, but we could certainly look into that. It is important to recognise that improving the state of design in GNOME isn’t just the responsibility of designers. There are things that all of us can do to help - from the release team and maintainers, to individual developers and community advocates. Here are some of my ideas for things that all of us can do to make design work more effectively and harmoniously as a part of GNOME: * a more rigorous (and better documented) feature proposal process I think there's some confusion here - you're not talking about purely technical proposals here too, are you? I assume this is more focused on anything that interfaces with any elements of design... Feature proposals aren't supposed to be purely technical, if my understanding is correct - they should always have user-facing value (whether we should have separate technical feature proposals is a separate issue in my opinion). As such they are a natural channel through which the community can participate in design activities. * new tools for displaying and discussing designs, such as something like Dribble or Design Hub * a process for resolving design disagreements - perhaps maintainers or the release team could mediate if a dispute seems intractable? I think we should definitely explore this more, it goes hand in hand with the other suggestions below - helping to stop bad behavior, soothing ruffled feathers and communicating better. Absolutely - it would be great if someone wanted to do some work there. * better communications about where GNOME is going and what the project is trying to achieve * some kind of active community management role to help soothe ruffled feathers * advertised designer playgrounds and discussion areas (for people wanting to stretch their design wings) * tackle bad behaviour across the project in a more proactive manner (will ensure that disagreements don’t get out of hand) * micro release-cycles in which new features are advertised, completed and tested * better testing facilities so people can test and give feedback on UX changes before release time What would this entail? This sounds like it could be incredibly helpful if we could find the resources for it. There are already initiatives that are pursing this, I'm happy to say - both in the form of a new testing framework [1] and a role for testing within the release process [2]. * keep a running list of design tasks that are appropriate for newcomers * work to prevent design disputes - ensure early informal contact between designers and developers at the beginning of feature initiatives So there are lots of ways that we can do design better as a community, and contributors on this list can all play a part in helping to make us to be even more successful in this regard. It will take actions as well as words to move forward, of course - if you want to help, or have your own ideas, just get in touch. thanks, Allan! I'm glad we're having these discussions and hope that we can find ways for the Foundation to help too. Me too. :) Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Wed, 2012-04-25 at 22:36 +0200, Frederic Peters wrote: Seif Lotfy wrote: So I would still like to have my question answered. How is the policy on using Zeitgeist for non-feature and non-UX related optimization and maintenance distribution? Do note this was not discussed by the release team, we'll have a meeting soon and we can add that to the agenda if you want an official answer, but in my opinion there is no problem if a maintainer wants to use zeitgeist because it helps in whatever s/he is coding. As an example, Seif has asked me to clarify that libfolks is happy to have Zeitgeist as a hard dependency if other core modules also have Zeitgeist as a hard dependency. In the meantime, we plan to have Zeitgeist as a soft dependency (just like most of our other dependencies) since it isn't used for too much in folks at the moment, and it's another thing which people would otherwise be forced to build before they could build folks for themselves. See https://bugzilla.gnome.org/show_bug.cgi?id=672709 for details on Zeitgeist + folks. Philip Fred ___ 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: Design in the open
On Wed, Apr 25, 2012 at 10:21 PM, Allan Day allanp...@gmail.com wrote: ... * better testing facilities so people can test and give feedback on UX changes before release time What would this entail? This sounds like it could be incredibly helpful if we could find the resources for it. There are already initiatives that are pursing this, I'm happy to say - both in the form of a new testing framework [1] and a role for testing within the release process [2]. Missing footnotes: [1] https://live.gnome.org/GnomeOS/Testable [2] https://mail.gnome.org/archives/desktop-devel-list/2012-March/msg00094.html - I realise now that the timing of these live images won't actually help with testing UX changes (since we'll already be in UI freeze when they're ready) - that's maybe something to look at if and when we have the necessary tools ___ 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 25/04/12 15:27, Allan Day wrote: * lack of design resources - we are always trailing behind where we want to be, and there are important tasks which we are unable to complete (a new HIG springs to mind) Caused by this, the design process in GNOME might be often shallow, based on static mockups, sparsely documented, and lacking enough justification and evaluation *before* the proposed changes get committed to code. Mistakes in design happen. This is just a natural part of the work and not bad in itself (fail early and fail often). However, in GNOME some of those problems in the original designs might take a long time to be detected, acknowledged and fixed. By the time an alternative proposal can be implemented, it has to go against the existing (published) behaviour and deal with a code base that was written to enable the old solution (scar tissue, as Cooper calls it). GNOME has very ambitious goals: to create an environment that works on tablets and desktops, along with ~20 core applications. This is not an easy task at all, and we only have a very small group of professional designers to work on it. There might be a mismatch between our current resources and goals. Maybe we need to scale either, or both, so that GNOME designers can focus much more in solving each problem better. Felipe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk+YdtAACgkQ3e5RNKzod9ft3ACfVAUusg0BFBRolyncoagrtXji wmMAn2eoPb1tT9JmS2/3XYTSy3qBz3YX =T4NI -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Wed, 2012-04-25 at 22:36 +0200, Frederic Peters wrote: Seif Lotfy wrote: So I would still like to have my question answered. How is the policy on using Zeitgeist for non-feature and non-UX related optimization and maintenance distribution? Do note this was not discussed by the release team, we'll have a meeting soon and we can add that to the agenda if you want an official answer, but in my opinion there is no problem if a maintainer wants to use zeitgeist because it helps in whatever s/he is coding. As a data point, I have a branch in Yelp where I'm using Zeitgeist. I want to use it to reorder search results based on frequency. of access. At the moment, the branch is reporting to Zeitgeist, and it's adding links to often viewed with pages alongside the more about and see also links. (That bit is sort of an experiment. Time will tell how useful it is.) It's not entirely clear to me what the process would be for me to propose merging this to master, especially given that there's an existing module proposal for Zeitgeist. Though I wasn't going to worry about that anyway until I had the search result reordering working. (I'd rather discuss code than ideas.) I also have a long-term, wishful thinking goal of being able to collect usage data for Yelp. I still have to figure out how I can do this without violating privacy, but Zeitgeist already collects exactly the information I would want reported. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Feature Unproposal: Dynamic Help Menus
I notice the feature page for dynamic help menus in 3.4 has been migrated to the 3.6 features: https://live.gnome.org/ThreePointFive/Features/HelpMenus I'm officially unproposing this for 3.6. It would take a lot of time to redo my implementation for changes in our platform and in our application designs, and I'm just not going to have very much time to devote to GNOME development this cycle. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
3.6 Feature: Lock Screen
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 A notification settings panel will need to be added to System Settings to allow the user to specify if either an indication that there are notification or the notifications themselves should be displayed in the lock screen mode. The design for the panel is available here: https://live.gnome.org/Design/SystemSettings/Notifications 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. The lock screen will be displayed within the same user session to enable the display of notifications. The lock screen will communicate with GDM via DBus to get authentication results. The look of the login screen will be changed too to have both look the same. The login screen is already implemented as part of the GNOME Shell code, and the common components will be shared, where possible. The feature page is here: https://live.gnome.org/ThreePointFive/Features/ScreenLock Giovanni Campagna, who will be working on this as his GSoC project, and I will be the main developers. Ray Strode will be helping us along by lending his GDM expertise. Thanks, Marina ___ 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
if we could find the resources for it. There are already initiatives that are pursing this, I'm happy to say - both in the form of a new testing framework [1] and a role for testing within the release process [2]. * keep a running list of design tasks that are appropriate for newcomers * work to prevent design disputes - ensure early informal contact between designers and developers at the beginning of feature initiatives So there are lots of ways that we can do design better as a community, and contributors on this list can all play a part in helping to make us to be even more successful in this regard. It will take actions as well as words to move forward, of course - if you want to help, or have your own ideas, just get in touch. thanks, Allan! I'm glad we're having these discussions and hope that we can find ways for the Foundation to help too. Me too. :) Allan -- Message: 2 Date: Wed, 25 Apr 2012 22:21:47 +0100 From: Philip Withnall phi...@tecnocode.co.uk To: desktop-devel-list@gnome.org Subject: Re: Module Proposal: Zeitgeist Message-ID: 4f986aed.e249b40a.0415.6...@mx.google.com Content-Type: text/plain; charset=utf-8 On Wed, 2012-04-25 at 22:36 +0200, Frederic Peters wrote: Seif Lotfy wrote: So I would still like to have my question answered. How is the policy on using Zeitgeist for non-feature and non-UX related optimization and maintenance distribution? Do note this was not discussed by the release team, we'll have a meeting soon and we can add that to the agenda if you want an official answer, but in my opinion there is no problem if a maintainer wants to use zeitgeist because it helps in whatever s/he is coding. As an example, Seif has asked me to clarify that libfolks is happy to have Zeitgeist as a hard dependency if other core modules also have Zeitgeist as a hard dependency. In the meantime, we plan to have Zeitgeist as a soft dependency (just like most of our other dependencies) since it isn't used for too much in folks at the moment, and it's another thing which people would otherwise be forced to build before they could build folks for themselves. See https://bugzilla.gnome.org/show_bug.cgi?id=672709 for details on Zeitgeist + folks. Philip Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message part URL: http://mail.gnome.org/archives/desktop-devel-list/attachments/20120425/0a842a97/attachment.bin -- Message: 3 Date: Wed, 25 Apr 2012 22:36:23 +0100 From: Allan Day allanp...@gmail.com To: desktop-devel-list desktop-devel-list@gnome.org Subject: Re: Design in the open Message-ID: cac_wn4t8h3jawrhdz+3xuf0lkvufm1i+vyhktzmc+n9v5tq...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 25, 2012 at 10:21 PM, Allan Day allanp...@gmail.com wrote: ... * better testing facilities so people can test and give feedback on UX changes before release time What would this entail? This sounds like it could be incredibly helpful if we could find the resources for it. There are already initiatives that are pursing this, I'm happy to say - both in the form of a new testing framework [1] and a role for testing within the release process [2]. Missing footnotes: [1] https://live.gnome.org/GnomeOS/Testable [2] https://mail.gnome.org/archives/desktop-devel-list/2012-March/msg00094.html - I realise now that the timing of these live images won't actually help with testing UX changes (since we'll already be in UI freeze when they're ready) - that's maybe something to look at if and when we have the necessary tools -- Message: 4 Date: Thu, 26 Apr 2012 00:12:48 +0200 From: Felipe Erias Morandeira femorande...@igalia.com To: desktop-devel-list@gnome.org Subject: Re: Design in the open Message-ID: 4f9876e0.5000...@igalia.com Content-Type: text/plain; charset=windows-1252 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/04/12 15:27, Allan Day wrote: * lack of design resources - we are always trailing behind where we want to be, and there are important tasks which we are unable to complete (a new HIG springs to mind) Caused by this, the design process in GNOME might be often shallow, based on static mockups, sparsely documented, and lacking enough justification and evaluation *before* the proposed changes get committed to code. Mistakes in design happen. This is just a natural part of the work and not bad in itself (fail early and fail often). However, in GNOME some of those problems in the original designs might take
Re: 3.6 Feature: Lock Screen
On 25 April 2012 18:38, Marina Zhurakhinskaya mari...@redhat.com 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. The lock screen will be displayed within the same user session to enable the display of notifications. The lock screen will communicate with GDM via DBus to get authentication results. The look of the login screen will be changed too to have both look the same. The login screen is already implemented as part of the GNOME Shell code, and the common components will be shared, where possible. When you say gnome-screensaver will no longer be used, what is your plan for GNOME Fallback users? Also, have you thought about how this would work for GNOME Shell users who happen to use LightDM or KDM or something else? And I wonder how this will affect Unity and Ubuntu 12.10. There's an Ubuntu goal to use LightDM for handling the lock screen but I don't know the technical details with that (whether it still needed gnome-screensaver or not). I guess the bigger question is are you really trying to deprecate and abandon gnome-screensaver in 5 months or did I misunderstand? Jeremy ___ 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 - 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? 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
Re: 3.6 Feature: Lock Screen
On Wed, Apr 25, 2012 at 8:04 PM, Shaun McCance sha...@gnome.org 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. I also think these designs are great. This will be a really nice feature, but Shaun is right about the accessibility concerns. If keyboard-only use can be added, I think the feature would be a big +1. Meg Ford How is the PIN supposed to be set? Will that involve changes to the User Accounts panel? 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 ___ 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, 2012-04-25 at 15:20 +0100, Bastien Nocera wrote: On Wed, 2012-04-25 at 14:50 +0100, Sergey Udaltsov wrote: snip And, did you think about setting up the formal survey? Your idea to ask people was really good! I think that our past experience with surveys done in the context of GNOME have shown that this sort of survey isn't useful. Asking people isn't about tallying who wants this option to stay, or absolutely needs the frobnicator to whirr clockwise, it's about defining requirements, and seeing how people use the current tools. Open questions are much more likely to bring in useful data for the design process than a survey ever would be. Taken to the extreme, as an example you'll be familiar with: if you asked how many people use more than 1 keyboard layout on a Russian Linux site, you'll get 90% positive responses. If you asked the same thing on a French end-user forum, you'd get close to zero, with none of them knowing what a compose key is, because it's just the Alt-Gr key. So any survey is likely to be biased, which makes surveys not so useful. Hopefully we can get Rui's code merged in early enough that we can catch most of the obvious problems before release, and work from there. Wait - aren't compose key and Alt-Gr 2 keys? I thought the compose key is the one used with XCompose used by 'geeks' to have various symbols such as γ or ∈. Alt-Gr (at least the key marked as Alt-Gr) uses alternative keys in layout for example ą, ę (this can be overriden by xmodmap). Best regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
