[PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)

[Ivica Ico Bukvic]

On Sat, 2010-11-27 at 23:18 -0800, Jonathan Wilkes wrote:
> Hi,
>      Here are some scrolling observations:
> In the attached patch, drag the [pd] object far down into the 
> bottom right-hand corner, so that you get some scrollbars to appear.  
> Now, on the current pd-extended, you can scroll down to that object, 
> and when you drag it back to its original location, the scrollbars 
> respond in realtime so that the object swoops back up the patch 
> until, finally, the scrollbars disappear.  In your version the 
> scrollbars don't react until you stop dragging and release the mouse 
> button.  Just an observation-- I suppose both methods have their 
> strengths and weaknesses.  I prefer the current Pd-ext behavior-- 
> for example, if I happen to paste an object into another patch with a smaller window size, it makes it quick to drag it back up.
> 
> But notice that once you drag the [pd] object back near its original 
> position, the [f] object looks as if it's at (0,0), when it's really 
> at (10,10).  However, if you save the patch and reopen it the [f] 
> will appear at its proper, original position-- (10,10).  I think this 
> is a bug, because it means any time one adds or takes away the 
> scrollbars the absolute positioning of the objects on the canvas is 
> temporarily lost, forcing the user to close and open to see the 
> real positioning.
> 
> -Jonathan

Both of these are actually a feature. I actually used to have real-time
scrollbar updates but that simply bogged the cpu down too much, so I
opted to updating them only once an object has stopped moving which in
most if not all cases makes perfect sense.

The reason canvas is displaced in l2ork version is because our
philosophy is "if a patch can fit in a window, it should." Granted, it
has some shortcomings like patches opening and then having to readjust
as well as having them not (0,0)-centric which makes them potentially
less compatible with vanilla version. That said, I believe this is a
much better way of dealing with patches, and if one really wants to
"lock-in" patch positioning, they should simply use a cnv (canvas)
object whose name in many ways suggests exactly that.

NB: repositioning of window upon load can be avoided only if the format
of saving the patch also includes the top-left corner of the canvas,
which current format does not support.

Please note that l2ork's scrolling algorithm also accounts for all other
operations, such as undo/redo/cut/copy/paste, even key presses that may
extend the width of an object.

Cheers!

Ico