[HN Gopher] GTK 3.99
___________________________________________________________________
GTK 3.99
Author : severine
Score : 118 points
Date : 2020-07-31 20:17 UTC (2 hours ago)
(HTM) web link (blog.gtk.org)
(TXT) w3m dump (blog.gtk.org)
| marsrover wrote:
| Still waiting for an acrylic blur (or some other type of blur) to
| bring Gnome to parity with modern desktops.
| jaas wrote:
| I don't understand what you're asking for. Can you explain?
| nightfly wrote:
| Transparency with a blur effect for windows. So you can see
| some of the color that's behind them without all the detail.
| I'm... not really a fan of it. It drives me crazy in windows
| that terminal transparency is for the entire window (even the
| text!) and not just the background.
| renewiltord wrote:
| There was a time when I had a terminal with just the
| background transparent. I recall that. You could do it in
| software and even on hardware on a Via Unichrome.
| mmm_grayons wrote:
| Terminal with transparent or even blurred background is
| very doable. I've done it on my i3-gaps and urxvt setup
| both with urxvt's "fake" transparency and by using a
| compositor.
| renewiltord wrote:
| I vaguely remember Gnome-Terminal even having it. I
| wonder if they removed it.
| ShroudedNight wrote:
| It appears that they removed it in 3.7:
|
| https://askubuntu.com/questions/475935/did-they-just-
| remove-...
| marsrover wrote:
| I don't think anyone is asking for the blur to encompass
| the text in a terminal. Is this a bug? I could have sworn
| when I used Windows Terminal that this wasn't the case, but
| it has been a while.
| [deleted]
| Firehawke wrote:
| If you turn on the acrylic mode, yeah, it covers the
| whole window. I have the preview of WT installed here and
| acrylic looks awful compared to how it did back in
| Windows 7. Probably a function of the way Microsoft wants
| you to use it in "modern" Windows 10 as opposed to
| Windows 7 as there are marked differences in how acrylic
| looks compared to the Windows 7 era and less
| configurability.
| marsrover wrote:
| Actually, apparently it is going to be supported in Gtk 4. My
| bad, I haven't been keeping up with it.
|
| https://developer.gnome.org/gsk4/stable/GskRenderNode.html#g.
| ..
| saturn_vk wrote:
| That might just be blurring a widget within a window, not a
| texture coming from another one
| c-smile wrote:
| GTK still misses:
|
| 1. Anything close to AdjustWindowRectEx() function. See:
| https://docs.microsoft.com/en-us/windows/win32/api/winuser/n...
|
| 2. MoveWindow(window,rect) where rect is window frame rectangle.
| Instead GTK has 6 other functions that do something close but no
| one of them do MoveWindow.
|
| See: https://stackoverflow.com/questions/58103333/set-frame-
| posit...
|
| Windows has these functions, MacOS has their direct equivalents,
| but GTK does not have such, IMO basic, functionality.
|
| Will we have anything like that in GTK4?
| chrisseaton wrote:
| I think this is because of the separation between window
| manager and GUI toolkit.
|
| Which I think is a terrible thing to have separate, for the
| functionality reasons you're illustrating.
|
| But that's why.
| [deleted]
| ATsch wrote:
| Wayland does not allow clients to make decisions such as the
| precise placement of windows for security and sanity reasons,
| so I do not think that these will ever be added.
| skeletal88 wrote:
| Then Wayland is kind of stupid. Why is that restriction
| needed or why do the developers think that it is a good idea
| to have it?
|
| For example, when the user has arranged the windows of an
| application in some way, and then wants to save and then
| restore the placement of windows, how should it be done by
| the application?
| sho_hn wrote:
| On Mac OS, you can ask the WM to store the geometry for you
| and recreate it. It's exposed to devs via the
| NSApplicationWindow (or something) API and then backed by a
| protocol between the app and the windowing server, leaving
| the latter in ultimate control.
|
| Wayland doesn't have an equivalent protocol yet, but this
| is also how it would be idiomatically done there.
| saagarjha wrote:
| But of course macOS also has APIs on NSWindow to move it
| around, as well as accessibility and AppleScript APIs to
| do it as a user in a scriptable way. Why the limitation?
| ATsch wrote:
| You can use positioners to request a location for your
| popup window relative to your toplevel window:
|
| https://wayland-book.com/xdg-shell-in-depth/popups.html
|
| You just don't get to set the absolute position of your
| window. The precise position and making sure it isn't going
| off of the edge of the screen is the responsibility of the
| compositor.
|
| This is good because it ensures proper security sandboxing
| and makes sure clients still work even when the windowing
| paradigm changes, e.g. with multiple desktops or window
| tiling. Developers hardcoding such assumptions is what
| caused much of the pain of Xorg so it's understandable that
| they want to make sure it does not happen again.
| war1025 wrote:
| It's done by the window manager, which is integrated
| directly into Wayland. The tight coupling of the two is a
| semi-contentious issue.
| [deleted]
| ohazi wrote:
| Is GTK 3 -> 4 expected to be as big a clusterfuck as 2 -> 3?
|
| I'd really rather not go through all that again.
| nfoz wrote:
| What were the problems with this transition?
| RedShift1 wrote:
| API changes every minor release.
| vetinari wrote:
| Any specific examples?
|
| According to https://developer.gnome.org/gtk3/stable/gtk-
| migrating-3-x-to..., the changes were pretty minor.
| ohazi wrote:
| They broke enough of the theming API on every minor
| release that for a few years it was essentially
| impossible to run any GTK theme other than the GNOME
| sanctioned default theme (Adwaita). Adwaita was updated
| in lock step with GTK minor releases (by the same
| developers), and unaffiliated theme builders were left
| with periodic drops of subtly different behavior and no
| notes or tools on how to update their themes. It drove
| many of them away.
|
| This was apparently a part of a deliberate strategy
| around GNOME branding. The GNOME developers wanted all
| GTK apps to have one consistent look-and-feel, they
| wanted people to associate this look with GNOME, and they
| wanted people to start thinking of GTK apps as "GNOME
| Apps."
|
| More recently, they crippled existing functionality for
| server side-window decorations (which literally every
| other toolkit supports), because GNOME decided to use
| exclusively client-side decorations. They vetoed all of
| the reasonable seeming workaround proposals, essentially
| telling developers to either use GNOME's decorations or
| to manually draw the close/maximize/minimize buttons.
|
| Honestly, all of the crap that systemd gets should be
| redirected towards GTK/GNOME. I've never seen a group of
| developers act in such bad faith.
| saagarjha wrote:
| Looks like they got the worst of both worlds, with no
| Cocoa arising from it and a bunch of pissed off
| developers and users...
| wolfgke wrote:
| RedShift1:
|
| > API changes every minor release.
|
| vetinari:
|
| > the changes were pretty minor.
|
| Was this pun intended? ;-)
| madboston wrote:
| There are not enough words I can write for this.
| quotemstr wrote:
| The GTK 4 transition is totally unnecessary. Any new
| functionality needed can be incorporated into the existing API
| in a backwards-compatible manner. Major version bumps should be
| an absolute last resort, not something a major infrastructure
| library does when it gets too stable and its developers get
| bored.
|
| You want a new recyclerview-like list widget? Great. Make a new
| damned widget. You want a retained-mode rendering system?
| Great! Add a bunch of new widget hooks. Don't require a whole
| new major version bump and make everyone using GTK3 deal with
| dependency hell trying to get upgraded. It feels like only
| yesterday that most things finally moved off GTK2.
|
| There is _ZERO_ reason for an ABI break here. None. GTK3 's ABI
| is a perfectly adequate base for adding new functionality. The
| GTK people, by making a GTK4, made a lot of work for everyone
| for no benefit.
|
| Is the GTK4 API cleaner? I guess? Event objects are opaque now.
| There's no root window. Yay? But "it looks slightly cleaner" is
| a totally inadequate justification for the pain of yet another
| GTK ABI transition.
|
| I could go and on about how much gratuitous breaking changes
| piss me off.
|
| The same goes for Wayland, by the way --- X11 has an extension
| mechanism. Wayland could have used it. And don't tell me about
| the core protocol breaking the model --- it doesn't hurt
| anything if you don't use it.
| war1025 wrote:
| > The same goes for Wayland, by the way
|
| Wayland happened mainly because they could get to 90% of Xorg
| functionality easily and ignored the fact that the last 10%
| would take over a decade to achieve parity on.
| quotemstr wrote:
| > Wayland happened mainly because they could get to 90% of
| Xorg functionality easily
|
| We're at 12 years of Wayland and counting and the thing
| _still_ isn 't really usable outside a very narrow use-
| case. I still run X11 myself and will for a long time. As
| far as I'm concerned, Wayland has set free software
| windowing back by a decade. After a decade of development,
| Wayland still isn't at parity with X11. What exactly is so
| compelling in Wayland that it was worth putting progress on
| hold since 2008?
|
| Yeah, yeah, I get that Wayland has a nice buffer-based
| composition system. _So what?_ Whatever Wayland does, it
| could have done over an X11 extension.
| fmntf wrote:
| While I totally agree with you in a desktop-like
| scenario, please note that X is totally inadequate and
| bloated for other domains (e.g. automotive).
| quotemstr wrote:
| Why? X originally ran on machines far less powerful than
| even the shittiest automotive head units around today.
| moonchild wrote:
| X has serious architectural problems. What would it _mean_ to
| build a completely new windowing API using the extension
| system, if 'proper use' would mean using exclusively the new
| extended API? Is that meaningfully different from building a
| new windowing system (cf wayland) and implementing x11 on top
| of it (cf xwayland)?
|
| FWIW, I think wayland also has serious architectural
| problems, and see arcan as much more promising, but
| rewriting/replacing legacy can definitely be justified.
| Extension hell is much worse than compatibility hell. If you
| don't _like_ gtk4 's api, then don't use it; gtk3 will
| continue to work. It's better that an api should be coherent
| and cohesive than that it should bend over backwards to keep
| compatibility with ideas that no longer make sense.
| Obviously, this should be applied within reason--don't do a
| complete rearchitecture every month--but compatibility breaks
| are important and necessary.
| AlexMax wrote:
| Good for them. Does this mean we're going to get a GNOME 4 as
| well? I'm quite curious to see what neat things the new version
| of GTK enables in practice.
| matthiasv wrote:
| While the toolkit certainly has an influence on all core apps
| that are part of GNOME, the shell is entirely independent of
| GTK. So, highly unlikely there will be a GNOME 4 any time soon.
| IAmLiterallyAB wrote:
| Eh I bet there will be. Every Gnome/GTK version until 3.22
| had the same version number and were released at the same
| time. The only reason that stopped is because GTK 3.22 was
| supposed to be "stable" and "the last GTK 3" version while
| Gnome still wanted to do updates.
| randtrain34 wrote:
| Can someone point me to a roadmap/changes to be expected for GTK
| 4.0? I've looked on the blog and googled around, but couldn't
| find an authoritative source.
| stonogo wrote:
| https://gitlab.gnome.org/GNOME/gtk/-/milestones/1
| marsrover wrote:
| https://gitlab.gnome.org/GNOME/gtk/-/milestones/1
| techntoke wrote:
| Telegram has shown the enormous potential of Qt with the latest
| update. Not that I have a horrible time with GTK, but Qt just
| feels better and lighter overall. qutebrowser is another example
| of the amazing potential of Qt.
| saagarjha wrote:
| Personally, I much prefer GTK apps over Qt ones. What makes you
| think that Qt does it better?
| klysm wrote:
| Does the .99 versioning irk anybody else? It seems like a very
| inelegant solution.
| chungy wrote:
| It's a serious blast to the past, and not necessarily a good one,
| to see versioning treated like this, where they'll pick 3.9? as a
| form of alpha/beta/RC phases for 4.0.
|
| I think semver (more-or-less a formalization of what was already
| becoming popular before semver got published) makes more sense.
| Go ahead and use 4.0-alpha.1, 4.0-beta.1, 4.0-rc.1 as needed. The
| strings still sort fine.
| Quekid5 wrote:
| Pfft... The versioning scheme is the _least_ of GTKs problems.
| layer8 wrote:
| The problem is that "4.0" sorts before "4.0-alpha.1". Not
| saying that 3.99 is better, but something's gotta give.
| deathanatos wrote:
| If you're lexicographically sorting, maybe? But if you're
| doing that, 3.10 and 3.2 won't sort correctly, either.
| bch wrote:
| NetBSD does similar (major.99.iteration), and before its alpha
| or beta, this is where things get hashed out. It's a reserved
| magic number (one _hopes_ there aren't 99 minor releases that
| would start a conflict over x.99.y) so that sucks (being
| "magic"), but it seems to work out in practice.
| Jerry2 wrote:
| Anyone know if they've finally added thumbnails aka "icon view"
| to the file picker?
| Shared404 wrote:
| That would be an issue with the GNOME DE, not the GTK toolkit.
___________________________________________________________________
(page generated 2020-07-31 23:00 UTC)