[kepler-dev] scrollbar additions to kepler

Tue Jul 27 20:06:26 PDT 2004

I wonder how much effort it would be to have the different
panning/scrolling modes be customizable user preferences.

Also, there is plenty of evidence in the world that the "best"
solution not always is the most widespread -- also sometimes "best" is
a parameter of the user community, etc.

To give a concrete example of my (strange) definition of "best":

- best editor: (X)Emacs
- best way to navigate and "say what you mean": keyboard 
(although I must say that I find Vergil quite nice!)
- best XML syntax: Prolog syntax
- best text processing system: LaTeX
- best functional prog. language: Haskell

just my $0.02 ;-)

Bertram

>>>>> "CB" == Chad Berkley <berkley at nceas.ucsb.edu> writes:
CB> 
CB> 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?
CB> 
CB> In this prototype that i've been working on, i've been choosing the 
CB> boundaries to be the actual size of the model and resizing the 
CB> scrollbars dynamically as the size of the model increases.  The canvas 
CB> is still infinite, but the viewport resizes (via the scrollbars) to 
CB> accomodate the model.  Do you see a problem with this approach?  The 
CB> other way I've seen applications do this is just to set the scrollbar 
CB> max to a very large value and position both the vert and horiz bars in 
CB> the middle of the range.  It effectively makes the canvas finite, but is 
CB> anyone really going to create a model that's 2 miles x 3 miles?  If they 
CB> did, I think we would accuse them of bad programming practice :)
CB> 
>> 
>> 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...
CB> 
CB> It seems like everytime we sit someone down with this they comment about 
CB> the lack of scrollbars for navigating the canvas.  I personally have no 
CB> problem with the panner, but it's still nice to have a choice of how you 
CB> want to navigate the canvas.  If you just want to move the view down a 
CB> little bit, it's much easier to click the down arrow on the scrollbar 
CB> than to move the panner a touch.  The panner can be too touchy for 
CB> moving the view small amounts due to it's low resolution compared to the 
CB> canvas.
CB> 
CB> Another idea is that instead of having the traditional scrollbar with a 
CB> slider, we could just use a set of 4 arrows to micomanage the canvas. 
CB> That way, if you want to nudge the canvas around the viewport by a few 
CB> pixels, you could just click the arrows instead of using the panner. 
CB> Without the scroll slider, the canvas would effectively remain infinite.
CB> 
>> 
>> 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.
CB> 
CB> Photoshop and Illustrator both have a finite canvas, but that canvas can 
CB> be very big.  I find the scrollbars to be very effective for navigation 
CB> on the canvas, especially when combined with the hand tool.  Note that 
CB> you can quickly change to the handtool in Illustrator by holding down 
CB> the spacebar, which is quite convenient.
CB> 
>> 
>> 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.
CB> 
CB> Personally, I don't see what the big deal is.  I've been using modal 
CB> GUIs for a long time and have never had a problem with choosing a 
CB> navigation tool instead of a drawing tool.  That said, I consider myself 
CB> an advanced user with most programs like this (i.e. Photoshop and 
CB> Illustrator).   I'll try to figure out a way to do this...possibly with 
CB> a keyboard shortcut or something.
CB> 
CB> chad
CB> 
>> 
>> 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
CB> _______________________________________________
CB> kepler-dev mailing list
CB> kepler-dev at ecoinformatics.org
CB> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev