4 ms·

http://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=1 http://www.phoronix.com/scan.php?page=article&item=x_wayland... (Take note of the

http://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=1 http://www.phoronix.com/scan.php?page=article&item=x_wayland... (Take note of the x remoting content). The thing is, we don't really "use" X these days, it's more just a wrapper. Toolkits and direct rendering do most of the work, that used to be reserved for X. So Wayland was designed to cut out all the cruft, and make everything nicer. I must admit, two clipboards can be nice, but a single clipboard is probably sufficient. Maybe we can copy-paste without requiring the original program to stay open.

gioele 13y ago
> Maybe we can copy-paste without requiring the original program to stay open. Probably no, we will not be able to copy and paste without requiring the original program to stay open. If you think of plain text, yes, that can work. But what about images? In which format should they be stored? Who should take care of converting these images from the internal storage model (the one used in Gimp is quite strange, for example) into plain bitmaps? And what about rich text? How can I copy and paste a bold, red, Helvetica 16pt text? In which format will it be stored in the clipboard? Copy and paste, in its modern form, requires some form of MIME type negotiation that, in turn, requires applications to be around to negotiate.
pdkl95 13y ago
> [href] Seen it, and seen the talk[1]. > we don't really "use" X these days GTK+ and QT do not use a lot of X, as they render all their widgets with (e.g.) libcairo.so and libpango-1.0.so that only treat X as a framebuffer. Unfortunately, projecting your own usage habits onto others is an easy trap to fall into. For example, one minor data point, from my desktop system - I use the built-in font server: $ rdb -q | grep 'URxvt.*font' URxvt*font: -xos4-terminus-medium-r-normal--14-140-72-72-c-80-iso10646-1 Why? Because it's (MUCH) faster to draw, doesn't slow down even remotely, and after is much clearer to read on the screen than the blurry mess[2] that pango/etc gives you. /// that said /// As I mention briefly, I was warming up to the idea of wayland. GTK+ and QT are certainly popular, and some things DO need to be fixed. The linked phoronix article (or talk) does bring up some good points. The massive amount of (serialized) round-trips to the x-server (even locally) that are mandated by the protocol is paticularly outrageous. If backwards compatibility and remoting can be maintained through some sort of extension (or whatever), then it could even be a nearly-seamless drop in. The clipboard and selection, on the other hand, have nothing to do with any of that. They aren't a performance problem, and there is no reason to remove it. In fact, given this is a big change in general, and an opportunity to fix some of the core protocols, why not /expand/ the idea to include a full kill-ring or similar? Call it a fix for CUT_BUFFER[0-7] that were never really used? Changing protocols and the display pipeline ("things programmers have to worry about") is one thing. Cutting UI features that have been in place for a long time ("things users care about strongly") is a different world entirely. > but a single clipboard is probably sufficient When you've used both for decades, a single buffer is NOT sufficient. They end up serving completely different purposes, and are often needed simultaneously. [1]: http://www.youtube.com/watch?v=RIctzAQOe44 http://www.youtube.com/watch?v=RIctzAQOe44 [2]: http://www.antigrain.com/research/font_rasterization/index.html http://www.antigrain.com/research/font_rasterization/index.h...

gioele 13y ago

> Maybe we can copy-paste without requiring the original program to stay open. Probably no, we will not be able to copy and paste without requiring the original program to stay open. If you think of plain text, yes, that can work. But what about images? In which format should they be stored? Who should take care of converting these images from the internal storage model (the one used in Gimp is quite strange, for example) into plain bitmaps? And what about rich text? How can I copy and paste a bold, red, Helvetica 16pt text? In which format will it be stored in the clipboard? Copy and paste, in its modern form, requires some form of MIME type negotiation that, in turn, requires applications to be around to negotiate.

pdkl95 13y ago

> [href] Seen it, and seen the talk[1]. > we don't really "use" X these days GTK+ and QT do not use a lot of X, as they render all their widgets with (e.g.) libcairo.so and libpango-1.0.so that only treat X as a framebuffer. Unfortunately, projecting your own usage habits onto others is an easy trap to fall into. For example, one minor data point, from my desktop system - I use the built-in font server: $ rdb -q | grep 'URxvt.*font' URxvt*font: -xos4-terminus-medium-r-normal--14-140-72-72-c-80-iso10646-1 Why? Because it's (MUCH) faster to draw, doesn't slow down even remotely, and after is much clearer to read on the screen than the blurry mess[2] that pango/etc gives you. /// that said /// As I mention briefly, I was warming up to the idea of wayland. GTK+ and QT are certainly popular, and some things DO need to be fixed. The linked phoronix article (or talk) does bring up some good points. The massive amount of (serialized) round-trips to the x-server (even locally) that are mandated by the protocol is paticularly outrageous. If backwards compatibility and remoting can be maintained through some sort of extension (or whatever), then it could even be a nearly-seamless drop in. The clipboard and selection, on the other hand, have nothing to do with any of that. They aren't a performance problem, and there is no reason to remove it. In fact, given this is a big change in general, and an opportunity to fix some of the core protocols, why not /expand/ the idea to include a full kill-ring or similar? Call it a fix for CUT_BUFFER[0-7] that were never really used? Changing protocols and the display pipeline ("things programmers have to worry about") is one thing. Cutting UI features that have been in place for a long time ("things users care about strongly") is a different world entirely. > but a single clipboard is probably sufficient When you've used both for decades, a single buffer is NOT sufficient. They end up serving completely different purposes, and are often needed simultaneously. [1]: http://www.youtube.com/watch?v=RIctzAQOe44 http://www.youtube.com/watch?v=RIctzAQOe44 [2]: http://www.antigrain.com/research/font_rasterization/index.html http://www.antigrain.com/research/font_rasterization/index.h...