On Nov 24, 2010, at 7:37 PM, Jonathan Wilkes wrote:
--- On Wed, 11/24/10, Ivica Ico Bukvic <[email protected]> wrote:
From: Ivica Ico Bukvic <[email protected]>
Subject: RE: [PD] call for testers for L2Ork iteration of pd-
extended (based on 0.42.x branch)
To: "'Jonathan Wilkes'" <[email protected]>
Cc: [email protected]
Date: Wednesday, November 24, 2010, 6:29 AM
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.
Also notice that [flatspace/entry] has a nice cursor associated with
resizing.
Ah yes, I forgot about that cursor in entry. I actually started
working on improving the [entry] widget, and that turned into the
tkwidgets library. I really should get the tkwidgets stuff into some
kind of usable release.
.hc
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.
Another solution: you can also place a checkbutton labeled "Edit mode"
directly on the menubar.
Also, since we're talking about the menu changes: Since there is a
"Find"
menu, I think the "Edit" menu can be shortened by removing "Find",
"Find
again", and "Find last error".
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.
Best wishes,
Ico
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
----------------------------------------------------------------------------
"[T]he greatest purveyor of violence in the world today [is] my own
government." - Martin Luther King, Jr.
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
