GTK+ 3.8 Released With Support For Wayland 193
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."
Replace X? (Score:4, Insightful)
Re: (Score:3, Insightful)
Agreed - it doesn't even do everything that X11 does. And some of us use those features.
Re: (Score:2)
But doesn't Wayland run X, too?
Re: (Score:2)
X Server, yes. Not X Client. So for the system to listen for XDMCP requests, you'd still need to have X running all the time.
Load and unload the X cruft on demand (Score:3)
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: (Score:2)
Which for many of us, won't be. As per my example, if I want to have a server running headless and connect via XDMCP, Wayland doesn't support this. Also, plenty of us use more then Linux, and Wayland is only being developed for Linux. No Solaris or BSD support (much less older UNIX systems, say IRIX).
Re: (Score:2)
Who's "us"? For most home users, if they want to run desktop apps on a server, they want those apps to keep running when the desktop is shut down, so they now use Xvnc and WaylandVNC will work just as well.
Re: (Score:3)
"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.
Re: (Score:2)
Wayland and Unix (Score:2)
Re: (Score:2)
XDMCP
Re: (Score:2)
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.
Re: (Score:3)
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 de
Re: (Score:2)
Re: (Score:2)
Of the free desktops, currently, only KDE and GNOME have endorsed Wayland. Qt5 and now GTK 3.8 will support Wayland, and so it will be up to DEs that use them, such as LXDE or XFCE or Razor-qt to support them or not. They can stay w/ X11 if they like - nobody is forcing them.
The people who need the remote accessing capabilities of X - mainly those who work w/ servers and who use their X terminals to access different servers remotely - those would usually be the people who need the terminals more than an
GPGPU (Score:2)
I don't know what kind of graphics cards you put in your servers (or why)
I know why: abusing pixel shaders [wikipedia.org].
Re: (Score:2)
Re:Replace X? (Score:5, Informative)
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 [freedesktop.org]
Re: (Score:3)
Windows 7 allows the running of X11 graphics through an X server, too!
Thanks Xming and Cygwin developers!
Re:Replace X? (Score:4, Interesting)
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? (Score:4, Informative)
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: (Score:3, Interesting)
6 to 15 kbps (Score:2)
Bandwidth is a far easier problem to solve, particularly for longer connections.
Are you talking wired or wireless? And how long of a connection? In a way, the sustained bandwidth of a typical connection is limited to 6 to 15 kbps. That's the 2 to 5 GB per month cap on a mobile data connection, times 8000000 kilobits per GB, divided by 2629746 seconds in an average month.
Re: (Score:2)
It's easier to upgrade my plan
But it can be cost prohibitive to upgrade the plans of all users of your application.
Run the app locally (Score:2)
You have a bandwidth limited connection? That's nice. Pay some more money, and get more bandwidth.
But there is a limit to how much more money for bandwidth the user of an application will be willing to tolerate. Good luck affording enough bandwidth to run something like OnLive for 8 hours a day, 22 days a month.
Just that the fewer the round-trips, the less latency dependent it becomes.
And if the application is running locally in a sandbox, communicating with the other machine only to synchronize data, there are even fewer round-trips. One example is any web application written in JavaScript.
Re: (Score:2)
Which now raises that latency problem again, which a system that is not bothering to do screen scraping because it knows what is there and changing is not going to have to waste time doing.
Re: (Score:2)
So when you run a modern app over a network, X is just shifting chunks of bitmap around anyway. Producing something analogous for Wayland is hardly an insurmountable task, and in the meantime things like vnc exist. It's even possible that
Re: (Score:2)
It was only a very short one line post above - why didn't you read it before replying?
Re: (Score:2)
VNC is one to one not many to one or one to many (Score:4, Informative)
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!"
Re: (Score:2)
VNC? What if more than one user wants to use something on the remote machine?
They they start another Xvnc process.
What is someone want to run things on multiple machines and doesn't want to juggle half a dozen full "desktops"?
Yes, that is a real problem.
Re: (Score:2)
What is someone want to run things on multiple machines and doesn't want to juggle half a dozen full "desktops"?
I wonder for how many people this scenario would even apply though, or why it should mean the experience in a Linux desktop should be hampered by X11 just to facilitate it.
Re: (Score:2)
I wonder for how many people this scenario would even apply though, or why it should mean the experience in a Linux desktop should be hampered by X11 just to facilitate it.
That begs the question, is the experience in a Linux desktop hampered by X11? I've so far seen no evidence that it is.
Re: (Score:2)
About 50 people where I work for a start. Different servers do different tasks so application windows are vastly better than a stack of slow VNC desktops and even large images are best dealt with on a node with 32GB instead of a desktop with 4GB.
In what way exactly? Wayland hasn't progressed to a working demo state yet so how is X hampering people more than what is available?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Most of the objections raised about network transparency seem pretty s
Re: (Score:2)
It appears we've hit the problem of the person who is dismissing X out of hand does not actually understand why people use it, which I suppose it why your suggestions have failed to address the questions.
Until Waylan
Re: (Score:2)
It appears we've hit the problem of the person who is dismissing X out of hand does not actually understand why people use it, which I suppose it why your suggestions have failed to address the questions.
I'm not dismissing X out of hand. That would be a straw man. What I am saying is that it clearly impacts on the local desktop performance (and it's not hard to find comments [lwn.net] by leading X devs who state this for a fact). And most of the objections raised for switching to something more efficient concern a feature that not many people use, and even if Wayland were to become the default experience, could be achieved anyway.
Anyone who absolutely cannot abide the change can just use an X11 fork, or vnc / MX /
Re: (Score:2)
There is also a very good explanation on the wayland site as to why X is so awful for performance
I don't see any benchmarks demonstrating how X is so awful for performance. The games I play perform similarly to their counterparts on Windows. Videos play smoothly. Window management is extremely responsive.
Premature optimization is the root of all evil. The Wayland folks haven't even demonstrated that there is a performance problem. And they expect us to abandon well loved features, for what? A flow cha
Re: (Score:2)
Wayland does not preclude a network transparent transport.
Wayland does not guarantee a network transparent transport. X11 does guarantee a network transparent transport. See the difference?
sudo apt-get install such a transport (Score:2)
Wayland does not guarantee a network transparent transport.
However, users' demands will guarantee that distributions make such a transport available through a command analogous to sudo apt-get install wayland-network-transparent-transport.
Re: (Score:2)
As long it's installed by default, everywhere, and usable without elevated permissions, and as easily invoked as 'ssh -X remoteapp', I'll be happy. But given how the Wayland developers have taken the issue, I'm not holding my breath.
Re: (Score:2)
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?
Would your Kindle allow you to run remote X sessions? You can't say the problem with Wayland is that you can't run remote X sessions and then use the Kindle a support for X as it doesn't let you run remote X session, either.
X server for Android (Score:2)
Would your Kindle allow you to run remote X sessions?
That depends on whether or not Amazon left a feature essential to the X server for Android [google.com] out of the Kindle Fire. Did it?
Re: (Score:2)
Such a lean X window manager also demonstrates a likely design flaw with wayland being stuck with the window management that is built in and no option to replace it with different window managers for different roles. Making a one size fits all system that can be tweaked to fit di
Re: (Score:2)
Isn't Wayland aimed for the mobile market as a light-weight replacement for X? So on Desktops, where you want to support many graphics devices and features like X-Forwarding, you will want to stick with X (unless you already follow a cross-device distro using e.g. Unity).
Re: (Score:3)
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: (Score:3)
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
Re: (Score:2)
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***,
And it's a really fucking stupid idea (tm).
Actually it's not even a Wayland idea per-se. There is no reason -at all- that client side decorations need to be done by Wayland: it's entirely possible to get the compositor to draw them.
For some reason, however the Wayland developers policy is client decorations. It seems that they've been so blinded by
Re: (Score:2)
Actually it's not even a Wayland idea per-se. There is no reason -at all- that client side decorations need to be done by Wayland: it's entirely possible to get the compositor to draw them. For some reason, however the Wayland developers policy is client decorations.
Right now I'm browsing in Chrome on Win7, where the top window bar is full of tabs so where do the client decorations start and end? One of the main complaints I hear about CSD is that a frozen application will also freeze the windows, but you have a compositor - you can have a key combo show a pop-up menu to minimize/move the window or kill the application etc. - your options are very static if it's not responding. The other big one is consistency, but I'm not sure if you're better off just having Gtk+/Qt
Re: (Score:2)
where the top window bar is full of tabs so where do the client decorations start and end?
I know that feature: I installed Crom(ium) on Linux and the first thing I did was switch it off. ewww. Horrible.
Anyway, to your points: yes you can. I still think that by default it's best to have server side decorations and have the client specially request undecorated windows.
The other reason for it is that it's much easier to enforce policies on top of applications if they assert less control.
For example, some misbe
Re: (Score:2)
Re: (Score:2)
And those of us who actually use X hope that Wayland never comes close to replacing X, because it's not going to be as featureful.
Re:Replace X? (Score:5, Informative)
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 [wikipedia.org]
Berlin/Fresco - http://en.wikipedia.org/wiki/Fresco_(windowing_system) [wikipedia.org]
Xynth - http://en.wikipedia.org/wiki/Xynth [wikipedia.org]
MicroXwin - http://en.wikipedia.org/wiki/MicroXwin [wikipedia.org]
DirectFB - http://en.wikipedia.org/wiki/Directfb [wikipedia.org]
Mir - http://en.wikipedia.org/wiki/Mir_(display_server) [wikipedia.org]
Then there is whatever Android uses -- SurfaceFlinger?
Re:Replace X? (Score:4, Informative)
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: (Score:3)
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: (Score:3)
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: (Score:2)
If you're going to include Android, then may as well include Mac OS's Quartz too. I don't think either of them really make sense to include though.
Re: (Score:2)
It didn't replace X, because andoroid never used X to begin with.
Re: (Score:2)
I remember having high hopes for Berlin back in the day (back when I was naively optimistic hehe).
Re: (Score:2, Interesting)
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 a
Re: (Score:2)
Patches have been posted for reenabling DDC, even as an option, but the X.org developers refuse to merge these patches.
Could you give a citation for this refusal or at least the Google keywords that will produce relevant results?
Re: (Score:2)
Because XFree86 / Xorg still performs like it's running on a circa 1993 dumb 1MB frame buffer. Video memory *is* actually useful for storing surfaces, rather than asking an application to redraw every time it's obscured/unobscured by anything. It's literally painful to use. Yes, literally.
I guess you never heard of X11 backing store. We were using that back in 1993.
Re: (Score:2, Insightful)
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 any
Re: (Score:2)
And yes I'd like my desktop to "draw shit to my screen fast and efficiently". Doing away with X11 will facilitate that. And for people who "like using X11" can continue to d
Re:Replace X? (Score:4, Informative)
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: (Score:2)
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.
Huge swathes of X are obsolete or unused, glyphs, logical fonts, rendering primitives, codemaps, and more. The fact you mention XRender means you recognize how obsolete X11 is yet all that shit must be implemented all the same.
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?
I can't even parse that. If you want backwards compatibility, install and run X11. Otherwise what do you mean? Most apps have minimal dependencies on raw X. There might be some which tap an API, or implicitly get stuck on X through GLX or similar. But most call GTK or QT. Moving to a
Re: (Score:3)
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 thin
Re: (Score:2)
Re: (Score:2)
so utterly wrong.
I like your rebuttal of my points. So well thought out.
no your wrong moran
Re: (Score:2)
Re: (Score:2)
It was clear to me that you were incapable of actually rebutting any of the points, which is what you failed to do first time round.
Re: (Score:2)
Proposing to get rid of it is not "esoteric" or "boredom", it's rational and pragmatic.
Prove it. [decision-m...idence.com] Extensively [decision-m...idence.com].
Re: (Score:2)
GNOME 3 does some things different then gnome 2. It's also clean and usable. I don't understand the public distaste for it...works for me! I'm sure there are others.
Re: (Score:2)
Re: (Score:2)
You can replace my X (Score:4, Funny)
Re: (Score:2)
Re: (Score:2)
And what stops you from writing a wayland renderer for X? Wine runs GDI programs under X, why not have some Wayland API shim that does the same thing?
Re: (Score:2)
Re: (Score:2)
X is hard, so most programs actually rely on a toolkit, like:
- GTK: Ported to Wayland
- Qt: Port in progress
- SDL: Port in progress
- EFL: Ported
- Wine: Port being considered
So you're right that nobody will write Wayland programs, but nobody writes X programs either.
Re: (Score:2)
"In reality this is not the case, so applications DO use particular display/graphics system peculiarities and therefore there is a difference."
In reality, this actually _is_ the case. Applications DO NOT use particular display/graphics system peculiarities.
Wayland Initial release :2008 (Score:4, Funny)
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 (Score:4, Informative)
Re:sigh (Score:4, Interesting)
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: (Score:2)
X on Quartz (OS X) actually works quite well. Copy/paste is not an issue.
The person to whom you're responding said a problem was "Copy/paste of more than text between X and non X" (emphasis mine). Can you, for example, copy an image from a Quartz app and paste it into an X11 app or vice versa?
Re: (Score:3)
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: (Score:2)
Will that work for all Wayland apps?/em.
Theoretically you could do the following:
Run a wayland compositor. Connect an X server to the compositor.
Now write a new compositor which uses X as the back end. Then connect any wayland apps to the new compositor.
That way you get to treat Wayland programs as X programs, and will get remoting and other things, except basically dumb pixel scraping remoting. And even more layers of fun.
Easier to stick with X, really.
Re:sigh (Score:4, Interesting)
Re: (Score:2)
So what's brain-damaged about X?
The font system. Not used much by modern code. Not brain damage, since it does not get in the way.
The drawing system---oh wait, once it's been augmneted with the XRender extension it still works pretty well.
The copy/paste/Xdnd system? Works great.
Window management scheme? Best in existence.
Remoting? Pretty decent and in need of some minor updates---but most programs written against it are brain damaged. Xlib is partly at fault, but Xcb solves the peoblems. Nothing fundemental
Re: (Score:3)
- 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 (
Re: (Score:2)
Now where's the Win32 port? (Score:2)
How many more years to we have to wait for a Win32 port of GTK+3? There are several projects which only have old versions ported to Windows because their newer builds target GTK+3 and that's not available yet.
Re: (Score:2)
Kill yourself.
mmm define (Score:2)
Smoothness (Score:2)
Re: (Score:2)
Has there been a Gtk release where theme compatibility was the only thing that broke? That sounds amazing!
(Why yes, I do write Gtk apps for a living, how did you know?)
Re: (Score:2)
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.
Re: (Score:2)
Doesn't matter. GTK dev's (and GNOME dev's) can't be trusted. I'll use QT from here on.
Didn't QT announce support for Wayland, too?