Hi list,I've been investigating other guis as possible replacements for tcl/tk gui. A few reasons:* tk is slow to redraw
But as it turns out, it's fairly difficult to find a decent replacement for tk canvas:* Gtk is a moving target and has reportedly poor documentation and poor community attitudes when trying to use it with OSX and Windows* Qt's "Qt Quick/QML" approach doesn't include Bezier curves or even lines as fundamental items (and they won't benefit from Qt's graphics acceleration if you add them manually). Probably related-- it seems to be geared mainly toward mobile apps. Desktop components seem to have been tacked on as an afterthought.
There's also this: https://github.com/rogerwang/node-webkit with a nice short introduction here: What you should know before starting node-webkit| Do Great Things - 叶玎玎 So node-webkit would essentially replace tcl/tk with HTML5 (or any subset of it), plus a javascript API for handling menubars, native file dialogs and other application-level details. Additionally it could leverage any HTML5 graphics framework, of which there are many. (Also, if a patch author wanted to write some insanely complex visualization, they could use any HTML5 framework and easily communicate with Pd.)
Of course the _big_ problem is that node-webkit itself currently weighs in at 99M for linux amd64 (37M zipped). There doesn't seem to be a Debian package for it (and I'm not sure if there could be, given how it wraps around the Chromium browser). Anyway, the only viable choices I see so far are:* Qt (through QGraphicsView or QML for tk canvas replacement)* node-webkit Personally, I have very little interest in designing a new GUI <--> Pd communication mechanism, and even less interest in coding in c++. So if left to my own devices, I'll probably just try opening an additional socket in Pd to connect to node-webkit and communicate with it similar to how tcl/tk does, using javascript instead of tcl commands. I would start with with Pd -> node-webkit, then adding GUI event-handling later. That way I can keep the tcl/tk GUI and node-webkit one side-by-side as I go.
Of course if someone with the knowledge and energy to do this the "right way" has any suggestions, I'm all ears. I have the inkling that if I could employ a full-time dev to do my bidding then Qt Quick would the "right way" to go-- it's in Debian, is cross-platform, well-documented, and it certainly has enough features for Pd's canvas editing. But I don't know how to retrofit a c program like Pd with Qt, nor how to replace Pd's current string-based communication with whatever one is supposed to use to do that.
-Jonathan
On 24/12/2014 06:18, Jonathan Wilkes via Pd-list wrote:
Hi list, I've been investigating other guis as possible replacements for tcl/tk gui. A few reasons:
- tk is slow to redraw
- no anti-aliasing except on OSX
- poor support for theming
- poor support for standard image formats
- binary alpha channel
- limited control of font properties on canvas
- lack of proper canvas zooming
- non-standard file save/open dialogs
- lack of common gui-toolkit tools like tooltips and rich text
- too much bit-rot in third-party libraries to work around all the above
Good point. In my opinion, graphical stuff requires a lot of effort (in code/design and, of course, for the portability). I really *LOVE* the pd (well... I prefer pd-extended :) ) graphical philosophy: small bocks, no exploding rainbows of color. Simple and elegant.
Can be better? Probably. Especially considering the issues presented by Jonathan. But I think that will be a huge milestone (in terms of effort). Ok... the modular nature of pd can help a lot in order to make smooth transitions.
To the technical side, which tk?
technically is not a tk, but a widget for Gtkmm, but its a nice widget for drawing "boxes and lines" (cit. Drobilla) stuff.
Cheers
Alessio
[CUT] -Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Dec 24, 2014 11:49 AM, "Alessio Degani" alessio.degani@ymail.com wrote:
On 24/12/2014 06:18, Jonathan Wilkes via Pd-list wrote:
Hi list, I've been investigating other guis as possible replacements for tcl/tk
gui. A few reasons:
- tk is slow to redraw
- no anti-aliasing except on OSX
- poor support for theming
- poor support for standard image formats
- binary alpha channel
- limited control of font properties on canvas
- lack of proper canvas zooming
- non-standard file save/open dialogs
- lack of common gui-toolkit tools like tooltips and rich text
- too much bit-rot in third-party libraries to work around all the above
Good point. In my opinion, graphical stuff requires a lot of effort (in code/design
and, of course, for the portability).
I really *LOVE* the pd (well... I prefer pd-extended :) ) graphical
philosophy: small bocks, no exploding rainbows of color. Simple and elegant.
Can be better? Probably. Especially considering the issues presented by
Jonathan. But I think that will be a huge milestone (in terms of effort). Ok... the modular nature of pd can help a lot in order to make smooth transitions.
Actually, it is not that much of work. Porting to tkpath took me no more than a couple of days. Granted, tkpath is quite similar to tcl/tk but the principle is the same. Alas, tkpath is defunct project.
The real leap in the gui will happen once/if/when networked nature of communication between pd and tcl is replaced with threaded design. This will solve a good chunk of determinacy issues and likely introduce new problems, but the gui will be likely way more responsive.
To the technical side, which tk?
- JUCE: multiplatform
Licensing is fairly restrictive, though, in comparison to alternatives. Benefits obvious (Max uses it).
- FlowCanvas (now Ganv, http://drobilla.net/software/flowcanvas/):
technically is not a tk, but a widget for Gtkmm, but its a nice widget for drawing "boxes and lines" (cit. Drobilla) stuff.
Cheers
Alessio
[CUT] -Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-- a.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
Hi Jonathan,
I can't weight in or help, as this is outside of my capabilities. But if
anything is needed for grunt work - testing (on all systems),
documentation, etc, I can help.
Best,
Joao