<br><br><div class="gmail_quote">On Thu, May 20, 2010 at 6:18 PM, Niels Mayer <span dir="ltr"><<a href="mailto:nielsmayer@gmail.com">nielsmayer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I forgot to mention one of my main finds regarding clojure -- a nice Qt interface, and working well w/ multithreaded...<div><br></div><div><a href="http://tealeg.blogspot.com/2008/11/on-clojure-part-3-designer-uis-and.html" target="_blank">http://tealeg.blogspot.com/2008/11/on-clojure-part-3-designer-uis-and.html</a></div>

<div><a href="http://briancarper.net/blog/clojure-qt4-system-tray-mail-checker" target="_blank">http://briancarper.net/blog/clojure-qt4-system-tray-mail-checker</a></div><div><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">

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.)</blockquote>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
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.</blockquote>

<div><br></div><div>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):</div>
</blockquote><div><br>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.<br>
<br>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 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).<br>
<br></div></div>