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