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

[Hans-Christoph Steiner]

On Wed, 2010-11-24 at 14:06 -0500, Ivica Ico Bukvic wrote:
> > 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.

That sounds like something that should have been done a while ago. My
big worry here is regression bugs.  So we'll need to come up with a
bunch of tests so we can make sure the faster code doesn't introduce
bugs.  I think the only place we are going to see big benefits for move
code is in redrawing arrays, the drawing is pretty simple in most other
GUI objects.

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

Yeah, I hear you.  I think the background color thing works well for
GNOME, not sure about anything else tho.  Changing the text between
"Edit Mode" and "Play Mode" is a viable option for all platforms IMHO.

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

I think there are advantages to having the GUI be a separate process,
and it would be worth exploring other ways of havning pd and pd-gui
talk.  Shared memory is one idea.  Plus for things like arrays, the data
could be sent as binary thereby skipping the string parsing aspect.

.hc