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

[Hans-Christoph Steiner]

On Nov 24, 2010, at 12:29 AM, Ivica Ico Bukvic wrote:

>> 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.

I just realize that there are two iemgui libs in a sense: there are  
the iemgui objects that have been included in Pd-vanilla for 10 years,  
those are the ones I was referring to.  Then there is the new iemgui  
library in pure-data SVN, I know little about that one.  Which one are  
you referring to?

>> 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.

FYI, 0.43 fixes this issue by changing the 'editmode' message so that  
1 means editmode is on, and 0 means editmode is off.  Before that, the  
'editmode' message toggled edit mode.  That's what made it so  
difficult to make the menu item checkbox work.  These are the kinds of  
things that I have spent many many hours working to fix, so it makes  
me sad to see you reinventing the wheel.

Also, since everything is always running in Pd, I'd much prefer to see  
it called "Edit Mode" and "Play Mode".

>> 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.


Peter Brinkmann, Peter Kirn, Miller and I all had a meeting recently  
to discuss the idea of making 'pd' a separate entity.  My part is  
making pd talk to pd-gui using pd messages, then it should be pretty  
straightforward to making new GUIs in lots of different toolkits.

.hc


----------------------------------------------------------------------------

"Free software means you control what your computer does. Non-free  
software means someone else controls that, and to some extent controls  
you." - Richard M. Stallman