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

[Ivica Ico Bukvic]

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

I am referring to the one that has been a part of pd for a long time. This is the one I just updated in the latest release so that moving of its widgets in edit mode is now a part of a single move-by-tag call. I am actually quite pleased how it works now.

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

I am not reinventing wheel in this case but simply backporting your solution (unless you are referring to me wasting hours as you did on the Tcl widget bug as the actual reinventing of the wheel). Either way, the checkmark next to the checkbutton widget is simply buggy and does not show up when it should (e.g. when invoking the widget). This is the case even with 0.43 gui rewrite. The only way one can "see" that the option has been activated on 0.43 (and now on l2ork iteration of 0.42) is by the fact "edit mode" option in the menu has changed its background color to green (which actually does not look all that bad, even though it is inconsistent with general menu UI guidelines Tcl/Tk is supposedly trying so hard to enforce).

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

As long as those messages are not something that needs to be sent via socket but can be also prototyped into direct function calls within C. Otherwise, the solution simply perpetuates the existing problem of socket and string parser saturation, resulting in very slow performance. Notice that even with l2ork iteration of pd-extended where everything "vanilla" now uses move-by-tag approach (in other words one call moves all selected widgets except for GOPs which are quite messy thus resulting in one call vs. potentially hundreds if not thousands) and which ostensibly approaches ideal performance via socket, it still gets relatively easily bogged down due to inherent overhead.

Best wishes,

Ico