[HN Gopher] Libadwaita: Splitting GTK and Design Language
___________________________________________________________________
Libadwaita: Splitting GTK and Design Language
Author : butz
Score : 97 points
Date : 2024-06-03 17:59 UTC (5 hours ago)
(HTM) web link (tesk.page)
(TXT) w3m dump (tesk.page)
| whalesalad wrote:
| adwaita is the quintessential example of how the hardest
| programming concepts are naming things and cache invalidation.
| mseepgood wrote:
| So is it a new kind of libgnomeui?
| https://wiki.gnome.org/Attic/LibgnomeMustDie#libgnomeui
| c0l0 wrote:
| Ouch, there's some bitter irony in all of this. See
| https://wiki.gnome.org/Attic/ProjectRidley for an explanation
| of the goals of this project, which now seems to be what GTK is
| trying to get away from again.
| cardanome wrote:
| Not really?
|
| > As Owen said in a recent GTK+ meeting, when looking over
| the list of APIs that we are discussing here, there are
| basically three categories:
|
| > A) Cross-platform API - things that make sense on Windows /
| OS X
|
| > B) X / freedesktop.org-specific API
|
| > C) GNOME-specific API
|
| > APIs in category A. are clearly suitable for moving to
| GTK+, APIs in category B. may or may not be suitable, and
| things in category C. are better off in a GNOME-specific
| library.
|
| So even back then the official stance was that GNOME specific
| stuff belongs in external libs.
| spookie wrote:
| Agreed, its a understandable that they're choosing this path.
|
| FOSS needs to stop having such quasi-religious positions like the
| ones mentioned at the start of the article, where very
| understandable decisions are taken as dabs against other
| projects.
| LocutusOfBorges wrote:
| This seems to quite deliberately miss the point of why so many
| find the effect libadwaita has had on the desktop experience to
| be so frustrating.
|
| Really, it doesn't matter whether the underlying motivations were
| supposedly to create a cleaner separation between projects at the
| abstract level - the consequences have been to introduce a
| situation where, for the first time in quite a long period, large
| swathes of significant, widely-used programs are no longer
| capable of fitting in on non-GNOME desktops.
|
| That decision was theirs to make, and they were entirely free to
| do so - but squirming around the point to avoid talking about
| responsibility for the actual consequences of the decision re
| further fracturing the Linux desktop ecosystem is absurd.
| NekkoDroid wrote:
| > the consequences have been to introduce a situation where,
| for the first time in quite a long period, large swathes of
| significant, widely-used programs are no longer capable of
| fitting in on non-GNOME desktops.
|
| I still am looking for this magical theme that makes QT apps
| feel like it fits on a GNOME desktop. Like, not matter how much
| you theme, the UX is going to be different and that can't
| really be changed without rewriting the entire app in a
| different toolkit with the target UX in mind.
|
| GNOME and KDE UX are completely different. One gives you the
| bare necessaties of options mostly behind a hamburger menu and
| a nice amount of padding, while the other throws every option
| and the kitchen sink at you with a relativly high dencity of
| content. They target different people, which is fine as no size
| fits all.
| simion314 wrote:
| >I still am looking for this magical theme that makes QT apps
| feel like it fits on a GNOME desktop.
|
| Qt does the work to integrate with Windows and OSX, by this I
| do not mean that it paints the exact shame of border colors
| on the buttons but more deeper integration, like integrating
| with the native System Tray, desktop APIs, the correct order
| of OK/Cancel buttons.
|
| For linux the Qt devs are aware that each distribution has
| it's own colors,, fonts and crap so it would be a waste to
| target only a distro say Red Hat.
|
| KDE did the work to make GTK apps integrate as much as
| possible but I think GNOME did zero work to integrate Qt or
| KDE apps and they tried sabotaging everyone else by removing
| the Tray or the server decoration.
|
| I am not that type of user that needs all apps to have the
| exact same buttons otherwise my brain segfaults, I use KDE
| apps, GTK apps, Java apps, Electron apps. What I want from
| this apps is to use same Open File Dialogs and not be like
| GTK where the native GTK file picker has a weird sorting
| option for files and folders that do not match any other
| popular and sane system.
|
| Also I remember GNOME guys claiming that you do not need
| thumbnails in the File Picker, that you are doing it wrong
| and the reality was that it was not easy to add the feature
| so they preferred to push that excuse that you are doing it
| wrong.
| NekkoDroid wrote:
| > KDE did the work to make GTK apps integrate as much as
| possible but I think GNOME did zero work to integrate Qt or
| KDE apps and they tried sabotaging everyone else by
| removing the Tray or the server decoration.
|
| Sure it's nice I guess if they have their own theme for GTK
| apps, but if their own QT Kirigami apps look like this[1]
| on other desktop they should probably focus more on that
| than on apps not made with their UI framework.
|
| > What I want from this apps is to use same Open File
| Dialogs
|
| From what I remember it uses the xdg-portal for opening the
| file dialog, so either this has been fixed a while ago or
| the portal was misconfigured to use the GTK dialog (on the
| DE side).
|
| > Also I remember GNOME guys claiming that you do not need
| thumbnails in the File Picker, that you are doing it wrong
| and the reality was that it was not easy to add the feature
| so they preferred to push that excuse that you are doing it
| wrong.
|
| All I remember is that there were multiple times over the
| years when patches were sent and when changes were
| requested each time the submitter just vanished but I might
| be misremembering.
|
| [1] https://imgur.com/a/dolphin-on-PUvU0ze
| josefx wrote:
| > All I remember is that their were multiple times over
| the years when patches were sent and when changes were
| requested each time the submitter just vanished but I
| might be misremembering.
|
| The original bug report contained multiple comments
| pointing out that a file chooser is not a full blown file
| browser and that it either should not display or cause
| the creation of new thumbnails.
|
| > and when changes were requested each time the submitter
| just vanished but I might be misremembering.
|
| Like the guy who stopped responding after only a year of
| complete radio silence from the GNOME devs?
|
| https://bugzilla.gnome.org/show_bug.cgi?id=141154&
| jeroenhd wrote:
| Qt on Windows looks pretty out of place. Qt copied Windows
| Vista pretty accurately, but I haven't seen any fluent
| design yet. The Vista style also looks a little off now
| that Microsoft has tweaked the native controls in Windows
| 11.
|
| KDE applications look out of place in Gnome. Some Gnome
| distros pack GTK-like themes for Qt applications, but
| Dolphin looks like ass on Gnome. Depending on your
| theme/night mode settings, it's also broken (black labels
| on dark grey backgrounds broken). Gnome apps may look out
| of place elsewhere, but at least they're functional.
|
| I, too, can't deal with different behaviour, but KDE is no
| better than Gnome when it comes to integration. The core
| application UI design approaches differ, so I doubt good UI
| integration can even be done; cross platform applications
| would need complete UI overhauls for every platform they
| target, ruining the whole point of cross platform UI
| toolkits.
|
| Thankfully, Linux applications using XDG portals will
| invoke native controls for features like file pickers,
| limiting the damage both ways. I expect something similar
| to happen on macOS and Windows.
| guerrilla wrote:
| Yeah, but now there are three, not just two. GTK, GNOME and
| Qt, rather than just Qt and GTK.
| NekkoDroid wrote:
| By that logic you also forgot iced, libcosmic, libxfceui4,
| kirigami, xapps, flutter, .NET Avalonia, electron/html,
| sdl/raw rendering, and probably alot more that I don't know
| or can think of. This really has been just GTK and QT for
| ages.
| anthk wrote:
| GTK was not always tied to Gnome. It was born with Gimp;
| and XFCE was remade into GTK making it faster than Gnome
| itself.
| shrimp_emoji wrote:
| Gimp Tool Kit!
|
| I wonder when Gimp will upgrade to GTK 4, and realize
| GNOME has twisted the GTK framework into a draconian
| railway to making a mobile app with rounded corners, and
| give up and switch to Qt like so many other apps have.
| tristan957 wrote:
| Inkscape was ported to GTK 4, and LibreOffice is in the
| works. Please read the article before commenting.
| Cu3PO42 wrote:
| It is relatively easy to patch libadwaita to apply non-Adwaita
| themes. On the AUR, there's libadwaita-without-adwaita. I have
| applied the same patch on NixOS. It works just about as well as
| theming does in standard Gtk3 or 4. No complaints really.
| red_admiral wrote:
| I know, but that still leaves a sour taste in the mouth.
|
| On Windows, the first thing I do after setting up a new PC is
| disable the adware, uninstall default apps, turn off as much
| telemetry as I can, and very soon that'll include turning off
| the creepy AI too. They say I should use linux instead ...
|
| And on a standard gnome/GTK/adwaita setup, apparently the
| first thing you have to do is patch the UI library to remove
| the hardcoded default theme. The free software world wasn't
| meant to be like this, where you have to fight the OS/distro
| to get things to work the way you want.
|
| (Meanwhile Mint, as the original article alluded to, is still
| trying to do good by its users. Long may this continue.)
| okanat wrote:
| > The free software world wasn't meant to be like this,
| where you have to fight the OS/distro to get things to work
| the way you want.
|
| I think the actual history says something different. The
| free software world is created by people who think the
| source code is the ultimate end, however basic it is.
| Actually combined with the common Unix convention of
| implementing the most basic and barebones piece of software
| to maximize text based interaction, I think it is
| fundamentally against democratizing computers for regular
| people.
|
| It doesn't have to be this way but many founders thought
| and still think that barely useful but libre software is
| better.
| jrm4 wrote:
| I find the attempt to define "design language" amusing -- feels
| like if you have to devote that many words to what you're
| trying to do with _design_ you 've already failed hard.
| tristan957 wrote:
| Every successful OS or application has a design language. All
| Microsoft Office applications look similar because they all
| use the same design language. Why do you diminish what you
| don't understand?
| 42lux wrote:
| I hope cosmic puts an end to this neverending discussions about
| bad decisions from the gnome foundation. They can go under for
| all I care. Overall I truly believe they did a disservice to the
| whole Linux Desktop and the community over the last 15 years.
| pid-1 wrote:
| What's cosmic?
| ianlevesque wrote:
| Yet another desktop environment https://github.com/pop-
| os/cosmic
| thesuperbigfrog wrote:
| A desktop environment that System 76 is making:
| https://blog.system76.com/post/cosmic-the-road-to-alpha
| 9dev wrote:
| Looks like yet another uncanny clone of MacOS UI
| erikpukinskis wrote:
| What disservice?
| cl3misch wrote:
| Isn't Cosmic based on Gnome? If yes, at least they did a
| service to enable the Cosmic DE.
| davet91 wrote:
| The new Cosmic is written from scratch in Rust with the iced
| GUI library.
| supercheetah wrote:
| They take some aesthetic inspiration from Gnome, but Cosmic
| inherits none of its code since it's being written in Rust.
| w4rh4wk5 wrote:
| Completely agree.
|
| The fact that there are still apps where the hamburger menu
| cannot be used properly without a mouse caused me to switch to
| KDE. Having certain menus accessible via Alt + Letter shortcuts
| is an accessibility requirement for me.
| pantalaimon wrote:
| The article sounds more like Gnome has learned from their
| mistakes and makes Gtk4 more general purpose with the Gnome
| specific bits contained in libadwaita
| 42lux wrote:
| Looks rather like rhyme...
| https://wiki.gnome.org/Attic/LibgnomeMustDie#libgnomeui
| Xelbair wrote:
| >gnome devs
|
| >learning from mistakes
|
| pick one, and only one. They are the most stubborn bunch in
| existence.
| sitkack wrote:
| The GUI fckshtry on Linux is exactly "The Tyranny of
| Structurelessness". Linux spent billions copying windows poorly
| when it could have spent 1/1000th of that being better than
| Windows by not copying it in the first place.
| anthk wrote:
| Gnome never tried to copy Windows except for Bonobo/Corba.
|
| KDE OTOH tried to combine _every_ GUI into a single place,
| making it usable to any user.
|
| Mac OS? RiscOS? Be? Die-hard Unix with Motif? KDE1 (and more
| 2 and 3) allowed that into widgets/window decorations and
| much more.
|
| But I prefer stuff like IceWM+XFE if I had to choose a
| desktop like environment.
|
| No desktop icons, the menu has shortcut entries and a subdir
| navigator allowing you to open anything with either the file-
| manager or xdg-open. It has a virtual desktop switcher, a
| task switcher, a systay and a clock.
| talldayo wrote:
| This is what the cathedral versus the bazaar is all about.
| You either make everyone angry by rejecting common-sense
| changes because you insist on being different (GNOME) or make
| everyone angry by accepting every kitchen-sink patch
| available until your desktop breaks (KDE).
|
| I guess people perceive it as fuckshittery because there's no
| advertising or marketing team to help assuage the missing
| features. Comparatively, Microsoft Windows struggles to
| maintain any less than a dozen GUI frameworks despite being a
| centrally managed product sold by one company. When you look
| at it that way, it's kinda miraculous that Linux ends up
| having it's cake and eating it too.
| jeroenhd wrote:
| Yet another GUI library won't fix anything. It'll just add one
| more platform that other desktop environments need to theme to
| look normal.
|
| Gnome was right to take a uniform design, the same way KDE did.
| Gnome applications look weird on KDE, the same way KDE apps
| look weird on Gnome, but that's such a non-issue. Every Gnome
| application has an alternative in almost any other widget
| style.
|
| The "damage" they have done seems to mostly be people who don't
| like Gnome being agitated by Gnome's success, forcing them to
| use Gnome applications because their ecosystem of choice
| doesn't have a native alternative. If Gnome were as bad as some
| people think, it would've already shrunk to irrelevance to the
| point the complains would go away.
| 42lux wrote:
| Being responsible for fragmenting the entire desktop
| environment and causing the creation of forks like Cinnamon,
| Unity, Mate, Pantheon, Budgie, Deepin, and Cosmic is not the
| kind of success story I want to be associated with. The
| amount of development time wasted is appalling besides that I
| wouldn't consider my human interface guidelines a success
| when 8 out of the top 10 most downloaded extensions are
| created to get rid of them making the system bearable for
| normal users.
| jeroenhd wrote:
| Why would development time be wasted? Most of these forks
| are "I like the basis, but I want to tweak it a bit". To
| each their own.
|
| I suppose Unity was a bit of a waste now that it's been
| mostly abandoned for standard Gnome these days. Then again,
| Canonical has a history of starting forks and alternatives
| and releasing them early, eventually ending up replaced by
| competitor projects that learned from their mistakes.
|
| The fact KDE's design hasn't inspired much in terms of
| forks seems like negative signal to me. Very few people who
| want to implement things their own way seem to be using KDE
| as a basis. I don't know if that's because KDE is more
| difficult to work with or if KDE people just aren't the
| ones that like to experiment with their own vision, but
| nobody forking the project is not necessarily a good sign.
|
| That said, KDE did just finish a complete redesign, with a
| Gnome-like desktop switcher, a Gnome-style (or rather,
| macOS-style) dock, altered default behaviour for mouse
| clicks, touchpad taps, and the way scrollbars work. Perhaps
| it'll inspire the next generation of tinkerers now that the
| redesign is out.
| 42lux wrote:
| KDE gives you the freedom to do whatever you want with it
| that's why they don't need to be forked. They actually
| learned from their community after the backlash they got
| for kde2. Oh and also gnome has no dock...
|
| That said you seem to misunderstand the gnome "workflow"
| if you think the new KDE features are copies or similar
| to the gnome workflow(tm). I give you that they are
| visually similar but most of the concepts you described
| were shaped by xerox.
| tristan957 wrote:
| Every single desktop you listed has a completely different
| user experience than the next, except for maybe Cinnamon
| and MATE. They are solving different problems. Just because
| a desktop uses GTK doesn't mean it is a fork of GNOME.
| themerone wrote:
| Are we in a state where GTK4 is the GNOME toolkit and non GNOME
| apps will be permanently stuck on GTK3?
| bonzini wrote:
| The opposite: "GTK had the unique case of bundling GNOME's
| design language into GTK, which made it far from generic [...]
| Thanks to the removal of GNOME widgets from GTK 4, [...]
| developers of cross-platform GTK 3 apps that rely exclusively
| on general-purpose widgets can be more confident that GTK 4
| won't remove these widgets, and hopefully enjoy the benefits
| that GTK 4 offers".
| kelnos wrote:
| Yes and no. The reality seems to be that GTK is a lot more
| desktop-agnostic, but in a way that means non-GNOME app
| developers (or non-GNOME desktop environment developers[0])
| have to build a lot of functionality themselves that was
| removed from GTK4 (and/or has been deprecated and will be
| removed in GTK5).
|
| To make matters worse, GTK4 "tightens up" some interfaces,
| making it harder to extend. So, for example, you can no longer
| "wrap" a native window handle on X11 with a GdkWindow (an
| interface that also no longer exists, in favor of a Wayland-
| centric GdkSurface interface) in order to integrate something
| "foreign" into the toolkit. They've also removed things like
| GtkSocket & GtkPlug, so you can't do cross-process embedding
| anymore[1].
|
| I think it's fair to say, though that GTK4+libadwaita is "the
| GNOME toolkit", and GTK4 alone is just a much less capable,
| less extensible, less "batteries included" toolkit than GTK3,
| and GTK5 will drive even further in that direction, if GTK4's
| deprecation list is any indication.
|
| [0] Full disclosure: I'm an Xfce developer, and have been
| disappointed with the direction GTK has been taking for some
| time. I don't begrudge them their prerogative to do what they
| need/want to achieve their own goals with the toolkit they've
| built and maintain. But it really is making life more difficult
| for me.
|
| [1] Part of the argument is that Wayland doesn't natively
| support things like cross-process embedding, so a cross-
| platform toolkit shouldn't have these types of widgets (the
| classic problem of only being able to support the lowest common
| denominator). But a) you can absolutely build something like
| that for Wayland (something I've been working on, though it
| requires tens of thousands of lines of code to do), and b) with
| other changes, it's incredibly difficult and possibly
| impossible to even implement the XEMBED protocol on GTK4, for
| people who do only care about X11.
| tristan957 wrote:
| GTK development is almost entirely led by people involved in
| the GNOME project. From my understanding, members of other
| GTK-based desktop environments have not tried to become
| maintainers themselves to help drive the direction.
| Elementary as a consumer of GTK seems to be fine with most
| decisions. Inkscape and LibreOffice don't seem to care
| either.
|
| All Cinnamon, MATE, and XFCE need is a libxapp similar to
| libadwaita which provides the design language that is common
| between those desktop environments. No one seems to have
| started on it though.
| ginko wrote:
| Just give me back normal window headers already.
|
| And put Okay/Cancel to the bottom right like any other UI toolkit
| in existence
| red_admiral wrote:
| I would personally like the title bar of the active window, and
| only the active window, to be my preferred accent color. Not a
| 1px colored border, an actual title bar.
| phkahler wrote:
| And please keep widgets out of the title bar. Those make it
| very hard to drag windows around because you can't really be
| certain what can be clicked and dragged to move the window.
|
| BTW MS windows does this even worse IMHO - I can't tell what
| app I'm using (think opening a document say .pdf or even an
| email in outlook), can't tell which is the active title bar,
| and not sure what I can drag it by.
| bityard wrote:
| I just started using a Mac for work and this is pretty
| prevalent on Mac as well, possibly that is where it
| originated. Applications on Mac are a random assortment of
| regular apps with proper titlebars and apps which
| effectively have no titlebar.
|
| Mac OS keyboard/mouse focus is also intensely weird and
| inconsistent. The rules for when a click brings a window
| into mouse and/or keyboard focus are basically
| unpredictable, as far as I can tell.
|
| When you click a window to focus it, some applications use
| that click to put the keyboard/mouse focus on the widget
| you clicked on. Others "eat" the click before bringing the
| window to the foreground. So if you want to activate a
| specific text field or whatever for keyboard focus, you
| have to click _twice_ every time you switch focus back to a
| particular app.
|
| But if you do that, you have to _space your clicks apart_
| to prevent them from being interpreted as a double-click!
| Which might maximize the window if you clicked on the area
| that would otherwise have been the app's title bar!
|
| It also throws me off at least once an hour that you use
| can the mouse scroll wheel and all mouse buttons except 1
| and 2 in a window _without_ bringing it into focus.
|
| After my work day is done, I am always so much happier to
| go back to Plasma for my personal stuff and hobbies.
| tristan957 wrote:
| Widgets in GTK header bars are draggable. Had you even
| tried it out before commenting?
| preisschild wrote:
| Nah. CSDs are great and don't waste space.
| kelnos wrote:
| In the days of large monitors, and even hidpi on smaller
| screens, wasting space is not really one of my concerns. I do
| all my work on a 2256x1504 laptop panel, and the 20px or so
| used up by my SSD titlebars is completely fine. I was
| similarly fine with it on my old laptop with a 1080p screen.
| fngjdflmdflg wrote:
| >As a result, GTK and GNOME's design language clashed together.
| Instead of being as general-purpose as possible, GTK as a cross-
| platform toolkit contained an entire design language intended to
| be used only by a specific desktop, thus defeating the purpose of
| a cross-platform toolkit.
|
| This is one of the things I like about Flutter. It supports both
| Material and iOS UI guidelines. There is also an ongoing effort
| called Blank Canvas[0] to provide easier support for creating
| arbitrary UI themes (although you can already do this albeit more
| difficultly). Being that Material looks awful to me (as an
| Android user, even) I'm glad that they support different UI
| Designs/guides.
|
| [0] design doc:
| https://docs.google.com/document/d/1rS_RO2DQ_d4_roc3taAB6vXF...
| fl0ki wrote:
| The only thing worse than modern Material is when there was a
| multi-year (?) period where Google didn't think buttons needed
| _any_ affordance indicating they were buttons, not in shape,
| contrast, color, etc. and with touch UIs you don 't even get
| hover feedback like you would on the web.
|
| Reading between the lines, I can see that Google was inspired
| by the post-skeumorphic minimalism of iOS, but took the wrong
| lessons away from it. Some of that has been walked back, but
| far from enough.
| fngjdflmdflg wrote:
| To me Material looks like Google looked at iOS and compared
| it to their then rectangle-box based UI and said "Our UI is
| too bland compared to Apple. We must need tons of border
| radius and padding. And big splash animations when you touch
| a button!" Some people used to look down on Apple's UI as
| "fisher price" but Google has long taken that crown in my
| book. When I make flutter apps for side projects I just use
| the Apple based widgets (called Cupertino [0]).
|
| [0] https://docs.flutter.dev/ui/widgets/cupertino
| infotainment wrote:
| Ehh... "supports" is a strong word when talking about Flutter's
| iOS theme.
|
| The last time I tried it, it fell into some kind of UI uncanny
| valley -- it looked _mostly_ like iOS, but there were enough
| little things off that it just felt _wrong_.
| arghwhat wrote:
| Well, there are caveats to flutter. One, the packages are
| clearly Material first, with Cupertino not having the same
| coverage and integration. There's a lot of common iOS UI
| constructs that are missing or incomplete, and Material is the
| base-type: There's Scaffold, which is material, and
| CupertinoPageScaffold, which is the iOS version. Widgets also
| don't necessarily mix - in cupertino land you need to use
| cupertino scaffold and page with their transitions, as they
| have hardcodes dependencies on each other.
|
| Second, cupertino is glitchy and just... wrong in so many
| aspects. Sizes, placement/paddings, animations... Placing an
| icon-only button in the trailer of an app bar doesn't align it
| with anything, and something as simple as a page animation is
| completely wrong: Click on a note in the Notes app, and the
| title and content of the new page follows each other - in a
| flutter app, they're on completely independent trajectories.
| Not to mention that mimicking a photo gallery with pinch zoom,
| dismiss and swipe to navigate is borderline impossible with
| flutters gesture stack, and existing packages and built-in
| Widgets don't get close[0]. Its handling of the screen rotation
| animation is also horrendous as it just stretches whatever
| widgets were present with no control.
|
| In my opinion, cupertino is just a weak lookalike used to lure
| developers in, but isn't really good enough to convince users
| in a "real" app. The real utility of cupertino and its packages
| are in adding necessary iOS widgets to material or custom UI
| apps, like share panes.
|
| [0]: Apple gets that one a bit wrong too though. Try to zoom in
| in the right edge of a picture in the Photos app, and start a
| swipe left from the middle of the screen. When the next image
| starts to show on the right side of the screen, change
| direction to swiping right. The previous image will come in
| from the left, but with a completely glitched out transition.
| Flutter is way worse though.
| fngjdflmdflg wrote:
| I appreciate you writing this. These are all valid criticisms
| of Flutter. Especially the bit about pinch-zoom. Proper
| zooming is a long missing feature from flutter. There is
| InteractiveViewer[0] but it does not actually cause a re
| layout of it's children and it also doesn't respect the
| ScrollBehavior of the platform. There is also Two Dimensional
| Scrollables[1] which is a new official Flutter package which
| could theoretically be used to create a better zoom widget,
| although this hasn't been done AFAIK. There are some packages
| that can do this though.
|
| As for Cupertino being a bad reproduction of the real iOS
| behavior, is it really that noticeable to non-developers? If
| so, that is very sad to here. I actually found out about
| Flutter via an open source app that was using Cupertino. I
| really liked the feel of the UI so I looked at the source and
| found out it was using Flutter. I feel like most Android
| users do not care about apps feeling "native" as the
| definition of a native UI feel has changed so drastically
| over the past decade or so on Android, with major apps like
| WhatsApp, Youtube, Gmail and stock Samsung apps each having
| almost completely different UI designs. If there are
| behaviors in Flutter Cupertino that would confuse iOS users
| (not just look slightly different) that does in fact sound
| really bad.
|
| >Its handling of the screen rotation animation is also
| horrendous as it just stretches whatever widgets were present
| with no control.
|
| FWIW I can't reproduce this in my own Cupertino app. For
| example a 3 column grid becomes a 6 column grid when rotated.
|
| [0]
| https://api.flutter.dev/flutter/widgets/InteractiveViewer-
| cl...
|
| [1] https://pub.dev/packages/two_dimensional_scrollables
| jl6 wrote:
| I've been a happy XFCE user for years, and although it uses GTK
| I've never run into whatever drama is going on here.
| gapan wrote:
| Then I guess you missed the huge pile of mess that CSD made
| when they were first introduced to Xfce.
| jl6 wrote:
| I guess I did. I didn't know what CSD was until just now. Is
| this something that using Xubuntu has shielded me from? I've
| been using it since around 2016, maybe a bit earlier, (using
| the default theme) and it's never seemed to be a problem.
| multani wrote:
| Xfce has libxfceui4, which should be equivalent to libadwaita
| (I never directly used it, but that was at least my
| understanding of it)
| jrm4 wrote:
| Bahahaha.
|
| In which GNOME finally realizes that they are not, and never will
| be, a Steve Jobs.
| fl0ki wrote:
| It's even worse than that. Choosing to copy another OS should
| have made the rest easy because it eliminates many design
| decisions and lets you focus on implementation. Somehow they
| still blew it, copying limitations rather than advantages.
|
| It doesn't help that they think extensions are an excuse not to
| finish features in the DE itself, while leaving the extension
| experience so poorly conceived and implemented that you have
| more confidence installing a Skyrim mod than a GNOME extension.
| anthk wrote:
| Gnome 1.4 borrowed a lot from OS8/9.
|
| Then, Gnome 2 got a bit of inspiration of Copland and Mac
| OS9/halfway to 10.
|
| Gnome 3 tries to badly copy OSX (and MacOS tries to do the same
| with some stuff from both iOS and Gnome).
|
| Still, MacOS can dream about having something like QT and not-
| walled software repositories.
| Aerbil313 wrote:
| GTK & GNOME are very successful projects in making me thankful to
| God that QT & KDE exist every time I have to use them.
| cookiengineer wrote:
| It's kinda ironic that they realized (and admitted) this more
| than 15 years later.
|
| Meanwhile, there's Cinammon, MATE, pantheon, moblin, clutter,
| mutter, unity, and several others that went into being hardforks
| at this point because they didn't agree with GNOME's Human
| Interface Guidelines.
|
| It's also ironic that the only thing using GTK2 components on
| every system at this point is GIMP. The problem with upstream
| GTK's workflow is that they have so many breaking releases and
| their own versioning scheme that is completely different from any
| other project, making it impossible to rely upon.
|
| A UI component framework should be reliable, stable in its API
| and scene graph, and not break with any second release every
| couple months.
| kelnos wrote:
| > _The problem with upstream GTK 's workflow is that they have
| so many breaking releases and their own versioning scheme that
| is completely different from any other project_
|
| Not sure what you mean. GTK uses semver; any 2.x or 3.x or 4.x
| release will work with software built around a previous release
| with the same major version.
|
| You can argue that GTK breaks API/ABI and increments their
| major version too often (I'm not sure I'd agree with that, but
| you can certainly argue it), but, outside of bugs, I don't
| recall instances where apps had to be modified to continue to
| work with new releases in the same major version of GTK.
|
| I do think it's notable that GIMP is still on GTK2, and the
| GTK3 porting effort has gone on for many years now. But I think
| it's also notable that GIMP is the exception, not the rule. On
| my system, for example, only GIMP requires GTK2, and I have
| over 100 binaries in /usr/bin/ that link to GTK3
| phkahler wrote:
| Which things are in libadwaita and not GTK? I thought the article
| said Dialog boxes, which would be incredibly bad for cross-
| platform apps if they need to be handled separately on a
| different OS.
| bonzini wrote:
| It's not dialog boxes per se that are in libadwaita, it's
| things such as where to place buttons and in what order, and
| also what are the standard labels for the buttons (e.g. should
| the dialog have Yes/No/Cancel or Don't Save/Cancel/Save
| buttons? That's the difference between the Windows design
| language and the Apple design language).
| phkahler wrote:
| OK, but does that mean I don't get cross platform dialogs
| with GTK?
| jandrese wrote:
| Wait, GtkDialog is considered a GNOME thing and is now
| depricated? They article claims "These aforementioned widgets
| only benefited GNOME apps, as they were strictly designed to
| provide widgets that conformed to the GNOME HIG.", but GtkDialog
| is the primary way to provide a modal dialog in GTK. That seems
| like a fairly general problem.
| the_biot wrote:
| It's entirely logical for the Gnome folks to do this. They've
| been removing features and widgets from all kinds of programs
| for literally decades; Gnome is fundamentally a destructive
| project. Outright sabotaging GTK (which predates and inspired
| Gnome) is just the logical way forward on this multi-decade
| orgy of destruction.
| bonzini wrote:
| There is gtk_window_set_transient_for() and
| gtk_window_set_modal(), and GtkDialog is basically a
| synchronous wrapper for those two + a nested event loop. But
| nested event loops are very easy to get wrong, so my guess is
| that, these days, you want to write the code for modal dialogs
| as if they were _not_ modal, even if to the user they prevent
| interaction with other parts of the program.
|
| EDIT: yep, the nested event loop part is not found in AdwDialog
| either (https://gnome.pages.gitlab.gnome.org/libadwaita/doc/mai
| n/cla...) so that's probably why GtkDialog is considered
| deprecated.
|
| There is also GtkAlertDialog which is a replacement for
| GtkMessageDialog but has a better design (for example it does
| not inherit from GtkWindow, which was a very 90s OOP thing to
| do) and it uses a callback instead of a synchronous, nested
| event loop.
| AlienRobot wrote:
| >these days, you want to write the code for modal dialogs as
| if they were not modal, even if to the user they prevent
| interaction with other parts of the program
|
| I'm never going to use a toolkit that can't guarantee a modal
| is modal.
| tristan957 wrote:
| GtkDialog is just a GtkWindow with a slightly different API.
| fnalelal wrote:
| Good. What Linux needs is libwidgets, i.e. GTK, to have widgets
| for desktop applications. And, separately, libwankery, where the
| GNOME geniuses can implement whatever nonsensical "design
| language" they want for their 0.003% of the market user base.
| kelnos wrote:
| The funny thing about all this is it's just history repeating
| itself. Back in the days of GTK2, there were a handful or two of
| "libgnome"-prefixed libraries that GNOME apps tended to use, but
| non-GNOME apps (that used GTK) tried to stay away from, in order
| to avoid depending on large bits of the GNOME desktop. The
| problem with that, of course, was that people in that position
| either got by with reduced functionality, or had to write their
| own code to do things that many people considered should be a
| part of the toolkit.
|
| The GTK developers did recognize that a lot of this stuff was
| integral to a UI toolkit, and so most of the functionality in the
| various libgnome libraries was moved into GTK for GTK3.
|
| And now apparently we're going backward again. No, I get, it's
| not the same situation. They are focusing more on "design
| language" than functionality: for example, the printing
| functionality that was moved from libgnomeprint (or whatever it
| was called) into GTK3 is staying (which makes sense), but menu
| bars (which have been in GTK since the beginning) are going away
| because GNOME doesn't use them anymore.
|
| But that's a part of the problem; it seems like their rubric is
| "if GNOME doesn't need it, then it should be deleted"[0], coupled
| with the idea that many _new_ design language elements should be
| GNOME-only and live in libadwaita, even if a more general
| audience would benefit from those elements.
|
| As a developer of GTK-based applications for a good 20 years now,
| I honestly can't recommend GTK for new projects outside the GNOME
| umbrella. The problem is I'm not really sure what to use instead.
| Qt is really the only other major cross-platform toolkit, and
| does seem like a more stable base, but I don't want to do C++,
| and bindings for other languages aren't very ergonomic. (And
| toolkits like wxWidgets are just abstractions on top of other
| platform libraries.)
|
| What I really want is a Rust-native UI toolkit library that does
| its own drawing, but can consume GTK3 themes. To me, the big
| issue is that of "native look", and I don't want Yet Another UI
| Toolkit that allows people to build apps that don't fit into my
| desktop at all.
|
| [0] Note that quite a few things, like GtkDialog as a notable
| example, didn't get removed for GTK4, but have been deprecated
| and will be removed in GTK5.
| HumanOstrich wrote:
| I was with you until you suggested rewriting everything in
| Rust.
| talldayo wrote:
| It's really not crazy at all, if you're familiar with what
| GTK expects developers to put up with for "native"
| development. Not long ago everyone was learning Vala because
| it looked like the way forward, but now you can get the same
| results with less code using gtk-rs and libadwaita. Rewriting
| it in Rust is one of the less-insane takes on the discussion
| table right now.
| grumpyprole wrote:
| Are they really deleting menu bars? Wow. Maybe in ten years
| time they'll figure out that two hamburgers is better than one;
| and that they'll need names like "File" and "Edit".
| tristan957 wrote:
| GtkDialog is just a GtkWindow with a few things done for you.
| It wasn't exactly a pleasant API to use either.
| AlienRobot wrote:
| Why does everyone have to make it so hard? All I want is
| literally the widgets Windows had 20 years ago in all
| platforms. That's all.
|
| I don't even need the ribbon.
|
| And now GTK has sliding tabs with animation effects I have to
| install tweaks to turn off. To begin with, why is tweaks even a
| thing? This should all be in the normal control panel! I can't
| believe I used to hear criticisms about the windows registry
| when in linux I need to install 2 different regedits to make
| the GUI look bearable.
|
| This is why people use electron.
___________________________________________________________________
(page generated 2024-06-03 23:01 UTC)