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".
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.
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.
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.
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?
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
> 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.
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.
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.
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.
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 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.
I think there's a niche to expand here. Not necessarily GNOME, but GTK or Qt apps in general.
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.
>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.
32 comments
[ 3.4 ms ] story [ 87.2 ms ] threadThe 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".
https://www.gnome.org/donate/
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.
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.
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.
I suspect GNOME would rather expect everyone else to adopt devhelp formats[1].
[1]: https://gitlab.gnome.org/GNOME/devhelp/-/issues/1
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.
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?
But it's not for lack of trying...
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.
>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.
It wasn't worth my time.
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.
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.
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.
[1]: https://opencollective.com/y-collective
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.
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.
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.