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

[Hans-Christoph Steiner]

On Nov 24, 2010, at 7:46 PM, Jonathan Wilkes wrote:

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

Right, I'm proposing changing it everywhere. "run mode" implies that  
things aren't running in "edit mode", which is definitely not true.

.hc




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



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

If nature has made any one thing less susceptible than all others of  
exclusive property, it is the action of the thinking power called an  
idea, which an individual may exclusively possess as long as he keeps  
it to himself; but the moment it is divulged, it forces itself into  
the possession of everyone, and the receiver cannot dispossess himself  
of it.            - Thomas Jefferson