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.
Shit - I really wanted to read that before going home.
> 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
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.
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.
Consistency and Configurability are two different things. Without the former, the latter is meaningless.
ENDUT! HOCH HECH!
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.
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
GTK has been ported to Windows, but that is a far cry from GNOME which is not a toolkit, but a desktop environment.
LibBT: BitTorrent for C - small - fast - clean (Now Versio
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.
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.
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.
It's called The Direct Rendering Infrastructure.
http://dri.sourceforge.net
Ranessin
>I have my OWN processor, thank you very much, and I don't need to run Mozilla off of a honkin' big >Solaris server.
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.
Well, I don't know about Direct3D, but with OpenGL the library was designed in such a way as to make drawing over the network fast and easy. In fact, the bus to the video card is a network of sorts; it's much faster to upload a bunch of data over the "network" (bus) to the video card and have the video card process it than it is to process it in advance and send much more data to the card (that's why we have display lists, texture id's, etc.).
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!
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!
Yeah great, except your first paragraph doesn't fly. Linux was useful almost from the first moment it was posted on usenet. The GNU toolchain was already hanging around, and the kernel booted and ran on certain hardware. A few months later, it was quite feature complete. Within a few years, it was the best thing going in Unixes.
Perhaps you missed the fact that Berlin is a Vector-based GUI. You know, like Aqua?
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
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...
X is so, so, so very slow compared to Windows/MacOS/BeOS and the like it's near unbelievable.
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.
I gots ta ding a ding dang my dang a long ling long
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.
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).
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.
then X-Windows *might* have a competitor. If Spruce Goose takes off, then F-22 *might* have a competitor as well. Cheers.
actually its come so far that some folks in my office who have never seen anything but Windows tell me that the GUI of an Apple sucks. I really hate Apple and everything they do (OS architecturewise), but their GUIs always were intuitive. The best compromise i know about in case of Usability was the AMIGA though. Most of my friends didnt even KNOW that it had a powerful shell. They just inserted a disk and started playing. Those who wanted a Desktop had the workbench and it was a simple and easy to learn. Anyone who wanted to go deeper into the system had the shell. Thats how it should be, thats what Apples trying with OS X (though i must say that i believe they will fail). When it comes to Linux i really dont need a standard Desktop though. I think about nice and easy webpads running linux or about Mp3 Players in my car or whatever all having a different Look&Feel. When i come home and turn on my PC i can still have my fovourite flavor, be it a plain console. Thats the STRENGTH of Linux not one of its weaknesses. Lispy
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...
Where'd you get that information from? Everything that I've encountered about Aqua places it as vector based. If it's not, how did they accomplish the realtime distortions of video when minimizing windows?
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"
Higher Logics: where programming meets science.
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.
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 "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
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.
GNOME has been ported to windows, along with XF86, using Cygwin - there was an article about it here a few months back...
A few questions -
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.
--
Free Mac Mini
Everyone should read Jef Raskin's, The Humane Interface. It's totally useless but so is XFree86 and Windows! The has been no real breakthrough in GUI APIs either.
I'm glad that I'm not you!
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.
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...
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.
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.
Display PostScript isn't vector based the way Aqua is AFAIK(though I think it COULD be if you tried). Besides, even if it were, there are no environments using Display PostScript in such a way(which was my point). And yes, I am very familiar with GNUStep and MacOS which both used Display PostScript, but once again, not in a vector based GUI. Swing is definitely not vector based.
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 about Aqua.
No toolkit will do that for you without expensive matrix transformations. I think if you check out the Berlin 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"
Higher Logics: where programming meets science.
I must add to that and say that alot of the graphics used in Aqua are not vector drawings, but the Core most certainly is vector based. Unless, of course, you can prove me otherwise...
-----
"People who bite the hand that feeds them usually lick the boot that kicks them"
Higher Logics: where programming meets science.
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.
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?
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.
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.
I love X. Great and amazing Architecture. Still, it isn't all the way there. It needs more flexibilty. It's hard for me to describe, but I'll try.
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
-------------
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
> The command line is a consistent interface.
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.
So here's a uninformed post by me ^^
X has competition; Mac OS X
I'll let everyone else fight over this comment =)
Geek dating!
GPL Deconstructed
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...
This is a good thing because if they were to try to modify OS9 to suit their needs I'm sure they would fail - just as you predicted. Fortunately for Apple, they bought an OS that has already proven its self to be anything but a failure (at least in OS design.)
There's something good to be said about starting fresh. It's a lot of work but it sure pays off in the long run...
Willy
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
You mean Xterm? Not sure if theres any distribution that actually uses that anymore (well, its there), but compared to DOS windows not even having a scrollbar... and resizing the font when you change size on the window? Eh. Heh. Windows needs no FUD to help them along...
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.
I just want something that's half, no, one quarter as functional as the Mac's CopyBits routine or the various windows blit routines.
X11 was written by network hackers, not graphics people, and by god it shows. X is not bad. It's positively evil. It's the most putrid piece of shit I've ever had to use, bar none. The sooner it goes, the better.
A.
Man, I wasted 5 minutes writing a response to this before I got to the end a realized it was a troll!
-- It only takes 20 minutes for a liberal to become a conservative thanks to our new outpatient surgical procedure!
Isn't everybody TRYING to get bloated performance?
Ok my karma is maxed out. When do I become Enlightened?
> * 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.
Poorly.
(jfb)
To spur "enterprise Linux," Big Bang, the distributed two-phase commit.
> Both are very good products/projects, so why standarize on either?
Well, if you're writing, say, a work processing app, which environment do you design it for? Now, how well will it work with some else's graphic app, designed for a different environment? And will both of them work with the spreadsheet someone else wrote?
Will they share the same clipboard? Use the same printer drivers and control panels? Can you embed spreadsheets and pictures into the word processor, and double-click on them to edit?
And even if all that could be made to work (and I understand that efforts along those lines are being made in KDE/Gnome compatibility) they're still going to have inconsistent look & feels.
Convictions are more dangerous enemies of truth than lies.
- Nietzsche
First, throw away the over the network approach to GUI. Instead, modularize the entire architecture. Then, you could swap in a network module for the xlib + xserver interaction, or you could do without the network, and do it all locally somehow.
Expanding on the idea of modules, allow swapping them in out while the system is running. I say system, because the server wouldn't be the central part. You'd need a few core components:
Now, X does meet a lot of the goals, but I want more. Can I run X without any network sockets ever being used? Can I make X run without displaying anything easily? Can I get X to run in text mode (ala aalib) easily? I don't know the answers really. But what I suggest is to screw X and Berlin at some point, and start over with a more dynamic and rich enviroment. These modules in the Windowing System would be like X-extensions, but on lots and lots of crack. Hopefully people can see what I mean.
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. Can someone who know the answer just send me a message (just grab my mail addressfrom the mail link). Thanks. (Yes, that is probably a dumbass question or so you think. No one knows everything).
-------------
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
You and all the other "X has (won/caught up)" folks miss the important point about opensource OSes - that there is no coerced standard, and little barrier to porting. Stuff like Berlin can grow in an "incubator" environment of skilled developers and early-adopters, and take its time in winning over ports and converts. Cross platform code like Mozilla and Abiword will get carried over. Emacs will. And nifty programs will build up over time. There is no commercial deadline, and no minimum-profitable user base.
Like all other opensource programs, Berlin will "win" or "lose" only in terms of its ability to attact development - and the attraction can but grow as it matures.
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.
While it's a bit old but it seems to be rather accurate article. X is chatty as far as the actual protocol (extra abstraction layer, etc) goes, wether over local unix domain sockets or over the network, and could probably be optimized (quite) a bit.
But by now we have DGA also.
For most common applications X will be far more than good enough, for the more demanding applications you can write around the slow operations, and for those needing fantastic speed you can use direct access.
The bottom line is, you could write something better. But you'd have to make it compatible with X11, you'd have to invent your own transparent mechanism, and you'd end up with something with another layer of abstraction still running over the same X11 protocol for most applications and something more efficient for a very select few.
You already have the ability to ultraoptimize if needed, as is, today.
Compared to what you could do to improve X for the same amount of work, I doubt you'd end up more on the plus side by reinventing from scratch.
Thing is, I read your comment before I read the article, and I'm thinking to myself, "Cool, berlin has their display-postscript driver" --which I assumed existed because someone else mentioned NeWS -- "implemented in forth?! Nifty".
I was more than a little bummed to find out I was somewhat off.
It might be worth ditching core support for a certain set of features (some kinds of color depths that nobody uses, e.g.) and having more direct support for the current common case: local X clients trying to do the sorts of things modern windowing systems do.
On the other hand, backwards compatibility, especially at the source level, is very important. But it could be only supported through a compatibility layer. (Xnest for Berlin, perhaps?)
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
Besides, if you really like xeyes it's availiable ask a gnome toolbar app.
I've been reading about Berlin for years. But to tell the truth, I wouldn't be interested in it even if the project does eventually start to go somewhere. I like X; I like its network transparency; I like the layered approach to its APIs; I like its seperation of policy from mechanics.
GNOME could never be ported to Windows, and virtual window managers on Windows are a horrible kludge.
It seems to me that fixing the problems in X around color management and font support is a much better approach than taking away all of the advantages of X and replacing them with just a clone of Windows.
LibBT: BitTorrent for C - small - fast - clean (Now Versio
It runs on no less than four megs of ram and that alone is just monstrous! I admit I really don't know much about how XFree really works but I would think that this program should be broken into about 3 programs that are completely independent of each other:
1. The communication layer in X should be a seperate program that interfaces with X when that functionality is needed.
2. Device drives should be made into modules that can be loaded into an opperating systems kernel (when at all possibly feasable).
3. I am told that X has about a million and one ways to do the same things. Re-architect X so it has a uniform standard way of doing XYZ and have a compatibilty layer for older applications.
The things above would make X bigger and smaller but in both cases- better.
The impression I get though is that the XFree developers are not interested in downsizing X to be a simple graphical management system and breaking thier project into little pieces.
The problem with what I am saying is that it is a lot of work and pain for little apparent benifit. At first, that would be true, but eventually, it would lead to more flexible and simpler framework for which real developement would be easier.
I am told that XFree86v4.X has made a huge improvement in building a standard interface for graphics drivers which is a good start but it is only a start... This beast is huge and needs to get smaller.
As for forking X and having a small group do this on thier own... well there are forks but thier lack of popularity makes developer involvement minimal.
I miss the Karma Whores.
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.
Why does the designer of the next generation windowing system insist on using Forth, an oldish low level language?
--
Je t'aime Stéphanie
What I don't get is why Berlin dosen't have some kind of X compatability layer. I'd definatley use it if I could run X apps on it, but for the time being it seems stifeled as just another academic exersize.
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;
Berlin is a great idea. It is doing what C++ did t C except for GUI's. Letting you work with the problem domain and not worry about crazy implmentation details such as lame0 X stuff. Anyways.. (Yes C++ is step up from C IMO) Jeremy
god i hope not. i'd hate to take a huge step backwards.
US Citizen living abroad? Register to vote!
X is a tool designed for allowing GUI control of remote systems on a wide range of platforms. Right now, I have X open for Solaris, AIX, VMS and FreeBSD, and Debian open on my Win2K box. I am able to work with all of them, with no Landesk/Control It/PC Anywhere type stuff. It is a logical, useful, and FREE extension to the command line. Using it for games on a local server is cute, but not the point.
Unix was not made to play Quake on, it was made to process huge Mainframe jobs, do massive sorts, handle web transactions, support databases, and act as a mini-computer stop-gap. It is supposed to span the area between OS/390, VMS/Alpha, Cray, and your average end-user's desktop. This is what it does very well. (IMO) It is a very decent stream editor, an excellent web-hosting platform, and a good cheap place to run scripts. Stop whining that your latest hobby OS (BSD, Linux, BeOS, what-have-you) doesn't run games as efficiently as you want.
I use linux and BSD, for the very reason that I can fix something rather than just whine about it. Now I want to see all of you other free OS users get off of your keisters and do the same! Don't whine about a tool not comforming to your purpose, or, God Forbid, requiring you to think. Use Windows/DOS/Amiga/Mac for that stuff, and let the hobby OSs become real OSs!
Sorry about the flamebait :)
-WSAn operating system should be like a light switch... simple, effective, easy to use, and designed for everyone.
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
fuck all this shit, this'll be the last comment I post on this site untill there's something I've got a lot to say about. damn you all, if anything was flamebait it was the moderation, not the comment...asshole(s)
terradot, growing awareness
The answer does NOT have to be fix X. If they choose to solve the "limitations" of X in a seperate graphics system, then that's their right. Now there may not be many converts to Berlin, and people may not agree in their perception of X's "faults" but that in no way invalidates their work. In fact it is a similar mindset that many critics of Computer Science blame for the lack of drastic innovation in the past 10 years. If we're always just making improvements to the old, we would all be typing from very big, yet advanced, mainframes (maybe a little bit of a stretch, but the point is there)
Trying to solve a problem in a new way often leads to new insights in the problem and better solutions all around. I'm sure Berlin has borrowed some solutions from X but maybe they have seen some problems from a new vantage point and come up with a better solution.
--
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
While Berlin may be a great project with great ambitions, it's going to be a while before XF86 goes away. The key to gaining acceptance and users for a product/project is being the first good implimentation to come around and be used by the masses. While unices in general aren't used by the masses, those that do use them are likely using xfree and aren't going to change until something comes along that makes xfree obsolete...how long's it going to be before most companies switch to Win2000 from 95/98/NT? I'd say double or triple that time period, and you might have something to viably replace xfree86.
terradot, growing awareness
Berlin is getting stagnant and has been for awhile now. Developers simply aren't giving it the attention it needs, and if you ask me it's dying. Back when it looked like nothing good was ever going to come out of X (ie. about 1998), I thought this was a great idea, but now I've changed my mind.
It's not hard to see why. As they say "X sucks", but lately it's been "sucking a lot less" and I've even heard a few "X rules!". Things are improving so drastically fast in the X environment that there just isn't a lot of good reasons to work on Berlin.
Sigs are awesome huh?
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
Great! I'd love to do some benchmarking on its performance. It would be quite interesting if they managed to make a generic RPC system as efficient as a hand-crafted protocol. Too bad there is no installable package around.
Those who don't know their history are condemned to relive it. For about a decade, X11 had one core toolkit on which most people built new widgets. It provided common behavior, common customizability, common layout, and other common functions. Then came Tcl/Tk, Fresco, and others.
I don't give Berlin even a couple of years before its "encouragement of common facilities" will be widely ignored. And if it backs up its encouragement with draconian enforcement, it will simply not be used. Sorry, that's the way software works.
There is a common widget set API called Motif, it's even an open standard and there are LGPL implimentations. If people complain that Motif is dificult to use or inflexible or something then they should work on the standard, if CDE blows, again it's an open evolving standard. If X dosen't have AA fonts write an implimentation, put it under a BSD type liscence and work like mad to get vendors to use it, there the people that sit at standard comittes.
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