New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mobile / Tablet version of Tiled #1971

Open
bjorn opened this Issue Jul 6, 2018 · 12 comments

Comments

Projects
None yet
3 participants
@bjorn
Owner

bjorn commented Jul 6, 2018

There is some demand for a mobile / tablet version of Tiled. Even though I think it will be very hard to match the desktop version of Tiled in terms of productivity and functionality, there are reasons why it would sometimes be preferable to be able to view and work on maps while not having access to a desktop PC.

There have been others who have built mobile map editors compatible with Tiled's map format, namely iTileMaps (iOS) and Terrapin (Android). These have been developed using the native technologies of their respective platforms. Unfortunately both projects are not in active development.

Personally I would prefer to share code with the C++/Qt-based desktop Tiled (through libtiled) and build a mobile version using Qt Quick (the new hardware-accelerated and mobile-ready interface layer of Qt).

@bjorn

This comment has been minimized.

Owner

bjorn commented Jul 6, 2018

Some years ago a major sponsor had asked me to work on this and I've made a start on it. This work is available on the wip/qtquick branch and currently functions as a basic map viewer, with pretty good performance.

Even as a viewer it is not ready to be published and a lot of work remains to be done of course. Personally I think there currently are a number of higher priority things on the Tiled roadmap for versions 1.2 and 1.3, but after that I think we should definitely consider allocating part of the time I work on Tiled to the Qt Quick version (which is not necessarily only interesting for mobile - it could form the basis of a better desktop Tiled as well).

@PuppetMasterHex

This comment has been minimized.

PuppetMasterHex commented Jul 12, 2018

Hi @bjorn,
did you see my port of wip/qtquick tiledquickplugin to work with unmodified libtiled master branch?
If not you can find it here: https://github.com/PuppetMasterHex/tiled-qml-plugin

Maybe it will be of use for a qml version of tiled.

@bjorn

This comment has been minimized.

Owner

bjorn commented Jul 12, 2018

@PuppetMasterHex I wasn't aware of this port, but does it have a purpose beyond working with current master? I've been merging master into wip/qtquick from time to time recently, so the wip/qtquick branch is not very dusted. The main difference in libtiled between that branch and master is that all the base classes are now QObjects:

https://github.com/bjorn/tiled/compare/wip/qtquick#diff-90064268292c5dca771036fc31fa1f98

This allows their properties and some of their methods to be made available on the QML side (though I'm not sure if I'm already relying on that anywhere yet). So for example when we add support for visualizing the objects, we should be able to simply bind to the properties. Of course, time will tell whether this approach leads to nice code and performs well (I'm a little worried about the overhead, have no concrete measurements).

@PuppetMasterHex

This comment has been minimized.

PuppetMasterHex commented Jul 12, 2018

The port works without subclassing libtiled classes from QObject

@bjorn

This comment has been minimized.

Owner

bjorn commented Jul 12, 2018

The port works without subclassing libtiled classes from QObject

I don't remember whether I already wrote any code that relied on the subclassing of QObject. It was mainly a preparation for being able to attach to properties of these classes in QML. Do you know what changes you needed to make for this?

@PuppetMasterHex

This comment has been minimized.

PuppetMasterHex commented Jul 12, 2018

The QuickItems have getters for the properties of the libtiled classes.

Also instead of passing a Tiled::Map pointer to the QtQuick MapItem a model view like approach was used where the MapLoader is passed as mapSource:
https://github.com/PuppetMasterHex/tiled-qml-plugin/blob/master/src/mapitem.h#L49

mapSource in the qml example:
https://github.com/PuppetMasterHex/tiled-qml-plugin/blob/master/example/qml/main.qml#L269

Also the ObjectGroupItem QQuickItem was added:
https://github.com/PuppetMasterHex/tiled-qml-plugin/blob/master/src/objectgroupitem.h

And I added support for ObjectTypes:
https://github.com/PuppetMasterHex/tiled-qml-plugin/blob/master/src/mapitem.cpp#L58

Edit: seems like it was only getters for properties, it's been a while since I last opened the code

@PuppetMasterHex

This comment has been minimized.

PuppetMasterHex commented Jul 12, 2018

If you want to, I can polish the plugin code and send a pull request against master to add it back as src/tiledquickplugin in ~2 weeks.
it would be easier to test / get comments on the qml API.

@PuppetMasterHex

This comment has been minimized.

PuppetMasterHex commented Jul 24, 2018

In the next days I have some time to work on the tiledquickplugin.

Did you decide if you want to stick with the QObject based version?
Otherwise I could start to reintegrate my port into tiled master and send a PR.

Of course I will add a foresighted approval allowing the relicensing of my changes to the code.

@bjorn

This comment has been minimized.

Owner

bjorn commented Jul 24, 2018

@PuppetMasterHex I'll spend some time tomorrow afternoon to try figuring out whether to stick with QObject or whether to wrap all these classes with QML-specific interfaces to allow access to the properties. My idea was to keep the amount of duplicated code to a minimum to reduce maintenance. Do you think there is any particular advantage of keeping the QML interface completely separate?

@PuppetMasterHex

This comment has been minimized.

PuppetMasterHex commented Jul 24, 2018

There is a minor overhead (IIRC ~160 Bytes) that comes with QObject classes and the compile time is longer (moc invokations), but these aren't really issues with modern hardware.

The main reason why the port is avoiding the QObject based types is because I wanted to stay compatible to master without rebasing/merging all the time.
The wip/qtquick branch seemed dead at that time since the last change was:

879fb85 - Mon, 10 Apr 2017 15:21:00 +0200 (1 year, 3 months ago)
Merge branch 'master' into wip/qtquick -- Thorbjørn Lindeijer

So the code was changed to work as standalone plugin with the unchanged libtiled master branch.

If you decide to keep the QObjects, then the ObjectTypes support and the ObjectGroupItem class could still be added to wip/qtquick

@bjorn

This comment has been minimized.

Owner

bjorn commented Jul 26, 2018

@PuppetMasterHex Sorry about not getting to this, I'm too busy trying to finish my work on the export options, which is much more tricky than I had anticipated and I'm trying not to switch tasks too much. On this issue I'd also value the input from @mitchcurtis, who's doing some work on Tiled Quick as well (see #1984).

My hunch is that wrapping all basic classes with QML items will have more overhead than making the basic classes QObject, but we'll need to see.

@mitchcurtis

This comment has been minimized.

Contributor

mitchcurtis commented Jul 26, 2018

I would vote for sticking with the current code in wip/qtquick. I haven't had any issues with it so far.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment