--- 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. > > > > 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 > > _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list