[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments --> Pop-up application menu by function key
Pascal J. Bourguignon
Re: Comments --> Pop-up application menu by function key
Tue, 27 Mar 2001 05:22:44 +0200 (CEST)
> From: Tyson Whitehead <address@hidden>
> 1) The sample applications ran quite a bit slower than I expected (i.e. I
> watched them draw/redraw various items on the screen). It was quite
> painful compared to the joe average X or Win32 application that I run on
> my system -- quite a bit like my experience with Enlightenment, the GNOME
> desktop, and maximum chrome. Granted, my home machine is a 133Mhz Pentium
> with 128MB of RAM. However, my understanding was that the original NEXT
> machines were quite a bit slower than a 133Mhz Pentium, the NEXT machines
> performed very acceptably, GNU Objective C is more efficient then NEXT
> Object C... hummm? Is the current speed any indication of the expected
> final speed?? Perhaps one part of the system killing off its performance
> (i.e. the X rendering back end)??
Up to now, I use it on a PII 90MHz/40MB RAM, and it does not feel
slower than on a NeXTstation Turbo 68030 33MHz/32MB RAM (but neither
> 2) My biggest complaint was being forced to use "Click to focus mode" (at
> worst I can fix number one by buying a faster computer).
This is the feel of NeXTSTEP/OPENSTEP.
> The system is
> quite unusable in "Sloppy focus" or "Focus follows mouse" mode, as it is
> near impossible to get to the menu in the upper left hand corner of the
> Looking at NeXT shots, would indicate to me that these menus in
> the upper left hand corner of the screen was how NeXT did things.
There's more than the look, there's the feel too. And the feel of
NeXTSTEP which we're trying to reproduce too is definitely "Click to
> However, I resent them for two reasons. The first is forcing me into
> "Click to focus" mode. The second is forcing me to do a bunch more work
> every time I want to access the menu (i.e. take my hand off the keyboard,
> move the mouse to the upper left hand corner of the display, use the menu,
> move by mouse back, place my hand back on the keyboard).
However, I don't believe it would be extremely difficult to make
GNUstep work with other modes. For example, even on NeXTSTEP, some of
"focus follows mouse" was implemented for the "Steal focus" function
of Terminal.app to allow to debug an application without sending
activate/deactivate events to its windows.
> This second reason actually stems from the same source as the first. The
> reasons I like "Sloppy focus" and "Focus follows mouse" modes (with a
> delayed raise) so well, is because they save me a mouse click. Yup, I
> wouldn't have believed one mouse click made such a big difference either
> until one of my friends practically forced me to try it out. Just try
> doing some remote platform embedded development between about one or two
> emacs windows, one minimcom window, and two xterm windows in both modes
> and it takes about thirty minutes to become a hardcore convert (it is
> seriously just that much better).
I consider "Sloppy focus" and "Focus follows mouse" quite dangerous ;
they would need much more control on the mouse movement that what can
be humanly provided. I usually use both all my hands to type on the
keyboard, and the mouse is then free to flee from my cat. That would
be awfull if my characters were to go to the wrong window (think:
entering a password vs. IRC).
However, with twm, I would not dare using "Click to focus". Each
environment has its own feel.
> As a result of that and other things, I
> have become convinced that saving unnecessary movements is a good thing
> (especially from keyboard to mouse and vica versa). So I don't think much
> of having to haul my mouse to the upper left hand corner of the screen and
> back every time I want to access the menu.
Neither do I, and neither do most of the experienced user of
NeXTSTEP. We usually hide the menu out of a corner of the screen, and
activate the pop-up menu out of the right button. Note however that
some mouse movement may be in order because only on the "desktop" the
right mouse down is guaranted to pop up the application menu. In
another window, the application get a chance of providing us with a
local (view-specific) menu. This is already implemented by GNUstep.
OpenStep does not specify anything concerning function keys. I would
not mind if the GNUstep Preference application would allow the user to
configure some function key to pop up the application menu, like
WindowMaker does, and then allowing navigating in it with cursor keys.
(This should probably go to the NSApplication object, in its handling
of events, and with perhaps some additions to NSMenu).
> And no, I don't believe that
> 'this is they way NeXT did it' is a good reasons for GNUStep to do it the
> same (while it might be possible to convince me that NeXT had a lot
> figured out, the size of the project and the laws of probability dictate
> that I write people off as fanatics [and stop listening to anything they
> have to say] who refuse to even consider something that is not an exact
> copy of NeXT). Could not this menu be tied to the third mouse button?
> Like WindowMaker's popup 'App' menu (which makes a lot of sense compared
> to MS's 'Start' menu -- why should accessing the applications be limited
> to the bottom left hand corner of the screen??)? Or maybe a key on the
> keyboard (the 'Window's key')? Or maybe a mouse keyboard combo??
> Thanks in advance for any reasonable (i.e. not fanatical) resulting
Well, now that we've specified a new function for GNUstep, please,
feel free to try and implement it and submit a patch ;-) That would be
a good exercise to learn Objective-C and a good entry point into
GNUstep (NSApplication/event handling and NSMenu).
__Pascal_Bourguignon__ (o_ Software patents are endangering
() ASCII ribbon against html email //\ the computer industry all around
/\ and Microsoft attachments. V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100 2001:my($f)=`fortune`; http://petition.eurolinux.org/