[PD-dev] much better scrolling algorithm (pd-extended 0.42.5)

[Ivica Ico Bukvic]

On Sat, 2009-10-31 at 17:18 -0400, Hans-Christoph Steiner wrote:
> Hey Ivica,
> 
> I rewrote the scrollbar logic in 0.43 and its working well, as far as  
> I can tell.  Have you tried it out?  I think its a similar approach,  
> but the difference is that my code tries to keep things at 0,0 since  
> Pd has a historical preference for patches having 0,0 as the upper left.
> 
> .hc

I see. After I've played with the 0.43 and here are a couple reasons why
I feel this implementation is still (IMHO) better:

1) it seems does that the canvas does not create scrollbars until you
let go of an object. So if you do go off-canvas, the scrollbar does not
appear until you do mouse-up. I personally find this distracting as the
canvas does not update dynamically. This is not the case with the
submitted patch.

2) more importantly, pd-gui-rewrite still suffers from miscalculated
"bbox all" size which this patch also addresses. e.g. try creating a
number2 object and adjust its height to 80 (top-right value on the
properties window). Now drag it all the way up and it can never reach
the edge of the top side of the canvas (or any other side for that
matter, depending upon the width parameter) due to miscalculated size
(bbox accounts for text as well and text through this process scales
incorrectly according to this tk post: http://wiki.tcl.tk/4844). Of
course, not everyone needs size 80 number2 box but this discrepancy is
present at all sizes--it is just less noticeable at smaller ones as in
those cases rectangle around the text is much closer to the text size if
not greater. In other words, with greater size value, the text size
grows faster than the size of graphical elements (rectangles, lines,
etc.).

3) 0 0 coordinate-centric design IMHO does not make sense. From
historical perspective, old patches should still TTBOMK open just fine.
Yet, if 0 0 approach is still imposed, it results in unintuitive
behavior of scrollbars. e.g. try the following on 0.43 (or previous
versions without the suggested patch):

create an object->create another object and slide it to the right until
it goes outside the canvas area->a horizontal scrollbar will indicate
there is more stuff to the right->scroll to the right and at this point
you may find both of your objects (effectively your whole patch) within
the canvas, yet the scrollbar will suggest there is something to the
left when there isn't.

This has in my opinion been rather distracting while building patches,
particularly when dealing with patch GUI design, so much so that I
resorted to creating "disable scrollbars" option (see my other email).
But even this does not guarantee proper behavior. OTOH, my
implementation does tend to pack everything to the top left corner, but
at least this way you have an option of putting a canvas object (or some
other more functional and less GUI-oriented object) in the top left
corner and you will always meet expected results upon reopening your
patch.

On a side-note, the new gtk look on the 0.43 is too large for netbook
screens (1024x600). e.g. iem object properties do not fit. The proposed
version of the older pd.tk takes care of this without sacrificing
(obviously IMHO) readability/usability.

Many thanks for all your feedback and support! Keep up the great work!

Best wishes,

Ico