GTK+ 3.8 Released With Support For Wayland

kthreadd writes "Version 3.8 of the GTK+ GUI framework has been released. A new feature in GTK+ 3.8 is support for Wayland 1.0, the display server that will replace X on free desktops. Among the other new features are improved support for theming, fixes to geometry management and improved accessibility. There is also better support for touch, as part of an ongoing effort in making GTK+ touch-aware."

Comments

Replace X?

[Great Big Bird]

"A new feature in GTK+ 3.8 is support for Wayland 1.0, the display server that will replace X on free desktops." Who said this is going to replace X on 'free desktops'? As far as I have been hearing, this is just another in a long line and because it hasn't done it yet, it is not justifiable to say it will.

Re:Replace X?

[armanox]

Agreed - it doesn't even do everything that X11 does. And some of us use those features.

Re:Replace X?

[Freshly Exhumed]

Poor summary. Wayland allows the running of X11 applications through an X server, with work being done to support this on Intel and AMD graphics:

http://lists.freedesktop.org/archives/wayland-devel/2010-November/000292.html

Re:Replace X?

[Jherek Carnelian]

What is this "long line" you have been hearing of?

It consists of X, then Wayland.

Just off the top of my head:

Y Window System - http://en.wikipedia.org/wiki/Y_Window_System
Berlin/Fresco - http://en.wikipedia.org/wiki/Fresco_(windowing_system)
Xynth - http://en.wikipedia.org/wiki/Xynth
MicroXwin - http://en.wikipedia.org/wiki/MicroXwin
DirectFB - http://en.wikipedia.org/wiki/Directfb
Mir - http://en.wikipedia.org/wiki/Mir_(display_server)

Then there is whatever Android uses -- SurfaceFlinger?

Re:Replace X?

[JabberWokky]

To be fair, whatever Android uses -- and whatever TiVo and other embedded systems use -- are successful, and were never aimed at replacing X. They were aimed at providing graphical output strictly for their devices, and if they hit the market, did so nicely. Android's interface is used by a bunch of software these days.

The rest were all aimed at general desktop usage as a main priority, and absolutely you're right: X outlived them all. That doesn't imply that will always be the case, merely that it is much more difficult than most people think, for a wide variety of reasons.

There *does* seem to be much more momentum toward a change recently. It feels a bit like the XFree86 to XOrg leap era.

Re:Replace X?

[ArsonSmith]

Actually Wayland is just a fix to a non-issue. There was a perceived issue quite some time ago, but that was fixed. Wayland is little more than a "Going out of Business" sign on a furniture store. There must be good deals in there!!! Wayland is not X and I've heard that this thing I use daily that works near perfectly is horrible so Wayland must be good.

Re:Replace X?

[Anonymous Coward]

Yeah. The advantages of Wayland are actually pretty esoteric, if the goal is "I want to draw shit to my screen fast and efficiently". People think X is some clunking mess, and yet it was playing videos on computers 20 years ago.

What X is, is old. And developers are bored with it. And they want something new and shiny and a chance to play with the hardware without abstraction throwing a wet blanket over their benchmark scores.

The benchmark of success for Wayland is that _users_ don't actually notice that anything changed. They'll fall short of that benchmark because too many people like using X11, and even the backward compatibility inevitably will cause headaches.

But developers will enjoy it more, and in the FOSS world those are the only consumers that matter.

Re:Replace X?

[evilviper]

Wayland allows the running of X11 applications through an X server

Windows 7 allows the running of X11 graphics through an X server, too!

Thanks Xming and Cygwin developers!

Re:Replace X?

[Kjella]

Not light-weight in that respect, the main difference is it doesn't draw anything. Each application has to render its own window complete with decorations, then tell Wayland where to find it. The only thing Wayland does is to combine them, like if you have overlapping windows, transparency, transitions or 3D effects. So it should be able to handle multiple graphics devices, multiple monitors and all that locally. What it doesn't have is any forwarding, since shared buffers are inherently local and it has no knowledge of the rendering commands so it can't send a rendering stream.

Even in theory it's not so easy to know if you should render something locally or remotely, for example complex 3D application that use lots of textures and such you want to render locally, then send the finished window to the client. But say if you're a terminal server for 100 clients that want to run apps and all these are proper desktops with graphics card maybe you want to send OpenGL commands and render client side. Or maybe not again, if there are thin clients. And it probably depends on what the available bandwidth is. Personally I think web applications are far more suited to the task, if you need to access it remotely and it doesn't have a web interface then it's going to be some form of screen scraping.

