[HN Gopher] Wine Wayland Driver
___________________________________________________________________
Wine Wayland Driver
Author : rom-antics
Score : 138 points
Date : 2023-02-25 15:23 UTC (7 hours ago)
(HTM) web link (gitlab.winehq.org)
(TXT) w3m dump (gitlab.winehq.org)
| mouse_ wrote:
| Neat, good seeing progress on this front.
|
| Many Windows applications since Windows 7 support fractional
| scaling natively (125%, 150%). Is there any way of accessing
| these modes with WINE? Is this really the same thing as simply
| setting the font DPI scale (which is what the WINE docs suggest
| doing)?
| kaba0 wrote:
| I am not knowledgeable on the low level details of Wine, or
| windows gui apis, but this might actually become properly
| working on the Wayland backend, as it has a scaling property.
| jchw wrote:
| I've been running these patches to play around with them and it
| seems pretty good; layered windows (WS_EX_LAYERED) work great,
| and the issue you would have with non-reparenting X11/XWayland
| WMs (mostly the mouse cursor being offset) is gone. There's still
| some minor quirks remaining, so it's not perfect, but a complex
| program like FL Studio seems to work just fine, as does some
| games using Wined3d.
|
| The only thing I really hit that would be nice to fix is that it
| appears tablet support isn't in yet, or at least it didn't work
| for me. Of course, tablet support is a thing I generally wish
| could be improved in Wine, especially because Windows apps are
| slowly moving towards more modern APIs than the old wintab32
| defacto standard.
| sprash wrote:
| Since this isn't a community effort at all but purely done by a
| consultant agency called Collabora my question would be, who is
| funding them?
| CameronNemo wrote:
| Always the question when it comes to Collabora work... they
| don't often tell.
| jacooper wrote:
| It should be companies interested in this
| ahartmetz wrote:
| Valve seems like an obvious candidate. They fund a lot of
| Wine work and AFAIU, because they use KDE/Plasma on the Steam
| Deck, they also fund certain developments in KDE including
| (that part is a guess) Wayland support.
| j16sdiz wrote:
| Collabora ports windows game to linux. They created SteamOS for
| Valve.
| sprash wrote:
| > Collabora ports windows game to linux.
|
| Not according to their references.
|
| > They created SteamOS for Valve.
|
| Obviously not. They created some parts of the update system
| for SteamOS 3.0.
| wheelerof4te wrote:
| We are still fixing stuff in Wayland, stuff that Microsoft and
| Apple had figured out 20 years ago.
|
| So defeating.
| ElectricalUnion wrote:
| > We are still fixing stuff in Wayland, stuff that Microsoft
| and Apple had figured out 20 years ago.
|
| I don't know, given that the UX situation in Windows UI -
| itself a inconsistent disaster that makes the disjointed things
| that make up KDE looks like a consistent desktop experience.
| They can't decide what UI framework to keep supporting, they
| keep changing what you're supposed to use to build your GUI
| every bunch of years.
|
| As for the Apple side, well, destroying everything every few
| years with almost no regards for backwards compatibility isn't
| "figured out 20 years ago".
| [deleted]
| client4 wrote:
| And Microsoft figuring out how to make Windows even worse with
| every new day!
| wheelerof4te wrote:
| Indeed, but Microsoft knows how to make a OS graphics base
| and stick with it.
|
| MS does a lot of things wrong, but backwards compatibility is
| still their strong point.
| paulryanrogers wrote:
| Yet Microsoft makes so many of them. I'm not even sure what
| the current recommended way is anymore.
| kaba0 wrote:
| Like what? At least be specific.
| wheelerof4te wrote:
| Like screen recording. Popular Wayland native apps not
| dependant on Xorg. Wine working on Wayland.
|
| Tangible benefits of switching to Wayland. And by those, I
| don't mean "no screen tearing", since it practically did not
| exist on most desktop environments with half-decent
| compositors.
| edent wrote:
| I run Wayland using PopOS. I can record screens and run
| WINE apps. I have a cheap laptop and it works just fine.
|
| Wayland means - for me - no fiddling with text files if I
| want an external monitor, roatated, with a weird
| resolution.
| kaba0 wrote:
| Screen recording works, even with OBS studio. What popular
| wayland native app is dependent on xorg?
|
| > half-decent compositors.
|
| At which point there was no point of X11 middle-maning
| between the compositor and apps -> tada Wayland it is.
|
| Also, screen tearing is a bigger issue on bigger resolution
| higher refresh rate monitors, hardware just grew up to
| 1080@60fps.
| justin_ wrote:
| Weirdly, I was just thinking about this earlier today. Years ago,
| Wine developers basically refused to add Wayland support. They
| told the Wayland devs that they'd stick with X11 and XWayland.
| Why? Because X11 and Win32 specify position windows in absolute
| screen coordinates, whereas Wayland positions windows relative to
| their parents. This broke some assumptions across the Wine
| project about positioning windows, and it didn't seem worth it to
| fix[0][1]. (And there may have been other issues. I'm not an
| expert).
|
| Even when the driver was being developed around 2021, it seems
| like the Wine developers only begrudgingly accepted it[2].
|
| Exciting to see this finally hitting upstream. Progress in
| desktop Linux often seems slow, but things are moving forward.
|
| [0] https://bugs.winehq.org/show_bug.cgi?id=42284#c1
|
| [1] https://news.ycombinator.com/item?id=19127952
|
| [2] https://www.phoronix.com/news/Wine-Julliard-Wayland-2021
| j16sdiz wrote:
| Many of those restriction in wayland were by design. Lots of
| simple task is seen as privileged and restricted to the window
| manager. These restriction may (or may not) make sense for
| native wayland application.
|
| However, for wine, as a compatible layer with windows, every
| deviation from windows behavior is seen as a missing feature.
|
| I am not sure if constantly creating artificial restriction and
| working around them is "moving forward".
| vlovich123 wrote:
| If the restriction is about improving real security issues
| and people are doing that work for free, then isn't it worth
| it? In fact, if I were an open-source project myself and
| someone is willing to go through the legwork of supporting
| doing the migration of my codebase to a newer piece of tech,
| I should be encouraging it and the only thing I get to
| enforce is quality for it being a default and no substantial
| regressions when not using that new tech (or I can accept
| some regressions if I think the value provided is better). So
| if XWayland is better then fine. But someone has to keep
| putting maintenance resources into it. The Wayland folks
| shouldn't be putting any resources into it when they think
| they've reasonably addressed any real technical blockers and
| then they should ask for the distro maintainers to remove it
| because they don't want to maintain it anymore. The distro
| owners can donate maintenance cycles or $$ if XWayland is a
| sufficient experience in terms of providing the perf, DX and
| security that projects they care about need. Cooler projects
| with more attention will naturally obtain more dev cycles
| from talented engineers anyway.
| sprash wrote:
| The work is not done for free. It is done by consultant
| agencies like Collabora with full time paid developers. It
| is just unclear who funds them.
|
| And no, it's not worth it. The amount of regressions are
| high compared to the rather questionable security benefits.
| jchw wrote:
| I don't think the Wine developers were simply being hostile due
| to a dislike of the concept, I also agree that a Wine Wayland
| driver seems weird. And yet, here we are: when I use it, it
| seems to work almost exactly like you'd hope. I'm not sure if
| the reason this has changed is because there are new standard
| Wayland protocols that help with some of these issues, or if
| they just came up with clever workarounds (like always
| anchoring new windows to be relatively positioned or
| something.) Either way, it works.
|
| I have heard there are still some tricky impedance mismatches
| though. I have no idea what they're doing for the system tray,
| for example. Right now, if I cause a tray icon to exist in Wine
| with Wayland patches on SwayWM, what happens is I get a "Wine
| System Tray" window. Not ideal to be sure.
| subarctic wrote:
| can someone explain what is going on here? i know what wine is,
| it's a thing that lets you play windows games on linux or macos,
| but what is wayland?
| Topgamer7 wrote:
| Linux gui applications historically have used X11 for desktop
| window management (think how your windows layer on top of each
| other).
|
| Wayland is a new ecosystem that aims to take over for X11 (as
| X11 was developed in mind with a lot of functionality that many
| do not care about, and just want a desktop environment).
|
| But it's a controversial effort, and Wayland still doesn't
| support a lot of the functionality even from the desktop
| perspective.
|
| Wine is not something that lets you (just) play games, it is
| effectively a re-implementation of windows low level apis, on
| top of linux. It lets you call the dlls, and kernel functions,
| effectively running windows applications in linux.
|
| The wine community is opinionated, and effectively weren't
| going to support Wayland; because it has some shortcomings in
| terms of api surface or ways that wayland handles things.
|
| Someone decided to try to support wayland anyway.
| kaba0 wrote:
| > X11 for desktop window management (think how your windows
| layer on top of each other)
|
| That's not really the primary job of these protocols - they
| are primarily about interfacing with GUI apps and displaying
| their content -- compositing those contents on top of each
| other in one way or another is the job of a window manager,
| which can be in-built, or separate from the display server.
|
| > Wayland still doesn't support a lot of the functionality
| even from the desktop perspective
|
| This has been less and less true. Plenty, or even most
| distros ship with wayland by default and people don't even
| realize it. Under gnome which is arguably the most complete
| implementation I really have a hard time listing things that
| don't work.
| rjzzleep wrote:
| Funny, I was literally just looking at this issue today. I
| switched to wayland a few weeks ago, just because it seems to
| save a lot of battery power. But so much basic functionality is
| still broken it's infuriating. And then so many things seem to
| follow the "unix functionality" and as a result they're half
| baked tools that aren't really working properly IMHO.
|
| A lot of these issues have fixes or workarounds directly in KDE.
|
| For reference I'm using sway. swayidle is an idle daemon, where
| the maintainer doesn't think that it matters whether its
| connected to power or not. You're supposed to create your own
| scripts around it that handles ac connect and disconnects.
|
| There's a tool to do flux like color warmth setting. One of them
| doesn't allow you to toggle, so you have create your own toggle
| script that kills or restarts it. The other one is controllable,
| but doesn't actually account for time or timezone.
|
| XWayland has had 2 or 3 patches to handle hidpi when the main
| wayland screen has fractional scaling, none of them are merged
| and they seem hardly active. KDE works around that by allowing
| you to turn it off for xwayland clients. Sway just passes it down
| and blurs everything.
|
| When I exit a wayland session and then restart it the screen
| locks up. This doesn't happen with normal X.
|
| And then there is electron. Slack is not the only app that
| ignores electron settings and doesn't run with wayland support.
| In chrome and electron it's supposedly supported but you have to
| toggle it yourself? What is this madness?
|
| These things seem like basic functionality for me. I don't really
| get it. Sure, maybe I shouldn't expect a proper experience for
| random sway tools, so that makes the first two points irrelevant.
| But the fact that years in they still haven't found a proper
| solution on passing down hidpi for xwayland? That's
| incomprehensible for me.
| cycomanic wrote:
| If you want full desktop integration why are you using sway.
| Most of the functionality you're talking about requires writing
| scripts if you used i3 or awesome WM on X11 as well so has
| nothing to do with wayland.
|
| Regarding exiting and restarting a wayland session, how do you
| do it? GDM, the console? It obviously works for most other
| people so it seems you're encountering a bug related to your
| hardware or setup so you could file a bug report with the
| appropriate project (again doesn't really seem like a wayland
| issue though).
| vorpalhex wrote:
| It's just early. It's fast to make little scripts and glue it
| together yourself, and until folks really enumerate use cases
| and build to meet them, it's going to feel unfinished. It takes
| years to build out a big project like this.
|
| If you want "just works", stick to X and a mature desktop
| environment like KDE or Gnome for now (especially if you do any
| gaming).
| hedora wrote:
| > _It 's just early._
|
| Have we hit the two decade mark yet?
|
| This stuff "just worked" in the late 90's (and probably
| earlier, assuming access to unix workstation hardware) with
| X11, when it was roughly the age Wayland is now.
| vorpalhex wrote:
| I have two displays on my computer, one is 4k and the other
| is 1080p. One has HDR. One is 400 nits brightness, the
| other is not. Games are built across several engines with
| an amazing collection of rendering technologies. We have
| apps that embedded web browsers.
|
| I'm sure if you restricted yourself to strictly first party
| native applications and a single display within one or two
| resolutions and no DPI scaling, Wayland probably meets most
| of your needs now.
| ComputerGuru wrote:
| This is the problem with making a wholesale rewrite and not
| including good (and complete!) backwards compatibility for
| the duration of the transition.
| kaba0 wrote:
| What's not good and incomplete about xwayland?
| kelnos wrote:
| XWayland doesn't really help you with things that are
| part of the desktop environment. You can't run a desktop
| background/icons manager or a dock/panel in XWayland, as
| it won't have access to the kind of information it needs
| to implement all its features.
| Shish2k wrote:
| > This stuff "just worked" in the late 90's
|
| I see you have repressed the memories of editing modelines
| in xfree86.conf :P
| hedora wrote:
| That's not something the comment I was responding to
| mentioned.
|
| Besides, the anti-aliasing on the type 1 fonts would have
| been glorious whether or not the capacitors in the back
| of the monitor started smoking.
| uberduper wrote:
| I had a very different '90s than you did, it seems.
| CameronNemo wrote:
| _The other one is controllable, but doesn 't actually account
| for time or timezone._
|
| Alright first off: file a bug! How am I supposed to know there
| is a user with a problem, if they don't tell me!
|
| That said not sure what you mean by this exactly... gammastep
| 100% does account for the local time. But it does choose the
| time of day to transition based on the location. Are you in a
| different location than your timezone is set to?
| cbushko wrote:
| Please help the community and make sure that these issues are
| documented in Github/whatever issue tracker.
|
| Or if you have the skills please contribute back and fixes
| these things that bug you!
| Arnavion wrote:
| >For reference I'm using sway. swayidle is an idle daemon,
| where the maintainer doesn't think that it matters whether its
| connected to power or not. You're supposed to create your own
| scripts around it that handles ac connect and disconnects.
|
| >One of them doesn't allow you to toggle, so you have create
| your own toggle script that kills or restarts it.
|
| If you're not a fan of making scripts then sway (and wlsunset I
| assume) is not for you. My sway install is held together by a
| myriad of scripts - keybindings are handled by a script,
| starting programs via bemenu goes through a script, sway itself
| is started by a script, etc. That's just how this compositor
| and its ecosystem are designed - they're for people who want
| the software itself to do the smallest possible thing with the
| least possible assumptions so that the user can do whatever
| they want to fill in the rest.
| ComputerGuru wrote:
| The problem isn't that it's held together by individual
| scripts and apps that one can replace or hack at. The problem
| is that none of these pieces ship in place.
|
| Ideally you'd have some sort of offering that gives you a
| reasonable starting place with all these composable pieces in
| place, and then you can hack/replace/add/remove as needed.
|
| Everyone starting from scratch doesn't make sense. It's like
| shipping a Unix system with no app doing it's own paging
| because the devs rightly expect you to use some other tool to
| page output for you, but there's no less/more installed (and
| no back buffer in the terminal or terminal emulator to boot).
| Then you complain and the answer is that you're supposed to
| write your own (or research, download, compile, and install
| something someone else might have hacked up).
| lapinot wrote:
| > The problem is that none of these pieces ship in place.
|
| Sway is not a desktop environment. What you are describing
| is a desktop environment. I too would like a sway-based
| desktop environment. Let's stop complaining that sway is
| not what it is or that somehow this is related to wayland.
| This whole thing is just a consequence that writing
| cohesive graphical/desktop software is tedious and that
| tinkerers cannot rely on the myriad of Xorg desktop
| environment, in particular the modular ones like lxde/xfce
| to mix and match components.
|
| > Then you complain and the answer is that you're supposed
| to write your own
|
| Yes, obviously. No-one is saying this would be a bad
| project. And if you blatantly misunderstand their project's
| scope it's no wonder you're getting dry responses.
| ComputerGuru wrote:
| I am not saying sway isn't allowed to do what they did.
| But the normal approach is for the 1st party dev to also
| provide reference implementations of
| supporting/complementing utilities to smooth adoption.
|
| No one is saying they have to be shipped as part of the
| compositor, obviously.
| kelnos wrote:
| > _But the normal approach..._
|
| Says who? You're getting software for free, from someone
| who is not beholden to you for anything. Either you
| accept it as it is, or you fix it; that's the nature of
| open source. Whining about it on the internet is rude and
| disrespectful.
|
| If you can't be bothered, and want all this stuff
| included, or at the very least recommended or installed
| automatically on the side, switch to something else that
| does that for you.
|
| The alternative to taking a piece of open source as-is
| isn't "complain to the maintainer until they fulfill your
| wishes". That kind of thing is why open source
| maintainers burn out. You are not entitled to anything
| from them; the alternative is that the software doesn't
| exist at all.
| ElectricalUnion wrote:
| I don't see how being "just a compositor" has to do
| anything to "has to bundle complementing utilities",
| without mucking the whole thing and turning it into a
| desktop environment.
|
| Thought I agree that for most people, a desktop
| environment, "everything integrated, just change this
| specific thing" instead of "let me just DIY my entire
| environment from those separated parts" makes more sense.
| falseassertions wrote:
| [dead]
| uberduper wrote:
| afaik there are various distros that will give you a
| preconfigured out of the box swaywm based desktop env.
| Garuda linux comes to mind.
|
| The sway wiki is pretty detailed and iirc has a helpful
| page full of options for various "not the compositor's job"
| tasks like notification daemon, app launcher, etc.
| kaba0 wrote:
| > And then there is electron. Slack is not the only app that
| ignores electron settings and doesn't run with wayland support
|
| I wouldn't be surprised if slack just ships with a much older
| chrome build that wasn't built with wayland support.
|
| Also, have a look at Gnome's wayland offering. It is by far the
| most complete as of yet.
| smaddock wrote:
| Slack tracks close to the latest releases of Electron.
| Election also tracks close to the latest Chromium releases
| [0].
|
| [0] https://releases.electronjs.org
| gigatexal wrote:
| scripting around hobby projects to fit your needs is the hacker
| ethos/mindset/what makes using linux/unix fun. But give the
| ecosystem time and Sway and its ecosystem will be just as good
| as X and i3 is.
| falseassertions wrote:
| [dead]
| nextaccountic wrote:
| > For reference I'm using sway. swayidle is an idle daemon,
| where the maintainer doesn't think that it matters whether its
| connected to power or not. You're supposed to create your own
| scripts around it that handles ac connect and disconnects.
|
| > There's a tool to do flux like color warmth setting. One of
| them doesn't allow you to toggle, so you have create your own
| toggle script that kills or restarts it. The other one is
| controllable, but doesn't actually account for time or
| timezone.
|
| I used to write little tools like his and my ~/bin is still
| littered with scripts from 10 years ago
|
| Nowadays I want this functionality to work by default and I
| won't settle for a less usable system
| jchw wrote:
| The reason why Chrome and Electron still need a flag is simple:
| Chrome still has a decent chunk of work to do before Wayland is
| supported to the same degree as X11. They had a lot of false
| starts: it took years before Wayland support actually got
| upstreamed in any regard. Likewise for Electron. It does
| generally work to the point of daily-driver usability today
| with stable Chrome and Electron, but some apps are shipping old
| and out-of-support versions of Electron, so unfortunately it
| has become a bit of a waiting game.
|
| Anyways, you can't actually do proper DPI virtualization for
| X11 apps because afaik there is no protocol for apps to
| communicate the scale that they are actually rendering at, so
| there will _never_ be full support for mixed or fractional DPI
| in XWayland to the same degree that it is supported in Wayland.
| I 'm not 100% sure there would be a point to making such a
| protocol at this point, since blurry-but-correct surfaces seems
| like an OK trade-off to keep things working in the long term.
| If you run real X11 with mixed DPI or fractional DPI, you get
| quite a range of potential failure cases depending on what apps
| you run.
|
| At this point most of my screen is filled with native Wayland
| apps, and Electron apps that use reasonably up-to-date Electron
| (like VS Code), so it's rare to see a blurry window.
| yjftsjthsd-h wrote:
| > Chrome still has a decent chunk of work to do before
| Wayland is supported to the same degree as X11.
|
| I'm not doubting you, but given that ChromeOS uses Wayland
| I'm very confused by this.
| Karellen wrote:
| I'm not familiar with the situation, but my guess would be
| that ChromeOS has created its own Wayland compositor with a
| bunch of private protocol extensions that Chrome on
| ChromeOS uses to get stuff done. But for some reason or
| another, those protocol extensions are not suitable for
| submitting as new public extensions for other compositors
| to implement. Or they are suitable for submission, but the
| official extension roadmap already has different extensions
| in the works (but not yet complete) that will do the same
| thing.
| jchw wrote:
| Yep, ChromeOS basically has Chrome itself as the
| compositor, so it doesn't have to worry about running
| "under" Wayland at all.
|
| Take a look at the "blocked on" to see the kinds of
| things still remaining:
|
| https://bugs.chromium.org/p/chromium/issues/detail?id=578
| 890
| Jasper_ wrote:
| ChromeOS uses Wayland as a bridge between Android and
| Chrome because it's a politically neutral technology
| neither of them control, and thus can both agree on
| implementing. It's not about integrating better with other
| Wayland compositors or the wider Wayland/Linux ecosystem,
| it's about using Wayland as a piece of technology to sling
| buffers back and forth between two different camps who are
| otherwise on bad terms.
|
| ChromeOS implements a Wayland compositor to support Android
| apps running as Wayland clients. Chrome being a well-
| behaved Wayland client is something completely different.
| hedora wrote:
| Regarding randomly blurry UIs:
|
| XFree86 (and later, x.org) have always had better support for
| hidpi rendering than MacOS X and Windows (by my definition,
| which is based on the quality of tear-free vector, font and
| bitmap rendering at non-standard DPIs while using mainstream
| hardware).
|
| The wayland developers apparently couldn't figure out how to
| read the X11 manual. Why expect them to reimplement it in a
| superior way?
| ibotty wrote:
| You might want to research who the first wayland developers
| were and are now. You might be surprised. Let's just spoiler,
| that they not only read the X11 manual.
| hedora wrote:
| I know who they were. I don't understand how they could
| screw things up so badly, given their backgrounds in X11
| development.
|
| I can only assume some other part of the team designed
| fractional scaling.
| mijoharas wrote:
| The thing that made me switch to Wayland was having two
| monitors with different DPI, which was unsupported by X.
| p_l wrote:
| IIRC, a big chunk of that was the trend that led to wayland
| causing "effective deprecation" of some more complex
| aspects of X11, like replacing multihead with windows into
| unified frame buffer (which now required single DPI for all
| screens while multihead allowed completely different
| settings)
| ElectricalUnion wrote:
| Intent is one thing, whenever userland GUI developers
| actually uses the API the intended way is another. It's not a
| bug, it's just a undocumented feature.
|
| If everyone uses the API the "wrong way", now you're stuck
| supporting the "wrong way" or everything breaks and people
| WILL complain.
| yjftsjthsd-h wrote:
| > And then so many things seem to follow the "unix
| functionality" and as a result they're half baked tools that
| aren't really working properly IMHO.
|
| I'm going to disagree pretty strongly with that. In fact, I
| think most of its problems are that it threw the Unix
| philosophy out the window. While it's true that it suffers from
| having made everything a implementation detail that can
| theoretically be plugged in with a different component, the
| problem is that they forced everything important to go through
| the compositor, which bottlenecks composiblilty and doesn't
| allow you to actually replace individual components without
| support from the (usually incomplete) monolith in the middle.
| falseassertions wrote:
| [dead]
| kaba0 wrote:
| As opposed to the single, so-huge-that-nvidia-ships-binary-
| blobs-for-it xserver implementation?
| yjftsjthsd-h wrote:
| Yes, actually; the X server was awful, but it was a single
| contained point of awfulness that allowed everything else
| to be trivially interoperable. Breaking that apart could
| have been good except that the way they actually did it
| mixed far too many concerns into the graphical server
| (compositor), so while we have more of them, in practice
| you can't actually mix and match the _rest_ of the system
| anymore.
| kaba0 wrote:
| It is a display protocol, responsible for displaying
| things. A compositor is a must for that, it is not
| additional complexity at all.
|
| What you would want to mix is a window manager, and there
| is no reason why that can't be done with this model (and
| is pretty much what wlroots does).
|
| But I do agree that a cathedral model can have benefits.
| yjftsjthsd-h wrote:
| > It is a display protocol, responsible for displaying
| things. A compositor is a must for that
|
| Er, are we using different meanings? Obviously something
| has to display pixels, but I literally do run X without a
| compositor.
|
| > a window manager, and there is no reason why that can't
| be done with this model (and is pretty much what wlroots
| does).
|
| No, you can't (excepting rootfull xwayland, obviously),
| Wayland forces the display server, compositor, and window
| manager to be a single program. All wlroots does is make
| it easier to write that compositor, it hardly changes the
| model.
| kelnos wrote:
| Not sure what you mean; wlroots still assumes that the
| window manager and compositor is in the same process.
| Wayland itself assumes that those things are also in the
| same process as the display protocol/server.
|
| With X11, if someone wanted to write a window manager,
| they could do that and only that, without having to write
| a compositor or display server. Wlroots certainly
| simplifies those latter two bits, but there's still a lot
| of work to do to use it.
|
| Beyond that, Wayland's mess of extension protocols are
| generally incomplete. I've been working on "porting"
| parts of Xfce to Wayland, and there are a significant
| number of things that just cannot be done at all right
| now without integrating it directly into the compositor
| process. The extension protocols necessary to do even a
| fraction of this table-stakes stuff are often
| experimental or non-standard, and even when they do
| exist, are often missing critical pieces.
|
| As an example: say you want to write a dock-type app that
| only shows the list of toplevel windows present on the
| current workspace (and when you switch workspaces, it'll
| show the windows on the new workspace). Nope, you can't
| do it. The workspace protocol itself has been languishing
| in Freedesktop GitLab[0] for two and a half years, and
| even if that was standardized, it doesn't interact with
| the Foreign Toplevel protocol at all, so you have no idea
| what windows are on which workspaces.
|
| So currently the only solution is: your dock app has to
| live in the same process as the compositor, where it has
| access to all the compositor-specific data around
| workspaces and windows. (Sure, you could build a d-bus
| interface, or something like that, but that would be
| specific to your one compositor... and a d-bus interface
| is the moral equivalent of a Wayland protocol, which is
| what you should be using anyway.)
|
| [0] https://gitlab.freedesktop.org/wayland/wayland-
| protocols/-/m...
| csdvrx wrote:
| This falls right on time for my 2023 "Linux on the desktop"
| attempt! (now I wish https://github.com/phil294/AHK_X11 had a
| Wayland option...)
|
| I can't live without Office! My personal favorite is 2010 x64, as
| Word then starts faster than the current Wordpad.
|
| Office 2010 works great in Windows 11, but there've been some
| suspicious move making me believe old office version will be
| given a poison pill or something under the plausible deniability
| of "security risks of 13 year old software", like how Outlook
| 2010 can't connect to outlook.com anymore (though it works great
| with gmail using google's GWSO plugin)
|
| On _MY_ computer, I run what _I_ want. So I 'll try Office 2010
| in wine within Wayland.
| estebank wrote:
| > On _MY_ computer, I run what _I_ want.
|
| You can always do so, as long as you're not connected to the
| internet. In the same way that on your property you can drive
| what you want, but on the road there are minimum standards of
| safety that are supposed to be met, and some authority might
| enforce them. I completely relate to the "who moved my cheese?"
| effect, but unpatched internet connected software affects more
| than just yourself. This is not giving companies that
| completely disable software that could otherwise be hardened
| with _some minimal_ loss of functionality (like disabling the
| old Office equation editor) a pass.
| LoganDark wrote:
| Being connected to the internet is nothing like being a car
| on a road... it's more like joining a "crowd" of "people",
| with each "person" being another internet-connected computer,
| and the "crowd" being the network. The recent "pandemic" has
| taught everyone a lot about virus-spread stuff, so it's an
| appropriate analogy in my opinion.
|
| Vulnerable pieces of software can be exploited to receive or
| transmit viruses. The viruses spread through the crowd to
| anyone who is vulnerable. But just because someone spread the
| virus doesn't mean an authority is going to crack down on
| them for being intentionally reckless. If you crash into
| somebody on the road however...
___________________________________________________________________
(page generated 2023-02-25 23:00 UTC)