Not impossible, it just needs to be implemented at a different layer. The compositor needs to expose some API for global hotkeys. For example, I found this with ~2 minutes of Googling: https://wayland.app/protocols/hyprland-global-shortcuts-v1
> Not impossible, it just needs to be implemented at a different layer. The compositor needs to expose some API for global hotkeys.
That's a big problem. When things become an optional extension for a compositor, that means you cannot reliably deploy something that depends on it to Wayland.
At this moment, things in the wild are coupling themselves to libwayland-client and in practice ossifying its ABI as a standard no matter what the wayland orgs say about it.
It's not a core protocol's concern and the fact that it's being successfully implemented proves that there are no fundamental limitations there.
I'm not happy with how the collaboration and planning between various parties involved went over years and I do believe that a lot of these adoption pains are fully self-inflicted, but that has absolutely nothing to do with Wayland's technical design.
I can, I just did. It's just not a thing that should be there at all, and it's obvious once you take a second to look at what's actually in it and why (spoiler: there's too much in it and not much can be done about it now).
And that's a problem, now instead of knowing that something just works in the WM you're using, you have to cross-reference a matrix of features for basic tasks across different WMs because the bare minimum features are not found in the core protocols. Nothing is standardized, it's just a pile of different WMs developing their own sets of custom protocols.
I'm not sure what point you thought you were making. The web is a complete mess.
I can't count the number of things that either no longer work or no longer even exist at all because of nothing other than the fragmented and ever-changing nature of the web. Aside from sites and apps that required flash or silverlight, I have several different pieces of expensive aactual hardware that either partially or wholly became unusable because the built in and non-updatable web interface requires an old version of java or activex.
Indeed we do all know how that went. It went like to total dogshit.
Currently there isn't really a "window manager" layer. Just like the automation / global hotkeys mentioned above, if you wanted a separate "window manager" your compositor would need to implement a protocol to expose window management. It looks like river is taking a stab at it with their river-window-management-v1 protocol: https://isaacfreund.com/blog/river-window-management/ . If they're successful we might see that protocol adopted by the other compositors.
Not only that. A11y is also quite hard. Tools that are simple to implement thanks to good a11y apis - for example on macos, the tool rcmd or homerow - are super hard to do in Wayland.
wdotool exists, and global hotkeys are a thing under wayland, but is desktop dependent. KDE allows it by default, Gnome can be made to do it as well with an extension.
Th point is the decoupling. sxkhd runs irrespective of wm and means your en can optionally choose not to handle key bindings at all. With Wayland you end up depending on whether or not and how your compositor supports it.
How many keybings do you have and how often do you try new window managers? Compromising the security of the whole system just to save you a few `sed`s when writing some config files seems like a bad trade off.
There's no need to compromise the security of the whole system. A trivially safe option would have been to restrict the ability to acquire global keybindings to specific clients, and require the user to confirm either once or every time (or any other policy you'd prefer). An X server could do that without breaking anything.
This issue is typical of the thinking that went into Wayland: No consideration was made when Wayland was announced of the fact that there were far simpler ways of achieving the same level of security.
> Compromising the security of the whole system just to save you a few `sed`s when writing some config files seems like a bad trade off.
Those aren't the only two options. There's no need to compromise the entire system for everybody if the Wayland devs would agree to configuration that controls these things.
Then those of us who need stuff to work rgardless of WM would get stuff to work and the rest of the Wayland users can simply go with a WM that suits them.
Imagine you wrote an application that supports global, unfocused keybinds (OBS is one popular example).
Instead of implementing it one way that works forever with any WM/DE (X11), now you must rely on each individual wayland compositor to implement one or more optional extensions correctly, and constantly deal with bug reports of people that are using unsupported or broken compositors.
Or you could write portable software that doesn't rely on reading global input. OBS you give as an example, and it is a good one. They could simply register a D-Bus handler and provide a second binary that sends messages to the running instance. The software is more general in this way as it allows full programmatic control. A Sway user, for instance, could add
bindsym $mod+r exec obs-control toggle-recording
to their configuration. What's more, they can do this in response to other system events. A user might wish to change the recording configuration of OBS in response to an application opening, and it now becomes possible to write a script which opens the application and applies the change.
If your disdain for desktop isolation is so great, you needn't even use D-Bus. Registering a simple UNIX socket that accepts commands would work equally well in this case.
What's really desired here is a standard way for programs to expose user-facing commands to the system, which is clearly not within the scope of the specification for a display server. The problem with X11 is that it has for a long time exposed too much unrelated functionality like this to the user, and so many apps have become reliant on this and developers have neglected the creation of portable ways to achieve these objectives. A new specification for display servers that excludes this harmful behaviour is a clear long-term positive.
This is an excellent description of why this is an awful situation.
It's extremely user hostile.
> The problem with X11 is that it has for a long time exposed too much unrelated functionality like this to the user
It's not "unrelated functionality". It's an entirely generic ability to listen to events that is available with Wayland as well, just with an added restriction.
I'm not sure how any of that sidesteps the point of my comment, which was having to rely on many different wayland compositors all implementing hotkeys properly.
I don't think it's always practical or desired to move the hotkey support completely out of the program itself. Most users (especially consumer/nontechnical people such as many OBS users) are not willing to setup hotkeys through a third-party program to manually get it to control OBS externally... so I think it needs to support hotkeys internally, whether there is also control possible via an external socket/dbus/etc. or not.
So either every user needs to manually bind every command using their WM's bespoke global hotkey mechanism, or the developer needs to ship keybinds for every possible WM.
Sounds like a nightmare for everyone involved to me
I think you've got it backwards. Applications like OBS do not typically register default global keybindings to avoid clobbering, you have to do it manually in their settings menu. The only difference with a generic interface is that the dialogue opened from the setting menu would be from the WM instead of OBS.
The problem with Wayland in this respect is that there is no such generic interface that works everywhere - each compositor may choose not to support it at all, or support it in different ways.
If there was a single standard way, great. In the meantime I'll stick to X11, which isn't this incredibly user-hostile.
Is there something wrong in particular with that image? The composition fits in well with the content of the article, and the art seems pretty well down. I'm only seeing one error that would make me think "a human probably didn't draw this" and took a while to notice that.
It is just awful and the entire composition does not make sense. Why is there a globe in the sky? Why is the text ‘open access’ there which is a completely different topic?
No thought or skill went into that image besides the prompt that the author wrote in 10 seconds. It signals that the author probably didn’t put any effort in the article as well.
I don't really understand what the value proposition of Bun and Deno is. And I see huge problems with their governance and long-term sustainability.
Node.js on the other hand is not owned or controlled by one entity. It is not beholden to the whims of investors or a large corporation. I have contributed to Node.js in the past and I was really impressed by its rock-solid governance model and processes. I think this an under-appreciated feature when evaluating tech options.
Deno has some pretty nice unique features like sandboxing that, afaik, don't exist in other runtimes (yet). It's enough of a draw that it's the recommended runtime for projects like yt-dlp: https://github.com/yt-dlp/yt-dlp/issues/14404
> The permission model implements a "seat belt" approach, which prevents trusted code from unintentionally changing files or using resources that access has not explicitly been granted to. It does not provide security guarantees in the presence of malicious code. Malicious code can bypass the permission model and execute arbitrary code without the restrictions imposed by the permission model.
Deno's permissions model is actually a very nice feature. But it is not very granular so I think you end up just allowing everything a lot of the time. I also think sandboxing is a responsibility of the OS. And lastly, a lot of use cases do not really benefit from it (e.g. server applications).
If one gets nothing from them directly, they've at least been a good kick to get several features into Node. It's almost like neovim was to vim, perhaps to a lesser extent.
I agree about the governance and long-term sustainability points but if you don't see any value in Bun or Deno is probably because (no offense) you are not paying attention.
Maybe if you can deliver information in small chunks in an interesting way that doesn't require a large attention span, it will work.
But if I have to read a wall of text, it's not an alternative to doomscrolling, it's an alternative to reading a book or documentation. And in that case I'd rather read a book or documentation.
You install the React SDK, register your React components with Zod schemas, and then the agent responds to users with your UI components.
Developers are using it to build agents that actually solve user needs with their own UI elements, instead of text instructions or taking actions with minimal visibility for the user.
We're building out a generative UI library, but as of right now it doesn't generate any code (that could change).
We do have a skill you can give your agent to create new UI components:
Basically it's just... agreeing upon a description format for UI components ("put the component C with params p1, p2, ... at location x, y") using JSON / zod schema etc... and... that's it?
Then the agent just uses a tool "putCompoent(C, params, location)" which just renders the component?
I'm failing to understand how it would be more than this?
On one hand I agree that if we "all" find a standard way to describe those components, then we can integrate them easily in multiple tools so we don't have to do it again each time. At the same time, it seems like this is just a "nice render-based wrapper" over MCP / tool calls, no? am I missing something?
Fun fact, I rarely have to show my ID when flying in the EU. But what I don’t understand is why so many people don’t have an ID in the US. Seems like one of the very basic service governments should provide.
Plenty of people have an ID in the US, the issue is whether or not those IDs are considered valid to get past security in the airport.
Did you know that Norway only introduced a national ID card in 2020? Until then if you didn't have a driver's license the only other state-issued ID option was a passport, and 10% of Norwegians don't have one. Until around 2015 or so banks would issue your bank card with a photo and your birthdate on it, and that was used as a de facto ID.
I've flown between plenty of EEA countries without ever having to show an ID. The requirement to have one in the US is incredibly stupid and only serves to make it harder for decent people to travel. It provides no actual value to safety.
I fly between various countries in western Europe a dozen times a year and have done so for a decade and every single time I've boarded a plane I have had to shown a photo ID with my name on it that matches my name on the plane ticket. Most of the time the gate agent barely looks at the ID/name, but it is required to hand it to them. I have never once just walked on a plane without showing ID with my name on it, and I have never seen anyone in line in front of me do so, ever, and I'm talking hundreds of flights at this point. It doesn't have to be a passport, I see older Spanish people showing their driver's license only all the time, but it has to have a photo and a name (to match the name on the ticket in some way) and be a state issued ID. Again, they seem very lenient with that whole name matching thing and checking the authenticity of the ID (it isn't scanned, just visually inspected), but I've never seen anyone just say 'no' and get on a plane.
So what the hell part of the EU are you talking about where they don't ask for any ID at the point where you are boarding, whatsoever?
For reference, here is Iberia's page for required ID when flying, and I've seen that this is absolutely enforced every time when checking in and boarding.
It's a product of the lingering sentiment of a country founded on not wanting to pay taxes, mixed with (often warrented) mistrust of the government and truely insane immigration laws all jumbled togeather.
Yeah, we would be better of with something universal and more robust then the toilet paper they print social security numbers on, but we got the system it was possible to pass through congress.
That’s completely false. You ALWAYS have to show your ID card to fly in the EU. Always.
Seriously, just stop trying to use us to justify silly arguments about the USA. Yes, Europeans must show ID to travel, must absolutely show ID to vote (it would just be ridiculous if we didn’t) and getting the ID costs us money and must be renewed every 10 years (and paid for).
This is not true. The airline has the right to ask for it but in practice this is not really done -- or let me rephrase, not consistently done.
I fly intra-Schengen flights at least twice a year. I had to show ID sometimes before COVID but I never had to show ID after that, it actually caught my attention as anybody could have travelled in my place. I do online check-in, drop the bags, go through security, and show the boarding pass. Last time was three months ago, and once again: no ID.
From the top of my mind I can say that I travelled from/to Sweden, Denmark, Germany, Poland, Spain, Portugal in the last few years and I didn't need to present any ID to board the plane.
reply