I’ve dabbled. I haven’t actually published anything, but I’ve cobbled some personal stuff together here and there.
GTK and libadwaita are the main things you want to look for. There is a lot of documentation, but not all of it is very clear, and some things are not all that well documented. Following the GNOME developer documentation should cover the L5.
Here are two apps I wrote years ago that “worked”, but who knows if they would work now. I haven’t tried building or running them in a while, and I never got them to a point that felt good enough to release. Maybe one day.
Unfortunately, there is no good WYSIWYG editor. The current state-of-the-art seems to still be defining the UI as an XML file
Probably the easiest SDK type experience is to use GNOME Builder and Flatpak. The upside of using these is that they do a lot of things for you. The downside of using these is that they do a lot of things for you, so it can be difficult to understand what is actually happening, where it is happening, and how it is happening.
It also seems like there might have been some recent progress on a WYSIWYG editor after all:
I heard about Cambalache a while back, but at that time, I heard it was basically unusable. Maybe it is usable now, but I think most apps you would be able to find on the GNOME Gitlab instance will not have used it
From my experience developing an application that runs on the Librem 5. The easiest way is to develop it on a Linux desktop with GTK + libhandy or libadwaita. Setup a flatpak for the application and publish it on Flathub. If your application is open-source, it’s not difficult to get it approved. As result you get your app build as flatpak for x86 and arm released automatically and if your users add Flathub as repository they can simply install the latest version getting automatic updates.
The whole integration is already pretty solid and I would argue it’s easier than getting an app into Google Play Store as with Android.
If your users don’t add Flathub as repository, you only need to make very minor adjustments to get your flatpak ready for Purism’s own repository.
Another option that may also work is shipping your application as AppImage or compact script (for example a Python script is quite portable for smaller apps). So users only need to download it to use it. Wouldn’t be integrated into the store though but it takes very low effort to publish like that.
Man, I wrote an app for my Librem 5 while on a car trip one time. My friend and I, we both had Librem 5s in his ancient car that doesn’t have the computerized map systems or whatever, and we were in the car of sanity with no Androids. And then we were talking about apps while he drove and I was in the passenger seat. And I wrote an app in vim and added it to my home screen as a desktop entry. The app was a political joke because somehow we got to the topic of defunding the police cars we were passing that stressed us out while driving. So the app was called “Defunder Gun” and it had a big button I could press that would count up the number of times that I had “defunded” officers we passed.
Politics aside, making that took like a couple of minutes. It doesn’t need an SDK and it doesn’t need a separate computer. All that trash – to me – is starting to only feel like a way for corporations to make you think that you shouldn’t be able to control your life. Why do I need that? Librem 5 runs GNU programs. You can make them however you want. I wrote Defunder Gun in Java. Okay fine. But you could also make it in GTK if that’s your style, or Qt, or whatever. And you can do that on the device itself without a computer.
For me it’s no contest. Librem 5 wins totally. The program is the other human beings who don’t know, and can never know, because they have been trained that phones should not be command line.
Edit:
One thing that helped me is that I have App of Apps on my home screen. This is an app written by ChatGPT that allows me to pick an icon, a name, and a shell script and then it spawns a new desktop entry there on the Librem 5. It was originally created for Linux desktops but runs perfectly on Librem 5 and can make an app icon of itself on home screen. Source code is on Codeberg but it was literally written by ChatGPT: etheller/DesktopEntryCreator: A tiny GTK utility for creating .desktop files. - Codeberg.org
I’ve created an app for the Librem 5. I learned Vala and GTK, set up Gnome Builder and a couple of weeks later I had a meditation app. I would not say the learning curve is very gentle. Most of the Purism documentation was outdated a year and a half ago when I built the app. Also, I would have published on Flathub or something, but I couldn’t get the metadata in the Flatpack showing up correctly locally and nobody on the Purism or Gnome forums could help me with that. Plus I had to create an icon, and I’m a backend developer, so I gave up
Then again, it’s very easy to create a small app if you just use yad and a app.desktop file plus some free icon you scoop up somewhere. I was pleased about that.
And in just a few minutes, Google now knows which lights you have on and which lights you have off, and so potentially where you are in your house, or whether you are home at all. Heartwarming.
The fundamental problem (in the scenario presented) will be that the interface with the light bulbs won’t be documented or will only be available under unacceptable conditions. So you can’t really develop that app at all unless the manufacturer is prepared to share the interface documentation with you and do so under acceptable conditions.
That’s a good question and I don’t think anyone has got anywhere near that as yet. Probably Purism would be most interested at this time in people forking and fixing existing apps and then making a Merge Request. And of course really in many cases those changes should be merged upstream.
I think that would depend on your familiarity with the chosen application framework, as well as the complexity of the app in question.
“Hello World” is certainly a good start - to understand the absolute minimum for “how long”.
I copied some Java “binaries” over from an x86 desktop/laptop. The GUI programs didn’t work and I have not spent the time to find out why. The non-GUI programs “just worked”. I guess that’s a bit of a cheat since I didn’t write any program specifically for the Librem 5.
Several years ago, I learned a few things about working different hardware architectures. I was shocked at the time to get as far as I did. Here is how things progressed.
1.) Bought a $40 Android phone so to not put my $1000 Samsung phone at risk.
2.) Rooted the $40 Android phone.
3.) Found and installed an Android app that required root privileges, but that installed a “chroot” system that allowed me to install a full authentic Debian distro on to that $40 phone, and to boot in to a real Debian desktop.
4.) Found, paid for, and installed an x86 compatability layer called Exagear and installed it in to that Linux distro. Too bad the Exagear compatability layer is no longer available now. It was extremely cool. From a terminal window, I could type “Arch” and it would return “ARM64”. Then, I could type “Exagear x86” and then again “Arch” and it would return “x86” to identify the architecture. So I could flip back and forth between architectures and install and run programs on either or both architectures, from the same terminal window.
5.) After a whole day of working on a four inch screen, to run programs from a debian desktop, my eyes started hurting and I moved to my linux pc, where I was able to SSH in to Debian on the phone and set the display back to a full sized monitor.
6.) Installed x86 wine on to the phone, in the Debian installation, inside of the chroot, inside of the Exagear compatability layer, under the phone’s Android operating system. So now I was five levels deep, in to different emulation/OS layers.
7.) Installed the Windows notepad.exe program in to Wine. It worked.
8.) Installed a very large program that my employer sells under Wine.
9.) Went to one of my colleagues in the programming department at work and said “hey, look at this”. When I opened the program on this four inch screen of a well known brand name phone, everything started out beautifully. Our company logo came up, followed by the name of the program, and then the program GUI came up. This colleague was one of the contributors to the writing of this program. But after the program was open, It was like looking through a keyhole as you could move the screen around to eventually see the whole program GUI a small amount at a time. This colleague had a shocked look of disbelief on his face. I told him that this program runs flawlessly on this phone with one exception, the USB port wouldn’t communicate. Considering that this program was written to connect to other hardware via USB, as a device programmer, that made the whole program running on this Android phone pretty useless. I asked if he could share our employer’s code with me and help me to troubleshoot the USB issue. I am typically a hardware person and had hoped that he might want to jump in to help. He quickly lost interest and didn’t want to share the code with me. I was dissapointed as I saw the potential of having a Field Applications Engineer, plugging their phone in to a customer’s application, and uploading new firmware in the field. I suspected that somewhere in passing through several emulation layers, that access to the USB port was lost. It was a fun hobby project. But it went nowhere. I learned a lot in the process though. What amazed me though is that the CPU and other hardware resources on that $40 phone didn’t simply fail at some point as I stacked one more emulation layer and OS on top of the other.
What are you trying to say? That your Librem 5 works no better than a $40 piece of trash?
I find that mine is faster than the $40 piece of trash phones that I had several years ago. The basic Phosh experience is substantially better, even in comparison to Android running on the pieces of trash.
The librem 5 is way better than the $40 piece of trash phone. But not for reasons that most people might think. Any mass produced electronics is going to be inexpensive, even if it has comparatively the same or a similar capability to a much lower volume device that costs much more to manufacturer. So the hardware on that cheap phone was probably equal to the capabilities of the Librem 5, which is not procuced in nearly the same volumes as the $40 piece of junk phone. For one, the $40 phone had an SoC (system on Chip), which greatly reduces per unit costs if you make several million of them. So the value is not in the electronics, it’s in the specific design and in the production volume, if run at lower volumes. The mainstream high end phones are relatively cheap to make too. But the phone manufacturers can demand high prices. So they do demand a higher price. And they get it.
The issue is not so much about finding a way to resolve one issue like with the smart bulbs. The issue as I see it is about the Librem 5 (and Pine Phone for that matter) software eco-system. As an Engineer myself, I am sure that I can solve any one of these issues like getting smart bulbs to work from the Librem 5. But notice that I didn’t say that with the Android phone, that I put my knowledge and experience as an Engineer to work, spent some additional money, wrote some code myself, and then several weeks later, I had resolved the issue. That is not what I said. What I said was that I bought the bulbs at Home Depot, screwed them in, and five minutes later, I was controlling them with the Android phone. There are a multitude of other apps. I mentioned the app to go with my local gym membership. Then there is an Amazon app, Cox TV/Internet app, SolarEdge solar power monitoring app, movie theatre app, and many more.
There needs to be a business plan that causes Librem 5 apps to proliferate. Google’s plan is to make it easy for people to create and sell their own apps. That won’t work for the Librem 5 unless the apps motivate people to voluntarily donate money to the app creator. But what if someone goes to that light bulb manufacturer and says, “for x amount of money, I’ll build and distribute an app in linux that works on your product”. The same could be true for the movie theatre, the gym, etc… So right now, it appears to me like a lot of opportunity exists for app-writers. Someone could even open a local store selling Librem 5’s, Pine Phones, and de-googled Android phones over the counter. So while things are slow, especially at first, you tend the store while writing Librem 5 applications for local businesses. One big account could set a person up quite well, especially if you can get a small percentage of their product sales. I think that there would need to be several different levels of service for someone who goes in to that business. For a company that has their own software writers on staff, you charge $500 (just for example) to have you come in to their facility for a day, set up one of their PC’s with the appropriate programming environment and opensource tools, and teach them how to write opensource code using opensource tools. I can only imagine that when you take away the average professional programmer’s Google, Apple, and Microsoft, they revert to a state of knowing nothing about programming, at least temporarily. For companies that don’t have their own programmers, you could charge per app. This is just an idea.
Well, yeah, I’m fairly suspicious of smart home tech even if it has fully documented interfaces that therefore can be controlled by open source software.
It still increases your attack surface.
Unless the entire thing is 100% open source, it still creates privacy and security risks that you will find it hard to measure, manage, mitigate.
I still struggle to see the benefit as outweighing the cost.
But at the end of the day the OP is free to explore and use as he sees fit.
I wonder what would happen if you install the Raspberry pi app directly to your Librem 5. Both use ARM architecture. There are a lot of raspberry Pi apps that run from a desktop environment on the Pi. But I do know that in the ARM world, that it’s not like a PC where any hardware will work with any software and be compatible.