| |||||||||||||
Remote desktop vs. remote displayRemote desktop vs. remote displayPosted Feb 14, 2013 9:53 UTC (Thu) by renox (subscriber, #23785)In reply to: Remote desktop vs. remote display by paulj Parent article: LCA: The ways of Wayland
I'm definitedly not an X apologist but what you wrote is *very* inacurate!
> There is no way that Wayland can make things worse for you or anyone else. It can only make things better.
False: when your toolkit drops support for X to become Wayland only (let's be realistic: backward compability support isn't good in the Linux desktop world), then "Wayland can make things worse for you".
> Wayland == X12
Only in the sense that Wayland is X's successor but X is a model where programs send drawings commands to a display server, Wayland is a model where programs sends whole buffers to a display server, that is a significant difference: drawing commands can include 'send a whole buffer' but not the other way round.
(Log in to post comments)
Remote desktop vs. remote display Posted Feb 21, 2013 4:06 UTC (Thu) by mmarq (guest, #2332) [Link]
No one in their right mind can be an apologist of the actual situation of Xorg...
Also none in their right mind will change car only because its tires got flat
Everyone should be apologist of how X network works... it could be substantially improved, yet maintain perfect compatibility (think of it like the kernel ABI)... and this is fundamental, kill X network and the desktop could not suffer much, but a good part of the "app server" business is gone...
There is this misconception that to "grow" you must change to new... its exactly the opposite... change when its a fail in "use" and "install" base, because this kind of changes mean exactly "born again", and you have to pass for the same growth pains allover again...
Wayland with improved X protocol in it is just X12... Improved Xorg with the Wayland protocol is also X12... X without X protocol is not X... Wayland without X is a disaster...
And worst, the ugly hack of running server on top of server a clumsy duplication that is not AT ALL in favor of fast or stability, could be buggy prone, and will flop miserably... more so because that is the *issue*, none of millions of potential users out there understand a word of you are saying... only *good* and or *bad* notions... yet they can feel when its real "draggy" or "instable", and they will NOT blame X or wayland or whatever, they will BLAME ALL, switch and stay away...
Remote desktop vs. remote display Posted Feb 21, 2013 6:48 UTC (Thu) by mmarq (guest, #2332) [Link]
and sure it isn't the toolkits guys fault... that is a lost battle, ppl should get over it, more so because there is a very simple solution...
* a common Icon engine
* a common theming engine (embeddable) mainly for the "app windows" and doesn't touch panels, docs, bars or special widgets.
Than the battle that is not lost yet, is putt a "common" display engine for everything from boot (Grub DM) to the desktop, one which could take the responsibility for basic multi display, mouse pointer and keyboard (among other things)... it could even be the engine for something like Coreboot setup display and help this one gain traction...
Can a striped down version of Wayland fulfill those rolls, be the "mouse pointer engine" and the "keyboard engine" for the desktop in collaboration with the main windowing system ? ( i think it can)
In debugging or a crash situation of the main desktop, is just a pain why does the keyboard mapping have to change and why does the mouse pointer theme have to change...
Then at least Wayland would be tremendously faster to adopt and evolve... and with those successful... than to port the now ~200.000 X applications allover all this years, to be Wayland apps, and to accomplish that will require ugly buggy and instability prone hacks, of servers on top of servers...
Honestly, i have nothing personally against Wayland... and it hasn't to do with the engine itself (which could be good)... but i couldn't think of a better *mess* than this, to throw Linux desktop back to stage 1.
|
|||||||||||||