User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.3) Gecko/20060326 Firefox/1.5.0.3 (Debian-1.5.dfsg+1.5.0.3-2) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.3) Gecko/20060326 Firefox/1.5.0.3 (Debian-1.5.dfsg+1.5.0.3-2) Currently it is possible to configure the repeat rate of the keyboard, and the cursor blinking. What i would like to see is the ability to configure the XKB settings. (Like the panel plugin in the goodies section does, change the layout and stuff) In my opinion, this is a trivial task, something a keyboard settings dialog should provide. -- it can be done by calling 'setxkbmap', though i do not know if this is an application which all usual X servers provide. Reproducible: Always
Even more interesting would be the support for sticky keys that have no dedicated executable (as far as I know). BTW calling an external program such as setxkbmap is not the right way to do it IMHO, would be more efficient and robust to use Xkb native fns instead.
This would be kinda cool, but it's not just as simple as shelling out to a binary. You have to build the lists of keymaps, then there are a bunch of options that maybe the X install supports, maybe not. It would be a cool feature to have, though it's not by any means a "trivial task" as you say. So... get coding ^_~.
I will :) One question though, what are sticky keys? :p
(In reply to comment #3) > I will :) > > One question though, what are sticky keys? :p > I googled around, and it looks like it allows modifier keys to be handled like toggle buttons. Is this correct?
(In reply to comment #4) > (In reply to comment #3) > > I will :) > > > > One question though, what are sticky keys? :p > > > > I googled around, and it looks like it allows modifier keys to be handled like > toggle buttons. Is this correct? > ignore that... it is an X11 XKB extension option i see. I am working on it. Will send the patch to the M/L or attach it to this bug when completed.
Created attachment 595 it does the basic sticky-key configuration. Sticky keys can be configured, but there is nothing to detect if the sticky keys are disabled when the TwoKeyDisable option is set. (And it is not possible to enable the sticky keys again after that without going to the dialog)
Comment on attachment 595 it does the basic sticky-key configuration. Patch does not support 5 * Shift to re-enable Sticky keys.
Created attachment 596 It supports all basic sticky key stuff now. It supports the following: - Sticky Keys (duh...) - Two Key Disable - Five times Shift enable - Latch To Lock
Wow, excellent!
(In reply to comment #9) > Wow, excellent! > Any idea on how to notify the user when sticky keys are toggled during normal operation? In Gnome the user gets a dialog anouncing the sticky keys are toggled, with the option to cancel it. I think this is bad practice, because it is rather intrusive. But there has to be some sort of notification.
Ok, the patch is applied. As for notification, maybe a systray icon? Otherwise, I don't know.
Created attachment 604 Bounce- and Slow-keys support I have implemented bounce and slowkeys aswell. (see patch) I will add mousekeys-support too (mouse-pointer control through num-pad), but i doubt wether it belongs in keyboard- or mouse plugin.
Thanks, applied. For such simple patches, I think you can commit them directly with your own account, no need for me for that. PS: It's "Accessibility", not "Accessability"
Created attachment 608 Mouse Keys supported and SlowKeysDelay/DeBounceDelay I don't have commit access to trunk (yet?), so here is another patch. I am working on the layout stuff now. Do you have any suggestions? I am not really happy with the GUI layout of the accessibility tab, perhaps you have any suggestion for that?
(In reply to comment #11) > Ok, the patch is applied. As for notification, maybe a systray icon? Otherwise, > I don't know. Perhaps a feature for the XKB-panel-plugin from the goodies page?
The patch doesn't apply, are you sure you updated your working copy? As for the layout, I would suggest using "xfce_create_framebox_with_content ()" and placing options vertically instead of horizontally (it looks better and helps with i18n as some languages have longer sentences than others, and that doesn't work well with horizontal layouts).
My bad (again... sorry), wrong file, committed.
(In reply to comment #17) > My bad (again... sorry), wrong file, committed. > I will remember to create patches from the xfce-mcs-plugins base dir. ;)
(In reply to comment #16) > As for the layout, I would suggest using "xfce_create_framebox_with_content ()" > and placing options vertically instead of horizontally (it looks better and > helps with i18n as some languages have longer sentences than others, and that > doesn't work well with horizontal layouts). Current layout has really been packed tight. Using xfce_create_framebox_with_content() and packing options vertically means ending up with a really weird dialog size or dropping Slow / Bounce Keys. Suggestions are welcome.
Created attachment 763 Moves mouse-keys to mouse-settings-dialog and packs keyboard-accessibility features vertically.
Unfortunately, it doesn't work here, the mouse plugin crashes. Log follows: (xfce-mcs-manager:18091): GLib-GObject-WARNING **: invalid cast from `GtkCheckButton' to `GtkNotebook' (xfce-mcs-manager:18091): Gtk-CRITICAL **: gtk_notebook_append_page: assertion `GTK_IS_NOTEBOOK (notebook)' failed (xfce-mcs-manager:18091): GLib-GObject-WARNING **: gsignal.c:1667: signal `toggled' is invalid for instance `0x8bfa70' (xfce-mcs-manager:18091): GLib-GObject-WARNING **: invalid (NULL) pointer instance (xfce-mcs-manager:18091): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (xfce-mcs-manager:18091): GLib-GObject-WARNING **: invalid (NULL) pointer instance (xfce-mcs-manager:18091): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (xfce-mcs-manager:18091): GLib-GObject-WARNING **: invalid (NULL) pointer instance (xfce-mcs-manager:18091): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (xfce-mcs-manager:18091): GLib-GObject-WARNING **: invalid (NULL) pointer instance (xfce-mcs-manager:18091): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (xfce-mcs-manager:18091): GLib-GObject-WARNING **: invalid (NULL) pointer instance (xfce-mcs-manager:18091): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
When compiled with --enable-debug=full, i have no problems with the mouse plugin. It works like a charm, but the kb-plugin crashes, i tested the same with the plugin currently in svn, and the problem remains :S.
Created attachment 764 Only fixes kb-settings dialog layout. Only removes mouse-keys, and adjusts layout. should work, tested with --enable-debug=full and --disable-debug.
Created attachment 765 Adds mousekeys to mouse settings dialog
(In reply to comment #24) > Created an attachment (id=765) [edit] > Adds mousekeys to mouse settings dialog > And it does not do anything usefull... sorry.
Created attachment 766 A patch that works :) I accidently removed a flag from the command that actually enables/disables the Mouse-keys. This patch is a replacement patch for 765, it adds mouse-keys to mouse-settings dialog AND fixes makes it work.
Applied with some changes.
Created attachment 767 Fixes a compile issue with --enable-debug=full introduced with last patch. Adds systray icon to indicate mousekeys activity. Changes 'Mouse Keys' to 'Mouse Emulation' in dialog. Icon should eventually idicate which mouse-button is emulated at that moment. (1, 2 or 3).
Applied with changes (funky indent)
(In reply to comment #29) > Applied with changes (funky indent) > hehe, right... i forgot to run sed -i 's/\t/ /g' :p
Created attachment 789 Fix 'default-button' display in systray, and add 'sane defaults' in config dialog It adds a g_timeout to check for the mk_dflt_button every 100ms. There are no apparent XEvents emitted when the default-button changes, so i can't check for that. (But i could be mistaking) The Settings-dialog now has some sane defaults.
Is a 100ms timeout really needed? That'll wakeup xfce-mcs-manager 10 times per second in that case.
(In reply to comment #32) > Is a 100ms timeout really needed? That'll wakeup xfce-mcs-manager 10 times per > second in that case. > I am not really sure either, but it only wakes up the xfce-mcs-manager when mousekeys are active. A delay of 100ms gives the user the idea of 'real-time' updates, i dunno if this is nessecary, perhaps 200ms or even 300ms would be ok too. Though we probably get some bug-reports about it then.
(In reply to comment #33) > I am not really sure either, but it only wakes up the xfce-mcs-manager when > mousekeys are active. Not only xfce-mcs-manager, but also the Xserver. > A delay of 100ms gives the user the idea of 'real-time' updates, i dunno if > this is nessecary, perhaps 200ms or even 300ms would be ok too. Though we > probably get some bug-reports about it then. Hm, dunno.
Humm, I have mixed feelings about that patch: - Do you need to recreate the pixmaps every time in mousekeys_systray_timer_cb(), why not caching them? It's really small pixmaps... - Don't you leak the pixbuf? It gets created but never unref'ed every 100 ms. - I think 250ms might be enough, though I did not try neither values. It's just that 100ms is well, quite a high frequency for such a functionality.
From GTK+ API documentation: gtk_image_set_from_pixbuf () See gtk_image_new_from_pixbuf() for details. gtk_image_new_from_pixbuf () Creates a new GtkImage displaying pixbuf. The GtkImage does not assume a reference to the pixbuf; you still need to unref it if you own references. GtkImage will add its own reference rather than adopting yours.
(In reply to comment #36) > From GTK+ API documentation: > > gtk_image_set_from_pixbuf () > > See gtk_image_new_from_pixbuf() for details. > > gtk_image_new_from_pixbuf () > > Creates a new GtkImage displaying pixbuf. The GtkImage does not assume a > reference to the pixbuf; you still need to unref it if you own references. > GtkImage will add its own reference rather than adopting yours. > Good point that is a big mem-leak indeed... Caching the pixbuf's is indeed a better approach. I'd rather not have a loop at all, but have it work event-based. Problem is X does not trigger an event when this attribute changes.
Perhaps it is better to remove the systray icon for 4.4 and leave this feature for 4.6.
I'd looove to see this ASAP, for what it's worth. I am using XFCE in many low-resource PCs and this is a major problem for anyone not using the default / standrard US-en keyboard variant. Would it be possible to see any screenshots until I get to install the latest beta ?
(In reply to comment #1) > Even more interesting would be the support for sticky keys that have no > dedicated executable (as far as I know). > FYI there is xkbset, but it's good to have GUI too :)
Jani, sticky keys are supported in current SVN (already in RC1 IIRC) throigh the keyboard settings -> Accessibility
(In reply to comment #41) > Jani, sticky keys are supported in current SVN (already in RC1 IIRC) throigh > the keyboard settings -> Accessibility > I know, I was just testing that GUI, and while reading about AccessX I found that there is a cmdline tool, so I mentioned it for whoever cares :)
Created attachment 939 patch against xfce-mcs-plugin svn revision 24447 Attaching a patch to add a layout configuration tab to the notebook. It uses libxklavier. It works fine for me but has only been tested on linux x86. It might be a good idea to keep this tool optional. Comments are welcome!
> Comments are welcome! > Anybody?
Created attachment 1835 Fixes (NULL) layouts More details about the bug: http://bbs.archlinux.org/viewtopic.php?id=39529
Hmm, unfortunately large portions of your patch will need to be redone against svn trunk of the xfce4-settings module. xfce-mcs-plugins is dead; 4.4.x will be the last series to use it.
Oh. This patch is for version xfce4-xkb-4.3 that is currently latest at gentoo' portage. Sorry.
(In reply to comment #47) > Oh. This patch is for version xfce4-xkb-4.3 that is currently latest at gentoo' > portage. Sorry. Oh -- is your patch for a non-Xfce application? In that case I guess the app would need to be ported to the new framework. Sorry, I'm just a little confused here, esp. since we natively support the slowkeys/bouncekeys/etc. stuff now.
Fixed