GNOME Bugzilla – Bug 642903
keyboard layout preview window issues
Last modified: 2011-03-14 17:37:43 UTC
A few things we can improve in the keyboard layout preview window. * It is currently modal of a modal. That's kinda gross. Also this is a window that would benefit from the ability to resize so I think it is fine to make it non-modal. * The Help option isn't needed. There is nothing you can do here besides look. It should be removed. * The Print option is really odd. Why would I do that? This isn't a print preview window this is a preview used to view layouts when the user is uncertain of the actual layout based on the name. It should be removed as well. * For me the initial size of the window is pretty large. Which may be OK actually but it was a little surprising to me at first. * The color used when a key is pressed is a bit dark. If we want to use that shade then we need to invert the text color. * In what is now called the "USA" layout, why does one key say "Caps\nLock" and another say "Caps_Lock"?
1. Will check that. 2. Ok. 3. IIRC "Print" was added when some guy wanted to print that image. If you want to put the printout of your layout on the wall - why wouldn't we allow that? If we take a trouble to show the layout... 5. Well, there is always conflict "too large window" vs "unreadable chars". I do not know what is the right point... As long as it gets inside minimal reasonable screen, it should be ok, I guess 6. The "pressed" color is taken from gtk theme, the widget style, GTK_STATE_SELECTED (just FYI, the unpressed color is provided by XKB). What would you recommend to use instead? Or - what color (from the style) would you recommend for the text of the pressed key? 7. Because "Caps\nLock" is an indicator, while Caps_Lock is a keycode. The indicator name "Caps Lock" is provided by XKB explicitly. The keycode name Caps_Lock goes from gtk. I will replace the last one with "Caps Lock". But I must admit it looks somewhat inconsistent - between ISO_Left_Tab and Shift_L.
(In reply to comment #1) > 3. IIRC "Print" was added when some guy wanted to print that image. If you want > to put the printout of your layout on the wall - why wouldn't we allow that? If > we take a trouble to show the layout... Just because one dude wanted to print out a layout (probably one time) doesn't mean it should be a feature sitting there unused in front of the rest of the world for ever. It doesn't help me add or select a layout at all - and so shouldn't be there. > 6. The "pressed" color is taken from gtk theme, the widget style, > GTK_STATE_SELECTED (just FYI, the unpressed color is provided by XKB). What > would you recommend to use instead? Or - what color (from the style) would you > recommend for the text of the pressed key? If you use the "selected" background color you also need to use the "selected" foreground color. > 7. Because "Caps\nLock" is an indicator, while Caps_Lock is a keycode. The > indicator name "Caps Lock" is provided by XKB explicitly. The keycode name > Caps_Lock goes from gtk. I will replace the last one with "Caps Lock". But I > must admit it looks somewhat inconsistent - between ISO_Left_Tab and Shift_L. I would just get rid of those weird underscores. Underscores look very strange as word separators outside of computer code.
1. If the dialog is not modal - what happens if the user presses "Preview" several times? Many similar dialogs? 3. It is not about "one user vs many users". It is just logical sequence - if we provide some "image" - why cannot we allow printing it? Using screenshots + gimp would give worse results than direct printing from the app. 6. I will check what I can do here. 7. They are keysyms returned by gdk. Do you propose to do global search/replace '_' -> ' ' for every keysym? We can do that.
For the record, 2 and 6 are fixed. 7 is fixed for Caps Lock only for a moment. Going to make a release for now, the discussion is still open.
3. The Print button is removed in the .ui file - can be returned back if users would ask (the C code is still there).
7. Replaced underscores with spaces, removed ISO prefix. Looks nicer. So, the only outstanding issue with modality. Will check it later.
For the record, the window title should be fixed - "Keyboard Layout" removed. And it should be correct in g-c-c as well, not only in gnome-shell.
(mid air collision) A couple other observations that came up in testing. * It would be nice to use a larger font size if possible. It is really hard to read even when expanded to full screen * The window title should show the name of the layout instead of "Keyboard Layout" - we can guess that part :) * When run as a standalone app from gnome-shell we need to ensure it has a good application name in the AppMenu in the top bar. For this we need a .desktop file.
So, just for the reference, open items: 1. Non-modal reusable preview popup in g-c-c. 8. I see what I can do. 9. Window title fix. This is easy - but wouldn't it confuse people to see just "USA" in the window list somewhere? You can easily guess while looking at the window - but if you do not have that window in front of you, it it not clear IMHO. 10. Will fix it.
10. Desktop file added.
Created attachment 181866 [details] [review] Improve app name and add icon
thanks, pushed
1. Non-modal dialog implemented. For some reason, the button "Close" is not pressable on it (even though it is not modal and not transient). Something with gtk...
9. Removed "Keyboard layout" prefix. But still think it is not nice for the window lists...
(In reply to comment #13) > 1. Non-modal dialog implemented. For some reason, the button "Close" is not > pressable on it (even though it is not modal and not transient). Something with > gtk... Is it parented to the modal dialogue? Is the modal dialogue's buttons clickable?
Actually, the preview dialog has no parent. There is "Add layout" dialog which is not modal, just transient.
[Removing GNOME3.0 target as decided in release-team meeting on March 03, 2011. This report has an "important" categorisation for GNOME3.0 but is not considered a hard blocker. For querying use the corresponding whiteboard entry added.]
The remaining issues: 1. Non-modal popup. Formally it is there but behaving oddly. Need some help from anybody more familiar with modal and transient machinary. 2. Increased font size.
To answer the first question: this doesn't work, you cannot have a non-modal window receive input while a modal is grabbing the keyboard. If you want that to work, you need to move the preview to a separate process.
It seems #1 is resolved now. The non-modal preview for the modal "add layout" popup works fine. The only unresolved is is the font size.
Changed the font size from 10 to 12. Should be better now. So, I think we're in the position to close this large bug of issues.