[kepler-dev] scrollbar additions to kepler

[Edward A Lee]

At 03:06 PM 7/27/2004 -0700, Chad Berkley wrote:
>Edward A Lee wrote:
>>I'm a bit confused about the basic motivation here...
>>A while ago, we had quite a bit of internal discussion about how
>>to handle navigation, and we ruled out scrollbars because they
>>make less sense for an infinite canvas...  How do you intend
>>the scrollbars to work?  How do you choose the boundaries?
>
>In this prototype that i've been working on, i've been choosing the 
>boundaries to be the actual size of the model and resizing the scrollbars 
>dynamically as the size of the model increases.  The canvas is still 
>infinite, but the viewport resizes (via the scrollbars) to accomodate the 
>model.

But how do I increase the size of the model?  The scrollbars
presumably won't take me beyond the boundary of the current model size.
I presume I could drag object offscreen, but this seems like a kludge (?).
The current panner easily and naturally moves beyond the current boundaries
of the model...

>Do you see a problem with this approach?  The other way I've seen 
>applications do this is just to set the scrollbar max to a very large 
>value and position both the vert and horiz bars in the middle of the 
>range.  It effectively makes the canvas finite, but is anyone really going 
>to create a model that's 2 miles x 3 miles?  If they did, I think we would 
>accuse them of bad programming practice :)

Having a large area will make the scrollbars too jumpy...
I.e., moving the scrollbars one pixel will move the canvas a few feet
if the total size is a few miles...

So how big is big enough?


>>The other question is about why you want scrollbars in the first place.
>>Is it mainly to create a familiar feeling, or is there really
>>a functionality issue?  They take some of the real estate
>>away from the drawing area... Maybe if you give the users some
>>time with the panner they will get used to it and decide they
>>like it after all...
>
>It seems like everytime we sit someone down with this they comment about 
>the lack of scrollbars for navigating the canvas.  I personally have no 
>problem with the panner, but it's still nice to have a choice of how you 
>want to navigate the canvas.  If you just want to move the view down a 
>little bit, it's much easier to click the down arrow on the scrollbar than 
>to move the panner a touch.  The panner can be too touchy for moving the 
>view small amounts due to it's low resolution compared to the canvas.

Perhaps the panner could be enhanced with, say, arrow buttons that
move the canvas a bit in each direction.  Ah, I see you are suggesting
that below (great minds think alike :-)... Another alternative would
be to just bind the arrow buttons to do fine-grain movement.


>Another idea is that instead of having the traditional scrollbar with a 
>slider, we could just use a set of 4 arrows to micomanage the canvas. That 
>way, if you want to nudge the canvas around the viewport by a few pixels, 
>you could just click the arrows instead of using the panner. Without the 
>scroll slider, the canvas would effectively remain infinite.

I would consider associating these buttons with the scrollbar somehow...


>>Photoshop, IMHO, is not a UI to emulate... But in any case, it
>>always has a finite canvas size, so this is less of an issue.
>>I think our infinite canvas is really much nicer for our purposes,
>>since limiting to a "page size" makes no sense in our case.
>
>Photoshop and Illustrator both have a finite canvas, but that canvas can 
>be very big.  I find the scrollbars to be very effective for navigation on 
>the canvas, especially when combined with the hand tool.  Note that you 
>can quickly change to the handtool in Illustrator by holding down the 
>spacebar, which is quite convenient.

That sounds like a reasonable interface (holding the spacebar
to get the hand)...

Edward


>>I agree with Steve that the major pitfall with the hand is
>>that you have to set a "hand mode" for the UI to use it.
>>It seems the prevailing "religion" in UI circles is that
>>modal behavior is a bad thing... and it is a nuisance to
>>have to be switching back and forth between modes...
>>If you can find a way to do without modes (and within
>>the Mac's one-button limitation), then that would be great.
>
>Personally, I don't see what the big deal is.  I've been using modal GUIs 
>for a long time and have never had a problem with choosing a navigation 
>tool instead of a drawing tool.  That said, I consider myself an advanced 
>user with most programs like this (i.e. Photoshop and Illustrator).   I'll 
>try to figure out a way to do this...possibly with a keyboard shortcut or 
>something.
>
>chad
>
>>Edward
>>
>>At 10:47 AM 7/27/2004 -0700, Chad Berkley wrote:
>>
>>>Hi,
>>>
>>>I've been working the last 4 days to add scrollbars to the vergil 
>>>canvas.  I've had limited success and I've run into a couple problems. I 
>>>wanted to see what others thought of this before I continue.
>>>
>>>There are two different places where this functionality can be added. 
>>>The first one (and probably the technically correct place) is in the 
>>>Diva library.  Diva is the library ptolemy uses to provide all of the 
>>>graph editing functionality.  Diva also provides the panner (the widget 
>>>in the bottom left that allows you to move around the workspace).  The 
>>>second place this functionality can be added is to the Vergil gui classes.
>>>
>>>Placing the code in diva is probably the best way to do this because 
>>>then it would integrate seamlessly into the current view and allow the 
>>>scrollbars to interact with the panner.  Changing Diva to do this is not 
>>>trivial.  Diva has it's own layer system built around AWT with some 
>>>Swing components.  Also, if we change diva, it's going to be much harder 
>>>to make this a "pluggable" change without making some architectural 
>>>change to diva itself.
>>>
>>>Placing the code in the BasicGraphFrame class of vergil is the most 
>>>straight forward way to do it because the vergil gui uses all swing 
>>>components and places diva widgets inside the swing components.  This is 
>>>the way I have partially implemented the scrollbars now (using a 
>>>JScrollPane).  There are several problems with this.  First of all, 
>>>getting the scrollbars to interact with the panner correctly seems 
>>>mostly impossible.  Basically, i have to remove the panner or else 
>>>things get chaotic real quick.  If the user moves the workspace via the 
>>>panner, there is no event to catch when this happens, so the scrollbars 
>>>can't be updated accordingly.  I've also had to make major changes to 
>>>the zoom code.  The two advantages of doing it this way are that it's 
>>>easier to code since one can work with only swing components and i think 
>>>it will be easier to make this a pluggable change since some people have 
>>>said they don't want scrollbars on the canvas.
>>>
>>>Another thing I thought of the other day while working with photoshop 
>>>(which has scrollbars on it's canvas), is that we could add a "hand" 
>>>tool which would serve one of the purposes of the panner (to let you 
>>>move around the workspace).  I like the panner and don't really want to 
>>>get rid of it anyway.  I think the panner, scrollbars and a potential 
>>>hand tool would work well together.  It's just a matter of figuring out 
>>>the best way to do it.  Ptolemy folks: how hard do you think it would be 
>>>to add this to Diva?
>>>
>>>thoughts?
>>>
>>>chad
>>>_______________________________________________
>>>kepler-dev mailing list
>>>kepler-dev at ecoinformatics.org
>>>http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
>>
>>------------
>>Edward A. Lee, Professor
>>518 Cory Hall, UC Berkeley, Berkeley, CA 94720
>>phone: 510-642-0455, fax: 510-642-2739
>>eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
>
>------------
>Edward A. Lee, Professor
>518 Cory Hall, UC Berkeley, Berkeley, CA 94720
>phone: 510-642-0455, fax: 510-642-2739
>eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal