[WASTE-list] Multiple views, shared controller (was: Re: WASTE 3.0 ClickLoop)

[Marco Piovanelli]

On Thu, 24 May 2007 10:26:50 -0700,
Richard Laws (manistyman at yahoo.com) wrote:



>One of the reasons I set aside my

>WASTE-view-within-a-HIScrollView version of my HIView

>was that I wanted a way of splitting the view to be

>able to consult (and perhaps modify, copy, paste,

>etc.) two or more sections of the text in the same

>HIViewRef.  An HIScrollView's text subview would have

>to respond to scrollable "scroll to" events with

>WEScroll.  This is where the concept of

>WEViewReference might come to the rescue.


Yes, that's the kind of scenario WASTE views were
designed for.


>Consider the following: A parent HIViewRef is created

>which creates a WASTE instance.  It then creates and

>embeds one or more HIScrollViews, each containing a

>'text' HIViewRef containing a WEViewReference created

>with that single WASTE instance.


You probably want a SplitView (possibly modeled after
the sample code in /Developer/Examples/Carbon/SplitView)
containing two HIScrollViews, each of which, in turns,
contains your WASTE-based HIView.  Each WASTE HIView
would keep its own WEViewReference, but they would share
the same controller (WEReference).


>My question is this: Would the multiple views work

>independently when receiving scroll to events?


Yes.  Each WEViewReference has its own view and destination
rectangles, and can scroll independently of the other.


>For example, I have two views of the same WEReference.

>I've set my current WEViewReference to the lower of

>the two.  I click that view's scroll bar.  I've got to

>respond to that event (sent by the parent

>HIScrollView) with WEScroll.


That WEScroll takes a WEReference, rather than a
more natural WEViewReference, is only a historical
artifact -- the original WASTE API wasn't designed for
strict model-view-controller separation, but to be a
drop-in replacement for TextEdit.  But internally,
WEScroll, and many other view-centric APIs, are routed
to the "current" view, which you can change at any point
with WESetCurrentView().

In other words, instead of introducing a bunch of
parallel view-centric APIs (WEScrollView, WESetViewDestRect,
WESetViewViewRect, WEAdjustCursorInView, etc.) that duplicate
the existing controller-centric APIs, I thought it simpler
to maintain the old APIs, with the implicit stipulation
that they operate on the current view.


>Would the upper view also scroll?


No.


>Or, not being the current WEViewReference, does it remain

>stationary and stay that way when made current again?


Yes.


                                    -- marco

-- 
It's not the data universe only, it's human conversation.
They want to turn it into a one-way flow that they have entirely
monetized. I look at the collective human mind as a kind of
ecosystem. They want to clear cut it. They want to go into the
rainforest of human thought and mow the thing down.