Re: [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 <h...@at.or.at> wrote:

From: Hans-Christoph Steiner <h...@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" <i...@vt.edu>
Cc: "'Jonathan Wilkes'" <jancs...@yahoo.com>, pd-list@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



_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list