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 application’s 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