From: Marc M. <Marc.Mulcahy@Sun.COM> - 2003-12-19 01:30:18
|
Hi Sean, On Wed, 17 Dec 2003, Sean Egan wrote: > What if we allowed other widgets to take focus, but gave focus back to > the input box on a keystroke (excluding space, enter, shift-arrows, and > anything else that would be handled by the currently focused window)? > > Would that be enough for a11y purposes? Would that be good enough to > give the impression that the input box is always in focus? > Yeah, I think that would be fine. do you want me to take an initial crack at that in my initial accessibility patch? Sorry I've been slow in getting it to you. The latest version of Gnopernicus has issues, so I've been waiting to be able to test against it. Marc |
From: Steven G. <ste...@si...> - 2004-01-11 01:40:06
|
On Wed, 17 Dec 2003, Sean Egan wrote: >>What if we allowed other widgets to take focus, but gave focus back to >>the input box on a keystroke (excluding space, enter, shift-arrows, and >>anything else that would be handled by the currently focused window)? >>Would that be enough for a11y purposes? Would that be good enough to >>give the impression that the input box is always in focus? Marc Mulcahy wrote: >Yeah, I think that would be fine. do you want me to take an initial >crack at that in my initial accessibility patch? >Sorry I've been slow in getting it to you. The latest version of >Gnopernicus has issues, so I've been waiting to be able to test against >it. This would be a much better solution as it would fix another odd side-effect of the current way the input box steals focus. When you select text in the conversation window history, as soon as you un-click after the mouse drag, the focus is stolen back to the input box - so even though it looks like your text is selected, key commands like Ctrl+C don't work on it since the history window isn't active. So as it stands, copying text with the keyboard is broken in the conversation history (select, then right click works, as it forces focus). Steven Garrity |
From: Nathan F. <8n...@ql...> - 2004-01-13 20:13:00
Attachments:
gtkconv-refocus-1.diff
|
On Sat, 2004-01-10 at 20:39, Steven Garrity wrote: > On Wed, 17 Dec 2003, Sean Egan wrote: > >>What if we allowed other widgets to take focus, but gave focus back to > >>the input box on a keystroke (excluding space, enter, shift-arrows, and > >>anything else that would be handled by the currently focused window)? > >>Would that be enough for a11y purposes? Would that be good enough to > >>give the impression that the input box is always in focus? > > Marc Mulcahy wrote: > >Yeah, I think that would be fine. do you want me to take an initial > >crack at that in my initial accessibility patch? > >Sorry I've been slow in getting it to you. The latest version of > >Gnopernicus has issues, so I've been waiting to be able to test against > >it. > > This would be a much better solution as it would fix another odd > side-effect of the current way the input box steals focus. When you > select text in the conversation window history, as soon as you un-click > after the mouse drag, the focus is stolen back to the input box - so > even though it looks like your text is selected, key commands like > Ctrl+C don't work on it since the history window isn't active. Here is a patch that implements what Sean proposed above. It allows the conversation log to be focused and only transfers focus back to the entry box on a non-CTRL-key-combination. You can still start typing anywhere within the window and it will go to the entry box. Other keys or modifier-keys that are important to accessibility could easily be added. I just did CTRL for now since that allows copying with the shortcut CTRL-C to work. Nathan |
From: Nathan F. <8n...@ql...> - 2004-01-13 20:28:08
|
On Tue, 2004-01-13 at 15:12, Nathan Fredrickson wrote: > Here is a patch that implements what Sean proposed above. It allows the > conversation log to be focused and only transfers focus back to the > entry box on a non-CTRL-key-combination. You can still start typing > anywhere within the window and it will go to the entry box. > > Other keys or modifier-keys that are important to accessibility could > easily be added. I just did CTRL for now since that allows copying with > the shortcut CTRL-C to work. I found one problem with this: CTRL-V can be used to paste text *into* the conversation log. I could limit the patch to CTRL-C only instead of all CTRL-key combinations, although perhaps the conversation log should be fixed to not allow pasting into it... Nathan |
From: Mark D. <sof...@ki...> - 2004-01-15 05:06:06
|
On Tue, 13 Jan 2004 15:12:35 -0500, Nathan Fredrickson wrote > Here is a patch that implements what Sean proposed above. It allows > the conversation log to be focused and only transfers focus back to the > entry box on a non-CTRL-key-combination. You can still start typing > anywhere within the window and it will go to the entry box. > > Other keys or modifier-keys that are important to accessibility could > easily be added. I just did CTRL for now since that allows copying with > the shortcut CTRL-C to work. Committed. Thanks. I put a tarball and an fc1 RPM of CVS online for testing. If anyone wants to be adventurous, please let me know if any keyboard shortcuts aren't working. Or if anyone has any more accessibility suggestions. http://kingant.net/oscar/gaim/gaim-0.76cvs.tar.gz http://kingant.net/oscar/gaim/gaim-0.76cvs-0mark.i386.rpm -Mark -- O O Mark Doliner \ | ma...@ki... \ | www.kingant.net "There needs to be a better word for weird." |
From: Tim R. <om...@ho...> - 2004-01-15 06:02:20
|
> > >Or if anyone has any more accessibility suggestions. > > I read through the Gnome HIG stuff a couple weeks ago and noticed a few things with the buddy list, which since I'm lazy and didn't try the new tarball, could be fixed already. Double clicking on a buddy opens a new IM window, but the top item is Get Info in the context menu. I think the default Item is supposed to be on top. The context menu won't open from the keyboard. Neither the new fangled context menu key, nor the shift+f10 thing works. They both work on other widgets, like the text entry widget (erm now gtkimhtml) for Chat's and IM's, which provide their own menus. There seems to be a similiar problem in the members list for chats. (There's probably a similiar problem for my room list patch.) It said something about tooltips being activated by a certain keyboard shortcut, much the way menus are supposed to be, but I don't remember what the magic combination was. Whatever it was, it doesn't seem to work for the buddy list. Also I think ESC (or something, anyway) was supposed to make tooltips go away, and doesn't. --Tim Ringenbach |
From: Ka-Hing C. <ja...@ja...> - 2004-01-15 06:12:35
|
> Double clicking on a buddy opens a new IM window, but the top item is > Get Info in the context menu. I think the default Item is supposed to be > on top. > I think the reason why IM isn't the first item is because when you use the right click menu, most of the time you actually don't want to IM but choose some other functions. -khc |
From: Luke S. <lsc...@us...> - 2004-01-15 16:17:12
|
Please make sure control-w only works when selected in preferences, this is a bug submitted last night. luke On Thu, Jan 15, 2004 at 12:05:57AM -0500, Mark Doliner wrote: > On Tue, 13 Jan 2004 15:12:35 -0500, Nathan Fredrickson wrote > > Here is a patch that implements what Sean proposed above. It allows > > the conversation log to be focused and only transfers focus back to the > > entry box on a non-CTRL-key-combination. You can still start typing > > anywhere within the window and it will go to the entry box. > > > > Other keys or modifier-keys that are important to accessibility could > > easily be added. I just did CTRL for now since that allows copying with > > the shortcut CTRL-C to work. > > Committed. Thanks. > > I put a tarball and an fc1 RPM of CVS online for testing. If anyone wants to > be adventurous, please let me know if any keyboard shortcuts aren't working. > Or if anyone has any more accessibility suggestions. > > http://kingant.net/oscar/gaim/gaim-0.76cvs.tar.gz > http://kingant.net/oscar/gaim/gaim-0.76cvs-0mark.i386.rpm > > > -Mark > > -- > O O Mark Doliner > \ | ma...@ki... > \ | www.kingant.net > "There needs to be a better word for weird." > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel > -- -This email is made of 100% recycled electrons. |
From: Marc M. <Marc.Mulcahy@Sun.COM> - 2004-01-16 06:10:01
Attachments:
gaim-accessibility.patch
|
Hi All, Here's my GAIM Accessibility patch. Sorry it's so huge. I've been playing with it here for a bout a week to ensure everything seems to work. It's up to date with anonymous Sourceforge CVS as of now. In short, here's what it does, and what the remaining issues are: It uses ATK, the accessibility toolkit portion ot GTK to ensure that all widgets have associated labels such that Gnopernicus or some other assistive technology knows what labels go with what widgets. It allows access to the right-click popup menus of the buddy list and the list of chat room participants via the keyboard (shift-f10). Note, this took quite a bit of refactoring, so if I missed something and got it wrong, I apologize. It also required writing a menu positioning function for treeviews. I stole most of the code from GTK itself. Sorry if it looks wrong-- I'm a blind guy and visual design isn't my forte. Let me know if it's busted and I'll fix it. The conversation window still has some issues. The recent patch to forward key events sent to the imhtml widget to the entry widget causes keyboard navigation to not work at all for me in the conversation window. I.E., pressing shift-tab after first entering the window and landing on the text entry field, does nothing. removing the keypress/keyrelease handler for the imhtml widget allows focus to move among the tab control, imhtml widget, and text entry field. Note that my patch removes the toolbar from the focus chain in the conversation window, since all the buttons are available through keyboard shortcuts. In order for someone to select text only using the keyboard, the imhtml widget displaying the conversation log will need to have a caret in it. Currently, if the imhtml widget is not editable, then it has no caret visible. I think we need at least an option to always have the caret visible so that, for example, I can cut and paste a URL from an instant message conversation. I think that's about it. Please send me your thoughts. Thanks, Marc |
From: Mark D. <ma...@ki...> - 2004-01-19 23:45:52
|
Alright, this should have all been committed. I accidentally credited Nathan Fredrickson in the commit message--sorry about that, my mind is kinda numb. I got it right in the ChangeLog. Very nicely written patch. I commited the gaim_set_accessible_label() stuff with little or no modification. I don't think I changed the gtkconv.c context menu code much, either. For the buddy list context menu, there was a lot of code duplication in your version because the callback for shift+f10 and the callback for right clicking on the blist both had a lot of code for drawing the context menu. I split that out into a new function that gets called from either of the callbacks. The positioning function works pretty well, but it doesn't feel as natural as the function gtk uses when you don't specify one, so I made sure the function is only used when the context menu is accessed via shift+f10 rather than via a right click (because in this case the mouse could be anywhere on the screen, or even non-existant, I suppose). Anyway, please please test the code in CVS to make sure I didn't screw up any of what you're trying to accomplish. I can make you a tarball or rpm if you don't have CVS access--just let me know. Thanks for the patch, you rock! -Mark On Thu, 15 Jan 2004 23:09:52 -0700 (MST), Marc Mulcahy wrote > Hi All, > > Here's my GAIM Accessibility patch. Sorry it's so huge. I've been > playing with it here for a bout a week to ensure everything seems to > work. It's up to date with anonymous Sourceforge CVS as of now. > > In short, here's what it does, and what the remaining issues are: > > It uses ATK, the accessibility toolkit portion ot GTK to ensure that > all widgets have associated labels such that Gnopernicus or some > other assistive technology knows what labels go with what widgets. > > It allows access to the right-click popup menus of the buddy list > and the list of chat room participants via the keyboard (shift-f10). > Note, this took quite a bit of refactoring, so if I missed > something and got it wrong, I apologize. It also required writing a > menu positioning function for treeviews. I stole most of the code > from GTK itself. Sorry if it looks wrong-- I'm a blind guy and > visual design isn't my forte. Let me know if it's busted and I'll > fix it. > > The conversation window still has some issues. The recent patch to > forward key events sent to the imhtml widget to the entry widget causes > keyboard navigation to not work at all for me in the conversation window. > > I.E., pressing shift-tab after first entering the window and landing > on the text entry field, does nothing. removing the keypress/keyrelease > handler for the imhtml widget allows focus to move among the tab > control, imhtml widget, and text entry field. Note that my patch > removes the toolbar from the focus chain in the conversation window, > since all the buttons are available through keyboard shortcuts. > > In order for someone to select text only using the keyboard, the imhtml > widget displaying the conversation log will need to have a caret in it. > Currently, if the imhtml widget is not editable, then it has no caret > visible. I think we need at least an option to always have the caret > visible so that, for example, I can cut and paste a URL from an instant > message conversation. > > I think that's about it. Please send me your thoughts. > > Thanks, > > Marc -- O O Mark Doliner \ | ma...@ki... \ | www.kingant.net "There needs to be a better word for weird." |
From: Mark D. <ma...@ki...> - 2004-01-21 04:52:58
|
On Tue, 20 Jan 2004 14:13:13 -0700 (MST), Marc Mulcahy wrote > BTW, do you have any thoughts on the visible caret in the > conversation log GTKImHTML widget? We need to have a caret that can > be moved around with the arrow keys so that folks who can't use the > mouse can select/cut/copy text from the conversation log. Would it > be acceptable to make the caret visible, and leave the widget read- > only. Or possibly make the caret a preferences setting? I think most of us are against having a preference for showing/not showing a preference. We try to avoid having too many preferences. And the widget will definitely still have to be read only. I think the best solution would be to have a caret, but only make it visible when the gtkimhtml widget is displayed. I'm not sure how difficult that would be to do, gtk isn't really my forte. Anyone have any input? -Mark -- O O Mark Doliner \ | ma...@ki... \ | www.kingant.net "There needs to be a better word for weird." |
From: John B. S. <sil...@us...> - 2004-01-21 05:26:44
|
On Tue, Jan 20, 2004 at 11:52:47PM -0500, Mark Doliner wrote: > On Tue, 20 Jan 2004 14:13:13 -0700 (MST), Marc Mulcahy wrote > > BTW, do you have any thoughts on the visible caret in the > > conversation log GTKImHTML widget? We need to have a caret that can > > be moved around with the arrow keys so that folks who can't use the > > mouse can select/cut/copy text from the conversation log. Would it > > be acceptable to make the caret visible, and leave the widget read- > > only. Or possibly make the caret a preferences setting? > > I think most of us are against having a preference for showing/not showing a > preference. We try to avoid having too many preferences. And the widget will > definitely still have to be read only. I think the best solution would be to > have a caret, but only make it visible when the gtkimhtml widget is displayed. > I'm not sure how difficult that would be to do, gtk isn't really my forte. > > Anyone have any input? > -Mark How about something like Mozilla Firebird's "F7" -> Caret mode. This puts a caret in the web page for selection, navigation, and context sensitive menus (the special Windows context menu key if you're running *that* OS, and/or Shift-F10 on either [which was copied from M$, BTW -- credit where credit is due :-/]), while maintaining a read-only text mode. The only little issue I'm thinking about is just the fact that this is undocumented (I only learned about it in a /. post some time ago. Above, Mark just pointed to the idea of "having too many preferences" - similarly we probably want to avoid too many menu options. I don't know if F7 -> Caret mode is a standard of any sort, or just a MozFirebird thing, otherwise I would envision a menu choice "Options->Caret Mode [F7]" (toggle) in the convo window. Just as there's really no choice about it in MozFirebird, I see no reason to disable this ability, just make it a toggling choice. You don't want to be in caret mode when you're typing messages, so I think toggling between the 2 parts with F7 seems logical to me. Cheers, John P.S. If anyone implements this, and decides to put in vi cursor keys, I'll be forever in awe with you :-D. |
From: Marc M. <Marc.Mulcahy@Sun.COM> - 2004-01-21 15:58:20
|
Hi All, Is anyone opposed to just having a visible caret all the time, even though the GTKImHTML widget is read-only. That's what my local copy does, and it's easy to do-- just don't set gtk_text_view_cursor_visible in the gtkimhtml_set_editable function. Otherwise, I think f7 would ban acceptable approach, although it would require pressing f7 every time a new conversation window was opened. Marc On Wed, 21 Jan 2004, John B. Silvestri wrote: > On Tue, Jan 20, 2004 at 11:52:47PM -0500, Mark Doliner wrote: > > On Tue, 20 Jan 2004 14:13:13 -0700 (MST), Marc Mulcahy wrote > > > BTW, do you have any thoughts on the visible caret in the > > > conversation log GTKImHTML widget? We need to have a caret that can > > > be moved around with the arrow keys so that folks who can't use the > > > mouse can select/cut/copy text from the conversation log. Would it > > > be acceptable to make the caret visible, and leave the widget read- > > > only. Or possibly make the caret a preferences setting? > > > > I think most of us are against having a preference for showing/not showing a > > preference. We try to avoid having too many preferences. And the widget will > > definitely still have to be read only. I think the best solution would be to > > have a caret, but only make it visible when the gtkimhtml widget is displayed. > > I'm not sure how difficult that would be to do, gtk isn't really my forte. > > > > Anyone have any input? > > -Mark > > How about something like Mozilla Firebird's "F7" -> Caret mode. This > puts a caret in the web page for selection, navigation, and context > sensitive menus (the special Windows context menu key if you're running > *that* OS, and/or Shift-F10 on either [which was copied from M$, BTW -- > credit where credit is due :-/]), while maintaining a read-only text > mode. The only little issue I'm thinking about is just the fact that > this is undocumented (I only learned about it in a /. post some time > ago. Above, Mark just pointed to the idea of "having too many > preferences" - similarly we probably want to avoid too many menu > options. I don't know if F7 -> Caret mode is a standard of any > sort, or just a MozFirebird thing, otherwise I would envision a menu > choice "Options->Caret Mode [F7]" (toggle) in the convo window. Just as > there's really no choice about it in MozFirebird, I see no reason to > disable this ability, just make it a toggling choice. You don't want to > be in caret mode when you're typing messages, so I think toggling > between the 2 parts with F7 seems logical to me. > > Cheers, > John > > P.S. If anyone implements this, and decides to put in vi cursor keys, > I'll be forever in awe with you :-D. > |
From: Mark D. <ma...@ki...> - 2004-01-28 06:10:29
|
I turned the caret back on for non-editable gtkimhtml widgets. Let me know if there is anything else we can do. -Mark On Wed, 21 Jan 2004 08:57:44 -0700 (MST), Marc Mulcahy wrote > Hi All, > > Is anyone opposed to just having a visible caret all the time, even though > the GTKImHTML widget is read-only. That's what my local copy does, and > it's easy to do-- just don't set gtk_text_view_cursor_visible in the > gtkimhtml_set_editable function. > > Otherwise, I think f7 would ban acceptable approach, although it > would require pressing f7 every time a new conversation window was opened. > > Marc > > On Wed, 21 Jan 2004, John B. Silvestri wrote: > > > On Tue, Jan 20, 2004 at 11:52:47PM -0500, Mark Doliner wrote: > > > On Tue, 20 Jan 2004 14:13:13 -0700 (MST), Marc Mulcahy wrote > > > > BTW, do you have any thoughts on the visible caret in the > > > > conversation log GTKImHTML widget? We need to have a caret that can > > > > be moved around with the arrow keys so that folks who can't use the > > > > mouse can select/cut/copy text from the conversation log. Would it > > > > be acceptable to make the caret visible, and leave the widget read- > > > > only. Or possibly make the caret a preferences setting? > > > > > > I think most of us are against having a preference for showing/not showing a > > > preference. We try to avoid having too many preferences. And the widget will > > > definitely still have to be read only. I think the best solution would be to > > > have a caret, but only make it visible when the gtkimhtml widget is displayed. > > > I'm not sure how difficult that would be to do, gtk isn't really my forte. > > > > > > Anyone have any input? > > > -Mark > > > > How about something like Mozilla Firebird's "F7" -> Caret mode. This > > puts a caret in the web page for selection, navigation, and context > > sensitive menus (the special Windows context menu key if you're running > > *that* OS, and/or Shift-F10 on either [which was copied from M$, BTW -- > > credit where credit is due :-/]), while maintaining a read-only text > > mode. The only little issue I'm thinking about is just the fact that > > this is undocumented (I only learned about it in a /. post some time > > ago. Above, Mark just pointed to the idea of "having too many > > preferences" - similarly we probably want to avoid too many menu > > options. I don't know if F7 -> Caret mode is a standard of any > > sort, or just a MozFirebird thing, otherwise I would envision a menu > > choice "Options->Caret Mode [F7]" (toggle) in the convo window. Just as > > there's really no choice about it in MozFirebird, I see no reason to > > disable this ability, just make it a toggling choice. You don't want to > > be in caret mode when you're typing messages, so I think toggling > > between the 2 parts with F7 seems logical to me. > > > > Cheers, > > John > > > > P.S. If anyone implements this, and decides to put in vi cursor keys, > > I'll be forever in awe with you :-D. -- O O Mark Doliner \ | ma...@ki... \ | www.kingant.net "There needs to be a better word for weird." |
From: Marc M. <Marc.Mulcahy@Sun.COM> - 2004-01-31 03:30:49
|
Hey Mark, Excellent! This works great. I have a couple more things for which I can submit a patch. 1. The "focus" signal handler on the pane which forces focus to the outgoing entry doesn't allow one to tab and shift tab off the outgoing text entry, removing it makes things work great for me. 2. It might be nice to also include home and end as keys which are allowed to be typed into the gtkimhtml. Thanks so much for doing all this work! I love using Gaim! Marc On Wed, 28 Jan 2004, Mark Doliner wrote: > I turned the caret back on for non-editable gtkimhtml widgets. Let me know if > there is anything else we can do. > -Mark > > On Wed, 21 Jan 2004 08:57:44 -0700 (MST), Marc Mulcahy wrote > > Hi All, > > > > Is anyone opposed to just having a visible caret all the time, even though > > the GTKImHTML widget is read-only. That's what my local copy does, and > > it's easy to do-- just don't set gtk_text_view_cursor_visible in the > > gtkimhtml_set_editable function. > > > > Otherwise, I think f7 would ban acceptable approach, although it > > would require pressing f7 every time a new conversation window was opened. > > > > Marc > > > > On Wed, 21 Jan 2004, John B. Silvestri wrote: > > > > > On Tue, Jan 20, 2004 at 11:52:47PM -0500, Mark Doliner wrote: > > > > On Tue, 20 Jan 2004 14:13:13 -0700 (MST), Marc Mulcahy wrote > > > > > BTW, do you have any thoughts on the visible caret in the > > > > > conversation log GTKImHTML widget? We need to have a caret that can > > > > > be moved around with the arrow keys so that folks who can't use the > > > > > mouse can select/cut/copy text from the conversation log. Would it > > > > > be acceptable to make the caret visible, and leave the widget read- > > > > > only. Or possibly make the caret a preferences setting? > > > > > > > > I think most of us are against having a preference for showing/not showing a > > > > preference. We try to avoid having too many preferences. And the > widget will > > > > definitely still have to be read only. I think the best solution would > be to > > > > have a caret, but only make it visible when the gtkimhtml widget is > displayed. > > > > I'm not sure how difficult that would be to do, gtk isn't really my forte. > > > > > > > > Anyone have any input? > > > > -Mark > > > > > > How about something like Mozilla Firebird's "F7" -> Caret mode. This > > > puts a caret in the web page for selection, navigation, and context > > > sensitive menus (the special Windows context menu key if you're running > > > *that* OS, and/or Shift-F10 on either [which was copied from M$, BTW -- > > > credit where credit is due :-/]), while maintaining a read-only text > > > mode. The only little issue I'm thinking about is just the fact that > > > this is undocumented (I only learned about it in a /. post some time > > > ago. Above, Mark just pointed to the idea of "having too many > > > preferences" - similarly we probably want to avoid too many menu > > > options. I don't know if F7 -> Caret mode is a standard of any > > > sort, or just a MozFirebird thing, otherwise I would envision a menu > > > choice "Options->Caret Mode [F7]" (toggle) in the convo window. Just as > > > there's really no choice about it in MozFirebird, I see no reason to > > > disable this ability, just make it a toggling choice. You don't want to > > > be in caret mode when you're typing messages, so I think toggling > > > between the 2 parts with F7 seems logical to me. > > > > > > Cheers, > > > John > > > > > > P.S. If anyone implements this, and decides to put in vi cursor keys, > > > I'll be forever in awe with you :-D. > > > -- > O O Mark Doliner > \ | ma...@ki... > \ | www.kingant.net > "There needs to be a better word for weird." > > |
From: Nathan F. <8n...@ql...> - 2004-01-31 04:11:56
|
Hi Marc, On Wed, 2004-01-28 at 19:04, Marc Mulcahy wrote: > 1. The "focus" signal handler on the pane which forces focus to the > outgoing entry doesn't allow one to tab and shift tab off the outgoing > text entry, removing it makes things work great for me. I'm the one responsible for re-adding that signal handler which your original patch removed. It was re-added to fix a focusing issue in chat windows (only chat, not IM windows). When switching tabs in a chat window, focus is supposed to go to the message entry box, but instead it's going to the topic entry box. It appears that the panel gets focused first which in turn focuses the first focusable widget: the topic entry. I'm sure there is a better method to focus the message entry first, and then the signal handler on the pane can be removed. Patches welcome :-) > 2. It might be nice to also include home and end as keys which are allowed > to be typed into the gtkimhtml. I agree, especially since we're already including the arrow keys. I'll make a patch as soon as I can connect to the anoncvs to update my tree. > Thanks so much for doing all this work! I love using Gaim! Thanks for all the accessibility work you've done on Gaim. Nathan |
From: Marc M. <Marc.Mulcahy@Sun.COM> - 2004-03-08 08:09:04
Attachments:
gaim.diff
|
Hi Nathan, Gaim as it exists in CVS is difficult to use, sine although the gtkimhtml widget is accessible via the keyboard, is isn't focussable. Ths appears to be for two reasons-- one is that shift-tabs get passed to the gtkimhtml and then cause the focus to shift back to the entry. This diff fixes this by adding GDK_ISO_Left_Tab to the list of allowed keys in the gtkimhtml. The other issue is, as we've discussed previously, related to the fact that the conversation container has a signal handler on it for "focus" which always puts the focus in the entry. This makes it impossible, using only the keyboard, to focus anything but the entry. You had mentioned previously that removing the signal handler for "focus" had some undesirable side-effect in chat windows. I think it related to switching tabs. When I switch tabs to a different chat, the focus seems to be placed in the correct widget for me. Could you give me some pointers about what the desired behavior is. I'd like to implement some code to get this issue fixed, since Gaim is difficult to use as it stands now. This diff removes the focus signal handler on the pane, and adds the GDK_ISO_Left_Tab key to the allowable keys for gtkimhtml widgets. I'm successfully using Gaim with this patch and Gnopernicus now. Marc On Fri, 30 Jan 2004, Nathan Fredrickson wrote: > Hi Marc, > > On Wed, 2004-01-28 at 19:04, Marc Mulcahy wrote: > > 1. The "focus" signal handler on the pane which forces focus to the > > outgoing entry doesn't allow one to tab and shift tab off the outgoing > > text entry, removing it makes things work great for me. > > I'm the one responsible for re-adding that signal handler which your > original patch removed. It was re-added to fix a focusing issue in chat > windows (only chat, not IM windows). > > When switching tabs in a chat window, focus is supposed to go to the > message entry box, but instead it's going to the topic entry box. It > appears that the panel gets focused first which in turn focuses the > first focusable widget: the topic entry. > > I'm sure there is a better method to focus the message entry first, and > then the signal handler on the pane can be removed. Patches welcome :-) > > > 2. It might be nice to also include home and end as keys which are allowed > > to be typed into the gtkimhtml. > > I agree, especially since we're already including the arrow keys. I'll > make a patch as soon as I can connect to the anoncvs to update my tree. > > > Thanks so much for doing all this work! I love using Gaim! > > Thanks for all the accessibility work you've done on Gaim. > > Nathan > > > |
From: Tim R. <om...@ho...> - 2004-03-08 08:23:24
|
> > >Could you give me some pointers about what the desired behavior is. I'd >like to implement some code to get this issue fixed, since Gaim is >difficult to use as it stands now. > > Basicly, when you switch tabs, we want the focus to go to the entry. When you changed it the first time, the focus went somewhere weird when switching tabs. On chat's with a topic, it went to the topic. On IM's, I couldn't tell where it was going, but it definately wasn't going to the entry. Maybe this was before the visible cursor in the noneditable gtkimhtml, and it was going there, because it seemed to automaticly move to the entry when you typed, which make it look like IM's weren't bugged too, when really I think they were. So I think the desired behavior is focus goes to the entry after a tab switch, but can easily be changed with the keyboard. This is apparently tricky to do, due to some interactions with the notebook automaticly focusing the first widget. Or so I've been told, I haven't looked at it too closely. --Tim Ringenbach |
From: Mark D. <ma...@ki...> - 2004-03-24 05:07:52
Attachments:
gaim.diff
|
We should do something about this patch. It's good, but after applying it, when you switch tabs on a conversation window focus is given to the top widget and it needs to be given to the text entry widget. I just tried to fix that for way to long, so I'm going to give up for a little while. I tried messing around with the focus chain, and I made it so the text entry widget is focused first, but then I couldn't get the conversation log to come directly after the text entry box when typing shift+tab. -Mark On Mon, 08 Mar 2004 01:00:17 -0700 (MST), Marc Mulcahy wrote > Hi Nathan, > > Gaim as it exists in CVS is difficult to use, sine although the gtkimhtml > widget is accessible via the keyboard, is isn't focussable. Ths appears > to be for two reasons-- one is that shift-tabs get passed to the gtkimhtml > and then cause the focus to shift back to the entry. This diff > fixes this by adding GDK_ISO_Left_Tab to the list of allowed keys in > the gtkimhtml. > > The other issue is, as we've discussed previously, related to the > fact that the conversation container has a signal handler on it for "focus" > which always puts the focus in the entry. This makes it impossible, > using only the keyboard, to focus anything but the entry. You had mentioned > previously that removing the signal handler for "focus" had some > undesirable side-effect in chat windows. I think it related to switching > tabs. When I switch tabs to a different chat, the focus seems to be > placed in the correct widget for me. > > Could you give me some pointers about what the desired behavior is. > I'd like to implement some code to get this issue fixed, since Gaim > is difficult to use as it stands now. > > This diff removes the focus signal handler on the pane, and adds the > GDK_ISO_Left_Tab key to the allowable keys for gtkimhtml widgets. > I'm successfully using Gaim with this patch and Gnopernicus now. > > Marc -- O O Mark Doliner \ | ma...@ki... \ | www.kingant.net "There needs to be a better word for weird." |
From: Marc M. <Marc.Mulcahy@Sun.COM> - 2004-05-26 05:00:42
|
Hi Mark, All, Sorry, somehow this message got lost in my inbox. I've attached a patch which seems to fix the focus/keynav issues in the conversation window for me. I applied this patch, and when using ctrl-page up and ctrl-page down to switch tabs, the focus seems to go to the text entry widget in both IM and chat windows, which is the desired behavior. I'm a blind guy, so I don't use a mouse to switch tabs, so I can't reproduce the behavior people are seeing of the focus going to the wrong control when switching tabs. I wonder if the behavior is different when using the keyboard than it is when using the mouse to switch tabs. This patch does the following: * Adds tab and shift tab to the "allowable" keys processed by the gtkimhtml's window. * Removes the "focus" signal handler on the pane -- this handler prevents focus from ever leaving the text entry widget. I'd really like to get this fixed somehow -- Gaim's nearly impossible to use for blind folks, since you can get the focus to anything but the text widget with the keyboard. I'm more than happy to hack on this if anyone has any suggestions. sorry to be a squeaky wheel on this -- I love Gaim and would like to get something workable for blind users (I've been using a patched local copy to work around the focus/keynav issues for several months). thanks, Marc On Wed, 24 Mar 2004, Mark Doliner wrote: > We should do something about this patch. It's good, but after applying it, > when you switch tabs on a conversation window focus is given to the top widget > and it needs to be given to the text entry widget. > > I just tried to fix that for way to long, so I'm going to give up for a little > while. I tried messing around with the focus chain, and I made it so the text > entry widget is focused first, but then I couldn't get the conversation log to > come directly after the text entry box when typing shift+tab. > > -Mark > > > On Mon, 08 Mar 2004 01:00:17 -0700 (MST), Marc Mulcahy wrote > > Hi Nathan, > > > > Gaim as it exists in CVS is difficult to use, sine although the gtkimhtml > > widget is accessible via the keyboard, is isn't focussable. Ths appears > > to be for two reasons-- one is that shift-tabs get passed to the gtkimhtml > > and then cause the focus to shift back to the entry. This diff > > fixes this by adding GDK_ISO_Left_Tab to the list of allowed keys in > > the gtkimhtml. > > > > The other issue is, as we've discussed previously, related to the > > fact that the conversation container has a signal handler on it for "focus" > > which always puts the focus in the entry. This makes it impossible, > > using only the keyboard, to focus anything but the entry. You had mentioned > > previously that removing the signal handler for "focus" had some > > undesirable side-effect in chat windows. I think it related to switching > > tabs. When I switch tabs to a different chat, the focus seems to be > > placed in the correct widget for me. > > > > Could you give me some pointers about what the desired behavior is. > > I'd like to implement some code to get this issue fixed, since Gaim > > is difficult to use as it stands now. > > > > This diff removes the focus signal handler on the pane, and adds the > > GDK_ISO_Left_Tab key to the allowable keys for gtkimhtml widgets. > > I'm successfully using Gaim with this patch and Gnopernicus now. > > > > Marc > > -- > O O Mark Doliner > \ | ma...@ki... > \ | www.kingant.net > "There needs to be a better word for weird." > > |
From: Mark D. <ma...@ki...> - 2004-05-27 03:49:26
|
This patch cannot be applied as-is. You remove the focus signal handler... this signal handler is used to give focus to the entry widget when a new conversation window is created or when switching to a different conversation tab. This behavior MUST remain unchanged. We try to force the entry to have focus in switch_conv_cb, but that isn't working. I think gtk is choosing to set focus to the whatever it wants AFTER we attempt to grab focus for the entry. Why is this a problem in the first place? When opening a chats with a topics (eg IRC channels), a user should be able to immediately beging typing into the text entry widget. If the entry widget is not explicitly chosen to have focus, then focus is given to the "title" text entry widget at the top of the window, and that's bad. -Mark On Tue, 25 May 2004 23:02:01 -0600 (MDT), Marc Mulcahy wrote > This patch does the following: > > * Adds tab and shift tab to the "allowable" keys processed by the > gtkimhtml's window. > * Removes the "focus" signal handler on the pane -- this handler prevents > focus from ever leaving the text entry widget. -- O O Mark Doliner \ | ma...@ki... \ | www.kingant.net "There needs to be a better word for weird." |
From: Mark D. <ma...@ki...> - 2004-01-13 20:47:03
|
On Tue, 13 Jan 2004 15:27:58 -0500, Nathan Fredrickson wrote > On Tue, 2004-01-13 at 15:12, Nathan Fredrickson wrote: > > Here is a patch that implements what Sean proposed above. It allows the > > conversation log to be focused and only transfers focus back to the > > entry box on a non-CTRL-key-combination. You can still start typing > > anywhere within the window and it will go to the entry box. > > > > Other keys or modifier-keys that are important to accessibility could > > easily be added. I just did CTRL for now since that allows copying with > > the shortcut CTRL-C to work. > > I found one problem with this: CTRL-V can be used to paste text > *into* the conversation log. I could limit the patch to CTRL-C only > instead of all CTRL-key combinations, although perhaps the > conversation log should be fixed to not allow pasting into it... That's funny :-) The fix for that is pretty easy, I think you just pass a flag to gtkimhtml when creating the widget. I can take care of that. I'll probably look at this patch tonight or tomorrow night (EST) unless Sean or someone else really wants to. I've already changed the key_pressed_cb stuff some more in my CVS to make it a bit more straight forward. Does anyone know why there are a bunch of calls to g_signal_stop_emission_by_name in the key_pressed_cb? It seems like the function could just return TRUE and have the same effect. Was this maybe to work around a bug in earlier version of gtk2? -Mark -- O O Mark Doliner \ | ma...@ki... \ | www.kingant.net "There needs to be a better word for weird." |
From: Nathan F. <8n...@ql...> - 2004-01-13 21:02:35
Attachments:
gtkimhtml-editable-1.diff
|
On Tue, 2004-01-13 at 15:46, Mark Doliner wrote: > On Tue, 13 Jan 2004 15:27:58 -0500, Nathan Fredrickson wrote > > > > I found one problem with this: CTRL-V can be used to paste text > > *into* the conversation log. I could limit the patch to CTRL-C only > > instead of all CTRL-key combinations, although perhaps the > > conversation log should be fixed to not allow pasting into it... > > That's funny :-) The fix for that is pretty easy, I think you just pass a > flag to gtkimhtml when creating the widget. I can take care of that. Perhaps gtkimhtml should respect it's own editable flag when pasting text. See the one-liner attached. Unless there's some "paste-able" flag I've overlooked... > I'll probably look at this patch tonight or tomorrow night (EST) unless Sean > or someone else really wants to. I've already changed the key_pressed_cb > stuff some more in my CVS to make it a bit more straight forward. Thanks, Nathan |
From: Marc M. <Marc.Mulcahy@Sun.COM> - 2004-02-02 23:52:01
|
Hi Nathan, One option might be to create a custom focus chain for the chat window so that the message entry is the first focussable widget inside it. I'll look into this. I'm having trouble building gaim at the moment-- it intermittently breaks for me when compiling against the Mozilla NSS stuff, so not sure what I've done to hose my system this time, but... Marc On Fri, 30 Jan 2004, Nathan Fredrickson wrote: > Hi Marc, > > On Wed, 2004-01-28 at 19:04, Marc Mulcahy wrote: > > 1. The "focus" signal handler on the pane which forces focus to the > > outgoing entry doesn't allow one to tab and shift tab off the outgoing > > text entry, removing it makes things work great for me. > > I'm the one responsible for re-adding that signal handler which your > original patch removed. It was re-added to fix a focusing issue in chat > windows (only chat, not IM windows). > > When switching tabs in a chat window, focus is supposed to go to the > message entry box, but instead it's going to the topic entry box. It > appears that the panel gets focused first which in turn focuses the > first focusable widget: the topic entry. > > I'm sure there is a better method to focus the message entry first, and > then the signal handler on the pane can be removed. Patches welcome :-) > > > 2. It might be nice to also include home and end as keys which are allowed > > to be typed into the gtkimhtml. > > I agree, especially since we're already including the arrow keys. I'll > make a patch as soon as I can connect to the anoncvs to update my tree. > > > Thanks so much for doing all this work! I love using Gaim! > > Thanks for all the accessibility work you've done on Gaim. > > Nathan > > > |
From: Marc M. <Marc.Mulcahy@Sun.COM> - 2004-05-26 16:48:20
Attachments:
gaim-focus.patch
|
Helps to attach the patch, sorry. Marc On Tue, 25 May 2004, Marc Mulcahy wrote: > Hi Mark, All, > > Sorry, somehow this message got lost in my inbox. I've attached a patch > which seems to fix the focus/keynav issues in the conversation window for > me. > > I applied this patch, and when using ctrl-page up and ctrl-page down to > switch tabs, the focus seems to go to the text entry widget in both > IM and chat windows, which is the desired behavior. I'm a blind guy, so I > don't use a mouse to switch tabs, so I can't reproduce the behavior people > are seeing of the focus going to the wrong control when switching tabs. > I wonder if the behavior is different when using the keyboard than it > is when using the mouse to switch tabs. > > This patch does the following: > > * Adds tab and shift tab to the "allowable" keys processed by the > gtkimhtml's window. > * Removes the "focus" signal handler on the pane -- this handler prevents > focus from ever leaving the text entry widget. > > I'd really like to get this fixed somehow -- Gaim's nearly impossible to > use for blind folks, since you can get the focus to anything but the > text widget with the keyboard. I'm more than happy to hack on this if > anyone has any suggestions. sorry to be a squeaky wheel on this -- I love > Gaim and would like to get something workable for blind users (I've been > using a patched local copy to work around the focus/keynav issues for > several months). > > thanks, > > Marc > > > > On Wed, 24 Mar 2004, Mark Doliner wrote: > > > We should do something about this patch. It's good, but after applying it, > > when you switch tabs on a conversation window focus is given to the top widget > > and it needs to be given to the text entry widget. > > > > I just tried to fix that for way to long, so I'm going to give up for a little > > while. I tried messing around with the focus chain, and I made it so the text > > entry widget is focused first, but then I couldn't get the conversation log to > > come directly after the text entry box when typing shift+tab. > > > > -Mark > > > > > > On Mon, 08 Mar 2004 01:00:17 -0700 (MST), Marc Mulcahy wrote > > > Hi Nathan, > > > > > > Gaim as it exists in CVS is difficult to use, sine although the gtkimhtml > > > widget is accessible via the keyboard, is isn't focussable. Ths appears > > > to be for two reasons-- one is that shift-tabs get passed to the gtkimhtml > > > and then cause the focus to shift back to the entry. This diff > > > fixes this by adding GDK_ISO_Left_Tab to the list of allowed keys in > > > the gtkimhtml. > > > > > > The other issue is, as we've discussed previously, related to the > > > fact that the conversation container has a signal handler on it for "focus" > > > which always puts the focus in the entry. This makes it impossible, > > > using only the keyboard, to focus anything but the entry. You had mentioned > > > previously that removing the signal handler for "focus" had some > > > undesirable side-effect in chat windows. I think it related to switching > > > tabs. When I switch tabs to a different chat, the focus seems to be > > > placed in the correct widget for me. > > > > > > Could you give me some pointers about what the desired behavior is. > > > I'd like to implement some code to get this issue fixed, since Gaim > > > is difficult to use as it stands now. > > > > > > This diff removes the focus signal handler on the pane, and adds the > > > GDK_ISO_Left_Tab key to the allowable keys for gtkimhtml widgets. > > > I'm successfully using Gaim with this patch and Gnopernicus now. > > > > > > Marc > > > > -- > > O O Mark Doliner > > \ | ma...@ki... > > \ | www.kingant.net > > "There needs to be a better word for weird." > > > > > |