On Saturday evening Matthias Ettrich, director of Qt development, gave within a talk at the KDE Developers' Conference 2003 in Nové Hrady -- besides a presentation of the company, the KDE/FreeQt Foundation and the past and present of the Qt development toolkit -- an outlook on Qt 4. Qt 4 is expected to be released in 2004 and promises to deliver increased performance, both at startup and runtime, more flexibility and productivity and changes to ease the learning process. Read more excerpts from the slides shown with the help of Matthias' home-brewn presentation program.
Qt 4 mostly tries to preserve source-compatibility with a little search and replace and a COMPAT compilation switch. More porting will be required for styles and code that uses the meta object system directly.
The increased startup performance will be reached through reduced number of symbols, less read/write data and fewer static initiliazers. Fewer mallocs, faster and more optimised tool classes and reduced memory consumption will improve the runtime performance enabling Qt 4 to run on embedded devices that are slower and have less memory than today's desktop computers too.
To back up these statements Matthias gave some numbers about Qt Designer which was ported to Qt 4 with only the necessary changes to make it compile: The libqt size decreased by 5%, Designer num relocs went down by 30%, mallocs use by 51%, and memory use by 15%. The measured Designer startup time went down by 18%.
Qt 4 will not be one library, but consists of many allowing finer granulation:
- Qt Kernel lib comprising tool, io, thread classes and QObject/QKernelApplication
- Qt GUI lib with QApplication, widgets, painter
- Others libs for network, XML, SQL, openGL and other purposes
Included among the presented planned features of Qt 4 as of today are:
- Designer split up into components. This makes it possible to create a form editor plugin for KDevelop.
- Model/view classes for list box, tree view, icon view and table
- New set of classes as part of a main window/docking architecture that distinguish between dockwindows and toolbars with support for tabbed docks.
- Accessibility support for the Macintosh platform and for ATK.
- Pixmap resource system
- Several API cleanups like unifying different APIs and reducing number of concepts aim to simplify common usage, increase flexibility and remove embarassements.
- New meta object code with static read-only data block (no constructors, no cleanup handlers, no relocations, no symbols) with significantly less generated code and minimal connect() memory overhead.
- Better connect() syntax
- New cast qt_cast(const QObject*) makes string-based QObject::inherits() obsolete.
- A new class QPointer, which is successing QGuardedPtr, is lighter and faster.
- The event filters were fixed and are now called from QApplication::notify() instead from QObject::event()
- The threaded library will be the default with more thread-safety/reentrancy. Atomic refcounting makes QDeepCopy superfluous.
- In the styles section the palette and background handling has been revised: A backgroundPolicy was introduced with non-toplevel widgets inheriting their background (policy) from the parent widget. Parents can propagate their content to child-widgets. This shall essentially give (semi)transparency for widgets. And last but not least system-wide double-buffering will allow flicker free update without any hacks at all.
Qt 4 will introduce a new consistent set of light, safe and easy to use value based container tool classes which are implicitly shared and highly optimised, both for speed and memory usage. Using them will expand to less code compared to Qt 3.x and STL which will stay available for further usage together with Qt.
QString and QByteArray were both optimised for performance and memory usage besides API improvements. An important change is that isNull() is dead and will be only available in compatibility mode. Functions like latin1() will always return a valid and never a null pointer. This change led to quite some discussion and aversions among the KDE developers but Matthias pointed out that there still will be isEmpty() and operator!().
Qt 4 shall be available within a year, with a short public Beta period next year before the final release. Among the open questions Matthias addressed to the KDE developers were if KDE will switch to Qt 4 and if so when, when KDE switches who does the initial port and where, and will KDE use the opportunity to refactor some of its architecture too? In return many KDE developers will, during the hackfast week, ask Trolltech developers for additions of classes and functionality which they find long-term missing and required by KDE.
Comments
In the current KDE CVS code base there and many remarks throught the code of depreciated classes or functions. When KDE4 is released these will be removed/fixed. This should provide a nice memory reduction along with making things cleaner.
-Benjamin Meyer
Can and have to those questions already be answered? KDE HEAD cannot switch to Qt4 until at least a Beta version is available, KDE cannot plan to make a release based on Qt4 if the Qt 4 Final release date is unknown. The work will be done by those who have time then, it will likely happen in HEAD and the architecture refactored.
Yes!! I have been waiting for the gui / non-gui separation. Finally, using Qt in server applications will become a real possibility. And yes I know of TinyQ, but it lacks QObject (and thus the event loop), which Qt 4 will have in the kernel portion. Good stuff!
You know you just have to pass false to the QApplications constructor to disable GUI, right?
Yep, that's what I do now. The problem is that I still have to bag the whole Qt library, which requires X11 to compile and run, even if I don't use those parts.
How good would Qt be at, for example, developing a mail/calendaring/messaging server in? So instead of having Kroupware, which consists of a bunch of third-party servers, you could have a Qt-native groupware server sharing many of the same features supported by the client (Kontact).
It would seem Qt's networking support is pretty advanced based on the amount of different KIO protocols that have been developed...
Eron
>>How good would Qt be at, for example, developing a mail/calendaring/messaging server in?<<
Should be good enough. Qt's networking support is indeed a weak spot, but it should be enough for TCP. Otherwise you could use thiagom's libqtaddon for this, or in the worst case the low-level socket api. And anyway, networking is just a tiny, almost negligible aspect of servers like that. TCP is trivial, the hard part is to implement the protocol and the data store.
have you not used glib or curses before?
The biggest problem with the Qt event loop is that there is only one per application. If you have a multi-threaded program with persistent threads, then it is likely that each thread will need it's own event loop.
I have written my own solution based on sigwait(), but it's a pain in the ass to keep hacking it in to each new version of Qt.
i would also like to see better support for vector graphics...
Okay, this was promised forver now and this has to be one fo the most important things that Trolltech can do for DE developers. On every other platforms upported by Qt, error messages native, file dialogs are native etc. and yet on KDE the platform that is actually freaking built on Qt, we don't even have consistent file dialogs between Qt and KDE!! THIS IS RIDICULOUS! There has to be something done about this as was promised about a year ago!
Exactly the fact that KDE is build on Qt is what complicates this, AFAIK. You will get circular dependencies. Maybe that would be solvable in runtime?
You should read the story before about the Kastle workshops carefully.
You might want to have a look at this new QtDirectFB screenshot:
http://www.directfb.org/screenshots/FirstQt.png
I'm really looking forward to having the KDE libraries independent from QtX11.
Best Regards,
Denis Oliver Kropp
I read Microsoft is going to introduce allot of animation using hardware accelleration for their Longhorn. Will this also be possible with all this?
I find this interesting since I am not aware of active resarch on this, it seems Longhorn will steel the show on window animations. Please correct me if I'm wrong.
Du you relly need a jumping OK button?
There are plenty of plans to get better eye candy on X11.
Probably the most likely to succeed is plans to turn the OpenGL and X relationship inside out.
This would mean an X driver that uses OpenGL for all 2d operations, and hopefully splitting out hardware initialisation like mode switching etc.
Obviously it would still be possible for lower end systems not to use this, etc etc. We aren't going to kill your ipaq or P133 or whatever.
For this to be acceptable for all uses, some colour profile and optional high precision rendering work must go into OpenGL.
The next stage would be retooling the toolkits to draw directly with GL.
All this is long term, and probably dependent entirely on volunteers, so don't hold your breath.
By now I have said this a couple of times on these boards, KDE WILL be doing (several) Microsoft catch ups 'again'. Not many developers really care about this, but it does reveal some bad aspects of how KDE is almost entirely dependant on (often jobless) volunteers. Holding ones breath for features is therefor often routine. Yes it works, but more and more open source projects themselves will have to 'compete' on how they manage themselves.
About Longhorns new GUI, most developers respond with that MS will probably implement Apple GUI features. I believe this is true - to some extend. MS has created a 'new' GDI code-named Aero. I bet allot of research is going into this and the developers are experimenting/toying allot with it. (with research I mean: what animations will help improve the windowing and make it easier to navigate) It will do what DirectFB, X11, Qt only promise to do.
One reaction on this board is: "Do you rely need a jumping OK button?". Such a mindset is so absolutely appalling when it comes to vision and progress of usability! Tell that to some Microsoft developers working on Longhorn and you will look so silly and irrelevant in your green dragon shirt.
I am relatively new to Open Source, but how can KDE ever provide innovations trough _ongoing_ research? Isn't this an inherently impossible thing to do with KDE-Open Source and only possible with solid fundings?
The thing which just 'bothers' me is that now many developers are nay saying and when Longhorn comes out, you bet there will be catching up (again) and then they are stuck with X11 or some hack. Key to the issue is that Microsoft did research and KDE could only do catch up and eventually innovate from its new gained abilities.
Its almost paradoxical, calling an open source desktop superior, while admitting there are shortcomings due to dependence on developer volunteering. Is there such a thing as "KDE research"? And if there is, would it be like KDE-usability, totally dependand on volunteers who seem to update their site 1 time a month (if not half a year)?
Open Source projects could improve in the organization/management beyond the developer organization. I truly believe that and am myself working on projects which are more concentrated on organization/managing of open source projects. The beauty is that these projects are all based on GPL software for web code.
One thing management should ensure is that any developer yelling "Do you rely need a jumping OK button?" will fall flat on his face and will be buried in visionary open source _competition_. Yes it already is that case, but it would be better to have less developers waste less time on pre-doomed mindsets. Key to all this is project alignment.
I believe we will begin seeing a trend where projects will emerge which don't necessarily develop open source code, but who will develop open source "supportive services". Kind of like sourceforge but then stretched to other fields - all serving a supportive role for open source.
Anyway, enough rant here is a possible informative link about Longhorn: http://www.winsupersite.com/showcase/longhorn_preview_2003.asp
With respect, AC, I think you may be overly optimistic about what Longhorn's graphical features will entail.
In the very, very long term, full 3D desktops might be desireable, but that would be in CAVEs and systems capable of offering the user an interactive 3D experience. A monitor is inherently 2D, and with the best will in the world, making each window a surface offers very few advantages. It essentially allows you to do window effects. If you look at OSX, you'll see clearly that it is used to shrink the window to a thumbnail in real time (looks like the window is being poured down a funnel) and a few other things, all of which are eye candy, and that is the most evident example. In fact, the only Quartz effect I have ever seen that is useful is the one in Panther, where you can shrink your windows on the desktop, so that you can zoom out and get a better look at all your work. Even this is of limited used, since the OSX gui limits users who want to open large numbers of windows and Quartz itself cripples the machine with large numbers of windows, simply because it allocates a full framebuffer-sized chunk of memory per window. Longhorn essentially wants to be able to play around with windows in the same way as OSX, with fancy effects. It isn't a productivity improvement or usability enhancement for the most part (the zooming being the only exception).
Moreover, if you look at Longhorn, their other features are:
- The bar becomes a PocketPC-type today application. Karamaba already does this, and on the larger space of the desktop. People have been trying to empty the desktop for years, but to what purpose? Karamba solves that question.
- WinFS, the meta-searching of the file system. It's not actually a filesystem itself, just a search service over the top. Downsides:
-- You need and SQL server always running in memory
-- Your SQL server needs the contents of every file you want to index.
-- You get namespace collisions
-- You're trying to map a heirarchical filesystem to and from a relatonal db.
-- Users don't want to try and Google for their files based on a phrase they think they added to it six months ago. They want to have a folder with an obvious name, and find files beneath that, even the ones they had forgotten.
-- Users don't want to have to deal with adding metadata every time they save a file.
Aside from making the UI a bit more cute and shipping the .NET virtual machine with it, that's Longhorn in a nutshell.
There is nothing there that users actually need. There is nothing there that improves their workflow. Essentially, since windows 95 and office 95, nothing has changed in windows to improve the life of users. USB is the only thing I can think of that has benefitted me, and we all know how unstable windows' USB handling is, especially when hotplugging.
KDE and Linux have now reached a point where they are fully usable on the desktop and are free to innovate further, while windows effectively sits where it is. I think it would be a complete travesty to simply mimic Longhorn, when there are more worthwhile things out there to do. ReiserFS 4, ACLs, tabbed browsing, cards, Umbrello and many others are examples of opensource projects really forging ahead and giving benefits to their users. That is just a taster of a very long list of applications and projects. This is where open source research is at the moment.
Final note; one of the problems we really do have is the assumption that because Apple and MS do something, they've put money and research behind it and it is the right thing to do. On usability, the suggestion that Apple always do what is best for usability is alarming, but it keeps on coming up. Be wary of such assumptions...
I was not referring to a 3D GUI experience here ;) Likely because I am not too good at constructing my thought in English (am dutch using a spell checker) and I am better at coding anyway. I was referring to using the hardware for animated windows themselves, not an interface with 3 axis's. Eye candy and pure usability benefits might breed each other.
_I_ do not expect much exciting new features from Longhorn actually, however the large drones of window users are easily mind bended again and again. We look at it from a much different perspective. Their research capabilities do help them in their favor and I do expect to see some good features from a usability point of view - I could be wrong off coarse!
All I wanted to get at is that having a window as a surface it becomes (new English word I guess) animationable. One can have GUI specialists play with that and come up with innovative features you and I might not expect. That procedure is less likely to happen in the open source environment unless someone develops it in the first place - I think it shows an obstacle for research opportunity, altough my example may be a bad one. I think it applies for several fields in open source.
Your references to all those projects, I was aware of those yes and they are exactly pointing to great open source things happening because of the open source model. What I am getting at is supportive projects for open source projects which I believe can go hand in hand and solve the problem of research I tried bring up.
I'm better at being practical than ranting, so I am going back to work now ;)
AC
>> All I wanted to get at is that having a window as a surface it becomes (new English word I guess) animationable.
'animatable'.. ;)
And yes, it would definitely make up for some very interesting effects when having the ability to apply xforms to windows or whatever.
I don't think XFree86 will ever be able to do that though.. (not even using cairo)
It's too old for that.
So what if it becomes even more clear that X11 cannot handle tomorrow's desktops and there will be real need for OpenGL accellerated windowing system, what then?
Sure you might argue that there is no need right now, and sure that is partially true (well atleast I would love to be able to show off Linux desktop to my Apple and my friends using Apple) but should the Qt4/KDE4 to be designed for the future or for today's hardware and software requirements? I think the only right way for that is to plan to use pure OpenGL as everyone else (like Apple with their Quartz Extreme is doing right now and Longhorn is also going to use it) are and Linux community is going to need to get it done!
So is there any already evaluated windowing systems that might fit the bill? Sure there are some but they are on pretty alpha stage but should there be some chosen system that would surely get more attention in the future?
>>So what if it becomes even more clear that X11 cannot handle tomorrow's desktops and there will be real need for OpenGL accellerated windowing system, what then?<<
When did it become clear? X11 does not prevent you at all from using a MacOS X-like, OpenGL based rendering system, at least not at the application level. The apps still render their windows and get their events like they did in the last 20 years. They may use classic X11 functions, new X11 extensions like Cairo graphics or OpenGL over GLX, but they still use rectangular windows as primitives.
The window manager may need to be aware of such a composition system (obviously, current X11 can not transform windows), but not the apps. And even that could be done using a X11 extension, no need to replace X11.
I will never understand why people are so eager to throw away the X11 system, even though they have yet to show a feature that X11 could not do - the only problem are implementations, not the protocol.
>>>>I will never understand why people are so eager to throw away the X11 system, even though they have yet to show a feature that X11 could not do - the only problem are implementations, not the protocol
I think this is related to the fact that not everybody understands how X is designed. Most people observe X is almost always causing troubles and causing literal headaches when setting up (refresh rate). Improving its setup procedure might remove most of the bitter experiences people now face with X.
Of course X does not prevent you from doing whatever you want. When you get down to it X is basically a blown up graphics driver. You can pile everything on top of that, you can do all desired effects, etc. Nobody is arguing that point.
But why would you want to? Why are you using languages like C++, Smalltalk or whatnot instead of Assembler? Because you don't want to be bothered with all the bit-pushing that's going on behind the scenes. The same is true with X windows: Who does actually develop for it nowadays? Nobody! All the developers are building their work on toolkits that could be run on any other graphics driver as well (probably better than on X, too:-) or on APIs better suited for their purposes like OpenGL, libArt or some SVG library.
Users don't care about the low level stuff, they still stick with X since all their applications happen to run on that 'driver'. If they switch to something else they are bound to loose some of their favorite applications.
Don't get me wrong: I do use X and I even like it a lot. It is a revolutionary product! But it is time to start to think about what could happen in the past-X(11R6) age. That could be something new like fresco (www.fresco.org) or picogui (www.picogui.org), it will most likely be X as we know it with some more extensions clobbered on or it could be DirectFB/Qt (I'd hate having that, networktransparency rocks) or something completely different!
Anyway, what made me post this is that I hate those "This is great and needs no fixing" attitude. Nothing is perfect, not even X. Why are you so rough to people trying to think out of the box? They could very well come up with some good ideas... which might result in some X successor, however that may look like.
I for one thing have a graphics card that has 10 times the clockspeed of my first PC's CPU. I payed for that power, I want it used. Of course I'd prefer something productive, but I'll settle for eye candy;-) If X can't do that - and as of today it can't - I'm looking for other projects and try to help those along.
>>All the developers are building their work on toolkits that could be run on any other graphics driver as well (probably better than on X, too:-) or on APIs better suited for their purposes like OpenGL, libArt or some SVG library.<<
Toolkits are layers on top of X11, and there are good reasons for layering them. The most important ones, probably, are that a) layering increases flexibility and b) the relative simplicity of X11 makes things like NX possible. To use a analogy myself, an approach like Frisco is like improving HTTP by getting rid of TCP and writing an alternative that provides the functionality of HTTP over TCP.
If there is *functionality*, including eye candy, that can not be transported using X11 and its extensions, you could easily convince me that it is a good idea to work on a second protocol. But I don't see it a point as long as the user does not notice any difference except that the old applications don't work anymore. If you start the post-X11 era, you should have a compelling reason for this.
Integrating widgets on the server side in a way that's less flexible than DPS rather limits the capabilities of the window system than increases them. There are still, and always will be, applications that do not want your widget kit and provide their own. Examples are emulators like Wine, and apps that want their own widgets for eye candy reasons (games are the no 1 example, but just look how many Windows apps do not use the Windows widgets).
>> Toolkits are layers on top of X11, and there are good reasons for layering them. <<
You are right. My point is that with every application depending on the top layer only, what stops you from even considering switching the bottom layer? That's exactly the increased flexibility you gain by layering! Why are you so much against someone even bringing up the topic?
>> To use a analogy myself, an approach like Frisco is like improving HTTP by getting rid of TCP and writing an alternative that provides the functionality of HTTP over TCP. <<
To stay in the layer-paradigm ou have brought up: Fresco is a set of interfaces defined on top of CORBA which in turn is a protocol defined on top of (among others) TCP/IP. So your analogy should be more like "improving HTTP by replacing it with something more powerful on top of SOAP on top of TCP." with SOAP and TCP being widely adopted standards.
>> If there is *functionality*, including eye candy, that can not be transported using X11 and its extensions, you could easily convince me [...] <<
Device independence, resolution independence, vector-based rendering, 3D capable desktop, and most important of all a consistent look and feel of applications, even while keeping the configurability we all know and love. Just to name a few...
Of course nobody is stopping you from adding all that to X via some extension. We decided not to work on an X extension for a simple reason: All X could do for us is access to the graphics card. We can get that in a more flexible way by using SDL/GGI/DirectFB/GLUT, some of them being able to run inside X or outside. The same is true for input devices. Network/language transparency? We get that for free from using CORBA, a technology necessary to have all the objects communicate (no, we will not replace CORBA, we need all it offers; no, something you need is not bloat; yes, CORBA is slower than sockets but because our architecture is way different from what X does that impacts performance far less then you might think; no, we cannot remove CORBA and replace it with something else). We need to do our own focus- and fonthandling, etc., so why on earth should we limit ourself to being an X extension? Fresco is less then 200K lines of code... why dock that onto a 2M lines of code XFree-monster for that little it offers to us? Right now that would hinder more then it would help.
Anyway: The important issue is that someone is trying out new things in free software and that the code is there. Take the code and turn it into an X extension if you think that's better than what we do. It doesen't matter to me what it is actually called and where it ends up getting used. What matters to me is that someone is experimenting.
>> [...] that it is a good idea to work on a second protocol. <<
We aren't. The protocol is defined by the OMG as part of CORBA and is called IOP. We just provide a set of interfaces on top of this protocol. That's not much different from what KDE and Trolltech do by providing their libraries using the X protocol.
>> If you start the post-X11 era, you should have a compelling reason for this. <<
No, you need a compelling reason not to want to improve on what is already known. The spirit of invention driving human development and all;-)
I am further not starting the post-X era, neither is anyone else in Fresco. We are just trying out some (not that new but still untried) ideas. But then who could claim more for those guys at MIT originally writing X? ;-)
>> Integrating widgets on the server side in a way that's less flexible than DPS rather limits the capabilities of the window system than increases them. <<
Correct. That's why we are not doing it.
>> There are still, and always will be, applications that do not want your widget kit and provide their own. <<
.. which of course they can in Fresco. We just try to discourage that as much as possible, just like Apple, Microsoft and probably KDE, too. And since our concept of a widget, being just some collection of graphics (like everything else on the screen) is way more flexible than the "each widget is a object with hardcoded attributes" used in traditional X toolkits, we are convinced that there is less need for custom widgets.
If you insist on using your own widgets you can, building them up from the same basic building blocks as the 'default' widgets. That is some work of course (not more then inheriting the basic functionality and extending it) and maybe someone will write up a "GUI painter" for that purpose someday... with the GUI consisting of the same elements as a graphics view that will be really easy. Well, there goes the consistency... ;-)
>> Examples are emulators like Wine, and apps that want their own widgets for eye candy reasons <<
The eye-candy reasons does not hold in Fresco:-) If a user wants eye candz he can just replace the admittedly ugly MotifKit with a (to be written) "Fully3DTexturizedMeshesWidgetKit" on his system and he will have eye candy widgets for all his applications. The look and feel can be freely changed by the *user* in Fresco (in X the developer selects the look and feel and might offer some themeability so that the user won't notice this too much;-), all Fresco does is making sure that all applications (that do use the normal interfaces to produce their widgets) look and feel the same.
>> (games are the no 1 example, but just look how many Windows apps do not use the Windows widgets) <<
I do not consider games a no 1 example: They tend to run fullscreen and need all the power the graphics card can deliver, so they usually go around the GUI environment as much as possible. So I don't see much need to discuss games in this context.
Some words about compatibility: You can extend X and you will end up with something else (let's call it Y for now). Anything written for Y won't run on X: backward compatibility is broken. Of course any X application will work on Y, too. That's great and a absolute must have if you ever want to think about replacing X.
But what about writting something (let's call it Fresco here) and implementing a X server in it? Any Fresco application won't work on X, but you could still run X apps on top of Fresco in the embedded X-server. So how does this differ from an extended X from a users point of view? That this is a feastable option was proven by Apple: It is what they have done with there MacOSX GUI.
> My point is that with every application depending on the top
> layer only, what stops you from even considering switching the bottom
> layer?
There are many top layers that people do not want to miss. Toolkits like Qt, GTK and XUL are very different and the holy grail of widget theming is still to implement a widget style that runs at least on Qt and GTK. So do you want to support only one toolkit, modify at least one of their APIs enough that you can use a single widget implementation or try to write one that is so flexible that it works with both?
And, of course, beside regular toolkits there are other challenges like SDL, apps that use XLib directly for various reasons and statically linked binaries, especially for commercial apps.
> Why are you so much against someone even bringing up the topic?
Sorry, I just heard way too often that dropping X11 solves all problems. And I never saw any proposal (or even code) that solved more problems than it created.
> All X could do for us is access to the graphics card.
It would also offer a communication middleware that is very well known and analyzed, for example regarding performance issues. I don't think that such a amount of research has gone into any CORBA-based rendering system (or maybe even CORBA for applications with real-time characteristics).
> why dock that onto a 2M lines of code XFree-monster for that little it offers
> to us?
While I can understand detesting XFree's (or X.org's) prehistoric code base, it cumulates a lot of experience and code for using graphics hardware on hundreds of different architectures, and is the only widely used X11 implementation. If you want to implement any X11 emulation you would have an hard time to emulate X.org's exact behaviour.
Proprietary drivers for NVidia cards are also a showstopper for everything that does not use XFree's driver model (there is no chance to get people use an OpenGL-based system without NVidia support).
You know what's the whole issue with XFree86?
IT IS TOO OLD AND NOT FLEXIBLE for todays standards (!)
Having said that, see the following comparison:
* setting resolution (@ runtime)
DFB: IDirectFB::SetVideoMode
XFree86: Use XRandr, depth cannot be set
* render an alpha blended rectangle
DFB: IDirectFBSurface::SetDrawingFlags, IDirectFBSurface::FillRectangle
XFree86: Use XRender (or Cairo, which usually uses XRender implicitly)
* getting an OpenGL surface for doing 3D graphics
DFB: IDirectFBSurface::GetGL
XFree86: Use a mix of GLX and X
* double or triple buffering of window surfaces
DFB: Automatic
XFree86: Backing store (b0rked, so not usable)
* documentation
DFB: Nice and easy
XFree86: Boring and hard to read/understand
* system integration
DFB: Boot kernel in graphical mode -> jump right into the desktop (nice!)
XFree86: Boot, mode switch, mode switch, mode switch, ... (ugly & unprofessional looking)
It's just the small things, but as you can see; one very important thing is that DirectFB can do things using a nice API without using yet another library/extension, thanks to the non-dependency on X11.
And not only that, it's also just too easy to create a slow GUI (that is, without Gtk or Qt, though even both these toolkits are still making some mistakes -> see perf docs from KP and that guy @ HP) using XFree86, which is partly the fault of X11 and partly the fault of XFree86 not being improved anymore (for the last few years (!)).
Another issue: the latest standards for eye candy (which is often very usable as well, not just for nice looks (ie. window drop shadows)) are very hard to do using XFree86 (nearly impossible without hacking away).
Using DirectFB it's much easier.. eg. I don't think it would be hard to create genie-like window effects using DFB.
Oh, and writing a driver for DirectFB is also a far more pleasing experience.
It's time for something fresh...
write back when I can use my NV Gf4 at reasonable speeds on DFB
>IT IS TOO OLD AND NOT FLEXIBLE for todays standards.
Then the easiest solution is to improve it.
>> Then the easiest solution is to improve it.
Probably not, as no person or even group of coders has/have succeeded in doing that the last few years..
AFAIK no one tried. And by creating something from scratch things won't be easier, because you probably want more features than the 2 millions lines of code in XFree provide, not less.
It is easier to create something from scratch!
* You are not stuck to an stone-age (IT industry-wise) protocol
* You do not need to wade through heaps of code added for obsolete architectures
* You do not have to work with a display model that matched the hardware that was available over 10 years ago and needs all kinds of clutches to get adapted to modern 3D accelerator boards and such
* You get a clean set of interfaces instead of the extensions-mess we are seeing in X today with obsolete extensions being dragged through the releases and dozends of interfaces for basically the same functionality.
If throwing out 2 Mio. lines of working code scares you: Don't forget that the 2 Mio. lines of XFree code does include lots of rarely used clients, too which could go with no harm done to get replaced by KDE/Gnome apps providing the same functionality. Then throw out all those obsoleted extensions (only those marked as obsolete and those that never really worked anyway) and you get down to a surprisingly small SLOC count!
The only really interessting thing in XFree are the graphics drivers... and unfortunately those seem to be really hard to rip out due to heavy interdependencies with the rest of the code.
> You are not stuck to an stone-age (IT industry-wise) protocol
Then I would suggest you to stop using Internet, which is using
a protocol that predates X11 by a decade. Oh, while you are at it,
you may also consider dropping BSD, Linux and other Unix-like
operating systems which are essentially technology of the
late 1960's :-)
Networks got faster, sure, but the basic assumption of "shoving data in at one end and getting it out at the other" still holds.
Graphics hardware on the other hand went from "set a couple of its in some chunk of memory" to "Render a Mesh with a lamp setup at this position". With such a change of abstraction level something new might be in order, don't you think?
"You know what's the whole issue with XFree86?
IT IS TOO OLD AND NOT FLEXIBLE for todays standards (!)"
This is EXACTLY the argument people use against Unix based OSes, and frankly it's a load of bullshit.
Mac OS X has lineage that can be traced directly back to the original AT&T Unix, historic BSD, and CMU Mach, yet few people would argue that it is not flexible enough for today's standards.
MS Windows is older than X11 (though some of X11's underpinning concepts predate Windows) yet few people would argue that Windows is not flexible enough for today's standards.
The actual limitations inherent in the X11 protocol are fewer than in most contemporary graphics systems since it is conceptually quite abstracted from the hardware, so in fact it's less likely that X11 is going to be fundamentally unsuitable for any type of graphics rendering than, say... Windows.
Mac OS X's Quartz window system uses many of the same ideas for network transparency as well as a fundamentally inefficient PDF based language to represent graphics, yet seems to do quite well for itself in both the performance and flexibility stakes, as evidenced by it's use of eye-candy so rich you want to floss your eyes after watching it for half an hour.
When pointing your finger, you'd do well to remember that there are four more pointing somewhere else.
I totally agree with you. i just hope some day gnome and kde both will have a choice of running on either of X or DirectFB.
And with intel open sourcing its drivers i hope directfb gets the much needed hardware support.
"On usability, the suggestion that Apple always do what is best for usability is alarming, but it keeps on coming up. Be wary of such assumptions..."
I find it ironic that you complain about people claiming that people are constantly raising Apple as a bastion of usability. One only need look at GNOME and KDE's taskbar clones to see obvious evidence that people are in fact looking to Microsoft Windows for their cues for interface design when it comes time to implementation.
People are not suggesting that Apple is a holy grail of usability, but that people should look at other environments rather than simply re-implementing Microsoft's interface because they lack imagination, or in the misguided belief that this makes it easier for people who have already used Windows.
My experience, and something that I recall reading from Sun's usability studies, is that when you clone the appearance of something, they expect that you would clone the behaviour as well. When this is not the case, the experience is very jarring and irritating.
Imagine getting into a car, and finding that the pedals are used to steer, and the steering wheel does not move side to side, but back and forth to control acceleration, and you have some idea of why this is.
I would prefer to see a user interface that isn't a clone of Classic MacOS, OS X or Windows, and is in fact a rethink of all that we have come to hold dear in computing, if the end result is better than what we have now.
I hold up Slicker and Enlightenment as examples of this kind of thing. You don't always win, but you also don't learn without making mistakes, and you don't innovate by copying.
Which I think brings us to the point you were trying to make. :)
Allot = a lot. Get it right, you product-of-society fucktard.
hahahahahahahaha
please rot :)
is very nice. Would it be possible to put the core qt lib under LGPL ?
This could make it first choice for portable non-gui tools, no matter which platform, no matter which purpose. And maybe it would make commercial developers more hungry for the other Qt libs :-)
Bye
Alex
Mod parent up! :)
Okay, just looked at this website: http://usability.kde.org/ What happened here? Why are all teh borders black?!
Today it's software patent decision day, that's why.
(ie. many websites are set to black today because software patents can mean death to OSS - see http://www.kde.org )
Death to OSS, because Europe is the center of the world, right?
Get over yourself.
Nah, but old Europe could stay sane without this US patent stuff.
Go troll elsewhere.
Just what is your malfunction? You very often sound annoying, hostile, selfish and god knows what.
What's wrong with protesting against software patents? That is IMO a good thing to protest again, and I fail to see why you need to whine about it. But I guess that's the thing you do best: whine.
So go protest. But leave www.kde.org out of it. Actually, I am in favor of using our hotspot, a dot story, etc etc. But the redirect is just plain European^Wsilly.