Reading through this report here, the author gives some well thought out reasons for a next generation Windows Server architecture for X.
A Possible Replacement to X11?
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSAlert.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
This guy really did his homework, so to speak. I really appreciate the fact that he wants to keep network transparency, which is very useful (and in fact not the performance killer most critics make it out to be).
excellent stuff – haven’t read it all yet – but it gave me an idea … (maybe the author has already done this and i haven’t read that far yet)… but some of the internals of X, or a reimplementation, could do with some of the algorithmic improvements that have been appplied to the kernel. for example, the transition to the O(1) schedular – or even in network packet routing (eg stochastic packet scheduling cf normal blocking queues) – these new ideas may give X a performance boost.
i’ll be keeping a printout of the report as it’ll help me with one i’m working on … good quality stuff on osnews!
Though I disagree with his speed comparrison after reading this: http://osnews.com/story.php?news_id=1905
If thsoe improvements were incorporated into X, it would be as smooth and fast as Quarts in Mac OS 1.3.
the kid needs some backers to get such a thing underway… The project has to play some serious catch-up to compete with existing, “archaic” standards.
That’s not to say that it couldn’t be done… but, if it’s really a viable and inherently superior pathway… the powers that be need to help…
It mentioned Fresco, Pico, DirectFB, and others.
it also said something about X compatibility, look at it more carefully.
The section ‘Future Work’ mentions a lot of things I’d like to see in X11 as well in future to be competitive to other OS like Win 2003 Server or MacOS X, but who’ll do this job? It will take (too much) time to realize this. I fear a stable common solution will take several years and potential users might don’t want to wait so long and decide to stay on Windows or give up Linux and return to Windows-based OS. Only if you had a huge developer team or developer community (e.g. like for KDE) I’d be positive about that studies like these will end in successfully creating a new X-Server fitting todays need to a modern graphical user interface and be in time and don’t sleep away todays requirements.
FUD:
Yes, if you read the whole article, it does mention Berlin/Fresco. Basically mentioning that they really having gotten a whole lot done (which I would have to concur with as I have been watching them since 1998), and they solution was simply way too complicated and overdone (such as the reliance on CORBA for a communication layer between components of the system).
I really think this guy is onto something, and it would be so awesome to see others throw weight behind this. If I didn’t have a side project that completely takes all my free time, I’d immediately drop what I’m doing to help him out (After reading this and seeing hiss code I still want to do this
).
Ok my bad. Just briefly looked over it.
“Didn’t mention anything about Berlin/Fresco either which has similar goals.”
Actually, it mentions Fresco on page 18. It also mentions DirectFB and PicoGUI on page 19.
[
Only if you had a huge developer team or developer community (e.g. like for KDE) I’d be positive about that studies like these will end in successfully creating a new X-Server fitting todays need to a modern graphical user interface and be in time and don’t sleep away todays requirements.
]
I disagree.
I think with a small core team of dedicated, experienced developers (say 3-4). *plus* several member from both KDE/Trolltech and GTK to port the backends of both to Y (as opposed to X), that you could really have something snazzy, in far elss time than people might suspect. Especially if you used the Snap-Tech drivers (for a GPL version of Y), you could have a solid starting place. He has already coded most of the core. Anyways I truly wish him the absolute best of luck.
The author plainly demonstrates his insight into the current problems of X and their corresponding modern solutions. This is an excellent read and worthy of closer investigation. I particularly liked his opinions on off-screen buffers. We’ve suffered enough under the present non-buffered solutions that exist in X and MS-Windows.
Buffered windows, standard (themeable) widgets, translucent windows, better responsiveness, client library + samples in C++, 18.000 loc, easily extandable, easier to use, changing display drivers @ runtime, …
And all that by one person?
Damn.
There is a lot of factual mistakes in the paper, such as the statement that X isn’t modular, that widget-sets aren’t double-buffered, and that implementing transparent windows is simple, and a lot of his complaints are just hand-waving. However, unlike 99.9% of the people bitching about X, he actually wrote some code! In fact, he wrote a lot of code. Most of the windowing system has been implemented.
However, I have some major complaints about the design:
1) Its not original. Its just the same-old, same-old, except with cruft removed. Has history taught us nothing? If something works well enough, a version that just removed cruft won’t succeed in the market. And if the system is successful, it will just accumulate new cruft. You can already see this in OS X — it now has two L&F’s, Aqua and BrushedMetal!
2) Server-side widgets are controversial. The problem is that custom widgets cannot be server-side, because application code cannot be trusted. The real problems with X apps today are not built-in widgets (I havent’ seen a single redraw problem in an standard Qt/KDE widgets since 3.1 came out) but custom canvases like KHTML. This design does nothing to address that issue.
3) A lot of the improvements, like double buffering and low-bandwidth operation, have already been incorporated into X toolkits or add-on software like XCB and NX. NX, in particular, does an incredible job in minimizing the number of round-trips through a caching proxy. The time spent writing yet another window system would be better spent working on Xouvert to integrate these seperate projects, or porting Qt/GTK+ to one of the xlib replacements.
bummer.. it’s all GPL.
Would be great if it would be LGPL, GPL sucks.
I have just looked briefly at this but it looks very good. I really hope some will pick it up and improve it.
http://www.doc.ic.ac.uk/~mbt99/Y/
Looks like the project is stalled until November
Maybe it’s a cleaner implementation than xfree86 but IMHO it worses some of the mistakes of xfree86, like having an even bigger monolithic server than xfree with all sorts of crap, from window managers to toolkits.
What is needed IMHO is something like an abstraction layered system. Layers would be independent of each other and replaceable. One layer would take care of hardware access and drivers, other the toolkit, other the window manager, other the network transparency, and all of the layers could accessed by apps or libs, so that if someone wants direct rendering (like games) and skip the toolkit, window manager and network transparency altogether they could.
Also he is wrong about directfb, it has a multithreaded multiapp core, but to work it needs a kernel patch, and it would have been nice to remember that directfb is work in progress.
Oh and BTW [page 10] i’ve never seen bubbles coming out the XP tray icons.
That’s what I’m waiting for!
But it would by good if it would be posible to port toolkits like Qt, gtk, Motif, … to Y, maybe just as wrapper so all the Linux apps (KDE, GNOME, Gimp, KOffice, …) could be ported by recompile (or better, only be starting Y and the Qt lib recognizes that there is no X, just Y)! (like Qt apps do on all platformes which Qt supports.)
>But it would by good if it would be posible to port toolkits >like Qt, gtk, Motif
Beeing able to do that is pretty mission critical, after all most gui apps uses one of those toolkits, rewruting every application would be a great task. But then again, very much of the “slowness”/latency/flickering/etc. on X comes from the toolkits. They could do much better.
So why not rather improve the toolkits, write better graphics drivers for X and live happily “ever” after with X ?
By Sagres (IP: 217.129.81.—) – Posted on 2003-09-27 20:41:22
Oh and BTW [page 10] i’ve never seen bubbles coming out the XP tray icons.
——
Is this humour?
At least he wrote some code. Try to put your ideas into working bits and bytes so we can slag it off here at osnews.
Quote
A common criticism of Windows XP is its over-use of eye candy. Rather than using animation to explain to the user what is going on, it is sprinkled throughout the system for no good reason. Menus ‘whoosh’ open and bubbles pop up from window gadgets and system tray icons. Although these often are suitable for novice users, intermediate and expert users find them patronising and annoying as they distract them from their work.
End quote
That WindowsXP description is certainly a piece of bad humour, the rest of the paper seems very serious and thorough. I concur with Sagres on detecting a worrying contempt, in the best of cases, when addressing the Microsoft WindowsXP GUI. If WindowsXP is “commonly criticized for too much eyecandy” (which is patently false), then what’s the fair description for the truly “commonly criticized” MacOS-X candy overkill? “Only suitable for” infants? The author was obviously not interested in a compared GUI study, but solely in a X replacement study. Fine.
..just built the whole thing (with a few corrections to fix the build errors) but it doesn’t seem to run :/
(doesn’t show any errors)
Check the Xouvert mailing list, they already discuss using parts of the Y concept. (Well, they plan to do a summary of the concept and start discussing the issues when the summary is ready…)
>>
OS X has tasteful eye candy. Luna is just tacky, and only suitable for ages 6 and under. Like Fischer Price toys…
>>
You surely meant “Fisher-Price” toys. The “Fisher-Price” GUI used to be KDE; toyish looks of right down awful taste, poor rendering and worse performance. Fortunately, the paper is not about tastes, except when addressing the Microsoft WindowsXP GUI in a non-technical very tacky manner.
[bummer.. it’s all GPL.
Would be great if it would be LGPL, GPL sucks.
]
GPL is the best end user license ever devised… IMHO.
Remember the guys market he is writing this for, ie: his lecturers and the people that decide his degree grade.
If the lecturers are particularly scornful of Windows then I don’t think this guy does himself any disservice by playing to that. Not saying that’s the case but just a possible as this isn’t a general press release but an undergrads final year project.
I agree with his opinions on luna. There is way too much garbage there for me.
I actually agree also. I think luna is a pile of crass cartoon junk in visual terms and in functional terms it feels like someone thought they should come up with things to increase useability without thinking about what would increase useability.
“Hey yeah, wouldn’t it be neat if like all your desktop icons like… just got vanished if you didn’t use them?”
-“Yeah and like your systray icons just vanished so you would lose the information inherent in them being there too!”
“Cool. Useable”
>>>
You surely meant “Fisher-Price” toys. The “Fisher-Price” GUI used to be KDE; toyish looks of right down awful taste, poor rendering and worse performance. Fortunately, the paper is not about tastes, except when addressing the Microsoft WindowsXP GUI in a non-technical very tacky manner.
>>>
Not sure where your attack on KDE’s (old, not current) look came from. That’s like me criticizing Windows 95’s UI as a slam on Microsoft. Fairly pointless in-my-opinion.
And Windows XP *is* often criticized for too much eye candy. That is my primary dislike of it versus Windows 2000. Immediately upon using a Windows XP computer I turn off all of the pointless eye candy, and the disgusting Luna theme. At that point I think Windows XP (Pro) is very nice operating system. The new “features” for the UI only hog system resources and add no benefit to useability.
And the Fisher-Price comment isn’t an entirely baseless slam. Look at the bottom two rings on the below image. Luna seems to be based on them. No joke.
http://www.dynatechaction.com/products/bf1016.jpg
I’m sooo glad it’s GPL.. LGPL is a crippled version of the GPL designed for people who don’t care about freedom.
I’m impressed. What I read sounded quite good.
Naturally, I’m not nearly as knowledgeable and technically proficient as some of you. But… it gave me something to keep an eye out for.
Does the project have a way to implement something like Ole or KParts? Thus that, when someone writes a word processor and someone writes a spreadsheet program, you can embed a spreadsheet in a text document?
Unfortunately, I have no idea how Ole or KParts work
I 100% agree with the comment that the animation and what not in Windows XP is unheplful to users. It’s there for an “oh cool” factor, rather than as an aid to users. One of the first things I noticed about OSX was that the animation helped the user, it wasn’t just there to look cool.
The phrase that comes to my mind when I think of XP’s UI is “try hard”. It’s like they’re trying to be funky, but they have no idea how to do that.
>>>>>>>>>>>>>>>>>&g t;>>>>>>>>>>>>>>>>> >>>>>
I’m sooo glad it’s GPL.. LGPL is a crippled version of the GPL designed for people who don’t care about freedom.
>>>>>>>>>>>>>>>>>&g t;>>>>>>>>>>>>>>>>> >>>>>
how can you make such an absurd claim like that? if anything the lgpl is made for people who care about freedom and the gpl is made for people who dont care about freedom.
everyone should have freedom to do with the code to do as they please if it is truly free…
the lgpl is less restrictive then the gpl; u can do whatever u wanna u do with it without repurcussions
contrary to popular belief, lgpl software cannot be made closed at any time… once its free, and out in the public, it is free for the public forever…
however, should a person or company decide, they can take a copy of that code, and close if off for their purposes if they want to…
it makes sense, since that person or company made any changes to the software code, that they should be able to keep those changes closed…
its not like the already opened, lgpled version of the original is being closed (since that has been made free already)
only the copy of the lgpl code + new code that has been added or subtracted is going to be closed… u can still get the original work from elsewhere…
if someone wants credit for their work, then add a clause to the license that the user must give credit to the original source… however, dont make it such that if the new code from a particular code, that the original author did not create, is written, it too must be opened….
how can you say that restricting someone to opening all modifications is more free than letting any person do whatever they want…
Unfortunately, I have no idea how Ole or KParts work
These technologies are not related to the windowing system in use.
A few comments so far:
While he’s correct that latency is more important than throughput these days, he hasn’t really shown that X or XFree has problems with this. In all the profile runs I’ve seen scheduling tends to have a big impact, followed by slowness of toolkits (for instance calculating containment based layouts, unicode etc).
His complaints about how X extensions “interfere” are kind of dubious. Of course XRandR breaks apps that assume the screen size will never change – apps that assume that are by definition buggy. An extension which resizes the screen cannot avoid this problem. That’s not a criticism of X, it’s a criticism of the apps.
The problems the Xine team are again nothing to do with X and everything to do with lack of maturity and standards on the Linux desktop. There is now a fullscreening protocol in place, which is being implement by GNOME, KDE, OpenBox etc – older WMs that don’t support that protocol have to be hacked around by using override-redirects and other nastyness. Screensaver control is the sort of thing DBUS is for, and again has nothing to do with X.
Finally he *again* mistakes the problem of inconsistant widget toolkits as being a problem with X. It’s not, it’s a problem of history and the way humans are. Windows has always had a central widget toolkit, however it’s not at all uncommon to find apps that roll their own – even Microsofts own apps (Office & Encarta for instance) do this. There are many reasons why custom widget toolkits are used, unfortunately nobody has yet invented the perfect toolkit, so I foresee this continuing for some time.
This is true even on the brand new MacOS X – Apples own apps roll custom client-side widgets all over the place, as close examination would reveal.
Still, he should be congratulated. I don’t want to come across as harsh – the paper is well written, interesting, and the guy is clearly a very smart cookie. I hope he decides to go forward with whatever ideas he has for Linux – in particular if he wants to do windowsystem research he should talk to Micah of PicoGUI – on the surface their goals and methodology seem very similar.
He also seems interested in object models. I have some thoughts in this space also, it might be worth trying to recruit him at some point
e.g. Qt runs also on non X systems (Windows, MacOS X) with native speed. I think a port in this way should be possible, or? At least for Qt (because it is designed for portability: Win, Mac, X, FrameBuffer).
The gtk Windows port isn’t that good, but wxWindows or tk is better (actually wx and tk are only wrappers in Windows).
>>> If WindowsXP is “commonly criticized for too much eyecandy” (which is patently false),
False? Not from where I am sitting. Everybody I know that uses XP, the first thing they do is turn off luna, and EVERY animation. I have nubes who have been on it for a mere month or two asking how they can get it to look like mine. These goofy animations and playschool colors do little to increase productivity and only accomplish chewing up processor resources for no good reason!
On subject:
If Linux is ever to become a true force in the desktop market, X has got to go. Sorry, but the API has become so convoluted and the client/server internal model, while fine for remote use, is a waste of processor time on a standalone machine, as it’s just another step a program has to wait on. Just as Microsoft has abandoned it’s 16 bit DOS legacy with 2K/XP, it is time for Linux to abandon it’s unix legacy, and a good step towards that would be moving away from X-free, who’s age shows WAY too much. You can only patch so many times before it’s time to give up the goose and start over from scratch.
I think Y is an idea who’s time is overdue. Unfortunately with so many people already tied into X in terms of time and resources invested, it likely won’t catch on. Damn shame.
>>>>>>>>>>>>>>>>>&g t;>>>>>>>>>>>>>>>>> >>>>>>>
If Linux is ever to become a true force in the desktop market, X has got to go. Sorry, but the API has become so convoluted and the client/server internal model, while fine for remote use, is a waste of processor time on a standalone machine, as it’s just another step a program has to wait on.
>>>>>>>>>>>>>>>>>&g t;>>>>>>>>>>>>>>>>> >>>>>>>
see, but thats not really the problem… the client/server model has absolutely nothing to do with the latency… its the other convulted mess in xlibs thats the problem… the client/server model leaves a comparartively small memory footprint
now, if u had actually READ the damn article u would’ve picked up on that because the Y server plans to KEEP the client/server model…. furthermore, he pins the problem on the xlib and the messed up way x talks to its components…
also, u should read this…. http://osnews.com/story.php?news_id=1905
maybe u should do some damn research before u claim that linux NEEDS to move away from the client/server method to **defeat** microsoft (gawd, i love sarcasm against zealots who dont know anything about what they are talking about; someone once said that those who know the most talk the least, those who know the least talk the most)… do some **damn** research before u cry that something is a ***”Damn shame.”***
(hey, that was his phrase, so i just damned everything too)
>>
however, should a person or company decide, they can take a copy of that code, and close if off for their purposes if they want to…
it makes sense, since that person or company made any changes to the software code, that they should be able to keep those changes closed…
<<
So let me get this straight. A company or individual can use code that they HAVE NOT originally written, modify it, and keep the modifications to themselves. Thats almost disgusting. Its like U couldnt write your own stuff… so u used someone elses code without now contributing back to its evolution.
Seems somethings wrong with that picture…….Well maybe its just me though.
yea, but that code is already supposed to be “free” as someone claimed….
its supposed to be for the “community’s” benefit…
so who is this community? individual coders or companies are not included?
what if i develop some really cool algorithm that I wanna couple with this gpl software… but I cant do that because **I** developed it, and why should I have to be **forced** to give it to someone… under lgpl, i dont have to…
if someone is gonna release software and code for free, they should at least make it free to everyone w/o restrictions… if i am a developer, i dont wanna have someone restrict me…
but, its all a matter of perspective; and there is a time and place for everything…
still, lgpl does not harm the original coder, cause there code is still out there for free, and will free… it doesnt hurt the end user because the original code still remains free, if u want additional benefits, pay up; those new modifications were not done for free u know… it does not harm individual coders or companies that want to base their software on good opensource software and codes (hey, its already been stated for free by the original coder)
now, the gpl, doesnt harm the orginal coder (sometimes benefits b/c others innovations are forced to be made free)… it doesnt harm the end user… but it definitely harms individual coders and companies b/c their innovations are forced out….
again, if the coder wants credit, just put a clause to give credit in the license… i agree give credit where credit’s due… but dont force other’s innovations out…
now, this is especially the case if some software or code under the gpl is made the standard… that means that a small company or individual has no choice whatsoever to use his or her new code because the market has already developed a standard…
Meet your first person that didn’t turn off Luna (unless you consider changing to Silver turning off Luna). And don’t worry, you would meet plenty more people like me, I know I did.
Well I think this whole discussion boils down to the concept of “FREE”.
My concept of “FREE” is this —->
If you are using someone else’s base code and you somehow modify it, it only seems natural to me to give back what what given to you. So in that sense I guess you could say the GPL is not “FREE” as in a “free LUNCH”.
Now if you write your own stuff totally from scratch —–> you dont have to release it under the GPL or any other licence. You can just as well copyright the entire process and write your own licence. Thats your choice.
BUT!!!!! If you dont come up with your own stuff and simply add-on, so to speak, to someone elses work…… remember even they have done it …. at no charge. So for you, now, to take their work which was given at no charge to you and use it, and maybe even profit from it, without somehow contributing back (notice contributing here has nothing to do with money but spirit of the code)……. Well just seems a tad odd…..
But like i said before,,,,,its how I see it and you are “free” ofcourse to interpret it in your own way.
You are right about the fact that the LGPL doesnt harm the original coder. Indeed his baby is still out there and its still “free” for any other user to modify it. But in this way does the code “TRUELY” evolve.
Its my belief that in most cases its not the idea……heck its not even the initial implementation that makes great code…….Its Evolution.
With the LGPL —–> Evolution mat or may not occur.
With the GPL ——> Evolution is “guaranteed”
Tell me…….as a true coder which would you prefer.
Heck I feel this way and im not even a coder.
You two seem a little bit confused about the licenses. Neither the LGPL nor the GPL force you to give out any sourecode, unless you distribute the software. So for your own use, you can modify as much as you want without giving anything back.
The LGPL however, allows linking proprietary applications to it, while the GPL does not. That’s the only difference. Thus, the LGPL should be used for libraries that should be commonly employed (like the toolkit…) and the GPL should be used for libraries if it’s some special library that you only want free software to benefit from (imagine a library with nifty image effects or something like that). It should always be the choice of the author. However, using the GPL for something as central as Y is supposed to be, would be horrible for the project, because nobody could write applications for it without using the GPL license or something compatible.
You should also note that for stand-alone applications, GPL or LGPL makes no difference at all, so these libraries aren’t competing in any way. They complement each other.
> 1) Its not original…
That’s fine. As long as its clean and well done.
> 2) Server-side widgets are controversial. The problem is > that custom widgets cannot be server-side, because
> application code cannot be trusted.
There may be ways around this. Providing an interpreted and safe language (eg, XML) to transmit custom widgets could be an option.
> 3) A lot of the improvements, like double buffering and > low-bandwidth operation, have already been incorporated > into X toolkits or add-on software like XCB and NX.
True, but these are improvements that have only come over many years. And they have been implemented on an X architecture that while extensible, could not have predicted all that would be expected of it. The result is a set of components that work together but often do so in a way that is unintuitive and difficult to visualize for new developers. Starting from scratch allows one to incorporate the work of the last 10 years into a foundation for the work of the next 10. This sort of refactoring is essential.
Does the LGPL allow companies to modify LGPL software without giving back any code?
>>
However, using the GPL for something as central as Y is supposed to be, would be horrible for the project, because nobody could write applications for it without using the GPL license or something compatible.
<<
does that mean that nobody could write applications for Linux without using the GPL. Im a bit confused here.
Please explain…..
>> Does the LGPL allow companies to modify LGPL software without giving back any code?
Only if they won’t distribute it, just like the GPL.
And as Spark said, it would make all software GPL, which is _bad_ because it _limits_ choice and it will make Linux/Y _not_ a viable option for the desktop as no company could port programs like Photoshop or whatever to Linux without GPL-ing it (which is often not possible because of other licenses being used).
This is a little bit misleading, actually. When I read this, I thought it was something like X interface for Microsoft Windows Server and coudn’t get it how it can replace X
if you distribute something udner gpl then you have agreed to give anyone gaining a copy (you dont have to give away the product, you can stillsell it. but the inflated prixes you see on some software today will most likely die) access to the full source of the product. and anyone gaing a copy of the product is free to redistrobute it, under the same rules, be that modefied or not. and if you do changes to the code noeone but you can claim that they have done the changes.
this way you keep the creative right of what code you write, the code can evolve and anyone can do a compile, package it with a moanual and sell it. the big point is that you cant sullpy binary only stuff udner gpl, you must supply anyone agreeing to the gpl and getting a copy of whatever you handing over access to the code its based on alltho its does not need to be on the cd the program is on, it cna be on a server somewhere that you print the link to in hte manual or something like that. one must allways avoid closed standards or the risk of a program dieing from cuts in support, and that is what the GPL does. closed standards lead to monopolys, and planed cuts of control leads to forced update cycles…
“”does that mean that nobody could write applications for Linux without using the GPL. Im a bit confused here.
Please explain…..””
The vast majority of code doesn’t get linked against the kernel, so the GPL doesn’t propogate to code simply running on Linux. Although I guess an argument could be made that an application that uses system calls provided by the kernel is effectively linked to it (In that it is dependant upon functionality contained within GPL code) the GPL doesn’t seem to cover this situation, only shared code.
X is a different matter because anything being displayed on X does so via the X libraries (xlib etc). If the X libraries were GPL then any application using those libraries would also be forced into either using GPL or not using X libraries to display things. With the LGPL developers can link against the X libraries and use their own license. This is why the LGPL exists (Side note: The FSF really doesn’t encourage the LGPL much…wonder why :>).
does that mean that nobody could write applications for Linux without using the GPL. Im a bit confused here.
No, because Linux is not a library. No application has to link to Linux, and thus the license of Linux doesn’t matter (for this). However, important libraries like libc, xlib, etc are all under “less protected” licenses (LGPL or BSD-like). An exception would be Qt, but that’s dual licensed under QPL which is less restrictive for free software developers and also allows companies to buy a license to develop proprietary applications for it. There is also a contract that says that Trolltech has to release Qt under a BSD-like license should they ever be bought up (or quit).
>“No, because Linux is not a library. No application has to link to Linux, and thus the license of Linux doesn’t matter (for this).”
Kernel modules link (dynamically) to the linux kernel, so they all have to be at least LGPL’ed.
That’s fine. As long as its clean and well done.
>>>>>>>>>>>
Not really — the market is full of “clean and well done” ideas that never get popular, because clean and well done just isn’t good enough. BeOS comes to mind…
There may be ways around this. Providing an interpreted and safe language (eg, XML) to transmit custom widgets could be an option.
>>>>>>>>>>>>
This is problematic. First, you’d need a real programming language, not XML. Even then, you’re stuck. With client-side widgets, all you have to do is describe how the widget looks at a point in time. With server-side widgets, you know have to ship the code for the entire widget to the server. Also, you have to ship the widget all the data it needs to render itself. So, for example, with the KHTML widget, you’d have to send it a hundred thousand lines of KHTML code, then every time data on the web page changed, you’d have to send it the new data. This would be much slower than the client-side case, and would defeat the point of having the client do most of the computing. No, a far better idea is to ship compact vector representations to the server, and use shared-memory locally for images. Of course, X is already well on this path with the Xr extension…
True, but these are improvements that have only come over many years. And they have been implemented on an X architecture that while extensible, could not have predicted all that would be expected of it.
>>>>>>>>>>
That’s the whole point of an extensible architecture — you can implement things that you never thought of at the time.
The result is a set of components that work together but often do so in a way that is unintuitive and difficult to visualize for new developers.
>>>>>>>>>>
If a developer finds X + Extensions hard to understand, I don’t trust him to be coding at the toolkit level. If he’s just coding at the application level, well, he can just use the very friendly and consistant toolkit APIs like Qt and GTK+.
Thanx guys for ur replies. Have definitely gained a better understanding about these licences now. I can safely call my legal teams off. :>) Just kidding
But thanx again
Quartz and NeWS both took advantage of well known rendering models, PDF and Postscript, respectively. Could Y, or something like it, benefit from a design based on a hierarchal vector graphics rendering model? SVG springs to mind, as an existing open format that is still being enhanced. Instead of requiring pre-deployed libraries on the server side, such as Y assumes, GUI widgets could be described and deployed dynamically (with support for caching to improve performance). Flash, although currently underpowered for the task, obviously uses a display model like this with great success.
An API like this could be lower level than a widget library like QT and GTK, but still high level high to be implemented on top of X11 or Y. Specification for server-side-only display logic could be provided by a system-inspecific language with appropriate security mechanisms (java, a stripped down python, ecma scripts, etc…). Messages to and from the client would be limited to registered messages, and only in situations where the state change required a change in the client software. This would provide the same low latency intended by Y, PicoGUI, and Fresco with the same technique: upping the abstraction level in the communcations between the client and the server.
Entities for displaying bitmaps and animated bitmaps could be wrapped in geometic-looking entities, keeping the model consistent.
Would such techniques offer any improvement to a model of predeployed widget libraries that Y suggests? Are there inherent limitations in this?
>>
Accelerated support is provided for Mach64, Rage, Rage 128 and Radeon chips by the “ati” driver.
<<
Got that from XFREE’s website
Does that mean that there is 3d hardware acceleration ?????
Thanx in advance,
madmax
I rememred that name so I googled. See http://www.hungry.com/products/Ywindows/
Would It be possible to use both models? For example, a limited number of server-side widgets but allowing the use of additional client-side ones. Or if you run in local run all widgets server-side to avoid copying the bitmaps to the server like X-Windows does.
I also think that this could be interesting to OpenBeos, Syllabe etc. They have a standard widget set so use server widgets is not a problem.
I also read a interview with SGI programmers who said the perfomance of Irix was due to the use a heavily modified X server and the use of the kernel (I think it refered to the use of low level kernel primitives instead of sockets the same Way Quartz uses Mach primitives but I'm not sure).
Is there any articles about the architecture of Atheos, Beos, SkyOs etc?
Yes, there is, but the 3D acceleration is generally provided either by the DRI project (http://dri.sourceforge.net) or by proprietary extentions (nVidia binary drivers).
Btw, a Linux kernel module doesn’t necessarily need to be licensed under the GPL… For example, the nVidia binary driver isn’t completely GPL. Only the kernel interface is. However, inserting a module like that will “taint” the kernel. That flag indicates that you have loaded a binary/proprietary module. You can be sure kernel developers won’t help you debugging a tainted kernel.
Isn’t this all dreamy anyways? How long could we possibly expect this to be fully working to the stage it could well replace X-Windows.
the site seems to be down, does anyone have a mirror of the pdf file?
I remember the first time I sat down and used a Citrix Winframe client (on our maths departments’s NT server.)
They were set up on old PC’s which still had floppy drives.
What struck me was the way that, once you had logged in, the (Win 3.1 style) file manager showed the floppy drives on the terminal as floppy drives to the user and allowing them to be used as such. Essentially they were mounted as network drives from the point of view of the terminal session running on the NT server (I think) but for all intents and purposes, the disk drive felt like a local one.
Simple little feature, maybe, but an important one to consider when thinking about replacing X. The imporant thing to think of is not this feature in isolation (nor how one should implement it in X), but the idea of taking the best parts of the user experience when running on e.g. a PC, and merging that with the advantages of a client/server network GUI/terminal/whatever system.
I’ll give some examples.
If I am running an application on a server, in a terminal session and the application wants to make a sound, it should come out of the terminal. This may not be part of the ‘graphical’ part of the GUI, and many would argue that it is beyond the scope of e.g. X, I would argue that it is clearly part of the user experience of the person using the terminal, and this experience is what the ‘GUI’ should really be aimed at capturing.
(Echoing the thing I said about Windows terminals.) Local removable (e.g. floppy/zip/CD-ROM) storage is useful.
In practice, what is needed, is a more-than-X replacement that encompasses (by design) the various aspects of the user experience, so that the whole sit-down-and-use aspect of using network terminals is a seamless as possible, as portably-uniform as possible (i.e. I can go to any terminal, log on and get essentially the same experience), and yet with as few limitations as possible (compared to having a networked bunch of PC’s.)
Networked terminals vs. PC’s is essentially an easy-administration+maintainence vs. user control+features+convenience tradeoff (or something like that) and the ideal for which user interface people should be aiming is the best of both worlds. As to what is ‘user interface’ and what is not: everything to do with the user _using_ the system (whatever it is) should be considered ‘user interface’, from the on/off switch to boot times to how sound and removable disks work through to where to stick the menus on the screen.
In short, the ‘graphical UI for the graphics part, all else is someone else’s problem’ attitude that is so engrained in X is one of X’s biggest (and apparently hardest to see) problems.
Rayiner Hashem wrote:
There is a lot of factual mistakes in the paper, such as the statement that X isn’t modular, that widget-sets aren’t double-buffered, and that implementing transparent windows is simple, and a lot of his complaints are just hand-waving.
I believe you are mistaken on some of the finer distinctions he is making. He says, “XFree86 is modular” on page 10. He does when speaking of Y say, “Unlike X, modules are unloadable and reloadable” on page 11. [Page references are the PDF page numbers.]
On page 16 he says most “X implementations” are modular. On page 16 and 24 he says “windows” are unbuffered but does not claim widget-sets aren’t double-buffered. I believe the buffering he means is buffering the contents of windows so that applications do not have to re-issue drawing instructions when parts of the window are exposed. Seperately, he talks about double-buffering in reference to blitting to the framebuffer to avoid flicker (page 35). And in a third sense, he speaks of widgets buffering and collating redrawing until the ‘viewport’ requests it. The point being, the viewport knows the appropriate refresh rate or bandwidth and can control the frequency of the paint-render cycle independent of the widget’s programmatic rate of change (page 41).
And translucent windows are easy to implement… just not in for X11 reasons unknown to me. Although XDirectFB does it ( http://www.directfb.org/xdirectfb.xml ) and buffers windows too.
However, unlike 99.9% of the people bitching about X, he actually wrote some code! In fact, he wrote a lot of code. Most of the windowing system has been implemented.
Right on.
1) Its not original. Its just the same-old, same-old, except with cruft removed. Has history taught us nothing?
The history of computing research is that things are very rarely new or original. By the time things appear in working code they probably have been mentioned in paper written years earlier. Other times they are a marginal improvement, or a new application of an old idea or a new collage of old ideas.
But then again, he has set himself up with the ambitious title of “a successor to X11” and if I were a betting man, I would concur with you Rayiner that it won’t replace X11. However, ‘successor’ does not necessarily denote backward compatibility or success. Take for example the Apple 3 computer
I haven’t finished studying the paper but hope there will be a mailing list eventually. I’d like to see him address your second point:
2) Server-side widgets are controversial. The problem is that custom widgets cannot be server-side, because application code cannot be trusted. The real problems with X … [are] custom canvases like KHTML. This design does nothing to address that issue.
One of his purposes is to provide standard widgets on the server-side so people aren’t so tempted to roll their own in their toolkits and thus improve on consistency. He allows the possibility of querying for a existence of a widget class on the server. If it does not exist, then the client can either use an alternative, or implement it client side using a canvas (page 23). But it does seem he hasn’t addressed how to deal with bitmap data as you seem to allude to in “Re: Looks Good”.
The other issue is latency. This is not a problem on a local machine, or on a LAN, but over something like ADSL or slower, the benchmarks in page 56 (Chapter 10) show Y is making a real significant difference.
3) A lot of the improvements, like double buffering and low-bandwidth operation, have already been incorporated into X toolkits or add-on software like XCB and NX. NX, in particular, does an incredible job in minimizing the number of round-trips through a caching proxy.
Ok, I’m being the devil’s advocate here since I already agree that a replacement of X11 is not widely practical…
NX seems to be a band-aid solution using a proxy and protocol compression. It better to fix the problem at the root.
XCB aims to provide a more efficient toolkit interface to X11 among other things but does not change the underlying protocol.
The Object Model (page 27, Chapter 3.1, 4) is where it gets interesting… alas I am out of time.
And translucent windows are easy to implement… just not in for X11 reasons unknown to me. Although XDirectFB does it ( http://www.directfb.org/xdirectfb.xml ) and buffers windows too.
It’s hard implement transparent toplevel windows in XFree86 due to the way the server stores the toplevel windows, their positions and how expose events are built and sent. Using XRender protocol transparent toplevel windows can be created it’s just that XFree doesn’t support transparent toplevel windows due to it’s internal structure.
A n00b question:
Why not integrate wxWindows as X toolkit? It’s tested, proven, and cross-platform!
Most recent versions of CORBA software have really improved, especially wrt real-time. Take a look at TAO for instance. Additionally, interoperability with other languages is built in CORBA from the ground up. So my question is why substitute a clean ‘C++/RPC’ proven design with an inferior ‘C a-la-OO/hand-made messaging’ system? Would it pay off in the long term? IMHO, it’s way better to rely on existing standards with an important user community even if it is a bit less efficient. At the end its less work for everybody to understand and to use your framework.
Can someone explain what he means by ‘get and set modifiers on fields’ on p.23? Also the ‘loosely coupled event signalling’ stuff? Can’t the observer pattern be used for that?