Valve Engineer Mike Blumenkrantz Hoping To Accelerate Wayland Protocol Development

[curfew]

Then I don't really understand what you want to use Wayland protocols for...

Well, you commented on a post that said that Wayland protocols for internal tasks could be used to split out the extensions from the window manager process for added stability and security. So exactly that is what we'd do.

Wayland protocols are just one messaging channel for two separate processes (apps) to talk to each other. In that way it's similar to D-bus, for example. I don't think the actual Wayland protocol would ever be exposed to shell extensions anyway because it's too low-level and powerful.

[Artim]

But i've given two examples of extensions that could just as well be written in any programming language, and aren't modifying the shell in any way, other then declaring their existence.

You may think so, but that's absolutely not how they work. While there could be an API to inject just anything into the top bar, including a weather widget, that's not how they work. And dash-to-dock by no means just "has to declare its existence", as it's indeed heavily modifying the shell - previously the dash, now the dock Gnome uses since v40 - to do what it does. You stating the opposite just shows your lack of understanding. Also, Gnome never really condoned extensions. You can create extensions, they even give you a website and a manager app to handle them. But that's pretty much it. By no means they guarantee any compatibility. If you break your shell with some badly made extension, you won't receive any support. So no, extensions on Gnome won't ever be more than JS scripts to modify the JS code of the shell.

i would suggest that you start looking glass for yourself, look at the extension you have running.. I suspect a bunch of them are just adding menu entries to the topbar. The reason why those exist because gnome say we're not going to create a standard protocol (a la tray protocol) because we don't want them to exist. well they exist now, and they're inside the gnome shell process slowing things down where they should just be an external process.

That's merely your opinion and nothing based on facts. In fact, you'd have to run some very heavy extensions for the difference becoming noticeable.

[Artim]

Well, you commented on a post that said that Wayland protocols for internal tasks could be used to split out the extensions from the window manager process for added stability and security. So exactly that is what we'd do.

Wayland protocols are just one messaging channel for two separate processes (apps) to talk to each other. In that way it's similar to D-bus, for example. I don't think the actual Wayland protocol would ever be exposed to shell extensions anyway because it's too low-level and powerful.

Or with other words you just wanted to throw some buzzwords onto a "solution" for a problem that yet has to be found. Without understanding what you are talking about. Got it.

[fitzie]

You may think so, but that's absolutely not how they work. While there could be an API to inject just anything into the top bar, including a weather widget, that's not how they work. And dash-to-dock by no means just "has to declare its existence", as it's indeed heavily modifying the shell - previously the dash, now the dock Gnome uses since v40 - to do what it does. You stating the opposite just shows your lack of understanding. Also, Gnome never really condoned extensions. You can create extensions, they even give you a website and a manager app to handle them. But that's pretty much it. By no means they guarantee any compatibility. If you break your shell with some badly made extension, you won't receive any support. So no, extensions on Gnome won't ever be more than JS scripts to modify the JS code of the shell.



That's merely your opinion and nothing based on facts. In fact, you'd have to run some very heavy extensions for the difference becoming noticeable.

so now you are pretending that gnome didn't kill the tray api? forcing many applications to needlessly become extensions? just because you misrepresent what I said doesn't make me wrong. dash to dock does need somewhat more than control of a dropdown menu, but it's not futzing with internal gnome-shell state. just wants to introspect the windows of the desktop. nothing that should force it to be written in javascript.

i've spent a bunch of time working on a gnome-extension, but it doesn't take long to see exactly why the gnome-shell approach is unnecessary and backwards technologically, and the it's a commitment to a backwards idea: https://blogs.gnome.org/aday/2017/08...ons-and-gnome/ that has failed in the marketplace.

[Artim]

so now you are pretending that gnome didn't kill the tray api?

Where have I suggested that? Please stop lying, it just makes you look even more pathetic...

