Great suggestion! That might work quite nicely. We only have to make sure for legacy purposes that wherever in the old code this variable is being checked that it can gracefully handle values less than 0.
That said, my top priority as of right now is further testing current code as well as continuing to work on my neck piece. Beyond that I would like to make all iem objects resizable via GUI, revamp the to-front and to-back algorithm so that it does not rely upon undo, followed by an "infinite" undo, and then tooltips, improved color picker, improve upon the tidy algorithm, and then weed through the documentation and externals and only keep those that are well maintained and are not redundant. Your suggestion might fit nicely somewhere inside here as well. I would also like to see Qt-ified (or better yet juce-ified) version of the whole thing. This will however have to wait. Long story short it might be a while before I make the next big push. In the meantime, as always, contributions will be most welcome provided they do not break the backwards compatibility. Cheers! Ico Jonathan Wilkes <jancs...@yahoo.com> wrote: >Hi Ivica, > Since you've been rooting around in the Pd source, I wanted to >bring up an idea about canvas properties and get your opinion on it: > >If you look at the coords for a particular canvas, the 7th argument >currently controls GOP status. > >0 = no GOP >1 = GOP >2 = GOP + hide args > >But what if this argument were thought of as controlling canvas visibility in >a more general way: > >-2 = no menu, no scroll >-1 = no menu >0 = normal >1 = GOP >2 = GOP + hide args > >That way it's not necessary to use an abstraction to hide the menu, >plus it can be set the way it should be set-- in the canvas >properties menu. > >-Jonathan > > > _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
