Open medmedin2014 opened 1 year ago
Foliate has always been a GNOME app from the start, though it did go out of its way to make it work better on other desktops, by e.g. having a menubar, which is gone from the current version, among other things that did not make it.
In the future, it might be better to build separate versions of Foliate using different toolkits. That will probably be more maintainable than what Foliate did in GTK 3. I'm already moving more and more features into foliate-js
(the e-book renderer used by Foliate), which will make this easier. At some point I will definitely release a PWA and/or Electron version, which will at least be cross-platform and give you system titlebars, which isn't much but it'd be better than nothing.
But I gather that the main subject of this issue is merely the inability to theme it. In that case this should be marked as not our bug because it's something that can only be fixed in Libadwaita or KDE, not in Foliate.
@johnfactotum Well, Foliate is used on many non GNOME desktops, and GNOME is not the standard of Linux desktop as it's dying. And the fact you choose to use a library specific to one desktop makes this bug yours, because LibAdwaita made it clear from the start that theming their apps is impossible, and KDE has no responsibility to fix the mess made by your choice or GNOME.
We love if 2.6 is kept as separate branch and receive future updates so we can use this useful app on non GNOME desktops. As for Electron, I'm not fun of it at all.
Was it not possible to migrate to GTK4 using only pure GTK4 widgets much more better? As theming pure GTK4 is by default supported on any major desktop.
And the fact you choose to use a library specific to one desktop makes this bug yours, because LibAdwaita made it clear from the start that theming their apps is impossible,
To clarify, I meant that the issue "the app isn't themable" is a libadwaita bug. Actually it's not even really a bug, as libadwaita apps are already themable,[^1] just that KDE doesn't theme it.
If your issue is "don't use libadwaita" or "make Foliate follow KDE HIG" then that's not a bug, but rather an enhancement that I addressed in my comment above.
Was it not possible to migrate to GTK4 using only pure GTK4 widgets much more better?
To migrate? Not really. Because Foliate supported GNOME in GTK 3, and to support GNOME in GTK 4 you have to use libadwaita.
Building a new version not designed for GNOME? Yes. Though it might be better to use other toolkits such as QT rather than GTK 4.
[^1]: See for example the following screenshot from #1118 showing Foliate running with a theme:
@johnfactotum
To clarify, I meant that the issue "the app isn't themable" is a libadwaita bug. Actually it's not even really a bug, as libadwaita apps are already themable,1 just that KDE doesn't theme it.
That's not an official theming but temporary one released by a third party, after modifying those hidden CSS files, and LibAdwaita will surely break it in future releases, because LibAdwaita officially only supports accent colors.
What is needed from GNOME is to release a standard API where it specifies colors and properties, so that any theme created by any major desktop while respecting modification via that API, will be always compatible with future releases.
To migrate? Not really. Because Foliate supported GNOME in GTK 3, and to support GNOME in GTK 4 you have to use libadwaita.
You are wrong, LibAdwaita is not a part of GTK4 library and will never be merged with it, it's a special library created by GNOME devs on top of GTK4 widgets to create their GNOME apps. And you can clearly create a GTK4 app without using that foreign library. And by using it, you lock your app inside GNOME ecosystem.
That's not an official theming but temporary one released by a third party, after modifying those hidden CSS files
That's exactly how it has always worked since GTK 3. There never was any real theming API. The default theme in GTK 3 did not stabilize for a long time after the initial release and even after GNOME 3.20, I think, around which point it became mostly stable, they continued to tweak it in many breaking ways.
I mean, even if you think it was official, that just proves that whether something is "official" or not means nothing: it's just as much a "temporary" solution that is now broken in GTK 4.
And you can clearly create a GTK4 app without using that foreign library.
Yes, you can create GTK 4 apps with only GTK. But you can't create GNOME apps with only GTK 4, which is what I said.
And by using it, you lock your app inside GNOME ecosystem.
And by not using it, you lock the app outside GNOME, which I'm not going to do, as Foliate has, as stated above, always been a GNOME app.
You can, of course, make it optionally use libadwaita. This is implied in my first comment when I mentioned how Foliate used to have special behavior designed to work better outside GNOME, but as I said, I now believe this can be better addressed by building separate versions of Foliate (which, if it makes you feel better, just think of it as compile-time configurations) based on a core, shared library, rather than having different UI code paths at run time.
That's not an official theming but temporary one released by a third party, after modifying those hidden CSS files, and LibAdwaita will surely break it in future releases, because LibAdwaita officially only supports accent colors.
@medmedin2014 No, I was just using a GTK theme that supports libadwaita (McMojave GTK theme). I did not do anything with the CSS files.
I use Foliate with KDE, and it integrates very well if I use a theme that supports both Libadwaita and GTK4 (and KDE), like the Arc theme.
I am using the native version of Foliate, if you use Flatpak, then you will have to enable flatpak apps to use the system theme, by copying the theme files to $HOME/.themes
We love if 2.6 is kept as separate branch and receive future updates so we can use this useful app on non GNOME desktops.
The Foliate 2.6 will remain separately available in the Foliate PPA (in the foliate2-gtk3
package) as long as GTK3 is supported in Ubuntu (in other words, as long as GIMP does not stop depending on GTK3 :smile: ), and it is also available on AUR.
I am hopeful that within a few years there will be excellent compatibility between libadwaita and KDE, like it used to be for GTK3.
In XFCE/MATE etc, the libadwaita apps can also be themed with an environment variable (which can be made permanent by placing a modified version of the desktop file in $HOME/.local/share/applications
for each libadwaita app), e.g.
GTK_THEME=Arc foliate
Perhaps, within a few years, they will support libadwaita apps as well.
@johnfactotum I would urge you to put your resources on maintaining and adding book-reading-features to the main Foliate GTK version as it is now, instead of maintaining too many toolkits (which will make you deal with too many bug reports of all kinds), and I am also against a one-electron-app-works-for-all approach, because then it would be very resource hungry compared to what Foliate is now. But that is just my opinion. Please feel free to go ahead with Foliate development as you like.
I will be making a PWA version, which will fix #115 and #336, and it will be maintained alongside the GTK version.
Once there's a version using only Web technologies, it will be easy to create hybrid apps around it, if that is what one wants (otherwise, one can just use the app in the browser). It could range from simple wrappers using something like Electron, to ones that re-implement the UI in different native toolkits, e.g. the current GTK version.
So one way to think of this is that it's not so much "building separate apps from scratch" but more of a continuation of "moving things into the WebView", which has many advantages in itself apart from making the code reusable on other platforms.
No, I was just using a GTK theme that supports libadwaita (McMojave GTK theme). I did not do anything with the CSS files.
Who publishes that called McMojave theme ? Can they ensure fast and continuous support for Qt and GTK updates ? The answer is no, only official KDE Breeze theme is able to adapt fast to Qt and pure GTK new features, especially on rolling releases distros like Arch, Manjaro, Tumbleweed... so using an amateur theme as temporary solution will never work, unless it's maintained and officially supported by KDE Plasma.
And KDE will never release a temporary solution for LibAdwaita unless it's fixed by GNOME, because ounce they attempt any temporary solution they will have to play mouse and cat with GNOME devs who reinforce locking their library with each release, they are even thinking of removing that broken GTK_THEME env var to force users to use that ugly embedded Adwaita theme.
The Foliate 2.6 will remain separately available in the Foliate PPA (in the
foliate2-gtk3
package) as long as GTK3 is supported in Ubuntu (in other words, as long as GIMP does not stop depending on GTK3 😄 ), and it is also available on AUR.
The same situation happened for Manjaro Pamac manager, when they released their LibAdwaita version of Pamac, they got bad feedback from various flavors especially KDE, XFCE and Cinnamon, because it was not sane to use a locked library to develop Pamac while Manjaro supports many desktop managers, and finally they were forced to split the app to two branches: GTK3 for KDE, XFCE and Cinnamon and LibAdwaita for GNOME.
I will be making a PWA version, which will fix #115 and #336, and it will be maintained alongside the GTK version.
Why not simply using pure GTK4 widgets ? Like how Inkscape is currently migrating from GTK3 to GTK4. I think LibAdwaita provides nothing exceptional to the table except those shiny dialogs and GNOME integration.
Who publishes that called McMojave theme ? Can they ensure fast and continuous support for Qt and GTK updates ?
Yes, the author has been maintaining these themes for years. https://github.com/vinceliuice?tab=repositories And often, third party theme developers are faster at supporting new features than the Breeze theme developers.
I think LibAdwaita provides nothing exceptional to the table except those shiny dialogs and GNOME integration.
I am not the developer of this application, but as far as I know, libadwaita provides good support for touch screen gestures, which pure GTK4 does not. And GNU/linux on affordable touch screen convertibles is a thing now.
Please don't turn this into a GTK4 vs libadwaita vs KDE war.
third party theme developers are faster at supporting new features than the Breeze theme developers.
That theme is quite outdated, I think you never used a rolling release distro.
I am not the developer of this application, but as far as I know, libadwaita provides good support for touch screen gestures, which pure GTK4 does not. And GNU/linux on affordable touch screen convertibles is a thing now.
LibAdwaita is just a library containing widgets components built on top of pure GTK4 widgets, they add nothing new, except theming and customizations and forcing what is so-called GNOME HIG. And gestures features are coming from the pure GTK library and not LibAdwaita.
There are too many things to respond to here. I will just focus on recapping what I've explained above.
Why not simply using pure GTK4 widgets ? [...] I think LibAdwaita provides nothing exceptional to the table except [...] GNOME integration.
You answered it yourself. Libadwaita is required for GNOME integration.
To clarity, as I have already explained, there are two logical possibilities if you want to be able to not use libadwaita:
Now, option 1 seems to be what you want. While it has some advantages, there is unfortunately one slight drawback: it would mean that Foliate would no longer work well on GNOME, which I would like to avoid because, as I said, Foliate has always been designed for GNOME. It used GNOME's platform libraries, and followed GNOME's HIG. By using libadwaita, it is simply continuing to support GNOME as it has always done.
So let us consider option 2. Again, as explained above, there are two ways to do this: A. Make libadwaita an optional dependency, and the app will decide which widgets to use at run time. B. Build a separate UI, possibly though not necessarily with another toolkit.
Now, there are pros and cons with both approaches. Previously, in v2.x, Foliate adopted option A, but from my experience, I feel that this might actually make the code harder to maintain, which is why I have suggested to go with something more akin to option B.
In reality, though, option A and B here are not really mutually exclusive; both imply generally refactoring and cleaning up the code, and both would require significant effort.
Foliate has always been designed for GNOME
Well, Linux is way bigger than GNOME, and GNOME is known only because Canonical was and is still advertising it as default on Ubuntu, but for other platforms like Archlinux it's already dying.
It's your app, and you have total right to lock your app to GNOME ecosystem.
It's your app, and you have total right to lock your app to GNOME ecosystem.
Not at all. In fact, as I have already explained multiple times in my comments above, I'm planning on supporting other operating systems, not just Linux. It's just that I won't be doing that using GTK.
I must say... you sure do love GTK a lot for someone that doesn't use GNOME. I mean, GTK isn't exactly people's top choice when it comes to building cross-platform apps today. And this is especially the case for Foliate when one of its core components, WebKitGTK, is not even available on Windows at all.
I mean, I don't even like GTK that much. That's honestly another reason why I want to try creating a version of Foliate without it.
Of course, you could argue that if it uses a different codebase, a different toolkit, etc., then it's not the same app anymore. Without getting too deep into the ontology of apps, I would say, with another "as I have already explained above", "if it makes you feel better, just think of it as compile-time configurations".
Quoting myself,
it's not the same app anymore.
I'd also like to add that there's nothing wrong with using different apps on different platforms, either.
There are already people building their own e-book apps by re-using some of Foliate's old code. See Arianna and Alexandria. And I believe Koodo Reader's development version is using foliate-js as well.
To me that is yet another reason why focusing on improving foliate-js first would be a good idea. Not only would it benefit Foliate, it could enable people to build e-book apps more easily with any toolkit on any platform.
I would rather have a GNOME/Libadwaita app than a Linux app... if that dichotomy made any sense. But it doesn't— there's no expectation for an app to support theming in order to be a "Linux app," and Foliate isn't any less of a "Linux app" because it doesn't look like a certain group of Linux apps. Libadwaita is, in my opinion, far superior to some other option in terms of appearance and usability
LibAdwaita is a GNOME library meant to be used to only develop GNOME apps, and it's impossible to change its look on non GNOME desktops like KDE, XFCE... because GNOME has locked their library and refuses to provide any public API to change it, and any amateur theme that temporary fixes it will be surely broken in future releases.
That's why KDE devs refused to touch any theming modification related to LibAdwaita until GNOME fixes their attitude. Currently, GNOME added official support to apply only a kind of gradient color.
So are you assuming that Foliate is becoming a GNOME app ? And not anymore a general Linux app ?
The old one looked consistent with the rest of apps
While the new one looks alien and refuses to use the system theme, it uses that embedded ugly Adwaita theme with inconsistent titlebar.