Amen to everything you have said, Miles. Here in Australia, the term we use (equivalent to jackass) is "dropkick" ..... i.e. timecop is a real dropkick !! ----- Original Message ----- From: "Miles O'Neal" <meo@xxxxxxx> To: <timecop@xxxxxxxxxxx> Cc: <gimp-developer@xxxxxxxxxxxxxxxx> Sent: Tuesday, December 12, 2000 5:56 AM Subject: timecop's menu issue > timecop@xxxxxxxxxxx said... > > |Actually, no. Since you were more concerned with professionalism of my > |email rather than actually reading it, you missed the part where I talked > |about this exact problem. > > No, the problem had more to do with whether it was worth the effort to > read a long, not so well written rant in detail. I decided it wasn't. > I skimmed it, and even that felt like a timewaste. > > But onwards to your complaint. > > |There is a difference between assigning a > |shortcut key to activate a menu item when the menu is not open, and a > |key to operate the menu by using the keyboard. I know the former is > |easily customizable by pressing the desired key combo while an item is > |selected. However there is no way to set the last one, without changing > |menu definitions. Gtk provides the "_" character in gtkitemfactory and > |other places for this purpose. The top-most menus in Gimp have these > |keys, but anything below does not. I am talking something like pressing > |Alt-F to open the File menu, then pressing "O" to open the "Open..." menu. > |Or Alt-H to get to Help, then "A" to get the about dialog. etc. Most of > |you probably don't care though, and that's exactly why my original email > |generated nothing but angry responses. > > I believe I've already covered that last issue. As far as the menus go, > I for one, HATE the kind of shortcuts you're describing. I have never, > ever seen the point of them. To me, they are a *total* waste of time. > > The current sort of shortcuts work quite well. I don't recall *ever* > hearing another request (much less flame) that we change this, or even > add your feature. They may have been a request for that feature, but > it certainly wasn't a big deal like you've made it, or I think we would > all remember it and have addressed it one way or another. > > Now, since an awful lot of people seem to be very happy with the way > it is now, the current sortcuts are not likely to go away. > > In light of that, would you care to prpose a solution? There's no > guarantee it would get implemented, without knowing the impact in > terms of effort vs payoff. But if you suggest a solution, it would > certainly be considered. > > |You consider adding this kind of a > |feature a waste of time, > > You have no idea what any of us think about anything until you ask us. > (Or provoke us, but how productive is that? 8^) > > |and at the same time focus on adding useless non > |customizable features like tearoff menus. > > A lot of people like them. You may not, but that doesn't > make them useless. They're there because people *wanted* them. > (In fact, they're handled in the Gtk, because people wanted > them. Have you looked at the Gtk customization, to see > whether they can be turned off?) > > |By the way, in the "real world" the features I described above fit under > |the category of "accessibility". It's about allowing people with > |disabilities to use full features of your program. > > Any particular reason you didn't bring this up before? > > -Miles, I can spell, but there are probably some typos herein. >
