--- On Thu, 11/25/10, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Ivica Ico Bukvic" ico@vt.edu, pd-list@iem.at Date: Thursday, November 25, 2010, 5:40 AM
On Nov 24, 2010, at 7:46 PM, Jonathan Wilkes wrote:
--- On Wed, 11/24/10, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@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@vt.edu Cc: "'Jonathan Wilkes'" jancsika@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.
By that logic "play mode" implies that things aren't playing in "edit mode", which is definitely not true either. Either way it takes a few seconds to notice that:
[osc~ 420]
|
[*~ 0.1]
|
[dac~]
is 'playing'/'running'/'producing music' regardless of which mode Pd is in (as long as DSP is turned on).
Changing all instances of 'run mode' to 'play mode' is a lot of work for very little gain. Not changing anything is no gain, yet no work. (I would vote for the latter but given the context that seems like too much work.)
-Jonathan
.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