Thanks! They are documentation to some extent here: Examples (Librem 5 Developer Documentation)
I would like to get time to write more examples that use the hardware features of the phone a bit more. Some things are not quite integrated as well as they might be, and that makes documenting them a little difficult. 
Now all I need is a phone.
I’ve never done any Linux programming, so if I am going to write any applications for the Librem 5, I am going to need some examples to hack from. “Hello World” would be a good start.
It’ll have GTK available, so I’d start with some python GTK tutorials, or similar. Then see about adding the mobile-ui GTK bits so it looks decent on a tiny display. I’m assuming you’re not new to programming in general.
If you want to learn the ‘linux way’ of doing things, the art of unix programming is still decent. Basically, the more modular you can make things, the more likely they are to be broadly useful. Lots of linux applications are non-graphical, with a graphical layer added on top. This makes it easy to use directly, while also easy to use ‘headless’, and easy to automate.
Thinking about it, lots of the useful things to make for the librem 5 will just be graphical wrappers around existing non-gui applications, to adapt them to keyboardless touch input.
Edit:
Found the library to make GTK ‘mobile friendly’: libhandy
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.