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" <[EMAIL PROTECTED]>
Sent: Tuesday, December 12, 2000 5:56 AM
Subject: timecop's menu issue

> |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..."
> |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.

Reply via email to