dash to dock does need somewhat more than control of a dropdown menu, but it's not futzing with internal gnome-shell state. just wants to introspect the windows of the desktop. nothing that should force it to be written in javascript.

And here we go again. You just can't stop showing off how little you understand, can't you?

i've spent a bunch of time working on a gnome-extension,

That obviously is a lie, otherwise you'd know how Gnome works. But you have shown on several occasions that you clearly don't.

but it doesn't take long to see exactly why the gnome-shell approach is unnecessary and backwards technologically, and the it's a commitment to a backwards idea: https://blogs.gnome.org/aday/2017/08...ons-and-gnome/ that has failed in the marketplace.

That's merely your opinion, not facts. So please stop spreading lies.

[fitzie]

Where have I suggested that? Please stop lying, it just makes you look even more pathetic...



And here we go again. You just can't stop showing off how little you understand, can't you?




That obviously is a lie, otherwise you'd know how Gnome works. But you have shown on several occasions that you clearly don't.



That's merely your opinion, not facts. So please stop spreading lies.

you are really having some basic reading comprehension issues, or you just want to argue with me. I will try this one last time then I will give up. You wrote this:

thus the extensions are using JS, as they are pretty much just injecting code into the shell's JS code in order to modify it. So no, extensions can't just be written in any language.

I am only trying to figure out what you are saying there. For example, the tray api was such a protocol that would allow external programs to control a icon/menu on the top bar. If you agree about that, then why do you say extensions need to be written in javascript? I've said multiple times not every extension could avoid javascript/running in process, but my point is a fair amount of them could be. If you are unwilling to explain your point, then I will just go about my day then.

[Artim]

I am only trying to figure out what you are saying there. For example, the tray api was such a protocol that would allow external programs to control a icon/menu on the top bar. If you agree about that,

Yes, back when Gnome had that support natively, it was just that.

then why do you say extensions need to be written in javascript?

Because that's how it is. The fact that the tray API did exist doesn't change that. The existence of the tray merely allowed apps to put their app icon there to indicate that they are still running in the background. That API was removed - though Gnome now has their own extension to bring back at least something, but it doesn't seem to be compatible with anything - so if you want to bring back the tray you need to write an extension, which in turn must be written in JS to inject its UI into the pre-existing UI. What's so hard about this to understand?

I've said multiple times not every extension could avoid javascript/running in process, but my point is a fair amount of them could be. If you are unwilling to explain your point, then I will just go about my day then.

