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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
