Re: on application focus navigation (was: On ctrl-tab)
On Wed, Nov 25, 2009 at 3:22 PM, Jud Craft wrote: > Use ctrl-tab repeatedly in Gedit. You can exit the text entry, you > can enter the toolbar. You can move through any toolbar button. But > when you reach the last one, you cannot leave the toolbar with > ctrl-tab. > > So, from what you're telling me, I deduce that > > 1. The text entry only lets you -enter- it with Tab, not ctrl-tab. > If this is indeed the case, I have many thoughts. > > 2. Gedit's toolbar is messed up. > This is a side-effect of gedit disagreeing with the GTK key handling model, and doing its own thing. See gedit_window_key_press_event for details. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: on application focus navigation (was: On ctrl-tab)
On 25 Nov 2009, at 19:32, Jud Craft wrote: > So, if you don't mind my asking -- where exactly is the canonical > reference for GNOME GUI design? I assume you mean the GNOME HCI > Guidelines 2.2 are unmaintained? Or is it just kind of touch-and-go? Well, "unmaintained" suggests nobody's looking after it at all, which isn't strictly true. We do still look at the bugs that come in, but it's true we don't fix very many of them in the stable version of the HIG. With GNOME 3.0 looming ever larger, I'd rather we devoted our efforts to taking a step back and producing a new set of UI design documents from the ground up. Cheeri, Calum. -- CALUM BENSON, Interaction Designer Sun Microsystems Ireland mailto:calum.ben...@sun.comOpenSolaris Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: on application focus navigation (was: On ctrl-tab)
On 25 Nov 2009, at 18:09, Jud Craft wrote: > On Wed, Nov 25, 2009 at 12:58 PM, Andre Klapper wrote: >> http://bugzilla.gnome.org/enter_bug.cgi?product=HIG > > Ah. I formerly heard to try against GTK. I'll need to do some bug > changes, but I don't see much use in a user filing a problem with the > HIG. Is that even a good idea? Since most keyboard navigation is implemented at the toolkit level, it's not really discussed in the HIG, so it probably won't get a lot of traction there. To be honest, you might be better having this discussion over on the gnome-accessibility-list, as there's a lot of people over there who rely on good keynav to use GNOME at all, and who would certainly need to approve any changes in this area. Cheeri, Calum. -- CALUM BENSON, Interaction Designer Sun Microsystems Ireland mailto:calum.ben...@sun.comOpenSolaris Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: on application focus navigation (was: On ctrl-tab)
On Wed, Nov 25, 2009 at 3:22 PM, Jud Craft wrote: >> Unless you invent a keyboard that has reserved keys for focus >> navigation, there will always be conflicts. > > GNOME has one. It uses ctrl-tab as the focus-nav shortcut to avoid > conflicts. It should be used more consistently, unlike in Gedit > (can't leave toolbar) and Rhythmbox (can't navigate toolbar). If you pay attention to where this discussion started, you will see that that is not the case. The starting point was a request to increase conflicting uses of Ctrl-Tab... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gst-devel] Video Hackfest conclusions
On 11/25/2009 05:56 AM, Farkas Levente wrote: thanks for the conclusion. one thing which would be very useful (for me and may be others). Fedora/Ubuntu is a very fast moving target, but i understood it as a good target for gstreamer. although some people (like me) would like to use a more robust os like rhel/centos. but currently it's not possible to update gstreamer to newer version on rhel/centos since gstreamer depend on glib/gtk which is too old in rhel for newer gstreamer. as (probably) rhel-6 will be out in 2010 it means that version of glib/gtk/cairo which will be in rhel-6 will remain for many years in the rhel/centos-6. so if i dare to ask that gtk/glib/cairo version in rhel-6 should have to enough for these features. ie. rise the required gtk/glib/cairo version in the current gstreamer to be enough for later version. otherwise these features can't be used in rhel-6 for many years. thanks in advance. As far as I know RHEL6 will be based on Fedora 12 which was released a few days ago. behdad regards. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: on application focus navigation
On 11/25/2009 02:32 PM, Jud Craft wrote: So, if you don't mind my asking -- where exactly is the canonical reference for GNOME GUI design? I assume you mean the GNOME HCI Guidelines 2.2 are unmaintained? Or is it just kind of touch-and-go? I don't know. I don't hack on any GUI. I hope would answer this though. behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Branch notifications
On Wed, 2009-11-25 at 14:26 -0600, Shaun McCance wrote: > On Thu, 2009-11-26 at 07:03 +1100, Danielle Madeley wrote: > > On Wed, 2009-11-25 at 13:03 -0600, Shaun McCance wrote: > > > > > The only potential problem is that the emails come from your username > > > @src.gnome.org. I know sha...@gnome.org gets to my inbox, and I think > > > sha...@src.gnome.org does as well. But do we have proper aliases set > > > up for everybody who has git access? > > > > Could you simply use the email in the commit instead? > > No, I don't think that will work, because branches in git > don't result in new commits. Ok, actually, that's a very good point. -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Branch notifications
On Wed, 2009-11-25 at 17:27 -0300, Germán Póo-Caamaño wrote: > On Thu, 2009-11-26 at 07:03 +1100, Danielle Madeley wrote: > > On Wed, 2009-11-25 at 13:03 -0600, Shaun McCance wrote: > > > > > The only potential problem is that the emails come from your username > > > @src.gnome.org. I know sha...@gnome.org gets to my inbox, and I think > > > sha...@src.gnome.org does as well. But do we have proper aliases set > > > up for everybody who has git access? > > > > Could you simply use the email in the commit instead? > > I think Shaun refers to that email. Can we assume then that that email will work, since they've chosen it. -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Branch notifications
On Thu, 2009-11-26 at 07:03 +1100, Danielle Madeley wrote: > On Wed, 2009-11-25 at 13:03 -0600, Shaun McCance wrote: > > > The only potential problem is that the emails come from your username > > @src.gnome.org. I know sha...@gnome.org gets to my inbox, and I think > > sha...@src.gnome.org does as well. But do we have proper aliases set > > up for everybody who has git access? > > Could you simply use the email in the commit instead? I think Shaun refers to that email. In order to get an idea, you can take some modules and try something like: $ git log --pretty=format:"%cd <%ce> <%ae>" | grep "\.gnome.org" You will find a lot of (svn|src).gnome.org emails from authors and committers. Regards, -- Germán Póo-Caamaño Concepción - Chile http://www.gnome.org/~gpoo/ 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: Branch notifications
On Thu, 2009-11-26 at 07:03 +1100, Danielle Madeley wrote: > On Wed, 2009-11-25 at 13:03 -0600, Shaun McCance wrote: > > > The only potential problem is that the emails come from your username > > @src.gnome.org. I know sha...@gnome.org gets to my inbox, and I think > > sha...@src.gnome.org does as well. But do we have proper aliases set > > up for everybody who has git access? > > Could you simply use the email in the commit instead? No, I don't think that will work, because branches in git don't result in new commits. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: on application focus navigation (was: On ctrl-tab)
On Wed, Nov 25, 2009 at 3:06 PM, Matthias Clasen wrote: > To clear up some of the confusion here, the difference is not how you > can _enter_ the toolbar, it is how you can leave the widget before it. > Gedits content pane needs to accept tab as input, thus you are > required to use Ctrl-tab to leave it. I hate to be presumptuous, but we're talking about the same thing. I know you have to use ctrl-tab to leave a text-pane, and I'm okay with that. And I am indeed talking about -leaving- the toolbar, not entering it. Use ctrl-tab repeatedly in Gedit. You can exit the text entry, you can enter the toolbar. You can move through any toolbar button. But when you reach the last one, you cannot leave the toolbar with ctrl-tab. So, from what you're telling me, I deduce that 1. The text entry only lets you -enter- it with Tab, not ctrl-tab. If this is indeed the case, I have many thoughts. 2. Gedit's toolbar is messed up. > In rhythmbox, regular tab works > since it doesn't have to accept tab as input. But you missed my complaint -- that in Gedit, I can use ctrl-tab to move between buttons, but in Rhythmbox, I can't. > Unless you invent a keyboard that has reserved keys for focus > navigation, there will always be conflicts. GNOME has one. It uses ctrl-tab as the focus-nav shortcut to avoid conflicts. It should be used more consistently, unlike in Gedit (can't leave toolbar) and Rhythmbox (can't navigate toolbar). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Branch notifications
On Wed, 2009-11-25 at 13:03 -0600, Shaun McCance wrote: > The only potential problem is that the emails come from your username > @src.gnome.org. I know sha...@gnome.org gets to my inbox, and I think > sha...@src.gnome.org does as well. But do we have proper aliases set > up for everybody who has git access? Could you simply use the email in the commit instead? -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: on application focus navigation (was: On ctrl-tab)
On Wed, Nov 25, 2009 at 2:53 PM, Jud Craft wrote: > On another note related to the widget-group problem, consider GEdit > and Rhythmbox, specifically their toolbars, and arrow key navigation > of a toolbar. > > > > In GEdit, I can enter the toolbar using tab and ctrl-tab. I can only > exit it using tab (ctrl-tab, which should get into anything, gets > stuck in it for some reason...). I can also use the arrow keys, which > is pretty cool, but if you're moving through fields with ctrl-tab, I > don't want to change over to a new shortcut. > > In Rhythmbox, I can enter the toolbar using tab. But, you can't > navigate it with either tab or ctrl-tab! You have to use the darn > arrow keys only! To clear up some of the confusion here, the difference is not how you can _enter_ the toolbar, it is how you can leave the widget before it. Gedits content pane needs to accept tab as input, thus you are required to use Ctrl-tab to leave it. In rhythmbox, regular tab works since it doesn't have to accept tab as input. [...] > The only thing more frustration than multiple options for keyboard > navigation, are multiple options that only work at certain times. > It's frustrating enough that Tab has text-entry conflicts. Unless you invent a keyboard that has reserved keys for focus navigation, there will always be conflicts. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: on application focus navigation (was: On ctrl-tab)
On another note related to the widget-group problem, consider GEdit and Rhythmbox, specifically their toolbars, and arrow key navigation of a toolbar. In GEdit, I can enter the toolbar using tab and ctrl-tab. I can only exit it using tab (ctrl-tab, which should get into anything, gets stuck in it for some reason...). I can also use the arrow keys, which is pretty cool, but if you're moving through fields with ctrl-tab, I don't want to change over to a new shortcut. In Rhythmbox, I can enter the toolbar using tab. But, you can't navigate it with either tab or ctrl-tab! You have to use the darn arrow keys only! Again from the previous mail, I think it would more consistent if one blessed focus shortcut [in this case ctrl-tab, at least] could make it through any field and any group. Tab is a useful shortcut to quickly change fields, and I understand needing a non-textentry-conflicting shortcut. But whatever this shortcut is, it, at least, should be able to access anything. That's my opinion, it may be wrong. It is highly lovely and convenient to be able to move through every field with the same method. [Especially with the GNOME Sticky keys]. I'm okay with different quick-and-easy methods (Tab when text-entry is not a problem, arrows in a toolbar*), but if there's going to be a super-navigator shortcut, then it needs to cycle through every field. *And since even this causes problems when your toolbar contains anything except buttons [textboxes (which lock left and right arrows), volume meters and dropdownlists (which lock up and down)], it would almost be simpler if this wasn't an option either. The only thing more frustration than multiple options for keyboard navigation, are multiple options that only work at certain times. It's frustrating enough that Tab has text-entry conflicts. The arrow-key conflicts with text-entry and dropdowns only make GNOME keyboard navigation more complex. I know they were meant to make it simpler (very easy to move between elements), but in anything but a static list of elements, it's a pain to keep track of "is this widget going to eat my keyboard navigation?" ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gst-devel] Video Hackfest conclusions
On 11/24/2009 12:47 PM, Benjamin Otte wrote: > = Timeline = > The end goal of all of this is to get the code into users' hands > quickly, but allow a smooth and non-disrupting upgrade. Desired dates > have been put forth to achieve this: > * End of January: release new versions of Cairo and Pixman that > contain the new APIs reuired by GStreamer > * End of March: X server and Mesa releases are due - make sure the > required Mesa extension is part of this. Ideally XrenderPutImage would > be included, too. > * April/May, after next Fedora/Ubuntu releases: Merge Cairo support > into gst-plugins-base and start porting elements to it. Encourage > application developers (browser, Flash players) to make use of the new > APIs > * October: another Fedora/Ubuntu release that switches all users to > the new APIs thanks for the conclusion. one thing which would be very useful (for me and may be others). Fedora/Ubuntu is a very fast moving target, but i understood it as a good target for gstreamer. although some people (like me) would like to use a more robust os like rhel/centos. but currently it's not possible to update gstreamer to newer version on rhel/centos since gstreamer depend on glib/gtk which is too old in rhel for newer gstreamer. as (probably) rhel-6 will be out in 2010 it means that version of glib/gtk/cairo which will be in rhel-6 will remain for many years in the rhel/centos-6. so if i dare to ask that gtk/glib/cairo version in rhel-6 should have to enough for these features. ie. rise the required gtk/glib/cairo version in the current gstreamer to be enough for later version. otherwise these features can't be used in rhel-6 for many years. thanks in advance. regards. -- Levente "Si vis pacem para bellum!" ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: on application focus navigation (was: On ctrl-tab)
[I apologize, this should have gone to the list. I really have to watch the Reply-to-All button in Gmail.] On Wed, Nov 25, 2009 at 1:51 PM, Behdad Esfahbod wrote: >> You can tab into a ListView, but not shift-tab (only >> into the headers), and not being able to tab through toolbar buttons > > File bug? One step ahead. https://bugzilla.gnome.org/show_bug.cgi?id=600168. >> (but you can ctrl-tab -- until you hit a non-button widget! or >> whatever. it's extremely difficult to keep track) is a nightmare. > > Either file bugs, or if its more fundamental stuff, bring it up here. The general underlying problem (from what I understand from talking with one of the Banshee accessibility developers) is that GTK defines "widget groups", with child elements that you can only access using ctrl-tab. But then again, it seems to define child elements that you -can- access using tab (assuming that the ListView bug I mentioned is actually a case of headers + listdata being one widget group). Aside from the very annoying exception of the ListView, I think I would call this an unfortunate design decision rather than a bug, and I can't change that nor make GNOME developers design to retool their GUI for my vagaries. > > >> Panel keyboard navigation (trying to work through the launchers, task >> buttons, and menus) is another thing entirely, but a little better. >> > Agreed. File bugs? Wouldn't bother. Isn't gnome-panel getting phased out? And the Shell hasn't began keyboard access work yet. >> Never mind that sometimes, just pressing an arrow key makes my focus >> jump from a toolbar to the document! > > Yeah, that can be quite handy or annoying depending how you look at it. Tell me about it. >> PS. I have no idea how to file bugs against the interface guidelines >> themselves -- or even if anyone agrees with me. Are people really >> happy with GNOME keyboard focus navigation? > > Technically the HIG, but doesn't help that it's unmaintained. So, perhaps > we need to address this problem first, that currently there's no way to > change these things. > So, if you don't mind my asking -- where exactly is the canonical reference for GNOME GUI design? I assume you mean the GNOME HCI Guidelines 2.2 are unmaintained? Or is it just kind of touch-and-go? >> I'd much rather them fix focus switching to use Tab *exclusively*, and > > How would you Tab out of a gedit text area? Well, you've got me. My problem isn't necessarily that GNOME uses a combination to escape from a text-entry field. I'm actually okay with using tab and ctrl-tab. But I at least want one way that is -always active- to move between fields. GNOME currently can't do this. For example. 1. In the Run Application Box, I can use tab or ctrl-tab equally to get through every field. It's lovely. 2. Open up Gedit. Try to cycle through every field once. You can't use just tab, or just ctrl-tab. You have to use a combination of different shortcuts. It would be cool if you could cycle through every field with a [modifier]+tab key. But you can't. You can get through many fields with ctrl-tab, but then you get stuck on the toolbar. For some reason, in the Run Box, ctrl-tab can go through every widget, but in GEdit it gets stuck in the toolbar group. It would be ideal if ctrl-tab could, at least, perfectly cycle through every field on its own. You could set Sticky Keys on ctrl, and then dance through an application to your heart's content. 'Tab' is merely a convenient legacy-user shortcut to switch between fields, and you also need a shortcut that does not conflict with text-entry. 1. Ctrl-tab can do this, or it could be anything else. 2. Ctrl-space (probably conflicts with some of those Gnome-Do/Launch-bar type programs) 3. Super-tab (I kinda like this one, since GNOME doesn't let you reserve super-shortcuts [except GNOME-Do for an odd reason]. So this one should be safe). Whatever it is, it needs to be able to cycle through all fields. Currently GNOME has no such shortcut, although it'd be cool if ctrl-tab could do it. Maybe a bug could be filed? And perhaps later the default "canonical focus shortcut" combo could be super-tab or somesuch, if people really wanted to retain ctrl-tab for document switching. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Branch notifications
On Tue, 2009-11-24 at 16:43 +, Calum Benson wrote: > Shaun McCance wrote: > >>From http://live.gnome.org/MaintainersCorner > > > > When you branch, please remember to let release-team, > > desktop-devel-list, gnome-doc-list, and gnome-i18n know. > > > > Since the git migration, we have automatic notifications for > > any branch using the standard gnome-MAJOR-MINOR scheme. They > > go out to release-team, gnome-doc-list, and gnome-i18n. > > Could the mail also go to the developer who made the branch, for > reassurance/confirmation? It's quite conceivable they won't be on any of > those mailing lists, so will never see the automatic notification > otherwise. > > (I'm on one of those lists, but even then I never noticed an automatic > notification appearing the last time I branched gnome-themes-- actually, > I don't see it in the archives, either.) I think that's a great idea. I was thinking of adding some language to the effect of "check the archives to make sure the automatic email was sent", but really, that's as much of a burden on maintainers as just sending the email. The only potential problem is that the emails come from your username @src.gnome.org. I know sha...@gnome.org gets to my inbox, and I think sha...@src.gnome.org does as well. But do we have proper aliases set up for everybody who has git access? -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: on application focus navigation (was: On ctrl-tab)
On 11/25/2009 12:29 PM, Jud Craft wrote: On Sun, Nov 22, 2009 at 6:57 PM, Behdad Esfahbod wrote: They have all been CLOSED WONTFIX consistently. The reason for not doing that by default is that currently ctrl+tab is used to change focus when tab itself is consumed by a widget (text area, etc. vte currently doesn't do that, but that's a separate bug. Bug #602665). (mini-rant that I am completely unjustified in making.) I can't believe that the focus shortcut policy holds a relatively simple and sensible change. GNOME's focus switching is so inconsistent it boggles my mind. Then lets just discuss it. I even brought it up! I'd much rather them fix focus switching to use Tab *exclusively*, and How would you Tab out of a gedit text area? make more sense. You can tab into a ListView, but not shift-tab (only into the headers), and not being able to tab through toolbar buttons File bug? (but you can ctrl-tab -- until you hit a non-button widget! or whatever. it's extremely difficult to keep track) is a nightmare. Either file bugs, or if its more fundamental stuff, bring it up here. Panel keyboard navigation (trying to work through the launchers, task buttons, and menus) is another thing entirely, but a little better. Actually navigating the focus around a semi-complex GNOME application (Banshee, Rhythmbox, MonoDevelop, F-Spot, Evolution) involves me trying many different ways to get through the stupid text-boxes and drop-downs, each of which have inconsistent and *completely different* ways to move focus from them. Agreed. File bugs? Never mind that sometimes, just pressing an arrow key makes my focus jump from a toolbar to the document! Yeah, that can be quite handy or annoying depending how you look at it. I'd much rather GNOME fix the focus-navigation shortcuts to be less insane, and then add a liberated Ctrl-Tab as a blessed tab-document switcher. How? I much rather GNOME fix all the other bugs too. That's my Xmas wish, now lets wait for Santa! (/mini-rant) PS. I have no idea how to file bugs against the interface guidelines themselves -- or even if anyone agrees with me. Are people really happy with GNOME keyboard focus navigation? Technically the HIG, but doesn't help that it's unmaintained. So, perhaps we need to address this problem first, that currently there's no way to change these things. behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: on application focus navigation (was: On ctrl-tab)
On Wed, Nov 25, 2009 at 1:09 PM, Jud Craft wrote: > > *because a funky keyboard navigation scheme does not actually prevent > functioning of the system. That is not true at all; keyboard navigation is an integral part of system function. But I don't think your rant is very true either... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: on application focus navigation (was: On ctrl-tab)
On Wed, Nov 25, 2009 at 12:58 PM, Andre Klapper wrote: > http://bugzilla.gnome.org/enter_bug.cgi?product=HIG Ah. I formerly heard to try against GTK. I'll need to do some bug changes, but I don't see much use in a user filing a problem with the HIG. Is that even a good idea? My belief was that asking to change non-bug* design points of the desktop really needs to come from the designers. They're the ones who have to program it, after all. *because a funky keyboard navigation scheme does not actually prevent functioning of the system. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: on application focus navigation (was: On ctrl-tab)
Am Mittwoch, den 25.11.2009, 12:29 -0500 schrieb Jud Craft: > PS. I have no idea how to file bugs against the interface guidelines > themselves http://bugzilla.gnome.org/enter_bug.cgi?product=HIG andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On Ctrl+tab
On Tue, Nov 24, 2009 at 11:54 AM, Calum Benson wrote: > For gtk, we tried to strike the best balance we could between not throwing > away peoples' prior keynav knowledge, ironing out their internal > inconsistencies, and filling in the gaps as logically as we could for things > that they missed or didn't exist in their platforms. I really enjoy GNOME, and I hate to be mean. And it has good points (you can in fact, navigate the whole application). But I can't help but think it has a few glaringly bizarre flaws of its own. GNOME focus navigation is at times almost infuriatingly crazy, with many special cases and inconsistent behavior for different widget -- and even in the direction of focus! (As an example: shifting backwards/forwards, as in the case of a ListView -- you can tab through the headers and the list data, but you can't shift-tab back into the list - it skips the list and goes to the headers, then you have to tab again to get back into the list). I actually don't want to be seen as vitriolic, but this bothers me so much. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
on application focus navigation (was: On ctrl-tab)
On Sun, Nov 22, 2009 at 6:57 PM, Behdad Esfahbod wrote: > They have all been CLOSED WONTFIX consistently. The > reason for not doing that by default is that currently ctrl+tab is used to > change focus when tab itself is consumed by a widget (text area, etc. vte > currently doesn't do that, but that's a separate bug. Bug #602665). (mini-rant that I am completely unjustified in making.) I can't believe that the focus shortcut policy holds a relatively simple and sensible change. GNOME's focus switching is so inconsistent it boggles my mind. I'd much rather them fix focus switching to use Tab *exclusively*, and make more sense. You can tab into a ListView, but not shift-tab (only into the headers), and not being able to tab through toolbar buttons (but you can ctrl-tab -- until you hit a non-button widget! or whatever. it's extremely difficult to keep track) is a nightmare. Panel keyboard navigation (trying to work through the launchers, task buttons, and menus) is another thing entirely, but a little better. Actually navigating the focus around a semi-complex GNOME application (Banshee, Rhythmbox, MonoDevelop, F-Spot, Evolution) involves me trying many different ways to get through the stupid text-boxes and drop-downs, each of which have inconsistent and *completely different* ways to move focus from them. Never mind that sometimes, just pressing an arrow key makes my focus jump from a toolbar to the document! I'd much rather GNOME fix the focus-navigation shortcuts to be less insane, and then add a liberated Ctrl-Tab as a blessed tab-document switcher. (/mini-rant) PS. I have no idea how to file bugs against the interface guidelines themselves -- or even if anyone agrees with me. Are people really happy with GNOME keyboard focus navigation? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
