Re: Comments --> Pop-up application menu by function key

[Pascal J. Bourguignon]

> From: Tyson Whitehead <twhitehe@julian.uwo.ca>
[...]
> 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
faster...).


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

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


> 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
> discussion,
> -T

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/