[Librem-5-dev] PyGTK+ app development and testing on qemu image
david.boddie at puri.sm
Mon Oct 28 06:56:32 PDT 2019
On Sun Oct 27 10:14:53 PDT 2019, Richard Duivenvoorde wrote:
> First post on this list, let me know if I need to move to another list..
This is the correct list. :-)
> My goal is to create an 'app'lication for the Librem 5 to
> show/publish/subscribe MQTT topics. For Android user: mimic MQTT-Dash
> app .
> Developing in Python3/Builder on Debian, using latest Purism5 VM
> I do have some experience with App development on Android and GUI
> development on Linux/Python with Qt (QGIS.org plugins).
Sounds like useful experience to have.
> Creating my first prototype I have some questions:
> - In Android there is a clear "Activity Lifecycle": what to do when the
> app is in view or not etc etc. In my case I would want to stop the mqtt
> messaging while the app is not in focus.
> But I could not find an PyGTK+ signal which is fired when my application
> windows get's in focus or so. Did I miss something?
I think you need to be looking at some of these:
These are the ones that I would use to monitor the visibility of the
> - While not having a real phone, is testing in the qemu VM a good way to
> test? (looking at performance etc etc)... because:
The VM does not perform as well as it should and it's not exactly clear to me
why. You can also test in your own native workstation environment - assuming
that you are using a GNU/Linux distribution. When you have got everything
working, then you can worry about granting the permissions needed for the app
to run on the phone. You can always generate flatpaks for testing on your
host system if you want to make sure that you have the permissions set
> - I do have some performance issues in my VM, not sure if it has
> something to do with my code (which retrieves a lot of MQTT signals and
> tries to update parts of the visuals in the app): all seems to be OK,
> but after (for example) pushing a button the app takes 100% of a cpu
> thread (gave the VM 2 cpu's and 3 Gb RAM).
> It is not clear if of what is creating havoc at that moment: the mqtt
> thread, or the updating of the 'tiles' (set_markup of labels)
> Any hints on how to investigate that?
Nothing comes immediately to mind. Some simple profiling or monitoring of
signals. Perhaps someone else can suggest something.
> Thanks for any input, and I hope this is the right channel for these
Yes, this mailing list is definitely the right place for discussions like
It might also be useful to ask for general guidance about GNOME/GTK programming
issues in a topic at the GNOME Discourse server: https://discourse.gnome.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 659 bytes
Desc: not available
More information about the Librem-5-dev