Re:Replace X?

[dbIII]

The thing that pisses me and probably others off however is instead the likelyhood of wayland only apps which can't be run remotely like the X ones - then we may as well be on MS Windows.
If you have one fixed software licence for an occasionally used application in an office and it works with X you can just run it on the display of whoever wants it, but if you have the 1980s idea of a dumb local framebuffer you have to reserve a machine for that application and do hotseating. It's stepping back to the single user non-networked idea that was worn out before MSDOS was badly cloned as a cut down single user version of CP/M.
As for X bloat, it runs on Kindles FFS so that should show how stupid the bloat claim is. Would Wayland with gtk perform acceptably on something like a Kindle?

Re:Replace X?

[Anonymous Coward]

Well all that does is demonstrate your ignorance of the subject.

There is nothing preventing wayland to be implemented with a remote renderer, and in fact one of the goals of the protocol is to allow efficient remoting (without hampering local drawing).

Seeing as the protocol is being explicitly designed to minimise round-trips, it has potential to be significantly more efficient than remote X.

http://www.h-online.com/open/news/item/Wayland-prototype-for-rendering-software-that-runs-remotely-1715463.html

It's really pretty simple to educate yourself, which is a really good idea if you plan to rant about a subject on a public forum.

Re:Replace X?

[dbIII]

Dumping a framebuffer into VNC is a really crappy alternative to X, so please apologise for your insult about my "ignorance" and "educating myself".

Re:Replace X?

[Anonymous Coward]

The people who have been working on breaking X, you mean?

Back in XFree 4.0, we got support for DDC, aka "plug and play monitor". This is a protocol that allows the monitor to inform the computer about things like size and resolution, from which we get the DPI of the monitor, which is important to make things like fonts have the correct size on high DPI screens.

