Re: cocoa-dev digest, Vol 1 #581 - 19 msgs
Re: cocoa-dev digest, Vol 1 #581 - 19 msgs
- Subject: Re: cocoa-dev digest, Vol 1 #581 - 19 msgs
- From: Ondra Cada <email@hidden>
- Date: Fri, 14 Sep 2001 22:29:57 +0200
John,
>
>>>>> John Geleynse (JG) wrote at Fri, 14 Sep 2001 10:29:36 -0700:
JG> And that type of request, along with any requests for new interface
JG> elements or enhanced behaviour for interface elements should be sent to
JG> me so that I can advocate on your behalf within Apple.
Thanks a lot. Actually, I would have some. I'll try to sort them
importance-wise, but of course, it is based on my personal opinion, being so
quite subjective. Also, they are based on 10.0.3, which I currently have; I
do apologize if some of them were already addressed in 10.1.
(i) bring back tearoff menus
Even if it temporarily works for Cocoa apps only, it would be still
*EXTREMELY* great. And, from a technical point of view, not difficult at all
(I even have a NSMenu category which supports that for 10.0.3; when I get
10.1 and have it working there, I will probably publish it as a freeware
extension. Your in-house solution would be *WAYS* cleaner though, since I
must hack in to AppKit to do so.).
I would be also *VERY* grateful for the possibility to pop-up the complete
application menu anywhere, just as it was possible in NeXTStep with the right
mouse button. I would recommend to use some modifier combination like
Ctrl-Alt or even Ctrl-Alt-Shift (preferrably, of course, configurable).
(ii) make windows resizable by all edges
I'd personally vote for the Mac OS X Server 1.x way as the best one I've
seen so far (preferrably improved by a defaults database item which would set
the width of the frame).
If you consider the window look (without the frame) that important, the
install-default value of the aforementioned item could be zero, making the
windows exactly the same as the current ones are.
(iii) resurrect the bring foreground / send to background functionality
The original NeXTStep way of command-click a window title to send back and
alt-click it to get to foreground (without making active) would be probably
impossible since cmd-click and cmd-drag are already used for different
purpose.
I would personally suggest to use Shift-click title to send window to
background, and Alt-click the title to bring it foreground (without making
active), to keep Ctrl reserved for possible future window-context menu.
Reason: the feature is _extremely_ convenient for making information in
partially or totally hidden windows seen, without losing the focus in active
application. A nice example of pattern I use every other minute when writing
some article is cmd-clicking the TextEdit window back, then using
Services/Grab to take an appropriate screenshot and place it automatically to
the (still active) TextEdit window.
(iv) bring back the visual distinction between main and active window
It is quite inconvenient if I happen to have some panel a key window (like
Find panel with cursor), that there is no visual track which of windows the
panel belongs to (since that window -- the main one -- looks just like all
the inactive ones).
IMHO almost any scheme will do; one possibility is opaque title + coloured
"semaphore" for key, opaque title + gray "semaphore" for main, transparent
title for inactive.
(Although I personally don't like the transparent title at all, since it
happens to be difficult to distinguish whenever it happens to float over a
white background. Therefore, I would prefer something like key: stripped,
coloured; main: stripped, gray; inactive: non-stripped, gray.)
Note: it would be even better to distinguish key/main windows by more than
just coloured/grayed "semaphore", but I have no idea how to do that without
breaking the current look. Perhaps different colour of the stripes?
(v) show in panels which application they belong to
I must admit I am mightily confused why you took out the application icon
from panels, moving them at the same time to the same tier as the other
windows -- which combined makes orientation on screen a bitch.
I would recommend either to return the app icon to panels, or placing app
name there (by default to title?), or both (possibly it can be optional?).
I would personally also appreciate if there might be an option to move all
panels to a different tier, just like it was in NeXTStep; it might be too
subjective though.
(vi) don't force panels to be floating unless vital, or offer an option
Particularly with Fonts panel it is inconvenient sometimes that is cannot go
background (partially), not obscuring the window, but (due to the uncovered
part) still be clickable.
I would recommend adding a standard title-widget for panels, which would
switch them between floating and normal ones.
(vii) put the tooltip and text drag&drop delays to defaults database
I guess there's no need to explain ;)
(viii) correct the mouse wheel behaviour
In the 10.0.3, the mouse wheel tends to scroll the first responder view,
even if the cursor is over another scrollable view. So far I understand, it
should scroll always the view the mouse is over (without making it active) --
in my understanding, that is the main advantage of mouse wheel over the more
traditional ways (like PgUp/PgDn or scroller), which all need the view to be
activated first.
(What baffles me is that is worked all right in Public Beta. Is it possible
that you consider the current behaviour to be the proper one? If so, I would
advocate for making that optionable.)
---
Ondra Cada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc