Producing an application for both desktop and mobile

Posted Feb 20, 2019 17:04 UTC (Wed) by halla (subscriber, #14185)
Parent article: Producing an application for both desktop and mobile

He'd probably found many more QML developers if he'd given the presentation at Fosdem :-).

In any case, since I'm interesting in doing much the same thing, porting Krita to iOS and Android, I'll take a look at how subsurface has set things up. What I'm wondering is, how many dependencies does subsurface have...

Of course, Krita has a _huge_ ui layer, all QWidgets, and our previous QML ui broke when Qt moved to a scenegraph for QML, so our OpengGL canvas broke. And a huge number of dependencies, as well.

Producing an application for both desktop and mobile

Posted Feb 20, 2019 20:58 UTC (Wed) by dirkhh (subscriber, #50216) [Link] (1 responses)

We have quite a few dependencies - libusb, libftdi, libhidapi, libgit2, libxml2, libxslt, ssl, curl... but I bet nowhere near as bad as Krita.
Feel free to poke around in the sources (https://github.com/Subsurface-divelog/subsurface) or to reach out in email...

Producing an application for both desktop and mobile

Posted Feb 20, 2019 22:12 UTC (Wed) by halla (subscriber, #14185) [Link]

I've been going through the scripts and files in the repo all evening :-)

Producing an application for both desktop and mobile

Posted Feb 21, 2019 0:00 UTC (Thu) by khim (subscriber, #9252) [Link] (3 responses)

For Krita another target could make sense: ChromeOS. These devices run Android apps nowadays - but with mouse and keyboard. Thus could perhaps could be easier first target than phones.

Producing an application for both desktop and mobile

Posted Feb 21, 2019 19:19 UTC (Thu) by smurf (subscriber, #17840) [Link] (2 responses)

On the other hand, it might be better to go to the really different device first. The middle ground later should then be easy. However, if you go halfway first you might paint yourself into a coding corner you can't get out of without scrapping the attempt and doing it again.

Producing an application for both desktop and mobile

Posted Feb 21, 2019 20:12 UTC (Thu) by halla (subscriber, #14185) [Link] (1 responses)

Things get complicated fast... iOS is a reasonable target because Qt supports the Pencil (which, imo, sucks...). It doesn't support the pen integration of Android or ChromeOS -- probably beccause of a lack of devices and therefore a lack of demand.

But I do have an Android and iOS device with a pen; I don't have a ChromeOS device with a pen.

Then there's the question of what the return on investment is going to be. It's clear that all three platforms are a huge headache. I already knew that, and after going through the subsurface code, I've got the headache, even without trying to do anything on my own.

Like the Windows Store and Steam binaries, if I'm going to suffer from headaches and ulcers, well, the binaries I make for those stores won't be free. iOS probably will return, Play Store might not, because of a lack of suitable devices. I have no idea about ChromeOS.

(Note that there has been at least one attempt at putting Krita in the Windows Store apart from the official one: the person who made the attempt failed to make a go of it, because they couldn't even manage to build Krita for Windows themselves. And they needed to do that to give the binary a distinctive name, because Krita is a TM.)

As the Subsurface documentation says,

Building Subsurface on Windows
------------------------------

This is NOT RECOMMENDED. To the best of our knowledge
 there is one single person who regularly does this. The 
Subsurface team does not provide support for Windows 
binary build from sources natively under Windows...

The lack of a working package management system for 
Windows makes it really painful to build Subsurface natively
under Windows, so we don't support that at all.

Unfortunately, one core library needed for Krita doesn't build with mxe or mingw on Linux at all, and mingw on Windows is needed... (It also doesn't build with msvc).

As for our equivalent for package management, look at the source code...

Producing an application for both desktop and mobile

Posted Feb 22, 2019 2:04 UTC (Fri) by pabs (subscriber, #43278) [Link]

Hmm, there are multiple package managers for Windows:

https://en.wikipedia.org/wiki/List_of_software_package_ma...

QObject facades in QML apps

Posted Feb 22, 2019 14:38 UTC (Fri) by bovinespirit (subscriber, #88348) [Link]

Working on a proprietory app that added a QML front end we had a lot of issues with object lifetimes. Putting singleton objects into the context wasn't really a nice solution for large dynamic model objects, and didn't fit with the way the rest of the code worked.

In MVC and design patterns terms we found that the way to tackle it was to treat the QObjects (and QAbstractListModels) that provide data to the QML pages as part of the View, not part of the Model. The QML code will create and delete them as it pleases, but the objects don't hold any data, they just act as facades for the actual data models. We've not found a way to nicely separate out the 'Controller' parts, instead the facade objects' constructor is generally responsible for connecting the various signals up. What you end up with is lots of QObjects whose properties (as in Q_PROPERTY) are almost identical to that of the Models, and just exist to pass through data.

Our facade objects are registered with QML using qmlRegisterType<FacadeType>("com.example.myobjects", 1, 0, "FacadeType") then the QML uses import com.example.myobjects 1 0 then FacadeType { id: myFacade } to create a facade object.