On Tue, Dec 12, 2000 at 11:39:43AM +0900, timecop@xxxxxxxxxxx wrote: > > There is no way to resolve duplicates - and what does it help if the > > shortcut-key is the third letter of the Word you want to select? You > > want to accelerate your work - and decyphering from some accidentally > > underlined letter which is the current shortcut does not improve your > > speed. > > First of all that's why care is (or should be) taken when determining > which letters get underlined. Second, there is no posible way you are > going to run out of 26 letters of the english alphabet on the same > menu. Remember, these keys only work while you are on that particular > menu. On most software packages (not for Linux, though), the > "underline" action keys are generally organized well enough so that it's Did you look at how Gimp works? Or are you still treating it like another textpad application? This is a dynamic plug-in environment built on the fly each time you run it. The "collisions" are between independently written software from many contributors, not all of which is included with the Gimp source tarball. So what happens when the four plug-ins in a dynamically generated sub-menu are called: _C_ool splash effect _C_ool burn-through _O_rangify _C_lout Hmm? That is the problem you must solve if you want there to be a useful underlined symbol in each entry in each menu in Gimp. You must also solve it for the multi-lingual and other cases, but just the "easy" case should be enough for now. You act as though Gimp's designers woke up and said "Aw, fuck this easy-to-implement menu shortcut stuff, we're hackers and we'll add an over-complicated solution instead" But really they considered the problems Gimp faces and found a powerful solution which accelerates for Power Users (the ones who really matter) and is easy to learn for beginners. GTK+ is perfectly capable of using accelerated labels, and many apps do use them. Specific criticism is much more helpful than alleging that they're not used at all. I explained above why dynamically generated parts of the menu structure don't use accelerators, but I don't see any reason to reject a patch for 1.3 which adds them to the non-dynamic parts of Gimp, if any are left. > Also, while this is probably a really minor issue compared to -other- > issues, when the "Help" menu is dropped down from the main gimp window > (the toolbox palette), and using keyboard to move the menu selector around > the help menu, it gets stuck when pressing "down" from "Help..." item, or > when going backwards, from "Context Help". It's really not funny that > something standard like a menu would have different behaviour depending on > the context. Aha, an actual bug. See timecop, if you try you can be helpful and find us genuine problems to fix, rather than just big moans "Your UI sucks" If no-one's fixed it already file a Gimp bug for this issue. > I imagine most of you *hate* the Win95 key that you get for free on most > keyboards (all of them now, actually) - but why not put it to good > use? Why not make it open the gimp's right click menu? Then you can > control everything from keyboard without moving the mouse at all! This is > provided that all of menu items have appropriate underlined > shorcuts. Hopefully some day they will. A Window key - mapped to Super/ Hyper, and used for... Windows. Most people who care are using these to control their... Window Manager. A properly thought out way of using a GUI. Gimp already uses too many controls that are likely to be mapped away and then "mysteriously" not work. Any way the right key would be the Menu key, not the Window one, and mine is mapped to (duh) the system Menu. > > So I guess this remains unimplemented - and I am not unhappy about this > Not to pick on the particular person who posted that message, but he might > have no problems in life. He's got both arms, hands, and has no problem > doing fine motor operations like selecting a menu. Not everyone is so > gifted. One of the reasons Linux will never succeed on the desktop is > because there is complete lack of "accessibilty" features. These > underlined keyboard things I have been talking about that most people just > shrug off as "blah, useless shit I never use" could actually come quite > handy for using the program. Not to mention that pressing a key is always > easier than moving the mouse, especially if the person has trouble doing > so, or the screen is small, etc etc. ... and timecop rambles off topic again. This is a development group, your opinions about whether "Linux will succeed on the desktop" or who would win if a tiger was attacked by a shark are not relevant, find somewhere else to vent if you must. Nick.