Around Xserver 1.7 (which is according to the new numbering system that was introduced after Xorg 7.0, they decided to do like XP, and just pretend all monitors are 96 DPI.

Shortly after that, Windows 7 (or Vista?) got support for reading the DPI from the monitor, like X.org used to be able to, and now we start seeing monitors in the 200 DPI area. Pretending a 200 DPI screen is 96 DPI will render everything at half size. Mostly unreadable without a magnifying glass. Meanwhile, Windows will render correctly on a 200 DPI screen, and X used to do so.

It is still possible to force the size in Xorg.conf, (after we thought we'd gotten rid of that file), and for a desktop PC that always has the same monitor, this works fine. But on a laptop, people will often have a big screen on their desk, and use the smaller screen on the go. That worked fine with DDC, back when only rich people had laptops, but when you force the size in Xorg.conf, you either need to buy a monitor with the same DPI as the laptop (try calculating the number of pixels on a 24 inch monitor at the DPI used in the Chromebook), or you'll be editing Xorg.conf every time.

Patches have been posted for reenabling DDC, even as an option, but the X.org developers refuse to merge these patches. Apparently they want to force us all to buy 96dpi monitors, or switch to Windows.

Those important X.org developers? I'm sure they'll do less damage to X by leaving for Wayland.

Re:Replace X?

[serviscope_minor]

What X is, is a heap of arcane apis which nobody uses

Bullshit. You ahve no idea what you're talking about.

What you *think* you're talking about is the font mechanism, which few people use any more. Oh the horror, X has a small unpopular part in the core protocol.

I guess it will take up kilobytes of space on disk while the unused code sits paged out.

Perhaps you're thinking of the drawing mechanism? Only some parts are unused. When coupled with the XRender extension it works just fine, and the two work together.

The reparenting mechanism is still used. The window manipulation mechanisms are still used. The remoting is still used. The elegant (and yes, it is elegant if you actually take the time to figure it out) copy/paste and now DnD mechanism is still used. The input basic mechanism is still used for most things. The screensaver mechanism works just fine.

And so on.

Basically most of it is just fine and for some reason people kile you get their knickers in a twist about an old protocol call which is not much used any more.

It's inefficient, complex (since clients must explicitly code for exensions with fallback behaviour).

So... your solution for requiring clients keep massive backwards compatibility is to break backwards compatibility. Okay, but you could jus tnot code clients with backwards compatibility to non extended X as well. Did that even occur to you?

Okey dokey. So it's not OK if you do it with X but it is OK if you do it with Wayland. I sense the FUD is strong in this one.

Proposing to get rid of it is not "esoteric" or "boredom", it's rational and pragmatic.

Basically the only thing people seem to coherently complain about is the little used and unloved font mechanism in X. Removing that is certainly worth losing remoting for!

And yes I'd like my desktop to "draw shit to my screen fast and efficiently". Doing away with X11 will facilitate that.

You are apparently not aware that X supports direct rendering and so has been able to "draw shit efficiently" for quite a long time now. Switching to Wayland won't change the rendering path.

The only efficiency improvement is that you input events will go from kernel->wayland->program not kernel->X->WM->X->program. If that has measurable latency then you're running on a 386 (good luck---it's out of support for Linux now) and rendering is the least of your worries.

And for people who "like using X11" can continue to do so - over Wayland.

FUD ATTACK!!! This has been rebutted many times including by me (again) elsewhere in this thread.

Re:Replace X?

[drinkypoo]

To be fair, whatever Android uses -- and whatever TiVo and other embedded systems use -- are successful, and were never aimed at replacing X. They were aimed at providing graphical output strictly for their devices

Android is Linux without X and with a new GUI. In a very real way, whatever Android uses does replace X. Prior portable Linux systems have used X, and you could do what Android is doing with X.

Re:Replace X?

[wed128]

Android is Linux without X...

And with a *completely* different userspace, and some scheduling patches (last i looked...have those been merged? will they be?)

Re:Replace X?

[Dcnjoe60]

The thing about free desktops is that they are free to ignore Wayland and either stick with X, or go the Ubuntu way and do their own thing.

Yes, free desktops are free to ignore Wayland and do their own thing. On the other hand, they are at the mercy of the distributions, such as Ubuntu, RedHat, Suse (and all the rest). Ubuntu is dropping X and not using Wayland and going with their own in house Mir, so those free desktops, if they want to run on Ubuntu will need to work with Mir. If Redhat goes with Wayland, as it appears it will be doing, then those free desktops will need to work with Wayland.

Or, they can go the Gnome route in which the developers have stated that they are going to shift from X to Wayland. Any distro that wants Gnome will need to provide Wayland.

And let's not forget the not so free video drivers. It's hard enough to get them to even support linux, but now they will need to support X, Wayland, Mir and who knows what.

My money is on whichever display server graphic cards write drivers for will be the winner. Of course, they are going to base their decision on which display server is going to see them selling more graphic cards.

But, as you say, the free desktops are free to ignore Wayland and do their own thing, even if that means their software won't run on any modern distributions anymore.

Re:Replace X?

[serviscope_minor]

Huge swathes of X are obsolete or unused

booollloooccckkkksss.....

You're talking about teeny-tiny swathes. And you ignored the bit where I pointed out the huge swathes which are still used. I love your arguing style: simply ignore the facts you don't like.

And basically you've picked almost exclusively on the font mechanism. WE know it's old.

We know it's nearly unused.

Guess what.

It doesn't matter.

I'll let you into a little secret. Modern processors (since about 1965 or s at the earliest) have this little thing I like to call virtual memory. It means that unused stuff sits on disk and doesn't get in the way. It doesn't make your programs magically slower any more than having X installed on the same system as Wayland will make Wayland magically slower.

If you were to delete that code out of the X server tomorrow it would have precisely no effect on how fast everything that doesn't use it runs.

I can't even parse that

Well, let me rephrase that: you claimed that X11 apps "have" to have alternate code paths in case the extensions are not present. Since the extensions are present on even remotely Xorg, they "have" to do that to maintain backwards compatibility.

Apparently the solution is Wayland because according to you X11 apps have to maintain backwards compatibility with ancient X but Wayland programs don't have to maintain backwards compatibility with ancient X.

That's double standards, because there's no reason X programs have to maintain backwards compatiblity with very old servers.

No it isn't. The composition path would be more efficient too. There are diagrams on the wayland site which demonstrate why it is more efficient. Maybe go look at them.

I have and it's a massive fud attack.

The only inefficiency is that some calls have to go via the compositor meaning a bunch more kernel->x->compositor->x->program transitions.

This is for things that happen a maximum of 60 times per second (once per displayed frame) for small *messages*. If your kernel can't handle that then you're running on a 386. Good luck with that.

In practive it happens far less often, more like once per input event, which are coming in at a few per second.

There's not even massive buffer copying in X over DRI.

So, basically you're talking crap.

You can use X11 over Wayland

And you can also eat a shit sandwhich too. See my rebuttal elsewhere in the thread and don't simply pretend that I havent pointed it out again.

You can replace my X

[RightwingNutjob]

when you pry it from my cold, dead, fingers!

Wayland Initial release :2008

[Osgeld]

the display server that will replace X on free desktops!

yea I know it takes some time to get stuff right, but call me when this thing gets out of duke nukem forever mode k

thanks

sigh

[smash]

Yet more "waaah, they're taking my X remoting!" crap. Wayland will enable an X server to run on top of it just like Windows does, just like OS X does - whilst enabling a far more efficient and modern rendering pipeline.

Re:sigh

[smash]

Being able to make X do something, and doing something without the last 20 years of brain damage are two entirely different things.

Re:sigh

[serviscope_minor]

Oh jeez more of the "oh but you can run X on Wayland" crap.

sure, you can eat a shit sandwich too, but it won't be very palatable.

Wayland will enable an X server to run on top of it just like Windows does, just like OS X does

Yeah, and we al know how well that works...

It's terrible. X is very much second class. Here are all the things that don't work:

* Copy/paste of more than text between X and non X
* Remoting of non X windows
* Drag and drop from X to non X
* Pleasant window management of non X windows

whilst enabling a far more efficient and modern rendering pipeline.

Evidence needed, and biased FUD from the Wayland team doesn't cut it.

X has supported direct i.e. nothing in the way rendering for ages now and that is very efficient.

Compositing window managers require a whole extra 2 socket round trips to the kernel *PER MOUSE MOVE*. Given that the kernel has a latency of positively micrseconds this is clearly a big blow for X /sarcasm.

Re:sigh

[Hatta]

Wayland will enable an X server to run on top of it

And what of native Wayland apps? Will remoting an arbitrary Wayland app be as easy as 'ssh -X waylandapp'? Will that work for all Wayland apps?

Re:sigh

[snadrus]

- Session-Oriented == hacks for log-in screen
- Tied to VTs
- Crashes take down all clients
- Takes 3 programs to draw a window: the application (hosting a lib), the window manager, the compositor
- Complex drivers tied to 1 version of X11
- Driver switching is impossible: it would take down all clients
- Hardware manipulation living outside the kernel (requiring root when we shouldn't)
- More lines of code than the Linux kernel
- Copy/Paste can't survive source program shutdowns (very common in Mobile)
- Remoting (& other pieces like Font) can't be fixed, but only wrapped or ignored, so we don't even know what doesn't work with X
- "Dead" code costs memory & load time
- Its model poorly fits hardware-accelerated toolkits.

Re:GTK+

[innocent_white_lamb]

I haven't used gtk+ much (for my own programming, that is) but I do use glib. A lot. God's gift to C programmers: glib.

VNC is one to one not many to one or one to many

[dbIII]

VNC? What if more than one user wants to use something on the remote machine? It's the age of the "cloud" where you can get a 64 core machine for around $9k, hook it up to fast storage and let a lot of people use it for very complex tasks. What is someone want to run things on multiple machines and doesn't want to juggle half a dozen full "desktops"? Sod this MSDOS single user non-networked approach - it's 2013 FFS!
Also that block diagram implies speed hits from the complexity and ignores that the wayland server+compositor is going to be doing a similar number of things internally as both the X server and compositor, so it doesn't prove your point and I doubt the person that drew it intended it to be used to try to prove that point.
It's been a long time and a lot of claims - why no benchmarks for identical task yet instead of handwaving and "X sux!!11!"

Load and unload the X cruft on demand

[tepples]

So why stick all the old cruft of X right back on?

So you can fire up the X cruft when the user starts an application that uses the X cruft, and you can shut down the X cruft when the user has closed the last application that uses the X cruft. As more GUI toolkits are ported to Wayland, fewer will require X to be running.

Re:Load and unload the X cruft on demand

[armanox]

"Home users" clearly aren't the "us" that I was referencing. Otherwise, I wouldn't have mentioned IRIX. I'm much less concerned with "home users" then I am with the server room. When I have to tell my clients to stay away from Linux because it's too unstable, too focused on the "home users" it will be a sad day. But it's coming very quickly. // And some of those clients really wouldn't mind moving to Solaris either. Especially since stuff doesn't just randomly change for the sake of change.