Thoughts on QML

[cboulay]

It's late and I need to get to bed... I just wanted to share a couple thoughts on using QML.

• After getting over the initial learning hump, I really liked it. It makes it easier to separate GUI logic from business logic. There are several different ways to communicate between C++ and QML; after you settle on one, the rest is pretty straightforward.

• I had to modify the LSLCMake script to add an argument to the windeployqt call.

• I really love its Settings component. See here for an example of how I used it. Upon first run it'll generate a file with the indicated name. With no filename specified, it'll use the default location, which for Windows is in the registry. These settings make bidirectional bindings between the GUI elements and the values in the config file, and are updated on the fly. And when you reopen the app, it restores the last settings.

• The config file it generates is very clean too:

[ApplicationWindow]
x=880
height=740
width=800
y=330

[EventStream]
type=Markers
name=Gamepad Events
stream_id=gamepad_evt_0

[SampledStream]
name=Gamepad
rate_x100=6000
stream_id=gamepad_cont_0
type=HID

• I don't love its signal/slot syntax in some circumstance. e.g., here I create a new slot and then below I connect it to a signal (from C++). That's not a problem per se. Compare to here where I connect to an existing signal. In both cases I use the function keyword, and both look like function definitions, but the first is a new slot definition and the second is a reference to an existing signal. It's probably more succinct than having a property for the signal name then another property for the lambda, it just bothers me that it looks like a function definition but it isn't.

[tstenner]

I've thought about it before, but hadn't gotten around to trying it out.

I really love its Settings component. See here for an example of how I used it.

That's nice, my only worry is that it harder to share code between the GUI app and a CLI app, e.g. for LabRecorder.