This is "huge" only if you run KDE...

So apps written in Qt but run in, say, Gnome won't see any change in either redraw or memory footprint? Or Qt apps on windows? Honestly curious here.

No, all Qt apps will get the benefit, independent of whether you're running KDE or not. Windows apps too will be flickerless.

Article says that GUIs written in it will be more 'light-weight' regardless of the flicker effect, anyway.

Everyone should run KDE. (Not kidding)

This is "huge" only if you run KDE...

For the moment, yes. But the technique may spread to other software projects.

Why is this huge?

Because a whole lot of open source applications are built on Qt, thus a whole lot of applications will be improved, especially for people running linux. So this is pretty huge.

Ok, that's better.

I had no idea what Qt is except some vague idea that it's some kind of "window toolkit" or something to that effect.

It's big because (if i read the article correct) this move is going to make Qt apps much more responsive and flicker-free... which is a Good Thing.

Yes, but it's doing so by working around a bottleneck in the X-Server, rather than solving the problem. Since they don't have any control over the X-Server, they can't really do much about the problems that the x-Server causes, but better X-Servers are the answer, rather than working around their issues.

Currently, widgets feel slow and clunky in X. The sizing needs to synchronize with the server, which then redraws the widget. This is annoying, ugly, and really does noting for the user experience. In QT4.4, widgets will be lighter weight, by (it seems) bypassing X altogether and relying only on QT to draw them. This means lower memory usage, more responsive apps, and maybe, just maybe, cheaper development.

As an aside, I currently just have beryl scale the widget until I let go, then do the redraw. This makes things a little less beautiful, but it works a treat when you cant stand that flicker.

I removed the offending question. Sorry to offend.

How well will this work with screen readers and other accessibility software?

No stuttering.

This wont effect the accessiblity of Qt. It will work just as well as before which is quite good. For more information about Qt's accessibility support check out: http://doc.trolltech.com/4.3/accessible.html

Ohhhhh. It's not the end of Flickr, though.

I thought the story was about that too.

Ditto. I'm planning on ponying up the money for a premium account today, too. Whew.

The only consequent and necessary next step is therefore to bypass the X server and let Qt do the job.

That's worrying. Does that mean that Qt applications won't be as fully-featured as other ones - can I still run them over a remote X server, can I manage them the same way, or is it going to get screwy?

Well, surely the root window will still be a standard X window. But instead of containing hundreds of windows, it will only be a single window.

This is what Java has had for a while (like, a year).

Sadly, Java's widgets are as bad or worse than native ones. Writing your own widgets doesn't help if you suck at it.

IMHO Swing with a Windows or Gtk look+feel looks a lot better than SWT with funny layout (and lots of non-native widgets as well!), or than Qt, but other people might prefer Qt over Gtk, or think that Qt looks good on Windows, too.

Just from that viewpoint, I'd prefer NetBeans over Eclipse (for instance) any day (but not from the power they have).

I wasn't talking about appearances. I've tried to do real-time scaling as you resize the window. It's bad. It's really bad. It's also really unpredictable. It'll work fine for a little bit, then not work worth shit.

Do you use the garbage collectors made for real-time apps and have you read up on how to properly tweak them? What you describe sounds like a GC problem.

GUI is hardly an obscure task. It is frustrating how deep and involved the implementation of "attractive and responsive" GUI is in Java. Especially compared to competing technologies.

Not to take away from all that Java offers as an enterprise platform.

This sounds like incorrectly used Layout Managers.

Using a good look and feel can go a LONG way though. The Looks LAF from jgoodies runs pretty nice on 1.5+. Their forms layout and validation framework also make things much easier for most apps.

http://jgoodies.com/freeware/index.html

Edit: Saw your comment on real-time scaling... yeah that does blow.

GTK+ has had most of its widgets be window-less since 1997.

Also, note that they are resizing widgets inside a fullscreen window. If you resize a window you will still get flicker.

Am I the only one not very excited by this? X itself obviously needs to be fixed. The fact that TrollTech has a bandaid is nice for people using Qt and no one else.

This really strikes me more as evidence that X is a bad windowing system.

If the only way to get acceptable GUI performance is to hack around your GUI server, then something is wrong with the GUI server.

My first guess was they'd fixed the awful VSYNC issues with Compiz...but fixing QT makes me happy as well.

Welcome to windows 95.

WinXP flickers like crazy. You may not notice this normally but in VMWare it's very noticeable.

VISTA FTW, BITCHES!

You know, I think this is the first pro-Vista smack I've ever run across on programming reddit. I suppose it had to happen sooner or later.

Mac had double buffering since 1984.

Moving away from native windows isn’t done over the night.

Whoa, there! Are you saying you're creating AWT in C++ now?

I'm hugely confused, that's what's huge ;-)

but can it run fluxbox?

The existence of hardware accelerated desktops make this not as Huge! as some are trying to make it out to be.

For Example: http://www.youtube.com/watch?v=ViuJPRZh0oo

There are some seriously unbalanced people on this Internet.

Unbalanced peop