Funding decentralised/local-first applications for GNOME(blog.ergaster.org)
blog.ergaster.org
Funding decentralised/local-first applications for GNOME
https://blog.ergaster.org/post/20220422-decentralised-local-first-applications/
32 comments
>It makes me wonder what redeeming qualities Electron has.
Electron still lets you write code that is "native" to the web browser and functions primarily as a remote web app with no installation. It's not comparable to any of the desktop toolkits that focus on being local-first, those toolkits can't do this. Qt has WASM support but you probably don't want to use that with anything that isn't C++. And GTK doesn't really have any WASM support.
Electron still lets you write code that is "native" to the web browser and functions primarily as a remote web app with no installation. It's not comparable to any of the desktop toolkits that focus on being local-first, those toolkits can't do this. Qt has WASM support but you probably don't want to use that with anything that isn't C++. And GTK doesn't really have any WASM support.
“Local first” is an excellent moniker, great way to distinguish software like this from other “decentralized” efforts that are out there right now.
Great point, it really does help frame the context: "you're local first but you allow A, B, and C - so you must allow/have X, Y, Z functionality."
The term "decentralized" has also been sullied a bit lately with relative failure of self-described projects, no rocket ship growth of legitimate federation projects (not yet anyhow), and was also another term that the Bitcoin et al "communities" misappropriated - along with the word "currency".
The term "decentralized" has also been sullied a bit lately with relative failure of self-described projects, no rocket ship growth of legitimate federation projects (not yet anyhow), and was also another term that the Bitcoin et al "communities" misappropriated - along with the word "currency".
> GNOME is a good candidate to focus on empowering developers to make local-first apps: applications where the data lives on your device(s) and is shared locally, without relying on any cloud service.
Then they should focus on actually having a full stack SDK development experience instead of throwing it all away with Gtk 4, like it happened with Glade, Anjuta, and whatever else keeps being redone.
Then they should focus on actually having a full stack SDK development experience instead of throwing it all away with Gtk 4, like it happened with Glade, Anjuta, and whatever else keeps being redone.
I don't understand what you are trying to say but Anjuta and Glade are respectively
22 and 24 years old.
Anjuta stopped making progress well before GTK 4. GNOME Builder is a great alternative and was developed with GTK 3, the GTK 4 port is coming along quite well thought.
Glade is being phased out for Cambalache by its own maintainer.
I find GNOME development/platform refreshing because it's not hype driven, and it doesn't reinvent itself every year.
Anjuta stopped making progress well before GTK 4. GNOME Builder is a great alternative and was developed with GTK 3, the GTK 4 port is coming along quite well thought.
Glade is being phased out for Cambalache by its own maintainer.
I find GNOME development/platform refreshing because it's not hype driven, and it doesn't reinvent itself every year.
Glade will likely be replaced by drafting: https://gitlab.gnome.org/chergert/drafting
Cambalache still remains to be seen if it will ever happen.
The talk about its roadmap is about two years old, the author was asking for monetary support, and it has an Electron like design using browser rendering for Gtk.
The talk about its roadmap is about two years old, the author was asking for monetary support, and it has an Electron like design using browser rendering for Gtk.
Your comment is out of line. Nothing was "thrown away" in GTK4 unless you consider it "throwing away" that apps have to port to a new API to make use of a new API. Please read the full article, particularly this part:
>Given the Foundation doesn’t sell products or services, it can only happen with targeted, planned and transparent programmes, funded by donations. Because of the very open nature of the GNOME Project, the Foundation can’t decide for one direction of the GNOME Project for everyone
If you think working on the SDK is a good direction, then you should join the community and work on it, or donate to someone else who's already working on it.
>Given the Foundation doesn’t sell products or services, it can only happen with targeted, planned and transparent programmes, funded by donations. Because of the very open nature of the GNOME Project, the Foundation can’t decide for one direction of the GNOME Project for everyone
If you think working on the SDK is a good direction, then you should join the community and work on it, or donate to someone else who's already working on it.
I did, almost 20 years ago to Gtkmm, doing advocacy, publishing some articles to The C/C++ User's Journal.
It wasn't worth my time.
It wasn't worth my time.
Yes, with the benefit of hindsight you could say that most things are probably not worth anyone's time. If only we could see 20 years into the future to know which ones aren't, then that would save us all some time right now.
Or you could take another outlook and just accept that the work involved in sustaining any community is ongoing and it never ends, no matter how hard you try.
Or you could take another outlook and just accept that the work involved in sustaining any community is ongoing and it never ends, no matter how hard you try.
Leave out the GNOME bit. It would be nicer that way. Look at Synching, and DecSync built on top of it for example: https://github.com/39aldo39/DecSync
I love the idea of decentralised apps for freedom of thought and privacy reasons.
One quibble with this claim: "with no server running 24/7 just to sync the data every once in a while, you avoid the production of the server in the first place and the energy it consumes when running."
Has anyone done any studies on this?
I personally wonder if a million book authors using Google Docs online on Chromebooks is going to be more energy efficient than a million local PC's running Libreoffice on Ubuntu?
One quibble with this claim: "with no server running 24/7 just to sync the data every once in a while, you avoid the production of the server in the first place and the energy it consumes when running."
Has anyone done any studies on this?
I personally wonder if a million book authors using Google Docs online on Chromebooks is going to be more energy efficient than a million local PC's running Libreoffice on Ubuntu?
No, because in reality you'd be comparing one million local PC's running libreoffice vs one million PC's running Chrome+frontend and one server running the backend
I am a huge fan of GNOME and it's received lots of polish over recent releases.
The one app I'd really love to see is a documentation browser like Dash.
I plan on having a go at writing it when my current contract comes to an end and I've a bit more time.
The one app I'd really love to see is a documentation browser like Dash.
I plan on having a go at writing it when my current contract comes to an end and I've a bit more time.
Yeah, I'm exploring writing a Dash-clone for Linux as well. The killer feature only Dash has is being able to import the documentation for any package one might use in JS, Elixir, go, etc. I can't live without that.
Me too, there is a gnome app I would love to build, but I earn my living by contracts too and cannot set apart time for my own projects.
It's not GNOME, but there is Zeal.
I suspect GNOME would rather expect everyone else to adopt devhelp formats[1].
[1]: https://gitlab.gnome.org/GNOME/devhelp/-/issues/1
I suspect GNOME would rather expect everyone else to adopt devhelp formats[1].
[1]: https://gitlab.gnome.org/GNOME/devhelp/-/issues/1
Yeah - I've used Zeal a bit and like it.
I spent a bit of time looking at the devhelp2 format and they look quite straightforward, maybe writing a converter utility is the way to go.
I spent a bit of time looking at the devhelp2 format and they look quite straightforward, maybe writing a converter utility is the way to go.
Wish there was a donate link prominently displayed. I love Gnome apps!
There's an opinion I'd never expected to see espoused publicly.
Graphically I love GNOME apps. Usability, I hate them (if you're using a hamburger menu on desktop, you've already failed).
And since GTK throws everything away and start again every now and again (I now have all of GTK2, 3 and 4 on my system) it doesn't feel like a very secure platform for development.
And since GTK throws everything away and start again every now and again (I now have all of GTK2, 3 and 4 on my system) it doesn't feel like a very secure platform for development.
Except they haven't thrown anything away, all they did was create new versions of the API. Just like almost every other major toolkit developer also does. They're all iterations on the same concept.
Also, if you ask me the hamburger menu is fine when it's used correctly and you don't put too many items in it. Some apps don't use it correctly but that's no different from a more traditional app dumping 30 random menu items into the "File" menu which I've seen a lot of badly designed apps do.
Also, if you ask me the hamburger menu is fine when it's used correctly and you don't put too many items in it. Some apps don't use it correctly but that's no different from a more traditional app dumping 30 random menu items into the "File" menu which I've seen a lot of badly designed apps do.
I think this is the GNOME Foundation donate page:
https://www.gnome.org/donate/
https://www.gnome.org/donate/
Work with us! The y-collective [1] is building the foundational technologies for local-first, collaborative applications based on CRDTs.
[1]: https://opencollective.com/y-collective
[1]: https://opencollective.com/y-collective
What is a CRDT? The link gives me a
Heroku server error.
> Because of the very open nature of the GNOME Project, the Foundation can’t decide for one direction of the GNOME Project for everyone:
But it's not for lack of trying...
But it's not for lack of trying...
>> The first project needs to be user research: when there is no Internet available...
Drop the map app that's just a skin over google maps. At least base it on OSM and download maps of interest locally. Apply this "local first" philosophy to all GNOME apps.
Drop the map app that's just a skin over google maps. At least base it on OSM and download maps of interest locally. Apply this "local first" philosophy to all GNOME apps.
GNOME Maps uses OSM, you can see that in the attribution on the bottom right.
A lot of developers, myself included, started working during the post web 2.0 era, and have done almost exclusively web development. A lot of times when I've had an idea for a small app, my default has been to use web stuff to build it because that's what I know. Even if it's just a self-serve tool with no interaction with other users or anything. It's not because it needs to be on the internet. It's just because it feels like to build a "native" app you have to know Swift or C++ or something. Or worse, drag web tech onto the desktop with Electron or something.
I don't know why it took me this long to give it a shot, but you can build a really decent "native" app with Qt by writing nothing but Python (and I presume most other popular languages also have bindings). They feel snappy, have uniform controls with good keyboard shortcuts. You don't have to build everything from scratch using divs in React. You have to learn a little about handling long-lived state and things like that, but I think any competent web developer can also build desktop apps using Qt or GTK. It makes me wonder what redeeming qualities Electron has. People say it's valuable because it lets us take web developer skills and bring them to the desktop. So would making Qt apps.
It may not replace compiled native apps, but I'd definitely love to see a wave of downloadable, offline-first, apps that don't require me to sign up and aren't stuck in my browser.