Gobject introspection does something similar to what moc does. Gobject introspection is a code generator that reads XML files and produces code from that. Moc takes similar information right out of the header. Both use that information to generate code.
Signals/Slots in Qt just make use of that information that moc generated. Note that Qt 5 does allow you to use signals/slots without that information as well. But you still need the information moc generates for other purposes (language bindings, introspection, some debugging tools use it, etc.).
Yeap. But Boost does not allow to inspect which signals/slots and properties are available on any given object. That is the information moc generates. Signals and slots in Qt just use that information, just as a host of other things including the language bindings, some runtime debugging tools and lots of other things.
Qt on the other hand is available in LGPL, GPL or proprietary licensed form. You are free to pick whatever works best for your project. I really fail to see how GTK can be better than that on the licensing front.
Sorry, but that is just not true: moc does add meta data on objects (their methods, properties, etc.) that is _not_ available in ANSI C++. Not even with C++11.
I would argue exactly the other way around: Qt is stand-alone and GTK is not. If you want to write any app you need more than the UI. You actually want the application to *do* something but render a couple of widgets.
With GTK you end up hunting down a host of glib/gnome based libraries, all with slightly different peculiarities and all of them coming with little useful documentation. How is that stand-alone? With Qt you get everything in one convenient package (and are still free to leave out the parts you do not need in your binary packages).
Qt is a C++ library: Any C++ compiler can compile it on a wide range of platforms. How would that be possible if Qt was written in a weird dialect?
Of course the object model leaks into the language bindings. How could it not be? The same is true for "object-oriented" libraries written in C.
Yes, even with Qt you can not get perfect cross-platform applications. You will need to some platform-specific code in any non-trivial application. That is perfectly possible in Qt... and it still gets you at least 90% of the way! That was the other reason for switching that Dirk gave in his presentation: That GTK does *not* run properly on windows nor on Mac. He claimed that some core GTK people are actually opposing the toolkit working on those platforms and that independent teams are trying to maintain the cross-platform parts as good as they can against a hostile core team.
Subsurface was cross-platform with GTK and it looked like shit on *all* platforms incl. Linux. The Qt port looks way better -- they could finally get the UI they wanted but could not manage to implement in GTK -- and works equally well on all three target platforms. Check the demo right in the middle of the video: Dirk shows of the new UI and contrasts it with the old one in pretty gory details. So, yes, Qt is not perfect, but it is pretty good nontheless:-)
Their new system is Qt based. I would not want to drag gnome dependencies into my Qt system if I could avoid it, too. even more so on a closed down device with limited resources like a phone. So they need to write a system settings app. It is only natural to use that on the desktop, too, especially when you want to sell the idea of "convergence".
Oh, come on: Qt2 was released 1999, Qt3 in 2001. Qt 3 is still supported in most distros, more that 10 years later! How much better than that can you get?
Porting from Qt3 to Qt4 was painful indeed, but that transition happened 7 years ago! That is a long, long time in IT. Also note that the upcoming Qt5 is mostly source compatible with Qt4: Even big apps like Qt Creator build using both Qt4 and Qt5 from the same code base.
Since the windows 7 announcement the following things happend in Qt land: The Qt SDK had mayor update, Qt Creator had a new release, Qt had some minor updates, the open governance program is in full swing, Qt 5 was announced with open planning, there is a Contributor Summit coming up to discuss all these changes with non-Nokia developers...
I can think of a couple like GStreamer and Telepathy, but in both cases the support isn't 100% yet. And both are really crossdesktop from the beginning (Telepathy is just a DBus spec after all)
Dunno about GStreamer, but Telepathy is a really broken spec that puts every pecularity of every protecol it ever thought about supporting into their apis. Considering that the only useable telepathy implementation is jabber at this time (in two different flavours) and hardly anything else works that project is a lot of hot air.
I was trying to explain what GUI consistency is all about and further claimed that this is a dream that can't be realized in the X-based world. I see that you do agree with me...
Saying that wanting a consistent GUI on my computer is like asking for MacOSX and Windows to share a GUI is rather hilarious though: I can not run Windows and MacOSX applications on one screen (at least without some virtual PC software) while I need to pick and mix KDE and Gnome and Motif-based and... applications in X windows all the time. I want good applications and can't wait for my desktop environment of choice to come up with something useable while a OKish application is available using a different toolkit.
That the applications are written in different programming languages and are using different communication mechanisms is of absolutly no interest to the user. Pointing to others and claiming that they are no better is no help either. So Linux can't have a consistent UI just because MS did not manage to come up with one or what is that supposed to mean?
The idea is that you start up MAS instead of whichever Networking sound solution you are using now. MAS is a stand alone server taht can run without X... in fact there are others you could use, but then MAS was developed with professional audio and video conferencing in mind (both needing low latencies) and MAS is has a solid suport from the X consortium behind it. Both are thing I most alternatives can not claim for themselves.
A consistent GUI allows for the things you learned in your word processor to be reused in your browser, e-mail client, etc. Thanks to the thousand of toolkits, desktop environments, support libraries, sound backends, printer support solutions, etc. that's plain impossible in X. So a user has to spend lots of time relearning how to do simple tasks for each application he uses (and mixing them up after learning them). That ruins productivity!
Wether someone runs one or onehundred word processors is absolutly irelevant to the GUI consistency discussion.
I guess MAS won't stream the silence created by your ususal XTerms in CD quality over the network:-)
If you don't have apps that output sound, then why should MAS waste bandwidth? It's not used! If your app does generate sound and you need to use it remotely then MAS streaming that over the network is surely not a waste of bandwidth, is it?
I've seen MAS demoed on a couple of shows already and I did like what I saw. They are aiming for professional quality sound delivery with extremly low latencies which definitly is a good thing. MAS of course is network transparent of course, but the network is just another input-/output device to MAS (like a soundcard), you don't have to use it for local playback. It is a handy feature though: You can pipe your sound to an effects mashine for processing, something that might come in handy in a professional environment.
Eclipse has the best CVS support I have seen so far. It helps resolving conflicts, figuring out which files to cvsignore, has great diffs, etc. Too bad that it has no support for good versioning systems (yet);-)
However I am quite dubious about actual "widgets" with user interface rules, based on work I did with NeWS.
Do you still have some documentation on NeWS? I've been looking all over the net for something but wasen't able to find much. I'd love to put up some links to documentation on NeWS on our website. We allready have a lot of other GUI systems covered. I don't really get where you are going with the rest of this paragraph, so I can't comment on this.
I also see this as locking us into user interface designs that will become obsolete.
We try to assume as little as possible about the objects getting created in the API. A button is "a objects that decorates a given graphic (label) reacts to some event executing a given command". The rest is an implementation detail: Wether that button is a simple rectangle or a 3D mesh with fancy lighting is of no interesst to the application.
The concept of a menu that controls a simple hierarchy could be outdated soon, already there is lots of interest in user-reprogrammable menus.
Fresco is concerned with displaying a menu (a set of given topics triggering given commands). Where those options come from is not the concern of a display server. To do reprogramable menus you need support in the client, the server will just make sure that all menus look and feel the same, no matter which program generated them. Of course some client-side library helping the developer to do reconfigureable menus is desireable. But how does that differ from let's say X?
I also expect window borders and titles to disappear if we can get the idea of them out of the server/window manager and into programs.
Why should a program be concerned with such implementation details? Why should a application developer care wether his program runs in fullscreen-only mode (no resize/move controls needed at all), in a classical windowing style (titlebars), in a style you propose (everything but the actual GUI elements of the application offeres the functionality of the titlebar) or a 3D VR environment (user just walks away).
Fresco can handle all thos estyles and probably lots more with ease, neatly separating the complete thing out into the "DesktopKit" (in X-terminology: WindowManager).
And I'm sure many other changes can happen that I have not thought of.
That's why we try to keep fresco as flexible as possible, trying to avoid "hidden assumption" like that we are rely on pixels, run on a 2D workspace, have a mouse and a keyboard only. run singleheaded or interactive,... . That way there is very little need to hack on an extension to get around those assumptions once we discover that those were too restrictive. Only time will tell how successful we are with our struggle of course.
Re:The problem of rewriting/forking XFree
on
XFree86 Politics
·
· Score: 1
And how is X11 not "configurable", "device independent", and "language transparent"? With XRENDER, X11 also supports resolution independent vector graphics.
As you pointed out it is the toolkits that are configurable since X is just a network transparent graphics driver. X is not device independent in any way: You cannot just print what you see on your display (except for ugly screenshots, those don't count). That Xrender offers a bit of resolution independet vector graphics is a completly different thing: That's yet another of those half-way solutions you get in X all over the place. Of course there's the Xprint extension in the works...
X11 has supported stereoscopic displays, virtual reality input gloves, and display hardware you probably haven't even thought of for more than a decade.
How so? Supporting does not mean "can have OpenGL go around all the infrastructure X offers". You can have a application running on X that can access (parts of) the screen via a completly different API in 3D mode. That won't even work over the network.
As for input hardware: There's the Xinput extension that can support a wide array of input devices. It's one of the best extensions there is in X IMHO. But even that gets accessed differently form the core-devices (5 button mouse and keyboard), thus making programms like imwheel necessary to map additional mousebuttons to key combinations, etc. It does not really work too well with many programs and so far I have not seen a dataglove or similarly complex device that was accessed via Xinput. So far it's been all done by drivers build into the applciation itself accessing some device-file directly. Well, you can't blame X for this ommision of the application developers of course:-)
[CORBA] It's far from "free": for the generality it offers, you pay a heavy price in terms of complexity and overhead.
Yes, CORBA is complex. It does have a lot of overhead necessary in the heterogenious remote computing case which has to be done in such an environment and can get "shortcircuited" when running locally. With fresco all the important stuff (rendering) is running locally, so we pay way less of the "CORBA price" then you are obviously thinking. Apart from that there's nothing freely available besides CORBA that can do what we need.
That claim doesn't make sense because X11 doesn't have a "look and feel" to influence.
Right. I was refering to the X-based desktops users know from today.
It can be as consistent and rigid as you like (CDE+Motif apps), or as flexible and diverse as you like (a wild mix of applications).
This whole consistency thing is not about what I like but about what is scientifically proven to make users more productive. X as we know it today makes it impossible to come up with a consistent environment, thus hindering users from being as productivbe as they could be.
Re:You have the right idea
on
XFree86 Politics
·
· Score: 4, Informative
The biggest thing you said that almost everybody else suggesting alternatives ignores is that an Xlib compatability library is needed.[...]
I fully agree that Xlib compatibility is very important, but that can't be the driving factor in a project that wants to replace X. Such an evolutionary approach is far better handled by extending X than by writting an replacement IMHO.
Several responses mention Fresco. However I feel that any attempt to put "toolkit" into the server is a bad idea, and will be rejected.
What makes you say it is a bad idea? We are not fixing the look nor feel of any object created, we just define a set of very generic interfaces to request certain kinds of objects (Buttons, lines, text,...). Developers can choose the level of abstraction that matches their need. Why should they care wether the Kit is loaded into the server or linked to the client?
First of all it makes it absolutely impossible to write such an emulation layer.
That's wrong.
Also despite claims to the contrary, it actually *increases* the amount of communication Why? Because widgets quickly grow complicated with many many cofiguration options and it gets COMPLICATED.
I absolutly fail to see your point.
You create a tree of graphic-objects that describe the look and feel of your application once. Afterwards there is NO communication between client and server anymore till the applciation updates its look or the user causes a change in the client's state. Usually not even events leave the server!
We tried remote-displaying our demo. Via Fresco the communication needed 1.9kBit/s (alive pings) after an initial burst to create all the necessary graphics, even while moving/resizing/scaling/... the windows. Doing the same using VNC to export the same demo at the same color depth and using the same screen-size up to 800kBit/s were used when doing those operations. We allow that factor of ~400 for unforseen complications;-)
You should further notice that individual graphics do not get complicated. Complex things are build up out of a couple of simpler graphics. This is *very* different from how both GTK and QT work and way more easy once you get used to thinking in terms of small building blocks.
Also Fresco lacks any attempt at the Xlib emulation library, so it is not going to be a viable replacement.
Yes, we are incompatible for now. Nobody is working on an Xlib emulation layer. It can be added and it will be added once Fresco becomes stable enough to hold its own. Nobody can use Fresco for serious work yet, so nobody will miss X compatibility. We'd still have to keep updating the code to keep in sync with the rest of Fresco, thus draining resources that can be put to far better use elsewhere, Doing such an emulation layer now would do more harm than good.
Re:Yes the window manager needs to go
on
XFree86 Politics
·
· Score: 1
To that ancient "inconsistent" argument I say it is totall BS and I challenge anybody to find a real user who is "confused" by the difference between a KDE and Gnome button or menu.
My parents are. I use linux/unix exclusively for a couple of years and even I get confused at times! The Look is not really the problem, the Feel is much more so: Sometimes menus stay open when you release the mousebutton, sometimes not, sometimes a scrollbar works as expected, sometimes you need to use different mousebuttons to scroll things. That is not that big a difference that I can't use programs, but ti is enough to break my concentration on the task I want done to focus on the UI. This change of focus is annoying like hell and slows me down.
Consistency is not about enableing users to figure out an application, it's about making them able to develop habits which can be performed subconcious. Such actions can be performed without losing the focus on the task at hand, thus increasing the productivity of the user.
Re:The problem of rewriting/forking XFree
on
XFree86 Politics
·
· Score: 1
What does "replacing X" have to do with forking XFree86?
Nothing. I was replying to the idea of DirectFB being an alternative to X.
And how is that [MacOS X] better?
It enforces a certain kind of Look and Feel (granted, that's because there's only one "ToolKit"). It can support way more features of modern graphics cards than X (OpenGL). I do consider vector graphics a huge plus too. Decent fonthandling (which admittedly is improving in X),...
And, again, what is supposed to be better about that [Fresco]?
Consistent look and feel, configurable, vector based, device independent, langauge transparent,... I'm not even starting on things like the option to support new hardware like autostereoskopic displays and VR/AR devices in a way that's consistent for 2D and 3D applications. Just saw some of those displays at the CeBit... they will hit the shelves soon. How is X prepared for such hardware?
I can't frankly think of a protocol that would be worse for client/server communication in a window system than CORBA.
CORBA is not a protocal, it's an architecture.
What's wrong with it? It gives network transparency and language transparency basically for free. It is by far not as slow as people claim and is the only system I know of powerful enough to fit our needs.
Yes, if we were doing client-server communication X-style CORBA would be a bad choice. We don't.
And I certainly don't want a window system that forces a particular GUI paradigm on me.
GUI Paradigm? You as a user can influence the Look and Feel of a application in way more ways then in X today. We try to put developer's into the direction of having them use our "ToolKits", but they may choose an abstraction level that best fits their needs best. Actually I think Fresco's much greater flexibility will allow to influence the GUI paradigm in much more detail then you currently can.
Re:The problem of rewriting/forking XFree
on
XFree86 Politics
·
· Score: 1
he extensibility of X11 is such that almost any addition can be made (or removed) with little problem.
What is X + ExtensionY? Is that still X? A application relying on ExtensionY will no longer run on plain X, will it?
With the current X11R6 standard comming out 1996 I keep wondering how many of todays cool new applciations will actually work on a server offering only what is part of the standard from back then...
X11 is good at what it does, a network transparent graphics protocol. Throwing this out would either require you to be tied to a single machine or rewrite much of X11 in any case.
Not really. Fresco is less then 190K lines of code. I am convinced that if you would reinplement it as an extension to X you wouldn't be able to reduce that number. That's one of the reasons we did not go that way.
Re:The problem of rewriting/forking XFree
on
XFree86 Politics
·
· Score: 1
Where do people get the idea that DirectFB is an alternative to X? It is a fast and good graphics library, just like SDL or GGI or some others! Just that you can run GDK on a graphics library does not make it a replacement for X.
I do think we need something to replace X, but that shouldn't be some more or less randomly picked graphics library. That's a step backward: You loose network transparency, which is a really cool feature and will become even cooler with the rise of mobile devices. You don't loose much more since X is itself not much more then a 2D centric graphics driver nowadays, but you are loosing the killing feature of X.
I think we should look more at what Apple does then on what happens to be at hand right now. Please help us getting projects like Fresco, PicoGUI and many others rolling (better). Those can turn into an alternative to X at some point -- they still have a long way to go of course -- but they do over significant improvements over X while keeping its strong points like configurability and networktransparency. Those projects are based on (runtime) switchable rendering backends that can use graphic libraries like DirectFB, GGI, SDL or others to do the actual work and thus profit from the work done by the devlopers working on those libraries.
I agree that we need some standard for hardware access. That shouldn't be tied to XFree though IMHO. If both Xfree and a new fork of it adhere to such a standard and thus can use the same drivers I don't mind them forking. In fact that will probably even improve the standard: Suddenly two project's needs will influence it, the interfaces must improve to accomodate both. The coupling of drivers into the display server will get reduced, maybe even to a level where still other projects like DirectFB, GGI or whatever will be able to use the same drivers as X! Now, that would bring us all a huge step forward.
I don't think the idea of community driven documentation is all that good. You wrote the program, you know how it works, so please document it! Users are great in pointing out areas you will need to improve, but they are not terrible good at writing the documentation in the first place: They don't know how your program works, so they have to guess (=> inaccurate documentation) or read and understand the code (=> usually start to develop themselves, forgetting about the documentation;-)
About a Wiki: Those tend to work rather well, contrary to what other people here claim. You need to monitor them regularly and frequently to catch all those changes by idiots that need to proof that a wiki is not secure (what a surprise! It's *editable webpages*, of course it is not!). That happens about once a month in our wiki or about 2000 times a day after being mentioned on slashdot (no, I won't give the URL here;-). Luckily most of those people are too stupid to da any real damage.
Anyway: I'd go for some annotation system like the one used by PHP and other projects where you have a fixed documantation text and users may add notes, ideas and questions to the static pages.
Slashdot Mirror
No, GTK does not do what moc does in C.
Gobject introspection does something similar to what moc does. Gobject introspection is a code generator that reads XML files and produces code from that. Moc takes similar information right out of the header. Both use that information to generate code.
Signals/Slots in Qt just make use of that information that moc generated. Note that Qt 5 does allow you to use signals/slots without that information as well. But you still need the information moc generates for other purposes (language bindings, introspection, some debugging tools use it, etc.).
Yeap. But Boost does not allow to inspect which signals/slots and properties are available on any given object.
That is the information moc generates. Signals and slots in Qt just use that information, just as a host of other things including the language bindings, some runtime debugging tools and lots of other things.
So Linus and Dirk are not compatible with 'old'-style linux users? That is hilarious.
Qt on the other hand is available in LGPL, GPL or proprietary licensed form. You are free to pick whatever works best for your project. I really fail to see how GTK can be better than that on the licensing front.
Sorry, but that is just not true: moc does add meta data on objects (their methods, properties, etc.) that is _not_ available in ANSI C++. Not even with C++11.
I would argue exactly the other way around: Qt is stand-alone and GTK is not. If you want to write any app you need more than the UI. You actually want the application to *do* something but render a couple of widgets.
With GTK you end up hunting down a host of glib/gnome based libraries, all with slightly different peculiarities and all of them coming with little useful documentation. How is that stand-alone? With Qt you get everything in one convenient package (and are still free to leave out the parts you do not need in your binary packages).
Qt is a C++ library: Any C++ compiler can compile it on a wide range of platforms. How would that be possible if Qt was written in a weird dialect?
Of course the object model leaks into the language bindings. How could it not be? The same is true for "object-oriented" libraries written in C.
Yes, even with Qt you can not get perfect cross-platform applications. You will need to some platform-specific code in any non-trivial application. That is perfectly possible in Qt... and it still gets you at least 90% of the way! That was the other reason for switching that Dirk gave in his presentation: That GTK does *not* run properly on windows nor on Mac. He claimed that some core GTK people are actually opposing the toolkit working on those platforms and that independent teams are trying to maintain the cross-platform parts as good as they can against a hostile core team.
Subsurface was cross-platform with GTK and it looked like shit on *all* platforms incl. Linux. The Qt port looks way better -- they could finally get the UI they wanted but could not manage to implement in GTK -- and works equally well on all three target platforms. Check the demo right in the middle of the video: Dirk shows of the new UI and contrasts it with the old one in pretty gory details. So, yes, Qt is not perfect, but it is pretty good nontheless:-)
Dirk stated in his presentation that this is his own, private opinion he is presenting here and not that of his employer Intel.
So the headline is technically correct, but that Dirk works for Intel is not relevant in this context at all.
Their new system is Qt based. I would not want to drag gnome dependencies into my Qt system if I could avoid it, too. even more so on a closed down device with limited resources like a phone. So they need to write a system settings app. It is only natural to use that on the desktop, too, especially when you want to sell the idea of "convergence".
Oh, come on: Qt2 was released 1999, Qt3 in 2001. Qt 3 is still supported in most distros, more that 10 years later! How much better than that can you get?
Porting from Qt3 to Qt4 was painful indeed, but that transition happened 7 years ago! That is a long, long time in IT. Also note that the upcoming Qt5 is mostly source compatible with Qt4: Even big apps like Qt Creator build using both Qt4 and Qt5 from the same code base.
Since the windows 7 announcement the following things happend in Qt land: The Qt SDK had mayor update, Qt Creator had a new release, Qt had some minor updates, the open governance program is in full swing, Qt 5 was announced with open planning, there is a Contributor Summit coming up to discuss all these changes with non-Nokia developers...
Yeap, Qt has all the hallmarks of a dead project!
I can think of a couple like GStreamer and Telepathy, but in both cases the support isn't 100% yet. And both are really crossdesktop from the beginning (Telepathy is just a DBus spec after all)
Dunno about GStreamer, but Telepathy is a really broken spec that puts every pecularity of every protecol it ever thought about supporting into their apis. Considering that the only useable telepathy implementation is jabber at this time (in two different flavours) and hardly anything else works that project is a lot of hot air.
I was trying to explain what GUI consistency is all about and further claimed that this is a dream that can't be realized in the X-based world. I see that you do agree with me...
... applications in X windows all the time. I want good applications and can't wait for my desktop environment of choice to come up with something useable while a OKish application is available using a different toolkit.
Saying that wanting a consistent GUI on my computer is like asking for MacOSX and Windows to share a GUI is rather hilarious though: I can not run Windows and MacOSX applications on one screen (at least without some virtual PC software) while I need to pick and mix KDE and Gnome and Motif-based and
That the applications are written in different programming languages and are using different communication mechanisms is of absolutly no interest to the user. Pointing to others and claiming that they are no better is no help either. So Linux can't have a consistent UI just because MS did not manage to come up with one or what is that supposed to mean?
The idea is that you start up MAS instead of whichever Networking sound solution you are using now. MAS is a stand alone server taht can run without X... in fact there are others you could use, but then MAS was developed with professional audio and video conferencing in mind (both needing low latencies) and MAS is has a solid suport from the X consortium behind it. Both are thing I most alternatives can not claim for themselves.
A consistent GUI allows for the things you learned in your word processor to be reused in your browser, e-mail client, etc. Thanks to the thousand of toolkits, desktop environments, support libraries, sound backends, printer support solutions, etc. that's plain impossible in X. So a user has to spend lots of time relearning how to do simple tasks for each application he uses (and mixing them up after learning them). That ruins productivity!
Wether someone runs one or onehundred word processors is absolutly irelevant to the GUI consistency discussion.
I guess MAS won't stream the silence created by your ususal XTerms in CD quality over the network:-)
If you don't have apps that output sound, then why should MAS waste bandwidth? It's not used! If your app does generate sound and you need to use it remotely then MAS streaming that over the network is surely not a waste of bandwidth, is it?
I've seen MAS demoed on a couple of shows already and I did like what I saw. They are aiming for professional quality sound delivery with extremly low latencies which definitly is a good thing. MAS of course is network transparent of course, but the network is just another input-/output device to MAS (like a soundcard), you don't have to use it for local playback. It is a handy feature though: You can pipe your sound to an effects mashine for processing, something that might come in handy in a professional environment.
Eclipse has the best CVS support I have seen so far. It helps resolving conflicts, figuring out which files to cvsignore, has great diffs, etc. Too bad that it has no support for good versioning systems (yet) ;-)
However I am quite dubious about actual "widgets" with user interface rules, based on work I did with NeWS.
... . That way there is very little need to hack on an extension to get around those assumptions once we discover that those were too restrictive. Only time will tell how successful we are with our struggle of course.
Do you still have some documentation on NeWS? I've been looking all over the net for something but wasen't able to find much. I'd love to put up some links to documentation on NeWS on our website. We allready have a lot of other GUI systems covered. I don't really get where you are going with the rest of this paragraph, so I can't comment on this.
I also see this as locking us into user interface designs that will become obsolete.
We try to assume as little as possible about the objects getting created in the API. A button is "a objects that decorates a given graphic (label) reacts to some event executing a given command". The rest is an implementation detail: Wether that button is a simple rectangle or a 3D mesh with fancy lighting is of no interesst to the application.
The concept of a menu that controls a simple hierarchy could be outdated soon, already there is lots of interest in user-reprogrammable menus.
Fresco is concerned with displaying a menu (a set of given topics triggering given commands). Where those options come from is not the concern of a display server. To do reprogramable menus you need support in the client, the server will just make sure that all menus look and feel the same, no matter which program generated them. Of course some client-side library helping the developer to do reconfigureable menus is desireable. But how does that differ from let's say X?
I also expect window borders and titles to disappear if we can get the idea of them out of the server/window manager and into programs.
Why should a program be concerned with such implementation details? Why should a application developer care wether his program runs in fullscreen-only mode (no resize/move controls needed at all), in a classical windowing style (titlebars), in a style you propose (everything but the actual GUI elements of the application offeres the functionality of the titlebar) or a 3D VR environment (user just walks away).
Fresco can handle all thos estyles and probably lots more with ease, neatly separating the complete thing out into the "DesktopKit" (in X-terminology: WindowManager).
And I'm sure many other changes can happen that I have not thought of.
That's why we try to keep fresco as flexible as possible, trying to avoid "hidden assumption" like that we are rely on pixels, run on a 2D workspace, have a mouse and a keyboard only. run singleheaded or interactive,
And how is X11 not "configurable", "device independent", and "language transparent"? With XRENDER, X11 also supports resolution independent vector graphics.
As you pointed out it is the toolkits that are configurable since X is just a network transparent graphics driver. X is not device independent in any way: You cannot just print what you see on your display (except for ugly screenshots, those don't count). That Xrender offers a bit of resolution independet vector graphics is a completly different thing: That's yet another of those half-way solutions you get in X all over the place. Of course there's the Xprint extension in the works...
X11 has supported stereoscopic displays, virtual reality input gloves, and display hardware you probably haven't even thought of for more than a decade.
How so? Supporting does not mean "can have OpenGL go around all the infrastructure X offers". You can have a application running on X that can access (parts of) the screen via a completly different API in 3D mode. That won't even work over the network.
As for input hardware: There's the Xinput extension that can support a wide array of input devices. It's one of the best extensions there is in X IMHO. But even that gets accessed differently form the core-devices (5 button mouse and keyboard), thus making programms like imwheel necessary to map additional mousebuttons to key combinations, etc. It does not really work too well with many programs and so far I have not seen a dataglove or similarly complex device that was accessed via Xinput. So far it's been all done by drivers build into the applciation itself accessing some device-file directly. Well, you can't blame X for this ommision of the application developers of course:-)
[CORBA] It's far from "free": for the generality it offers, you pay a heavy price in terms of complexity and overhead.
Yes, CORBA is complex. It does have a lot of overhead necessary in the heterogenious remote computing case which has to be done in such an environment and can get "shortcircuited" when running locally. With fresco all the important stuff (rendering) is running locally, so we pay way less of the "CORBA price" then you are obviously thinking. Apart from that there's nothing freely available besides CORBA that can do what we need.
That claim doesn't make sense because X11 doesn't have a "look and feel" to influence.
Right. I was refering to the X-based desktops users know from today.
It can be as consistent and rigid as you like (CDE+Motif apps), or as flexible and diverse as you like (a wild mix of applications).
This whole consistency thing is not about what I like but about what is scientifically proven to make users more productive. X as we know it today makes it impossible to come up with a consistent environment, thus hindering users from being as productivbe as they could be.
The biggest thing you said that almost everybody else suggesting alternatives ignores is that an Xlib compatability library is needed.[...]
...). Developers can choose the level of abstraction that matches their need. Why should they care wether the Kit is loaded into the server or linked to the client?
I fully agree that Xlib compatibility is very important, but that can't be the driving factor in a project that wants to replace X. Such an evolutionary approach is far better handled by extending X than by writting an replacement IMHO.
Several responses mention Fresco. However I feel that any attempt to put "toolkit" into the server is a bad idea, and will be rejected.
What makes you say it is a bad idea? We are not fixing the look nor feel of any object created, we just define a set of very generic interfaces to request certain kinds of objects (Buttons, lines, text,
First of all it makes it absolutely impossible to write such an emulation layer.
That's wrong.
Also despite claims to the contrary, it actually *increases* the amount of communication Why? Because widgets quickly grow complicated with many many cofiguration options and it gets COMPLICATED.
I absolutly fail to see your point.
You create a tree of graphic-objects that describe the look and feel of your application once. Afterwards there is NO communication between client and server anymore till the applciation updates its look or the user causes a change in the client's state. Usually not even events leave the server!
We tried remote-displaying our demo. Via Fresco the communication needed 1.9kBit/s (alive pings) after an initial burst to create all the necessary graphics, even while moving/resizing/scaling/... the windows. Doing the same using VNC to export the same demo at the same color depth and using the same screen-size up to 800kBit/s were used when doing those operations. We allow that factor of ~400 for unforseen complications;-)
You should further notice that individual graphics do not get complicated. Complex things are build up out of a couple of simpler graphics. This is *very* different from how both GTK and QT work and way more easy once you get used to thinking in terms of small building blocks.
Also Fresco lacks any attempt at the Xlib emulation library, so it is not going to be a viable replacement.
Yes, we are incompatible for now. Nobody is working on an Xlib emulation layer. It can be added and it will be added once Fresco becomes stable enough to hold its own. Nobody can use Fresco for serious work yet, so nobody will miss X compatibility. We'd still have to keep updating the code to keep in sync with the rest of Fresco, thus draining resources that can be put to far better use elsewhere, Doing such an emulation layer now would do more harm than good.
To that ancient "inconsistent" argument I say it is totall BS and I challenge anybody to find a real user who is "confused" by the difference between a KDE and Gnome button or menu.
My parents are. I use linux/unix exclusively for a couple of years and even I get confused at times! The Look is not really the problem, the Feel is much more so: Sometimes menus stay open when you release the mousebutton, sometimes not, sometimes a scrollbar works as expected, sometimes you need to use different mousebuttons to scroll things. That is not that big a difference that I can't use programs, but ti is enough to break my concentration on the task I want done to focus on the UI. This change of focus is annoying like hell and slows me down.
Consistency is not about enableing users to figure out an application, it's about making them able to develop habits which can be performed subconcious. Such actions can be performed without losing the focus on the task at hand, thus increasing the productivity of the user.
What does "replacing X" have to do with forking XFree86?
...
... I'm not even starting on things like the option to support new hardware like autostereoskopic displays and VR/AR devices in a way that's consistent for 2D and 3D applications. Just saw some of those displays at the CeBit... they will hit the shelves soon. How is X prepared for such hardware?
Nothing. I was replying to the idea of DirectFB being an alternative to X.
And how is that [MacOS X] better?
It enforces a certain kind of Look and Feel (granted, that's because there's only one "ToolKit"). It can support way more features of modern graphics cards than X (OpenGL). I do consider vector graphics a huge plus too. Decent fonthandling (which admittedly is improving in X),
And, again, what is supposed to be better about that [Fresco]?
Consistent look and feel, configurable, vector based, device independent, langauge transparent,
I can't frankly think of a protocol that would be worse for client/server communication in a window system than CORBA.
CORBA is not a protocal, it's an architecture.
What's wrong with it? It gives network transparency and language transparency basically for free. It is by far not as slow as people claim and is the only system I know of powerful enough to fit our needs.
Yes, if we were doing client-server communication X-style CORBA would be a bad choice. We don't.
And I certainly don't want a window system that forces a particular GUI paradigm on me.
GUI Paradigm? You as a user can influence the Look and Feel of a application in way more ways then in X today. We try to put developer's into the direction of having them use our "ToolKits", but they may choose an abstraction level that best fits their needs best. Actually I think Fresco's much greater flexibility will allow to influence the GUI paradigm in much more detail then you currently can.
he extensibility of X11 is such that almost any addition can be made
(or removed) with little problem.
What is X + ExtensionY? Is that still X? A application relying on ExtensionY will no longer run on plain X, will it?
With the current X11R6 standard comming out 1996 I keep wondering how many of todays cool new applciations will actually work on a server offering only what is part of the standard from back then...
X11 is good at what it does, a network transparent graphics protocol. Throwing this out would either require you to be tied to a single machine or rewrite much of X11 in any case.
Not really. Fresco is less then 190K lines of code. I am convinced that if you would reinplement it as an extension to X you wouldn't be able to reduce that number. That's one of the reasons we did not go that way.
Where do people get the idea that DirectFB is an alternative to X? It is a fast and good graphics library, just like SDL or GGI or some others! Just that you can run GDK on a graphics library does not make it a replacement for X.
I do think we need something to replace X, but that shouldn't be some more or less randomly picked graphics library. That's a step backward: You loose network transparency, which is a really cool feature and will become even cooler with the rise of mobile devices. You don't loose much more since X is itself not much more then a 2D centric graphics driver nowadays, but you are loosing the killing feature of X.
I think we should look more at what Apple does then on what happens to be at hand right now. Please help us getting projects like Fresco, PicoGUI and many others rolling (better). Those can turn into an alternative to X at some point -- they still have a long way to go of course -- but they do over significant improvements over X while keeping its strong points like configurability and networktransparency. Those projects are based on (runtime) switchable rendering backends that can use graphic libraries like DirectFB, GGI, SDL or others to do the actual work and thus profit from the work done by the devlopers working on those libraries.
I agree that we need some standard for hardware access. That shouldn't be tied to XFree though IMHO. If both Xfree and a new fork of it adhere to such a standard and thus can use the same drivers I don't mind them forking. In fact that will probably even improve the standard: Suddenly two project's needs will influence it, the interfaces must improve to accomodate both. The coupling of drivers into the display server will get reduced, maybe even to a level where still other projects like DirectFB, GGI or whatever will be able to use the same drivers as X! Now, that would bring us all a huge step forward.
I don't think the idea of community driven documentation is all that good. You wrote the program, you know how it works, so please document it! Users are great in pointing out areas you will need to improve, but they are not terrible good at writing the documentation in the first place: They don't know how your program works, so they have to guess (=> inaccurate documentation) or read and understand the code (=> usually start to develop themselves, forgetting about the documentation;-)
About a Wiki: Those tend to work rather well, contrary to what other people here claim. You need to monitor them regularly and frequently to catch all those changes by idiots that need to proof that a wiki is not secure (what a surprise! It's *editable webpages*, of course it is not!). That happens about once a month in our wiki or about 2000 times a day after being mentioned on slashdot (no, I won't give the URL here;-). Luckily most of those people are too stupid to da any real damage.
Anyway: I'd go for some annotation system like the one used by PHP and other projects where you have a fixed documantation text and users may add notes, ideas and questions to the static pages.