[PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

Jonathan Wilkes jancsika at yahoo.com
Thu Nov 25 01:37:52 CET 2010



--- On Wed, 11/24/10, Ivica Ico Bukvic <ico at vt.edu> wrote:

> From: Ivica Ico Bukvic <ico at vt.edu>
> Subject: RE: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
> To: "'Jonathan Wilkes'" <jancsika at yahoo.com>
> Cc: pd-list at iem.at
> Date: Wednesday, November 24, 2010, 6:29 AM
> > Notice that both
> [cyclone/Scope~] and [flatspace/entry] have a
> > bug: a sudden increase in height/width by about 5-10
> pixels when you
> > initially drag to resize.  This makes it
> difficult if not
> > impossible to make minor size changes (especially
> since there is no
> > Properties dialogue).
> 
> Good to know. I will look into this when I get there.
> Currently working on accelerating iemgui objects as well as
> exposing them to sarlo's highlighting magic.

Also notice that [flatspace/entry] has a nice cursor associated with 
resizing.

> 
> > Wouldn't it be easier just to toggle the text for that
> menu option
> > between "Edit mode" and "Run mode"? (That's what
> they're called in
> > the manual.)
> 
> Sure. There are other options, too, like the one 0.43 and
> now l2ork version of 0.42 uses by changing option's
> background which works visually relatively well (albeit at
> the expense of consistency). This is however not the issue.
> The issue is finding out that after an hour of debugging the
> problem is not in you or your code but the toolkit you are
> using and in 2010 for a toolkit that has been around for
> more than a decade that is plainly sad.

Another solution: you can also place a checkbutton labeled "Edit mode" 
directly on the menubar.

Also, since we're talking about the menu changes: Since there is a "Find" 
menu, I think the "Edit" menu can be shortened by removing "Find", "Find 
again", and "Find last error".

> 
> > How would you go about doing that?
> 
> A: Ugly path: Isolate pd<->gui hooks and port the
> entire thing to Qt.
> 
> B: Better (albeit more time-consuming) path: clean-up code
> first so that all objects can utilize the same
> gobj_<whatever> calls and then do the A: (which at
> that point won't be nearly as ugly or difficult to
> maintain).
> 
> FWIW, my first ever GUI app was RTMix I did back in 2001
> and it was (and remains) the ugliest hack ever (basically I
> tried to learn how to program doing that app). Yet, the fact
> remains even in 2001 qt was way better than what Tk is
> today. Another advantage is avoiding socket bottlenecks as
> the entire thing could be done simply in C. License-wise it
> should be fine and cross-platform-wise miles ahead of
> Tcl/Tk. Heck, you could even throw in Qt for mobile devices
> for good measure since that is apparently hot item these
> days.
> 
> That said, I need some more time working with Pd code
> before I can undertake this. Perhaps more importantly, I
> just need a generous, uninterrupted chunk of time to do
> this.
> 
> Best wishes,
> 
> Ico 
> 
> 


      



More information about the Pd-list mailing list