Slashdot Mirror
Y: A Successor to the X Window System
impto writes "Whenever someone brings up the topic of replacing X, everyone always says that's nice, but where's the code? Well, Mark Thomas put his money where his mouth is and produced a replacement that maintains network transparency while adding many of the features that people desire from X such as alpha blending and a built-in toolkit. It still needs a bit of work to be as featureful as X but it's a fresh start that takes advantage of current technology and ideas. Read the paper here in PDF (1.7MB) or PS or grab the source and start hacking."
It might not yet be perfect, but its a start.
Oak trees grow from Acorns and all that.
The website (available by clicking his name) should really include more information. It tells us that Y is the replacement for X, but offers NO reasoning. What problems does it solve? What features does it have? Can I install it alongside X? With this little bit of information, it makes me not even want to download it. Sorry.
Also, it should be noted development has stalled on this project. He says it should start up again in November.
That's all well and good, but one of the reasons that X is so successful is that you can use whatever toolkit you want, and all X really is is a network-aware framebuffer.
This leads to toolkit darwinism, which has left us with essentially GTK and QT as the two dominant toolkits. Imagine if X had been shipped with Motif as its native toolkit? Who the hell would use that in 2003?
You're doing it wrong.
What will they do after they've finished with Y and Z, they'll have no more letters of the alphabet then. It'll be a disaster
I have over 70 freaks, do you?
According to the webpage:
;-)
Y depends on:
* libSDL 1.2 (available at www.libsdl.org)
Now, doesn't libSDL again depend on X?
Note to self: get smarter troll to guard door.
In the end, nobody has to use it, and it's a good idea and I would love to see it eventually part of the distros
BUT it's never going to catch on called 'Y'!
A) it doesn't sound cool, and
B) its too much like the yahoo IM service Y!
puts ("Python r0cks\n");
UNIX desktop environments are a mess. The proliferation of incompatible and inconsistent user interface toolkits is now the primary factor in the failure of enterprises to adopt UNIX as a desktop solution.
:-)
So what do we do to solve this mess of user interfaces? Let's create yet another one! I love the way that geeks think
I don't really like this... X is mature and popular, replacing it will take a *lot* of time, and most people will not switch unless the major distributions do.
And anyway, alpha blending and an official toolkit? No. The unofficial X toolkits work well enough, and alpha blending is not very hard to hack in - it's also quite useless for anything other than eyecandy.
I doubt this project will get much highlight after this initial slashdotting.
and your point is????
© 2004 The SCO Group, Inc. All Rights Reserved.
1. If it can't run existing X windows applications it's useless. Additionally if it can't run anywhere it's useless.
2. If you can't use existing XFree accelerated drivers it's useless because you're not going to make gfx card companies produce new drivers for another environment. Asking them to produce X drivers was hard enough, and some of them haven't even got that right yet.
3. I don't want unified toolkits because it means the entire KDE and Gnome desktop projects would need to be scrapped, unless QT and GTK can be re-created as "wrappers" to this new, unified toolkit.
4. It's a final year project. Sorry, but this guy's just an undergraduate student, no offense but I find it highly unlikely he can come up with something superior to X, QT and GTK (all of which this system supposedly replaces) in a year of work.
30% - Zealots who laud that this a great feature of open source, as they have the choice to hack and choose.
30% - Who say this is a setback to the standardization of getting open source onto the majority of desktops (Lusers don't want choice!)
20% - Who post something witty, or copy various ??? Profit or ISR jokes
10% - Who post goatse links
5% - Who spout inane bullshit about god knows what
5% - Who actually have something to say on the subject, and *gasp* have knowledge of what they are talking about.
10% - Post comments showing their lack of mathematical ability.
x -> y -> z -> aa :)
Good point! But I only made it twice....and I've only seen it like 500 times...hummmmm...maybe I'm not the only one.
© 2004 The SCO Group, Inc. All Rights Reserved.
...wouldn't it be more in keeping with tradition to call it X++?
philcrissman.com.
No, someone did NOT have to do it. But they still do, to obvious chagrin of many.
- Too much focused on 2D user interfaces, no native transperency for multimedia, low level and optimized applications.
- Too little scalability between devices with varing performance and ability.
- No sufficient support for disabled user enhanching devices.
- Severe security issues in the protocol.
Especially no encrypted operation at NATO standard SECPROT level 4.
- Network protocol too bloated and complicated.
- No smooth integration into the operating system.
- No smooth integration of the window managers.
- No stream compression in the protocols.
What the author of Y does is basically reenforcing the usage of old problematic software and protocols. This can be best compared to giving free cigarettes to a nicotine addict.Owner of a Mensa membership card.
What's the license?
For great justice.
Shit just go down and read all this guys comments one by one, he's an absolute retard.
Is completely transparent window system over network.
I wan't to be able to grab windows from my home machine and use at work, I wan't to be able to clone windows to be used on more machines. So more people can watch/edit the same thing.
Emacs can do this, but I do not like it to be per program, it should be built into the windowsystem.
I would gladly support in a monetary way, to get this feature implementet.
everybody is using XFree86 7.8.9 and ignoring all the X replacements, which by then number into the 100s.
sorry, i'll never do it again, Anonymous Coward.
© 2004 The SCO Group, Inc. All Rights Reserved.
Is Y the best name he could up with? How about Yinx Is Not X or fuck... anything but the next letter in the alphabet.
Something like that... maybe vy? (-: asbestos suit, check; grin, duck, run :-)
Got time? Spend some of it coding or testing
Everybody says X sucks, that it's bloated, that it's slow, ... and everybody wants to replace it. The best effort I've seen so far it Qt (especially Qtopia for palm devices).
I think X is like Unix : it was inadequate and bloated but computers have caught up with their demands, in terms of power and disk capacity.
Computers get more and more powerful, networks are faster and faster, and X is more and more lightweight comparatively. Combine that with decades of testing and millions of developers who have experience with it, and I can guarantee X is there to stay and evolve.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
You think I post as AC all the time? Whatever.
There is no way to get consistency in a window system. People will port their favorite window managers and toolkits to whatever window system you create. MS Windows runs many of the same toolkits that X11 does. Apple is even worse, officially supporting OS 9, Carbon, Swing, and Cocoa-based applications on the same desktop, and now also X11; and in addition to all that, toolkits like Gtk+, FLTK, Swing are also being ported to native Quartz backends.
If you want consistency on your desktop, just choose to use a consistent set of applications. Most non-computer experts can't even tell the difference between an MFC, Gnome, KDE, and wxWindows application: they all look equally flaky and confusing to them. And most people incorrectly think that something is an OS X native application if it has shiny gumdrop buttons. In short, most people neither know nor care.
...and MS "API of the month" Windows targets, so another non-X target should be duck soup.
Got time? Spend some of it coding or testing
Read the paper. It is of shockingly good quality, both in the writing and the completeness of ideas. The writer is a college senior!
Hint: You replied to the retard.
Think nothing is impossible? Try slamming a revolving door.
i'm glad I could provide some entertainment for your simple mind.
© 2004 The SCO Group, Inc. All Rights Reserved.
Y... pronounced "Why". Get it?
That way it can be abbreviated to '*'. (-:
Got time? Spend some of it coding or testing
Where have I seen this idea before? Oh yeah... "Berlin", now being called "Fresco"...
I saw a demo of this at the "Alternative: Linux" conference in Montreal in late 1999, and it seemed "almost done" then. Haven't heard a whit about it since then.
I can't see why either of these projects would get the necessary 'traction' to have much meaning to the world, even if they ever do finally get the technology finished. Though I do like cool new technology. :-)
Cheers,
Richard
(RichDice username, ID 7000+random... I forget now)
i never had a problem with X, the problems arise when using Bolated resource HOGs like Gnome & KDE, use something lighter such as ICEwm, WindowMaker or XFce-4 was just released and runs nicely too...
People should know that there has been at least one project called "Y Window System" already (Not to mention W and Z...):
Here, 1998 vintage
There was also the YY window system. but that's long dead - 1992 era.
Hey, im the original AC, not you! Stop impersonating me!
Some people don't like the name Y. I say hey, Y leaves us with Y Windows.. which is a good question.. why windows? Use Linux.
My Blog
and what a very nice logo, also. these things matter.
Let's call it Youvert! ;-)
The preceding comments reflect the author's personal opinion and are public domain, unless explicitly stated otherwise.
I slammed a revolving door. Right into my girlfriend's foot. ...actually, ex-girlfriend :(
open4free
For all you Slashbots out there, let's state the more obvious posts about this article...
Now that those comments are out of the way, let the other bad jokes commense!
This guy seems to know what he's talking about and as far as I can tell he's got a proof of concept to show allready. Along with solid research and design.
I wouldn't be to fast at hand with bashing this guy - he lists all the other XFree replacements and for some like Berlin/Fresco he can clearly state why they failed and what you have to aviod to not fail the same way. And he also acknowleges XFrees benefits and sees no point in overthrowing them.
Keep an eye on this project, this could be something really interessting.
We suffer more in our imagination than in reality. - Seneca
I was planning to do something very similar for my final year project this year. I think I'll have to stay well away from his source in case I get "inspired" by any of it and get in trouble for plagarism...
Slamming doors on one's girlfriend tends to make them ex-girlfriends.
>> the Windows GUI system is a very limited toy compared to X because it was designed for single computer use... to not be used by 5 people or more at once.
As I write this, I am logged on a Linux box, accessing either a Windows Server or Windows XP box using "terminal services".
In the "ol" days this might have been the case, but these days it definitely is not the case. For example when I run across the Internet using Terminal Services, my devices ACTUALLY respond. Eg, try to develop with pop context senstive list boxes. X simply is not cut out for the job.
My question is why not chuck X? Seriously, as Linus and crew has multiple times rewritten the core of Linux, why must X remain X? Why not rewrite X to be "modern"?
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
Blah blah X needs this and X needs that.
When you lay it all out, it's not all the BIG stuff that needs to be rewritten for X. The network code? Yeah, it slows things down in some cases.
But all I want is:
1.) Alpha blending
2.) A standardized menu system for applications.
3.) The ability to cut and paste between applications.
That's it.
~Will
sig?
Sorry moron. It 's Y depends on X (Y -> SDL -> X). It's that simple (read the code if you don't believe me).
Anyone who thinks that everything is hunky-dorey in X land is smoking something. Remember that thread about Keith Packard getting turfed from the X team and the whole mess about X people being too slow to accept patches and drivers. Maybe this is the step in the right direction to fix that. I'd like not to have to wait for the next X release to see my new shiny video card work. I am sick of X not being able to handle five button mice some five years after these have been put out to market (even Apple which sells 1-button mice supports these out of the box). And yes, cut and paste *is* broken and not having a consistent interface is a problem for non geeks. And just for the record: I actually use Linux on the desktop...
Well someone has to say it, so it might as well be me...
:=P
The question has to be asked, Y bother? What Xtra stuff can it do that X can't with minimal Xtra effort? There is no point reinventing the wheel when there is solution that has had been tried, tested and proven over many, many years.
--
Any man who can drive safely while kissing a pretty girl is simply not giving the kiss the attention it deserves. -- AE
Well, I guess this is slashdot and people feel the need to post opinions without even reading the subject material. Almost ALL of the parents questions were answered in the PDF file both linked above and in the hosts website.
..........FULL STOP.
how come sometimes this gets modded up to +5 funny and other times -1 redundant
The scarf evolved into the cravat, and the cravat evolved into the modern necktie.
(You probably meant "caveat.")
Will I retire or break 10K?
"UNIX desktop environments are a mess. The proliferation of incompatible and inconsistent user interface toolkits is now the primary factor in the failure of enterprises to adopt UNIX as a desktop solution."
So let's solve the problem by writing YAXR(Yet another X replacement).
Whatever, man. Hope you had fun and learned a lot with Y, but scrapping 20 years of X is not the answer IMHO.
I don't know much about the subject. I only know that something should be done. Are the problems unfixable? Can these features be added: "subpixel cursor positioning, anti-aliasing, and 3d"?
What about actually trying this before blathering uninformed bullshit all over the place, you troll?
Not only does it work, it even works very well.
Want a list of a few non-x targets for SDL?
Here it is:
QNX Photon
Linux Framebuffer
Playstation 2 GS
Linux ggi
Linux SVGAlib
AAlib
Atari XBios, Gem
the dummy driver
DirectX, WinApi
Qtopia
PicoGUI
BeDirectWindow
MacROM, QuickDraw, Quartz
Of these 13 targets, five are usable in standard Linux, another three (PlayStation, Qtopia, PicoGUI) are for special variants. None of them needs X.
Is it plain-old-GPL, or is it GPL with an exception like that of Guile? In general, a window system cannot become popular unless some sort of proprietary software can be published for the platform. Some disciplines such as prepress image editing need patented algorithms whose owners aren't willing to license them royalty-free; only proprietary software can implement these algorithms.
Will I retire or break 10K?
You are talking about the XFree project, not the X system. Packard didn't get along with the XFree crowd, but his new project is still an X implementation and nothing else.
Some of us out here dont want X replaced, its efficent, its universal, its network aware, its the standard.
If you want to extend X, sure..thats nice... wheres the code.. but replace? No thanks.
---- Booth was a patriot ----
how do you pronounce UNIY?
Will Linux's become Linuy? How about Knoppiy, Lyny, WineY, and so on. very disturbing
He was dismissing the work due to the person doing it was a final year undergraduate. I was merely pointing out, by historical anecdote, that this project has as much change to grow and become important as any other project, and shouldn't be dismissed due to its origins.
Think nothing is impossible? Try slamming a revolving door.
I'd be curious if somebody in the know commented on how this compares with the Plan 9 project?
"a replacement that maintains network transparency while adding many of the features that people desire "
Is one of those added features, perhaps, reliability? (It seems that every other new XFree86 release introduces some ingenious bug that sucks up several days of my life.)
Why Windows?
I've experiments to run, there is research to be done on the people who are still alive.
The XFree86 server is (mainly) a set of drivers for various graphics hardware. It is possible XFree86 may not support your particular 5-button mouse. Without further information it's not possible to know. Please give the exact model name of your 5-button mouse and the exact version of XFree86 which are using.
Scroogle
The Hungry Programmers have had a 'Y Windows' Spec since at least 1998:
http://www.hungry.com/products/Ywindows/
I've read the article and it is the same tripe I've heard over and over again, "network transparency is the problem", "toolkits aren't integrated enough", "xlib is bloated", "[component] is bloated", "Project Berlin is the future (and in a state of continious lost direction too)".
There is nothing wrong with X in its current form. What is the problem is, is the lack of quality drivers. Here is any example, grab a run of the mill, generic XFree86 4.3.1 installation, buy a copy of Summit 2.2 drivers from XIG ( http://www.xig.com ), install them and see the difference. Then, grab a copy of X-Accelerate and Summit, install both then test it.
You will see that there is NO difference in terms of responsiveness or speed when comparing to GDI or Quartz.
Who do we blame? we can blame two parties, firstly the video card vendors who produce shoddy drivers for *NIX, and the second group is "ourselves". The only way we can send a clear message is to reward vendors who make decent drivers, aka Matrox and 3DLabs (Oxygen card is fully accelerated and opensource), and punish those who don't make a decent effort, aka, Nvidia and ATI.
Sure, us *NIX users may be a niche, however, when they see a sudden shift of several million users pulling away from a particular vendor when they do their 3 monthly video card upgrade, I think the message will be sent loud and clear.
"The difference between pornography and erotica is the lighting" - Woody Allen
What the hell is wrong with middleclick? It seems to work in allmost all of the apps I use.
And the one app that doesn't accept this is rdesktop, which is understandable.
Not trying to start a flamewar but I never had a problem with pasting in x.
The way to corrupt a youth is to teach him to hold in higher value them who think alike than those who think differently
I like the idea of a change, but it's probably not necessary. I've rarely had problems with X, but nothing that couldn't be cured with a "killall -9." Well, there was this one time... I accidentally fricked up all my config scritps and files for X, and it took me forever to figure it all out from the command line, which brings me to two other points:
1) if Y has a better way to configure itself than X (perhaps allowing the use of a mouse or a more advanced autodetection kind of thing?), I'd definitely switch- but only after I got my new *n*x system.
2) nevermind- it wasn't as good as I thought it was going to be.
Esoteric reference.
Free clue: Ask the people who come up with the anti-X arguments what background do they come from? Bet you it's Windows.
Oh well, one of these days we'll get the straight dope from the people who work on X on a daily basis i.e. The Xfree86 team
Which is why I choose to go with X. X windows does just fine iand is fast enough. The only ones I hear bitching are the gamers and why the hell do you want to run X when your running a GAME! What is really needed is a non X lib that virtualizes the graphics and sound hardware but has no need for windowing and the like. This whay your game launch script can just launch the game on another VT and then switch back when the game exits. For 2D stuff it's fine.
Having the choice of running different widget sets when I want to and running KDE or GNOME environments when I want to is good. Tying the widget set into Y is not going to fix anything. It's going to make more FORKS of Y then anything (a GNOME fork, a KDE fork....etc etc). UNIX is and has always been about choice. People go with UNIX because there are less hoops to jump through when you decide OK I am going to use COBOL (Don't laugh...it's possible...well for non graphical stuff) to develop my APP. Your nto stuck with trying to find a compiler that will do what you want to do concerning the API. You don't HAVE to use a API if you don't want to and if you need to (can't find a API that does what you want), you can write your own API. That's the TRUE power of UNIX and why unless Y does something significant (and I mean REALLY significant), it's not going to up and displace X. X has been out there for MANY years. There's something to say about stability!
That said, Xfree is not the only choice when wanting X. Depending on what you run, you can rin AIXWindows (for AIX machines), Solaris's X engine for Solaris machines and of course there's Xouvert. There are also many Commercial X windows engines. If you don't like Xfree, noone is forcing you to use it.
Y replace X?
Gorkman
...so why is X too slow now? Don't we like slow things that a faster CPU can fix anymore?
So what this means is every icon can be a 3d model? My nudes folder icon can have a dancer wrything along her... um pole.
Particles/T&L/stenciled shadows/Anti-Aliasing/Ansio filtering/etc???
Dynamic graphing for hardware monitor(s)/business applications which would lag any non-accelerated machine.
Dynamic (high quality) filtering/enhancement for video, nice for the big screen or other.
Cool effects which can provide a new experience to either professional or user side which cannot be provided any other way?
Much, much more...
Its a subsystem, the GUI goes on top of X.. that is where the inefficiencies come from.
Perhaps some reading is in store for you instead?
Ill give you that I've not read about Y, as I've not real interested in another 'we are better then X' project.
Instead of tossing out the wheel, we just need to improve it..
I don't understand the general mentality in OSS, always re-inventing what is already there. If you doubt me, how many text editors do we have?.. Mail clients?.. if we would all work together on one thing at a time.. it would be amazing what could get done.
---- Booth was a patriot ----
You probably shouldn't be blaming the "network code" for slowing your computer "in some cases".
Do you know that if you run a Linux desktop with the X Window System and GNOME/KDE, you are not necessarily using the networking features of X?
To use the networking features of X on your computer, you would need to login, over a network such as the internet, from your computer, which is running an X server like XFree86, to a remote computer, and, on that remote computer, start an X application, like xv , which would be displayed on your computer's display by having the remote computer communicate the graphics over the network to your computer's display. That's an example of actually using the networking features of X. That would also be slow unless you use a protocol accelerator/compressor for X which makes X completely usable even over a slow 28kbps network connection.
Scroogle
... unless you have read the paper, of course, in which case it will be a pointless answer...
1. There is an explanantion of how X compatibility can be achieved, and it is pointed out that such a compatibility is required for Y to become widespread,
2. Under the requirements, he lists the kernel 2.4 ATI driver, so he is using existing XFree drivers.
3. see other posts in this thread
4. It's a framework, with a working base implementation. The paper is well written, and allows for the real work on Y to commence. Of course it will take more than one year to make it complete, but of all the "replacements" of X, this one seems to be best positioned for a possible success. After all, it took another undergraduate 4-5 months to get his hoby project to a working state to be shared with others, and it took few years before that project took off...
I've been running Linux off and on since 1992. My first freely available installation was Slackware. I also had Yggdrasil. In fact, they still are running on these two 386 33's that I have (I keep waiting for them to give up the ghost but they just won't). That being said, if I can see that the lack of a standard interface is hindering the adoption of Linux as a desktop system, why is it that so many of you do not? Maybe I'm not as smart as most of you, however, a new standardized system makes an incredible amount of sense to me. Windows may be buggy, slow, and bloated. However, it is predictable. Predictability breed familiarity and, as so well evidenced by Slashdot, contempt. This contempt that /.'ers have for Windows is based solely upon its success and ability to shape the market.
X has some great tools and does some things that Windows obviously doesn't. However, if the tools and concepts are difficult to take advantage of by the normal end user, how will it ever penetrate the desktop?
You may discount Y for technical reasons, however, that is no reason not to seek the next level in GNU/Linux development which is to provide the necessary basis for a *predictable* end user experience.
Y-Box, DirectY ...
wait... X? Y? is this a male vs. female issue? XX / XY !!! GET IT?! AHHAHA!
anyway, revamp is the best way to go about it, not reinvent. too many man hours have already been spent in X... clean up, organize, be happy.
One more comment, if NeWS was so cool back then, how cool is it now or could it be now? Maybe some effort should be made to talk to Sun about release NeWS as open source so that it can be updated and ported. Maybe this would provide a good basis for a new UI for Linux?
There is, like it or not, a good reason for X to not have a toolkit builtin: Fashions change, but mechanisms usually don't.
If X had had a builtin toolkit, it would have been something even worse than motif, and we would either be stuck with that, or replaced X far sooner than necessesary.
"Seperate policy from mechanism", spake the Unix Guru. Policy, such as how GUIs look and act, changes much more quickly than mechanism, such as how to draw a spline or a pixmap.
This is not particularly important since Y is a work in progress, but you can see use of a GCC C extension in Y's button.c:
.c = &buttonClass, .reconfigure = buttonReconfigure, .paint = buttonPaint, .pointerButton = buttonPointerButton, .pointerMotion = buttonPointerMotion, .pointerEnter = buttonPointerEnter, .pointerLeave = buttonPointerLeave
static struct WidgetTable buttonTable =
{
c: &buttonClass,
reconfigure: buttonReconfigure,
paint: buttonPaint,
pointerButton: buttonPointerButton,
pointerMotion: buttonPointerMotion,
pointerEnter: buttonPointerEnter,
pointerLeave: buttonPointerLeave
};
That's not necessarily a bad thing - I think GCC is one of the best compilers around. The only issue here is that that particular named struct member syntax construct has been deprecated since GCC 2.5 and may be dropped in the future. If I understand the GCC docs correctly I think the alternate C99 syntax would be:
static struct WidgetTable buttonTable =
{
};
But I could be mistaken.
I see all these posts about how he's going to fail miserably. That might well be true, but why must we attack people who want try and change things in Linux that need changing? X is old, outdated and bloated. I for one, would love to see this project succeed, and like someone else mentioned, Linus started Linux as an undergrad project.
-------
"In times of universal deceit, telling the truth becomes a revolutionary act."
-- George Orwell
Someone quick, give this guy a job working on any kind of desktop and pay him money to come up with ideas.
I'm no X-windows guru, nor am I a hard core driver hacker (in fact I've been doing J2EE work for the past 4 years or so). But I do know one thing about the engineer who wrote that code and wrote that paper, he's what we all should strive to be like. Not the fact that his idea might not be perfect, and not the fact that his idea may never compete with X*, but the fact that he is driven. He's thorough, systematic, he challenges conventions and has the drive and determination to sit down think through a problem, find a solution and implement it. Then he goes back and tests it, compares it to the competition and spend a good chuck of time thinking about how to expand the idea, the possibilities. He's not the guy who just sits around complaining about the problems and ripping apart all the solutions. He's the one making steps to solve the problems.
In 15 years (hopefully), the world won't be run by desktops or workstations running X or even Y or Z. It will be run by software that takes all the great concepts from all of them, none of the bad concepts and a few new concepts and puts them together.
The philosophy behind Y can be applied to any project and any technology, whether its an OS, a graphics system, a protocol, a web framework or a new language.
Enough ranting, my hat is off to this man.
Brian Pontarelli
CEO and founder of Inversoft.com : Invert Your Mind
True, but Linus didn't plan it as the next big thing that replaces Unix and Windows. It turned out quite well after years of work by many contributors, and the same thing might as well happen to Y. It's too early to predict anything, so in the meantime it's probably best to do as Linus says: forget about competition and just focus on writing good software.
Escher was the first MC and Giger invented the HR department.
"Y" do we need another windowing system?
The MacOSX comes out and blows away anything the Linux community had or could have due to the twisted X.
"Y" not call it X++?
It is based on C, but if it was C++, X++ would be a nice name.
"Y" is (GTK/QT/motif/etc) not good enough?
GTK is great but if you read his article he explains a plethora of reasons. He raises a good point about software development on Linux. QT is doing some great things, through integration; however, if the community focuses on one highly themeable environment...
Also toolkits are just another layer of abstraction, which can only make it slower (yada yada yada about optimized objects.
"Y" listen to a college senior, when other, more "qualified", people have tried to tackle this problem?
If you read his article, you will see the kid is pretty damn qualified. Someone mentioned Torvalds. No one mentioned Gates, and with good reason. Age is a state of mind to everyone but the Government.
I know you were mainly joking, but I had to rant and rave b/c I really like this project. Am I the only one?
slamming cock into one's girlfriend's mother has the same effect :(
Do you even lift?
These aren't the 'roids you're looking for.
That's true, as far as it goes, but is pretty much unnecessary.
The "norms" as you call them can click through a RedHat or Mandrake install if they want, and if they accept the defaults will end up with a desktop that is not so far removed in usability from a Windows interface that they will be incapacitated. At least, unless they are such complete morons that they shouldn't be allowed within spitting distance of a computer...
This notion that everybody should throw out all desktop environments except one and unify is all very well until you try to decide which should go or stay.
The whole point is to enable freedom of choice, not to turn Linux desktops into Microsoft-style dictatorships.
I use Linux on the desktop 99% of the time at home, and I feel it is definitely lacking in areas. Where X is lacking (and the toolkits) is of course, as you said, consistent cut and paste behaviour (for non-text items as well!), speed, and the ability to be reconfigured without restarts (and for it to start in a safe mode if the settings in the conf file dont work).
On todays desktops, X is as important as the kernel. XFree86 needs to be as stable, and as dynamically configureable as the Linux kernel. It needs to be able to dynamically load and unload drivers and settings without a restart. If X crashes (or locks up), it might as well be the whole computer locking up, nobody is going to ssh in and kill X, they're going to hit the big red button.
I think this is going to take years before it's sorted out. But with Longhorn approaching, it might end up being too late.
Must be deep and dark...
Blar.
What will they do after they've finished with Y and Z, they'll have no more letters of the alphabet then. It'll be a disaster
Then Norway will rise to world domination with the AE Window System.
The first thing that will then happen is that Slashcode will be eradicated; because that piece of Perl junk won't let me use a proper Æ in comments.
/A
Unfortunately, the name Y Window System has already been taken by the Hungry Programmers. Still, Z is probably free :-P.
-- Ed Avis ed@membled.com
C was the successor to a language called B (which was built on BCPL, which was built on CPL, both of which look more like Pascal than anything else, but I digress) and yet the successor to C was C++.
There are 3 toolkit, and the 3rd is at least as important as Gtk+ or Qt.
It's mozilla XUL.
X Windows succeeded because all other options on Unix or Unix-like workstations were fundamentally awful, whereas X was just plain awful. This is because everyone who's designed a GUI environment or toolikt for Unix was fundamentally clueless, or in the case of X, plain clueless. I don't doubt that X works, but so did the Pinto.
...anon...
Anyone stating otherwise should examine what portion of the desktop market is held by X-Windows-based systems. Those of us who need to get work done use Macs or PCs. Others who like to fiddle endlessly with window managers, desktop themes, wiggly titlebars, floating eyeballs and incompatible applications can continue using X systems.
I wish it were otherwise. I wish that X had been designed better to start with. Instead we had inane and dumbass declarations like "mechanism not policy", on the supposed notion that somehow magically beautiful toolkits will evolve and the world of Unix finally will be set right. So much darwinism, so little evolution. Now, almost twenty years later, we have the declared winners, Gnome and KDE (aka the Monitor and Merrimac of Linux desktops), both incomplete, backward-looking and non-pioneering environments.
The only useful solution would be for either Apple or Microsoft to port their environments to Linux. Given what kind of a mess most MS code must be in, the only market-viable candidate is Apple. Quartz already has all the unix microkernel underpinnings anyway.
Come to think of it, if Apple were to just port MacOS X to x86 platforms, we could solve this whole Linux desktop misery thing once and for all. Of course that would eliminate Linux, but oh well, much worse things have happened to computing already and we've all survived.
In fact, probably millions of software jobs can be attributed to really crummy system designs that required all sorts of patches and workarounds in order to become useful. If those systems had been built right to start with, most of us would be laboring elsewhere and otherwise.
Perhaps I should stop myself before I cause an economic collapse...
I think a lot of you guys (primarily developers, I guess?) are missing the point. Sure, X is perfectly fine for most of us, but it simply can not compete with the more popular "windowing" systems. Things have gotta become a shitload more pretty for that to happen. "Fast" doesn't matter if it's not fast compared to Windows on the same box, and maybe it's the drivers, but if it can be helped elsewhere, then why not make it BEAT Windows? In all aspects. I work for a dozen or so companies, and I would feel comfortable moving all of those hundreds of users over to Mac, assuming their applications were available. But even IF all of the those programs worked under X, it's just not fast, clean or cozy enough for cranky doctors and traders. Only developers benefit from using an ultra-extensible ancient system that requires basic understanding of the underlying operating OS. For everyone else it's just inconvenient. So yeah, X is great, but projects like Y are critical creating a true desktop choice for the masses.
I think, in order to be accepted, it would need X-Y and perhaps Y-X bridges. A bridge that allows you to run arbitray X apps on a Y desktop will enable it to be used. Then perhaps we can see more Y apps being built.
I didn't catch what it did for window management, but X's seperate window manager wins over Windows any day - not only because of the choice, but because an application crash doesn't cripple the window manager. On Windows, window management is done by the client app itself (or by the Windows libraries running as part of the client app).
Fresco
And you're wrong.
I was at the University of Michigan, which was an all Mac and Apollo shop essentially. We had a few Suns and X was criminally slow on them. X was so slow that Sun developer other alternatives instead (Sun Tools, etc). It would take several seconds for an X window (say, xterm) to come up.
Sun's couldn't run X at any decent speed until they went to the SPARC processor and got more RAM. And they couldn't match the speed of a Mac (say, IIci) until they went to faster busses on the SparcStation (SS2?).
X had many problems, to set up a window would take many many transactions. Each transaction was stop-and-wait. Also the memory usage was just too large for the RAM in machines at the time.
When shared memory transport became available with X11R4 it helped a little. And when they removed much of the stop-and-wait transactions to initialize things in X11R5 it helped a lot. Oh, and when X11R4 started to use the video accelerations in hardware on some machines it helped a lot too.
I never saw X reach the level that you didn't wonder if there was a better way until the HP PA/RISC machines came out.
Personally, I still don't think X is as fast as a Windows. Windows doesn't use network transparency though and allows video drivers to live in the kernel. Both of those add a lot of speed. You might not like the trade off though, which is find since X is plenty fast enough now for most things.
(yeah, I suck) Fresco.
Thanks for playing! I never said Y depended on SDL talking to X. I said SDL did not depend on X. Which it doesn't. Learn to read.
So, what's your point? People should never try? I think we have, manifest in you, 0x0d0a, the entire poisonous reason the human species doesn't get its act together.
unless they are such complete morons that they shouldn't be allowed within spitting distance of a computer...
It's offensively mindless ramblings like that that are a) keeping Linux out of majority desktop share and b) keeping the sterotype of the arrogant geek strong in the hearts and minds of millions.
Computers are not important enough to serve as the deciding factor of one's intelligence. I would argue that social skills are a much better yardstick, and by using it on your post above, I see that you shouldn't be allowed within spitting distance of another human being (loosly assuming that you are one yourself).
Computers are just pieces of equipment that some people understand, and some don't. Could you rebuild your car's engine from scratch, or do you take it to a mechanic? Does he make you feel like an imbecile because you don't know how to tune your own fuel injectors?
The norms need some kind of consistent interface, and Linux (or *nix in general) just doesn't provide that. Yes, they can click through a Redhat install (doubtful as one of the first things to do is partition the drive, and I can't see my mother doing that), but it'll be different enough from what they know. And, then, what if they want to install a new piece of software? Do they have GTK? Probably. QT? Again, good possibility. OCaml? Ahhh...I don't know...and they sure as hell aren't. (I know, not a toolkit, but an example). All they know is when RPM tells them they need it, they won't know how to get it. And, considering how well written 90% of the install docs are, they'll never find out.
Which is more painful? Going to work or gouging your eye out with a spoon? Find out!
http://www.workorspoon.com
To say the security of X is horrible because silly people have done "xhost +" is ridiculous! Doing "xhost +" should make absolutely no difference to your computer's security with respect to network attacks because your computer should have a firewall which (at least) blocks incoming and outgoing X11 connections. Anyway, if you want to run X applications on remote computers, the best way to do so is to use ssh for securely forwarding the X11 connections to/from the remote computers., e.g.
ssh -X -l login_name remote_computer
or
ssh -X -l login_name remote_computer X_program
Scroogle
Just looked, and -- tragically -- the code is GPLed. So long as it has a viral, anti-commercial license, this code will not gain the support of commercial software vendors, and will not be able to make the inroads that X has under the MIT license. If the author wants it to go anywhere besides Linux (if it even becomes popular there), he must reconsider the licensing of the code.
Thank you *very* much for pointing this out.
For some reason, people (generally folks new to X) consistently manage to completely misunderstand how X works, and happily rant about it. Among the issues:
Problem: X has bad 3d support.
Answer: No, it doesn't. Manufacturers have just barely put out drivers, and still don't have great install procedures. Starting with a new system would make this problem orders of magnitude worse.
Problem: X uses lots of memory.
Answer: No, it doesn't. Try running pixmap_mem (and the analyze script that comes in the same package) on your system. Unlike Windows apps, X11 apps store pixmaps in the server. X11 newbies frequently confuse this with X using a lot of memory. Combine this with the fact that Unix memory utils multiple-report memory usage of shared libraries, and report device mapping as memory usage, and people look at X and say ("Oh, it's blowing 30MB of memory in overhead."). No, it isn't. Trust me.
Problem: X11 is inefficient.
Answer: No, it isn't. X11 is pretty damned efficient. Today's pixmap-laden interfaces can run much more slowly over a network than the original interfaces, whicch were mostly big, flat-color rectangles, but the same is true of VNC and similar.
Problem: X's multiple-widget set system is a bad idea.
Answer: No, it isn't. People look at X and think "Gosh, I don't want to use Athena apps." The thing is, the widget-independent design of X has been a huge boon. X11 dates to 1987. If we had been unable to advance through widget sets, we'd still be using ugly, grotty Athena. But, you say, this ignores the fact that Windows and Mac OS have advanced through the years! Nope. First, Windows widget sets *have* broken user-level compatibility on a regular basis. Menus in Office XP now work a lot differently than menus in 1987 did. Second, some widget sets are hamstrung by initial design flaws. The classic MacOS widget set does not include a slider widget, for example. As a result, years of application developers misued the scrollbar widget, made up their own widget (which led to even worse user interface problems), or just went without. The ability of X11 to evolve has let things like KDE's tearable panes come to the fore. Also, when it comes to APIs...the modern, easy-to-use APIs of GTK and Qt blow away the horrific Macintosh Toolbox API (note: I am not a Cocoa developer, so things may have improved) or the almost-as-grotty Win32.
Problem: X11 is hard to use.
Answer: No, it really isn't. Occasionally, piss-poor setup on the part of distro makers has made things more of a pain than it should be. If a user isn't interested in remote windowing, he shouldn't have to worry about xauth or xhost. This is largely a problem of the past.
The main "problem" with X11 is actually newbies to it making a bunch of claims about software that they haven't used and don't understand. They've frequently just come off of a decade of Windows use, and expect things to work in precisely the same way, and are horrified when there are differences.
The majority of people I've seen complaining about X11 are Johnny-come-lately types. Most of the older folks who have been using it for a while just don't care enough to respond to the complaints, which they see as pretty uninformed.
Now, there are things about X11 that aren't that great. X11 supports an *extremely* rich color model. If you're using Xlib (which you shouldn't be doing unless you're writing a widget set), it is a royal pain in the butt to support every color model available. This was done to handle the vast array of hardware that X11 has been run on.
X11 doesn't support a great way to share identical pixmaps from different apps. This is really hard to do in a secure way.
Basically, I'm reminded of the SSL discussion that came up recently. Everyone wants to run out and rewrite SSL to be simpler, faster, easier. They don't understand that the stuff in SSL is there because it *needs*
May we never see th
The guy is lying (or trying to be funny) Windows used protected mode 16bit (and later on enhanced mode 32 bit) and would require at least a 286 (AT machine) to run.
The thing is that you're assuming that all widget sets provide the same functionality (or that you can go with the least-common-denominator). In reality, that'd make for some pretty awful applications. You'd have to give up your KDE-draggable-panes (not supported under Win32), your sliders (not supported under classic Mac OS), gtk's easy layout system that provides automatic resizing support (Win32 and classic Mac OS use a pixel-based layout system). Some widget sets use infinite progress bars (XUL), some use animated icons (Windows). The two can't fit in the same space.
You're thinking of something simple, like theme engines. These *are* pluggable, and plenty exist for gtk. You can't just drop in a new widget set, though.
Xlib *was* designed so that it's easy to develop widget toolkits, though.
May we never see th
Well, what you're saying is a nonstarter.
When people say "we want one true toolkit" they are users saying they want one user interface. If someone standardizes themes, keyboard commands, clipboard handling, etc. then what they've provided is the one true toolkit.
Of course nobody cares what code was used to generate the app. Nice meaningless observation. What people want are the applications to behave similarly regardless of who programmed them using what and to have a universal look and feel. That's the one true toolkit.
"4.Severe security issues in the protocol. Especially no encrypted operation at NATO standard SECPROT level 4"
What a hilariously absurd comment! I can just imagine this guy's physically insecure office or home PC equally lacking TEMPEST-approved hardware and secured BIOS, and the terrible risks he must surely be exposed to (day in and day out!) due to the lack of NATO standard SECPROT level 4 encryption!
Scroogle
In my opinion, the biggest problem with X is that it's not device-independent and provides no way for applications to render to a printer as easily as they do to a screen.
Sadly, Y offers no help in this department. If someone is going to design a rational replacement for X, printing should be at the top of the list for design consideration.
XXX!
Don't tell me Linux will still be low profile if its windowing system has THAT name.
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
We're still using a keyboard designed to lessen the chance of hammers jamming and this guy is hoping to replace X ?
If all you do is wander aimlessly with all this 'choice' and so many unfinished 'alternatives' then no one benefits, and the movement is rendered ineffective and irrelevant.
"choice" can be taken too far...
---- Booth was a patriot ----
Alpha blending is very useful, I want to be able to see directly through my terminal window while something is compiling and I'm browsing websites. I guess you arent a serious Linux user, go back to windows.
Here we are, in 2003, and the most appropriate language in which to write Y is...C?!?
The mind boggles.
I'm beginning to think the solution is the industry-wide adoption of the current flavor of FORTRAN. Now there's a timeless language. ;-)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
The toolkits don't care very much about the underlying technology. I'm not suggesting that Y be treated as a framebuffer, I'm offering the framebuffer as a kind of lowest common denominator. Look at SDL and GGI as other examples that basically don't care about the transport mechanism.
Got time? Spend some of it coding or testing
This spring chick probably started out with big delusional ideas but quickly got swamped with Organic Chem 1, and so he probably banged out a simple windowing system that runs off libSDL over a network (based on ideas from non-scholastic doodling), wrote two pages of documentation, slid it under the professor's door two days after the due date, and hoped he woudn't get bad marks for the course.
We need a -1 retarded mod. (Please mod this post +2 Funny. kthx?)
1. Y has been designed so that an X compatibility layer would be possible to implement. You wouldn't get many of the benefits from using Y, but it would provide backwards compatibility. I'm pretty sure that's mentioned in the project report.
:-)
2. Wrong. Hardware interfaces for new drivers can always be derived from the X source code (where available); if it becomes big enough, then the companies may well be willing to describe their specs for a Y developer, too.
3. The KDE and GNOME desktop projects have a lot of code which is no-longer needed if adapted to run under Y. The applications could probably be adapted to Y with relatively little effort.
(I'm not an X/GNOME/KDE coder; the above may be an exaggeration one way or the other.)
4. ``this guy`` is a friend of mine. I know him, he's smart. He aced a first at one of best university's in the UK and got a prize for this project.
You are clearly only questioning the fact that an undergrad could develop something worthwhile when nobody else did. I'd much rather you'd debate the quality of the work rather than baselessly disparaging the person who created it.
Oh, and it wasn't a year of work, it was 9 months, tops. And he still had 8 other courses to do at the same time along with a break to do the requisite 8 final exams.
Cheers,
David
Well and good. About time for an X replacement, I'd say.
Once the basics are done, and it runs stably and fast, people will gain interest - and not until (for the most part). No doubt we'll soon see GTK and Qt ported to Y. Applications will be soon to follow.
Granted, I really don't know much about how X works. Would a simple port of a given X app be possible, maybe just a recompile, provided the toolkit was there and available?
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Even a perfect incarnation of X/Y will be abused and treated as a dumb buffer by many libraries for the sake of asthetics.
You can't judge a book by the way it wears its hair.
This is clearly a troll, but whatever:
/dev/input/eventX handle for it, and a driver exists in Y to support it, it'll work.
1. The widget component system is designed so that you could create native widgets for, say, a video renderer. In this manner, you could send it a raw MPEG-2/DiVX/whatever stream and have it rendered and controlled properly with minimal effort. And if you're operating over a network, you don't have to render it client-side and send each frame; you can simply use the compressed stream.
Similar widgets could be implemented for audio, OpenGL-based 3D, etc.
2. This is not a well-substantiated argument. There is no clear reason why Y could not scale up or down.
3. Wrong. So long as the kernel can understand the device, present a
4. This will be an extension. Or you could just tunnel it over SSH, much like X does now.
5. Flat-out-wrong. I've seen this run over a slow link, and it works just fine, thankyouverymuch.
6. ``Smooth integration`` is ill defined. If you mean GUI tools for managing a machine, well -- that's an applications, not a windowing system, issue.
7. It doesn't need a window manager -- it *is* one. If you don't like it, you can write a new backend driver to provide the one you want.
8. You can always gzip the stream; that could be an extension. But you already get a lot of benefit from the from the design of the widget system over, for example, X.
In case anyone is fooled by the baseless criticisms of X given by the regular troll above, here is a brief rebuttal.
Most major computer operating systems have 2d user-interfaces, but this doesn't matter because applications provide their own 3d user-interface if they really need one. Another reason may be that there are very few genuine 2D users who can satisfactorily project themselves onto a 3d user interface. Transparency is not a major requirement for X because those rare applications which require it can implement it themselves e.g. using GIF or PNG transparency. There is also going to be a transparency extension for X
Not true. X runs fast, and much faster than Microsoft Windows 95, on my old i486 PC with 8MB RAM.
This is a problem not of X itself but of the hardware manufacturers not writing device driver modules for XFree86. When enough people run Linux desktops in the opinion of the hardware manufacturers, device drivers for XFree86 will be written.
This has been nominated for Top 10 Absurd Comments on Slashdot. With a properly configured firewall, this is irrelevant because nobody on the internet can attack your computer's X display. By using ssh for securely forwarding X11 connections most attackers will be unable either to watch or to disrupt your X session.
Very few people ever use the X11 protocol over a network, firstly, because most people who use X are using it for X applications running locally on their desktop computer, and, secondly, because anyone wanting to run X applications on a remote computer would use an X11 protocol compressor. The X11 protocol is complicated because it is powerful and easily extensible. As an aside, most intelligent people don't seem to have much trouble understanding the X11 protocol or the various extensions.
That would be a very bad idea. Increasing the complexity of the interfaces between vital system components such as the kernel and X is a recipe for worse security, worse compatibility, and worse maintainability.
Integration with what? X? The whole point of separating window management from X is to give you the freedom of choice to use whichever window manager you like. You can even change the window manager without having to reboot the kernel or re-start X. Otherwise, if you don't like using window managers, use GNOME, or KDE, or return to MS-Windows.
You don't seem to have heard of NX for real-time X11 protocol compression which typically achieves a 1000:1 compression ratio, of the ancient LBX, or of Differential X Compressor
Why oil price increase equals economic trouble (Score: Interesti
Well, I've only gotten as far as the critique of X at the start of Thomas' paper. This critique is a classic /. "X sucks" troll in academically semi-polished form.
Point by point:
- X has too much latency: See Packard's paper in Freenix 2003: high latency is not an inherent X attribute, even over high-latency connections.
- X requires a toolkit for ease of programming: Duh. As opposed to what, exactly?
- X needs standardized UI semantics: This is moot. You may use X+Gnome or X+KDE if this is what you desire. Either is a fairly good and fairly complete system with standard UI semantics. The existence of two such systems is no more troublesome than the simultaneous coexistence of Windows and MacOS.
- X is "an incoherent mess": When making this argument, it is always useful to confuse the protocol with the implementation. The existence of Kdrive is a nice example of how much the latter can be cleaned up. The protocol hasn't changed in 20 years except for extensions: the argument that the extensions don't work together is supremely unconvincing, supported by one lame example. freedesktop.org has made a lot of progress in a short time in refactoring and standardizing X.
- X is complex: It is. Unfortunately, it is a response to complex application requirements. Again, one lame example involving perhaps the most demanding application running is cited. And again, freedesktop.org is standardizing mechanism for dealing with the cited problems.
All of this would have been easy to avoid. Just talk to an X developer before publishing the paper. Many are quite accessible, and would undoubtedly have been happy to correct the critique.It's perfectly valid to want to write a new window system. I can think of a variety of justifications, starting with "it's nice to try something different" and "I wanted to learn some things". Trolling is hardly necessary, and hardly welcome.
The parents of this kid are probably going to sue slashdot for spreading this mediocre class project all over the internet and exposing this young man to ridicule. Look what it did to Linus Torvalds. Poor kid.
The author's final stated goal? "Improve on X, and enable extra features like widget buffering, alpha transparency, and desktop resizing."
He has improved briefly and partially. Desktop resizing (which works far better than he claims) and alpha transparency (via Render) are already there. Widget buffering (actually server-side window buffering) and alpha transparent window support for X were designed last night, and implementations should be available in a couple of months.
Why improve upon X? Just improve X.
So, the author reduces years of Microsoft's market dominance (with no mention of any previous versions of Windows) to:
"Windows XP has many of the features of both X and MacOS listed above, though it has no outstanding features of its own.
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."
This is not an analysis of a windowing system, this is someone's predjudices and opinions showing, about how the operating system interacts with the data presentation. It is stuff like this that forces me to doubt the author's knowlege of his subject area. Is there any analysis of how MS has integrated an interpreted scripting language into their windowing system? Any mention of Remote Desktop, OLE / embedded applications & shared toolbars, HTML/XML integration?
I'm not usually a Microsoft proponent, but let's at least give a nod to MS that they have had some skilled programmers in their employ over the years, and have come up with some creative ways of blending applications into easy to use products.
The Berlin Project (now known as Fresco) has been working with replacing X11 since begining of 1999 I think. Anyone tried their window/desktop? http://www.fresco.org
crevasse: a deep crevice or fissure (as in a glacier or the earth, or a graphical windowing system)
It doesn't even compile...
The one thing that, for me, makes the biggest difference in the apparent quality of a desktop is how the redraw scheme works. In Mac OS X, Quartz buffers the contents of every window and takes care of redrawing the window when it is exposed. The result is that there are NEVER any redraw issues when an application is busy doing something - when a window is exposed, it looks like it is already drawn. Even a completely frozen application still gets redrawn properly.
The lack of this is always the first thing I notice when using an X-based desktop (Windows has this problem too - OS X seems to be the only desktop to actually get it right, which makes sense, since it is only recently that memory has become plentiful enough that this makes sense). It is very distracting to, for example, drag an xterm window across a Mozilla window and have the xterm leave a nasty little trail across the Mozilla window where the redraw hasn't caught up yet.
So I hope that anybody who is working on an X11 replacement keeps this in mind - when you're working on a brand new system, you should take advantage of the fact that you're already breaking compatibility - might as well do what Apple did and go all out in creating the best system possible.
Definitely has a ring to it. Though things with "open" in their name usually sound like they're based on open standards, but are not free software -- still, there is a stylishness to it all: OpenWindows, OpenStep...
(Yes, I know there are thousands of counter-examples: OpenOffice and OpenBSD to name a few.)
The filesystem is the package manager
Like I said in prior similar topics, for intranets, businesses really want an HTTP-friendly GUI to avoid firewall hassles. Candidates include XWT, and SCGUI (my pet). I suppose XUL could also be included. HTML forms + JS + DOM is really a pain for GUI emulation.
Table-ized A.I.
QT was developed after object oriented methodology was well understood. Its far easier to learn than Motif. There is genuine progress.
X is an old protocol, designed to work on slow machines
When articles about X appear, everyone says that X has problems because it is old. And I almost understand if features were hacked into it, but they should become efficient during the open source refactoring. X is one of the big projects, so everything should be reviewed regularly, especially anything to do with performance since that is the itch that everybody wants scratched.
What I do not understand is how older is not better. Older code was written when resources (CPU cycles, hard drive space, bandwidth) were scarce and programmers cared about performance. I have tuned many apps where the original programmer used the first algorithm that worked without any thought about performance. The old-style programmers had to make every function as quick as possible or the apps would not be usable.
I was building a commercial app on the just released 386. My original search algorithm sucked: start at the top of the index and continue until the key is found. But it ran great on the 386. Then a customer ran it on an XT. Ouch. It took almost an hour to run. A quick rewrite and it would run in less than a minute on an XT. It was the requirement to run on limited resource hardware that forced me to fix it. I learned to always care about performance. If all the customers used Pentiums (which did not exist then) than the original algorithm could have survived without complaints.
My question is:
How can an old protocol designed to work with slow machines be worse than a new protocol that requires modern hardware?
I spend my life entertaining my brain.
XFree, on the other hand isn't. Form what i've heard, XFree either needs to be replaced with something similar or have a managemant change. That's where everybody's complaints come from, the XFree team's reluctance to add patches.
Btw, if you think X is slow, don't use KDE or GNOME on old hardware. Or at least turn off all that eyecandy. As pretty as they are, they don't run good on anything but failry new computers. Try enlightenment. It has all the features of K/GNOME and a lot of eyecandy, but runs on older hardware fine. I thik idesk works with it as well for desktop icons.
Whenever someone brings up the topic of replacing X, everyone always says that's nice
Hey, I'm part of everyone, and when I hear someone suggest replacing X, I always say "gosh, are you stupid." They are, too! Every time.
If it utilizes features that the new hardware introduces and the old protocol doesn't, then it will run more efficiently (or with better features) than the old protocol.
It's kind of the same reason that some projects don't care about backward-compatibility because they get the benefit of a lot less kruft.
So, in some cases, newer protocols are better.
I might add, by the way, that the GPL will also prevent commercial developers from programming for the environment. It appears that all of the required libraries, etc. are GPLed, so that any program created for the environment must likewise be GPLed. Few programmers can afford to write a serious application without having some means of being rewarded financially for their work. Again, the license must be changed or the project, regardless of its merits, is destined to go nowhere.
Y may not fly so ill start coding Z in ASP ... .NET?, You Bet!
-Don
PS: To annoy X fanatics, Don specifically asked that we include the hyphen after the letter "X,", as well as the plural of the word "Windows," in his chapter title.
Take a look and feel free: http://www.PieMenu.com
> Older code was written when resources were scarce and programmers cared about performance
Older code also often had a crippled design in order to work around hardware limitations of the day.
Some examples: your XT program was probably written in real mode DOS and was eventually dumped in trash. Windows 95 and Classic MacOS are ridiculously efficient GUIs, but that doesn't mean we want to use them. A large number of the optimizations in classic BSD UNIX were VAX-specific and had to be trashed.
So, just because X is really quick at displaying Athena widget programs doesn't make it efficent modern software (which can be seen by observation).
-Don
Take a look and feel free: http://www.PieMenu.com
Depends are the brand of adult diapers you need to put on your head, to keep to verbal diarhea from dripping down your neck.
Oops, Mark, not Mike, my apologies.
-util/rectangle.c redefines MIN and MAX already defined in yutil.h
-consolecreate in widget/console.c tries to destroy 'font' (whatever it is).
-there's no simplerenderer.h
Now.. what are those features? No really!
X itself has no direct hardware interface, it uses a device driver. X is a message parsing system, that enables a process to parse its output on to be displayed. Thats done via a socked (unix|inet), and thats the way (tm) to do that kind of thing in Unix. This socked stuff is also the feature that provides the network transparency in X. Any new window system for Unix are likely to use sockets the same way, so.... I guess you guys will have to live with the network transparency.
If you were to create anything different, it should be for an entirely different demand like gaming, where alternatives already do exist. Here X was replaced (or rather supplemented) very quickly.
Message parsing needs to be done for any system to function. Its done that way in Windows too. The most significant difference is, that much more of the windowing system runs in kernel space in Windows, so it cant be changed or removed the way X can.. talk about bloat, but thats an another discussion.
* Top-level windows are always buffered.
Reduces the number of repaints, for example
when a window is moved.
* The widget system sits in the server.
Reduces client-server communication.
* Built-in support for multiple-monitors
and desktop resizing.
* RGBA color model (transperancy).
* Hardware acceleration support, but only
on cards that support alpha-blending.
My conclusion:
Y is neither 90% compatible with X, nor runs faster, have more drivers, or has too many new ideas.
In Y, "applications are forced to use the same set of widgets" (in the Conclusions). If you propose a standard widget system for Unix, it must be very good. But little thought had gone in this direction in Y. Ok, it supports themes, but what about widget behaviour? should menus work like in Windows or like in MacOS?
Therefore, "In comparison to Windows and MacOS X, Y is a capable competitor" (in the Conclusions) is a bad joke.
Nice project, but it takes much much more than that to replace X + GTK/QT/Motif.
Now, one of the greater percieved advantages of Windows over Linux is that the user interface reacts faster - I readily admit I'm sold on snappy interfaces - the always-present slight delays of X bothers me.
Question now is: Does Y do anything to improve on X in this area? If not, it's just Eye Candy to me - nice, but the day I toss X I want something that fixes the lag problem.
I'm in a Unix state of mind.
Good points. X is actually very fast, especially on the local machine. To get the best performance out of X, the programmer must understand and use the X API. Obvious example: use XDrawLine to draw a line, rather than implementing your own Bresenham algorithm and plotting pixels. Less obvious: use XDrawLines to draw multiple lines, rather than calling XDrawLine repeatedly. Create the right number of GC's (graphics contexts) and switch between them, rather than modifying one GC.
All of this is hard to abstract. Once you build a "toolkit" atop X, it's quite possible that some performance will be lost. I suspect this is what happened with GTK and QT.
Then there are apps/toolkits implementing features that really should be in the windowing system, like enhanced font rendering or translucent backgrounds. These are sometimes implemented by rendering on the client side and sending images to the X Server. Naturally, that's slow. I think X is getting the extensions to make this unneccessary.
except for the thing where all of your x session goes over the loopback device on the local machine. It was written for network, and it does a good job of that. But, the problem is that it can't stop doing a good job of that. When not on a network, in order to get stuff to work, it has to go through an unnecessary step to make everything think it's on a network.
I know how X works. We need *some* sort of window manager - slash - GUI - slash - unified display system that is for personal computer use. It needs to talk to the hardware, and it needs to focus less on customization and themeability and more on unification and cutting out steps that aren't necessary.
This is a barrier to linux on the desktop. X is slow and clunky. I can run windows XP with all the features and pretty stuff turned on on my 333 celeron just fine. When people say X is fast, they're using it on a fast system. Also, another thing keeping people from being able to use the linux desktop is lack of unification. It's something that linux users like - the ability to customize to hell - but when windows user A goes to windows user B's computer, they can find everything because it's familiar. Not so for linux, if I go to use my friends ximian setup, and then switch to my other friend's darwin set up, and then pop in KnoppixSTD for some network assessment, none of them will look like my gentoo gnome2.0 setup.
~Will
sig?
To clarify the thing about the 333Mhz - the window system runs fine. It takes a coon's age to start any applications.
sig?
Any such "prepress image editing" has nothing to do with a low-level display server, and would be done by the application talking to the server.
All apps under a network-transparent window system have to be linked to the client library that talks to the server. If this client library is GPL without an exception such as that of Guile's license, it is impossible to make proprietary apps for the window system without clean-rooming the client library (expensive).
Will I retire or break 10K?
I've been reading some of the replies to this idea... and I think it's quite clear what the results are of this discussion:
1. There are 2 camps when it comes to X. The first camp sees no need to replace X as it is a standard base which the Unix world has used for 2 decades. The other camp sees X as antique technology which is due to be replaced.
2. There are some who like the name 'Y', but most don't. Jokes ensue about this name.
3. There is some disagreement about putting a standard wigetset into the server itself.
My $0.02:
1. I would agree with the PDF that X, although successfull, is old and outdated technology. Thus, I support Y (and any other prodject which tries to update old code, thus competing) but I do not see it taking over any time soon. Also, one should note that there is very likely a lot of useful working code in X, which should be used or designed from. Y will not be successfull unless A) it works as well as X, B) has some backward compatibility to X, and C) has some application support.
It's like an old car vs. a new car: The old car isn't broken... it works. The new car does the same thing as the old, but it has some nicer features. Since the old car isn't broken, don't fix it. When the new car can do the same things the old one can, I'd use it. When the new car starts to do things that the old car can't do, most others will use it as well. (And since price isn't an issue with these cars...)
2. The name of 'Y' for the graphical interface is fine by me, just as 'C' is the replacement name for 'B'. The Y symbol is also quite pleasing, although I understand that it has been used elsewhere.
3. I think the author of the PDF did not intend to replace QT and GTK. Instead, he intended to simplify the most basic operations such as buttons and window sizing into the server's domain, not the window managers. Doing so would not make KDE or Gnome obsolete, but they would need to be re-tooled to use the pre-existing Y controls. Also, this allows programs which do not want to depend on QT or GTK libaries (or others) to have a uniform look and feel with the rest of the system, rather than re-inventing the wheel every time.
I hope the best for this prodject. Even if his project fails, he will have learned great things about programing and open-source politics.
Pathway
It's abandonware based on an obsolete and inefficient CORBA IDL binding. Read the Y PDF file for more info.
Something with a string datatype, automatic bounds-checking for arrays and strings, and better memory managment than malloc()/free() for starters. Doing away with direct pointer manipulation would be nice too. Worrying about where an object is in memory and how much space it uses should be a job for the OS kernel, not for an applications programmer. Personally, I would like to see something like Python, except that it could be compiled to native machine code instead of running in an interpreter.
0 1 - just my two bits
I see some flaws in the document posted.
I love research, and more than anything I love the people involved in doing research: those who create, explore and can give us future direction. But I also believe that the research must be truthful if we want to build on it.
The Y presentation paper is interesting on the ideas it introduced (we could argue whether they are new or not, since NeWS did did before, in fact, with a more extensible system) but it fails on presenting X correctly.
The document goes on to show that the X-based approach has lead to major GUI fragmentation, and how the MacOS and Windows do not have this problem.
On the screenshots where X looks bad, the author shows some old graphics program running together:, xpdf and two modern apps: mozilla/xul and gnome calculator. All of those programs have Gtk-based or Qt-based equivalents that would have made the whole experience consistent.
The screenshot should instead be presented as a proof that X can still run applications that were developed 12 years ago.
Then he shows the Mac and Windows. Again, not really honest screenshots, because even Apple is shipping two different GUI views: the brushed metal theme and the aqua theme (this combination kills me) and Microsoft is not exactly known for keeping their GUI look consistent across their product line: Office, MSN and the rest of the desktop use different styles and widgets.
So summing it up: the screenshots are presented to prove a point which happens to not be there.
Now, to make things even more interesting, here is a little bit that the author of Y might not be aware of: widget rendering on MacOS X happens on the client side, and the operation that the server supports is basically "uptade-rectangle-with-this-RGB-buffer", there is no magic of server-side widget rendering on MacOS X.
Also, doing an X protocol translator is not an easy job, but I wish them good luck pursuing this new adventure, it defintely sounds interesting.
Miguel.
Anyone else but me notice that he misspelled "initialize" as the constructor in his classes? Not exactly a good move when you're trying to earn respect to replace a tried-and-true stable windowing system.
Tell her to save her files before she starts, & tell her to never use, "Save As". When she saves a document for a 1st time, tell her to call you before she clicks okay. This way, you should be able to find it for her each time. I'm sure that she might find a way to confuse you, but I speculate that it'll be less often.
I hope that helps.
PS. I'm sorry to see that your comment got modded down. I wish that comments such as yours got modded up & locked so that they can't be modded down again.
testing out my trending skills
If you want to read the tired, old arguments abouy X and diversity in toolkits, ten proceed down the page!
If you want to reinforce the idea that market-share==quality and viability, then we have a great story about Windows 2003, abit farther up the main page!
Know-nothings with less than 7-years implementing complex server systems are advised to comment in excruciating prose.
"Flyin' in just a sweet place,
Never been known to fail..."
How about "[Windows"? As in, "I'm running [Windows on my cell phone."
The COPYING file in the released code contains the GPL. There is a strong argument for saying it should be released under a BSD like license, as XFree86 is.
Now to see if it works...
Perl predates the web. Larry is no more employed by O'Reilly.
I cannot get enough of people telling me that kind of thing! My ego needs to be fed! Hehehe. Seriously, much obliged!
Which is more painful? Going to work or gouging your eye out with a spoon? Find out!
http://www.workorspoon.com
X is not slow and and it's not "clunky" by which I assume you mean visually ugly. X has never been slow and it will never be slow. I've got an old 66MHz i486 with 8MB RAM and it runs X just fine, much faster than MS Windows 95. On modern hardware, X runs blazingly fast and as fast as, or for well-written applications using XShm/Render, faster than Windows XP. Many applications for X are badly written and/or use a bloated widget library (nothing to do with X). Any clunkiness has nothing to do with X and everything to do with the particular applications you are using and the particular widget libraries they were linked against. X is a set of libraries and header files that implement the X11 protocol. X doesn't care whether you use beautiful or ugly widget libraries; that choice is given to the programmer.
The whole point of separating window management from X is to give you the freedom to choose which window manager to run. If you were to write the applications for X in the way you like them, you can make any environment you like that is as unified or disunified as you like. X gives you that freedom. It seems you have a Windows background, don't know much about X yet, and consequently have completely misunderstood the strengths and weaknesses of X.
Scroogle
The parent poster has correctly pointed out why none of the usual criticisms of X so often mentioned by other ignorant posters are valid. Please moderate his post as Insightful.
Scroogle
Why shag that ugly old hag?
I for one, welcome our new Y window system overlords.
in seriousness, this might be an up seeing as XFREE86 is running off of old code and old standards, it'd be nice to have a less troublesome window system.
...if you take the time to read the PDF file that is so kindly linked from the story. It just so happens to contain reasoning, problems solved, and it's features. As well as how it's going to tackle these problems. As for installation alongside X, I would assume you could. You have to type a command to start X (or put it in a script) and I would assume Y would be started in the same fashion. That would mean you would simply start one in place of the other.
It's an obvious name for an X successor, of course, but there is (well, was) a Y Windowing System in development by the Hungry Progammers
No, that's not celbration, that's Yet Another Y.
You know how many replacements for X called Y have been along?
Sheesh, maybe open source needs some marketroids to take over naming things.
Do you mean that X is efficient for flat-color rectangles but inefficient for pixmap-laden interfaces?
Yes, _OVER A NETWORK_(as he said...)! Transferring pixmaps over a network is always going to be as slow as the compression and network will allow. Hence, him using VNC as an example... This is meaningless on the local machine.
How is it different than GTK 1 and GTK 2? QT 1 and QT 2 and QT 3?
It's different because with X you can still have all those old widget libraries, which is not always the case when the widgets are built into the windowing system.
Show me a good way of pasting one selection over another selection under X without retyping.
X doesn't have a single copy/paste buffer. IIRC, X has 2. Most programs use both, one being used in the exact same fashion as Mac/Windows. In every application I use - Control+c/v - just like in Windows. For applications that don't support that? Well, I dunno, but they're mostly ancient, using old crusty widget sets, but at least they still run :)
Sticking feathers up your butt does not make you a chicken - Tyler Durden
I agree this young man's drive and determination, evident in his project, are admirable but I don't think that these positive attributes should be taken to mean he necessarily has the right approach. I'd expect anyone doing a project under supervision to have the capacity and willingness to absorb and to seek constructive criticism from others. Is this guy mature enough to have validated his approach by discussing with his peers and supervisors whether his particular solutions, and the problems he has tried to solve, are valid and appropriate? Unfortunately I think there are many serious criticisms of his project which he hasn't considered. For example, that part of his work dealing with color management is pointless because he hasn't solved a valid problem. X already has an excellent, though underappreciated, color management system based on the theory of color spaces, which he dismisses trivially, and without understanding his subject matter, merely by saying it's "overly complicated" [p.12] That's a fundamental flaw. If he had sought the opinions and criticisms of others knowledgeable in the topic, he would have been directed along much more productive paths than those he has followed. There are other examples of similarly misguided work based on his misapprehensions about the technical architecture of X but I don't have the time to discuss them further here.
Show me a good way of pasting one selection over another selection under X without retyping.
Well, you can't in most applications. However, show me a way to copy in windows without touching the keyboard or opening a menu. You can't.
Neither of these problems is really a big deal - paste-to-replace is instead done as 1. paste the new stuff 2. delete the old stuff, and in windows click-to-copy becomes opening a menu or using the Ctrl-C hotkey.
Personally, I LOVE being able to use only my mouse for copying and pasting. I really don't miss the replace option as much as I enjoy the X copy/paste semantics. They save me a lot of time.
microsoftword.mp3 - it doesn't care that they're not words...
I don't think there's anything stopping an X server from doing per-window alpha blending, by simply letting the client know that it is never obscured. I'm not sure why none of the servrers do this, and application-based fake blending (like rxvt, konsole, and others) just looks stupid.
As for lower-level aplha blending, it may require a new extension, which is one of the nicer facilities of the X protocol.. The X Render extension may be enough.
Well I didn't read the whole paper, but the first 5 minutes made me go.... you know this guy actually knows something, the next 5 minutes made me go, you know this guy actually knows a hell of a lot, and the next 5 minutes after that, I was convinved that it's not a bad system to replace X Window, with.
If people actually got behind this, poked around, wrote drivers so everything didn't have to go through SDL and the other things that it needs it could really work, admitidly it'd be a bit of a shift and many things done today would have to be built as modules to the windowing system, thinking particularly things like Evas *druel*, themes and so forth.
Bigest turn-on: You could connect to a machine, run a program and no matter what it was it'd look right on your machine, somone else running the same program on the same machine would have it look right on their desktop as well.
Bigest turn-off: The number of legacy X11 appications which would totally ignore the good features of the windowing system and fact it'd probably take 10 years to get to the stage where nvidia and ati would write accelerated drivers for it.
Now of course I am a beast of my enviorment, so I'll just mourn that I saw no mention of RISC OS and say jolly well done, I don't think my masters project will be anything close to this impressive.
You forgot the 10% of posts telling you things you forgot :)
That's the great thing about standards, there are so many to choose from.
-Andrew Tanenbaum
Begun, this browser war has.
The paper is rather decent, but all it really describes is a rather simple design for a GUI framework, of the kind that has been designed and implemented dozens of times over in the last 20 years.
It would take dozens of man-years of development to turn the implementation described into anything that would be competitive with X11. At this point, all that it is is a polemic for a simple high-level GUI protocol. There's no graphics model other than rectangles, blitting and line drawing, there's no font management API to speak of, no affine transforms, no splines, no region fills.. and what about a unified imaging model for on-screen displays and printing? Cut and paste/drag and drop? What about sound and multimedia? Event synchronization? Surely you'd want to link those into a new GUI standard. The paper properly points out the need to develop a security infrastructure.. how about a way to deal with the widget resources of a terminated client? Is there a distributed garbage collector in the system?
It's those kind of precise detail-oriented issues that are the real challenge in developing a user interface/presentation system. Sketching out a basic object communications model that puts responsibility for refresh into server-side data structures is nice, but it is such a tiny part of the problem at hand.
Don't get me wrong, I give the author high marks for a nice bit of work for a school project, particularly given that he actually implemented the thing. It's just not of a level of detail, functionality, or novelty to deserve to be brought up on Slashdot as 'Y: A Successor to the X Window System'.
At least, not yet. If the author is able to collect a rag-tag band of coding warriors to his banner, he might well make a significant contribution with Y in three or four years. There wasn't anything particularly special about Linux in the beginning either, until Linus gathered his tribe and showed the quality of his leadership. But remember, Linus was trying to support the execution of legacy code, not to rip and replace all of it. The author of this work is setting himself up for a much harder and lonelier task.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Already exists.
Why Y?
correct me if I am wrong - are'nt you one of the co-authors of the Y-Windows specification? Just curious...
I'm with you 99%.
I was surprised but believed his analysis of the impossibility of using C++ as the basic language, but maybe BeOS was like Y, really C with a C++ api.
Actually I was also thinking that I would not like to have the miniscule memory on my laptop being chewed up by buffers but..
If a new integrated windowing system is being designed though I wonder what other things could be done at the same time. For example, could a module be added to Y which subscribed to all events, listened to all data, and was able to index and learn about your activities. It would seem that an object oriented windowing system would be a big ally in this. Also, if a system providing live queries like on the BeOS was implemented, it could answer queries based on the content of open applications, not just static files. Of course I seem to remember IRIX would let you browse windows as files too..
That most geeks say "Lets create yet another crappily designed one!" or "Lets DESIGN yet another one!" Difference being, one wants to work, but doesn't have a well thought out plan. The other has a good plan, but doesn't want to do work. This guy has thought it out, discussed it with people, and has started work on it. That's the makings of something decent. Plus it got on slashdot, so it's got a good head start :)
Mr Stallman, is that you?
Then color me ignorant, I have called it XWindows many times. I have been using it on Linux since sometime in '99, unless you count the Sun terminals, then it would be since, oh, '93.
Now if you were to have politely said "technically it is really called X or The X Window System" and left it at that, then you may have some credibility. But instead you come off like some pompous ass, trying to impress the Slashdot masses with your carefully crafted insults. I couldn't help picturing the Comic Book Guy when reading your comments. Get over yourself, and your wishful 'superior intellect'. I can't wait until your kind is essentially extinct, relegated to some far-off IRC channel where you can impress each other with your 'witty banter' and insults of the 'lesser life forms'.
My beliefs do not require that you agree with them.
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. Some people look at what X is designed to do, whilst others look at what is needed for the role in which X is used today.
John_Chalisque
It was a grad students MS thesis project in 1985. It was the graphics part of a distributed Unix system called W. MIT was looking for a starting point for it in-house system and used W & X.
There's already an X-replacement out there. It's called Fresco (www.fresco.org). Check it out.
'He who has to break a thing to find out what it is, has left the path of wisdom.' -- Gandalf to Saruman
I doubt he could review RISC OS properly (access being the problem), and sticking in hearsay from other's descriptions would be bad.
John_Chalisque
The rest of your comment was pure ad hominem. Credibility is about the facts, not popularity. No amount of politeness could make the previous poster's statement more valid, especially since it's already demonstrably right.
Jon,
You said, "There wasn't anything particularly special about Linux in the beginning either, until Linus gathered his tribe and showed the quality of his leadership."
That, to me, is the most important thing you said. I realize I took it out of context.
Maybe the beginning of a new X Windows is humble, but at least, like Linux was years ago, it is a beginning.
I'm not qualified to judge all issues surrounding X Windows. However, it has become clear to me that it must be re-written. Linux should have a GUI system as excellent as that of Apple's OS X.
I consider this a priority project. Governments and industry should pay for it, and it should be done professionally as soon a possible. The whole issue of making GUI-based programs is at present a mess.
The social problem appears to be that programmers are not good at loving themselves. They make do with very little sometimes. Programmers should band together and make sure the fundamental tools are available.
It is completely unacceptable that a government would use proprietary products that may do hidden things.
Michael
Whatever you guys may say that this project is no good anyway the way X now performs with all theese toolkits is awful. The one that wants to make it cyrillic (users from Russia, Ukraine etc) will have to turn himself into a cool hacker making all this understand and use cyrillic. There must not be any Cyrillization-Howto, just one click, just one line in config. That's the very big obstacle for X winning users there. There should be a real desktop for real users, and not just english-speaking, fast, consistent, user-friendly, easy to setup, one. That all X misses. Something have to replace it. And this project seems to be capable. Good start.
I was getting this strange error:
...) do { syslog (LOG_INFO, "%s:%d: " str "\n", __FUNCTION__, __LINE__, ##__VA_ARGS__ ); } while (0)
...) do { syslog (LOG_INFO, "%s:%d: " str "\n", __FUNCTION__, __LINE__ , ##__VA_ARGS__ ); } while (0)
buffer/painter.c: In function `painterRestoreState':
buffer/painter.c:63: parse error before `)'
There was nothing wrong with the syntax in the code so I did some digging around and found out that this line from Y/util/log.h is incorrect:
#define Y_TRACE(str,
Well, okay.. what's wrong with it?
It should be this:
#define Y_TRACE(str,
A page on developers.apple.com about Variadic Macros helped me find the solution.
Previous versions of CPP implemented the comma-deletion extension much more generally. We have restricted it in this release to minimize the differences from C99. To get the same effect with both this and previous versions of GCC, the token preceding the special ## must be a comma, and there must be white space between that comma and whatever comes immediately before it:
So if you change all those lines in Y/util/log.h to the correct format, you should be able to compile it. (Some things are still broken for me though and I'm looking into it.)
There needs to be a place to discuss this project I think.
I'm learning Xlib at the moment. I've learned to write my code to respond to expose events by redrawing the window.
However, the server automatically draws the exposed area with the background pixel value or pixmap. Pixmaps are drawables. So, presumably I can draw on the background pixmap, thus shifting the entire refresh burden to the server.
I understand what stopped programmers doing this in 1990, the server would run out of memory to store the pixmaps; but what stops me doing it this way in 2003, when RAM is $200 per Gigabyte?
Unfortunately for an X-Y bridge to be built, the toolkit used for X would have to be imported into Y, and kind of defeat the purpose of Y having a standardized toolkit, since developers would then be able to use the same toolkit they were using before and have the program then work for both X and Y. It is the best way to get people to think about switching to Y, but it isn't the best way to keep Y with one standardized toolkit.