Re: GUI vs: CLI (was: Shell command in VB6)

From: Willem (willem_at_stack.nl)
Date: 04/12/04 

Date: Mon, 12 Apr 2004 15:13:11 +0000 (UTC)

Programmer wrote:
) Actually, they are. Windows are divided into "client" areas (the
) usual part used by the app) and "non-client" areas (the edges, menu
) bar, caption bar). Programmers have full control over both, if they
) want it.

I assume it's more difficult than putting them where they are normally.

)> A long time ago, AmigaOS used to have a menu bar at the top of the
)> screen which was owned by the focused app.
)
) The upper, upper bar (the caption, or title, bar) in Windows has
) three active areas: the SystemMenu on the left, the Min/Max/Close
) buttons on the right and the bar between (which, if double-clicked
) toggles between maximized and normal).

IIRC, the buttons don't react to clicks right on the window edge when
maximized. I haven't tested it, though, may be mistaken.

) You can--if you want--put your own buttons there.

Will those buttons be clickable with the mouse pointer right up against
the edge ? Or do you need a small flick back (as you described earlier) ?

) That most apps don't suggests to me there isn't a perceived need,
) or that it was tried and deemed not as good as the current method.

The second reason would certainly be true if you test it with people
who are used to the current method. And given that there are a lot of
other things very worng with the MSWindows GUI setup, I wouldn't say
that it's a very good reason at all.
(One example: What idiot decided it would be a good idea to put the close
 button right next to the maximize button ? If it sat there alone, with no
 other buttons near, you wouldn't need those pesky 'are you sure' dialogs.)

)> And those menu items *were* right against the edge, which made
)> them a lot faster to reach. I've not worked with Macs often,
)> but I seem to recall they have this too.
)
) I suppose it would be slightly faster *IF* you ran apps maxed.
) I don't see it as a significant difference--at least as I work.

Nonono, the menu of the focused app window was on the top of the *screen*
on AmigaOS. Maybe the same on MacOS, dunno. Maximized window or not.
This meant most users could blindly hit the leftmost and rightmost menus,
and could very easily hit the other menus as well.

SaSW, Willem 

-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Relevant Pages

  • Re: Mighty Mouse: a step backwards for Apple
    ... app to app or even window to window. ... It repeats the same menu items you can find in the menu bar AND contextual menus. ...
    (comp.sys.mac.advocacy)
  • Re: The Silly Dock...
    ... bar on the window and it opens up and you were right there with one click in ... the app you want and operating on the window you want. ... need to be dextrous, find keys to go through the icons, find other key combos ...
    (comp.sys.mac.apps)
  • Re: The Silly Dock...
    ... app drop down, tear-offable, the other was the window collapse ... into the top bar. ... applications open as you could only see what was currently active. ...
    (comp.sys.mac.apps)
  • Re: displaying a form
    ... you can have the name of your App in the title bar and your own icon if you wish. ... You can minimize the database window, ...
    (microsoft.public.access.forms)
  • Re: Can Someone Change My Mind About .NET?
    ... splash screen in C++ that gets a window up there quickly and then launches ... the .NET app. ... .NET does make you feel like less of a programmer since it ... hence how it resembles a scripting language. ...
    (microsoft.public.dotnet.general)