[Bug 969359] Re: [keyboard]: gnome-settings-daemon consumes 100% cpu (and blinking numlock)
I'm seeing this on 12.04 with 3.4.2-0ubuntu0.2. It's not only eating most of the CPU, but also tons of memory - this morning I unlocked the computer and g-s-d had 4.3GB VIRT, 3.2GB RES! After killing, it only takes 450M VIRT and 8M RES. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-settings-daemon in Ubuntu. https://bugs.launchpad.net/bugs/969359 Title: [keyboard]: gnome-settings-daemon consumes 100% cpu (and blinking numlock) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-settings-daemon/+bug/969359/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1000675] [NEW] apt://package URLs not recognized as URLs
Public bug reported: [ubuntu/debian specific feature request] URLs such as http://foo are underlined when hovered and ctrl+clickable to open. It'd would be nice to recognize apt:foo or at least apt://foo, so READMEs, outputs of commands like apt-cache search etc. could privide ctrl+clickable links to packages. [upstream feature request, which would include the above] More generally, gnome-terminal should highlight any URL scheme supported on the system (specifically by epiphany). I guess the canonical place to check is gconf /schemas/desktop/gnome/url-handlers Not sure if bare scheme:foo should be supported or only sheme://foo which have less false positive. But since the behavior is unobtrusive (only highlighted when hovered), I think both. ** Affects: gnome-terminal (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1000675 Title: apt://package URLs not recognized as URLs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1000675/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 666418] Re: gnome-terminal.wrapper doesn't wait until program finishes
Still happens on Precise with gnome-terminal 3.4.1.1. According to https://bugzilla.gnome.org/show_bug.cgi?id=664730 fixed in upstream. ** Bug watch added: GNOME Bug Tracker #664730 https://bugzilla.gnome.org/show_bug.cgi?id=664730 -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/666418 Title: gnome-terminal.wrapper doesn't wait until program finishes To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/666418/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 666418] Re: gnome-terminal.wrapper doesn't wait until program finishes
Yes, the situation is the same on natty. Googling more, it seems there is a similar situation with konsole. So to portably launch a command in a terminal and wait for it to finish, one currently needs to special-case each terminal, like http://hg.netbeans.org/cnd-main/file/tip/cnd.debugger.gdb/src/org/netbeans/modules/cnd/debugger/gdb/proxy/ExternalTerminal.java#l209 I didn't find a proper definition of how x-terminal-emulator SHOULD behave, but: - http://bugs.debian.org/481123 says Without such an option, urxvtc cannot be an x-terminal-emulator alternative, because x-terminal-emulator is expected not to return before the terminal window is closed. - It's clearly intended to be xterm-compatible, and xterm -e command waits. - If it waits, caller has freedom to background it; if it doesn't caller has *no way* to wait for completion of command. ** Bug watch added: Debian Bug tracker #481123 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481123 -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/666418 Title: gnome-terminal.wrapper doesn't wait until program finishes -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 666418] [NEW] gnome-terminal.wrapper doesn't wait until program finishes
Public bug reported: Binary package hint: gnome-terminal gnome-terminal -e some_program usually (if another gnome-terminal is already running) returns immediately; most other terminal emulators (e.g. xterm) return only after the program finishes, which is much more convenient when opening programs in a terminal from scripts. gnome-terminal --disable-factory -e some_program does wait, which solves the issue - unless you're writing a portable script and use x-terminal-emulator -e some_program where you'll get different behavior depending on the alternative selected for x-terminal-emulator. And you can't use x-terminal-emulator --disable-factory -e some_program because xterm etc. will barf on it. IMHO, gnome-terminal itself should always wait for the command to return. But defaulting to no-factory mode would lose all benefits for which the factory was created; waiting for completion notification from the factory would solve it better but I have no idea if it's easy to implement. An easier solution is to always add --disable-factory in gnome-terminal.wrapper. This would keep the behavior of gnome-terminal but unify the behavior of x-terminal-emulator. ** Affects: gnome-terminal (Ubuntu) Importance: Undecided Status: New -- gnome-terminal.wrapper doesn't wait until program finishes https://bugs.launchpad.net/bugs/666418 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 128735] Re: Notification Area on second screen's panel doesn't work
gnome-panel - 1:2.30.2-0ubuntu1 - Fix issues with old-style multiscreen setups (lp: #128735) Thanks for the patch. But does the wording mean there is a new-style multiscreen setup I'm missing out? :-) -- Notification Area on second screen's panel doesn't work https://bugs.launchpad.net/bugs/128735 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 573129] Re: Keyboard layout indicator cannot be removed from panel
*** This bug is a duplicate of bug 519372 *** https://bugs.launchpad.net/bugs/519372 ** This bug has been marked a duplicate of bug 519372 Regression: keyboard layout indicator cannot be hidden -- Keyboard layout indicator cannot be removed from panel https://bugs.launchpad.net/bugs/573129 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-settings-daemon in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 549654] Re: no keyboard indicator applet
One problem with it being a notification area icon is that it's less usable on dual monitor setups. You could have a separate layout indicator applet on every monitor, but have 2 notification areas just don't work. [This is a long know bug #128735, which is hard to solve due to the design of notification area.] The new Indicator Applet does works well when instantiated twice, so I can see and adjust volume power on both monitors. It'd be sweet if the keyboard layout management could be migrated to the new indicator framework as well... -- no keyboard indicator applet https://bugs.launchpad.net/bugs/549654 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-applets in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 15495] Re: Archive Manager doesn't mean anything if you don't know what an archive is
@Krzysztof Kosinski: The simple user doesn't recognize the difference between compression and archiving, because he has no use for archiving. Why would anyone want to clump files together if it offers no savings in disk space? On the contrary, the simple user nowdays doesn't care about file sizes and disk space, but does care about attaching a dozen files to an email vs. attaching one archive. (The ideal fix for that use case would be to support attaching whole directories. They can be transparently converted to an archive when you attach them and exploded to a directory when you save an attachment. But this won't be ubuquitous any time soon, so we still need an easy way to explicitly handle archives.) Anyway, I agree with your analysis of Compress... being best. -- Archive Manager doesn't mean anything if you don't know what an archive is https://bugs.launchpad.net/bugs/15495 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a direct subscriber. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 15495] Re: Archive Manager doesn't mean anything if you don't know what an archive is
+ Another word: pack seems to capture both meaning, while not exactly stepping on package reserved for .debs? + What about expanding the vague meaning of the operation by labeling the menu Combine / Compress...? + What about letting the option explain itself in a submenu? Something like: - Create file.tar.bz2 - Create file.zip - Other / help me choose... Benefits: - A submenu header is less threatening than a Compress... button, so it helps dicovery. - A submenu allows including the familiar ZIP. - A submenu allows fast access to common functionality. (Perhaps it should grow to include formats you have used, a-la Open With?) In any case, I think the real bug is that users don't understand these operations, and playing with the wording can only help users stumble upon the functionality. But will they successfully compelete their task? With , will they understand what it does and whether they want it? Will they choose the best format? The current dialog looks like this: ICON Filename: __file [ .tar.gz | ▽ ] Location: [ places | ▽ ] ▷ Other Options [Help] [Cancel] [Create] (where Other Options expands to Password, Encrypt, Split - greyed out most of the time!) The harder part of the fix is re-designing the dialog to be educational! It's a hard task, and I don't have a polished proposal, only a starting-point suggestion: Save result as: __fileFormat: Location: [ places | ▽ ]┌───┐ │ .zip - cross-platform │ [x] Combine many files into one. │ .tar.bz2 - compress well │ │...│ [x] Compress - create a smaller file(s). └───┘ Without compression, Tar + BZip2 - very good the files take 5.2 MB. compression, somewhat slow, easy to open on Linux Mac. ▷ Other Options [Help] [Cancel] [Create] [x] Combine would be greyed out if only one file is seleted. (Or entirely omitted? I think educating users about the ability is important.) When it's unselected, many files can be compressed individually (a message warning of that should appear below the checkbox). The [x] Combine and [x] Compress boxes would grey out irrelevant lines in the formats list; clicking a line in the format list would assign [x] Combine and [x] Compress to the appropriate values; typing an extension in the filename output would also choose format and checkboxes. Additionally, I'd argue that the [x] Compress section should also notify you when you have selected uncompressed images / audio / videos, and at least point you to the appropriate applications. Ideally, it should allow you to directly: - Compress losslessly to PNG and FLAC - Compress lossly to JPG, Vorbis, Theora - Reduce resulution / sampling rate This is major new functionality, but it's very useful for sending/uploading files, and it's part of what the user might expect from an option called Compress Instead of hiding behind but that's not what the word means I think we should cover the meanings. -- Archive Manager doesn't mean anything if you don't know what an archive is https://bugs.launchpad.net/bugs/15495 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a direct subscriber. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 15495] Re: Archive Manager doesn't mean anything if you don't know what an archive is
Ahh, it botched my ascii art. Attached above dialog proposal in .txt form (UTF-8). ** Attachment added: archive-dialog.txt http://launchpadlibrarian.net/36297669/archive-dialog.txt -- Archive Manager doesn't mean anything if you don't know what an archive is https://bugs.launchpad.net/bugs/15495 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a direct subscriber. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 296585] Re: Archive Mounter action should open mounted folder
Ha? Still broken on a fresh install of Karmic [amd64], fully updated. Archive mounter runs: /usr/lib/gvfs/gvfsd-archive file=%s This creates the mount, but doesn't open it in nautilus. Nautilus does know that a new mount was created - it shows it in the sidebar. One (correct?) fix would be for nautilus to automatically open a new window for the mount, as it does for inserted media. A simpler fix would be for Archive Mounter (/usr/share/applications/mount-archive.desktop) to run: nautilus archive://URL encoding of file://file (probably needs a wrapper script to achive the correct encoding). This triggers the mount automatically, and displays it in a new nautilus window. [tested on .zip and .iso files] -- Archive Mounter action should open mounted folder https://bugs.launchpad.net/bugs/296585 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 295989] Re: Archive mounter should have better name
@A. Walton: dlocate -S /usr/share/applications/mount-archive.desktop nautilus: /usr/share/applications/mount-archive.desktop It is packaged as part of nautilus [checked on Karmic]. It execs gvfsd-archive file=%s to do the work, which is packaged in gvfs-backeds: dlocate /usr/lib/gvfs/gvfsd-archive gvfs-backends: /usr/lib/gvfs/gvfsd-archive @mac_v: The bug you mention is #296585. -- Archive mounter should have better name https://bugs.launchpad.net/bugs/295989 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 382703] Re: Home Folder has 3 different names
I doubt 'Homme' in French makes sense. Home is a house, flat, not a directory on a computer (which is inside of a home). 'Kuća' in Croatian is also very... I said it already :) By same logic: I doubt 'Home' in English makes sense. Home is a house, flat, not a directory on a computer (which is inside of a home). What people frequently forget about silly-sounding translations of English computer terms is that they are just as silly in English! Non-native English speakers have just accepted their double normal/technical meaning because they were foreign. WRT to the bug, note that: - GNOME puts a house emblem on the folder, so if you change the name, you should also change the emblem. - The filesystem has them under /home, and sooner or later may users are exposed to that. Be careful of names like User Folder lest users look for it under /usr :-) Renaming it for UI consistency risks users facing a bigger inconsistency later. (The real fix is renaming fixing FS names, like Mac OS X. But that's controversial.) -- Home Folder has 3 different names https://bugs.launchpad.net/bugs/382703 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 431176] Re: karmic: gdm should not start in single user (recovery) mode
If I understand the fix correctly, this is a bad idea. It used to be, until recently (karmic bleeding edge), that I could boot the recovery option, do my stuff in single-user mode, and proceed to a graphical boot. But now, not only GDM doesn't run by itself, running it manually appears to have no effect! I'm forced to reboot in normal mode to get GDM. /etc/init/gdm.conf is the wrong place to do this decision. It causes a manual start gdm to silently fail! The correct way to not start gdm automatically would be to boot into a different runlevel. IIRC on debian runlevels 2 and 3 (?) don't include GDM. And it's not clear that single-user recovery mode is a 1:1 indication that a text-only mode is desired. - If generally useful, it could be a (third?) option in the boot menu. - If sometimes useful after recovery, the Resume normal boot menu option could be split into 2 options: Resume normal graphical boot vs. Resume boot to text-only login. - If the motivating desire is convenience of recovery work with full-fledged login, maybe the recovery menu should be enhanced to offer many consoles, job control etc. (I got used to automatically start single-user work with several openvt commands.) -- karmic: gdm should not start in single user (recovery) mode https://bugs.launchpad.net/bugs/431176 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gdm in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 385369] Re: Show Current Layout should track layout changes
Upstream bug (independently reported): http://bugzilla.gnome.org/show_bug.cgi?id=346908 ** Bug watch added: GNOME Bug Tracker #346908 http://bugzilla.gnome.org/show_bug.cgi?id=346908 -- Show Current Layout should track layout changes https://bugs.launchpad.net/bugs/385369 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 80702] Re: Keyboard indicator flags are missing
http://community.livejournal.com/xkbconfig/982.html Ouch. Half a day of reading ;-/ Summary: 1. Flags represent sovereignty, and their very presence is politically loaded. Experience proved there is no way to ship flags without offending some users. GNOME removed all flags and their HIG recommends against the use of flags. http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en#internationalization (KDE ships flags but some distributions censor them. RedHat got burned and removed all flags.) 2. The use of flags to represent languages is imprecise anyway. The use of flags to represent keyboard layout is doubly imprecise and ambiguous. Finally, flags are not always visually distinct - color blindness is obvious, and many are really similar: http://www.jankoatwarpspeed.com/post/2008/10/27/You-should-never-use-flags-for-language-choice.aspx#1 3. For these reasons the keyboard indicator defaults to labels. Flags are still supported because some users (including the indicator's developer) want flags. OK, so shipping flags is a bad idea. (Technically, if this is the conclusion, the original bug is a WontFix. Should I open a new bug to discuss the spinoff?) But we still have sub-optimal usability: - The labels are not precise. The full layout names are a bit better but too long to display in panel. Layout naming is a historically a mess - some are named by country, some by language. - The labels are hard to distinguish visually. I see several improvement directions: - Write layout names in repsective script (and language?). E.g. USA / עבר / Рус. - Support: Wikipedia language choice uses this style (with full language names); googling for language flags leads to much web design advice suggesting this style over flags. - Choose labels per layout that indicate not just the language but the exact layout. E.g. Eng or QWER vs. Dvrk or PYFG is better than USA vs. USA2. - Use Jaunty's shiny new notifications on keyboard change, showing full name (in respective language). The time should probably be made shorter, e.g. 0.5 seconds. - Allow users to select indicator color per layout in the GUI. This provides as much visual distinction as flags or arbitrary images, while not confusing the user with Where would I now find a good image of dvorak? and If they allow images, why don't they ship flags?. Note that these options are non-exclusive. Any subset would help. Notifications + color together are probably an overkill, but I can't guess beforehand which is more usable. -- Keyboard indicator flags are missing https://bugs.launchpad.net/bugs/80702 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-applets in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 385369] [NEW] Show Current Layout should track layout changes
Public bug reported: Binary package hint: gnome-applets Show current layout window shows the layout that was selected at the moment it was open. It would be more convenient if it tracked keyboard layout changes in real time. That would also be more consistent, considering that it tracks keypresses in real time and highlights the corresponding keys, and even tracks LEDs. And it would feel more GNOMEful, in the spirit of no Apply and gconf... If there are reasons to prefer that the window wouldn't switch layouts by itself (e.g. performance - layout display used to be quite slow, but nowdays I find it very fast), then it should contain a dropdown with active layouts, from which it's easy to switch (and layout list ideally should be updated when layouts are changed/added). ** Affects: gnome-applets (Ubuntu) Importance: Undecided Status: New -- Show Current Layout should track layout changes https://bugs.launchpad.net/bugs/385369 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-applets in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 80702] Re: Keyboard indicator flags are missing
It's not enough addition to have the files available - we can't expect users to edit gconf manually. Enabling flags by default sounds like a good idea. But ideally there should be a easy way to toggle it from the applet. Also, once we have icons, they could also be used in the Keyboard Properties dialog - Add Layout shows a frighteningly lost dropdown of languages/countries, which could be made friendlier with addition of icons to country/language names. (Also, that menu is too slow to scroll through. It should be split by continent or just by letter ranges.) -- Keyboard indicator flags are missing https://bugs.launchpad.net/bugs/80702 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-applets in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 80702] Re: Keyboard indicator flags are missing
Note about enabling showFlag by default: Flags only show the language and don't distinguish between variant layouts (e.g. US vs. US Dvorak). So users with more than one layout for same language will experience a usability regression if we just enable showFlags! I see 3 ways to fix it: - Add a mode where the string is shown alongside the flag. - Add a mode where the string is shown over the flag. This saves space on the panel. It might be worse for people with disabilities (but wouldn't they then disable flags anyway?) - Add a way to choose personal images per layout. This allows people to represent layouts however they want, but requires effort to be used. If such flexibility is a goal, it's probably OK if people have to edit some file to change the layout-image mapping. Anyway, this can't be the only (or default) option (unless we provide cute images for each layout, which we probably won't). BTW, the string only differnetiates such layouts as USA vs. USA2. This is quite cryptic and maybe should be replaced with the full name? However some layout names are very long, so showing them would be impracticle. Also, the applet already shows the full name in a tooltip when you hover the mouse over it. -- Keyboard indicator flags are missing https://bugs.launchpad.net/bugs/80702 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-applets in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 385395] [NEW] Way to choose subset of keyboard layouts
Public bug reported: Binary package hint: gnome-applets As a user of 3 layouts (English, Hebrew, Russian), I find layout switching unconvenient and error prone. I need to press the layout switching key sometimes once and sometimes twice to toggle between two layouts. This requires a lot of mental state, so I frequently make errors and start typing in the wrong layout. What happens in practice is that I only need 2 layouts at a time: - At a given time, I work in one language context - English, Hebrew or Russian. - But English is always needed (command line, URLs, keyboard shortcuts). So removing the layout I don't need at the moment improves the switching experience a lot - with just 2 layouts (+ keyboard LED feedback), layout switching becomes trivial. But the existing interface makes removing and then adding back layouts too cumbersome to be practical. What I would really love is a way to disable layouts temporarily. (I ended up writing shell scripts to do setxkbmap en,us, setxkbmap en,ru etc. But I believe a GUI solution would benefit a lot of people in similar position.) I can imagine 2 interfaces: - Checkboxes in layout menu to disable/enable individual layouts. Ideally, clicking the checkboxes should leave the menu open. When the checkbox is disabled, the layout name should be grayed out, and skipped on keyboard switching. - Hardcoded model of 2 languages: One layout would be the primary layout, always enabled. Choosing one of the other layouts by mouse would automatically make it the secondary layout. Keyboard switching always works between primary and secondary. The second approach has the potential to be more effecient in use (by how much? one click?) but is harder to understand, less discoverable and requires configuration to enable and choose primary layout. (Can't assume primary layout is english The first approach is visually obvious, trivially includes the case where all layouts are active. In both cases (and in fact unrelated to this feature), switching by right-click would be easier if the layouts were moved from a submenu to the top level of the keyboard indicator menu. I'm not sure if switching by left-clicking the icon should include all layouts or only the enabled ones. I'm inclined to include all, because if a person placed the mouse on the indicator, he is already looking at it and the visual feedback should make repeated clicks easy. P.S. on the discoverability front, the indicator tooltip should also say which key(s) switch keyboard layout. ** Affects: gnome-applets (Ubuntu) Importance: Undecided Status: New -- Way to choose subset of keyboard layouts https://bugs.launchpad.net/bugs/385395 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-applets in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
