Window staggering
Richard Gaskin
ambassador at fourthworld.com
Wed Apr 12 03:46:37 EDT 2006
James Spencer wrote:
> This should be really easy and I don't want to rediscover gravity so
> I'll ask first: does anyone here have a simple algorithm for
> staggering new windows in a multiwindow app? I've gotten spoiled by
> Cocoa, etc. which takes care of this for me but cloning a template
> window in Rev does not. Obviously, I could just move my new window a
> bit but I'm not sure how far and in any case, if the number of
> windows is large enough, we need to restart at the top. I figure
> someone has written this already??
The magic of a good UI is that it *seems* easy. This one is made easy
within Apple's framework, but outside of that framework it's not so
easy. It touches on a number of things beyond a simple rect
function which a comprehensive framework can serve well, but which is
difficult to describe in an email. Just the same we'll give it a try:
Apple's recommendations are here:
<http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_17_section_4.html#//apple_ref/doc/uid/20000961-BACFHDHE>
New document windows should open horizontally
centered and should display as much of the
document content as possible. The top of the
document window should butt up against the
menu bar (or the applications toolbar, if
one is open and positioned below the menu bar).
Subsequent windows should open to the right 20
pixels and down 20 pixels. Make sure that no
part of a new window overlaps with the Dock.
Sounds simple enough, and by itself you could use something like this:
function NewDocRect pDocNum
put item 1 of the screenLoc-300 into L
put item 2 of the windowBoundingRect+24 into T
put item 1 of the screenLoc+300 into R
put item 4 of the windowBoundingRect-4 into B
--
put pDocNum*20 into tAdjust
add tAdjust to L
add tAdjust to T
add tAdjust to R
--
return L,T,R,B
end NewDocRect
But that's not enough. :( There are some exceptions not listed
in Apple's description but evident in all of their multi-window apps:
- If the user moves (but not merely resizes) the topmost
document window, the next window be created at the
original default position. Note that for Rev development
this implies some means of keeping track of which windows
are documents (I use a custom property named "fwType" for that).
- If the user creates enough new documents to go too close to
the bottom of the display, the next document is created at
the expected next horizontal location but positioned at
vertically the same as the first default location.
- To avoid overlapping the Dock, calculations are best made
from the windowBoundingRect rather than the screenRect.
There are probably a few other considerations that I'm overlooking right
now, but that'll get you started.
Given the range of this it touches on, there is no single handler that
will cover what you need. I use a combination of a frontscript to trap
window moving, properies to differentiate between document and
non-document windows, a function to return the rect based on the last
rect used, and this is tied into the routines that create new documents
so the window sizing happens before the window is drawn.
There are subtleties about when you revert to the default loc and when
you continue to increment down to the right; check out this behavior in
TextEdit.
The sizing function is the easy part; it's the infrastructure to
support it, and knowing when to reset it, that'll keep ya' busy. ;)
You can see my most recent implementation in action in this app made for
ResearchWare:
<http://www.researchware.com/ht/index.html>
It got a reasonably good review in this month's MacAddict, not too bad
for a v1.0:
<http://www.macaddict.com/issues/2006/4/reviews/transcribe>
If you spot any behavioral differences between mine and, say,
TextEdit's, go with TextEdit's. :) There are still a few imperfections
in mine, but it had been lot of work and we had to move on to
deal with QT performance issues (thanks to Mark Waddingham for coming
through on QT stuff so well in the last couple versions).
We're enhancing the window/document management stuff (and menu bar
updating routines, and a whole lot more) and moving them into another
app for that client, which will be the focus of my "Bionic App"
presentation at RevCon West: <http://www.revconwest.com/>
Maybe we'll see ya' there?
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.com
More information about the use-livecode
mailing list