On Thu, May 20, 2010 at 06:46:16PM -0400, Paul Davis wrote: > On Thu, May 20, 2010 at 6:18 PM, Niels Mayer <[email protected]> wrote: > > > I forgot to mention one of my main finds regarding clojure -- a nice Qt > > interface, and working well w/ multithreaded... > > > > http://tealeg.blogspot.com/2008/11/on-clojure-part-3-designer-uis-and.html > > http://briancarper.net/blog/clojure-qt4-system-tray-mail-checker > > > > As you'd expect from Clojure, the concurrency part of the app was a > >> no-brainer. There are a bunch of threads hammering on a single global hash > >> list of email messages, and they're all forcing updates of the GUI, but > >> throw a bunch of dosync's around certain bits of code and it all works > >> without worry. (Qt's invokeLater is also necessary if you're updating a Qt > >> GUI from more than one thread at a time.) > > > > > >> My first version of this app had even more threads, with one thread > >> updating the GUI every few seconds, and another master thread managing all > >> the mail threads. It also worked fine. It was overkill so I scaled it down, > >> but it's really nice how you can coordinate a bunch of threads and don't > >> have to worry about deadlocks and race conditions and whether your data > >> structures are thread-safe. > > > > > > Question: how easy is it to "add on" to an existing Qt/QtDesigner-based app > > like, say, qtractor, the aforementioned clojure language extension? > > (instead of "angelscript" mentioned in Rui's 0.1 whitepaper pdf... and > > that's assuming the caveat mentioned in one of the above links "You must use > > Qt Designer with the QtJambi plugins installed.") And how much would java be > > able to "introspect" out of the C++/Qt-part of its environment without > > having to be told about it. (e.g to access&manipulate, then schedule > > rerendering of MIDI, timing, & non-destructive editing data.). The "slot" > > stuff looks pretty introspective inter-call between QtDesigner and clojure > > (from first link): > > > > i think you're missing the model/view separation that apps like qtractor (or > ardour) have. added access to the GUI elements is relatively easy because > they are semantically simple objects. providing access to the "model" (e.g. > the MIDI data) is quite complex. > > just for reference, torben wrapped libardour in python and ended up with a > 500MB library. he was able to load and play an ardour session entirely in
this was a COMPLETE wrapping of everything. and most of the stuff were REALLY large boost::python symbol names. i could have probably gotten the size a lot smaller > python. this was done using automated tools followed by some hand-tweaking > (it involved parsing all the C++ and generating XML descriptions of every > data structure/object, and then feeding that into a python external > generator). > _______________________________________________ > Linux-audio-dev mailing list > [email protected] > http://lists.linuxaudio.org/listinfo/linux-audio-dev -- torben Hohn _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
