Berlin Packages Released For Debian

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.

Comments

Re:Resolution Independence

[smack.addict]

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:Wait a minute...

[renoX]

> It's a combination windowing system with
> toolkits for a consisten user interface?
> ...and I thought X was bloated. No thanks, guys.

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:Resolution Independence

[marxmarv]

In other words, Berlin takes the Mac approach of taking UI decisions away from app developers

... and putting it into the hands of users where they belong. The user is more important than the whims of some clueless artiste who happens to have the time and the energy to bang some segfaulting piece of code together with artsy-fartsy skins and inconsistent mouse controls. Get off your high horse, little boy.

Any time you add flexibility you create opportunities for both inconsistency and innovation; they're two sides of the same coin.

The beauty of Berlin is that UI innovations can be applied systemwide because the application developer is forced to pull his head out of their ass and think in terms of abstract actions and the UI developer is limited to thinking in terms of right-double-clicks. This is a superior way to do real UI innovation (as opposed to developer self-aggrandizement), as new paradigms can be explored globally with the flick of a switch, evaluated on how and where they work best and worst, tweaked to improvement, and again.

An application demanding that a double-right-click behave in a particular fashion is only an innovation in the Microsoft sense of the term.

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.

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