4 ms·

There seems to be a lot of limitations here. It is odd, sandboxing just the graphics stack. It isn't true sandboxing so all the benefits of sandboxing are not g

by com2kid 12y ago

There seems to be a lot of limitations here. It is odd, sandboxing just the graphics stack. It isn't true sandboxing so all the benefits of sandboxing are not gained, but a lot of the disadvantages still come with it. It sounds like something as simple as a keyboard macro manager would not be doable, nor would the Windows utility AutoHotKey. I'd also hate to try and write UI test automation for Wayland apps. It seems like they've pretty much ruled that out all together. Heck what about services that do browser test renders? Would those be possible? And not allowing plug ins is just foolish. "I'm sorry, we dictate that you must divide your application up this way." Flash, for years, drove innovation on the web, billions of dollars of value were created by Flash, trying to say "That won't be allowed to happen again because I say so" is hubris of the worst sorts.

wmf 12y ago
It is odd, sandboxing just the graphics stack. Since Wayland is a redesign of the graphics stack it looks like they decided to redesign it in a secure way rather than waiting for some system-wide security architecture to be designed. GNOME is working on full sandboxing: https://news.ycombinator.com/item?id=8219309 https://news.ycombinator.com/item?id=8219309 It sounds like something as simple as a keyboard macro manager would not be doable... That's doable in the compositor/window manager. I'd also hate to try and write UI test automation for Wayland apps. That's possible either through accessibility interfaces ( https://developer.gnome.org/accessibility-devel-guide/stable/gad-how-it-works.html.en https://developer.gnome.org/accessibility-devel-guide/stable... ) or the compositor/window manager. Note that many OS X "haxies" also use the accessibility API. Heck what about services that do browser test renders? That should be no problem using either a modified browser or modified compositor.
stelonix 12y ago
AutoHotKey-like behavior is already severely limited on X (can't send to non-active windows, same with XTEST). That is, if you want to use it for macros. For UI test automation it's fine I guess.
audidude 12y ago
ui automation will have to be there, as accessibility toolkits require it (that's how atk works). it's just going to require an additional wayland interface.

by com2kid 12y ago

wmf 12y ago

It is odd, sandboxing just the graphics stack. Since Wayland is a redesign of the graphics stack it looks like they decided to redesign it in a secure way rather than waiting for some system-wide security architecture to be designed. GNOME is working on full sandboxing: https://news.ycombinator.com/item?id=8219309 https://news.ycombinator.com/item?id=8219309 It sounds like something as simple as a keyboard macro manager would not be doable... That's doable in the compositor/window manager. I'd also hate to try and write UI test automation for Wayland apps. That's possible either through accessibility interfaces ( https://developer.gnome.org/accessibility-devel-guide/stable/gad-how-it-works.html.en https://developer.gnome.org/accessibility-devel-guide/stable... ) or the compositor/window manager. Note that many OS X "haxies" also use the accessibility API. Heck what about services that do browser test renders? That should be no problem using either a modified browser or modified compositor.

stelonix 12y ago

AutoHotKey-like behavior is already severely limited on X (can't send to non-active windows, same with XTEST). That is, if you want to use it for macros. For UI test automation it's fine I guess.

audidude 12y ago

ui automation will have to be there, as accessibility toolkits require it (that's how atk works). it's just going to require an additional wayland interface.