Scripting approach for a splittable window?

[Joe Lewis Wilkins]

Hi David,

I guess not too many Revers are heavily into drawing applications.

Several months ago I started to do pretty much what you're describing,  
but got discouraged because I knew I had already done "something"  
similar to it years ago using FutureBasic, and it wasn't nearly as  
difficult. More direct. It was the drawing tools that gave me the most  
problems. Instead of using "panes", if I remember correctly, I had the  
master (whole) drawing off-screen, but had trouble efficiently moving  
around the drawing with scrolling, panning or zooming. Basically, I  
wanted to duplicate MacDraft in Rev, so I could give it features MD  
doesn't have and probably never will. Unless you have a very large  
monitor, as I do, dividing it into 4 panes seems to be not very  
useful, since it would be, perhaps, more useful to merely be able to  
zoom or pan portions of the master-page to the full screen.

Good luck. I look forward to your progress.

Joe Wilkins

On Sep 8, 2009, at 4:51 PM, David Epstein wrote:

> Has anybody tried to build a scrollable, horizontally and vertically  
> splittable window interface that allows a user to create and freely  
> add, delete, and edit graphic objects or fields in any pane of the  
> window?  The true "page size" might be much bigger than can be shown  
> in the window at any one time, but the objective is to let the user  
> split his view and inspect any 2 vertical regions and any 2  
> horizontal regions (as in a spreadsheet).
>
> I can think of various ways this might be approached, and wondered  
> if anyone has experience or advice.  Should we make 4 groups with  
> identical content, adjust their scroll properties appropriately, and  
> when a user edits one group automatically change all the others  
> (and, in that case, should this be done by copying a created or  
> modified object, or by replacing each entire group with a copy of  
> the changed one)?  Should we maybe keep a "master" page off screen  
> entirely, and copy objects from that master page to the appropriate  
> pane by checking the rect of each object against the pane's intended  
> scroll position?  Or should the "master" set of objects be  
> alternately hidden, shown in a pane, or cloned in several panes,  
> based on a list of their "logical" locations that gets compared with  
> the intended pane scroll positions?  Or should we maybe construct  
> each pane from an image of a rect of the master page, and when the  
> user tries to edit a pane swap in the real objects, or a scrolled  
> view of the master page?
>
> Or something else entirely?
>
> Many thanks.
>
> David Epstein