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

[Jonathan Wilkes]

--- On Wed, 11/24/10, Hans-Christoph Steiner <hans at at.or.at> wrote:

> From: Hans-Christoph Steiner <hans at at.or.at>
> Subject: RE: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
> To: "Ivica Ico Bukvic" <ico at vt.edu>
> Cc: "'Jonathan Wilkes'" <jancsika at yahoo.com>, pd-list at iem.at
> Date: Wednesday, November 24, 2010, 11:54 PM
> 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.

If you do this please call it "Run mode" and not "Play mode".

It's "run mode" in the manual, as well as a lot of the docs, 
tutorials, and internal help patches.

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