Threads for greg_loscombe

    1. 2

      I’d be less against this decision, if adwaita wasn’t a horrific waste of desktop real estate.

      Unless GTK3/4 is focused on productive corporate environments, its going to be a half touch half desktop joke. There is countless studies showing more scrolling or less information presented in all sorts (like finance, programming, creative writing etc), leads to more mistakes.

      But yet, this is the default theme (gtk4) next to a custom one (Mojave-dark). Pointer (mouse precision) is increasing, why on earth would I need such a bloated UX.

    2. 5

      My main gripe with libadwaita is that it effectively hardcodes the theme. GNOME has officially discouraged theming (by distributions) for some years now, but that’s mainly because the existing theming system is both too powerful and too ad-hoc. In practice, as long as you don’t go crazy with it, GNOME theming works fine. The switch from libhandy to libadwaita changes that. There’s some talk about this being accompanied by a new theming API, but I have no idea if that will actually happen.

      1. 6

        I’m surprised people care about themeing so much - once you stop being a teenager with no skills and lots of time, it stops being interesting (because you have more rewarding pursuits) and you don’t have the time for it anymore.

        1. 10

          People love theming things. They paint their IKEA furniture, buy colourful phone cases, set backgrounds.

          If you make it possible, they’ll also theme software they use daily based on their own preferences. Just look at how many shell/terminal colorschemes exist.

          1. 5

            Saying that no one needs theming is effectively the same as saying that no one needs different clothes. Orange jumpsuits is the only clothes anyone will need—with ball and chain as a decoration. ;)

          2. 1

            Color scheme is one thing. Functionality is another. Oh, who thought scroll bars were a good idea? Oh, now they’re on the left? Oh, it’s proportional now. Oh wait! They’re on the right. Now they’re invisible unless you hover over the right edge. Now you have to hover over the left edge.

            1. 1

              Why is it okay if every app has its own scroll bar and button position, in different places, with different functionality?

              And why is it not okay if the user themes the apps so that every app has all its buttons in the same places, and the same scroll bars?

              1. 1

                What I’m commenting on is scroll bars exist on the left in version X of the UI. The next version they’ve been moved to the right. The version after that they’re invisible.

                Can a theme define where scroll bars appear? Or how they work? Can I get back the look and feel that I’m used to?

        2. 6

          I sort of get it. I really don’t care about theming on any platform except Linux, and in particular, except GTK applications.

          My external monitor is… mid-range, I guess, it’s not a particularly expensive one. But my eyesight isn’t what it used to be, and in my reasonably well-lit office, I can’t read the text in inactive windows unless I lean over my desk and squint. It doesn’t help that it dims everything, not just toolbar or menu items (the way macOS and Windows do) but the actual window content, too.

          The huge widgets are unpleasant but I think Linux users tolerated it better because we always had oversized widgets. Back in the day, GTK2 was sensibly bigger than Windows and Aqua. It’s even bigger now (you can fit two or three macOS buttons in a GTK3 button…). Frankly, it only bothers me on large screens. On small, high-res screens it’s tolerable.

          (Edit: FWIW, I am a little personally invested in this topic. I have pretty good eyesight, as in, I can read without glasses and all – but only in one eye. My bad eye is practically useless now, so I try to take good care of my one good eye, because I’m one stupid accident away from blindness. Not having to either squint or hack CSS themes after each GTK release is basically half the reason why I got a Mac, which was particularly disappointing for me because Gnome used to have pretty good reputation for accessibility.)

        3. 5

          once you stop being a teenager with no skills and lots of time, it stops being interesting

          I don’t much care for changing themes, myself, but I think you are being uncharitable here and confusing your own preferences with a universal rule.

          I do take advantage of themes to have one consistent theme between Emacs, my terminal, my screen locker, my browser, StumpWM and X11 applications. I use one theme on my work machine and another on my personal one, so I always know at a glance which machine I use.

          But I don’t fiddle with themes — as you note, there are more rewarding pursuits in the world for me. I don’t begrudge someone else who does, though. It’s a free world!

        4. 3

          It’s less about theming, and more about not being in a position where well-meaning designers can sabotage my user experience.

        5. 2

          I don’t care about theming as a user, I want the GUI provider to pick a good one. Theming is a backup mechanism for when the GUI provider has made bad choices. If I care about theming for your GUI, it means that your defaults are bad.

          I do care about theming as a developer because I want to integrate my look and feel with multiple host platforms. Not looking and behaving like native Windows / macOS apps has been a problem for a lot of open-source toolkits and means that I can’t adopt them in places where users expect a native experience.

          I do care about theming as a packager / integrator because I want to ensure that things all work well together. If some things use a menu bar at the top of the screen and others use one in-window, or if some things put scrollbars on the left and others on the right, that’s a bad user experience. Supporting theming makes it possible for me to provide a single theme for each toolkit that makes it behave in a specific way, so GTK, Qt, XUL, and so on apps all behave in a more-or-less consistent way.

      2. 5

        Also doesn’t help that adwaita is a touch centric anti real work padded mess.

        There has been countless studies showing that having to scroll a window to see more information, be it spreadsheet (accounts etc), code (the worst being having to scroll up and down a page), document writing, leads to productivity issues.

        But yet here we are, with libadwaita, effectively making lower screen resolutions (like 768p) completely unusable with 1/8 of your display taken up with huge padded titlebars and tabs. Absolutely awful. No one is going to take productivity on a linux desktop seriously with this oversized rubbish.

        And to make it worse, most input devices have got more accurate not less over the years. (high dpi mice vs old style).

        1. 6

          I find it funny people seem to find Adwaita so touch-driven when Gnome doesn’t work well on touchscreens and the designers explicitly say touch isn’t a priority.

          There has been countless studies showing that having to scroll a window to see more information, be it spreadsheet (accounts etc), code (the worst being having to scroll up and down a page), document writing, leads to productivity issues.

          Source? Last I used Gnome 3 on a 1024x768 screen (on an old ThinkPad X61) a couple of years ago, I didn’t have any problems. People get into hysteria over whitespace, but even older desktops had whitespace for the sake of making things easier to scan visually and provide better click targets. (i.e. a lot of apps by devs that complain about whitespace look even denser than say, Windows 2000 was, for the worse.) With a trackpoint, that helped a lot.

          1. 4

            The parent’s claim is a lot broader than serious HMI investigations can afford, and it’s also not something that has been investigated that much due to a combination of technical and historical reasons (tl;dr regardless of how efficient scrolling is, it was, for a long time, the only feasible way to present long information). That being said, just about every (narrower) result there is suggests that scrolling is associated with some cognitive impairment or loss of efficiency, or just isn’t preferred. For example:

   (specifically, about reading long texts)

   (specifically about navigating hierarchies, and it’s particularly interesting given that it’s literally 40 years old – the test installation used PDP-11s!)

   is possibly not as relevant but worth a read nonetheless.

            I don’t have my notes from back when I was working on a project where this was a relevant question, these are only the ones I could recall by title or author name. There were a bunch of other, less-cited papers that I’d read at the time (cca. 2015-ish).

            Methodology quality varies (as in, the closer you get to present day, the more “relaxed” things are, which I think says a thing or two about this, too…) but my understanding is that, in general, no scrolling is better than any amount of scrolling, and less scrolling is better than more.

          2. 2

            There is loads

            This one was measuring screensize, which is basically the inverse of screen estate (ie adding more inches == more space).

            People using the 24-inch screen completed the tasks 52% faster than people who used the 18-inch monitor People who used the two 20-inch monitors were 44% faster than those with the 18-inch ones.

            GTK theming wastes space. Fact.

            1. 2

              You cut off the last bullet point in the findings:

              Productivity dropped off again when people used a 26-inch screen.

              Which, besides being, frankly, a bit intellectually dishonest, also draws attention to an anti-pattern I see in online discussions: people arguing this way or that way when the real answer is some number

              I do think a lot of modern designs waste too much space, but if we suppose the reasoning that got here was as simple as:

              • Bigger buttons are easier to press…
              • Make buttons bigger!

              Then we should not really expect to get better results by dogmatically moving in the other direction; oversimplifying the results is not helpful.

              1. 1

                No the exact opposite, there is also issues with having to move eyes / head to track from edge to edge. Reduce the padding / still can see more.

        2. 3

          headerbars take less space than titlebar + menubar - they waste less space by using the empty area in titlebars

          1. 3

            I mean… maybe if every other widget was a little thinner, we wouldn’t need to reclaim space by reinventing titlebars and active/inactive state feedback along with them.

            Plus, FWIW, this obviously depends on the theme, but back when headerbars were introduced and I tried them, they were definitely bigger than a titlebar from an average theme + the menubar of a Qt application using QtCurve or the default Fusion style. Depending on widget fatness, they were maybe a few pixels thinner than a titlebar + a menubar + a toolbar. Headerbars made a world of difference on Gnome because the titlebar and the padding around menu items in the default theme were humongous but that’s not what everyone was coming from.

          2. 1

            I never said that headerbars aren’t good. I like CSD, and headerbars. I just hate the complete waste of space that GTK3/4 headerbars are.

    3. 1

      People don’t care that an application is a streamlined 3MB or a big round 200MB boy – they care that it works for them and it makes them feel good about using it.


      1. 3

        Neither is correct. The right answer is that some people care about the efficiency of the programs they use, and some people don’t. Additionally their reasons for caring or not caring, and which programs this decision applies to vary greatly.

        1. 1

          I care, hence the statement that ‘people don’t care’ is incorrect

          1. 1

            I think we’re in agreement on that point?

    4. 1


      But I’d not expect a bonus or the company to be flexible with you with regards to things like working from home or days when you need childcare cover.

      1. 3

        I’ve done this at jobs where I’ve explicitly negotiated shorter workweeks. So definitely possible.

        In general I think it goes the other way around: if you set boundaries you are (usually) better respected. And you end up becoming more productive, too:

        1. 1

          Didn’t say you can’t set boundaries, saying if you aren’t going to be flexible with the company, I’d expect them not to be flexible with you.

    5. 4

      Is there a reason to consider this instead of something like 1Password or Bitwarden? I read the FAQ and it seems like it is the same except tied to Firefox.

      1. 6

        Dunno about their offerings, but what I personally like, about lockbox is that it’s got super friendly ux (caters for simplicity of use rather than us nerds :-)). I already use Firefox Sync on all my devices but the Android autofill API allows using it for apps too.

        Lockbox is also free of charge, free software and encrypts data on the client, not in the cloud.

        1. 4

          If I follow correctly, you are saying its encrypted at the client and then sync’d to the cloud. Correct?

          1. 4


      2. 0

        1Password or Bitwarden

        Those are proprietary, and I would assume the Lockbox thing isn’t?

        1Password is proprietary, bitwarden isn’t. oops.

        1. 10

          Bitwarden is open source:

        2. 1

          […] Bitwarden

          Those are proprietary, […]


          1. 2

            Well, ok, one of them is then.

            1. 2

              Have to say, my experience of Bitwarden has been nothing but positive. Much prefer to alternatives like lastpass