No, not a single extension can avoid being written in JS, as it still must inject its UI into the rest of the JS-written gnome-shell. I'm not unwilling to explain my point, you are just too arrogant to see that you have absolutely no idea about how Gnome works. Your argument is like claiming that websites can just execute script written in any language and don't need JS (for anything that goes beyond what's possible with HTML and CSS). That's just plain wrong. Yes, thanks to WebAssembly, you can write programs in a couple of languages, which are then compiled to wasm and that can run inside a page, making pretty much a native app out of a website. But you still need a bunch of JS to actually use a wasm program inside a website.

[fitzie]

Yes, back when Gnome had that support natively, it was just that.



Because that's how it is. The fact that the tray API did exist doesn't change that. The existence of the tray merely allowed apps to put their app icon there to indicate that they are still running in the background. That API was removed - though Gnome now has their own extension to bring back at least something, but it doesn't seem to be compatible with anything - so if you want to bring back the tray you need to write an extension, which in turn must be written in JS to inject its UI into the pre-existing UI. What's so hard about this to understand?



No, not a single extension can avoid being written in JS, as it still must inject its UI into the rest of the JS-written gnome-shell. I'm not unwilling to explain my point, you are just too arrogant to see that you have absolutely no idea about how Gnome works. Your argument is like claiming that websites can just execute script written in any language and don't need JS (for anything that goes beyond what's possible with HTML and CSS). That's just plain wrong. Yes, thanks to WebAssembly, you can write programs in a couple of languages, which are then compiled to wasm and that can run inside a page, making pretty much a native app out of a website. But you still need a bunch of JS to actually use a wasm program inside a website.

i've told you before that I've written gnome extension, yet you continue to tell me that I don't know the gnome extension api. do you really think that is a winning argument?

If gnome brought back the tray api (as you mention there's an extension for it) then some extensions that really just want a tray api can switch to that tray api, and no longer be an extension, no longer be written in javascript.. do you follow that? It seems like you're making a circular argument, that extensions must be extension because they are extensions. I'm saying that extensions no longer need to be extensions if gnome starts to offer an api that doesn't require them to be extensions.

At this point I think you're saying agreeing with me that gnome doesn't offer these api's because the choose not to, not because there's a technical reason. You seemed to claim there was a technical reason because you say "they must be written in javascript" over and over, but as you acknowledge there's a gnome-extension that recreates the tray api, so it's obvious there's no technical reason if everything you want to do as an extension would be satisfied by the tray api which doesn't require you to write in javascript.

since you have no interest actually clarifying what you have said I will end this conversation now. have a great day!

[Artim]

i've told you before that I've written gnome extension, yet you continue to tell me that I don't know the gnome extension api. do you really think that is a winning argument?

Do you actually think I care if you think it is? It's more than obvious enough that you have not the first clue about how gnome-shell works.

I'm saying that extensions no longer need to be extensions if gnome starts to offer an api that doesn't require them to be extensions.

No, you haven't. This is literally the first time you made that point. And the point you make literally makes no sense whatsoever. Obviously you can make an API for everything so you don't need extensions anymore. But nobody will do that, otherwise you'd have a situation at least as bad as with Wayland, where everyone and their cat feels entitled to create an API/protocol and have it accepted, no matter how bad it is. Just stick with extensions and call it a day.

Your original point was that you wanted to get rid of JS and just throw the buzzword "Wayland protocol" on it, which doesn't make any sense whatsoever. I told you that this would destroy the whole extension ecosystem as not a single extension would be able to work anymore. Now tell me, how does creating an indefinite set of APIs solve anything beyond your ridiculous animosities with claiming that extensions would make Gnome slower as they are run in the shell's process with the issue of killing off every extension? You'd still have extensions that still need to be extensions. But instead of going straight the current route of simply modifying gnome-shell's JS code to whatever the user wants, you want them to all be rewritten to use some arbitrary APIs where nobody can guarantee that all needed APIs will even be present. This is plain stupid. Sure, if you want to pay all extension developers (current and future!) and Gnome developers to do all that work just to satisfy your urge to make everything stupidly complicated, go ahead. But thank god you have no voice in the future of Gnome, because that would instantly kill Gnome.

At this point I think you're saying agreeing with me that gnome doesn't offer these api's because the choose not to, not because there's a technical reason.

No, in no way I'm agreeing with you. I still think you have no clue what you are saying, and probably have never written a Gnome extension in your life...

You seemed to claim there was a technical reason because you say "they must be written in javascript" over and over, but as you acknowledge there's a gnome-extension that recreates the tray api, so it's obvious there's no technical reason if everything you want to do as an extension would be satisfied by the tray api which doesn't require you to write in javascript.

All Gnome extensions must be written in JS. And spoiler: this is also true for the Gnome extensions for the tray icons, as it's literally written 100 % in JS: https://gitlab.gnome.org/fmuellner/top-icons

since you have no interest actually clarifying what you have said I will end this conversation now. have a great day!

Well thank god you finally do! Because I have absolutely nothing to clarify. I'm just stating some very basic and simple facts that you choose to ignore over and over with your ridiculous whataboutism and your utter lack of any knowledge whatsoever how Gnome works. So unless you can come up with some actually usable ideas instead of a bunch of unrealistic brain farts, I'll keep calling you out for what you are: an entitled brat throwing around buzzwords thinking they know anything about the stuff they talk about, yet doesn't have the first clue.