Berlin Packages Released For Debian 349
A reader writes: "Berlin ? testing packages for Debian are available from the Debian website and should soon be moved to unstable, according to their the Berlin consortium website." The Berlin website (which looks great, IMHO) has an excellent architecture FAQ - the Berlin vs. X is very well done.Update: 09/01 12:41 PM GMT by H : A number of people have e-mailed me about some....wonkiness...if you view the Berlin vs X page using Internet Explorer. I'd advise using something else.
I found my reason to try it: (Score:1)
Berlin has alpha transparency today. You can see this on Berlin's screenshots page (www.berlin-consortium.org/screenshots.shtml). Notice that everything can be seen behind a transparent window, not just the background image. Furthermore, Berlin's archicture allows for anything to be transparent, from a single widget to the entire desktop
Well, that's reason enough to load debian on this spare machine and try it
On another note, the site seems to be responding slower now (/.'ing beginning to take effect?), so I cant seem to find information about support. Does berlin build on *BSD?
Re:I found my reason to try it: (Score:1)
Re:I found my reason to try it: (Score:1)
Re:I found my reason to try it: (Score:2, Informative)
Last year there was trouble with the threading
implementation of BSD (not sure which BSD was actually tried). I heared there were a lot of improvements in that area... it might be worth to try again. Please report any finding:-)
Tobias Hunger
Re:I found my reason to try it: (Score:2)
Re:I found my reason to try it: (Score:1, Informative)
Of course it's really a stop-gap measure. OpenGL (which does 2D just fine - set z=0) in the Kernel is the way forward
enlightenment on berlin (Score:1)
there doesn't seem to be much movement on Berlin,
I've kept my eye on it for a while,
last news item was June 28th
X must die
Interesting decisions they made (Score:3, Informative)
If I recall correctly the KDE team were originally intending to use CORBA for all their communications but quickly dropped back to their own KOM (based on Microsoft's COM) for their local communication to improve speed and memory usage of the system. Surely Berlin has come up against at least some of the problems the KDE team did and I wonder what their defense for sticking out with CORBA is?
Secondly, the idea of running EVERYTHING through OpenGL is particularly bothering. Most video hardware has some very specific optimisations for 2D work and by going through a specific 3D interface you are tossing all those performance advantages out the window. Sure, ok they want to create the ability to play with Windows in 3D - my question would have to be "Why".
Most people have a hard enough time keeping a 2D desktop organised that they'd hardly want things at arbitrary 3D angles!! Wouldn't a far better way to go be to leave at least the current window square with the screen (and possibly tap into the 2D performance of your hardware) and at least have some methodical way to place other windows in 3D (if you must), while having severe restrictions on their ability to update...
While very cute and all, I just don't see this becoming a successor to X, Windows or Mac user interfaces.
Re:Interesting decisions they made (Score:1, Flamebait)
Re:Interesting decisions they made (Score:1, Insightful)
Wheres my clue stick... ah here it is, SMACK SMACK.
Dcop is used for inter-process comms with in KDE and its not based on M$ COM.
Re:Interesting decisions they made (Score:2, Informative)
KDE were using CORBA, but found that it was too big and slow. But that was because they were using a big and slow ORB!
D'OH!
There's no reason that the 2D hardware can't be used to optimise the imaging subset of opengl, often neglected by driver writers, who focus on optimising opengl's 3d performance. OpenGL is a 2D/3D API, not just 2D.
And anyway, truth to tell, only Matrox makes 2D hardware that's any good these days. NVidia 2D performance sucks suprisingly badly.
Re:Interesting decisions they made (Score:2)
KDE were using CORBA, but found that it was too big and slow. But that was because they were using a big and slow ORB!
The size of the ORB was not the problem, I believe the size of the resulting executables was. Mico is STL based, and I think the problem may have something to do with template bloat (the STL classes that ship with gcc compile to 50-100k *per instance*)
OpenGL is not 3d specific (Score:1)
Re:Interesting decisions they made (Score:3, Informative)
Most current gfx-cards are more 3d-cards with a little 2D-engine as extra and none of them is slow in 2D.
They can render several 10^6-triangles per second, a window has a astounding 2 triangles. So that won't be a problem.
Furthermore it's a open and evolving standard which even supports rendering videos. (aviplay can use opengl to accelerate videodisplay)
It's a well documented and powerful interface to the gfx-hardware with vendor-support and drivers..
Transparency in 2D is nearly unsupported by hardware (at least I don't know of such things).
The 3D desktop is surely not very useful, but you get it for free, and you don't have to use it.
OpenGL and OT: KDE (Score:2)
Back on topic, OpenGL is NOT simply a 3D toolkit, it provides hardware-accelerated 2D functions as well, making it a perfect choice for Berlin.
Re:Interesting decisions they made (Score:2)
Re:Interesting decisions they made (Score:1)
Re:Interesting decisions they made (Score:5, Informative)
We have hardly any communication between client and server: The client creates graphic objects inside the serverprocess. Those are used to redraw and can handle almost every event that happens (only those that change state in the client get send over the wire). You can manipulate the server not to test for the clients existance. Afterwards the GUI of a client stays around after killing the client itself. You can still move the window, rotate it, set the alpha channel,
Running inside the same address space the CORBA-overhead basically is reduced to a virtual function call.I think we can handle that:-)
Yes, the KDE example is so often flung at us: Yes, the way KDE used CORBA they are way better of with the KOM they invented. But they need way less functionality then we do.
To graphics via openGL:
you can render anything to openGL, you can although render the graphics to libArt (which dumps a raster to the screen) and is the default nowadays. A PostscriptDrawingKit is in the works too: That way you can print anything that can get displayed on the screen. The printout will of course use whichever resolution and colors your printer has to offer;-)
Oh, Berlin _is_ slow right now. But not for the two reasons you give: We have not yet optimized anything and we have _NO_ hardware acceleration at all.
About screen-aligned windows: In the berlin architecture it would be hard work to have only those:-) A window is just another graphic, you expect a line in a graphics program to be reotateable/zoomable/... so we have to support those operations. Nobody forces you to do it. We do it right now mostly to show off.
Regards,
Tobias Hunger
Re:Interesting decisions they made (Score:2)
1. You mention in your FAQ that a developer can use a wrapper around QT and GTK+ - nice idea, but what about Motif stuff? wrapper around those also? same for TCL/TK, FLTK, and native xlib stuff? This will make everything VERY slow..
2. As for drivers for the cards - your best chance would be to write somehow a convertor of X server driver to Berlin. Without this you'll need to sign NDA to all the graphics companies and start writing drivers from scratch - that is of course if you want to use the accelerated features. You can use always the VESA to give the basic stuff (unaccelerated) - what are your plans?
Re:Interesting decisions they made (Score:3, Informative)
2. Berlin does not include any drivers for graphic-card. Instead, it relies on other programs to do that. Currently everybody uses GGI because it has a working implementation working in a X-window. It also works on SDL, GLUT (OpenGL) and framebuffers. Support for other interfaces should be very easy to add.
Re:Interesting decisions they made (Score:2)
>>>>>>>>>>
Sorry to break this to ya, but Qt, GTK+, etc are essentially just wrappers around X anyway. Its not fast the way it is NOW.
OpenGL for 2D Graphics (Score:3, Interesting)
Well, I'm gonna let you on to a little secret that game programmers know all too well. Doing 2D graphics is usually faster if you use the 3D hardware to do it. Now, it does depend on what you're doing, but overall, putting sprites onto polygons and blitting the polygons to the screen is faster than drawing the sprites on the screen directly.
I know these seems odd, but it's really just a fact of the video cards being great for 3D (or bad for 2D, if you want to look at it that way). There's just been so much of a push for 3D in cards, and not too many people have been asking for better 2D performance, so the current crop of video cards is kinda lop-sided.
Microsoft even stopped developing new versions of DirectDraw. They say that if you want to make 2D applications, use Direct3D. This wasn't because DirectDraw was done, or because they want all new games to be 3D, but because 2D graphics API's are becoming insufficient.
Unless i missed something, no one was talking about moving the windows around in 3D. It's strictly a performance thing.
ben.c
Re:Interesting decisions they made (Score:3, Informative)
The 3D stuff is used because it lets you do neat 2D stuff really fast, and not to make animated 3D windows fly around in space. To support games, the 3D hardware can scale and otherwise transform bitmaps to random locations and orientations on the screen. This is used, e.g., to apply a brick texture to the side of a building in a game. You can draw the application window into a 'texture' and let the video card draw it anywhere on the screen at any size. (With rotation and perspective, if you're *really* feeling silly.)
You can also align the texture buffer on page boundaries, and map the window's "frame buffer" directly into the app's address space. This lets programs have near-direct access to the frame buffer without any danger of blowing away the system.
DirectX 8's Direct2d is a special case of Direct3d (Score:3, Interesting)
Secondly, the idea of running EVERYTHING through OpenGL is particularly bothering. Most video hardware has some very specific optimisations for 2D work and by going through a specific 3D interface you are tossing all those performance advantages out the window.
As Yokaze mentioned, a rectangular window is two triangles. Two. The fact that DirectX 8's 2D API is simply Direct3D 8 with orthographic projection shows that Microsoft has begun to understand this, as Shelrem mentioned. Besides, "OpenGL" != "3D"; OpenGL is just a Graphics Language with an Open specification.
The only difference between rotation and scaling of textures in 2D and in 3D is that in 3D perspective projection, there's a divide by z every few pixels to fixup textures if the plane isn't parallel to the x axis. In 3D parallel projection (of which 2D is a special case), or in 3D perspective with the triangle's plane parallel to the x axis (reminiscent of Super NES Mode 7), it's just an affine transformation (two adds per pixel), that is, unless you count elliptical filtering.
Most people have a hard enough time keeping a 2D desktop organised that they'd hardly want things at arbitrary 3D angles!!
You'd be surprised what you can do with the middle mouse button mapped to toggle between the x-y and x-z plane, especially if you map the mouse's x-axis to theta and rotate the view. With the typical 90 degree field-of-view of most FPS game engines, you already have four desktops.
Re:Interesting decisions they made (Score:2, Informative)
Re:Interesting decisions they made (Score:2)
Perhaps you're referring to the 3Dwm project [3dwm.org]? Of course, what you're talking about above has little relevance if that is the case. From the 3Dwm introduction [3dwm.org]: "The 3Dwm project does not aim to create the 'be-all-end-all' 3D user interface
The fine folks working on 3dwm are not claiming to have some great desktop. They are simply making the tools that will allow ambitious developers to write 3D interfaces. Not to mention the fact that they are squarely against the oddly angled 2D windows you are complaining about. Running current apps in a 3D environment is just a migration nicety. Apps that take full advantage of living in a 3D environment should (hopefully) provide read gains over 2D interfaces. Think Borders Books vs. one very very very long bookshelf.
-Erik
Entire desktop?? (Score:5, Funny)
So.. if the entire desktop is transparent.. what do you see.. the inside of your monitor??
Re:Entire desktop?? (Score:1)
Re:Entire desktop?? (Score:1)
Bartender slides a pint over to the neutron.
Neutron says, "How much do I owe you?"
Bartender says, "For you... no charge!"
Re:Entire desktop?? (Score:2, Funny)
The other atom asks, "Are you sure?"
The first atom replies, "Yes I'm positive."
Re:Entire desktop?? (Score:2)
Berlin is a nice concept... (Score:3, Troll)
There's nothing out there for it! People are working on porting Gtk/Glib over, but can they port enough of Gnome to be useful, and still offer any advantage over using X in the first place?
Then, there's KDE. I know of no work on porting Qt or KDE over to Berlin, although that might actually be easier than Gtk, as I think Berlin is C++.
As for the other window managers & environments (CDE, Motif, OpenLook, QVWM, WindowMaker, 3dwm, etc), you're going to irritate a lot of people if these don't get ported. And I'm not just talking a simple Berlin->X11 layer, either. Nobody is going to put up with the speed loss.
Using OpenGL as a central element was interesting, and potentially very useful, but how well can you make use of it? If you've still got a 2D world, but a 3D algorithm generating it, you've just blown a whole lot of clock-cycles on nothing. It doesn't even have a coolness factor. Now, if you can rotate -into- the screen, -that- would be cool.
Last, but by no means least -- CORBA as the communications layer???? And I thought I could be stupid, at times. CORBA is a wash-out, due to too many corporations wanting to have proprietary extensions to make it usable. It would have been a great technology, but either you use the standard and have a gazillion lines of code to work round the limitations, OR you "enhance" the standard, making it impossible for other systems to talk with it.
Also, with CORBA, the overheads are VAST. X is bad enough, but CORBA is a nightmare. One of the important considerations in a system like this is who will use it. If you're talking home users, then you need a protocol with as close to zero overhead as possible, whilst still allowing as much flexibility & dynamicism as possible. CORBA doesn't cut it, either way.
Re:Berlin is a nice concept... (Score:1)
Re:Berlin is a nice concept... (Score:1)
There's nothing out there for it! People are working on porting Gtk/Glib over.
In their X vs Berlin page the say that one of the advantages is that all applications have the same "look & feel" because they use the same widget set.
So, if to have applications in Berlin you have to port your widget set so applications that use that set can run on Berlin, what's the point of their point?
I think that it will be extremely difficult for them to have as much applications as you have with Motif/GTK/Qt, even if the speed is good (has anyone really tested it?). The code base of other projects is big, and a lot of time has been spent on them, so it's not really going to be dumped that easily...
Re:Berlin is a nice concept... (Score:4, Insightful)
Using OpenGL as a central element was interesting, and potentially very useful, but how well can
you make use of it? If you've still got a 2D world, but a 3D algorithm generating it, you've just
blown a whole lot of clock-cycles on nothing. It doesn't even have a coolness factor. Now, if you
can rotate -into- the screen, -that- would be cool.
Last, but by no means least -- CORBA as the communications layer???? And I thought I could be
stupid, at times. CORBA is a wash-out, due to too many corporations wanting to have
proprietary extensions to make it usable. It would have been a great technology, but either you
use the standard and have a gazillion lines of code to work round the limitations, OR you
"enhance" the standard, making it impossible for other systems to talk with it.
Also, with CORBA, the overheads are VAST. X is bad enough, but CORBA is a nightmare. One of the
important considerations in a system like this is who will use it. If you're talking home users,
then you need a protocol with as close to zero overhead as possible, whilst still allowing as much
flexibility & dynamicism as possible. CORBA doesn't cut it, either way.
You have some valid points about acceptance, but I think your complaints about Corba and OpenGL are based on prejudice and FUD than facts. Did you actually read any article about Berlin before commenting? I understand that first impression might be "those are slow", but the story doesn't (have to) end there.
It has already been said by n+1 people here that not only can OpenGL easily do 2D too (degenerate case of 3D), but that it may actually be faster; not because it's inherently faster but because gfx card makers have lately concentrated on 3D acceleration, and many advanced features (from basic texture mapping to transparency) are only available via 3D rendering. Thus, it need not be slower to use OpenGL. It might be faster, but what is reasonably sure is it'll be fast enough (ie. not order of magnitude slower). Another thing that helps is that h/w acceleration is easier to use with higher-level rendering requests (that Berlin uses, see below).
As to Corba; whether implementation is in the order of virtual method call (in local app/server case) or 10 times slower is not as relevant as with X-windows because the atomic operations being sent are much higher-level (read: bigger) on Berlin. That's what is on their FAQ; you don't draw bits on screen, you more likely transform more complicated (vector) graphics objects. Much of the stuff can also be made on server-side, thanks to integrated toolkit, removing the need to use Corba at all for much of the stuff X-protocol would need to use messaging.
Re:Berlin is a nice concept... (Score:2)
Re:Berlin is a nice concept... (Score:2)
Re:Berlin is a nice concept... (Score:2)
>>>>>>>>>>
A) First, all the gee-wiz features in MacOS-X and the new Linux WMs (except EVAS) are software accelerated. THAT'S slow.
B) This is hardware accelerated, courtesy of OpenGL. Transparency, for example, is painful in 2D cards (since its done in software) but OpenGL cards are built to handle this. Trust me, if a run of the mill TNT-1 can handle Carmack's love creations, it'll have no trouble handling a simple (or complex) desktop.
Re:Berlin is a nice concept... (Score:2)
No. KDE `gee whiz' (which I read as: usability - I like to be albe to read letters on screen - YMMV) done in XRender, which is hardware accelerated in almost every instance. GNOME 2.0 will also do a whole bunch of cute XRender stuff.
EVAS is something two people will use precisely because it uses a nonstandard method of rendering graphics that sends crap down the wire.
Re:Berlin is a nice concept... (Score:2)
No. KDE `gee whiz' (which I read as: usability - I like to be albe to read letters on screen - YMMV) done in XRender, which is hardware accelerated in almost every instance. GNOME 2.0 will also do a whole bunch of cute XRender stuff.
>>>>>>>>>
However, many more apps have accelerated OpenGL drivers than XRender drivers.
EVAS is something two people will use precisely because it uses a nonstandard method of rendering graphics that sends crap down the wire
>>>>>>>>>>
Sorry to break this to ya, but XRender is the non-standard method. OpenGL is a much more established (and supported!) standard, plus it does a lot more than XRender.
Re:Berlin is a nice concept... (Score:2)
OpenGL is a much more established (and supported!) standard, plus it does a lot more than XRender.
Again, flat difference of opinion. I disagrre with you. Xrender does things like text the way they were always done with a few improvements (ie, rgb becomes rgba).
Resolution Independence (Score:4, Insightful)
Some of the advantages touted for Berlin vs. X actually sound like disadvantages to me. Consider:
In other words, Berlin takes the Mac approach of taking UI decisions away from app developers. Themes, schmemes, that's not real choice. Any time you add flexibility you create opportunities for both inconsistency and innovation; they're two sides of the same coin. When you take decisions away from people you reduce flexibility, gaining the advantage of consistency at the expense of stifling creativity.
Here's another example:
Thank you very much for deciding that for me. Maybe I want to free up screen real estate by switching to a higher resolution. Maybe I want all those annoying little dialog boxes to shrink so I have more room for that big image window, which I can resize and zoom in/out just fine without your help, but now you've scaled them right back up so they're in the way again.
OK, maybe that's overstating the case a bit. The point remains, though, that they have strong assumed that there's one "right way" to do things. Even Windows lets you specify lots of things in either pixels or inches (or centimeters, maybe - I don't remember). As it turns out very few applications take advantage of that, but at least they have the choice instead of being told which method to use.
I don't think Berlin's bad. I don't even think they've made bad decisions on the aspects I've mentioned. I just wouldn't go touting them as advantages vs. X when they might just as easily be considered neutral or negative.
Re:Resolution Independence (Score:1)
I'm sure you can make things whatever size you want be it in the form of a little slidder to change the size of everything or just lying and saying you have a monitor twice as big as it really is.
Re:Resolution Independence (Score:5, Interesting)
Some of the advantages touted for Berlin vs. X actually sound like disadvantages to me.... In other words, Berlin takes the Mac approach of taking UI decisions away from app developers.
There is a reason the Mac is considered a good user interface and all X Window UI's bad. Funny how that works.
Seriously, though, if nothing else, a user experience must be consistent. All X Window UI's are nothing close to consistent. Windows is at least somewhat consistent. The Mac, of course, deals best with consistency.
Re:Resolution Independence (Score:2)
Abstraction of UI elements (Score:2, Insightful)
Not really true. I want "File" to ALWAYS have the same minimum components every time no matter what app it is: open, close, new, etc. There is no valid reason to dick with this. As much as possible, interfaces SHOULD be consistent to MINIMIZE the learning curve.
I agree that some standards are good. However, your widget set has to build in customizability. Some users like the menus at the top of the screen (Mac), at the top of a window (Windows, OS/2), or at the bottom of a window (Newton). Apps should see "this function creates a Menu Bar Or Tool Bar" in the API and leave the physical appearance of the menu bar to the widget set's theme engine. Same with pop-up menus: some users like ring-shaped popups; others like rectangular ones. Some users like their large virtual desktop to be four screens wide with wraparound and one screen tall, while others prefer two screens by two screens with no wrapping.
The point is that the UI should present the application with a set of abstract widgets (menu, window, etc.) and leave their presentation up to the theme, a strategh which in theory would also allow for specialized themes that work with alternative input and output devices for those with disabilities. Does this remind you any of W3C's goals in separating presentation from structure by deprecating HTML's physical markup in favor of CSS?
Re:Uhh, no. (Score:2)
Most UI experts. The couple of idiosyncrasies you mention are not in fact UI problems. As others have mentioned, they are probably not even problems at all. Nevertheless, I never claimed the Mac OS UI was perfect.
Not to mention that having only one mouse button severely limits the usefulness of the device.
Funny, I use Mac OS and I have two mouse buttons and they work just fine. And they do exactly what you would expect. Just because Apple sells machines with one mouse button does not mean that the OS is a one mouse button OS.
People who "consider" the Mac interface to be better don't really understand human dynamics.
You mean like usability engineers? What UI is better than the Mac UI from a usability perspective and what experts back up your opinion?
Re:Resolution Independence (Score:1)
That's just the point: you shouldn't have to switch to a higher resolution to shrink the dialog boxes. If you want the dialog boxes to be smaller, the GUI should give you an option to do this without increasing the screen resolution. Similar, you should be able to make text appear larger without dropping to 800x600.
Think of how Windows lets you choose between 'Large fonts' and 'Small fonts', then pretend that they got it right so you don't have to reboot the computer whenever you switch, and you'll get the rough idea.
Re:Resolution Independence (Score:2)
Yes, perhaps it should provide such an option. Does it? Should/does it apply globally, or can you set it differently per-application? Per-dialog? Is it as flexible as .Xresources, which lets you set things this way for emacs and that way for everything else? How would that relate to themes?
It's all very well to talk about "should" but in the end it doesn't count for much if the default behavior is annoying.
Re:Resolution Independence (Score:5, Informative)
No. You want to free up screen real estate by switching to a smaller appearance setting. You want to make things appear in more detail by switching to a higher resolution. That's two different settings instead of just one, so this actually gives you more flexibility. At least if the Berlin developers got that right, I haven't looked at how it actually works yet.
Running a lower resolution to "zoom into your desktop" is like slowing down your processor to watch a movie in slow motion. The idea is just wrong. Time and performance are two different (but related) things, and so are size and resolution.
Re:Resolution Independence (Score:2)
1) My desktop doesnt hold too many fixed pixel width apps visible at 640x480. By switching to 1280x1024, it contains many more of those applications visible at any given time. Berlin would negate this by scaling applications back up to "6in across" instead of staying at "180pixels"
2) He wasnt talking about zooming in by lowering his resolution back down (to 640x480). He was talking about in a paint application, and being able to zoom in/out of the image.
His point is 100% completely valid, I have the same concerns. You just missed it is all.
Thanks for playing though.
CyberKnet
Re:Resolution Independence (Score:2)
You're the one who missed it: Berlin doesn't work in either units of pixels or centimeters. It works in abstract length units which default to being centimeters. If the window manager is sanely designed, it will let you change the scale factor however you want. If you want a Netscape window that is scaled down to the size of a postage stamp with 3-pixel-tall fonts, just shrink it. Want another Netscape on the same screen to be normal size? No problem.
This is unspeakably nice. Neither X nor Win32 handle scaling properly. (And don't say Windows does it right because you can choose font sizes. If you choose a good font size for a 1600x1200 display, it will warn you that nothing will work and that you are completely fucked.)
And here are some lovely parting gifts for you too.
Re:Resolution Independence (Score:2)
No, it wouldn't. If you wanted everything to take up less screen space, you could just dial down the scaling. Moving away from explicit pixel-based graphics allows you to do that sort of thing.
Things *wouldnt* end up looking more detailed at a higher resolution. They would be scaled bigger, and still look big and chunky.
They would take up the same number of centimeters on the screen, so they would be no bigger or smaller than before. Since they are based on vectors instead of rasters, they wouldn't look jaggy; in fact they would look smoother than they did at lower resolution, since the pixels that make them up are smaller relative to the size of the objects.
Re:Resolution Independence (Score:2)
No, you missed it. Look at your printer... if it has a resolution of 600dpi, and you change the setting to 300dpi in the driver, what happens? Everything is four times as large? Nope, things just appear in a worse quality. You also can't fit more text on a page by increasing the resolution to 1200dpi, if you want to fit more text on a page, you'll have to use a smaller font size. This shouldn't be any different for a screen.
That's correct, but by changing the size setting (as I said, there would be two settings), you can just make the app smaller if you want. The nice thing is, you can even make it that small at 640x480 (it might not look that good, though). Imagine making a screenshot of your application, sizing it down in a picture editor, than putting it back on your desktop and continue to work.
Re:Resolution Independence (Score:4, Insightful)
...
And giving it to the users.
Re:Resolution Independence (Score:2)
Wrong. Themes can't be that detailed, to cover all the decisions the app developer makes. Even if they could, they'd be so incredibly large and complicated that nobody could create new ones. I know themes and skins are the height of fashion right now, but they're no substitute for UI flexibility.
Re:Resolution Independence (Score:2)
Re:Resolution Independence (Score:2)
They don't, and that's the point. The standard excuse when it's pointed out Berlin gives app developers fewer options seems to be that those options are being given to the users instead, in the form of themes. But themes don't cut it. They don't offer the same sorts of flexibility that the developer needs to create the right interface for a particular application. Sure, many (most?) developers abuse that responsibility instead of using it responsibly, but - as I said - you can't deny them that flexibility without a downside.
When did "people can't handle flexibility, we should abandon flexibility in favor of conformity" become the mantra around here? That's Windows thinking. It's totally opposite to the philosophy that underlies UNIX in general or Linux in particular. Do you think all of your favorite X-window-manager toys - transparent and oddly-shaped title bars, dockable apps, virtual desktops just the way you like them - are going to survive a transition to Berlin? Think again. Because developers no longer have such flexibility, the environment you'd get with Berlin will be oh so spartan and sterile. But at least it'll be consistent, so I guess it's OK, right? Have you all tired of freedom so soon?
Re:Resolution Independence (Score:2)
You and I know that if we let people standardise on just one tool kit they will pick the most butt ugly, bug ridden piece of trash they can find [opengroup.org]. But that's the exact thing that be-fan would love.
Quite frankly, I think Apple's user interface is overrated. Sure, it's not as bad as windows but if that's your measure of the quality of a user interface then just about everyone is Jakob Nielsen.
Give developers freedom and don't use the ugly apps. It's not that complicated...
Re:Resolution Independence (Score:2)
>>>>>>>>
Entirely true. However, nobody said that themes were the only thing. There is configurability too. With the combination of the two, you get a good deal of power for the user. Also, nobody says that the toolkit must be the same in every case. Since Berlin is interfaced through Corba, it is entirely plausible that somebody would rip out the standard toolkit and implement a different one in its place. All app would still work, since the CORBA interface would remain unchanged.
They don't offer the same sorts of flexibility that the developer needs to create the right interface for a particular application. Sure, many (most?) developers abuse that responsibility instead of using it responsibly, but - as I said - you can't deny them that flexibility without a downside.
>>>>>>>
Are you honestly deluded enough to believe that application developers can USE all that flexibility? If that was true, Linux would be full of incredible great desktop applications. Its not. The problem with your thinking is that you want to give all the power to the developers, assuming that they somehow know more than the users. Besides, if a particular interface really is RIGHT for a particular application, nothing prevents that developer from implementing it himself. As long as you can still do raw drawing and get raw access to the interface devices, you can make whatever type of interface you want. True, that makes it harder for a developer to make a custom interface, but that's probably a good thing. If the app really needs that interface, then they'll go the extra mile to implement it. If it really doesn't, there is no point in breaking the standardization, now is there?
When did "people can't handle flexibility, we should abandon flexibility in favor of conformity" become the mantra around here?
>>>>>>>>
Its called society. Look outside the window. Conformity allows the world to run smoothly. I'm not saying that you should always conform, but you'd better have a good reason not to.
That's Windows thinking. It's totally opposite to the philosophy that underlies UNIX in general or Linux in particular.
>>>>>>>>>>
BS. UNIX is EXTREMELY standardized. Take the whole text-stream paradigm. It allows all apps to work together, no matter what they do. You think UNIX's CLI would have achieved the same level of usefulness if every developer had decided to use a different "but, it fits my app better!" method of exchanging text data?
Do you think all of your favorite X-window-manager toys - transparent and oddly-shaped title bars, dockable apps, virtual desktops just the way you like them - are going to survive a transition to Berlin?
>>>>>>>>
Yes, as long as the grognards want them, they'll get ported. However, many people DON'T like transparent, oddly-shaped title bars. Many people LIKE coherence and conformity. With Berlin, the rest of us aren't forced to pay for your weird sense of asthetics.
Think again. Because developers no longer have such flexibility, the environment you'd get with Berlin will be oh so spartan and sterile. But at least it'll be consistent, so I guess it's OK, right? Have you all tired of freedom so soon?
>>>>>>>>
Yes, that's why Windows apps have NO personality and inefficient interfaces. 3D Studio, Fireworks, Dreamweaver, Poser, Truespace, and Bryce are really just figments of my imaginiation and don't really exist.
Who's choice? (was Re:Resolution Independence) (Score:5, Insightful)
It is real choice, just not so much on the part of the developer. This approach takes the choice away from the developer and hands it to the user (in the form of theming). The user gets consistency and choice - isn't that who is supposed to be controlling his/her own desktop?
Personally, as a developer, I don't want the choice of look at feel. I want to choose an API and I want to design the data bindings to UI components, and a default layout for the UI. I want the user to worry about the rest; how the pretty widgets look, key bindings, even how the UI is layed out if he/she wishes to go that far. I don't want my apps to stand out as being visually different any more than needed. There is absolutely no logical reason for one button to look and behave differently from any other button.
Re:Resolution Independence (Score:2)
>>>>>>>>>
Yea, and it gives the decision back to the user! I like the Blue Metal theme, but my Athena apps don't look like that! And the KDE Blue Metal theme is a little different and the buttons look wierd. I don't give a rat's ass what the developer thinks looks nice, I want it the way I want it!
Themes, schmemes, that's not real choice. Any time you add flexibility you create opportunities for both inconsistency and innovation; they're two sides of the same coin.
>>>>>
Honestly, most developers aren't smart enough to be innovative. In a one-toolkit system, there is still room for innovation, since nothing prevents you from adding your own widgets. For example, TrueSpace and Bryce have pretty imaginative interfaces. True, it's more work to implement custom widgets, but that's a good thing. That way, people who really have good ideas can work a little harder to impelement them, while people who are just lazy (and would have created inconsistant rather than innovative interfaces otherwise) can just use the default. For desktop OSs, its probably good to dictate policy this way because people really don't want inconsistancy without really tangible benifets.
the size of an object on a 15 inch screen is the same as its size on paper, which is the size of an object on the big viewscreen at NASA...users would be compelled to use the highest resolution/color depth possible for the visual quality rather than for the space on their desktop.
Thank you very much for deciding that for me. Maybe I want to free up screen real estate by switching to a higher resolution.
>>>>>>>>
Dude, its called a third generation graphics layer. Anything that uses virtual coordinates has this "problem." If you want to do it differently, just change the mapping (its very easy in OpenGL).
OK, maybe that's overstating the case a bit.
>>>>>>>
What case
The point remains, though, that they have strong assumed that there's one "right way" to do things. Even Windows lets you specify lots of things in either pixels or inches (or centimeters, maybe - I don't remember).
>>>>>>>>>
If its in inches, its the same thing as using virtual coordinates. Pixels are an ancient relic that really need to be discarded. Font-sensitive GUI layout libraries all the way baby.
As it turns out very few applications take advantage of that, but at least they have the choice instead of being told which method to use.
>>>>>>>>>>
And if an app really does have the need to change a default, they can do it, they just have to do a little more work. You really have to ask yourself, does my app really need to make something 3.1" when 3.0" is the default? If it does, then go ahead and override the defaults. If it doesn't, just go with the flow. In a system that doesn't impelment some policy, you have people using 3.5" and 3.52" 9cm, just because the developer liked it better, not because of any real merit. The mere fact that most people consider KDE and GNOME to be functionaly equal attests to the fact that (in that case) competition doesn't make things better, just different.
Re:Resolution Independence (Score:3, Insightful)
Second, I don't see how anyone one is forcing you to do anything. At least I am not aware of any kind of license agreement forbidding you to resize your applications and dialogue boxes. The point of me saying that about resolution independence was to show where the Berlin desktop will probably be heading. For omnipotent being's sake, even PNG and CSS have absolute sizes in their specifications. So it makes sense for this to show up at the desktop level. How can a desktop make sense of a PNG image that is 5 cm across if it doesn't have any useful conversion from pixels to centimeters? And lets say you have two monitors showing the same PNG image but at different screen sizes and resolutions, should both images appear as the same size?
Third, conceptually there is a difference between resizing (what you do when you resize a window and the window contents realign themselves to fit in the window) and scaling which can be used to get your extra screen real estate. By when you scale, you need to scale by a factor. That is, you need to scale by twice or one-third the original. But the problem here is what the original size is. Is it expressed in resolution dependent terms (pixels) or resolution independent terms (centimeters, inches)?
Fourth, the consistant UI theme in the article is yet in a plan-to-do stage, I believe. While it seems to be the intention of the Berlin developers to have this in their design, the vehicle for this "taskets" which is like a meta-widget that allows the application to ask what from the user rather than how. An example is on the wiki (http://www2.berlin-consortium.org/wiki/html/Berl
But the main point I want to get at is that changing the setting of a system always require more advanced users. I think the idea of a desktop being consistant and nice by default is a good idea. The more advanced user is free to screw it all up, if you like.
Best regards,
Kevin Holmes
Re:Resolution Independence (Score:5, Interesting)
An application demanding that a double-right-click behave in a particular fashion is only an innovation in the Microsoft sense of the term.
Berlin's message is this: application software micromanaging the user interface is a dead end, and rude too. Introducing a level of indirection gives the user control by plugging and unplugging toolkits to do things the app programmer never thought of. If the UI toolkit becomes scriptable, every well-formed Berlin client program becomes scriptable. If the UI toolkit supports blind users' I/O devices, every well-formed Berlin client supports blind users' I/O devices.If you want to innovate, then innovate a new toolkit. I suspect you're less interested in innovation than shoving your ideas down the users' throats.
-jhp
Re:Resolution Independence (Score:2)
Aqua++ (Score:1)
But Aqua/Cocoa may well be successful because it is quite simple and uniform, always primarily focusing on usability, functionality and user experience. To be really successful Berlin must both be simple to use and configure, yet support powerful functions.
Did anyone find what hardware is required to test it on an i386-debain machine?
sure... (Score:1, Funny)
it's there! trust us!
What about a light replacement for X? (Score:1)
So now that Berlin is a heavyweight replacement for X, with obviously different goals, what else is out there that's lightweight?
I was thinking about this when trying to run SuSE 7.2/KDE on an old P133 laptop with 32MB of RAM. It'd be great to have a fully functioning modern Linux on this box, but it couldn't handle the graphics overhead (it ran, but way slow). If there were a graphics system that didn't tax the system any more than Windows' does, this poor machine might not be put out to router pasture or some other text-only use.
Sounds a lot like Apple's Quartz (Score:2, Informative)
I mean, resolution independance and the fact that it is not pixel based. It feels like it's using vectorial representation of the graphics to be displayed.
Unicode support, that is a big plus and one of the few real advantages of Mac OS X. Integrating this is a good idea. Even if unicode has it's flaws, it's still better.
And of course alpha blending... this is the first thing you really notice in Mac OS X's Quartz and it's one of the major features of Berlin.
I must say, these are good features, and a number of other nice ones. It's good news that graphic engines similar to Mac OS X's are now (will be) available in open source!
Re:Sounds a lot like Apple's Quartz (Score:1)
Still has a long way to go (Score:1)
That said, Berlin looks like a nice, promising idea, but the feeling I get from their web site and the screenshots I've seen is that this is still a fledgling project that is getting all excited about the wrong things. It seems to me that the developers are far more excited about 3d rotating windows and alpha channel transparencies than actually producing a functional, reliable graphical user interface. Much of that stuff is good and I know a lot of X users have been looking for features like these for a while, but if this project is to gather any momentum, they need to concentrate on more important issues like speed and stability. One thing I would like to see them do, for example is find a more efficient solution to X's complex network client/server layers which I believe are wonderful but have a significant speed cost. When that happens, I'll start thinking of trying it out on my PC.
An ambitious project (Score:2)
Given this, it seems likely that a usable release is at least another ten years off, and then don't forget the five or ten years it's going to take for common applications to be ported over and kinks to be worked out.
In other words, this truly is the "GUI of the future"...the very distant future.
Without Support *DEs, Why Bother? (Score:1)
Re:s/\*DE/Toolkits/g (Score:2)
The interesting question is, just how easy would it really be to move Qt to Berlin? Berlin is designed around a model where all of the drawing and interaction code for widgets are hosted inside the display server. I haven't seen any talk of a Java VM like system for safely hosting downloadable code, so I'm not sure how well that actually works in practice, but it seems like there would be a whole lot more structural differences for a widget set written to use Berlin than just what rendering layer it's layered on top of.
Of course, I haven't done any Qt coding.. perhaps Qt is sufficiently abstract that such a very different underpinnings could be put in place. It doesn't at all seem like an easy or obvious conclusion to make, though.
X is extensible! (Score:2)
I thought it was sort of interesting that many of the X vs Berlin features actually said X does this too. That doesn't make it very much of a "vs" argument.
The key thing that many people seem to forget is that X has a nice extension mechanism. Everything Berlin is doing could be done as extensions to X. The alpha compositing is already being done via the RENDER extension. The Resize and Rotate extension will allow you to switch via mode and rotate on the fly. You could do the rest as extensions if you wanted.
The big advantage of extending X is that you don't throw the baby out with the bath water. All the old applications still work. Applications can decide which extensions to use when they are ready. This makes it easy to see what works and what doesn't and to let each application progress at it's own pace.
Re:X is extensible! (Score:2)
Except that is isn't a layer. It's integrated into the X server just like any other protocol operation. They cost you nothing more than any other X call.
Try doing a little research before you anonymously post sarcastic remarks.
Re:X is extensible! (Score:2)
Extensions really aren't as cool as they're made out to be.
A) They aren't uniform. Say you add an extension for a high-speed way to access the display. All your old apps use the old (slow) method, and only a few new apps use the new, fast method. That sucks.
B) They duplicate functionality. In the above example, you now have 2 methods of accessing the display, when only one is needed. That sucks.
X has a perfect example right now. You have a standard font renderer, and you have a nice AA render extension. Not only do you now have to change the code in all your apps to use the new extension (or more likely, just live with un-AA text in some apps), but you have two sets of APIs that do the exact same thing! Its like Windows and its CreateWindow, CreateWindowEx, and CreateWindow16ThunkHack API.
A few bits about Berlin (Score:5, Insightful)
I see a lot of things being thrown around, without any real understanding (although anyone from the Berlin project is welcome to smack me around). Here are some clarifications:
- OpenGL.
- Toolkits.
- to make X programming less painful. OK, in the future, there could be some sort of Xtoolkit->Berlin wrapper that would 'port' over applications with a recompile. But an important but unheralded aspect of Berlin is that it is designed to present a consistent programming interface that is not painful to work with.
- to give consistent looknfeel to apps. Berlin would do this at the server level. Berlin uses a single consistent set of widgets (a 'toolkit') to render the entire screen. That is why they talk about universal theming -- it would be like in installing GTK and then having the ability to switch all your applications to use GTK on the fly. Want QT? Install QT. Flip a switch. Now all you apps render with QT.
- to integrate with a desktop. Berlin doesn't deal with this, but it could be easily extended.
- Corba.
.. sometimes many orders of magnitude fewer commands.
Well, that is all I can think of for now. But I think Berlin is one of the coolest projects in a long while, and has the ability to transform Linux just like Aqua/Quartz did for BSD.Why use OpenGL? Well, according to the FAQ, it is because it is a stable API that already does a bunch of what they want. But that is missing the point -- Berlin is not OpneGL-only. OpenGL is one of the several available toolkits used by the server to render the app. In fact, the most advanced toolkit currently bundled with Berlin doesn't use OpenGL at all.
People here are talking about QT, GTK, etc. The purpose of these toolkits is
Berlin uses corba. Yes. Corba can be slow. Yes. But the trick is to see how they are using corba. For local operation, the call to the orb can be highly optimized... Just a couple of pointer jumps. (This is not much different than with X, where it uses TCP/IP to communicate with internally, even on a standalone machine). For remote operation, the corba orb shouldn't be the bottleneck the network should. But using corba gives the option to redirect displays, just like X.
The difference is that, whereas X sends thousands (or millions!) of directions over the wire saying 'Paint pixel(x,y) green', Berlin says something like 'Put a button a this point in the screen graph' (where the screen graph is part of the Berlin prgramming model). The server has enough smarts to draw and position the button itself. Hence, Berlin has the possibility of being faster than X, even with Corba, because it has to give fewer commands to the server
CORBA vs X Sockets? (Score:1)
Also, it would seem to me that the way X handles itself would be suboptimal speed-wise for a single machine, making Berlin more suitable for the standard desktop, yet not for a client-server pair operating over a network, in which case X would excel.
web site lovee from hemos... (Score:1)
Are you kidding? I can't tell...I hope so, because these two things, as well as the incredibly poor navigation, fonts and colors, make this a horrid website. Almost as bad as this one.
From the site:
1.:>>"<!-- This document was created with Latte version 2.1 -->
<!-- For information on Latte, see http://www.latte.org/ -->"
2.:>"This is just a filler page for now; check out the links on the left.
Last modified: Sat Apr 29 10:48:25 2000 UTC"
pathetic...
Just make X(Free86) better, prettier and easier. (Score:3, Interesting)
I don't think there's a need for an replacement for X. It's great, and it works. But, most of the time I deal with X, I find it confusing, difficult to install and really hard to handle. First of all, it needs good setup tools. Correct me if I'm wrong, but I haven't found any good, complete ones for XFree86 4.1.0. There's xf86cfg but that didn't really work, uses the highest screen res it finds which makes it flicker and almost unreadable and is far from complete. It doesn't cover all features of X. There's XFsetup, but the readme said that it wasn't compatible with 4.1.0. There's of course xf86config but that's a joke in terms of usability. And the config generated by XFree86 -configure - a config file doesn't tell me what I have to do, it doesn't help me in any way.
Setting up DRI must be easy. Like copy binary, tell which driver to load. But, I have to recompile stuff and get Glide3 for Voodoos. That's annoying.
X needs better mouse support, I think it's just ridiculus that I have to edit config files just to get my mouse wheel working. And for the mouse pointers, where's color, alpha blending, shadows and whatso ever?
My last point is that X has all this stuff for exporting a screen over a network included. Much of the (great) functionalty of X is not used on home computers because people usually don't need it. What about a cut down version of XFree86, streamlined, compact with a decent setup tool that uses NCurses? That would, in my opinion, be sufficent to eliminate the need for things like Berlin. I respect those peoples work but I think they shouldn't "re-invent the wheel", like they taught me in my OOP class :-)
Did this happen to anyone else? (Score:5, Insightful)
Re:Did this happen to anyone else? (Score:4, Insightful)
slashdot links to browser forkbomb.
cute.
Me, I had to reboot; I was unable to get control before the windows had spawned to infinity, and beyond!
Re:Did this happen to anyone else? (Score:2)
Re:That and super-wide browser windows... (Score:2)
If they suddenly develop angst against an OS we could maybe end up with fun little anti-BSD or anti-*nix bombs? This doesn't really inspire my trust.
Yes, I'm pissed off.
Berlin, eh? (Score:2, Funny)
Berlin on FreeBSD (Score:2)
Re:Berlin on FreeBSD [ corrected link ] (Score:2)
What's wrong with competition?! (Score:5, Insightful)
I'm suprised that so many people are not only unsupportive (which is sort of reasonable, if you don't care you don't care), but that they go as far as being outright hostile.
These folks are trying to push the state of the art. You may think they're misguided, you may think they suck, but that doesn't invalidate what they're doing or who they are. They have their dreams and seem like they may just realize them. Who the fuck are any of you to insult them? At least they're trying something.
If X is a better system, it will still be here in spite of Berlin. I don't see why anyone is so threatened. Berlin could be a smash success without ever displacing a single X installation.
Also, competition is good
I'll never understand how some people who scream about civil liberty, free speech, intellectual property issues, and the rejection of old-world dogma/family-values-crap can still be so closed minded about competing open source technologies that they consider a threat to established traditional technology.
You'd think that the general Slashdot reading population would be more supportive of change.
Berlin vs. NeWS (Score:2)
I wonder if the Berlin designers are familiar with NeWS and could make a further comparison.
Re:Berlin vs. NeWS (Score:2)
The slow and crufty one which most people used was the "X11/NeWS" merge. This was a horrid mess where both the PostScript and X were implemented in paralell C code, and a low-lying renderer which was bloated with if's so that it could render pixel-accurate emulation of X11 and not break PostScript too badly (it still failed to fill any shape other than rectangles correctly). The attempts to make a NeWS toolkit were also seriously hurt by the need to have the windows reusable by X and the need to write all the horrors of an X window manager implementation in PostScript code. The PostScript interpreter was also slowed down quite a bit by peoples rabid insistance that it copy every single bug and misfeature of the Apple LaserWriter (too many people thought NeWS's only purpose was to preview documents before printing...)
They should have emulated X11 atop PostScript, but it was already know that Sun was killing NeWS so they were forced to do it this way so X11 performance was not hurt at all.
Of course the real reason it died was that Sun tried to sell it when there was an open-source (not free though, a tape and license cost $120, although that cost was trivial) alternative.
Re:Wait a minute... (Score:4, Interesting)
> toolkits for a consisten user interface?
>
The X server is quite lightweight, but the clients are not: think at the number of toolkit you use simultaneously: Qt, GTK+, Tk, Lesstiff..
This is memory bloat!!
Worse, those toolkit has usually some troubles working with the others: cut-copy-paste problems sometimes, poor look&feel integration etc..
And think about communications between the client and the server:
- with X you have LOTS of very low level communications between the client and the server (draw a rectangle here, etc..).
Have you done XLib programming?
If no, you'd be surprised to see how many events the X server send to the clients..
- with Berlin, usually a client would use higher level primitives that the server which would manage: less bandwith usage, improved latency.
X main's advantage is that it works now, but I feel that Berlin's design is cleaner IMHO.
Re:Wait a minute... (Score:1)
Maybe this was a good idea back when Berlin was started, but nowadays... I dunno. 256MB of RAM is cheaper than a meal at a cheap restaurant.
Re:Wait a minute... (Score:1)
--jon
Re:Mac OS X already does this. (Score:2)
Re:directfb (Score:2)
Re:Apology (Score:2)
Not that it means much, but you lost at least one desktop with this. You'll never be on mine.
Re:I am not a big Windows lover ... (Score:2)
Your efforts in the development of a new windowing system may be groundbreaking -- good for you. X is rather stale. Unfortunately as you are learning right now breaking ground and having your development site totally open to the revision of passers-by may not be a good idea,
If the Internet has proven anything it has proven that if someone can be an ass and get away with it, chances are good they will be. This has happened since
Re:focus - mod up (Score:2)
Case in point - copy a URL, then go to a browser window and highlight over the old URL to paste the new one in. OOOPS! You just copied the old URL to the clipboard. What do you need to do? Either "open a new location" or position your mouse and hold DELETE.
Re:focus - mod up (Score:2)
It sounds a little bit from the other poster that perhaps KDE/Qt are going to do this as well.
The old X mechansim is actually equivalent to "drag&drop" but with the advantage that you can rearrange the windows in the middle of the drag. This makes the real problems with drag&drop become visible, this is what you are seeing. (it also points out the drag&drop is pretty powerful, seeing as X has survived for so long with only that, but that it is not sufficient for everything).
I do wish people would stop complaining that the mechanism sucks and then go on to complain that "X lacks drag&drop". I'm sorry, you are wrong, perhaps the mechanism sucks but that mechansim *IS* drag&drop!!!