--- On Mon, 11/29/10, Ivica Ico Bukvic <[email protected]> wrote:
> From: Ivica Ico Bukvic <[email protected]> > Subject: Re: [PD] L2Ork pd-extended release candidate 1 now available (was: > Re: call for testers...) > To: "Jonathan Wilkes" <[email protected]> > Cc: "András Murányi" <[email protected]>, "PD List" <[email protected]> > 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 > > > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
