Announcement

Collapse
No announcement yet.

Libadwaita 1.0 Released For Kicking Off A New Year Of GNOME App Development

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Libadwaita 1.0 Released For Kicking Off A New Year Of GNOME App Development

    Phoronix: Libadwaita 1.0 Released For Kicking Off A New Year Of GNOME App Development

    GNOME's libadwaita 1.0 has been released for this library implementing the GNOME Human Interface Guidelines (HIG) and complementary to the GTK toolkit...

    https://www.phoronix.com/scan.php?pa...libadwaita-1.0

  • #2
    While I know it's just a name (and has little to do with the theme), the name feels like they want to force one theme on its users...

    Comment


    • #3
      Originally posted by tildearrow View Post
      the name feels like they want to force one theme on its users...
      They're going to, in the future.

      Comment


      • #4
        Does it acknowledge that there other desktop environments ?
        Does it acknowledge that some of them are not even based on Gnome ?
        Does it acknowledge that some users want to have other window decorations or window control buttons (minimize, maximize, close) ?
        Does it acknowledge that some users don't want to have everything in the title bar ?

        As a KDE Plasma user, which really tries to integrate GTK programs as much as possible, I hate that GTK programs follow some design rules only for Gnome and look like shit on KDE Plasma disrespecting the dark theme preference, direspecting the window control buttons preference, etc.

        At least these programs should offer a toggle button like Chromium to change back to system's theme.

        Comment


        • #5
          Originally posted by tildearrow View Post
          While I know it's just a name (and has little to do with the theme), the name feels like they want to force one theme on its users...
          That's the idea. Libadwaita is going to be for app developers who buy into the idea that user customization via themes should stop at the Adwaita recoloring API.

          That's why there's a closed bug named `adw_init` shouldn't forcibly change back the stylesheet to Adwaita if another is set that is not Default.

          Comment


          • #6
            what stops a distro from replacing upstream libadwaita with their tweaked fork or patched version?

            is that actually going to make it harder for distros to customize, or just break prior efforts and require them to redo their customizations in a new but sane way?

            does it implement distro branding in any way already?

            ps:
            I'm glad to know this is actually the successor to libhandy... this little lib was created with the help of Purism and is behind quite a few tricks used by them to enable true convergent apps on true linux smartphones.

            I hate apps that implement phone/tablet layouts in desktops (lots of wasted space with excess padding, large fonts and large buttons, too-deeply-hidden or removed functionality, etc), but they seem to have achieved the impossible by making reasonably desktop-oriented designs reflow automatically when squeezed into a phone form factor.

            Comment


            • #7
              I think that standarized theme is what Linux desktop needs. Unfortunately the only problem for me is that there is no compact theme and there is a lot of space wasted by default GTK themes.

              For instance I like to use Eclipse, unfortunately on Linux it is unusable with default theme and I can't find theme which makes it look good. I would like to have a theme created by developers which is compact and I would love to use it instad of trying to make good look myself.
              It is very sad that Eclipse on Windows looks much better and is more usable than on Linux. I hope that this will get sorted one day...

              Comment


              • #8
                Easyeffects uses libadwaita:

                easyeffects.png

                Comment


                • #9
                  Originally posted by ssokolow View Post
                  Problem is:

                  - there are apps in where "stop theming my app" makes sense (e.g. Serato DJ, Ardour, Photoshop, most gaming software, etc.)
                  - there are apps in where theming should be allowed and the developer must be aware of it (e.g. most apps part of a DE)

                  Comment


                  • #10
                    Originally posted by marlock View Post
                    what stops a distro from replacing upstream libadwaita with their tweaked fork or patched version?

                    is that actually going to make it harder for distros to customize, or just break prior efforts and require them to redo their customizations in a new but sane way?

                    does it implement distro branding in any way already?
                    The first page I linked is a message basically saying "Please don't implement distro branding beyond things like default desktop background. We don't want it."

                    It's certainly possible for distros to patch libadwaita, but that'd just worsen the problem of applications looking terrible because their developers didn't bother to test their UI design on multiple themes that libadwaita is a response to, because app developers will be making even more assumptions about the predictability of how their applications will render.

                    Solus is investigating making a GNOME-less version of Budgie as a result. (Specifically, they're investigating using EFL because they don't want to work in C++ and Qt's Rust support is not great to put it mildly... I say that as a KDE user who's migrating to writing non-trivial programs using PyQt for the frontend and rust-cpython for the interface to the backend.)

                    Comment

                    Working...
                    X