On Nov 24, 2010, at 12:29 AM, Ivica Ico Bukvic wrote:
Notice that both [cyclone/Scope~] and [flatspace/entry] have a
bug: a sudden increase in height/width by about 5-10 pixels when you
initially drag to resize. This makes it difficult if not
impossible to make minor size changes (especially since there is no
Properties dialogue).
Good to know. I will look into this when I get there. Currently
working on accelerating iemgui objects as well as exposing them to
sarlo's highlighting magic.
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?
Wouldn't it be easier just to toggle the text for that menu option
between "Edit mode" and "Run mode"? (That's what they're called in
the manual.)
Sure. There are other options, too, like the one 0.43 and now l2ork
version of 0.42 uses by changing option's background which works
visually relatively well (albeit at the expense of consistency).
This is however not the issue. The issue is finding out that after
an hour of debugging the problem is not in you or your code but the
toolkit you are using and in 2010 for a toolkit that has been around
for more than a decade that is plainly sad.
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.
Also, since everything is always running in Pd, I'd much prefer to see
it called "Edit Mode" and "Play Mode".
How would you go about doing that?
A: Ugly path: Isolate pd<->gui hooks and port the entire thing to Qt.
B: Better (albeit more time-consuming) path: clean-up code first so
that all objects can utilize the same gobj_<whatever> calls and then
do the A: (which at that point won't be nearly as ugly or difficult
to maintain).
FWIW, my first ever GUI app was RTMix I did back in 2001 and it was
(and remains) the ugliest hack ever (basically I tried to learn how
to program doing that app). Yet, the fact remains even in 2001 qt
was way better than what Tk is today. Another advantage is avoiding
socket bottlenecks as the entire thing could be done simply in C.
License-wise it should be fine and cross-platform-wise miles ahead
of Tcl/Tk. Heck, you could even throw in Qt for mobile devices for
good measure since that is apparently hot item these days.
That said, I need some more time working with Pd code before I can
undertake this. Perhaps more importantly, I just need a generous,
uninterrupted chunk of time to do this.
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.
.hc
----------------------------------------------------------------------------
"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent controls
you." - Richard M. Stallman
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
