Berlin Project Lead Holds Forth 140
infodragon writes: "Here is a good interview with the project lead of Berlin. It is very informative and interesting, they talk about technologies such as gtk+, bonobo, corba ... If Berlin takes off it looks like X-Windows may have a competitor." That project head is Stefan Seefeld, and Seefeld gives good answers to questions like whether GNOME can or will be ported to Berlin, and how Berlin can hope to win converts from the millions of Xf86 users.
/.'ed (Score:1)
> Warning: Too many connections in functions.php on line 58
ok people - there goes my carma.
Lesson to learn: Never let frustrations be know under full name
Re:If Berlin ever takes off? (Score:2)
Unix hasn't had such mainstream acceptance as it does now. It might not have stood a chance ina purly corporate world, but now when Linux and everything that comes with it is Free it isn't such a harsh transition to give people a choice between X and something with a compatibility layer for X and GTK.
I think that one thing they could do to help themselves in make a mini widget set that is basic but uncomplicated for very simple creation of very simple GUIs.
Replacing Xfree!?! (Score:3)
Re:GUI Unification (Score:2)
--------
Genius dies of the same blow that destroys liberty.
Re:X *is* bad (Score:1)
So? What's your point? Be happy that you can at least run them on the same screen. If one were written for BeOS and the other for Berlin, you couldn't even do that.
Re:Don't start over, just help X (Score:1)
Consistency and Configurability are two different things. Without the former, the latter is meaningless.
Re:Don't start over, just help X (Score:1)
Good graphics cards have their own processor, and they introduce a bottleneck between the CPU and graphics memory: sharing memory between processors is difficult, expensive, and raises caching issues. Video memory is particularly bad because a real-time process needs to read the stuff out and a real-time processor needs to render stuff from it. If, at the same time, you have the Pentium messing around in that memory, it gets really tricky.
The only reason why PC hardware supports that model is because of the PC software architecture and the expectations of PC programmers. In the long run, Graphics systems on the PC need to become more like X11, not the other way around. Writing into frame buffers is not an efficient long-term proposition.
[X] sure as hell going to have to implement a "I know I'm running as both client as server, let me optimize" mode.
It did that, oh, 15 years ago: shared memory and UNIX domain sockets. I have never seen any benchmark that indicates that anything more is needed.
Re:Whether it runs on X or not this is what we nee (Score:2)
It just happens that you can run both of these at the same time, as well as various miscellaneous applications that have been developed outside any desktop environment. When you do this, it just happens that things are inconsistent.
While I'm quick to blame many things on X, this isn't X's fault. It's a shame that it took so very long for a layer ontop of X to be developed, but it was the (noble) intention of X that such layers be written.
The same is true many places. You can take a BSD kernel and make something that is quite different than your average *nix -- take, for instance, MacOS X. You can take a graphics display and make many interfaces. That's what partitioning and layers of abstraction are all about. Ultimately, I would expect that people will run largely homogenous desktops. I think that is appropriate. And when that happens, there will be consistency.
Re:Why we should keep X. (Score:2)
When you roll your mouse over a mozilla button, you're constantly sending "okay, I'm here, now over here, now over here, now over here..." messages to mozilla. If that's over the network, you get lagged pretty quickly.
Now, if the widgets had some autonomy, you'd be able to do some javascript-esque things like say "here's a widget for the server to display. On mouse_enter, switch to this image, and on exit, switch back to the original. If you get a click event, let me know when it's released."
Right now, moving the mouse generates far more traffic than it needs to.
--
I noticed
Re:Slow development (Score:1)
GTK has been ported to Windows, but that is a far cry from GNOME which is not a toolkit, but a desktop environment.
Re:Berlin missed the boat (Score:1)
X doesn't require pixel accurate drawing for everything, it requires it only for a well-defined set of its primitives. Other parts of the X protocol, including scalable fonts, 3D, and antialiased drawing, are not bound by that.
One could change that, of course, in say X12, but it would break all backward compatibility. Or at least you would have nice resizable applications alongside with ugly fixed size application.
If the whole world consisted of desktop applications, yes, picking g raphics model like that in DisplayPostscript, Berlin, or Quartz is simple and convenient. However, the whole world does not consist of desktop applications. You need pixel-accurate drawing for low-resolution screens, and you need display-specific bitmaps for efficient network transport. This was important 20 years ago on almost all machines, but it is still important in industrial and commercial applications.
Since X11 can already give you both, I don't see a problem. If you stick with a toolkit that is based on a desktop view of the world (Gtk+ and Qt both are, and both use scalable fonts and antialiasing), you get the applications you want. The fact that the same window system works with other stuff as well is an added bonus.
misconceptions... (Score:2)
First off - berlin isn't _tied_ to Python; Stefan just suggested using it as a simple prototyping tool - Berlin is language independent (everything happens thru Corba) In fact, the server part is mostly written in C++, but there's client apps in lots of languages.
And no; Berlin isn't just another widget set like some other poster suggested. It allows flexibility (so you won't lose your precious "choice"); but if you "theme" something, it happens on the server; _that's_ where policy is defined - in one central place, like it should be (don't get me started on what a bad idea "meta-theming" is - that just suggests a bad design i believe)...
Apps shouldn't have to bother with the gui, let it be done on the side where it's best done (the display server is closest to the hardware - so the work should be done there) Oh; and by the way: it _has_ anti-aliasing, and way more to boot (it's vector based)
Everyone's always moaning about whether or not innovation is possible with free software/open source; This is an excellent example of great innovation in my mind...
The sad thing is no-one seems to understand or care.
Re:There is no "boat" to miss (Score:1)
Yet, many open source projects do die, sometimes because they use old technology, sometimes because they are trying to solve a problem that is already well solved by other packages, sometimes because they aren't very well executed, etc. I'm merely predicting that Berlin will like fizzle out; you are welcome to make a different prediction.
Re:Don't start over, just help X (Score:1)
It's called The Direct Rendering Infrastructure.
http://dri.sourceforge.net
Ranessin
Re:Don't start over, just help X (Score:1)
Maybe so, but I'd rather have Mozilla a my 486SX/25 sitting on my kitchen table while I eat breakfast. With Mozilla actually running on a nice Athlon in the other room.
>because you can't optimize for the specific cases.
DGA or DRI ring a bell? Probably not. Try running a video game over a 10meg hub and maybe you'll appreciate how much optimisations are there on the local system.
>How fast do you think Direct3D would run over a network?
Um, it won't because it was designed under the assumption that hardlocking the accelerator(thus the system if you're lucky) is just an outb away.
GLX has no problem with it though. I've run Quake3 over a 100meg ethernet connection. It sucked just as much as running it locally. But that was just because the GLX/DRI driver for the i810 I was playing with sucked hard.
>but it's sure as hell going to have to implement a "I know I'm running as both client as server, let me optimize" mode.
See above.
Re:Don't start over, just help X (Score:1)
X has the potential to work in much the same way.
This means it also has the potential to be faster than a non-networked protocol, since the video card can do most of the processing without having to re-upload commands. Imagine how fast a window manager could be if you just put the borders into a GL display list!
Why we should keep X. (Score:3)
Anyway, all technical issues aside, X is an accepted standard that works across every UNIX platform, VMS, Windows, Mac, RiscOS, BeOS, Java, you name it. There is no practical reason to replace it; it does what it's supposed to do, and it does it well, and if there's something you don't like about it, it's extensible. IF for some bizarre reason it was felt that the protocol should be scrapped in favour of a new one, it should be X12, and it should be developed with the expertise and experience in the X crowd, not by random idiots who want alpha channels as a top priority! Furthermore, anyone who knows anything about the X protocol knows that it inherently supports a server supporting multiple versions of X simultaneously. So migration to X12 would be relatively simple, you would start with X servers and libraries supporting both X11 and X12 and move over. Whereas if some dumbasses decided to switch to Berlin we'd end up with fragmented, incompatible stuff and redundant work.
Bah.
If there's a code fork... (Score:2)
Re:GUI Unification (Score:2)
And which one would that be, may I ask you?
Sometimes effort is duplicated in the open source world. And sometimes that is a waste. On the other hand, diversity can also lead to quality.
There are two (actually even more) great desktop environments out there. Both are very good products/projects, so why standarize on either? As long as interoperability is good, choice is good.
Which brings me to the reason of my post: the Berlin lead talks about "gtk+, bonobo, corba". That sounds very, very scary:
Does that mean Berlin (if ever useable and ready) will be optimized for GNOME? Could KDE even run on it? (would've checked article for answers but the Slashdot effect is here again). Imagine GNOME ditched X11 for Berlin and KDE wouldn't work with it. Even more inconsistancy.
What's next, Qt/Embedded included in the kernel's framebuffer code? Perhaps DCOP and KParts as well?
I definitely agree that X11 is not perfect at all. And that a replacement might be a good thing on the long run. But please, if you are writing a replacement, don't include technologies which will force your users to one or the other desktop environment!
Re:If Berlin ever takes off? (Score:1)
Re:Berlin missed the boat (Score:1)
Aqua isn't a vector based GUI. It's all just pixmaps, albeit it alpha blended in places. The CoreGraphics layer underneath isn't vector based either, it just has some support for PDF.
-dair
Why X is a POS and needs to die. (Score:3)
Everytime X is mentioned, the UNIX grognards come out of the woodwork. All through the halls of
Compatibility: If I cared all that much about compatibility, I'd still be using Windows. 'Nuff said.
Network transparency: This is a half-decent point. However, Berlin does network transparency as well, so it is a moot point anyway. The truth is, other windowing systems do network transparency, and some better than X. If you don't believe me, read the docs on QNet and QNX's Photon. Whoa, somebody actualy DID come up with something better than X!
Maturity: I don't know how to explain this to the grognards. Let me put it this way. I love my grandparents. I want to learn from my grandparent's vast life-experience. However, there is no way in hell I'd be caught dead dressing like them. Even with a cap on backwards, a tweed coat is a tweed coat. The same thing holds true for software. 30 year old software, just like 30 year old people (no offense to those of you that far over the hill
Flexibility: Flexibility is over-rated. No, its true. X had to make some tough design decisions, and it chose to make things more flexibile rather than better. While a certain amount of flexibility is necessary, software should be designed with two goals in mind: Providing the absolute best experience for the next ten years (a generation in software-time) and providing some sort of migration path to the next level. While X, due to its flexible nature, has survived the last decade and a half, it is not, in its current form, able to keep up with its younger competitors.
Will it be *FASTER*? (Score:1)
Windows 98 on a P-200 with the cheapest-ass graphics card you can buy provides a slicker GUI than XFree86 on a P3-500 with a Voodoo 3.
X might be network-aware, but when its unusable over a slower connection than 10Mbps ethernet, who cares? Most people still use 56k modems for remote connectivity, and X is laughably useless in this scenario.
For remote access, Windows Terminal Server/Citrix Metaframe absolutely beats the pants off anything X-based.
As a foundation for a modern desktop computing environment, X is simply inadequate. No clipboard, no drag and drop, slow rendering, terrible font support, bad network performance - The only thing X does well is deny that support for (insert useful feature here) belongs in X at all.
I run Linux/X both at home and at work, mainly because i much prefer programming on *NIX, and in my opinion, X should be replaced with something that meets the needs of power users of the 21st century, not the needs of university professors of the 70s.
Re:Berlin missed the boat (Score:3)
-----
"People who bite the hand that feeds them usually lick the boot that kicks them"
Re:Berlin missed the boat (Score:1)
DisplayPostscript and Swing, for example.
Many X11 toolkits provide rescalable primitives if you want to use them. However, it is generally not correct to use vector scaling for changing window or widget sizes (e.g., displaying a font at 12pt and at 24pt is not just scaling).
Re:GUI Unification (Score:2)
Also, configuration files should be in a standard place and there should be more of a common standard for them (at least for basic functions) so that applications can more easily install, manipulate, and configure whatever desktop they are on. You want to add "EXTRA" functionality on YOUR desktop implimentation. Again. Fine. Thats what application specific config files might be for. But there should be a more uniform set of standards so that when Joe Six-pack unloads his new, state-of-the-art, machine, and turns it on (after his son sets it up). He is presented with something that is similar to what his last machine was like (his son just customized his personal home directory, he didn't change dad's).
Do standards change? Heck yeah.
Your right, the user should decide what erratic behavior they want, but some modicum of backward compatibility should be possible too. (not for every feature, but for most of the new 'wiz bang' ones). By the same token, they should start off with a common setup and work from there.
if Berlin takes off ... (Score:1)
Good argument, (Score:1)
Re:Don't start over, just help X (Score:2)
Re:X *is* bad (Score:2)
Person 1: "Well, if one were written for Windows and the other for Quarz, you couldn't even run them on the same screen!"
Person 2: Duh. What's your point?
Person 1: See, that was clever! I'm clever! I came up with a clever and comprehensible comment!
Person 2: Right...
Now, I'll explain my point. My point is that the first party (you) reccomended to the second party (me), that if the second party wanted consistancy on their desktop, then they should only use apps from one toolkit. This the second party pointed out to the first party that two of the best apps on Linux were written for different toolkits, and thus the second party was forced to exchange RAM and consistancy (consistancy is VERY precious to the second party, as anyone whose seen his directory structure can attest to) and application quality. The first party then made a snide comment about BeOS, and told the first party to use both toolkits, thus creating a paradox with the first party's original statement, and the first party was immediatly sucked into the abyss of non-sensicalness.
Re:Berlin missed the boat (Score:1)
Some support for pdf? It's completely based on pdf. That's why it's vector-based and why it's so evolutoniary.
-----
"People who bite the hand that feeds them usually lick the boot that kicks them"
Re:Don't start over, just help X (Score:2)
The common case today is that X applications are optimized for the local display server, through design and/or through the toolkits.
Re:Don't start over, just help X (Score:1)
It seamlessly allows local and remotely-running programs to work together on a display
This is even more true for Berlin. As I understand it, Berlin moves a lot of the simple GUI code for stuff like buttons to the server side. This is a big performance advantage for Berlin over networks. Compare the two, creating a button and it being pressed and released:
X: Client tells server how to draw the button as unpressed. Server tells client a mouse event occurred. Client tells server how to redraw the button as unpressed. Server tells client a mouse event occurred. Client tells server how to redraw the button as unpressed again.
Berlin: Client tells server to create button. Server tells client button was pressed.
Obviously, this is much more efficient. The more high-level widgets the server side has, the more this is true. There's not only less bandwidth used, but much less latency since the server and client don't chat back and forth a bunch of times when only one is necessary for the server to tell the client what is going on.
It is flexible enough to allow programs to fully determine how it is to behave on lots of things -- X does not force you into a specific widget set or window decoration method, window placement behaviour, or anything else
I'm not sure how Berlin stands on this. I believe a while ago they were considering some sort of virtual machine so the client could send new GUI controls to the server to be run. Obviously it would still be possible for the client to create its own buttons and such even if this is not true, but I don't know how much of that would then need to be moved to the client side (negating the advantage I just discussed).
In any case, I don't think this is as great a feature as you make it out to be. I like comformity. I want all my applications to look and act the same, so I don't get confused. With Berlin's design, I could replace the list box widget in all of them at once, since they share the server's implementation. With X's current situation, none of them will ever be the same, since none of the toolkits have anything in common more abstract than Xlib. There are advantages to diversity, but there's huge advantages to shared code as well.
It is flexible enough to have extensions to help with some things. Lately we have seen extensions to add Anti-Aliased fonts and to aid in 3D display and moving picture display.
I believe this is also true of Berlin. (That it can have extensions, not that these specific extensions have been added.)
Many of the old ``problems'' of X, such as no anti-aliased fonts and poor support for moving pictures and 3D, are being addressed within the existing framework of X. This is because X is great, it allows for this sort of advancement while still having compatability.
But existing applications don't take advantage of extensions. As Stefan noted in the article, "The new renderer is usable as an extension, i.e. both the server as well as the client have to be aware of it." So you can only fix these problems by dropping legacy support. If X had sufficiently abstracted font drawing in the first place, like Berlin intends to, anti-aliasing could have been introduced without rewriting client-side code.
If you want to make your windowing stuff faster, if it's X's fault you can almost always fix it.
Not really. The performance problems I just discussed take place because of something fundamental in X: the client tells the server exactly what to draw. The server doesn't have any knowledge of something even as basic as a button.
Please don't get rid of the good to go with the new.
Again, these problems in X are fundamental.
If you have a problem with X, fix it. Don't just whine.
I do believe that's what the Berlin people intend to do...
If Berlin ever takes off? (Score:2)
Re:Linux's GUI problems (Score:4)
Re:What Berlin needs to do (Score:1)
Berlin should only provide unnamed shaped "canvases" that belong to different clients, it should not provide any "buttons" or "menus" or "windows", but conversely you should be able to easily (ie with no setup before the drawing function) do full PostScript and OpenGL graphics into these, and anti-aliased fonts, full UTF-8 formatting of text, and high speed placing of images with arbitrary linear transformations from user memory onto the screen.
Did you read the article? Do you have any idea what Berlin is trying to accomplish? Berlin allows graphic primitives (the buttons, menus, and windows you mentioned and more) to be moved to the server side. This has several obvious advantages...one being that there's much less network traffic, since higher-level messages are being passed around. Likewise, much fewer context switches in the local case. None of this would be true if they did what you wanted, exporting only a canvas to the client.
Re:Slow development (Score:1)
CDA nonsense.. (Score:2)
Re:GUI Unification (Score:1)
Ditch X11 for what? Are there any viable alternatives to X11 that provide the features it has, provides significant additional featurer and is mature enough to replace X11?
Standardize on either KDE/QT or GTK/GNOME - I can see some advantage to doing this but without X11 underlying them either would have to be ported to your X replacement which is definitely a major effort. I can say that there would be a holy war to decide which to standardize on unlike any seen in the Linux world before.
Finally, a good human interface specification would be a huge benefit for the community, but who would approve it and how would it be enforced? Deciding who sits on your suggested board would be a big enough problem. How would you deal with an app that didn't meet the guidelines? How would you prevent a ditribution from including it? Maybe there could be a "100% LinuxGUI Compliant" label that could be applied but who would police the use of that?
Unfortunately I don't see it possible to enforce much of anything interms of Linux standard when any joe hack can start a project and no one can stop them from violating any standard out there eith deliberately of by accident. This is one of the advantages of a corporate development effort - if management has any guts it can require the developers to toe the standards line.
Re:GUI Unification (Score:1)
--
GUI Design (Score:1)
I'm glad that I'm not you!
Re:GUI Unification (Score:1)
The command line is a consistent interface.
No, it isn't. Type "setenv DISPLAY :0" into ksh, or "DISPLAY=:0; export DISPLAY" into sh. Or even "export DISPLAY=:0" into sh; only bash likes that, I think.
There are lots of choices for command interpreters, and there are lots of choices for graphical toolkits. The command interpreter is much easier to replace than the toolkit (the shell utilities aren't different, but the code using the toolkits is) but the parallelism is still there.
One question... (Score:2)
Re:"If they only opened Be" (song) (Score:2)
Re:Don't start over, just help X (Score:1)
A slight correction to what I said:
So you can only fix these problems by dropping legacy support.
Legacy applications would still run fine, but they would not take advantage of the new feature without being rewritten. In Berlin, they would automatically, since there more shared code.
Re:Whether it runs on X or not this is what we nee (Score:2)
Re:Don't start over, just help X (Score:2)
MDI isnt a function of X, but of the toolkit. Gnome supports MDI fine, and you can even chose which MDI model you prefer, and I think Qt does the same thing.
Re:Berlin missed the boat (Score:1)
I think perhaps you're misunderstanding what vector based means. It's not about auto-scaling pixmaps. It's about not having pixmaps at all. All your drawing primitives and much on-screen data are defined by equations. Resizing, translating, rotating are not about matrix multiplications and manipulations ala Gimp/PhotoShop. They're all perfect operations because the transformations are not being applied to a pixmap. No need for anti-aliasing, no need for bicubic interpolation, nearest neighbour or anything like that. I know I'm not even doing it justice, so I'll provide the link to a very informative article [arstechnica.com] about Aqua.
No toolkit will do that for you without expensive matrix transformations. I think if you check out the Berlin [berlin-consortium.org] webpage under the "Screenshots" section, you may see what I mean.
-----
"People who bite the hand that feeds them usually lick the boot that kicks them"
Re:Berlin missed the boat (Score:1)
-----
"People who bite the hand that feeds them usually lick the boot that kicks them"
Re:Slow development (Score:2)
1) emacs
2) xdvi/xdpf (they wouldn't be called that of course)
3) xterm
4) netscape (or the frankly superior Internet Explorer. I wish it weren't so, but t'is.)
Those are the only gui apps that I've used during the daylight hours for the last four odd years. Incidentally, they are also the apps that would benefit most from anti-aliasing (preferably sub-pixel).
The article didn't quite make it clear to me whether an X compatiblity layer would be possible, either at the developer level (recompile all apps) or the user level (just start the Xf86 server that hooks up with a running berlin server). Anyone want to chip in with an opinion?
Also, (somewhat OT): does anyone have a status update for Xrender in the newest Xfree86? I seem to recall a page promising sub-pixel anti-aliasing for my laptop, and I want it badly. That would make my emacs SOO easy to read.
The recent release was mum tho, so I'm sorta in the dark.
Re:Good argument, (Score:1)
After becoming accustomed to Windows one would not feel as home in Mac. So for you the interface failed.
Whether a pure and untouched user would pick up Mac faster than Windows or Berlin faster than Gnome is the point though.
Re:What Berlin needs to do (Score:2)
toolkits simple enough to be programmed by mere mortals will appear.Berlin should only provide unnamed shaped "canvases" that belong to different clients, it should not provide any "buttons" or "menus" or "windows."
>>>>>>>>>>
Have you gone mad? That's like X11! You are empowering the developer instead of the user. By keeping "buttons" and "menus" and "clients" on the server side, it makes it much easier for users to make apps conform to their preferences, not those of random application developers.
Re:Don't start over, just help X (Score:2)
A lot of the overhead has to do with (un)packing X requests gazillions of times, which, the author claims, also happens in the shm case.
--
Change is inevitable.
Re:GUI Unification (Score:1)
Not to fan old flames, but doesn't QT already have this capacity? TrollTech wanted to make some embedded qt apps and that was their rationalle. I just wish those Norwegians would get more evil and actually make a concerted effort of elbow out X windows. Wouldn't this be much quicker than waiting for Berlin to ripen?
The illusion of the intuitive interface (Score:1)
1. The fortune program of my Psion has this in its tiny database -
The only intuitive interface is the nipple. Everything else is learned
I tend to believe that. I hated Windows 95 when I moved from my familiar Windows 3.1 - because I had learned the interface. Similarly I hate the famously easy Mac OS interface when I occasionally use my friend's Mac - because it's not the Windows 95,98,NT interface I'm now used to. Give me a few days of constant use and I'm sure I'll be proficient with it.2. A successful linux UI will be one that will be designed as if the command line never existed
Maybe, maybe not. Such a UI would be well suited to a non-techie desktop user. To me the most successful linux UI IS the command line.
It always amazes me the way people talk about the GUI for linux. Linux is an open-source clone of unix.
Open-source means it is driven by the people who write it - so it's primarily a programmers OS. It also mean that it's pulled in different directions and that for every problem there's 5 different solutions (none of them finished!). There is no coherent design in linux as a whole because what we call linux (i.e. the distributions) are loose collections of a lot of different people's work. Linux is a pick-n-mix of OS, tools, GUI, applications.
And being Unix-like means its greatest strength is the power of the command-line. The power of the command line is the ability to combine many programs each of which do a single thing well. What Unix command line has over say DOS is the ability to script those combinations allowing more flexibility. I've yet to see these things done well in a GUI, where they've been attempted at all. Which is not to say that GUIs are bad - they just have different strengths.
My point is that linux origins and its development style tend to direct it away from being an end-user desktop OS. It tends towards being a server OS with a quirky but useable GUI.
wow I didn't realise how strongly I felt until I wrote this! Rant over.
Re:Don't start over, just help X (Score:3)
Exactly, when I read the part about Berlin enforcing MVC I knew that there was no way that Berlin was ever going to take off.
X is here today, it works, it is improving, and it allows you to write your application however you want (even if it is the wrong way to approach the problem). Besides, the biggest problem with X is the fact that it is too low level to really promote code reuse, but both KDE and Gnome are frantically at work trying to fix this. Honestly, what new GUIfied software being written today for Linux doesn't rely on either the KDE or Gnome libraries for much of the heavy lifting?
If Berlin + GGI would have been available when X was still crusty and before KDE and Gnome existed then possibly it might have generated a following, especially if it would have included a legacy X compatibility so that I could still run all my X applications (there is no way I am using a desktop that doesn't include Emacs).
As my grandmother always says, "If wishes were horses then beggars would ride." The reality is quite different.
The Berlin folks are welcome to prove me wrong though. Competition is always good. And it's their time and effort.
Re:Don't start over, just help X (Score:1)
You've got me worried already... * Display backend : controls the hardware
That's the X server
Not entirely. I mean extremely low level. Like an Xfree 4 module. The server would be a more abstract element in the system, consiting of the I/O for devices, whatever Extensions you would be running (think X-RENDER / Display PostScript / OpenGL), and the server communication glue.
* GUI library : Basically xlib
Huh? Xlib doesn't povide any GUI stuff at all, unless you consider things like rectangles, points, and arcs to be GUI objects. There are no widgets in Xlib; it is not a GUI library. GTK+ and Qt are GUI libraries.
I do consider rectangles and stuff GUI code. They are drawings that make up the graphics, that make up the user interface. So, it is GUI code. You would build your toolkits on top of this, just like you do with Xlib. Now, it is possible to write a program sans toolkit, and you could do the same with this, but it would be just as painful.
* User Interface Management : controls for the various devices like mice and keyboards
xset and xmodmap
Not exactly. I'm talking about raw I/O with the devices. There would be a standard interface to use the devices, but then you would have the modules to communicate with the devices. The tools like xset and xmodmap would be built on top of the standard interfaces.
* GUI backend + library communiction : the glue that would tie everything together and allow them to talk, whether it be by network or any other method
Try X protocol. The thing is, X protocol *must* be on a lower level than widgets or other UI components. If it was up to the higher level stuff, then things like KDE and GNOME simply could not co-exist unless they worked out a new standard for network display. But they've already got a standard in X protocol.
I'm just not being clear am I? There would be a standard communication protocol between the low level GUI libraries and the display backend. Now, you could choose how to implement this. Be it over a network, or some way to do it locally with no networking involved at all.
Snipped the rest out
-------------
Re:GUI Unification (Score:1)
Oh boy - thats a whopper! There is no consistentcy whatsoever in the Unix/Linux command line interface. The only thing cocsistent is that you have to type all the commands into the shell. There is no consistency in command naming, command parameters, I/O conventions (does it take stdin input or not, etc) configuration file structures or locations, temporary file usage, naming, location, error logging and log formatting or anything else. This is one of the major drawbacks to new users learning to use the command line interface and to system admins in setting up systems. If you want to see a reasonably consistent CLI, the best place I know of is IBM's OS/400. Its a bear to use and I wouldn't wish AS/400 programming on anyone but at least the CLI is consistent, easy to use, easy to find a command if you don't know its name and easy to find the command's parameters if you don't know them.
Linux was useful the moment it was posted? Bah (Score:2)
Quoting Linus Torvalds: "0.01 sources weren't actually runnable: they were just a token gesture to arl who had probably started to despair about ever getting anything. "
if you're feeling ignorant of linux history, read this [maxlinux.net]. It has content I haven't seen elsewhere.
Re:Don't start over, just help X (Score:2)
>>>>>>>>>>>>
Who says this is a good thing? I'm both a developer and a user, and both sides of me say that the user is king.
Stop misusing the word 'technology' (Score:2)
When will the madness end? Perhaps Judge Jackson should change the Microsoft penalty from splitting the company up to cutting out Bill Gate's tongue? Wow, wouldn't that make Larry Ellison stop and think for just a minute
Re:Why we should keep X. (Score:2)
Bullshit. The explosion of pixmap based themes (on modern GUIs which can handle them, I mean) should be proof enough that nobody cares whether their graphics update in one microsecond or ten.
which can do all the neato stuff like opengl, directx, etc. as close to the hardware as possible
Does the acronym "DRI" ring a bell? "Xv"?
while having at least some basic GUI semantics built-in, so every application doesn't look and behave differently
There is a basic GUI included with X. Start any Athena widget based program, then be thankful that X doesn't enforce policy. If you still believe that it's never too late to make the "let's force everybody into using our widget set" mistake, your solution is clear: pick one. You can get a pretty complete desktop based entirely on Qt or Gtk.
Oh yeah, it needs to be easy to configure (X is a bitch...I never ever want to deal with scanlines and refresh rates!!)
No, XFree86 is a bitch; try MetroX for an example of why we don't have to throw away an entire windowing system just to get a better config program. Even XFree86 is only a bitch depending on which config program you use.
but these are desktop users, who would never run a display over a network in their lifetime.
This gets said a lot, usually by the same people who said "normal people would never use a computer" 20 years ago or "normal people would never use a network" 10 years ago. Is it so incredible to imagine that someone might be at work and want to run a program on their home computer, or vice versa?
Explain to Joe Sixpack Gamer why his GUI has been built on a framework for network-based display.
Sure, after you explain to him why his game doesn't run in ring 0, or why it can be preempted by the operating system kernel. As long as he gets the frame rates he expects, Joe Sixpack Gamer doesn't care.
Re:Linux's GUI problems (Score:2)
This is a really tough nut to engineer, and while you see some horrible hacks of it on systems like linux, the idea is that the user never needs to know how to use the command line if they don't want, and they can do all their work via the GUI, but all the underlying stuff should be easily manipulatable via the console so that those people feel at home too. Remember, the console is a UI, it's just designed more for a different kind of user. The trick is to fully accomodate both and not force them to interact if they don't want.
As for your evaluation of Linux UI standards, I agree with you entirely, and it's pretty sad. If you're forking GNOME, what are you going to be modeling your UI on? Mac? Other? Some hybrid? The idea is really interesting to me, if you'd let me know more I'd love to hear about it.
"I may not have morals, but I have standards."
Re:Don't start over, just help X (Score:2)
No, it has supported rectangular windows with masks. This is far different from a round window in berlin, which is a real shape. No mask needed.
--
Whether it runs on X or not this is what we need.. (Score:2)
I know it will never happen but what I would Love to see is a common widget set API. Then you could have the widget set embedded in the window manager or the X server and all apps inherit in when they run. You wank GTK alright, you want QT, alright. If there was some way to have a layer that calls for buttons or whatever could be translated to the appropriate function calls to do the same thing. I'm not much on GUI programming but I think it would be an awesome idea.
"One World, one Web, one Program" - Microsoft promotional ad
Re:Don't start over, just help X (Score:2)
The user is king. And with Linux (and most other operating systems) the user is occasionally going to want to build a one off application. I have seen a lot of these applications (often built with tools like Access) and they are hardly ever built in the proud tradition of Model View Controller, and yet they are still useful. What's more, these applications are oftentimes much easier to write (at the expense of being difficult to extend and maintain).
The fact of the matter is that Berlin has got to be more flexible if it plans on ever taking X's place. After all, Gnome already has all of the nifty features of Berlin (Corba, OpenGL, anti-aliased fonts, etc.) and you can certainly use MVC to design your Gnome applications. The difference is that Gnome works today (mostly), and unsophisticated users can easily build simple applications without having to worry about using an MVC model. If Berlin doesn't do everything that X + Gnome does, plus some extra nifty features, then hackers and users will simply use Gnome (and the same argument applies to KDE).
This is why it makes sense for the Berlin folks to be targetting non-PC devices. After all, there isn't a pile of legacy X software for these things. There is a chance that they could get a jump on the competition. However, with new shrinky-dink versions of X and GTK and QT both being able to work with framebuffer devices I don't see that happening either.
The user is king, and Berlin has no users. Nor does it really have any truly nifty advantages that are going to lure developers its way. Without users, and without developers building applications to lure those users to the new platform then Berlin will likely remain a nifty toy that CmdrTaco brings up every 6 months or so for old times sake.
Local display is irrelevant (Score:2)
A major complaint brought against X is that it's "fine for remote display, but for local display the network design is a bottleneck". A number of whitepapers have touched on this, including the D11 paper by Mark Kilgard.
A few weeks back I decided to check this out. Using the DRI I implemented several X functions using direct rendering. What this meant was that after some initial setup code for the DRI the client appliation was writing directly into the video card FIFO. There was no pipe. I had direct rendering without the X server, but still using the X API.
There were about a zillion problems with my test rig. It wasn't X compliant: no guarantees of rendering order, I ignored cliplists, I didn't even attempt to care about GCs. But I got pretty definite results. For most operations in x11perf the overhead of the packing plus the unpacking was below 2% and the overhead of extra kernel time was below 5% (which I guessed was a combination of context switches and socket copies).
What this means is that by dropping the local network pipe you'd gain perhaps 7% performance at the cost of the clean X design (separation of the server/client with a well defined boundary). You also need to give every direct rendering client write access to the video hardware. This isn't an entirely unsafe operation, but it is certainly less well-tested than letting X server process do all the hardware banging.
There are exceptions: some X operations are bandwidth intensive. Extensions have been written to address these problem childs on a case by case basis (MITSHM, DRI/Mesa, etc). But for most X operations, with the current balance between GPU and CPU speeds, there is very little performance to be gained and a stable codebase to be lost.
I'm cleaning up the code, checking my results, and I'm going to perhaps release a whitepaper on this later this year. I've got thesis work for my degree to finish first and that's more important.
"If they only opened Be" (song) (Score:3)
I'd move my windows rapid, and they'd redraw not vapid,
They'd move responsively
I'd get such vast improvement In my mouse's pointer movement
If they only opened Be
My afternoons spent quaking, While simulatenously making
Illegal Mp3's
In multimedia heaven, Not in hell, like X11
If they only opened Be
Oh I, Linux guy, Would thrown my redhat CD in the trash,
If Jean-Louis would GPL the code, I'd ditch Linux--in a flash
No more time I would spend waiting, For massive screen updating
When launching apps concurrently
We'd all be very happy, With an OS far less crappy
If they only opened Be.
Re:Don't start over, just help X (Score:3)
> programs to work together on a display
As does Berlin, Berlin does even better than X.
> * It is flexible enough to allow programs to fully
> determine how it is to behave on lots of things
Berlin does, too. But it strongly encourages to use the common facilities.
Here, less freedom for the app developer means more freedom for the user.
Think GTK Themes, just with much more configurability. The user can easily replace a widgetset implementation, and it will apply to all apps, because the API for the widgetsets is standardized.
Have you checked out Berlin's design? It is very powerful and flexible.
BTW: If you "fix" X, it's not the standard X anymore. You "enhanced".
Re:Don't start over, just help X (Score:3)
Dammit, X has supported non-rectangular shaped windows since 1986, but try opening a round window in either KDE or Gnome, and what happens?
X has a few deficiencies in the multimedia area. These can be fixed. It's got to take less work to fix them than to replace X. Meantime, creating a new competing windowing layer is not going to unify the Linux desktop - Linux is not like that. Many people will stick to X anyway, some because they use programs which were written for it, some because they appreciate it's qualities, some (not many!) because they're too conservative to change. So what you'll get is more diversity, not less.
Not of course that diversity is bad. Diversity is good. And one of these days there will be a competing windowing layer that is better than X (if windows don't just become irrelevent before then). But if you think that X is bad, you're the wrong person to write a windowing layer, because you fundamentally don't understand the problems.
Re:Don't start over, just help X (Score:3)
What Berlin needs to do (Score:5)
First, we do not need another toolkit. We need an environment that makes it easy to write toolkits. If we have this, GTK and Qt will be ported quite quickly, and maybe new toolkits simple enough to be programmed by mere mortals will appear.Berlin should only provide unnamed shaped "canvases" that belong to different clients, it should not provide any "buttons" or "menus" or "windows", but conversely you should be able to easily (ie with no setup before the drawing function) do full PostScript and OpenGL graphics into these, and anti-aliased fonts, full UTF-8 formatting of text, and high speed placing of images with arbitrary linear transformations from user memory onto the screen.
(The problem with Berlin and the other projects like it is that is is really trivial to write a toolkit compared to writing what powerful antialiased graphics or asynchronous communication interfaces, and writing toolkits appeals to the programmer's desire to control how others use his/her system, so the programmers get diverted to this useless bloat that actually makes their stuff less likely to be used.)
Berlin has to have an Xlib emulation library so that X11 programs (and remote X clients) can display on the Berlin server. Fortunately this is easier than it used to be because the emulation library only has to pretend that a TrueColor visual exists (a few years ago emulating an 8-bit colormap was mandatory to get some of the awful X clients to work, but these have disappeared). This emulation is absolutely necessary so that people can migrate to Berlin. There is no need to be able to run X window managers.
Conversely, Berlin programs must work on X11. The graphics can be lousy, very slow, and plenty of functionality can be missing (don't crash, but leave blanks in the output). This requires an implementation of the Berlin interface that works atop Xlib. Without this people will not write new applications for Berlin.
Finally Berlin must be easy to program. It should be absolutely clear to someone without a PHD exactly what you do to create a window and draw into it, and to get events, by reading the manual in sequential order. The set of calls should be reduced as much as possible, there should be as few arguments as possible, and none of the arguments should be structures or pointers to structures. Use a static graphics state like OpenGL. And there should not be gratuitous objects, colors are identified by rgb numbers, not "color objects", fonts are identified by names, not "font objects", etc. Use integer ID's for the canvases.
The library has to be C rather than C++ or any other language to make the Gnome/GTK people happy.
Re:Don't start over, just help X (Score:2)
Is it such a great feature that you can run X remotely on a LAN behind a firewall? I think it makes sense to shoot a little higher than that.
VNC clients aren't seamless, but they are far more portable and widely available than X and provide better security, as well as session independance. It's not all one might want, but it already beats X for remote display by a long shot.
Re:Don't start over, just help X (Score:4)
Yup. X is a brilliant protocol for remote display. It's just a goddamn awful protocol for local display. Just because something is well well designed does not make it appropriate for the given task.
Not possible, X's primatives are simply too fine grained.
I look forward to using a gui that runs directly onto an accelerated local framebuffer, with an X server running on that. The network abstraction should run ontop of the gui. Not vice versa.
Re:X *is* bad (Score:2)
Sorry, this is just about the most annoying thing about X for most end-users, and there is always somebody who jumps up trying to defend it. I don't want every program to use a different widget set. I do want my programs to be able to support basic cut-and-paste. I want good support for scalable fonts.
What is X? It's not a GUI. It was not designed to be a GUI. With that in mind, why on earth should it impose GUI standards? It shouldn't! Now, pick a GUI. Use GNOME for example. It uses the same widget set, can cut&paste between widgets, etc etc. Same is true for KDE. It could be argued that there's no real need for interoperability between those GUIs. Just because they're both based on the same low-level framework doesn't mean they need to do the same things with it. Still, though, even with the many different GUIs available for X, copy&paste works quite well. Lots of effort has been put in to making such things work.
Re: extensions for 3D, anti-aliased text, etc.
Having a general extension mechanism is a good thing. Needing to use it to provide basic functionality isn't such a good thing.
You've got to remember when X was designed. In the 80's, while anti-aliasing did exist, computers really didn't have the processing power to use it comfortably. Same holds true for 3D animation. Can you think of any other GUI frameworks from that era that are still in use? The fact that X, a framework made with no support at all for the "basic functionality" of anti-aliased fonts and 3D animation, can be made to take advantage of new technologies simply by providing an appropriate plugin is really quite amazing.
Having said all that, though, I really do want to see good things from Berlin. I would like to see a more modern framework in use. There's a lot of ancient legacy stuff in X that just isn't used anymore, and unfortunately there's no way to "unplug" such functionality similar to the way you can plug in new functionality.
noah
Re:CDA nonsense.. (Score:2)
Very extensible, and efficient over networks. Very similar to how themes all used to be pixmap based, and can now use "engines" to render more efficiently, these extensions allow you to transfer your functionality to the display server when necessary.
Very Cool (and if I'm wrong, flame away).
Slow development (Score:3)
Re:GUI Unification (Score:2)
You don't seem to have much practical knowledge of standards! Standards typically go out of their way to include all of the features people already use. "Par for the course" would probably be a superset of Gtk and Qt (if you can imagine that!).
Seriously, go to a standards meeting sometime and suggest ditching functionality that some committee member's company uses. If an end to the "UI wars" is found, it won't be a in a standards body.
GUI Unification (Score:2)
- ditched X11
- standardize on one of GTK/GNOME, or QT/KDE
- write a human-interface guidelines document and put in place a board for review
We could actually have a system with a user interface as consistent as those of Apple and Windows.Just a thought. Unfortunately it means ditching miles of code written for the widget toolkit not used, but that's par for the course when building standards.
Re:What Berlin needs to do (Score:2)
Re:X *is* bad (Score:2)
And if you think that MacOS 9 or even 8 or 7 runs on the same gui framework code as in the original System 1.0, you have another think coming. I'm not terribly fond of macos myself, but it has come quite some way since two-bit grayscale.
"If ignorance is bliss, may I never be happy.
X *is* bad (Score:4)
Okay, I'll accept that it allows you to do that (that's pretty much the whole point of X, really). But I wouldn't exactly call it "seamless". Between configuring
It is flexible enough to allow programs to fully determine how it is to behave on lots of things -- X does not force you into a specific widget set or window decoration method, window placement behaviour, or anything else
Sorry, this is just about the most annoying thing about X for most end-users, and there is always somebody who jumps up trying to defend it. I don't want every program to use a different widget set. I do want my programs to be able to support basic cut-and-paste. I want good support for scalable fonts. It is flexible enough to have extensions to help with some things. Lately we have seen extensions to add Anti-Aliased fonts and to aid in 3D display and moving picture display.
Having a general extension mechanism is a good thing. Needing to use it to provide basic functionality isn't such a good thing.
Re:Replacing Xfree!?! (Score:2)
Linux's GUI problems (Score:5)
1. Many (not all, but many) Linux people do not understand the desktop, nor do they understand end-users, nor do they understand fundamental GUI design concepts. Go to a LUG meeting and ask everyone who knows what "Fitts' Law" is to raise their hands. Few hands if any will be raised. The linux community is approaching the concept of linux on the desktop from a server-based perspective, and this will not work. Mention killing X and immediately your get arguments of how great X's network transparency is. "Linux on the desktop" will not work. A desktop that "just happens to use Linux" will. A successful linux UI will be one that will be designed as if the command line never existed.
2. Standards have to be good standards. They have to be well chosen standards that are done for sound reasons that are based on fundamental usability principles. We're not talking about "you say tomato, I say to-ma-toe" issues, we're talking about stuff that's been proving by the cold, hard science of cognitive psychology and usability labs. As mentioned in #1, most of the people involved with linux don't understand basic usability principles, so they copy others who they think do understand these principles. Unfortunately, the people that they copy are just as much in the dark about designing good UI as they are. I'm talking about Microsoft. Microsoft started off on a bad note in the initial design of windows when they intentionally violated many proven UI design principles just to avoid Apple look-and-feel lawsuits. Throughout the last ten years of computing history, the only consistency microsoft GUI's have had is the consistency with which they have been cluttered, confusing, unintuitive, inefficient, and inconsistent. Everything from cluttering UI widgets with zillions of underline accelerators to MDI windows within windows to adaptive menus that move around on the user have made Windows the textbook case for bad UI design. I've heard myths of micrsoft usability labs in the Himalayas that have large staffs of highly trained Yeti's with PhD's in design and cognitive psychology. Apparently Microsoft's own programmers have never heard of such myths. Check out the Interface Hall of Shame website. Microsoft is by far the most frequente inductee. I guarantee you that any standards (including any set by the GNOME Foundation) will be nothing more than "Let's go copy Windows". I'm not very optimistic, which is why I'm forking GNOME. The one thing that linux has going for it in the standards department is that people who understand how to craft good standards have the code to do so.
Berlin missed the boat (Score:3)
I think Berlin has missed the boat. X11 has caught up, and better implementations of Berlin's ideas already exist. This is not the time anymore to loose another C++/CORBA thing on the world.
The frontiers in toolkits is elsewhere anyway. If you want to play around with a powerful, extensible toolkit, spend some time digging into Squeak [squeak.org]. It's a research system and on the surface, it looks like a pretty unappealing and cumbersome system with a bunch of oddly colored windows. The documentation is so-so (take a look at the Wiki, it contains some tutorials). But Squeak and its toolkit, Morphic, are also extremely powerful, a window system in which everything is open to inspection and modification, in which everything can be made to interact with everything else, and in which there is a huge number of tools, browsers, and development tools. The whole thing can run on a plain frame buffer (it also runs fine under X11, Windows, or MacOS), and everything is built in Smalltalk.
Re:Don't start over, just help X (Score:2)
MIT-SHM
Check your X server; I'm sure that you are already running with the X shared memory extension. The faster game libraries already use shared memory instead of network traffic to directly update the display.
Re:Why we should keep X. (Score:3)
Yes, but did it ever occur to you that what it does (well, at that) might not be exactly what everybody wants?? X is great for network display server. But guess what, there are some people who couldn't give a sh*t about a network display server. There are some people (um, 98% of desktop users?) that just want a fast (*fast*!) gui, which can do all the neato stuff like opengl, directx, etc. as close to the hardware as possible, while having at least some basic GUI semantics built-in, so every application doesn't look and behave differently. Oh yeah, it needs to be easy to configure (X is a bitch...I never ever want to deal with scanlines and refresh rates!!). You may consider these people wackos, but these are desktop users, who would never run a display over a network in their lifetime. Explain to Joe Sixpack Gamer why his GUI has been built on a framework for network-based display. If anything the remote display stuff should be built on the gui, not the other way around. There is *plenty* of room for another display server. Um, isn't "choice" defined as GOOD around here anyway?
Re:GUI Unification (Score:2)
Neither Apple nor (especially!) Windows are very consistent. These days they're as bad as X _ever_ was.
And it'll all get even more inconsistent. The best we can hope for is some enforced total configurability where the user at least can decide which erratic behaviour they want.
Re:Don't start over, just help X (Score:2)
X is several orders of magnitude less stable then the rest of Linux. Because X has access to essential hardware without an operating system providing a safe interface, it has the power to crash your computer. It's a total cop-out on the part of Linux kernel developers that they won't include protected video access in the kernel, because as a result Linux is not the high-availability OS they like to believe it is. It is a high-availability server OS, sure, because you don't use X on a server.
Re:X *is* bad (Score:2)
didn't have the processing power to use it comfortably
>>>>>>>>>>>>>>
It doesn't matter. If X can't be extended to support AA in the core protocol, it means the core protocol was badly designed. It is a matter of high-level vs. low-level, but the truth is, that X is not extendible at all. If Be (or QSSL or MS) had infinate man-power, they could extend their GUI tomorrow to use fully hardware accelerated display PDF technology running on a remote server in Alaska. After the change, 95% of all apps would still work perfectly (given a fiber-optic connection to Alaska, of course
Re:X *is* bad (Score:2)
>>>>>>>>>>>>>>
GIMP is the best Linux image editor. KDevelop is the best Linux IDE. Reconcile that Lusenix boy.
Re:Don't start over, just help X (Score:2)
Re:Don't start over, just help X (Score:2)
You've got me worried already...
* Display backend : controls the hardware
That's the X server
* GUI library : Basically xlib
Huh? Xlib doesn't povide any GUI stuff at all, unless you consider things like rectangles, points, and arcs to be GUI objects. There are no widgets in Xlib; it is not a GUI library. GTK+ and Qt are GUI libraries.
* User Interface Management : controls for the various devices like mice and keyboards
xset and xmodmap
* GUI backend + library communiction : the glue that would tie everything together and allow them to talk, whether it be by network or any other method
Try X protocol. The thing is, X protocol *must* be on a lower level than widgets or other UI components. If it was up to the higher level stuff, then things like KDE and GNOME simply could not co-exist unless they worked out a new standard for network display. But they've already got a standard in X protocol.
A small question now: does X allow you to make a multi-docment interface (1 big app window, with several document windows that are constrained to within the window). I've been wondering about that for a while. I've seen nothing to say it can, but I still wonder.
Yes, you can "swallow" objects. I don't know if it still does it, but StarOffice used to essentially embed MWM within a window, so you had what ammounted to a StarOffice workspace in which you could iconify, maximize, re-organize, whatever the sub windows. Basically (though I've never actually written code to do it) I believe you just create an MWM widget that is a child of some other manager widget. Afterstep does something similar with whole programs with its "wharf" module. It can be done...Somebody else will probably give you better info on this.
noah
Re:X *is* bad (Score:2)
No, it doesn't -- from Sytem 1.0 to System 7. That's a ridiculous comparison. Compare System 7 (late 80s) to MacOS 9.
But, the real pudding that provides the proof is that you can use a Mac from 1999-2000 (say an iMac running MacOS 9) and my SE/30 running System 7.1. While the SE/30 is slow, and some things you expect aren't there (like double-clicking on a title bar to "windowshade" it), you're in completely familiar territory.
Try that with a randomly selected group of Linux nerds. You'd be lucky to figure what they've mapped the mouse buttons to, much less understand what's going on.
Re:Don't start over, just help X (Score:2)
computing platform today.
>>>>>>>>>>>
Let's see. Quartz provides a better imaging system. GDI provides a better acceleration system and more features. QNX Photon provides better network transparency. BeOS provides a better API. They are all faster ('cept maybe Quartz) than X. How can you rationalize calling it the "most poweful and flexible windowing system available on any computer platform today" when that statement is an outright lie?
Re:X *is* bad (Score:2)
--Ben
Re:Don't start over, just help X (Score:2)
I'd disagree with this. xhosting is bad, but that's not how we set up remote X sessions nowadays, we use xauth keys, or even better, carry it over an SSH tunnel (which is how I do it).
Re:Berlin missed the boat (Score:2)
The X protocol postulates that everything has to be drawn pixel accurate, even over the network. That means for instance that if you display a wordprocessor over the network on a computer with a very large screen, you can't just make everything bigger but with better resolution, no, the wordprocessor window and its menus, buttons and glyphs will just be unreadably small.
This is something that for instance MS Windows can do, (but badly), but Berlin can do routinely. And it is something that X cannot do by definition of its protocol.
One could change that, of course, in say X12, but it would break all backward compatibility. Or at least you would have nice resizable applications alongside with ugly fixed size application.
-----------------------------------------------
UNIX isn't dead, it just smells funny...
Re:X *is* bad (Score:2)
Well, X does some "GUI" things like fonts, middle-button paste, and drag-n-drop. Once you've gone that far, you might as well support a real clipboard.
The main problem people have with X is that it doesn't provide enough common code. This is half X's problem, and half the problem of Unix developers who refuse to agree on anything and instead contunally insist on fighting Widget War VIII, and like it that way.
BTW, the MacOS GUI framework was designed in the early 80s and is still in use.
Don't start over, just help X (Score:5)
- It seamlessly allows local and remotely-running programs to work together on a display
- It is flexible enough to allow programs to fully determine how it is to behave on lots of things -- X does not force you into a specific widget set or window decoration method, window placement behaviour, or anything else
- It is flexible enough to have extensions to help with some things. Lately we have seen extensions to add Anti-Aliased fonts and to aid in 3D display and moving picture display.
Many of the old ``problems'' of X, such as no anti-aliased fonts and poor support for moving pictures and 3D, are being addressed within the existing framework of X. This is because X is great, it allows for this sort of advancement while still having compatability.If you want to make your windowing stuff faster, if it's X's fault you can almost always fix it. But I think that we can do a lot from within the framework of X. I see a future where X actually has most of the stuff running inside the video card, and programs on the local machine sending updates to it, similar to the way in which programs update remote displays over a network. Without the framework of a flexibile windowing architecture this is impossible, but with flexibility it is within reason.
Please don't get rid of the good to go with the new. Don't just sit around and bash X, either. 'Cause X kicks butt. If you have a problem with X, fix it. Don't just whine.