Mobile App

[hackervera]

Any plans to port this to mobile? A messaging app on desktop-only just isn't very practical for me

[mempko]

Totally! A mobile port is definitely planned. I wrote the backend fairly separate from the frontend. However, I can't make it happen without help as there is lots of work involved making a new GUI to the backend.

If you know anyone who wants to give Qt Quick a try, I would appreciate making mobile possible, and I am sure many phone users like yourself would too.

[arduino-man]

Hi I am somewhat knowledgeable in IOS development and would be happy to have a shot at implementing this on that platform! Let's talk when you have a chance man. Cheers and congrats on this great project. Found it on gnu.org

[mempko]

I of course would love help developing an iOS version. However, my understanding is you cannot release GPL licensed software on the app store.

http://apple.stackexchange.com/questions/6109/is-it-possible-to-have-gpl-software-in-the-mac-app-store

It seems I would need to release the software under a separate license while providing the source independently. Do you know if this is true and how would you approach this problem?

[arduino-man]

You raise a good point. Yes I believe what you say is 100% true. If all the code used in Firestr is your own creation, then you can release it under more than one license for example GPL and MIT which would allow us to put it in the app store. Additionally in the app’s “about” button we would put a link to your github repo for anybody who wants to get the code.

Cheers!

On Apr 18, 2016, at 1:02 PM, Maxim Khailo [email protected] wrote:

I of course would love help developing an iOS version. However, my understanding is you cannot release GPL licensed software on the app store.

http://apple.stackexchange.com/questions/6109/is-it-possible-to-have-gpl-software-in-the-mac-app-store http://apple.stackexchange.com/questions/6109/is-it-possible-to-have-gpl-software-in-the-mac-app-store
It seems I would need to release the software under a separate license while providing the source independently. Do you know if this is true and how would you approach this problem?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub #17 (comment)

[mempko]

I also realized another potential problem. Firestr apps are written in lua, and the iOS app would have foreign code pushed and executed on it in the form of lua scripts. My understanding is that apple had a very explicit restriction against this. Has this policy changed?

[mempko]

Also, do you have any experience, or want to get experience with QML? My original plan with the mobile version is to convert the QtWidgets interface to QML, and then it would support all the mobile platforms with one large effort.

[arduino-man]

Hi!

Sorry for the delayed response I was stranded at a hospital for a little project for a couple of days.

I actually don’t know QML it would be awesome to learn some. Any suggestions?

Also, regarding the lua scripts, I hadn’t heard of that policy but will make sure to re read their app store guidelines and see what I can find.

Cheers!

Mario Solorzano

On Apr 21, 2016, at 1:50 PM, Maxim Khailo [email protected] wrote:

Also, do you have any experience, or want to get experience with QML? My original plan with the mobile version is to convert the QtWidgets interface to QML, and then it would support all the mobile platforms with one large effort.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub #17 (comment)

[mempko]

The lua apps communicate with the frontend via messaging, and the frontend talks to the backend the same way. Each lua app runs in it's own thread and has it's own message queue. You can think of them like actors.

The frontend interface is defined here.

https://github.com/mempko/firestr/blob/master/src/gui/api/service.hpp

The QtWidgets implementation of the frontend is here.

https://github.com/mempko/firestr/tree/master/src/gui/qtw

The frontend_client is a shiv that handles calling the frontend asynchronously. It is how the backend thread talks to the frontend.

The backend has a pointer to the frontend_client and calls the functions. The functions emit messages to the GUI thread to handle the gui calls.

An idea to start is instead of replacing the whole application with QML, we can replace the QWidget implementation first with QML and leave the shell app as QWidgets. Once we have the QML implementation of the Lua Apps, we can then migrate the shell.

What do you think of that strategy?

[trosel]

can't you use LOVE2D for cross-platform apps? https://github.com/love2d/love#ios