Slashdot Mirror
Berlin 0.2.0 Released
starseeker writes: "The Berlin people have released version 0.2.0. Check out the new screenshots.Talk about your awesome graphics!" For a project that's had a lot of smoke over the years, it's pretty nice to see something tangible.
What if your monitor's fallen over? Seems like this would be a good way to get around the problem.
That said, I think it's time I changed my
Berlin is not a window manager, it's a full blown windowing system. ie. it's a replacement for X not for fvwm! I don't know if it is API compatable or not, I hope so!
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.
One word: cool focus/maximize/minimize transitions! (ok, 5 words).
Minimize an app and it spins and fades to the bottom of the screen.
Transparent windows: dont miss a second of your streaming video from behind a full-screen terminal.
This isn't "just" another window manager, this is a whole new graphics server.
This isn't intended to run under X, it is intended to replace X.
For more details, see this page.
Cheers,
Tim
It's official. Most of you are morons.
Instead of a lame spin-n-disappear, how about "spin to get your attention"? Beats the pants off of "flashing title bar" or "tiny light in the corner of the window".
--
Compaq dropping MAILWorks?
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
Okay, it looks nice and has a lot of interesting effects, but I'm really wondering what the whole point of being able to do linear transforms on windows is, other than for purely cosmetic reasons. Who here would ever really need windows tilted at some neck-wrenching angle whilst actually trying to get something done?
Apart from that though it looks like it'll be promising if it ever gets to a fully working state and people start supporting it. The idea of having its API exposed through a CORBA interface is interesting, though I do wonder at a possible performace hit there.
Anyway, it's about time something took over from X, a system which is becoming increasingly aged and complex. I certainly hope this takes off in the next few years.
---
Jon E. Erikson
Jon Erikson, IT guru
.... would people look at a product described as 0.2.0 alpha test and proclaim "Not Vaporware Any More"! The "community" does itself no favours by boasting about these promising but half-finished applications on public fora like sourceforge. Why not concentrate on products which are ready for primetime like (insert your favourite example here -- I'm not interested in flamewars). Taco et. al. have the right idea with the Slash code -- release reasonably early and often, rather than constantly crying wolf over a product that's still sucking nipples. The way some projects carry on, you'd think they were just playing the hype game to raise IPO capital -- even some of the much-reviled marketing droids would quail at the number of "launches" and "new releases" that these projects go through. Relax, guys, you're not in the commercial arena so stop huckstering like you're selling raw prawns from an unrefrigerated truck on a hot day.
-- the most controversial site on the Web
Their Berlin vs X document makes a big thing of pixel independence, but I see this as a disadvantage. Present displays, and future ones for that matter, still have pixels that are big enough to see, and the difference between a 1 pixel line and a 2 pixel line is significant. As a result I'm not ready to go for pure non-pixel metrics yet, although I grant that they are increasingly useful.
I also worry a bit about the CPU/GPU overhead of all this stuff, although I grant that this is a pretty short term concern. Modern high-end graphics cards can do this stuff at the necessary speeds without problems, so its only 2-3 years until the bog-standard consumer PCs have this capability.
Paul.
You are lost in a twisty maze of little standards, all different.
Maybe this will help. Also the FAQ is here. Personally I like the idea of someone working on an alternative/replacement for X, things change.
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.
Berlin is not API compatible with X.
If it was they wouldn't have been able to do some of the cool things they are doing.
What I hope though is that some stuff can still be ported to it quite easily. For example. I don't know too much about it, but since the GTK+ ppl make the (IMHO) brilliant decision of writing GTK+ for GDK and GLIB rather than making it depend on X, they may now be in a position of writing an alternate gdk library over the berlin APIs and suddenly gnome works on Berlin!
Okay, I have made it sound simpler than it is (not least because I don't really know how complicated it is) but hopefully it's possible.
wow. just imagine that. a CHOICE of windowing systems to run a choice of desktops on might be a reality in the near future.
I like choices.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
At least if the text in it stopped scrolling you could tell that your program compilation was finished, which you couldn't tell in an iconised window except by opening it up again.
Also, if windows are really 3D, you could push them back into the screen to get them out of the way (they'd shrink smaller the further you pushed them back) and then drag them forward to the front of the screen to use them.
----------------------------------- My Other Sig Is Hilarious -----------------------------------
How do you define a "bog-standard consumer PC"? I just checked Gateway's cheap boxes (I've never bought anything from Gateway, it was just the first mainstream consumer box vendor that popped into my head). It turns out that these machines, which retail from $799, include integrated Intel 3D graphics hardware. Without a doubt, that hardware doesn't exactly compete with the big guys' stuff, but it might be able to handle the probably rather modest fillrate requirements of a GUI. Then again, it's a completely different question when we can expect to actually find this kind of hardware in the homes of the consumers... Hm.
main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
Nice screen shots. The only problem is that beauty isn't really what Berlin aims to fix. The weaknesses in X are well known but I will list them here for those who are unaware.
1. Size. X 3.x eats up 16 megs of RAM If you run it on 8 MB ( I have ) you will notice a distinct crawl caused from swapping.
2. Speed. X is fast but not quite fast enough. On a low end Pentium Linux runs wrings around NT or 95 for most things. The GUI is only a little faster however. I won't be happy until the *nix GUI is 3X the speed of the Windows GUI on the same Hardware.
3. You can't resize the desktop without shutting down X. Yes I know you can switch resolution but the Virtual desktop size will remain the same. I.e. this is good for Zooming in on fine print or small pictures. Nothing much else. If you use Mac, Windows or OS/2 you know why someone would resize a whole desktop.
4. X is not stable. Sure most of us hardly ever get a GUI lockup or spontaneous X server termination. Too many of us have seen this though. I have never seen an E-Smith server go down without massive hardware failure. Same goes for Cobalt Cube. X doesn't approach the stability of Linux or Apache or SaMBa. Bad Applications can't take down the Kernel. It can take down the GUI however. I.e. Sometimes Alpha quality KDE from CVS dose this for me.
Everything else that people see as wrong with X can be fixed at a higher level. If these problems can be fixed without ditching X then by all means do so. If X must be replaced then so be it. Berlin will still run X apps. It won't matter if it doesn't.
--= Isn't it surprising how badly I spell ?
I think this is why pixel independence is so important - think anti-aliasing (and we all know how good X is at that). Represent the data as unlimited (or very large) resolution and resample to the actual display. This would be very cool for CAD, wireframe 3D (i.e. all the content creation apps), proper AA fonts, etc.
Jon.
Microsoft thinks, "Well the command line is not very useful to the average computer user, let us do away with it."
Unix programmers think, "Well I do not think rotating windows in 3d is useful, but let us keep this feature, someone else may have a use for it."
Keep this in mind... it is hard to find a use for something that does not exist!!!
--
May the source be with you!
--
May the source be with you!
Jason Zwolak
Think of Berlin as something that is rather useless right now, given current hardware constraints, but will become a very nice graphical interface once we have monitors with pixel spacing more comparable to paper.
Given a future world where such hardware exists, it's easy to see where current windowing systems (X and MS Windows in particular) are woefully inadequate. Anyone who has a high-end monitor and has set the resolution to something like 1600x1200 knows what I'm talking about. All the fonts are way too small. So then you go and change the default font size. *Then* you find out that there are a lot of application developers who never tested their applications with a larger font size.
Berlin will be a good basis for a future windowing system. It's time will come.
I'm a leaf on the wind. Watch how I soar.
I'll give it a shot. Most any application program you're likely to use runs on top of X, which is a windowing system. You can imagine X being at the lowest level, as it is written specifically for the hardware it runs on. Interfaces like KDE or GNOME run on top of X, usually written in XLib, X's programming API, or XT, the X Toolkit, which provides basically an abstraction and a set of "widgets", or common programming components, for XLib. Then, you have your window manager. This would be kfm, if you're using KDE, or you might be running twm, or fvwm, or Enlightenment, or about a hundred others. Berlin uses GGI for graphical display. GGI unfortunately doesn't contain native hardware support, to the best of my knowledge. It's a library which utilizes several different existing graphical display libraries for output, such as svgalib, X, and fbcon (frame buffer console). Though I haven't researched this myself, I would expect that you need to be running fbcon in order to get any usefulness out of berlin, but I could be wrong. Anyway, I hope this has been at least somewhat helpful. -Dan J. "Hrothgar" Rempe
Not so much marketting as communication.
Of course, there is a lot of overlap between the two concepts - good communication can often be good marketing, and vice versa. Occasionally good marketting is bad communication - e.g. selling a bad product by lying about it, or even bad communication is good marketting - selling a product by failing to explain what it is.
Whatever the terminology though, open source software is foundationally dependent on lots of communication to link developers and projects. If a project does not have a web page and obtain links from the relevent forums, then projects can never get off the ground.
If open source were to take your advice it would cease to exist.
The most interesting Berlin idea IMO is the change in the client-server protocol : in Berlin protocol, ASAIK, the presentation details (like repainting a window when exposed ) are in charge of the server. In X, they are in charge of the client ( though they are handled by the toolkit for standard widgets ).
This should greately reduce the communication flow between client and server, therefore making it possible to implement it over low-bandwith connections ( as is the Internet for most people ).
Also, this should also make possible for applications to be truly and easily toolkit-independent.
Ciao
----
FB
My personal take on a 3d desktop is such:
/..................\
/...-----------......\
/.....Close App........\
/........................\
/..........................\
The only advantage that you get from having a third dimension (to some extent, we have a z axis.. but not really) would be in adding more desktop space.
Imagine having just one desktop with DEPTH. You want that ETerm that you started up earlier? Reach down to 30% and pull it up. It zooms into view. All the 'icons' on your 'desktop' (which is just the lowest point of the desktop) are actually just windows that appear small from perspective.
You are up here.
/..................---.......\
===============================
Desktop \
Far App
(Sorry if this won't render on non-fixed width fonts)
Neat huh?
The only real problem with this is the clutter that occurs in the back ground. My solution to this is that windows in the background are shaded 30-50% darker.
Rami James
GUI Guy
ALST R&D Center, IL
--
rJames.org - illustration
Dynamic scaling of windows is possible if you can apply an arbitrary transform to something before displaying it - which would make it possible to zoom windows in and out fairly trivially.
And it's transparency in general, not transparent windows, which is useful - this allows antialiasing, among other things, to work properly.
(Not that I'm a Berlin programmer or user, just an observer...)
This is strange: this seems to be the same crowd that not so long ago has been actively discussing just how much X sucks: it is ancient, does very poor job displaying fonts, curves, is all crufty, etc., etc., etc.
Now, here comes the news of a project [long in development and refered to a number of times in the previous discussion] making a new (though pre-pre-pre-alpha) release, boasting numerous new advances, done in the [so much adored] OS way. And what do we see? Sceptical "well, this is all so nice but it is nott even close to become a replacement for X" or "WTF do I need those rotating/tilted windows for?".
Folks, this is about developing new things! This is about a brave new world. There were so many people who were going ooh!... and aah!.. about Apple's Aqua -- Berlin can almost do the same sort of thing (correction may be able to do the same sort of thing in future)! Why on Earth does it produce so much scepticism?
--AP
Please don't put MS Windows in there. Windows has been pixel-independant from way back as far as I've known (back to the 3.0 days) and maybe even further. Yes, you can still use pixel alignment, but non-pixel based measurements are built into the GUI.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
I gave this some more thought. One of the main reasons that we, at this point at least, don't need programs like 3dWM is simply because all of the CONTENT is 2d.
Any applications that you run are built around the paradigm of a 'window' and content inside a 2 dimensional box. While this idea works well for flat screens and flat OS's, this does not apply in any way to a OS(or wm) with that added dimension.
How useful is it to compile a kernel in a window that is floating at some odd off angle in the middle of virual space? Not very helpful at all. Now, imagine a program that is built with the Z in mind: my example is a file manager that has it's branches in all directions. I am POSITIVE that it is more intuitive to a user to think to himself, "I know I put the file over there, in the back to the right," over the tree system that we have now.
There are some things (most things, IMO) that work well in 2d specifically because we are used to writing in 2d. Other things (organization and such) are more suited to oriented positions and such.
Rami James
GUI Developer
ALST R&D, IL
--
rJames.org - illustration
This really looks nice. I'm not sure how much berlin can be compared to apple's aqua but it looks like it has rather similar capabilities. For those who are wondering what to do with all this functionality: it makes it really easy to write graphical applications. Graphical applications generally display lots of 2D shapes which need to be manipulated in arbitrary ways. A GUI library like Berlin does all the difficult transformations for you. Since it's all integrated, it works fairly transparently too. I admit that rotated, translucent X-terms are not a particularly exciting example (I wouldn't want one on my desktop) but you have to realize that it is only an example of how easy it is to make such graphical objects (in any case, what would make a terminal window exciting?). Note that these transformations can also be applied to objects inside a window.
Having resolution independent graphics is a particular nice feature which can for instance be used to add high quality printing functionality to applications in a very straightforward way but also allows for zooming functionality etc.
Jilles
The basic difference between X and Berlin at this level is that the Berlin system stores representations of all graphical objects on the server, whereas X only stores windows. There are swings and roundabouts here, but one of the swings is that, as the parent message points out, that Berlin does repaints on the server. However, the downside of this is that the server's memory usage is dependant on the complexity of the display, and probably higher on average than that of an X server.
This does not have much impact on bandwidth use - all display changes still have to be sent by the client to the server, and these are more frequent by far than window-damage repaints. Oddly, remote UI graphics are not especially bandwidth hungry - both LBX and Citrix's ICA use roughly modemeseue amounts of bandwidth. It does, however, have a positive impact on latencies and Berlin, if done right, should be usable over much higher latency connections than X (like the internet).
Simon
Disclaimer: I work for Citrix, but am not speaking for my employer.
Sure, the effect is silly, but what it says about the software's architecture is not.
What this is meant to demonstrate is that the software design is highly orthagonal -- that you can make a list of objects going down the page and a list of operations going across, and if you checked out which operations apply to which objects, nearly all the cells would be checked.
Orthagonality is a desirable property for two reasons. First, it implies flexibility. One of the most frustrating things when using other peeople's designs is to find out you can't do x with y because the developer never thought anyone would need to. Secondly, it eases the learning curve. When you wonder "Can I do x with y?", the answers is likely to be yes and you are less likely to have to refer to the manual on a regular basis.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
For an interesting take on "rewrite it from scratch" software development, check this out:
http://joel.editthispage.com/st ories/storyReader$47
Talks about Mozilla, Borland, and other projects that have had serious problems rewriting from scratch. Also,
http://joel.editthispage.com/2000/05/26 (scroll down)
A great quote from Lou Montulli of the original Netscape team.
Berlin is not a replacement to GTK/Qt or to GNOME/KDE or to any of the window managers that run on top of any of the previous. It is a replacement for X, an attempt to redo what X did, only more intelligently, with a knowledge of the limitations of X and taking into account the developments of the computer industry and for that matter the new needs of the computer industry.
X is powerful but there are several areas where it cannot be revised and extended without breaking all the other applications which currently depend on X. Sooner or later you need to throw out the old software and do a clean start.
The real significant developments in Berlin are the fact that it uses CORBA for brokering the API, a well thought out approach to client/server distribution of resources over the network and the support of resolution independent graphics as well as other features of modern graphics hardware.
Why not use X? Because X was designed in a far more different era than the one we have now. It is better to have a system that is optimized for modern computing uses and has room for growth.
Why would anyone switch from X? As has been commented over on the Berlin site, one can create an XLib compatibility layer, and between that and ports of GTK and Qt, which are designed to be insulating layers between programs that use a GUI and the underlying graphics API, running existing software on Berlin shouldn't be that difficult. Modular software design in the Unix world has its overhead but there are advantages to it.
Unix needs to evolve with the times. Yes, there is power in continuity and well-hammered tools that have survived the test of time, but that should not be a barrier to progress. That includes things that are technically separate from Unix but closely associated with it, such as X. Apple keeps pushing the standard for graphics forward and OS X has raised the bar for graphics technology. The Berlin people have a moving target to hit.
People may wonder at the hype of a 0.2 release, but the fact is that Berlin is slowly starting to move from the 'interesting toy' level to something more along the lines of a serious prototype for a new windowing system. Hopefully it will start reaching the point where it attracts more developers interested in a cool windowing system.
The second step is the XLib and GTK/Qt porting support, at which point the number of applications that can run on Berlin shoots up dramatically.
The real goal is to get software driver support for Berlin on the order of support for XFree86. That is going to be a pain in the neck unless someone can figure out a brilliant way to get device drivers for X to be used by Berlin. Those systems with open source drivers will probably have drivers written by motivated developers.
I'd like to see a real competition for developer mindshare between Berlin and XFree86 on the order of GTK/Qt or GNOME/KDE. Competition can only benefit the consumer.
For antialiased fonts, the font bitmap is basically the alpha transparency. There is no real image bitmap to speak of. Normal X fonts have alpha transparency, only it is either 100% opaque or 100% transparent. A 4-bit bitmap provides more than adequate anti-aliasing.
But Berlin looks like a dog. I know that it is version 0.2.0 and very prototypical, but I would prefer them to work on the underlying stuff rather than generating their own widget sets which look really foul and basic. I approve of the other posters idea of porting GTK+ to Berlin just by rewriting the underlying libraries - that would make things look a lot nicer immediately.
Anyone who doesn't know what use Alpha transparency in windows does not have an imagination. Subtle drop shadows for active windows is one UI prettification, fading backdrop windows is another.
Does Berlin allow for affine transforms of windows at all? Does it allow for basic image processing of windows (that would be great!) such as tinting them, or greyscaling them? If you are going to do transparency and rotation, then these other things should be done as well.
The transforms are not that useful when applied to windows, but the same transforms can be applied to any visual in the berlin system. For example, you could have a really spiffy nested list widget (think MacOS finder), and when you click on the button to expose another sub-level, the button rotates in a visually pleasing manner, instead of simply switching to another state.
I think that Apple's Aqua--as bad as I think it is on some points--demonstrates the utility of transaprency and translucency in a GUI. It cna be used to give the user the feeling of being immersed--almost a 2 1/2D experience. Transparency is not the most useful of features IMHO, but translucency can be used to great effect. There is no good reason that a window should not very faintly show up behind another. It gives the user more information, in a controlled fashion. This is a Good Thing.
It can also be used to make an interface more attractive. This is not as immediately useful, but it is a fact that we are more comfortable with attractive things than with those which are, shall we say, ugly. Why is it that every few years every GUI gets some sort of facelift? Because people want an attractive interface. It's the same reason that car interiors change. It's Style.
As far as pixel-based vs. measurement-based systems go, I think that it is pretty unarguable that measurement-based systems are superior. The only reason for being pixel-based is that it removes a layer of processing. But wiht more powerful computers, this is not such an issue. It just makes more sense. Granted, individual pixels are still visible (at least on screen; try seeing one dot in a 600 dpi printout), but this will not be so forever. Resolution-independence is a Good Thing because it simplifies printing, because it simplifies changes in monitors and monitor parameters and because it uses a scheme which is familiar to users (whether that scheme be inches or centimetres, we've grown accustomed to using them). In addition this solves the problem of screwy fonts (can you say Windows?). Fonts are defined in points, which are 1/72 of an inch; with a measurement-based system, fonts will display perfectly, and at the exact size specified, both on-screen and printed.
BTW, for those who hate metric and those who hate English units, I imagine that any display scheme is going to use its own internal measurements, translating to the user's preference. So the rest of the world need not worry about font sizes measured in old-fashioned points screwing up their displays, and I don't need to try to think in millimetres. This way we're all happy and all compatible. What a thought!
I think this is a reasonable summary:
X and Berlin are the core graphical interface programs which allow graphics to be drawn on the screen, although that isn't even a sketch of the multitude of capabilities they offer. See their documentation for a detailed description.
Things like icewm, windowmaker, twm, enlightenment, qvwm, etc. are window managers, which provide basic functionality such as windows for applications, logout prompts, menus, etc. and run on top of something like X. (Right now, most run ONLY on top of X, but that may change.)
KDE and GNOME are desktop environments, not window managers. This means that they provide advanced hints for applications which allow for a common look and feel, and advanced interface features like the GNOME panels and menus and providing common functionality to programs that request it. KDE contains its own window manager, but GNOME requires a window manager in addition to itself to function properly.
Basically, X is the only viable alternative at the low level right now. In the case of window managers there are an enormous number of choices. Right now KDE and GNOME are the two major desktop environments.
Compatibility is largely a question of having the necessary libraries for KDE and GNOME applications. You can run KDE apps under GNOME, and vice versa, if your libraries are in place. At the window manager level there shouldn't be a problem - the applications are normally seperate from the window manager and work within its framework.
Hope that is of some help. Look around the internet for more complete listings - some good initial places to start are freshmeat.net and linuxberg.com
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
X11 can make fonts large enough if you configure it correctly. In any case, when hardware becomes good enough that pixels don't matter, adding a resolution independent imaging API to X11 is easy. In fact, people are already working on it.
The only sensible way I find of implementing that kind of design is with a safe, platform neutral language, like PostScript or Java.
In fact, most of the goals of Berlin seem already satisfied using Java as a display server: widgets run in the server, a resolution independent API, etc. I think the Berlin effort might be better expended on implementing AWT and the Java2D imaging API on raw hardware in an open source project.
The X11 folks weren't stupid, and design like Berlin's were around before X11 even was created. To me, it really appears that the Berlin model is fatally flawed.
The parent post is quite correct that getting new code onto the server is a question the Berlin team have not yet addressed - though if I remember correctly there are a number of approaches that might work, including adding new widgets as remote CORBA objects. Allowing Java, or better (though probably not appropriate to Berlin) Postscript, code to be downloaded to the server would certainly be a big plus. Probably there are other configuration management issues to tackle in the system (as there are in X).
... Java2D ... on raw hardware" - they already use acceleration where it is available, what more is needed ?
I'm not sure comments on how other people choose to expend their free-time are really appropriate, and Berlin is at the very least interesting, and at best possibly very useful.
I'm not at all sure how one could "use Java as a display server". You could provide remote access (using, say, RMI) to the AWT or Swing, and this has indeed been done for the AWT, and works. Kinda. You still have the same issues with getting new graphical objects from client to server as you do with Berlin. Remoting Java2D would really only give you a "better X", or really a "better ICA" since it has no windowing primitives. Nor am I sure what is meant by "implementing AWT and
Finally, while the design of X has much to commend it, the protocol itself is by no means the last word in how to design a graphics system. It has no support for, for instance, vector based fonts or antialiasing, and these problems do show increasingly as the protocol is used more and more to push bitmaps and nothing else in systems that try to get more out of it than it was designed to provide (eg Englightenment).
Simon
It's not as if Berlin just pulled this code out of its collective ass -- a good chunk of it is mature work from the Fresco project, of which Berlin is essentially a continuation.
A lot of the Fresco code was 13 years in development. The only relatively immature code in Berlin is the underlying graphics subsystem, the CORBA stuff, a few aspects of layout, and the new event/input model.
So, they're buliding on an existing system, rather than just trying to redo EVERYTHING from scratch.
DNA just wants to be free...
I believe you're referring to XCruise. It's pretty useless as a file manager, but fun to play with and show off to non-X friends. You don't even need an expensive graphics card, OpenGL or Mesa to run it.
Size. [XFree] 3.x eats up 16 megs of RAM If you run it on 8 MB ( I have ) you will notice a distinct crawl caused from swapping.
Keep in mind that when you start an XFree X server, it maps the video card's address space into system virtual memory. This makes it look like it is using a lot more memory then it is. You need to look at the RSS (Resident Segment Size), or how much physical memory it is using.
In most cases (on Linux, mind you -- commercial UNIXes are another story), I've found it isn't the X server that eats up memory, but the desktop manager, window manager, Netscape, terminal program with translucent inverse rotated backgrounds, and that sort of thing that really chew up memory.
Try just running "X" (not "startx", not "xinit", just "X", the server itself) and compare memory usage to a full blown X desktop. I think you'll be surprised.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.