[Note: This thread is intended to be a discussion thread for the topics in this post. Please keep your replies on topic. Some examples of off-topic replies include:
“When is my order shipping?” (We contact people to arrange shipping and update shipping addresses over email, not in a forum thread.)
“I have a support request.” (These are better handled with the Purism support team.)
“I want to air a personal grievance.” (You can do that in your own topic.)
]
A Mobile Platform
When we announced the Librem 5, we knew we would have to invest in and build a mobile operating system and applications to run on it — by “mobile” understand “for smartphones”. To avoid reinventing the wheel, we decided to base that system on an existing environment. Librem laptops ship with our operating system PureOS, which provides GNOME as its graphical user environment as it is a modern environment and a very active project with which we share many goals, design principles and values.
Touchscreens bring a new set of possibilities and constraints to user interface designs. For many years, GNOME’s main target is laptops, and it acknowledges in its design that they can have touchscreens. All of these factors made GNOME a serious candidate for Purism to turn into a mobile platform, and using it on both the Librem laptops and the Librem 5 brings some very valuable consistency to our broader software ecosystem and user experience.
To feed that system we need mobile applications, but rather than creating mobile duplicates of existing GNOME applications, we decided to take an approach the web has been doing for years: making existing GNOME applications adaptive. Making an application adaptive not only makes it work on smartphones just as well as on laptops, but it allows it to work well on anything in between, e.g. when its window is small or tiled. Adaptive applications also means same app code for multiple device sizes.
Speak for yourself. Purism can’t do anything about the covid situation; they would be glad to get the phones out and receive even more orders. Please stop spamming all topics.
Last warning. If you want to air a personal grievance you can do it in your own thread (as I mention in the disclaimer at the top of this thread). If you continue down this path we’ll have to resort to moderation. I’d like this thread to stay on topic so people can discuss the post.
Cool article! I really like the idea of taking something that works on laptops and make it work on phones, as opposed to creating a new independent system just for phones.
The whole ecosystem gets better, and other people can build on top of it and so on.
Kudos to Adrien for getting adaptive widgets to become a fundamental part of GNOME. It is really encouraging to see the GNOME ecosystem becoming adaptive for mobile devices. This is why I think it is so important to back companies that pay for software development.
I take it from this post that libhandy isn’t going to become part of GTK 4, as originally planned. That kind of makes me sad. Are there any reasons why it was decided to not make libhandy part of GTK 4?
I have a few nitpicks. In the article, change the text from:
With Libadwaita now hosting the Adwaita stylesheet and thanks to Alexander simplifying it,
to:
With Libadwaita now hosting the Adwaita stylesheet and thanks to Alexander for simplifying it,
I also can’t see any changes in the last video showing a “neat stylesheet transition animation”. Does the video show the animation or is it really subtle and I am just missing it?
Not quite. LibHandy is for GTK-3 and LibAdwaita is for GTK-4 (and LibAdwaita is based off LibHandy, see below)
LibHandy grew into a semi official widget library to implement GNOME HIG, there are some MR on Gnome Gitlab to illustrate that, for instance: https://gitlab.gnome.org/GNOME/gnome-music/-/merge_requests/803 (in there, GNOME devs says this app, music, should use some Hdy widgets for GNOME 40 UI patterns).
Now with GTK-4 and LibAdwaita, it is official: LibAdwaita is the library to use to implement GNOME HIG a top GTK-4. And GNOME HIG are now considering mobile/tablet screen sizes as well.
IMHO, we could not hope for a better turn here, it means all GNOME softwares will progressively align with the HIG (since HIG compliance is a requirement for being an official GNOME project) so it looks like this is really going in the right direction.
As long as you stick to making it “Adaptive for” and not “Pleasing”. Because we all know what happens with the philosophical proverb of trying to “please everyone”. (You’ll become another M$oft or Apfel.)
@henry-nicolas,
I don’t think I made my question clear so let rephrase it:
Why was it decided that the adaptive capabilities of libhandy are going to become part of GNOME, rather than becoming part of GTK? Isn’t it better to have adaptive widgets built into the toolkit, rather than making them part of GNOME’s style library?
It seems to me that libhandy’s adaptive widgets should be available to anyone using the GTK, rather than the smaller subset of programs that use the GNOME libraries.
The original text is correct and your suggestion changes its meaning to something completely different. It’s “new features are possible thanks to Alexander simplifying the stylesheet”, not “thank you Alexander for simplifying the stylesheet”
In a nutshell, my understanding is that the tradeoff that has been made is that LibAdwaita does not only care about adaptiveness through dedicated widgets but it is also the official mean to implement GNOME HIG.
Why not make it part of GTK? GTK development cycle is independant from GNOME releases, still the HIG evolves alongside GNOME releases so a library which helps implementing the HIG needs to be close to GNOME development/release cycles.
In Adrien blog post, it is also mentionned that having a HIG that is well alive and GTK releases not necessarly following those of GNOME led to code deduplication since developpers had to support the HIG without relying on standardized components offered by an official library such as LibAdwaita.
Quoting Adrien :
Implementing the HIG is a lot of manual work for application developers. This led to lots of verbose copypasted UI code, full of slight interpretation variations and errors, making applications hard to maintain and full of visual and behaviorial inconsistencies. The fact these guidelines are not set in stone and evolve every so often made these inconsistencies explode.
