You assume correctly.
Honestly for the kind of things that I would probably be interested in (i.e. what is missing from a new mobile phone environment at Day 1), I would generally only be concerned about how well it operates and how usable it is on a tiny display. Convergence isn’t a priority for me and the existing desktop/laptop environment is fairly comprehensive for my needs.
However as it would be my Day 1 too, any GUI application that I can write is a start. 
I expected it to be much harder, but looking through the examples, it doesn’t look that hard to use GTK. Any advice on learning GTK?
Has anyone tried using the Rust bindings for GTK?
Is Rust+GTK stable enough to use?
It seems like these are already being used for the Shortwave app, which is written in Rust.
I only found out about this from Alexander Mikhalyenko’s blog post on his very cool libhandy work, which was mentioned in another thread. (GNOME gestures for Phosh)
I can’t speak to Rust+GTK, but GTK is old enough and stable enough there’s no reason it shouldn’t be stable. As for advice on learning GTK, the docs are decent, stackoverflow often has solutions to the non-obvious bits. I don’t ever do anything fancy, so I don’t have a lot of additional advice.
Another option to consider, if you want to develop cross-platform stuff, is WX. It’s a wrapper over GTK (on linux, or whatever the windows and mac equivalents are), I used it about 10 years ago when I was doing UI work on a regular basis. It handles most of the tedious bits for you, while still letting you access the underlying properties when needed (which should let it rescale for phone-displays without too much effort).
I’m in a late batch I’m sure (ordered Jan-2019), so it’ll be a while before I can do anything myself, but I figure I’ll do some playing with it when I can. I may get impatient and grab the qemu image when the first physical devices ship.
I would like to create something that is cross-platform. Is the code for a GTK application that different between Windows, Linux and MacOS? I assumed that it would be basically the same. I’m guessing that if I want libhandy to work with my app, I going to have to write my code in GTK.
GTK does work everywhere it’s installed. WX will (mostly) transparently use whatever window drawing system is available. This means it works on windows machines without GTK, and it looks native both on windows and on mac. GTK may not be installed on windows machines. You could also ship a copy of GTK with your application on windows, which has some advantages and drawbacks.
That’s a very strange idea for me, as someone who often prefers doing things via the command line even on my smartphone. I assumed there wouldn’t need to be much work on software which already had a command line version, because command line software already works on basically everything!
Just happened to see this today, a tool/language to wrap CLI with a GUI
https://chriskiehl.com/article/gooey-as-a-universal-frontend
Yes I have.
The bindings are stable, but it takes a little getting used to due to how GTK/Glib is designed with its reference counting and mainloop design together with Rusts lifetimes and multi-thread safety mechanisms. It also seems like the bindings are being well maintained.
If you want some examples of a good Rust+GTK application you should take a look at fractal, I used that as a reference a few times when there was basic things which I was unsure about how to solve.
I’m largely the same way, I tend to live for extended periods in an emacs-nw full screen. That said, various of my family members, who use Linux just because I insist if they want free tech support, are much less happy on the command line. Most of the GUI work I do is wrapping the commands they’d have to remember over and over again into simple button lists.
In case anyone missed the edit above, libhandy is the GTK library for doing portable mobile/non-mobile GUIs. Not sure exactly what is required to hook into it, but that’s probably documented in its gitlab repo.
Yaaayyy python! 
Good choice for developers/programmers and an excellent choice for people like me who aren’t! (using years of nullege, stackoverflow and 2to3 of course)
@kieran saw your comment about programming on GNU/Linux and look forward to seeing what you make
Starting from scratch, I will set expectations low.
Never touched Python but I’ve got a book.
I’ll need a phone first … I wonder when that will be.
All you need is a computer, or access to a computer, and a knoppix cd or usb if you don’t want to commit to anything (but if you do want to commit, Debian raawks :)).
Yes thanks @DemBeesDoneStolenAll , I have plenty of computers and they all run Linux.
It is the programming side that I have never tackled on them e.g. GTK, Python. On top of that is then the cross-development side i.e. develop and test on desktop/laptop, then debug it all over again on the phone .
Ah, sorry, assumed there would be other non-techies here too Hopefully, the emulator helps reduce a lot of that work for you
I strongly advise against 2to3. It’s broken, it’s always been broken, I’ve raised the issue before, it seems it will always be broken.
If your python2 code was broken, it might come out okay. If your python2 code was not broken, it will break if you use 2to3 on it.
HA HA HA! My code is broken, it’s all sorts of broken! Probably because never studied any thing related to computers. I strongly believe that you shouldn’t have to be a programmer or developer to write code, just as you needn’t be a chef to make Sunday roast. That’s why I’m also loving that Purism is looking at flatpack for applications (and I’m sure they’re be an approval process of some sort)…I can’t break anything of someone else’s if I’m stuck in my own little sandbox
Fair enough, but that only means it might work. The biggest problem with 2to3 is it turns all bytes literals into unicode literals. This is because most novices used bytes literals where they should have used unicode. But if you are doing anything network related (or other raw IO), it breaks your code. And it does so in a way that you cannot after the fact tell what got improperly converted. As a related issue, invocations of the str function don’t get changed to bytes, and the unicode function goes away, so invocations of it get mapped to str too.
I’ve found it is far faster and easier to convert even enormous code bases by hand than to use 2to3 and try to fix the mess. Doing it by hand, if you are in a hurry, lets you put unicode = str at the top of a file, and then just go through and find all string literals and str and make sure the literals are prefixed by either u or b, and convert all str to bytes (or unicode if it should have been unicode in the first place).
I gave up on Python when it moved to version 3 and started using other languages that didn’t demand that I code in a certain way.
Of course, Rust is even more annoying in that respect and it doesn’t pretend to make anything easy for the programmer like Python does.
Although PHP is kind of a crappy language, I find myself using it simply because I doesn’t try to impose a particular style on me and generally lets me do what I want.