Mimas: Lua/Qt binding

108 views
Skip to first unread message

Peter Kümmel

unread,
Dec 11, 2010, 9:27:10 AM12/11/10
to rubyk
I found rubyk&Co. because of your lua-l messages and I
stumbled upon your post about discovering Qt and your
plans to use it for mimas. Being already a Lua user you
are maybe interested in the Qt binding to Lua:

http://code.google.com/p/lqt/

Cheers,
Peter


Gaspard Buma

unread,
Dec 11, 2010, 11:05:12 AM12/11/10
to ru...@googlegroups.com
Hi Peter,

I saw this binding very briefly. I am still considering how to encode the views (defined on the "server" side but running on the "client"). The current options are:

1. json: easy to "merge" (update some parts of the interface by sending partial dictionaries)
2. qml: native support by Qt made for UI
3. lqt: avoids having yet another language, would need to be made "safe" (we do not want to run arbitrary code on the client) but that should be pretty easy.

For the communication layer between instances and between the server and clients, I want to use Lua so there will be at least some lua code running in Mimas anyway so that's another incentive on using lqt. My only worry is that I need the GUI to be in place really fast and I do not want to spend time on Lua bindings on the GUI side (already a lot to do in Rubyk core).

I did not realize at first that you were one of the authors of lqt. If you think lqt is a good choice to build the visual elements (or even all of Mimas), I'll use this because I like the idea of using Lua for everything. My main concern right now is time: I have a show in June and everything must work long before this date so I will choose whatever saves me time !

I looked at the Lua examples for lqt and they look really nice.

Gaspard



--
_______________________________________________
rubyk mailing list
ru...@rubyk.org
http://rubyk.org/en/community

Peter Kümmel

unread,
Dec 12, 2010, 11:12:21 AM12/12/10
to rubyk
On 11 Dez., 17:05, Gaspard Buma <a...@gaspardbuma.org> wrote:
> Hi Peter,
>
> I saw this binding very briefly. I am still considering how to encode the
> views (defined on the "server" side but running on the "client"). The
> current options are:

Hi Gaspard,

what do you mean with "defined on server side". As I understand your
architecture, client and server are running in its own process on
maybe
different machines communicating via zeromq. And you wanna make the
server something like a webservice with a special kind of client,
which
is only for viewing the content generated by the server? This sound
very
complicated to me, or is the content of the view not that complex?

> 1. json: easy to "merge" (update some parts of the interface by sending
> partial dictionaries)

Having Lua you don't need JS to package some data.

> 2. qml: native support by Qt made for UI

Have you looked into the QML doc? For me it looks like it is not
usable
for desktop GUIs because you have to define all elements by your own.
I even coudn't find a simple hello world example with a pushbutton.

> 3. lqt: avoids having yet another language, would need to be made "safe" (we
> do not want to run arbitrary code on the client) but that should be pretty
> easy.

As mentiond above, why not coding the views in C++ with help of Qt's
designer?


> For the communication layer between instances and between the server and
> clients, I want to use Lua so there will be at least some lua code running
> in Mimas anyway so that's another incentive on using lqt. My only worry is
> that I need the GUI to be in place really fast and I do not want to spend
> time on Lua bindings on the GUI side (already a lot to do in Rubyk core).
>
> I did not realize at first that you were one of the authors of lqt. If you
> think lqt is a good choice to build the visual elements (or even all of
> Mimas), I'll use this because I like the idea of using Lua for everything.
> My main concern right now is time: I have a show in June and everything must
> work long before this date so I will choose whatever saves me time !

Then I would code the GUI in C++, it's a proven way to produce stable
GUIs in
short times. lqt is maybe interesting for extending existing
functionality.


BTW, recently I read a book about music and mathematics,
and I assume you will also like it:
http://www.maths.abdn.ac.uk/~bensondj/html/maths-music.html

Cheers,
Peter

Gaspard Bucher

unread,
Dec 13, 2010, 2:52:24 AM12/13/10
to ru...@googlegroups.com
Heya Peter,

what do you mean with "defined on server side". As I understand your
architecture, client and server are running in its own process on
maybe
different machines communicating via zeromq. And you wanna make the
server something like a webservice with a special kind of client,
which
is only for viewing the content generated by the server? This sound
very
complicated to me, or is the content of the view not that complex?

The interface is not very complex: it's just a bunch of sliders, knobs, labels and such. Since the devices can be very small (embedded linux), VNC and such is not an option (no graphics layer) and publishing a UI can be pretty straightforward (the current implementation uses JSON).

 
Have you looked into the QML doc? For me it looks like it is not
usable
for desktop GUIs because you have to define all elements by your own.
I even coudn't find a simple hello world example with a pushbutton.

The latest version of QtCreator has a drag&drop tool to create QML based interfaces and I have created some apps by following the tutorials. As I noted above, Mimas is some kind of "meta-UI" so the main user interface area is just an empty space that the users will use to compose the patches (processing tree) and views. Mimas is to Rubyk what QtDesigner is to Qt.


Then I would code the GUI in C++, it's a proven way to produce stable
GUIs in
short times. lqt is maybe interesting for extending existing
functionality.

I'll follow your advice. 
 

BTW, recently I read a book about music and mathematics,
and  I assume you will also like it:
http://www.maths.abdn.ac.uk/~bensondj/html/maths-music.html


I did not know the book. I ordered it on amazon: it will be a great bedside reading... Thanks for the pointer.
Reply all
Reply to author
Forward
0 new messages