It's just a huge step backward. You give up network transparency and make lots of applications incompatible without gaining a thing! You might gain a tiny speedup, probably not even that. Most time is spend in the toolkit anyway, you are obviously not cutting out that part.
Of course PicoGUI, Fresco and others suffer from lacking applications. They are for most part in alpha stage! But with a bit of work you can
port applications over. Lots of work for one application at a time. But then you get the optimum out of your shiny new systems.
port toolkits over. Then you get most apps build on that toolkit while staying on a high level of abstraction, thus using feature like device independence.
port xlib over. You get all the X apps. Of course you go down to a very low level and sacrifice most benefits of the new systems.
run a Xserver in a window and use that to display your apps. Ugly, but very easy to do (and in fact done in Fresco allready).
So you keep the revolution and the applications;-)
Did you ever bother to read up on the projects mentioned in this thread? We are not talking about some X-without-networking here (like what you were calling a evolution)!
I disagree: They use OpenGL or some Toolkit to run their stuff on. X is just underneath somewhere because most cards come only with XFree86 drivers.
OpenGL is not too well supported either: You can have one window with acceleration. So a GUI research project build on OpenGL does basically assume that it has control of a complete environment via OpenGL. It just happens that this environment is a window in X...
Drivers for input devices like data gloves go around X completly, opening some devices in/dev directly. Great for cross plattform development:-(
Of course you can 'fill in the gaps'. You can enhance a bicycle and turn it into a truck if you put enough work into it! But why would you want to drag along lots of code you are not going to use in your project?
What gave you the impression anyone is trying to reduce the flexibility? Just because a user can pick his prefered 'Widgetset' and not the application developer? To me that's more flexibility... and you get a very much reduced bandwidth for free on top of that.
I agree with you that X is a solid system. It's network transparency was way ahead of its times (and still is). Nobody is arguing that X sucks here! X got its place on a Unix Syatem and it will keep that place for a while longer.
That's not the point. The point is that somebody needs to do some research on how to improve things. We don't want to copy Windows and to a lesser extend MacOS X only, do we? So we cannot just say X was fine for years now, let's just add things onto it and hope that it won't break. Have you ever seen the new Apple GUI? The eye candy allone that can be done with it makes it worth to investigate it once. Guess what: It's not based on the notion of pushing pixels around like X is: It uses OpenGL underneath.
X was developed nearly two decades ago. That it is still around and widely used shows the genius of those that developed it. But at that time there was no hardware that could do much more then setting individual pixels. Nowadays we got those niffty 3D accelerator boards: Wouldn't it be nice to use that power outside of games for once? X can't do that.
Then there are high resolution displays getting developed. Supporting those with a purely framebuffer-based solution will suck. Just think about the bandwidth you will need between your graphicscard and your 20" 300dpi monitor! X cannot support that: It needs a framebuffer and cannot use some vectorbased protocol to talk to your monitor.
Think about input devices: X supports 5 button mice and a keyboard. It does not support a wheel mouse (the wheel is mapped to button4 and 5!), it does not decently support graphic tablets, nor more sophisticated input devices like data gloves.
Think about those 3D display systems that regularly make it to the fontpage here. There's just no way you can properly use those with X.
Fresco on the other hand is developed with all that in mind. So projects like it (there are more then Fresco and PicoGUI!) are of extrem importance to the community in my oppinion. Even if they all fail: The code will be there, others can pick it up and lump it into X13 or whatever.
I'm following your suggestion! I'm replacing the part of the X-Server I don't like with my own 'Implementation': The protocol. We needed a new name for that and came up with Fresco. Other people have done the same and used names like GNUstep (although they are merging their code back into X), PicoGUI, OpenBeOS, 3dwm, to name just a selected few.
Since all of these are very much different from X. Some of the projects mentioned go way beyond anything proprietary GUIs can do today! So if we are reinventing wheels, at least we are improving allong the way.
Regards, Tobias
Re:Why I love X and will defend it to the death...
on
picoGUI: An X Alternative?
·
· Score: 4, Informative
Yes, we all like X. But since Fresco was mentioned allrteady I'll step in on its behalf here. I knoe PicoGUI a bit and both projects are somewhat similar from the ideas behind it all (allthough with a very different implementation and emphasis:-)
With Fresco you get network transparency. We use CORBA to develop Fresco, so that's a free bonux. I know all those CORBA is bloated, jadajada, arguments, but I am confinced they do not apply to Fresco: We knew from the very beginning we will use CORBA and have taken its strength and weaknesses into account designing the overall system.
Anyway: Fresco is network transparent and it uses way less bandwidth then X. The protocol is so much more high level! The small demo we got only uses 1.9kBit/s to hold the connection with the remote server. I don't know any numbers for X, but VNC needs 800kBit/s when used to 'forward' the Fresco server to another computer via its protocol. It was using the same demo but with less then half the screensize the original server ran at. Not that the screensize does matter with Fresco. Of course I did the same things with the window (moved, rotated, shaded it, opened subwindows, etc.) using VNC to forward the display and running the Fresco server locally and having the client connect from the remote maschine.
Fresco allows for different 'WindowManagers' (of course we call them 'DesktopKit'). Those are loaded into the server and are not normal clients like in X, that's the basic difference.
You got a good point wrt. the decades of testing. Obviously neither PicoGUI nor Fresco can give you that. But then there's less testing needed: The servers have much less code. All the graphic-card handling stuff is separated out into libraries like SDL, GGI or whatever. Those have been thouroghly tested for a while now, makeing that critical component rather relyable.
Hardware support is not as bad as you imagine. Since neither PicoGUI nor Fresco (nor any other project in a sane mind) is writting graphic drivers themselves! There are excellent libraries, kernel modules, etc. around to do that. If there are only X-drivers, then you can still run on X-windows (it spoils the purpose of replacing X, I know:-) till one of the farious 'rip the drivers out of X'-projects is successful. There are several of those arround even now.
Finally you use the if it works, don't fix it argument. I like that, but obviously X does not work or there wouldn't be so many X-extensions getting actively developed. As I see it, you can either extend X (to Y or whatever you want to call it) or work on something new like PicoGUI or Fresco or some other project. In both cases you end up with a system where applications developed for it will not run legacy X-Systems (without considerable efford of the Programmer/Toolkit writer). Once you use an extension your application breaks for X-without-said-extension. So baiscally you end up with a system not 'forwardward' compatible with vanilla X, independent of wether you extend X or write something new. X-with-extension is of course backward compatible, but a compatibility layer can be added to another system later if need be. That's a lot of work, agreed, but the very simple case of just letting a X-server run in a window was allready demonstrated in Fresco.
I used to have a soft spot for its simple 'UI' and powerful feature set. I still use it occasionally (whenever there is no 'real' editor around or emacs just takes too long to start up). I can use vi, I just don't want to do so anymore:-)
I really like the book "The Humane Interface" from Jef RAskin.
I found it on amazon where one reader stated that "Once you read this book you will know why you have the programs you hate." He is right... I absolutly loath vi now (not that emacs is that much better of going after Raskin;-).
Please put the CD image somewhere when you have created it and post a link here. I'm very much interessted in taking a glance at whatever you are going to collect and would love to give it a try.
There are tons of 'X replacements' out there. Usually they are just an X without network transparency, whiich I find very poor indeed. Network transparency is the onyl thing that really rocks in X. And with all those mobile devices popping up left and right I think it will become even more important in the future.
What alternatives are there? Nothing that's really useable yet:-) For a list I compiled recently check the other GUI projects section at Fresco. Of course you might want to check out Fresco, too. It's device independent, vector based and features even more buzzwords;-) We need more developers to get this really rolling... but the architecture is capable of doing all the nifty things MacOS X does, even some more:-) Dunno wether Fresco 'meets the need of the home user', but is that really what you want? A downsized version of a real UI environment?
Obviously you are american (== speak only one language that sounds vaguely like english):-)
Try learning another language well, you will discover that languages are not interchangeable. Some things just can not get expressed in english (or french or german). It's just like programming languages: Some are better for the task at hand then others. So if everybody just spoke english we would use a whole lot of nuances, even complete ways of think! That would make the world a poorer place, maybe not for you, but to the rest of us that got a bit of education while we grew up;-)
Microsoft did something like that. It was called Bob and turned out to be the biggest flop MS ever made! From what I read about it carrying the desktop metaphor too far actually hampers the useablility and does not improve it. You can interact with your desktop in way much diffrent (like grabbing folders, turning pages, punching numbers into your phone) from the ways you interact with your computer (keyboard and mouse). Sticking the real world into a computer without offering the options to interact that the real world offers is in general not the best idea:-)
From your message I assume you to be a gnome devleoper. I can understand that you get upset with so many critique raining down on you (be it justified or not). But this is not going to help your project: Just listen to the complaints, note what people think and try to learn what your users want. Most people are not developer material, but they can be very valuable assets to the developing work by providing feedback.
Positive feedback is nice for the ego, but it does not make your project better.
You are invited to join the Berlin (soon to become Fresco) project at http://www.fresco.org/. We are going very slowly these days, but we are trying to do something new. We can do all (even more) then MacOS X can with our architecture. Of course lots of stuff is missing. We are not ready for even the most adventurous of users, but we could definitly need some developers.
[...] if they want to steal some cars along the way, let them!
When the definite version is released and the cars don't get returned then, only then you have a (maybe minor, because it's the company's own decision to follow the law or not) reason to complain. [...]
s/cars/source code/
Wake up! Not releasing software linked against GPLed code is illeagal just as it's illegal to steal cars.
You *MUST* release under the GPL if you have linked in any GPLed code. You have no choice in that decision. You can chose not to use GPLed software in the first place, but it you have decided to actually do so, then you must release under the GPL.
Looks like Lindows is linked against GPLed software, or the FSF wouldn't have filled a complaint. That lindows-CEO-guy in the interview does not argue against that, so the FSF is most propapby right;-)
If they did then they are in legal trouble. Too bad for them. They had the license terms in their hands when they started out, if they did not read them carefully (maybe even getting advice from some lawyers) then it's their fault, not the fault of the community.
Bitching about the community being mean to all those poor linux-based companies is just stupid!
Is it only me or does Gordon think that suppoort is holding the users hand during the installation?
Support is adapting the software to the needs of a user (company). So writting a new module to connect to some proprietary server is 'Support', rearranging the whole UI is 'Support'. All this is completly independent of the userfriendlyness of a piece of software.
Well, if he want's to use something else but the GPL, in god's name, let him do so! As long as he does not use GPLed code in his products and thus plays according to the GPL rules...
Hey, you can allways give ask some developer to do changes for you if you have the source. So I really think the GPL is meaningful to endusers. Even if it's only because they are allowed to share the software with their friends:-)
> Personally though I think everything should be > on the client side. The reason is that any > interface to widgets will freeze us into > present-day design. You can think the Berlin > interface is really cool and customizable, but > it probably locks in ideas like "scrollbar" > and "text editing field" and "menu" that may be > considered archaic in 10 years.
A very good point!
We try to address this by minimizing the assumptions for widgets. A Berlin client can request a button and he will get something that executes a client-specified command on a certain event and that incorporates a given graphic soemhow.
The current implementation of the WidgetKit produces a tree of objects that form a motifish looking button (all straight lines, very easy to implement, but ugly) that is drawn 'around' a given graphic (usually a textlabel), reacting to mouseclicks (better: mouse releases).
Of course you could do a diffrent implementation of the WidgetKit interface, using a completly diffrent look (lets say MacOSX-ish or a texture-mapped 3D Mesh) and feel (voice controlled?).
'Minimizing' the assumptions made about Widgets, or better the interface for requesting them, is a very central task in designing Berlin. We think that this very general approach can at least handle anything from a athena-widget-button to those themable button we fancy so much nowadays.
You might want to take a look at Berlin (http://www.berlin-consortium.org/). We don't have a windowmanager (nor toolkits for that matter;-).
(Allmost) everything is a graphic that gets generated in the server. So it does not need to talk to clients at all when redrawing, greatly reducing communications between client and server. Of course the whole thing is multithreaded.
Since most graphics are generated by the server there is consistency: You exchange the 'DesktopKit' and all windows change their look and feel. At the same time you can have inovation: Berlin is fully device independent (able to render to a framebuffer, openGL or Postscript, allways making full use of the devices), it is fully 3D capable (allowing for 3D monitors and 3D objects outside of windows, even windows are 3D objects), can handle powerful input devices (like datagloves, etc.) and much more.
The downside: It still needs a lot of work. You are welcome to help:-)
Slashdot Mirror
It's just a huge step backward. You give up network transparency and make lots of applications incompatible without gaining a thing! You might gain a tiny speedup, probably not even that. Most time is spend in the toolkit anyway, you are obviously not cutting out that part.
Of course PicoGUI, Fresco and others suffer from lacking applications. They are for most part in alpha stage! But with a bit of work you can
So you keep the revolution and the applications;-)
Did you ever bother to read up on the projects mentioned in this thread? We are not talking about some X-without-networking here (like what you were calling a evolution)!
Regards, Tobias
OpenGL is not too well supported either: You can have one window with acceleration. So a GUI research project build on OpenGL does basically assume that it has control of a complete environment via OpenGL. It just happens that this environment is a window in X...
Drivers for input devices like data gloves go around X completly, opening some devices in
Of course you can 'fill in the gaps'. You can enhance a bicycle and turn it into a truck if you put enough work into it! But why would you want to drag along lots of code you are not going to use in your project?
Regards, Tobias
Regards, Tobias
Regards, Tobias
That's not the point. The point is that somebody needs to do some research on how to improve things. We don't want to copy Windows and to a lesser extend MacOS X only, do we? So we cannot just say X was fine for years now, let's just add things onto it and hope that it won't break. Have you ever seen the new Apple GUI? The eye candy allone that can be done with it makes it worth to investigate it once. Guess what: It's not based on the notion of pushing pixels around like X is: It uses OpenGL underneath.
X was developed nearly two decades ago. That it is still around and widely used shows the genius of those that developed it. But at that time there was no hardware that could do much more then setting individual pixels. Nowadays we got those niffty 3D accelerator boards: Wouldn't it be nice to use that power outside of games for once? X can't do that.
Then there are high resolution displays getting developed. Supporting those with a purely framebuffer-based solution will suck. Just think about the bandwidth you will need between your graphicscard and your 20" 300dpi monitor! X cannot support that: It needs a framebuffer and cannot use some vectorbased protocol to talk to your monitor.
Think about input devices: X supports 5 button mice and a keyboard. It does not support a wheel mouse (the wheel is mapped to button4 and 5!), it does not decently support graphic tablets, nor more sophisticated input devices like data gloves.
Think about those 3D display systems that regularly make it to the fontpage here. There's just no way you can properly use those with X.
Fresco on the other hand is developed with all that in mind. So projects like it (there are more then Fresco and PicoGUI!) are of extrem importance to the community in my oppinion. Even if they all fail: The code will be there, others can pick it up and lump it into X13 or whatever.
Regards, Tobias
Since all of these are very much different from X. Some of the projects mentioned go way beyond anything proprietary GUIs can do today! So if we are reinventing wheels, at least we are improving allong the way.
Regards, Tobias
With Fresco you get network transparency. We use CORBA to develop Fresco, so that's a free bonux. I know all those CORBA is bloated, jadajada, arguments, but I am confinced they do not apply to Fresco: We knew from the very beginning we will use CORBA and have taken its strength and weaknesses into account designing the overall system.
Anyway: Fresco is network transparent and it uses way less bandwidth then X. The protocol is so much more high level! The small demo we got only uses 1.9kBit/s to hold the connection with the remote server. I don't know any numbers for X, but VNC needs 800kBit/s when used to 'forward' the Fresco server to another computer via its protocol. It was using the same demo but with less then half the screensize the original server ran at. Not that the screensize does matter with Fresco. Of course I did the same things with the window (moved, rotated, shaded it, opened subwindows, etc.) using VNC to forward the display and running the Fresco server locally and having the client connect from the remote maschine.
Fresco allows for different 'WindowManagers' (of course we call them 'DesktopKit'). Those are loaded into the server and are not normal clients like in X, that's the basic difference.
You got a good point wrt. the decades of testing. Obviously neither PicoGUI nor Fresco can give you that. But then there's less testing needed: The servers have much less code. All the graphic-card handling stuff is separated out into libraries like SDL, GGI or whatever. Those have been thouroghly tested for a while now, makeing that critical component rather relyable.
Hardware support is not as bad as you imagine. Since neither PicoGUI nor Fresco (nor any other project in a sane mind) is writting graphic drivers themselves! There are excellent libraries, kernel modules, etc. around to do that. If there are only X-drivers, then you can still run on X-windows (it spoils the purpose of replacing X, I know:-) till one of the farious 'rip the drivers out of X'-projects is successful. There are several of those arround even now.
Finally you use the if it works, don't fix it argument. I like that, but obviously X does not work or there wouldn't be so many X-extensions getting actively developed. As I see it, you can either extend X (to Y or whatever you want to call it) or work on something new like PicoGUI or Fresco or some other project. In both cases you end up with a system where applications developed for it will not run legacy X-Systems (without considerable efford of the Programmer/Toolkit writer). Once you use an extension your application breaks for X-without-said-extension. So baiscally you end up with a system not 'forwardward' compatible with vanilla X, independent of wether you extend X or write something new. X-with-extension is of course backward compatible, but a compatibility layer can be added to another system later if need be. That's a lot of work, agreed, but the very simple case of just letting a X-server run in a window was allready demonstrated in Fresco.
Regards, Tobias
Some URLs you might find interessting: the Fresco Homepage, a short comparison of Fresco and X (the server is slow, please bear with it), finally a page listing among other things Other GUI Projects I found to be interesting for various reasons (both dead and alive;-).
... but this book is a excellent documentation for Fresco (formerly known as Berlin).
Sorry, coudln't resist, feel free to mod me down.
Regards,
Tobias
By the way: There is a project trying to realize the ideas of Raskin on SourceForge: look here.
It is for macintoshs only IIRC.
Read the book and you will see:-)
I used to have a soft spot for its simple 'UI' and powerful feature set. I still use it occasionally (whenever there is no 'real' editor around or emacs just takes too long to start up). I can use vi, I just don't want to do so anymore:-)
I really like the book "The Humane Interface" from Jef RAskin.
I found it on amazon where one reader stated that "Once you read this book you will know why you have the programs you hate." He is right... I absolutly loath vi now (not that emacs is that much better of going after Raskin;-).
Please put the CD image somewhere when you have created it and post a link here. I'm very much interessted in taking a glance at whatever you are going to collect and would love to give it a try.
There are tons of 'X replacements' out there. Usually they are just an X without network transparency, whiich I find very poor indeed. Network transparency is the onyl thing that really rocks in X. And with all those mobile devices popping up left and right I think it will become even more important in the future.
What alternatives are there? Nothing that's really useable yet:-) For a list I compiled recently check the other GUI projects section at Fresco. Of course you might want to check out Fresco, too. It's device independent, vector based and features even more buzzwords;-) We need more developers to get this really rolling... but the architecture is capable of doing all the nifty things MacOS X does, even some more:-) Dunno wether Fresco 'meets the need of the home user', but is that really what you want? A downsized version of a real UI environment?
Regards,
Tobias
Obviously you are american (== speak only one language that sounds vaguely like english) :-)
Try learning another language well, you will discover that languages are not interchangeable. Some things just can not get expressed in english (or french or german). It's just like programming languages: Some are better for the task at hand then others. So if everybody just spoke english we would use a whole lot of nuances, even complete ways of think! That would make the world a poorer place, maybe not for you, but to the rest of us that got a bit of education while we grew up;-)
Regards,
Tobias
Microsoft did something like that. It was called Bob and turned out to be the biggest flop MS ever made! From what I read about it carrying the desktop metaphor too far actually hampers the useablility and does not improve it. You can interact with your desktop in way much diffrent (like grabbing folders, turning pages, punching numbers into your phone) from the ways you interact with your computer (keyboard and mouse). Sticking the real world into a computer without offering the options to interact that the real world offers is in general not the best idea:-)
From your message I assume you to be a gnome devleoper. I can understand that you get upset with so many critique raining down on you (be it justified or not). But this is not going to help your project: Just listen to the complaints, note what people think and try to learn what your users want. Most people are not developer material, but they can be very valuable assets to the developing work by providing feedback.
Positive feedback is nice for the ego, but it does not make your project better.
Regards,
Tobias
You are invited to join the Berlin (soon to become Fresco) project at http://www.fresco.org/. We are going very slowly these days, but we are trying to do something new. We can do all (even more) then MacOS X can with our architecture. Of course lots of stuff is missing. We are not ready for even the most adventurous of users, but we could definitly need some developers.
Regards,
Tobias
[...] if they want to steal some cars along the way, let them!
When the definite version is released and the cars don't get returned then, only then you have a (maybe minor, because it's the company's own decision to follow the law or not) reason to complain. [...]
s/cars/source code/
Wake up! Not releasing software linked against GPLed code is illeagal just as it's illegal to steal cars.
WRONG!
You *MUST* release under the GPL if you have linked in any GPLed code. You have no choice in that decision. You can chose not to use GPLed software in the first place, but it you have decided to actually do so, then you must release under the GPL.
Looks like Lindows is linked against GPLed software, or the FSF wouldn't have filled a complaint. That lindows-CEO-guy in the interview does not argue against that, so the FSF is most propapby right;-)
If they did then they are in legal trouble. Too bad for them. They had the license terms in their hands when they started out, if they did not read them carefully (maybe even getting advice from some lawyers) then it's their fault, not the fault of the community.
Bitching about the community being mean to all those poor linux-based companies is just stupid!
Is it only me or does Gordon think that suppoort is holding the users hand during the installation?
Support is adapting the software to the needs of a user (company). So writting a new module to connect to some proprietary server is 'Support', rearranging the whole UI is 'Support'. All this is completly independent of the userfriendlyness of a piece of software.
Well, if he want's to use something else but the GPL, in god's name, let him do so! As long as he does not use GPLed code in his products and thus plays according to the GPL rules...
Hey, you can allways give ask some developer to do changes for you if you have the source. So I really think the GPL is meaningful to endusers. Even if it's only because they are allowed to share the software with their friends:-)
> Personally though I think everything should be
> on the client side. The reason is that any
> interface to widgets will freeze us into
> present-day design. You can think the Berlin
> interface is really cool and customizable, but
> it probably locks in ideas like "scrollbar"
> and "text editing field" and "menu" that may be
> considered archaic in 10 years.
A very good point!
We try to address this by minimizing the assumptions for widgets. A Berlin client can request a button and he will get something that executes a client-specified command on a certain event and that incorporates a given graphic soemhow.
The current implementation of the WidgetKit produces a tree of objects that form a motifish looking button (all straight lines, very easy to implement, but ugly) that is drawn 'around' a given graphic (usually a textlabel), reacting to mouseclicks (better: mouse releases).
Of course you could do a diffrent implementation of the WidgetKit interface, using a completly diffrent look (lets say MacOSX-ish or a texture-mapped 3D Mesh) and feel (voice controlled?).
'Minimizing' the assumptions made about Widgets, or better the interface for requesting them, is a very central task in designing Berlin. We think that this very general approach can at least handle anything from a athena-widget-button to those themable button we fancy so much nowadays.
You might want to take a look at Berlin (http://www.berlin-consortium.org/). We don't have a windowmanager (nor toolkits for that matter;-).
:-)
(Allmost) everything is a graphic that gets generated in the server. So it does not need to talk to clients at all when redrawing, greatly reducing communications between client and server. Of course the whole thing is multithreaded.
Since most graphics are generated by the server there is consistency: You exchange the 'DesktopKit' and all windows change their look and feel. At the same time you can have inovation: Berlin is fully device independent (able to render to a framebuffer, openGL or Postscript, allways making full use of the devices), it is fully 3D capable (allowing for 3D monitors and 3D objects outside of windows, even windows are 3D objects), can handle powerful input devices (like datagloves, etc.) and much more.
The downside: It still needs a lot of work. You are welcome to help
Regards,
Tobias