--- On Mon, 11/29/10, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...) To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "András Murányi" muranyia@gmail.com, "PD List" pd-list@iem.at Date: Monday, November 29, 2010, 8:34 AM 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.
That makes sense. It will make cutting and pasting from a different window size a bit more difficult (because objects are pasted at the coords from the original patch) but unless pasting from the bottom corner of a 1000px canvas it shouldn't make much difference.
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