4 ms·

I read this expecting to pooh-pooh on System76, but left thinking maybe they have a good case. At heart are some opinionated changes by the libadwaita team to

I read this expecting to pooh-pooh on System76, but left thinking maybe they have a good case. At heart are some opinionated changes by the libadwaita team to disable global styling, which align with an anti-theming petition that some of the team members support (stopthemingmy.app). These decisions wouldn't normally be particularly noteworthy, except that libadwaita seems posed to make its way into "core" GNOME software and would thusly affect System76 and their own efforts in customizing Pop_OS!. Some of the S76 staff responses are brash, but not without merit. I'm left with the impression that distros are not considered a "customer" by these GNOME contributors, so much as the app developers in their immediate circles that shoulder the brunt of support issues caused by the problems they hope to solve.

md8z 5y ago
The amount of misinformation on the net about theming in libadwaita is staggering. Global styling hasn't been disabled. There is nothing there that would really affect them in any significantly worse way than GTK3. That isn't to say they should do it, CSS theming will still be as broken and ill-advised as it is in GTK3, you can see that with the images at the bottom of the article. "which align with an anti-theming petition that some of the team members support (stopthemingmy.app)" To me this is a bad way to put it. I don't consider myself to be "anti-theming" and I agree with everything in that petition, except for the title which seems to be inflammatory and has contributed to some of the confusion and upset about theming in GTK. The title could be changed and the petition would be much better, I think. But it is probably too late for that.
- tomnipotent 5y ago
  > Global styling hasn't been disabled But that's the plan, while working on a recoloring API leading up to Gnome 42 when libadwaita can be adopted into core apps.
  - md8z 5y ago
    It's not the plan though. You can still inject global styles into libadwaita apps. It continues to be as bad an idea as it was before. I'm happy to provide details here.
    - tomnipotent 5y ago
      > You can still inject global styles into libadwaita apps So a GNOME user with the POP_OS! theme will see those styling elements when opening an app that's using libadwaita, without any special modification to the app or compile process?
      - md8z 5y ago
        I don't understand the question you are asking. Yes, if you configure GTK to load some CSS, it will do that. However that won't guarantee you see the correct styles, because CSS is technically not able to do that in all cases. If there are bugs in the the Pop_OS theme then it will continue to be broken, see the images at the bottom of the article... Edit: I kind of alluded to this before but I want to make it clear, if you are trying to make it so the user can safely load themes without "special modifications to the app or compile process", then CSS is probably the wrong choice. It is not suited to do that, CSS is only safe to use when modifying the app itself, or if you are shipping a theme as a build-time dependency in the form of a library (i.e. libadwaita). So that's kind of why your question doesn't really follow to me.
esarbe 5y ago
> I'm left with the impression that distros are not considered a "customer" by these GNOME contributors I think that impression is correct - System76 is not considered a customer but a co-developer.

md8z 5y ago

The amount of misinformation on the net about theming in libadwaita is staggering. Global styling hasn't been disabled. There is nothing there that would really affect them in any significantly worse way than GTK3. That isn't to say they should do it, CSS theming will still be as broken and ill-advised as it is in GTK3, you can see that with the images at the bottom of the article. "which align with an anti-theming petition that some of the team members support (stopthemingmy.app)" To me this is a bad way to put it. I don't consider myself to be "anti-theming" and I agree with everything in that petition, except for the title which seems to be inflammatory and has contributed to some of the confusion and upset about theming in GTK. The title could be changed and the petition would be much better, I think. But it is probably too late for that.

tomnipotent 5y ago
> Global styling hasn't been disabled But that's the plan, while working on a recoloring API leading up to Gnome 42 when libadwaita can be adopted into core apps.
- md8z 5y ago
  It's not the plan though. You can still inject global styles into libadwaita apps. It continues to be as bad an idea as it was before. I'm happy to provide details here.
  - tomnipotent 5y ago
    > You can still inject global styles into libadwaita apps So a GNOME user with the POP_OS! theme will see those styling elements when opening an app that's using libadwaita, without any special modification to the app or compile process?
    - md8z 5y ago
      I don't understand the question you are asking. Yes, if you configure GTK to load some CSS, it will do that. However that won't guarantee you see the correct styles, because CSS is technically not able to do that in all cases. If there are bugs in the the Pop_OS theme then it will continue to be broken, see the images at the bottom of the article... Edit: I kind of alluded to this before but I want to make it clear, if you are trying to make it so the user can safely load themes without "special modifications to the app or compile process", then CSS is probably the wrong choice. It is not suited to do that, CSS is only safe to use when modifying the app itself, or if you are shipping a theme as a build-time dependency in the form of a library (i.e. libadwaita). So that's kind of why your question doesn't really follow to me.

esarbe 5y ago

> I'm left with the impression that distros are not considered a "customer" by these GNOME contributors I think that impression is correct - System76 is not considered a customer but a co-developer.