Gaslighting Wayland Devs To Fix Multi Window Apps
Vložit
- čas přidán 15. 12. 2023
- I've been harping on about multi window apps on Wayland for quite a while and whilst I would like the problem to be done we're now on the 3rd protocol which I like to call gaslighting the Wayland devs into fixing the problem.
==========Support The Channel==========
► Patreon: brodierobertson.xyz/patreon
► Paypal: brodierobertson.xyz/paypal
► Liberapay: brodierobertson.xyz/liberapay
► Amazon USA: brodierobertson.xyz/amazonusa
==========Resources==========
Protocol 1: gitlab.freedesktop.org/waylan...
Protocol 2: gitlab.freedesktop.org/waylan...
Protocol 3: gitlab.freedesktop.org/waylan...
=========Video Platforms==========
🎥 Odysee: brodierobertson.xyz/odysee
🎥 Podcast: techovertea.xyz/youtube
🎮 Gaming: brodierobertson.xyz/gaming
==========Social Media==========
🎤 Discord: brodierobertson.xyz/discord
🎤 Matrix Space: brodierobertson.xyz/matrix
🐦 Twitter: brodierobertson.xyz/twitter
🌐 Mastodon: brodierobertson.xyz/mastodon
🖥️ GitHub: brodierobertson.xyz/github
==========Credits==========
🎨 Channel Art:
Profile Picture:
/ supercozman_draws
#Wayland #Linux #OpenSource #FOSS
🎵 Ending music
Track: Debris & Jonth - Game Time [NCS Release]
Music provided by NoCopyrightSounds.
Watch: • Debris & Jonth - Game ...
Free Download / Stream: ncs.io/GameTime
DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase I may receive a small commission or other compensation. - Věda a technologie
Rick Yorgason here. A big piece of feedback on the original protocol was "we can't accept this when we haven't even explored the possibility of a better alternative", so Matthias is doing his best at exploring alternatives.
I'm just doing a bit of light tire kicking on his proposals. I legitimately think his latest proposal is a better fit for non-traditional compositors (tiling, scrolling, VR, etc...). It's moderately harder for traditional compositors, toolkits, and Wine, but it's flexible enough that they should be able to do *something* reasonable. And the loudest voices in the Wayland community have this weird double standard where supporting unusual compositors is of the utmost importance, but unusual apps are "not our problem", so this might have more success at getting accepted.
But if the end result is just saying "okay, we explored the alternatives, and they're more complicated than they're worth, so we should just go along with the industry standard", then that's a win too.
I appreciate you testing some of the edges and concerns you have in a productive way. Whilst I would have been happy with the first protocol I think this one is the best we've seen so far
I just wrote a lengthy reply to someone asking why there's hesitation to adopt absolute positioning, but it looks like the original post got deleted. So if anyone's interested, here's what I wrote:
I like the original proposal; that's how I found it in the first place, but the people who don't like the original proposal have a few different reasons.
The best complaint I heard was from someone who is building a VR compositor, and yeah, XY coordinates really don't make sense in a 3D space, so I get it. I think the latest proposal works better here, because you can easily place a virtual screen in 3D space.
It's a similar situation with tiling compositors. Smart compositors could theoretically do something like this already to keep app windows clumped together, but it would be guess work that sometimes guesses wrong, and wouldn't work for multiple apps coordinating together. I feel like these developers are holding out hope that Qt, SDL, and all the other toolkits drop support for absolute positioning if Wayland doesn't support it, thereby forcing app authors to stop making these "distasteful" apps that work poorly with tiled managers, but I think that's unrealistic, especially now that JavaScript is getting support for absolute positioning.
There's some people who are worried about security risks, where a malicious app does something like placing a borderless window over a credit card input field to capture your input. It's a stretch given you would have already had to give the malicious app permission to run, and to inspect your screen, but I'm glad someone's thinking about it.
Then there's people who are just worried that if an app can place a window wherever it wants, then apps will start doing that all the time, and the desktop experience will be garbage, but I never bought that argument, because apps have been able to do that for about 40 years and generally haven't.
Either they deleted it or CZcamss auto filter is running wild
@BrodieRobertson My guess is probably CZcams, because on Thursday I tried to post a comment on your video without links and it disappeared TWICE.
@RickYorgason
> I'm just doing a bit of light tire kicking on his proposals.
And I am very thankful for that! And in this case I think the new proposal does actually improve upon X11 while still being not too much of a burden to port to and allowing enough cross-platform compatibility.
It could even be augmented to work as session-management protocol, by simply making the workspace (now zone) handle persistent, allowing windows to restore themselves at the position where the user has left them. But I didn't want to make this too complicated (or start a riot by certain compositor developers), so I left this out for now.
Tbh this protocol proposal seems pretty ideal to me aside from the 'workspace' name. It goes above an beyond to be more versatile than absolute coordinates in ways that could be helpful for window management, should play nicely enough with existing applications, and strikes a balance of power between compositor and application that I think should be ideal for all (reasonable) parties.
I like the "virtual coordinates" name. Workspaces is best used for virtual desktops.
@@softwarelivre2389 Virtual Coordinate Systems... wait a minute...
"Ideal for all (reasonable) parties"
Ah well there's your problem right there, these are wayland devs we're dealing with. 😂
I may not be understanding this properly, but the multi-workspace suggestion seems like _the solution_ to make this feasible for tiling WMs, as it allows for arbitrarily irregular geometries.
Practically, giving the multi-window workflow access to, say, 3/5 tiles while you have a web browser and a terminal having squares reserved on the remaining two seems like the ideal outcome.
However, I think you could achieve something similar with an "in-between" layer: A sort of mini-winow manager, that registers as a client with one window to the Wayland window manager, and offers an extended Wayland protocol to the applications, which allows free window positioning inside the registered Wayland window.
This would save all the Wayland servers from implementing all the complexity this protocol imposes. It only needs to be something that works for all clients and can be set up in an easy way.
Just think about the additional work this protocol would impose on the OS community: Every single Wayland window manager would need to re-implement the same thing. Instead, you could just have this in-between layer which would need to be written once, and solve it for all clients and all servers.
Hey, while the most gets annoyed by wayland devs reinventing the wheel, some of these new wheels provides a new unexplored path that we haven't figured out before.
imo this combined with modularity of protocols and the freedom on implementing them, I see a win at the end _most of the time_
Though sometimes it takes forever to get to the good end 😅
wayland is a great example of perfection being the enemy of the good
Wayland is also a good example of having the end-user having the freedom to do anything... within the tight confines that the core developers define.
one day we will get there!
7:26 I love that we're reinventing vram for application space on monitors
context: vram (virtual ram) works by giving a program some amount of ram that the program sees as 0 to max, but the actual placement of where that chunk in memory lives is the memory management's responsibility (like having the chunk start at 1024 instead of 0 or something)
First 3 words worth a click lmao
Fr, I just went bruhhhh I gotta click
Remove everything EXCEPT the first 3 words.
Insta 4 million views
'So far I'?
If I'm inferring how this works correctly, I would suggest calling them "Screen Zones", ngl.
Sounds reasonable. I was thinking playgrounds :-)
"Virtual coordinates" seems good for me.
@@softwarelivre2389Virtual seems like the right word. I was going to suggest virtual relative screens. VRS is a good solid old-school TLA.
I have a feeling they might not like the term "screen" because wayland is trying to be more general than that
@@centdemeern1VRD for display? M for Matrix. VRCS (co-ordinate system) is an e-TLA...
Every time a new protocol for this is introduced. The odds go up of it being implemented.
I wonder if Gnome is going to break its way into not being the de facto DE.
there is an infinite scroll wayland compositor out there called newm, with the maintained version being newm-atha. It's a really neat project.
It's impressive that none of the people who thought this was an important use case even mentioned it lol
There's also a somewhat more recent compositor called niri, which is infinitely scrolling but only horizontally. I use it right now, because I have a very wide monitor and find that it works nice for my workflow mostly
At this point I'm kinda worried that X11 will be killed off before Wayland is actually ready, and then a lot of applications will just be limited to Mac and Windows, because Linux does things in a non-standard way that's too confusing. I get that they wanted to remove the bloat and improve security, but did they really have to make a totally incompatible way of doing everything that a lot of developers will see as harder to work with than X11? It's too bad there's no actual alternative to Wayland giving it a run for its money, like Mir wanted to be... I bet if they had to compete with something else people liked better that was actively developed, suddenly they'd drop a lot of this arrogance and try to win the competition. As it stands, Linux users are basically going to be stuck with Wayland even if it sucks and have to work around it by standardizing on a single compositor or something, writing everything for that specific compositor and not making exceptions, even if Wayland in theory wants to support multiple compositors. Developers can't work with ambiguity like this, so eventually applications will just be written for specific Wayland compositors and not for Wayland itself, with Wayland becoming an insignficant technical detail as developers give up talking about it and start talking about writing applications explicitly for KWin, Mutter, etc, whatever gives them the features they need, and not be portable across Wayland compositors. Is that really their goal, or are they just not seeing that as a likely outcome?
This is an issue that is likely not ever going to effect the average user but I do expect RHEL to get a rude awakening from industry partners if they continue to sleep on issues like this one
Well XWayland will always be a fallback, and virtualization the _ultimate_ fallback.
wayland could be ready without gnome.
@@GSBarlev It will be funny if even 10 years from now, the main way people use Wayland is STILL through XWayland. Wayland by itself isn't a drop-in replacement for X11, but XWayland is... X11 applications can be adapted to the limitations of XWayland a lot more easily than they can be adapted to all the Wayland compositors out there. I know a few application developers who have said that their response to Wayland isn't going to be rewriting their application, but rather simply testing to see if it works well enough on XWayland and treating that as the new standard, with plans to drop Linux support if that ever stops working and they are forced to rewrite their application for Wayland to keep building a Linux version. I can easily imagine us winding up with something very much like what we already had, with KDE applications only working properly with KWin, GNOME applications only working properly with Mutter, and XWayland being the main half-busted fallback for more independent applications that aren't really in the KDE/GNOME space that need to coexist with multiple compositors and have some legacy support. I wonder if someone will wind up writing a Wayland compositor that is primarily intended to run XWayland as well as possible, perhaps even well enough to get X11 Window Managers working, and how the Wayland devs would react to that. But more seriously, look at the web browser space... Wayland is a protocol, just like HTTPS and HTML and all of those. Does anyone actually read the spec, or do they just try to code against the two main implementations of that spec, Firefox and Chromium, and treat those as the defacto standards regardless of what a spec or a protocol says? Seems to me like most web developers just write web pages for Chromium and not for web standards, and I can easily imagine most app developers just writing apps for GNOME and not caring about Wayland as a standard outside of that.
@@GSBarlev VMware UX has also regressed on Wayland/XWayland. There's noticable additional delay and a cool mouse lock/absolute repositioning bug similar to the ones in Wine and Barrier that messes with certain apps' 3D viewports and sliders (granted the gaming mouse setting fixes this but probably has its own issues).
What I'm really curious about is, what is Cosmic's ideal solution? What WOULD they be interested in supporting if they could just snap their fingers and instantly have a solution that works with multi-window applications?
I hope they implement the first one, as it's the industry standard fro traditional window managing.
I also have one extremely important problem with Wayland, being that LibreOffice, when it detects multiple monitors, spawns two windows in presentation mode. One for the presenter and one for the audience. On X11 the presenter window appears on the main screen and the audience window on the secondary screen. On Wayland they appear both on the active screen and moving them using the desktop switcher breaks the audience window and it stops updating its visual content, which is a huge problem for a slideshow.
This topic has been a source of endless frustration, even back in the X11 days - there were basically three or four parties involved and they were playing hot potato. The Desktop environments say, it's the applications responsibility, the application developers say it's the toolkit's responsibility, the toolkit says the window manager …
As a user, I just want my browser windows to open back where they were when I closed them. I don't care who implements it or how. Just get it done, please?
I'm sad to hear this attitude is still present. It reinforces my decision to stay very far away from Linux in any role, and to minimize my use of any Unix in a desktop role. After years of fighting with Linux and noticing that just-about every other OS is easier to manage, I figured Linux contains a whole host of things being fixed in the wrong layer. Without knowing the history of every part, it could be due to those who should be responsible passing the buck. In one case, I know it's true: udev exists because Linus Torvalds refused to include DevFS. I recall experienced sysadmins finding udev painful to use.
16:05 X11 places no restrictions on positioning or size. It you want to go outside the monitors you can.
Fair enough, I probably framed that sentence a bit off
I'm with a lot of commenters here: I found this to be incredibly sane (except the name, but that's obvious by this point :D), and even moreso Rick Yorgason's comment about not restricting it to one workspace per client. I'm used to running a number of apps with their own mind when it comes to window placement, and this would actually let me finally move to a tiling WM.
You've got my attention just with the notion of a windowgroup that can be moved/stacked/tiled independently of whatever else you're doing. I appreciate that tiling is really efficient, but for me tiles mean that there's less and less space for existing windows whose sizes were not an accident. I have several browser windows and they're all maximized for a reason, etc.
But those windows for me are effectively like a 2nd order tab structure. I use them because I don't really have a way to organize an unreasonable number of tabs into tab groups that work for me. But effectively this group of browser windows function for me as One Thing. I actually have two workspaces of Firefox and one of Brave, with each workspace containing windows each with a group of tabs. A window group could help improve that workflow. (Some tree tab system I actually like could improve it more, admittedly.)
Isn't this a "wrap the app into a virtual window manager" but with extra steps?
I mean the very idea of a multi-window application is never gonna play nicely with external window management (tilers, other apps, …) unless the compositor gets a lot of very informative hints and somehow makes sense of them. And that's not gonna work out for all of these legacy applications here, so we still need to provide them with a legacy-like API somewhere. IMO the best place would be either a wrapper compatibility layer that presents itself to the compositor as a single window (per monitor?) or just Xwayland .
Yes it basically is that
I personally like this new approach, the only downside is really the extra abstraction layer but I don't see any other way that is easy to port to than either real global coordinates or these "virtual global coordinates".
I thought on "virtual coordinates" as well. The global one probably would make the name too long, but the idea is good.
Regarding negative coordinates, I don't even find it that weird. I mean, you can place windows partially outside of the screen anyway, right?
A side note to 15:20 and multiple work spaces across multiple displays, the devs shouldn't lose the intended use case here, if I start up an application for the first time and everything is constrained to the "primary work space" then so be it, the MAIN use case is this, after moving windows about, left or right. I expect those windows to remain in the "indexed" work space where I left them when I *RESTART* the application! If I swapped my displays around and "display 2" is now on the left instead of the right, then I can expect me windows to be somewhere else!
wayland has just so many roadblocks and design committee issues
which would be ok, if it wasn't being adopted as the next standard before arriving in the 90s in terms of functionality.
Having fun toys and super cool modern stuff means nothing if you can't actually use it because some basic features are missing
i used to use a laptop together with a bigger monitor, so having a single "workspace" rectangle would not be an option for me lol
One thing I will say about Wayland's approach to new proposals is that, they should probably just *try implementing the proposals in an experimental branch* instead of endlessly debating how a protocol would be implemented and behave. One of Wayland's strengths (supposedly) is that compositors can choose not to implement protocols that they don't need, and there are a number of "minimal" compositors that Wayland devs could use to implement an experimental protocols and actually see if they work, their caveats, etc.
There's also no harm in tearing that work down afterwards and rewriting reference systems once the protocol is proven to be beneficial. That experimental work does not need to be (and shouldnt be) final.
Multiwindow app support has taken so long because no one thought to implement these ideas and find out that the first proposal was DOA. The 2nd proposal basically has a proof of concept drawn up in an image processor. That's fine too, but surely that's evidence that these proposal need to be more tangible instead of months of theoretical debate.
Or am I wrong here and they DO make experimental protocols for testing?
15:20 This is exactly my point. Why are they discussing ~entirely hypothetical~ scenarios when a simple protocol could've been built and tested to see how best to approach this issue? I don't think it'd make the discussion happen faster, necessarily, but at least these discussions would come to a conclusion instead of everyone having an imagined Wayland compositor in their heads.
I recon the answer to all of lifes problems is... step 1: What ever you do, don't use gnome.
"Virtual coordinates" seems like the best name for this.
18:05 I think the point here is that apps themselves are only allowed to request positions within a workspace, but a user can drag them out, and just build into the protocol that, when a client asks, the position of a window may be larger than that of the workspace, sort of like if a window had been dragged off-screen
40 years of graphical user interfaces on every other system around. Wayland guys: "We know better!".
the X11/xorg guys and wayland guys are literally the same ppl. they made wayland specifically to adress the issues they've been having with maintaining and developing xorg and the X11 protocol.
Bruh, if every software project is a student council, then the wayland project is the entire parliament
I'm just thinking in my head it could be kinda like gamescope, where it's basically a "virtual screen" inside a window where the user defines the width and height the app can use through a launch variable before starting the app, but with a transparent background instead of a black one. Or like how WINE has it's own "desktop mode" of sorts, complete with the ability to modify it's registry to set a custom background that isn't blue. When you close the virtual window, it closes everything else.
I really like the 'workspaces' approach. it allows the devs of these floating-window spaghettifests to imagine they're in control of window management (and in fact, they are by default), while in reality it's me and my sway config giving them the illusion of whatever they want it to be, since that's the program that's literally built for, y'know, *window management*
I love gaslighting programs :3 chroot my beloved
Contributor: “Here’s a fix to a pretty common real-life issue. I did everything to make it work, I tested it, I documented it, I described what it does, I perfectly integrated it in your current code, all in my free time, because I like the project and want to help making it better”
Devs: “No, fuck off.”
Contributor: “Here’s a absurdly complex and complicated other thing I am thinking about. This thing makes it harder for everyone to implement and less consistent to work with!”
Devs: “Great! We buy it! Let’s discuss how to make it even more complicated and complex!”
🤣
This is why Linux is so fragmented, devs don't want to collaborate so everyone says fork it and goes their own way
@@IoraTeraThat's GNOME for you...
the segment at 18:11 is repeated twice, looks like you did a retake but forgot to remove the first take
I think it would be neat to toggle a parent window for managing/resizing groups and use in tiling window managers. It would be the windows 3.1 file explorer or program manager but with a nice blur in the parent window.
It's not wrong, but it's always jarring for me when Brodie says "Windows doesn't support tiling" given my first experience with tiling was Windows 3.1 😂
16:50 "Would it be better to just expect clients to-" NO. Not until Wine is no longer something people have any interest in using.
If you're asking "how should the applications that target us behave?", you're asking a pointless question at the moment. It's "How do we get the applications that target elsewhere to work as users expect them to?".
You want to make things work for the unmaintained binary running off a compatibility layer, not your own app you just compiled from source.
You're making a paradigm for like 0.3% of computing. Compatibility with the other 99.7% is the only way it survives long enough to see application developers think about it in a few years. And the historic stuff will never adapt, because those devs are gone.
As someone who is making an application that can have multiple windows, I'm really hoping that this, or something like it, gets approved as a protocol. I need at the very least a position system local to the application to make what I want. Other than a couple of bugs, it's the only reason I still use X11.
Same. I don't even need to be able to place them at specific locations, just a way to query where my window is so certain interactions can work correctly. (such as docking)
@@bluesillybeard I think the fact that this hasn't been implemented as a most basic feature (like so many others) in Wayland is just insane. I don't buy their argument of security, and not only in this case.
@@stephanhuebner4931 Agreed. Honestly I wouldn't be surprised if another X11 successor shows up just because of Wayland's incompetence at making an actual product.
Add a 1x1 "master" window at top-left and global positioning is relative to that
I like that third option. These are all just hints that can be ignored if it's not relevant to the particular environment, but in the vast majority of environments for most users, it seems like it'll be useful.
We will continue to propose new protocols until moral improves! Good Luck Matias :)
I remember having a tiling option in the early days of the Mac, and I miss it, but those were not multiple windows from a single app. In general, it seems to me that modern apps either don't do multi-window in a way that would use tiling to an advantage, or they use tabs. The only exception I can think of is Gimp. Maybe some other CAD and drawing tools do it?
Tbf, multi-window was the main thing that made it difficult for me to learn GIMP, so when I tried it again after five years, I was pleasantly surprised to find the new one-window modal was the default.
But yeah there are a ton of use-cases for multi-window applications, especially if you have multiple monitors, from nonlinear video editors, CAD software (as you say), IDEs, and basically any application where you want a persistent "preview" pane separate from your primary editor or command console.
It's absolutely relatively absolutely relatively absolutely...
GNOME devs have been summoned
Vague security arguments, paranoid-level approach are a big pain point of Wayland, combined with glacier pace of implementing protocols. That's main reason why Wayland is not taking linux by storm now.
Great time to squeeze in PRs is when the maintainers are being judged for performance and any PR approvals count towards their goals. I had six go through on a Microsoft open source project in two weeks when 4 different managers were within a handful of points.
11:35 This one I don't get. Can't the design just use signed coordinates? That way, the origin can just stay where it is in screen space and the coordinates of unmoved windows in the workspace remain unchanged. In other words, the origin is just an anchor for the workspace recording its "offset" in screen space.
As mentioned, this would require the ability to resize workspaces (or at least request resizes), which are now more like bounding boxes changing corner coordinates. But I don't get the security concerns. This is similar in nature to virtual memory allocation, which (barring minor improvements) has worked well to isolate applications for decades.
The problem here is, as @Linuxdirk stated, there is an easy and "uninteresting" way, which is proven to work, and is widely compatible with current applications, but why do something that was already done, if you can instead do some crazy and hard shit that sounds cool as f*ck? And why I, as a developer, should implement this new way of doing things, instead of asking you to use The Old Way™, even if it means using old software? I mean, I'm working on this cool new feature here, ain't got no time to rewrite my windowses bro... 😋😅
@@maxinne86 I disagree. There is a good reason to discard the old way of doing things, and quickly. Just because the Linux desktop is not a high-priority target for criminal actors (yet), that doesn't mean our display server and compositors should have zero protection against applications stealing sensitive data from each other - something the remaining ecosystem is actually well designed to do. X simply has no security, squandering any and all effort at it elsewhere.
That said, a good solution should be as simple as possible given the desired features (in this case application isolation), and these endless discussions are not helpful in fixing the immediate issues users face.
I've once written a desktop application for windows, that was placing transparent windows on each screen at full size in foreground. the windows stay click-through and transparent until an event occurred. in that case, they would pulse a small outline around each screen, notifying the user about an urgent matter with another popup on their primary screen.
if wayland devs would not give access to dock and sidebar pixels on demand, this would look horrible in wayland.
I'd literally have to patch such a userspace application into the core of wayland to make it work.
this is dumb.
Interesting idea to be able to move windows as a group
"[...] let's gaslight the wayland devs into supporting absolute or global positioning in a way where they don't realize they're being gaslit." Also known as gaslighting. Also they're not gaslighting, they're providing additional options and reframing the supporting argument for the initial concept proposal to make it more convincing. Gaslighting is deceptive behavior specifically intended to make the target doubt their own perception and reason (ie make them think they're going crazy)
I really like this implementation, while it's more complex and most likely more prone to some weird bugs, it's very flexible and fixes problems that existed in the old x11 approach.
I wonder how this will affect double glazed windows
I wonder how this will affect jelly-filled windows
idk why so much discussion about setting an XY coord for an window, every desktop out there does this and applications use this, so, u know, wayland at that point is behind windows 95 feature-wise
I think this is the most over complicated monstrosity I've seen in a while in linux unfortunately
tbh i dont like some badly written apps just spawns at 0,0, especially on my ultra wide monitor. or ignore where i placed them last time.
so window manager picking their position is always good.
but apps always have multiple windows sometimes, even some sites or extensions on the browser creates windows (which sometimes they also randomly spawn at 0,0), this seems like an excellent solution.
it also gets all of the windows as a single app, which is how it should be.
this is not just a solution for wayland, this is how it should be on every window manager and os like windows mac etc.
give freedom and control to user, not the app.
thats why i love fedora silverblue (with bluefin)
This is a big one, hope they add this one or the 1st protocol, Until then Wayland is unusable for my case, its absurd that its this hard to get something this essential in.
It feels like it's getting easier as Wayland becomes default for more users. It was easy for Wayland to say "well behaved apps shouldn't do that" when it was only a relatively small number of developers and early adopters asking for these features, but now that the unwashed masses are using it, it's undeniable that, yes, we really do need screen capture, global shortcuts, screen tearing, absolute window positioning, cursor warping, and always-on-top windows. After 15 years of slow-as-molasses development, the last year feels like a huge shift.
And as much as I hate to admit it, some good things have come out of Wayland's reluctance to accept these features, like support for sandbox engines, so your compositor can let you opt into an app recording your keystrokes in the background.
IIUC, Wayland developers are not sold on the idea of letting clients have as much control as they had on X11, and some of them seemingly think this app design is not correct at all.
Also, take in mind that protocols have lengthy discussion periods because of the devs' intention to have good standards from the get go.
@@lucas7061 And I'm not sold on the idea of Wayland devs telling me what I use is bad. I am perfectly happy using X11 until they get there heads out of there asses. I understand wanting a new system and I want wayland to work out, but most of there "lengthy discussions" boil down to Gnome devs trying there hardest to keep Wayland dysfunctional like there garbage desktop environment.
At the rate Wayland have been going it will be finished way after the head death of the universe.
@@lucas7061who they are to say I am not allowed to start my "firefox --kiosk" fullscreen by setting proper geometry to fit the particular monitor I'm using, without window decorations and no virtual keyboard if my application requires that ?
A dumbing down of the zone thing could be a more verbose thing simply titled, "available area" where compositors report a maximum "safe area" to place windows. The assumption would be that its basically a complete monitor that has no things covering it (like launchers, status bar things, docks, etc.)
What is the reason for not wanting a global coordinate positioning?
Are they trying to reinvent the wheel just for the sake of reinventing it?
If they want apps to be tiled, fine. But let the app decide if it wants tiled or not. If it doesn't want to be tiled give it this new workspace of sorts. If it can be tiled give her a fixed tiling workspace. This can depend on a user setting.
P.S. I would call this layout. Different kinds of layouts and each can have a different window area. And eah layout would also need the concept of the main window. And perhaps allow apps and the wm to switch the type of layout as well, where the wm would overrule the app (and the user overrules everything through a user setting: "X layout", "Y layout", "Per app default").
I feel like I awe an apology for getting angry at the stalling on this one lol. Still stand by the general statement of "Wayland can be is too focused on the vision to the detriment of users" but this time it worked out, That actually looks like a better way to do it.
my main concern is about apps with propriety/custme tooling. Every aspect a company needs to consider when porting is less companies deciding to put in the work. My gut reaction says to put in the first protocol as a backup, but if they'll do that no one will opt into the new one plus having a redundancy might cause problems plus its added code burden, so that's not really an option....
I think a better way to frame it is Wayland is too focused on perfection, we'll get something practical in the end but who cares how long that takes
@@BrodieRobertson Yeah, that's way better. Problem is with Xorg's clock ticking that's not really the time to do that😅 Wayland is a rare project (afaik) where its prime time is decided for it rather than by it, so it needs to be ready at the very least for every professional usecase. If that won't be the case... Eehhh it might be my pessimistic brain but I don't feel like companies will be as patient with it
Changing the setting to make gimp render to a single window, is the first thing I do in gimp
I wonder if the issue about having to move all the windows, is much a problem: if the workspace didn't start at 0, 0 by default, but started at some bigger numbers and the window moved left, they could move the left of the workspace.
Brodie I'd take some issue with your characterisation of multi-window applications being "weird" or "cheap" or "cobbled together". Certainly it's not the paradigm for full-screen games or phone applications. But in technical domains the software can be super-expensive because there a few people sufficiently expert to write or maintain them, and usually they're a component in a broader workflow that can be very industry or project specific. So the fact that Wayland doesn't properly support this sort of usage is a good reason for me to keep ignoring Wayland until it's more mature. Don't get me wrong, Wayland might (or might not) be prime-time-ready for mainstream consumer applications, that's great. But it's not for me or my day to day work.
my wayland ambassador
The workspace is technically just windows anchoring point, so could just call it as window anchor. Called the same in many other things with same functionality.
Window anchor or virtual coordinates seem good for me
I can't see this making sense on tiling WMs so you may as well do absolute coordinates and just not implement it in those
Thus reminds me of plan9 where you can run the window manager inside a window in the window manager
Hi. I just run the update manager in my LinuxMint MATE after having been away for a week. And I noticed that there where Wayland packages in it. As well as kernel 5.15. ...91 and a number of other stuff. Is this new? I have another (non production) system on which I'm going to try my installed programs for compatibility.
I run 3 vertical monitors & want to be able to toggle between a mode that treats all 3 monitors as one large display. If anyones aware of a workaround please do let me know. Ocarina of Time in "12k" would be pretty sweet.
Isn't that the normal mode of X11 now?
THis seems the windows 3.1 or java AWT approach of doing it.... so it has some previous experiences to the same issue.
The case of java AWT, is almost identical to wayland. It had to maintain control of it's frames, so couldn't let X to do it. They end up with the same workspace schema. Although a lot more rigid and totally opaque to X appart of being able to convert an internal window to an external one.
Funny you should mention that. People ended up bringing up the idea of "modernizing" multi-window apps by wrapping them in a sub-compositor in the xdg-placement proposal and I pointed out how people hated MDI in Windows 3.1 enough that one of the selling points of Norton Desktop for Windows was reinventing Program Manager and File Manager to break their windows out of their MDI prisons so they could properly participate in a user-controlled stacking order.
Sounds like a good abstraction
Wayland missing core functionality that have been in GUI systems for 2 decades now. I'm shocked, SHOCKED!!!!
My 6 monitors together look like the Android logo. I'm not sure any of these solutions work for me because it's not a square more like a cross with two legs, and all my monitors are different sizes and resolutions. Or did I not understand how these solutions work?
For xdg-placement-protocol, you summarize it at one point as "a stacking window manager inside your existing window manager", which makes me think: At that point, do you really need this to be a protocol? Wouldn't it be *way* simpler to just do exactly that... and run a lightweight nested stacking compositor? The only problem that is immediately obvious to me is that you don't have the "trust" functionality from this proposal. Sciency apps work just fine, but now the shared secret is WAYLAND_DISPLAY=wayland-1, which isn't as secure as a compositor-owned handle
As long as this doesn't screw up auto-hiding the task bar then I don't care. I still can't daily drive Wayland, and the last update I did for KDE screwed up several things too. Hopefully the next update I do the KDE devs will have fixed those issues, and supposedly they're adding back flip switch, but I'd love to know what they did that new windows keep trying to overlap each other. I hope this isn't because everyone is prioritizing Wayland and kicking X to the curb, but I also probably won't update until they've fixed all the issues that prevent me from daily driving Wayland anyhow.
Still not ready.......
yesterday, my linux mint gets a "curious" update that says XWAYLAND. i decide to go for it(i didnt request for any "upgrade" to wayland) after the installation and reboot, i cant find any "wayland" anywhere, not in "top" processes in terminal, not in resource monitor, not in system info nothing. somebody has been fooling around with me.
Multi-window applications are everywhere. Dunno how the hell they think it's something "niche".
"Everyone but gnome seems to do a good job handling this this so... just dont use gnome"
All things considered if more people realized this for far more than just this wierd niche issue linux would probably be in a much better state. Gnome just sucks.
GNOME isn't a completely terrible project and of the devs I've spoken to personally they've all been great people but especially with how Wayland is handled I can understand that stance
Fr feels like at times they are just against every productive feature it shy im never going back to gnome hoping system 76 cosmic can make the gnome desktop but without all the bs
This is awesome. I am glad this has been proposed. It seems to solve a lot of problems. Would be great to have it be X Y Z since there are so many possibilities in the future regarding 3D and VR, but I guess those compositors will be able to layer that on top
Z axis shouldn't be paid attention to by conventional windowing systems, though if Wayland works out well enough it could be a reasonable inspiration for a 3d system.
@@absalomdraconis Traditional windowing systems could use z as simply indicating stacking order.
Honestly, I think its good that there has been some iteration on the window placement situation. IMO there needs to be some way to give an app multiple placement contexts for windows and there needs to be some sort of hinting for window managers.
The window manager paradigm is sufficiently different that I think it makes sense to by default just let apps "tile themselves" within a window-managed placement context, and then somebody can contribute PRs that add some simple, standardized, and declarative per-window placement hints to make the application work better on their window manager of choice.
I care that shit seems to just open wherever the fuck it wants in ways that don't make sense. Why do I even set a main monitor? Nothing seems to acknowledge that. (Fedora 39 by the way)
I really like the idea of being able to move all gimp windows in unison
Then why not just use the single windowed mode at that point
@@tux_the_astronaut This does not work if I wanna put one window in one monitor. Example, Streaming. You need to separate monitors for chat, game, stream settings etc.
Any reason why there can't be layers? Let workspaces overlap. When they overlap they will be each on different layer. Give user control over switching between layers.
the redhat / gnome people reek of the lennart poettering / systemd syndrome...
Ghidra suffers from this too.
This is more sane...
The knowing of where a window can be a information leak...
I still do not think windows should know where their exact coordisates, but I think this is more sane. Just slap a boarer and a around the "workspace" and treat it like a window i _do not like_ the automatic re-sizing, though.
I think a special command could be used to spawn the workspace and specify geometry, and placement:
wl-spawn-workspace -w 800 -h 600 -p TOP-LEFT --command foobarapp
So the workspace would just be like a client to the compositor, but inside apps can known their coordisates if and only if it is in such a workspace.
Nor quite like a client (I assume you mean a single-window client), because raising one of the windows in the workspace in general should not raise all the windows in the workspace. Otherwise, what would be the point in multiple windows in the first place?
@@__christopher__
This avoids the problems with multiple window apps all together.
It would basically be like a nested Wayland session, but with special properties, that the compositor can take care of, either by directly compositing them, or by spawning a nested session with special properties.
@@GegoXaren But the whole *point* of a multi-windowed application is that it doesn't behave like a single window. It's like "solving" the problem of traffic jams by just disabling cars from entering the road.
Just some other applications the needs this: Blender and game engines using the Imgui lib
I think that the whole idea of limiting the applications' window placement is wrong. If you have a malicious app then it's a little too late to try to block it's behaviour. If all the apps are good then there's nothing wrong if they want to place their windows anywhere they want.
In case of multi-monitor config I can see a lot of troubles. A single app can be allowed to use multiple monitors but decides to create a large single window. Sometimes it's a good idea, sometimes it's a terribly wrong idea. And sometimes I want to enlarge a window so it takes multiple monitors and then shrink it back to a single monitor.
I think Wayland has a lot of wrong whole ideas.
It should be called a placemat. As you mentioned, workspace has other meanings.
so... basically virtual monitor but for multi window apps?
Edit: I propose the name appscope
Effectively yes
I don't understand, whats the problem with absolute coordinates anyway?
The Wayland dev logic is maybe there's a better way. Wayland is also intended for non standard interfaces like a VR desktop where absolute coordinates wouldn't work
Allowing application windows to query their absolute position can leak information from the environment and possibly other applications, which is a _biiig_ security vulnerability. And one that is impossible to prevent in X by design.
It's all fun and games to ignore such issues until some application tiled with your browser calculates and records a precise history of your browers' canvas size, uniquely identifying it within a few resizes and precisely tracking your every move on the web. Hope you have nothing to hide 🙂
@@Paulolz22 not really because you can't query the location of other apps so you can work out how many monitors exist, how big they are and where you're placed and minus the final point all of that is already visible outside of this. The browser concern isn't a concern of the compositor as you can already do that style of finger printing without this
@@BrodieRobertson Of course browser trackers already fingerprint your browser by precisely recording your canvas size history, and this is the issue: now they can observe parts of your system _outside_ your browser, badly breaking application isolation.
Say you have a screen width of width X with a browser and a spy application tiled next to each other. As a web tracker, you know the browser's canvas size Y(t), so you can deduce that the application window width across time is Z(t) = X - Y(t). In other words, the size changes of both applications are identical and opposite.
You now know information about another application you were never supposed to know. Even worse, if you are the vendor of both the tracker and that application (common for big corps like Google, MS, etc.), you know both instances and their account info are associated with the same person.
@Paulolz22 if you assume every window manager has the same layout
The longer I see this whole security madness with Wayland, the more I want to stay on X. I get the security is important, but ffs this is paranoiac point of view. Security is not an excuse to not implement basic feature. If they really want to secure their display server, just get rid of displaying anything whatsoever. User is main weak point anyway. X would be long gone and we all would be running Wayland now if devs didn't for years look for ways of implementing basic and *possibly* insecure features in a way that is still maybe insecure but now definitely not basic
GNOME world is something else...
I really didn´t know Wayland still was in a conceptual delta version still. Now I really want to know the logic behind "we must kill X11", that some distro´s seems to be thinking. It can´t be security. OpenBSD fixed that years ago with Xenocara. I mean, this Wayland stuff is clearly killing off the last hope for the concept of "the year of the Linux desktop".
At this rate, we will have big problems in just a few years. So enjoy your Chromebook, Mac or Windows when the Linux desktop era has imploded.
Wayland needs to fix basic stuff that people is used to since decades before even calling it alpha.
If we had a good user interface for applications requiring certain Wayland extensions, I didn't see the problem with just making the original proposal a Wayland extension.
It obviously doesn't make sense on smartphone shells like SailfishOS (who were among the first systems with proper Wayland support), and if COSMIC or Gnome decided to not implement the extension, software stores could just display a message like "This application does not support your kindergarten DE, get a proper one".
Users of scientific applications would have to use KDE or XFCE, or Gnome/Cosmic could decide to support these applications, or they could ship a wrapper that wraps the multi windows in one parent window (someone would need to implement an easy to set up general solution) to support all DEs, this would technically even work on smartphones or tablets.
I am very curious where this gnomes…
please please be accepted this time 🙏🙏🙏
I think the second protocol made the most sense. As a user, I want my apps to open in the middle of the screen, and that's what I set mutter to do. If an app wants to have multiple windows, I want those to be placed surrounding the main window that is centered on the screen.
The first and third protocol doesn't make this possible. The apps could just choose to place themselves wherever they want. On Xorg and XWayland, apps like Steam's updater appear in the deadcenter of my two screens, below the the monitor bezels. That's plain broken behavior. It's better that the compositor has control over window placements so stuff like that doesn't happen.
Applications being able to place their subwindows at arbitrary locations is the entire point, though.
@@CptJistuce The first protocol would allow apps to arbitrarily place the main window, ignoring my preference. And by the sounds of it, so does the third protocol.
It seems like only the second protocol guarantees that the main window will be placed according to my preference, while also allowing its sub windows to be placed around the main window.
@@that_leaflet But the users of these multi-window applications don't want that behavior.
I want my windows opening with the layout intended by the developer, at least on the first run, as it hints at the intended way to use them. After first run, I want it to open according to where it was when I closed the application before... Is it that hard?
I do feel obliged to clarify my stance. As a general rule, I actively hate multiwindow applications and do my best to avoid using them. But the people using them have little alternative, and the desired use pattern for those programs is for the various subwindows to show up at specific screen locations every time.
Kinda reminds me of Gamescope.
Gamescope is a Wayland compositor, but I'm confused about the comparison
Gazulighting wayland devs
The silence on Red Hats DEI controversy is deafening among the linux community.
What does this have to do with this new Wayland protocol proposal?
@@MarquisKurt Nothing at all. I just find it interesting that none of the Linux podcasters are talking about it. Kinda strange don't you think?
Are you implying that Red Hat is paying everyone? If so I didn't get my cheque yet
@@BrodieRobertson No. I'm not implying that Red Hat is paying anyone. I think the fear of talking about a controversial topic is enough to keep people silent. I also want to be clear that I'm not picking on you Brodie. I really think you're a good guy and I know you wouldn't take a cheque if one was offered. I just want people in your position to speak up when an injustice is occurring within their community.
@@donanderson6727 I can't speak for anyone else but I got burnt out on discussing the decay of American culture over 5 years ago, I'll just go hang out with normal people
Sadly running xorg because Nvidia crap.. Hopefully they can get SOMETHING thro
So X11 Screen per application basically 😂
Yeah that's a good way to look at it