The author complains about a lack of people interested in developing for the Pinephone, but IMHO the elephant in the room is simply that the PinePhone is too underpowered to enjoyably develop on. Its A64 processor is weak as fuck, and some of us who ordered the PinePhone got the original version with just 2GB of RAM. Not only does it take a long while to build software on the phone, but UI lag for your finished program is long – you will probably have to wait a good 5 seconds just for a window to open.
Back in the Nokia N900 days I did a great deal of hacking on that phone, but that device (even though its specs are much lower than a modern phone’s) had a much more responsive UI and it was actually enjoyable to test out what you had developed.
> It's basically my first C project, first v4l2 project and first GTK3 project but I started it because nobody who actually knows any of these things want to, and so far nobody who knows these things has stepped in to do better (...)
(I probably do not know any of these things better - but if I did, and wanted to help, I'd probably click on the link to the github profile, not find megapixels source... And move on?)
Seconded with building Megapixels on the PinePhone - though I do the actual editing itself on another machine. I have however found that doing clean builds of libraries like libhandy (specifically for building flatpaks) is a lot faster using qemu on a desktop.
I remember feeling like cross compilers for handheld devices were silly in 2006 when I had a Zarus. The only reason not to develop on your Pinephone is because it's in your pocket and you can't be bothered to pull it out and hook a keyboard up.
I don't think this is an insurmountable problem, but it definitely is a problem. I got a (3GB) pinephone late last year with plans to hack on it and write some nice user facing applications as well as exploring ways to help make sure that a phone can help users preserve their privacy.
What's quickly become clear to me is that all of that stuff is futile until we have a better way to build and run applications. The existing shells and toolkits for building applications are simply too heavy for the hardware, and I don't see the situation changing much any time soon. The hardware ought to be powerful enough to do more than it can, but it's going to take a lot more effort to build more efficient underlying components.
Unfortunately, as an individual developer with several other large side projects going on at the moment I don't expect to be able to contribute much to this anytime soon, but I hope that the discussion will prompt some people with the spare cycles to pick this up and run with it.
Sure, but you must have taken special care to ensure that the gobject introspection tools are run using qemu. Or maybe this does not use GIR at all because it is plain C (which I would not recommend for new apps, and neither does GNOME AIUI).
This mystifies me. Why would you not use a cross-compiler running in your favorite desktop development environment, and run gdb in place, there, with gdbserver to control the runtime on the phone?
sshfs gets executables automatically exported to the phone as they are linked.
Doing native builds on the phone seems like deliberately choosing to do it the hard way. [But somebody says GTK will not cross-build. Could that be possible?]
Cross-compiling is frequently harder than compiling natively and you cannot run the build-time tests while compiling, so you will have less confidence in the results.
GTK 3 cannot currently be cross built due to some sort of dependency issue with Python, but random GTK apps can be cross-built just fine, and have been by Debian cross-build QA efforts:
Back in the Nokia N900 days I did a great deal of hacking on that phone, but that device (even though its specs are much lower than a modern phone’s) had a much more responsive UI and it was actually enjoyable to test out what you had developed.