Slashdot Mirror
Berlin Project Lead Holds Forth
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.
If Linux"takes off", I'll eat my hat. It is a nice academic project, but just doesn't have the development speed to ever get anywhere. Linux has been around since at least 1994, and before that as Minux (in essence). Lo these many years later, you still can't use Linux for anything other than developing Linux.
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.
This Wiki Feeds You TV and Anime - vidwiki.org
We can't replace Xfree! If we did, what new scapegoat out there would we blame for performance bloat?
"I like to wear big boy pants."
GNOME and KDE are both WAY too fat to be deemed standards and all others dropped.
--------
Genius dies of the same blow that destroys liberty.
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.
You know, I'm baffled that people actually think that X is a great network display server. It's a horribly laggy network display server!
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
--
I noticed
It's getting about time to leave everywhere
I'd say one of the things that's keeping Berlin back is the boatloads of misinformation that's going around.
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.
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 from Berlin as time goes on, will it be referred to as "The Berlin Wall" or "The Iron Curtain"? -Nev
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!
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.
A deep unwavering belief is a sure sign you're missing something...
Perhaps you missed the fact that Berlin is a Vector-based GUI. You know, like Aqua? I don't think there are any other GUI's out there with that capability(besides proprietary Apple one of course) and you certainly won't find any vector-based rendering extensions for X.
-----
"People who bite the hand that feeds them usually lick the boot that kicks them"
Higher Logics: where programming meets science.
Standards should be something more along the lines of "Out of the box this is how the GUI is set up". WHATEVER GUI that is. When you install KDE or Gnome out of the box they should both have a more commonly defined default. You want to play with and customize that default? Great! Go to it! Add lots of bells and whistles. Move the toolbar onto a second display that is in greyscale and flipped so you can see it in the mirror properly when you look over your shoulder.
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.
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
If you don't know shit about X why the hell are you posting about it? Kernel module device drivers are nice for some things (SCSI adapters and NICs) but for video and sound (half-duplex sound at least) you don't need to bother the kernel with it. Having video drivers and the like run in user space means that your entire local interface can die while the kernel and its kernel space drivers chug along. This is simply an issue with the way Unix is designed. It came from the world of mainframes where wasting memory on a framebuffer is blasphemy. X can do things a million different ways because it only really provides a link to the hardware. Its up to toolkits and window managers to decide how things look and act. Thats why you can do the same thing a bagillion ways and dispite my dislike at times for X it is really a powerful feature of it. You're suggesting a load of bunko. X is already broken up into several components and allows for a good deal of extensibility.
I'm a loner Dottie, a Rebel.
How does BeOS factor into this? Get past the name, please. Besides, the comment doesn't even make any sense! You're comparing an OS to a windowing system.
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.
A deep unwavering belief is a sure sign you're missing something...
Check out how X does things locally. Check out SHM. Check out GLX. That networked-application functionality isnt exactly what it sounds like when you're running on a local display server, especially not when you have applications aware of the distinction.
The common case today is that X applications are optimized for the local display server, through design and/or through the toolkits.
If Berlin "takes off", I'll eat my hat. It is a nice academic project, but just doesn't have the development speed to ever get anywhere. Berlin has been around since at least 1998, and before that as Fresco (in essence). Lo these many years later, you still can't use Berlin for anything other than developing Berlin.
Information on Fitts' Law: http://www.asktog.com/columns/022DesignedToGiveFit ts.html
Prevent email address forgery. Publish SPF records for y
The link is already slashdotted and perhaps this was answered in the interview. Can anyone offer a comparative analysis of Berlin and Quartz/Aqua in MacOS X. Is Berlin going to more potent in the future than what Apple is churning out? I have little idea about the two systems but would like to find out more? There are some similarities such as vector drawing, right?
Your pizza just the way you ought to have it.
I too wish that BeOS would be open sourced. It would guarentee the existance of the platform. However, I believe it is not possible because several parts of the OS contain licensed code and I doubt Be has the available man-power to clean it up.
A deep unwavering belief is a sure sign you're missing something...
I think he means more of a "meta-API." Not an API for apps, but an API for widget sets. That way the user gets to decide which widget set to use, not the application developers.
A deep unwavering belief is a sure sign you're missing something...
You're already doing without the network if you're running locally. You're using Unix domain sockets, which isnt really networking but is an IPC mechanism. A lot of applications use MIT SHM, which is shared memory areas for drawing in. Again, no networking (usually they'll fall back to network if they cant get shared memory).
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.
It would take a grand total of four apps ported to berlin to make it a viable alternative for me.
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.
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."
>>>>>>>>>>
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.
A deep unwavering belief is a sure sign you're missing something...
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.
Change is inevitable.
Progress is not.
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.
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. It has content I haven't seen elsewhere.
Life is like an egg better scrambled than fried. -- Ken Sawatari
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)
>>>>>>>>>>>>
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.
A deep unwavering belief is a sure sign you're missing something...
Dammit, is there no end to the damage Microsoft continues to do to the English language? First, every new feature becomes an 'innovation', and then every software library became a 'technology', as I was told when my company recently sent all of us developers off for .net indoctrination. And now /. readers have begun to believe that GTK+ isn't a mere GUI class library, or Bonobo software for object oriented IPC, but infact raw technology, too.
;-)
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
I think the idea of designing a UI as though the command line never existed isn't all it's cracked up to be. Granted, if I were to choose one or the other for intuitiveness, I'd choose the GUI, but I think that the GUI should operate as though the command line never was, but be open to manipulation via the command line, if need be.
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."
"I may not have morals, but I have standards."
> Dammit, X has supported non-rectangular shaped windows since 1986
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.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
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
The Anti-Blog
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.
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" (to the tune of "If I Only Had a Brain")
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.
> * It seamlessly allows local and remotely-running
> 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".
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.
I'm old enough to remember when discussions on Slashdot were well informed.
X is great if you define great as a GUI protocol for running applications over a network. Unfortunately, that's not how applications are run today. I have my OWN processor, thank you very much, and I don't need to run Mozilla off of a honkin' big Solaris server. It's nice to be ABLE to, and sure, that flexibility is an advantage. Unfortunately, flexibility also has drawbacks, because you can't optimize for the specific cases. How fast do you think Direct3D would run over a network? The whole point of accelerator video cards is REDUCING the bottleneck between CPU/RAM/video. If X is going to survive, it doesn't necessarily have to drop the networked-application functionality, 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.
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.
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.
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.
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
I've been following the Berlin project for a few years and I've had the opportunity to look through the source and even compile it on a few occasions. It saddens me to say that the development of Berlin is very slow and is verging on stagnant. It is the most advanced X alternative out there, but I'm afraid that it's not getting the attention that it deserves from developers. Perhaps dropping their ties with Python and implementing a more common C++/C api would assist in the acceptance of Berlin as an X replacement.
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.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
- 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.
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
X doesn't handle drag-n-drop. The most common implementation of it is libDnD.
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.
-- Veni, vidi, dormivi
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.
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.
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. 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.
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.
LibBT: BitTorrent for C - small - fast - clean (Now Versio
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.
Which is exactly why all Windows apps look different and use a different set of core services? That's bullshit. Developers are lazy. Provide them with a good-feature set to start out with, and most won't stray from the toolkit unless there is a damn good reason to. Besides, users (in general) hate apps that don't "fit-in" with their desktops, which provides additional incentive for developres (at least those you give a damn about their users) to work within an existing framework.
A deep unwavering belief is a sure sign you're missing something...
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
I strongly agree with this. People who want to replace X generally don't understand X. X is far and away the most powerful and flexible windowing system available on any
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?
A deep unwavering belief is a sure sign you're missing something...
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).
-- Erich
Slashdot reader since 1997
- 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.
-- Erich
Slashdot reader since 1997