discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Comments


From: Tyson Whitehead
Subject: Comments
Date: Mon, 26 Mar 2001 12:09:25 -0500

Martin wrote:
Hi, -

What do you think about creating gnustep-doc-user and
gnustep-doc-developer packages? I'll explain further....
 

<snip>

I think that is a GREAT idea...

On another front.  I'm a C/C++/ASM programmer just learning Objective C.  I downloaded all the code and compiled GNUStep okay after a bit of messing around.  As someone new to the project I have two comments (perhaps relevant as you do want new converts *grin*).

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)??

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

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

PS:  Remove the "_words" to email me directly...

-- 
 Tyson Whitehead  (address@hidden)
 Computer Engineer                          Dept. of Applied Mathematics,
 Graduate Student- Applied Mathematics      University of Western Ontario,
 GnuPG Key ID# 0x8A2AB5D8                   London, Ontario, Canada
 
reply via email to

[Prev in Thread] Current Thread [Next in Thread]