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

  • #11
    Originally posted by Danny3 View Post
    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..
    You do realise that it was via the development of libadwaita that a global dark style API was developed? It is being implemented in gnome, elementary and patches exist for KDE (not sure if they have been merged yet - how to decide if a theme is light or dark was an active question at the time)?

    As for integrations in other systems, KDE apps fit into gnome because of work done by gnome (well, in this case Red Hat) centric people - they developed qgnomeplatform to allow qt to fit in. I dont know if anything like that has been developed for the other way around.

    As for recolouring, it will arrive. The people linking to older rejected merge requests and issues are spreading FUD because they are linking to something else - replacement of styles instead of additions.

    Why does this distinction matter? Libadwaita is not just a theme - it adds widgets, which are styled by the stylesheet. If you allow replacement of the stylesheet, the replacement stylesheet may have been made without taking a particular widget into account (maybe because it was implemented later?). This would break apps.

    So what can be done? Something like the recoloring API mentioned in the blog post or as done by gnome-text-editor. So far no one who has looked at the details as stepped up with an alternative. Even the Ubuntu theming folks when discussing it are happy with what it will provide.

    The only developers hating on it so far from what I know are the ones that would not include libhandy in their distribution because "they were a desktop OS" and another who thought the pre-alpha state without the dark style was the stable release.

    Comment


    • #12
      Originally posted by ssokolow View Post
      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.)
      Are you aware of any repository where they are doing this exploratory work? I really want them to do this and see how it goes, but chances are it will go the same way as their previous announcement of moving to Qt - a lot of hot air and no action.

      Comment


      • #13
        Originally posted by tildearrow 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)
        Honestly, I prefer that everything except games obey my chosen theme. That's one of the reasons I've been retiring the GTK components from my mixed-toolkit desktop and leaning into KDE over the last few years. (Something I began when some applications started obeying aspects of the GNOME HIG not shared with KDE's conventions.)

        Comment


        • #14
          Originally posted by tildearrow 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)
          The other problem is that that page is not against user theming. It is against broken distro theming. Do distros occasionally break themes? Yes, as shown by screenshots a few months ago of Pop_OS!. It was very eye opening because they are normally pushed as a very solid distro.

          (I don't use them but I am looking forward to see their gnome-shell alternative plugin to mutter written in rust.)

          Comment


          • #15
            Originally posted by You- View Post

            Are you aware of any repository where they are doing this exploratory work? I really want them to do this and see how it goes, but chances are it will go the same way as their previous announcement of moving to Qt - a lot of hot air and no action.
            I'm a happy KDE user, so I haven't been following what Solus does. I mainly know of that post because I'm also a Rust developer and it was noteworthy for it to list Rust compatibility so high in their decision-making.

            Comment


            • #16
              Originally posted by You- View Post
              The other problem is that that page is not against user theming. It is against broken distro theming. Do distros occasionally break themes? Yes, as shown by screenshots a few months ago of Pop_OS!. It was very eye opening because they are normally pushed as a very solid distro.
              That's fair... except that, for the longest time, the best GTK theme I could find was literally named "Lubuntu".

              I'm getting shades of the “We developers should be elite gatekeepers over everyone who doesn’t know how to compile software from source” from Drew Devault's Developers: Let distros do their job but for theming.

              (His argument effectively boils down to "Don't make binary releases. Let distros do that. Don't ask distros to package your stuff. Let user demand do that. Oh, you're developing something aimed at users that don't know how to compile your software so they can realize they want to demand pre-made packages? Well, you're SOL unless someone who can compile takes pity on them. Oh, you're a user who can't compile things and wants a program too young to have a distro package? Learn to compile or GTFO.")

              I don't want to go back to the bad old days of theming when it was effectively "cobble together your own solution or GTFO." It's bad enough that QGnomePlatform for GTK 3.x is greatly inferior to QGtkStyle for GTK+ 2.x at deduplicating effort to get the two toolkits looking the same.
              Last edited by ssokolow; 31 December 2021, 04:45 PM.

              Comment


              • #17
                Originally posted by You- View Post

                The other problem is that that page is not against user theming. It is against broken distro theming.
                You can assert that this is their goal all day, but the DTMA people are frequently cited to legitimize GNOMEs decision to remove user theming for apps. Wether or not this was their intention, they are complicit in the removal of themeability in libadwaita. Many of them appear to be very happy about this (especially those in close proximity to GNOME), but I can't assume they all are. Either way, I don't feel too inspired to contribute to any of their apps, and the behaviour around GNOME makes me unlikely to make any contributions either. System76 has been very kind to me as I cut my teeth working on open source projects, for what it's worth ;p.

                Comment


                • #18
                  Originally posted by ssokolow View Post
                  I'm getting shades of the “We developers should be elite gatekeepers over everyone who doesn’t know how to compile software from source” from Drew Devault's Developers: Let distros do their job but for theming.
                  There are still going to be ways for users to override the Adwaita theme at run time—you can set the GTK_THEME environment variable or edit ~/.config/gtk-4.0/gtk.css. However, it'll be explicitly unsupported and application developers will probably close bug reports of visual glitches when you override the theme this way.

                  In the past, developers had to deal with bugs caused by distro and popular user themes, which made it harder for them to implement custom widgets. They could not declare support for a finite set of themes as many distros chose a theme for their users and users could use GNOME Tweaks to set a custom theme. Libadwaita will provide developers a stable set of themes to build their applications on.

                  Comment


                  • #19
                    I'd rather app devs be better at making adaptive UIs that look good no matter the font size/format, padding, border thickness, etc, but that's understandably very hard to get 100% right...

                    I did hope that using libhandy-based designs would help achieve more adaptability more easily instead of making it worse, because AFAIK (not a dev here, just an avid reader) the app leaves a lot of the adaptive layouting in the hands of this lib, just requesting "a menu of this kind with items x, y, z" and such higher abstraction components, but obviously this is a very limited not-hands-on perspective so I'm curious to hear more about the real implications

                    the quote looks like a surprisingly hostile stance from GNOME to distros... at the very least I'd design for accent color customization + distro logo right from the initial release, and probably even a few other bits that I can't think of now!

                    edit: also maybe an option for the app to use classic title and menu bars to better integrate to XFCE, Mate and other classic-looking DEs/distros too... though honestly on Linux Mint the GNOME apps with buttons and whatnot on the top (gnome-calculator, gnome-disks, etc) still do look well integrated on Cinnamon

                    Comment


                    • #20
                      wrong name

                      it should be called "libTabletUX", it is designed for tablets

                      Comment

                      Working...
                      X