Gnome 2.0 Alpha 1 Released

Dave H writes "The first pre-release of the GNOME 2 platform is now available! Find it at you can grab it from FTP.gnome.org It is of course a technology preview; note that it can't be installed alongside GNOME 1.x." There's some more information information posted on LinuxToday.

Comments

Love the warning

[wiredog]

WARNING: This release does not include anything of use to end
users.

That could be put on half or more of the stuff on my box.

Re:Love the warning

[Unknown Bovine Group]

Which raises the question: Why is slashdot posting ALPHA releases? all this will lead to is a couple months from now people will comment "Yeah I tried Gnome 3 and it sucked."

Re:Love the warning

[Menthos]

Gnome probably needs the users testing it out and giving feed back

True for the coming beta releases probably, but this is a platform alpha release and not intended for end users, as several people have already pointed out.

It's intended for developers that want to be able to port their applications to the GNOME2 platform (or develop new ones on GNOME2) more easily, that's all. There are very few actual end user applications that have already been ported. The panel is one of the few ones.

Re:Love the warning

[shaka]

According to The Register's article on the subject, the warning ("this release does not include anything of use to end users") "makes it consistent with all the previous versions of GNOME Desktop we've used."

I don't know what's wrong with the writer's (a mr Andrew Orlowski) brain, but the article is full to the brim with stupid and mean comments in the same league:

"working with GNOME software has always been fun, if ultimately fruitless"
"[Gnome's] great gift to the world has been to spur development of the older, more established rival KDE"
"A visiting Martian would surely conclude that the GNOME Project has served its purpose"
"[KDE is] probably two years ahead now"

Makes me wonder what he's trying to accomplish. What's the purpose for a big, widely recognized site such as The Register to sell ad space with mean, stupid and uninformed statements such as these?

Backward compability.

[Lussarn]

Does anybody know about backward compability?

I know a couple of widgets from gtk1.2 is deprecated, CList is one of them. But will gnome 2 also include gtk1.2 or only gtk2.0.

And, does deprecated in the gtk2.0 case mean "not there" or "could disapear in the future"?

Re:Backward compability.

[sporty]

In terms of api, it usually means its there for backwards compatability and should not be used anymore.

Re:Backward compability.

[Havoc Pennington]

GTK 1.2 and GTK 2 can be installed simultaneously, I would expect all distributions to do that for the forseeable future.

Deprecated means "will disappear in some future version, when not many people are using it anymore"

Re:Backward compability.

[flanker]

Doesn't deprecated mean "there's a better way to do this now -- don't use this any longer." With the understanding that it might be removed or gutted in the future?

Re:Backward compability.

[GauteL]

I've always interpreted it to be "please don't use this in any new applications, because we will remove it someday".

No new toys. :(

[acm]

This release does not include anything of use to end users. It is a technology preview release of the development platform only. It is also not yet fully parallel installable with GNOME 1.

Damn, KDE users are getting all sorts of new toys to play with, was hoping Gnome was gonna give me some too. :)

acm

Wow

[Anonymous Coward]

I didn't think GNOME2 would ever see the light of day. It should be interesting race between KDE3 and GNOME2.

Re:Wow

[Anonymous Coward]

interesting race between KDE3 and GNOME2

where's the race? KDE appears to be ahead 3 to 2.

I'm much more interested in seeing if RedHat (at 7.2) can catch Mandrake (up over 8 now)

Re:Wow

[ted_nugent]

You are a real penisbird if you think version numbers mean anything at all. Microsoft has put out less than 5 versions of any of their products bar office, and Mandrake seems to think every little gui update is deserving of a major (whole number) upgrade.

Sun and Slackware both changed their version numbering in the last couple of years to "catch up" with the competition.

Meanwhile, you have the OpenBSD style, which really doesn't make use of the software revisioning system at all. They simply count from 0 to 9, and then call the next release a "major" revision.

I prefer the ones that use decimals to differentiate between bug fixes, minor changes, and major feature overhauls without being in a hurry to get to the number 10.

Re:Wow

[ted_nugent]

The topic seemed halfway interesting at the time. Ah well.

Look is apparently the same

[greenfly]

From what I can gather from reading the comments to the Linux Today article, the main things that have changed and the underlying libraries, nothing that would really change the look. So apparently a screenshot of this wouldn't really look any different from a screenshot of gnome 1.x.

Re:Look is apparently the same

[GauteL]

Well... at least you have anti-aliased fonts and bidirectional font-support.

Re:Look is apparently the same

[assbarn]

Yeah, the look is pretty much the same. Probably the coolest is Pango, which is the text layout engine behind GTK+ 2.0. There are some older screenshots at pango.org.

Most of the advantage, though, is at the API level.

Re:Look is apparently the same

[Mike McTernan]

I hope it does look the same. You see, I am getting bored of more eyecandy on my desktop. Pretty as it all is, and great to look at, I find my system is becoming slower and slower as more pretty pictures seem to eat away at more memory/cpu.

I would far prefer Gnome (or KDE) releases to stop adding visible features and just try to make everything go faster, using less memory and be darned more efficient. And I am sure that this is not impossible since Windoze seems to radically outperform both KDE and Gnome in responsiviness (although I have no figures for this, I rarely have to wait while my system goes to swap space for a new window to appear under M$).

One of the nice features of the browser wars was the M$ spent lots of effort making IE have a faster rendering engine.

Maybe we need a similar window manager war on *speed*, not eyecandy?

ftp mirrors

[richie2000]

you can grab it from FTP.gnome.org

Guess again. :-)

http://www.gnome.org/mirrors/ftpmirrors.php3

ftp://ftp.twoguys.org/GNOME
ftp://ftp3.sourceforge.net/pub/mirrors/gnome
ftp://ftp.rpmfind.net/linux/gnome.org/
ftp://ftp.sourceforge.net/pub/mirrors/gnome/
ftp://ftp.cse.buffalo.edu/pub/Gnome
ftp://ftp.yggdrasil.com/mirrors/site/ftp.gnome.org /pub/GNOME/
ftp://ftp.sunet.se/pub/X11/GNOME/pre-gnome2/releas es/gnome-2.0-lib-alpha1/

Go fish! :-)

Re:ftp mirrors

[PygmySurfer]

I guess you didn't read the article, did you?

As soon as the mirrors update, you can get the release from:

ftp://ftp.gnome.org/pub/gnome/pre-gnome2/release s/ gnome-2.0-lib-alpha1

Re:ftp mirrors

[richie2000]

As soon as the mirrors update (which several of them already have) you won't have to get it from ftp.gnome.org (when I tried just before I posted the mirrors, it was deader than Elvis).

Re:ftp mirrors

[ncb]

I have it on good authority that ftp.twoguys.org is temporarily off the net.

However, ftp://ftp-linux.cc.gatech.edu/pub/linux/X11/gnome has mirror of the Gnome stuff, as well as some of the other bits that twoguys.org was mirroring. Please be gentle. :)

Re:ftp mirrors

[richie2000]

A couple of extra spaces crept in to a pair of the links there:

ftp.yggdrasil.com

and

ftp.sunet.se

should work better. Sorry. (No, I'm NOT just karma whoring! Am not!)

Re:ftp mirrors

[maswan]

Well... I made a better guess of where to find it on ftp.gnome.org and I found it. We also added some symlinks to make the published url work.

What should have been posted:

http://download.gnome.org

Or if people want it from ftp.gnome.org (which really is just another mirror):

http://ftp.gnome.org/pub/GNOME/pre-gnome2/releas es /gnome-2.0-lib-alpha1/

Or ftp:// for those that still use that. http is a much nicer protocol from our point of view.

/Mattias Wadenstein - Admin of ftp.acc.umu.se aka ftp.gnome.org

Re:ftp mirrors

[richie2000]

Oh, you prefer tucows? ;-)

Re:ftp mirrors

[Alan]

'es not dead! He's resting!

Re:Wow!

[Anonymous Coward]

All you need to get then is a mature OS gor your GUI.

after you check out gnome2a1, check out kde3a1

[Anonymous Coward]

It will come out on this friday:

Date: Tue, 2 Oct 2001 17:22:16 +0200
From: Dirk Mueller

I delay alpha1 release until Friday to give us more time to fix and verify the recent regressions in KIO and khtml.

Also, there will be a kde 2.2.2 release soon, check http://developer.kde.org/development-versions/kde- 2.2.2-release-plan.html

Re:after you check out gnome2a1, check out kde3a1

[diamondc]

.. and of course this has EVERYTHING to do with gnome 2..

Re:after you check out gnome2a1, check out kde3a1

[Anonymous Coward]

Who the fuck cares, just because there's an offtopic moderation choice, doesn't mean people have to use it. I and other people are interested in the link and that's all that matters, I don't exactly see any kde3 articles being posted recently, I think this person was justified in posting.

I love catching these kind of moderators in metamod. I hardly ever give anyone fair for modding someone down unless the person was obviously a troll. I usually leave it be, and if it's anyway iffy on the moderation I'll mark it unfair. Don't like this? Then fucking stop modding people down! Let them post at 1, just don't mod em up.

It pisses me off when people vote down a perfectly valid comment that has to do along the same lines as the story, just because it's not exactly on topic. Which is why I'm posting this as AC. Because I'd probably instantly moderated down to -1 offtopic (which I am, but hey). Normally I wouldn't care, but that affects my normal account and what I can post at.

Re:after you check out gnome2a1, check out kde3a1

[diamondc]

what the fuck!? taco creams in his panties over konqueror and kde.. i think gnome vs kde stories are about even, now a days.

Re:after you check out gnome2a1, check out kde3a1

[Mandelbrute]

.. and of course this has EVERYTHING to do with gnome 2..

Of course it does - it's only version 2 to play catch up with KDE version numbers, silly really.

Anyone why thought that gnome 1.0 was called that because it was stable (in was more unstable than many earlier releases) was sadly deluded. Lets keep the silly politics out of *nix.

Re:after you check out gnome2a1, check out kde3a1

[Menthos]

If it was only to play catchup with version numbers, it would have already been GNOME 3.0. But we don't do that game.

The truth is that this is a major change/rewrite of the platform, which requires a new major version number (2.0). It is nothing like the 1.x platform (and requires porting of applications), and labelling it 1.x.something would thus be very confusing.

Re:after you check out gnome2a1, check out kde3a1

[Knuckles]

Of course it does - it's only version 2 to play catch up with KDE version numbers, silly really

Bull. It's a major number change because they are breaking API compatibility (move to Gtk 2.0). And guess what - that's just what major number increments are for.

GNOME, a thought

[jd]

GNOME follows a nice concept, but suffers from one fatal flaw. X. X is a good system, in theory. It does many things other OS' GUIs only dream of. But it's over-designed and over-complex. So much so that AFAIK, of all the extensions, window managers, desktop environments, etc, out there, ROX is the only one to use X' own drag-and-drop system.

There are alternative GUIs out there, for Linux & Unix - Berlin for example - but they're either not compatiable with X applications and/or the X protocol, or they're not mature enough to be usable.

Most Unix manufacturers go the other way. The sample X implementation may be broken, in many ways, but it's still a good place to start. So they write their own version of X, either from scratch, or using the sample X tapes as a starting point. This certainly produces a faster implementation, but it still doesn't tackle the complexity issue, and none of these are Open Source or Free Software.

IMHO, what's needed is a GUI that'll do for X what RISC architectures did for processors. Produce a MUCH simpler underlying architecture, using layers to provide more and more complex functionality.

How does this relate to GNOME, since that's where I started? Easy. Either GNOME or KDE is in a key position to write this "layered X", since they are projects sufficiently wide in scope to understand where bottlenecks and bugs creep in. Nobody else really has that kind of breadth of information.

Wouldn't it be better to pile effort into Berlin? There are too many problems with the approach taken. CORBA is known for horrible overheads, for example, and the CORBA implementation used is, AFAIK, not the same as the one used by either GNOME or KDE, which means a combined effort will require extensive rewriting.

Re:GNOME, a thought

[adadun]

IMHO, what's needed is a GUI that'll do for X what RISC architectures did for processors. Produce a MUCH simpler underlying architecture, using layers to provide more and more complex functionality.

But isn't this exactly what X is? The X server is just a very dumb program that only knows how to draw lines, boxes, circles, and fonts. Everything else (i.e., the complexity) is layered on top of this through toolkits and window managers.

A GNOME program uses the simple GTK toolkit to provide the GUI. GTK uses Xlib which uses X. The complexity is layered.

Furthermore, neither the application nor the toolkit needs to worry about how the window is managed; this is taken care of by the window manager program. The window manager interacts with the user and moves, resizes, and iconifies windows. Layered complexity once again.

Re:GNOME, a thought

[Junks Jerzey]

But isn't this exactly what X is? The X server is just a very dumb program that only knows how to draw lines, boxes, circles, and fonts. Everything else (i.e., the complexity) is layered on top of this through toolkits and window managers.

Maybe so, but then the question is "Why the heck is X so _huge_." I mean, come on, if you're going to write hundreds of thousands of lines of code then they should do something more than provide something so minimal that you need to write another hundred thousand lines of code to get a halfway decent interface.

Re:GNOME, a thought

[starseeker]

Sounds like http://www.directfb.org/ may be what you're after. It doesn't have all of X's features by any means, but you might get there eventually.

However, my vote goes for Berlin, using the GGI project's stuff. They project is concentrated on getting it right. Here are the reasons I believe it is better to support the Berlin project:

1) Better design. They are focused on doing it right. So many systems are focused on getting it done fast, and so few seem to worry about high quality. Yes, Berlin is slow in coming. But when it is ready, whenever that may be, it will be truly awesome.

2) Corba is not necessarily a bad thing. It depends on how it is used. Yes a Corba call is relatively expensive, but for things like graphics over the network (where such things are likely to matter the most) the number of calls is sufficiently small that compared to the X method of blasting bits across the network, things should actually improve. Also, remember that machines will continue to get faster. Overhead will be worthwhile for more flexiblity and power. And when the machines are there, Berlin will not have to be rewritten to take advantage of them.

Yes a lot of applications would have to be rewritten. But considering the potential benefits, and the fact that an X compatability layer is not out of the question (since both systems are open that's a big plus) make the future transition tolerable. Apple rewrote their graphical desktop, and released OSX. We can do the same. Only we won't have to run an entire classic environment. It can work. And when it does, Berlin will begin to redefine the desktop computer experience.

Re:GNOME, a thought

[Havoc Pennington]

X is very simple, for a windowing system, it's not complex at all. Plus no one has to see that stuff,
it's always hidden behind toolkits.

X doesn't have a drag-and-drop system, so I don't see how ROX could use it. DND is built on top as a custom protocol (Xdnd) shared by GTK, Qt, etc.
I would guess that ROX just uses Xdnd, isn't it GTK-based?

Berlin is far more complex than X.

Porting GNOME/KDE to Berlin would be infeasible, but said infeasibility would have nothing to do with different CORBA implementations.

Most UNIX vendors do not reimplement X, they are basically using the open source implementation with some minor tweaks. The open source implementation (primarily maintained by XFree these days) is generally more robust than the proprietary ones.

Re:GNOME, a thought

[the_2nd_coming]

card drivers,

on a side note....the 20 second thing realy sucks, some people do not need 20 seconds to come up with a meaningful statment.

Re:GNOME, a thought

[Junks Jerzey]

card drivers,

No, it's more than that. The drivers are a relatively small part of the X codebase.

Re:GNOME, a thought

[rgmoore]

The idea that X is huge is greatly exaggerated. X itself isn't that large, but the total package looks much bigger than what you actually use because of the need for a zillion drivers. Yes, X could have a greatly simplified system that took much less code, but it would come at the expense of not being able to take advantage of the features in advanced graphics cards.

Re:GNOME, a thought

[Fnord]

From a pretty standard XFree86 4.1.0 installation.

drivers/modules/extensions (the contents of the X11R6/lib/modules directory): 21M

essential libraries (X clients can't function without them, toplevel X11R6/lib): 12M

X server binary itself: 1.5M

I'd say the drivers are a fair chunk of that.

Re:GNOME, a thought

[Spy Hunter]

Hee hee...

X-Windows: ...A mistake carried out to perfection. X-Windows: ...Dissatisfaction guaranteed. X-Windows: ...Don't get frustrated without it. X-Windows: ...Even your dog won't like it. X-Windows: ...Flaky and built to stay that way. X-Windows: ...Complex nonsolutions to simple nonproblems. X-Windows: ...Flawed beyond belief. X-Windows: ...Form follows malfunction. X-Windows: ...Garbage at your fingertips. X-Windows: ...Ignorance is our most important resource. X-Windows: ...It could be worse, but it'll take time. X-Windows: ...It could happen to you. X-Windows: ...Japan's secret weapon. X-Windows: ...Let it get in *your* way. X-Windows: ...Live the nightmare. X-Windows: ...More than enough rope. X-Windows: ...Never had it, never will. X-Windows: ...No hardware is safe. X-Windows: ...Power tools for power fools. X-Windows: ...Putting new limits on productivity. X-Windows: ...Simplicity made complex. X-Windows: ...The cutting edge of obsolescence. X-Windows: ...The art of incompetence. X-Windows: ...The defacto substandard. X-Windows: ...The first fully modular software disaster. X-Windows: ...The joke that kills. X-Windows: ...The problem for your problem. X-Windows: ...There's got to be a better way. X-Windows: ...Warn your friends about it. X-Windows: ...You'd better sit down. X-Windows: ...You'll envy the dead.

Copied from this page.

Re:GNOME, a thought

[Junks Jerzey]

essential libraries (X clients can't function without them, toplevel X11R6/lib): 12M

Think about that for a second. I have a *Lisp* system that takes less disk space than 12M. That is a huge, huge, amount of code. Sure, it is less than the drivers, but considering that X does very little, it is positively *enormous*.

Re:GNOME, a thought

[Panaflex]

I'm a newbie by standards around the X community, but alot of past work is devoted to old nasty things.. I've been lightly studying it for a few years, and have provided alpha ports for voodoo chips in the past.

X was written from a frame buffer perspective, and had accelleration hacked in over time, until Mark Vojkovich developed a standard for it(XAA, iirc). Attempts to go towards a rendering pipeline are embodied in the excellent work in Xrender.

The drivers are all fairly minimal bits of code.. most of them rely on other modules to initiate standard display setting, etc.

Alot of the "cruft" in X is related to the I18N sctick that got hacked into R5 I think. More cruft comes from PEX (The long-dead competing standard to OpenGL), the horrible toolkit helper implementation known at Xt, the keyboard and colormaps (scarry). The seldom used XPrint and Xnest servers as well.

More cruft comes in with several implementations of frame buffering code implementations (fb, cfb, cfb16, cfb24, cfb32, mfb) XAA kinof added a layer below these original "drivers."

Also, there is a huge amount of interface code from X to toolkits such at gtk/qt. This code is mostly hidden in the X11 libs. Do a stack trace when drawing a button in GTK with X11 debugging on.. it is truly horrid (13 deep to draw a clipped line), and doesn't show the server side of the mess.

Also, X has a very syncronous rectangle management core. The server keeps a list of all viewable rectangles and updates the whole list after every rectangle update. (Slow window movement, anyone?)

The biggest problem with X is simply the fact that toolkits have been religated to client apps, instead of being loadable into the X server.

Often times core X developers argue that this is dangerous, and even say that client side apps are faster and are fixed in their minds that X is the only way to go. A huge chunk of code goes for all the abstraction(known as mutilation by code in my book) and platform independance.

By no means should we throw away all that knowledge, but it should be second tier to providing native interfaces IMHO. Larger processor caches and faster asyncronous graphics chips somewhat nullify this argument these days, but the fact remains that X would be alot faster without it.

In fact you're starting to see X as simple a pixmap display device in the end. All the toolkits are basically just blasting pixmaps into the server, because X can't handle much of the advanced graphics now anyhow.

Yet sitting down to a windows box is proof positive that X is slow. I'd say that a good rewrite would do X a world of good. Let applications communicate in terms of toolkit messages (add widget tree instead of get gc, 8 drawlines, 3 fills, and get font, set font, get colormap, set colormap, draw text).

Of course this could be *maybe* be done with an X extension, but there are a few limitations of what X extensions can perform without going and adding more hacks into the X server.

All in all, X11 is a fine piece of work. The work done in the past 2 years is fantastic to say the least. All the linux companies and the freetype, mesa, and DRI developers really deserve a major pat on the back. I really enjoy the engineering talent and ingenuity displayed by the XFree team.

Cleaning up X, or rewriting it would be a major step in the right direction.

A funny thing about windows, is that they have the opposite problem. Applications are often times tied _too_ closly to the GDI, and often break between versions. No doubt, a few graphics intensive applications from win31 would break on win2k.

Pan

Re:GNOME, a thought

[Fnord]

>Think about that for a second. I have a *Lisp* >system that takes less disk space than 12M. That is >a huge, huge, amount of code. Sure, it is less than >the drivers, but considering that X does very >little, it is positively *enormous*.

Ok, but first of all this is stuff used by X clients, not the X server. These are things like libX11 and libXt, essential apis for X clients. Then you have the fact that alot of these apis have been pretty much depreciated for modern X programs. Gnome doesn't use Xintrinsics or the athena widgets. If you're running mostly gnome programs libXt and libXaw almost never loaded. Then there are things sitting around in there like libPEX. Don't even try to say you've used a PEX based program in the past 4 years. All in all, you're probably only going to use libX11, libICE, libSM, libXm and if you're using pretty antialiased fonts libXft and libXrender. Thats about four megs.

Re:GNOME, a thought

[be-fan]

Overhead will be worthwhile for more flexiblity and power. And when the machines are there, Berlin will not have to be rewritten to take advantage of them.
>>>>>>
Its that idea that makes Linux GUIs suck performance-wise. Power is rarely worth the tradeoff in speed and effieciency, since very little software ever exposes more power. Don't get fooled into equating features with power BTW. Power is being able to quickly do the work you need to do without the system getting in the way. Most of the stuff that these desktop environment developers think is power (network transparency, CORBA, etc) are really just mental masturbation and have little significance on the desktop.

Re:GNOME, a thought

[Ian Bicking]

Any idea how DirectFB relates to KGI (and/or GGI)?

It seems similar -- GGI uses KGI, where I suppose DirectFB uses the framebuffer. The advantage being, I suppose, that the framebuffer is included in the main kernel where KGI has always been a patch.

But the problem with the framebuffer is that it is so darn slow. Perhaps reasonable in hardware that doesn't have any graphics acceleration (like on a handheld), but not useful on normal computers. I don't know if there is any real effort to ever make the framebuffer any faster -- the very name seems to imply non-accelerated simplicity.

I think the path away from X involves factoring the pieces better -- maybe that can even save X, as Xlib isn't really the problem, it's all the other half-assed crap that goes with X.

Re:GNOME, a thought

[rice_burners_suck]

To answer your sig: "That thud you just heard was all the former BeOS users throwing their PC's out the window..."

If you want to talk about efficiency in GUIs, BeOS has an awesome graphical system. (I used R3 through R5.) Too bad the company fscked up so bad. Oh well. We all know the command line is where the real power is. (GUIs are nice on laptops though. It just seems more appropriate to run a GUI.) Sorry for the off-topic post.

Re:GNOME, a thought

[Wesley Felter]

DirectFB has graphics acceleration for several cards.

Re:GNOME, a thought

[renoX]

Basically you're saying that X should move to a higher level, no?

I agree and maybe you would be interested to have a look at Berlin.

See http://www.berlin-consortium.org

It is a work in progress not ready at all for use, but its design is interesting..
They didn't choose to evolve X but instead they use the Fresco framework for basis.

Re:GNOME, a thought

[Phill Hugo]

You sound like you know one or two things but calling "XNest" seldom used in the manner you do doesn't inspire confidence.

Xnest is great, its perhaps one of the best things about X. If you don't know why, you don't know X.

Re:GNOME, a thought

[be-fan]

So does QNX. Yea, it is bad that Be died. What really would have been cool would have been a mixture of the Linux kernel (which has gotten pretty nice these days) and the BeOS GUI. BeOS has problems with VM and networking, Linux has problems with GUI. A match made in heaven. Well, here's hoping that QNX open sources Photon...

Re:GNOME, a thought

[Panaflex]

OK, let's take a slashdot poll... I bet more people use vnc.

Pan

New ORB.

[sarkeizen]

Anyone know if there's intent to implement some kind of simplified IPC? Similar to DCOP? I'm a CORBA developer and even I think that CORBA presents a fair ammount of work to perform some relatively simple things.

BTW: Great Job on the multilingual!, as someone who likes to have his desktop in traditional chinese this is a big deal for me.

Re:New ORB.

[Phill Hugo]

I'm not sure GNOME needs a new ORB at its heart. Orbit is easily sleek enough for general desktop use.

How more simple can you get than a 3 line python random.org CORBA client?

This would make a nice op-ed at K5

[wiredog]

Really.

GNOME Stability

[Arandir]

I just ran across a GNOME problem not just ten minutes ago. I want to build Dia because argouml is insufficient and Rose sucks.

Dia is under GNOME/stable. gdk-pixbuf is under GNOME/unstable. Anyone see the problem here? Who in their right mind can call Dia "stable" when it relies on an "unstable" library?

Re:GNOME Stability

[NonSequor]

I'm pretty sure that gdk-pixbuf should be moved to stable. A lot of programs have been using it for quite some time.

Re:GNOME Stability

[efgbr]

Since gdk-pixbuf is a part of the GNOME 1.4 platform you can consider it stable.

You shouldn't really be looking in the stable/ unstable/ dirs in GNOME's ftp.

Re:GNOME Stability

[Uerige]

You shouldn't really be looking in the stable/ unstable/ dirs in GNOME's ftp.

Where to look then? _Everything_ on the ftp site is either in the stable or unstable dir. Ts.

Re:GNOME Stability

[Arandir]

I'm looking there because I want to build Dia! Hello McFly!

Another thought...

[jd]

Now that GNOME 2 is approaching a point where the API (at least) is stable, it would be really interesting if a hardware manufacturer could take GNOME and produce a graphics card with GNOME support.

"But hardware != software", I hear some cry. Well, sorry to break it to you, but software is simply a simulation of hardware. There is nothing that you can do in software that you can't do in hardware. Faster.

Picture this - a graphics card that has a pure hardware implementation of XFree86 4.1, Gnome 2, and (just for the hell of it) KDE 2.2 as well. Nothing on the computer, the graphics is done entirely in silicon. This would free up much of the computer's RAM, unload much of the heavier cycle devourers, and produce one of the fastest GUIs on the planet.

"It wouldn't be free, though!"

Free as in free beer? No, it wouldn't, but if you want free beer, you're probably in the wrong place, anyway. You want the beer tent.

Free as in free speech? Why not? The hardware would need to follow GNOME, X and optionally KDE. X is the only non-free component of that. By having a re-implementation of it, you could make the hardware version totally free and totally unencumbered.

Re:Another thought...

[mark_lybarger]

that's definately an interesting idea, but how would you propose to handle upgrades?

also, that much of a integration of hw/sw seems a little scary to me. now all the sudden, all the other software i run on my box is dependant on this desktop chip i have on my machine.with the costs of hardware these days, i just don't see a practical need to move this stuff out of the RAM/core CPU area. Enough system ram for one of these desktops costs less than a few days lunch, and those athlon t-birds... well, they're just c00l to have heating up the place :)!

Re:Another thought...

[Patoski]

All too often 2d hardware acceleration doesn't buy you speed compensatory to the level of effort that is required to maintain it in your program. Maintaining something like this would be a nightmare to put it mildly. Don't look for it anytime soon... =)

Re:Another thought...

[David Greene]

Insightful? I've never questioned the drug-using habits of moderators before, but there's a first time for everything. :)

"But hardware != software", I hear some cry. Well, sorry to break it to you, but software is simply a simulation of hardware. There is nothing that you can do in software that you can't do in hardware. Faster.

While it's true that hardware and software are essentially the same thing (a favorite rant of mine, BTW), it's not true that hardware is necessarily "better" than software, even in the speed department.

Picture this - a graphics card that has a pure hardware implementation of XFree86 4.1, Gnome 2, and (just for the hell of it) KDE 2.2 as well. Nothing on the computer, the graphics is done entirely in silicon.

If we look at this proposal from a perspective of practicality, it clearly falls down. Hardware is incredibly difficult to debug and change. That is the beauty of software. The fact that complex computer architectures are implemented in terms of software (microcode) only points to this flexibility.

To address your speed claims, I point you to HP's Dynamo project. Dynamo is a dynamic translator for PA-RISC binaries. It is a software system that translates PA-RISC instructions to PA-RISC instructions at run-time. That doesn't seem to make much sense until you realize that the translation includes optimizations that can only be done at run-time. Binaries actually run faster under Dynamo than in native execution mode. By putting in a layer of software, HP was able to increase system speed.

One cannot do this in hardware because metal and silicon is fixed and FPGA's are too slow. Yes, people are researching reconfigurabler hardware, but that is for very specialized applications like DSP's, applications that are already used to boost graphics performance today.

A final observation: hardware gets much of its speed from parallelism. A ripple-carry adder runs much more slowly than a carry-lookahead adder. While certainly running at the speed of light (yeah, yeah, give or take) helps, parallelism (pipelining, O-O-O execution) is what got us the machine speeds we see today.

Parallelism is really, really hard to extract at the instruction level. Theoretically, it's there, but damned if I know how to get at it. Certainly lots of graphics routines have loads of parallelism. But guess what? We already have hardware to exploit it!

This would free up much of the computer's RAM, unload much of the heavier cycle devourers, and produce one of the fastest GUIs on the planet.

Modern GUI's really don't need to be much faster than they are now. We all like high framerates in our pretty games, but those are very specific applications. In fact, good hardware solutions already exist for them. I don't see RAM consumption as a problem, considering that X runs just fine on the iPAQ with room to spare. I have no idea what software you are running, but the CPU usage of graphics code is not even close to the largest consumer of cycles on my machine.

We already have good graphics hardware. Moving the X/GNOME/KDE control into hardware would gain almost nothing.

Re:Another thought...

[Prince Caspian]

What you are proposing does not make sense. X is simply for drawing primitives, and the whole point of an optimized X server is that it calls the hardware optimized functions of your graphics card to draw those primitives. I assume when you say that GNOME and KDE should be implemented in hardware you mean Gtk and Qt, since the majority of GNOME and KDE are non-graphical libraries.

Re:Another thought...

[dvdeug]

> Picture this - a graphics card that has a pure hardware implementation of XFree86 4.1, Gnome 2, and (just for the hell of it) KDE 2.2 as well.

Okay, in the year 2025, someone comes out with a multi-trillion transitor chip dedicated to emulating 25 year old software, slower than any contemporanous chip. (25 years is probably optimistic for coding this in "pure" hardware.) I'm sure eveyone will be thrilled.

Do you understand the difference between CISC and RISC? The whole point of RISC is that dumping more and more stuff on the hardware isn't always the way to spend things up. RISC does a few things fast. Modern CISC chips, like the Pentium, are largely a CISC to RISC interpreter with a RISC core.

Re:Another thought...

[jd]

Upgrades would require ripping out the old chip, plugging in a new one. The assumption is that if 99% of desktop users can survive with a pile of carp as a GUI, they can survive with an old (but usable) quality GUI.

Re:Another thought...

[GrenDel Fuego]

Rather than implementing all of X in hardware,
why not just run X on a seperate, dedicated box?

You can run X applications on a seperate server, but the machine you're running needs to run X as well in order to do the hardware interaction.

Of course, certain parts of X can be moved to the other box, including the Font server, the window manager, etc.

Re:Another thought...

[jd]

That's usually because a lot of 2D acceleration is done using FPGA, microcode, or some other "software buried in hardware" technique, which does not get past the inherently slow nature of any software approach.

If you implemented this in raw hardware, you should get a sizable speedup, as there is a sizable amount of parallelism present. In software, you can only run one task per processor. In hardware, you can run one operation per link between gates.

Maintenance a nightmare? Oh, certainly. If anything, I'd say "nightmare" is too mild. This kind of stuff would give the average hardware guy post-traumatic stress disorder. I'm not joking, either. We're talking about VLSI on a scale far beyond anything that's been done.

Re:Another thought...

[Turmio]

Umm what the *hell* are you talking about? I didn't find any sense in that and it's Score:4, Insightful. LOL. At least tell me where did you pick up those mushrooms, I'd like to have a trip like that too.

Re:Another thought...

[vrmlknight]

ever hear of this new stuff that we like to call FLASH ROM or EEPROM as technical people like to call it it is Electrically Erasable Programmable Read-Only Memory

Re:Another thought...

[jd]

No, I mean GNOME and KDE. The non-graphics parts still need accelerating, and in the end, a computation is a computation, regardless of what you want to use that end result for.

By having everything (or as near to everything as physically possible) on silicon, you turn what is basically a serial stream of operations into one ultra-gigantic parallel process.

When you reach this point, there is no need for an "optimized" X server, as there's really no need for the computer to have any GUI code on it at all. All you'd do is generate X calls, and have the hardware take over from there.

Re:Another thought...

[David Greene]

By having everything (or as near to everything as physically possible) on silicon, you turn what is basically a serial stream of operations into one ultra-gigantic parallel process.

Where is this parallelism? Sure there is a lot in the actual rendering routines, but beyond that you are going to be hard-pressed to find much at all.

When you reach this point, there is no need for an "optimized" X server, as there's really no need for the computer to have any GUI code on it at all. All you'd do is generate X calls, and have the hardware take over from there.

We have this. It's called DRI. It operates at the appropriate level of abstraction.

Re:Another thought...

[mark_lybarger]

yep, i've heard of it. i'm not actually the engineer (so please correct me if i'm misled), but my understanding is that these chips store software. that's not exactly going with the original author's idea of implementing the desktop via hardware.

i'm still a little skeptical on the idea. would a hardware implementation of a desktop kinda lock a user into one monitor/display unit? I guess that could be just a "setting" that's stored on one of these nifty EEPROM's :)

Re:Another thought...

[jd]

Let's say you have N active processes that are using X. Then, for every event, you must search a table of at least N entries to see which process that event is to go to.

This is one parallelizable step.

Then, you have the problem of when one (or more) of those active processes themselves generates an X event. X must then pull that event into its event handler and farm it out appropriately.

Since a microprocessor can only deal with one thing at a time, what you have is the following:

• Process fires event
  
• X receives event
  
• X directs event
  
• Process receives event
  

Not too bad, you might think. But each of these requires a context switch, and those aren't cheap. Now, when you start throwing in GNOME stuff, it gets worse, as you have to bury your way through Gnome's libraries, the lower-level libraries, gtk/glib to Xlib, or vice versa. Again, each of these requires a context switch.

(One context switch = dump current state of current process; load in new process; set up registers for correct state)

Since, in a logical sense, there is no real difference between GNOME and X, context-wise, all those extra context switches are simply wasted computer resources.

As or DRI, I believe that requires kernel stuff, and there's not much kernel stuff there, yet. Once there's a decent set of drivers there, it might be meaningful.

Re:Another thought...

[David Greene]

Let's say you have N active processes that are using X. Then, for every event, you must search a table of at least N entries to see which process that event is to go to.

This is one parallelizable step.

I'm not sure how the process table is implemented in X, but unless it's a straight array, doing it in hardware is going to be complex/expensive (lots of comparators, etc.). Then there's the issue of having a limited number of hardware entries. If it is a straight indexed array, why do it in hardware? :)

I agree that in principle this could be parallelized in a straightforward manner. I still question whether there will be a significant performance gain, however.

Since a microprocessor can only deal with one thing at a time, what you have is the following:

• Process fires event
• X receives event
• X directs event
• Process receives event

Not too bad, you might think. But each of these requires a context switch, and those aren't cheap.

Now, when you start throwing in GNOME stuff, it gets worse, as you have to bury your way through Gnome's libraries, the lower-level libraries, gtk/glib to Xlib, or vice versa. Again, each of these requires a context switch.

I'll grant you that certain types of application combinations can behave badly, but I think people in general are overly concerned about context-switch time. A colleague of mine did a study using parallelism (SMP) to improve the user experience of GUI systems. Indeed, performance improved significantly for "interesting" combinations like running an MP3 player in the background. However, only a few applications needed improvement because most events occurred under the human "perception threshold," even with the additional MP3 load.

Incidentally, a more interesting outcome of this work was that the high speed of today's GUI's and processors allows one to save an enormous amount of power by simply slowing things down. The user experience is not degraded in any way. Think Crusoe taken to the next level.

In any case, complex custom hardware such as you proposed wasn't needed. An extra CPU did the trick just fine. One could probably get away with a "dumb" slave CPU. Personally, I think it would be a waste of resources given that your eye really won't notice the difference most of the time.

As or DRI, I believe that requires kernel stuff, and there's not much kernel stuff there, yet. Once there's a decent set of drivers there, it might be meaningful.

I absolutely agree that DRI is in its infancy. But I believe it is the correct approach, providing performance at the bottleneck while maintaining (relative) simplicity.

Re:Another thought...

[nexthec]

My only critisism is the coment on FPGA's They are getting quite fast, especially on graphics because so much of it is parralelable, rotations/translations/shading. All of it is Linear algebra that can be easily accellerated. I saw a 40Mhz FPGA outperform a 400Mhz PII (couple of years agod) almost 10:1, on a few specific graphic routines. Now if you take technology Like PipeRench(sp) from MIT you get som very state of the Art technology. Not to mention that people like NVIDIA and ATI are already instituting programble devices on their cards

Re:Another thought...

[ajs]

Ok, there are other replies that indicate some moderators might have been on crack, but let's take this simple suggestion seriously for a second and see where it goes.

If we were to put gnome-terminal and everything that it requires on a card, that card would hardly be a "graphics" card any longer. This would be a general purpose device with acces to (and thus assumptions about) all sorts of OS details. It would be managing its own IPC, creating devices in the filesystem, sockets on the network... it would be a BEAST.

Ok, let's just back off a second. *What* was the actuall proposal.... Well, someone wanted to speed up Gnome and remove some of the "bloat" by putting it in hardware.

A smaller subset of that is not only relatively easy, but quite desirable. An implementation of GDK (the abstraction layer that Gtk+ uses to talk to X or Windows or console graphics) in hardware would go a long way to eliminating the need for an X server entirely (the other pieces would be an Open/GL interface that Mesa could talk to, a set of window management primatives and a screen saver interface). This would be much more reasonable than putting an X Server in hardware, since it would provide a higher level interface, but at the same time you could still upgrade to the latest Gtk+ lib (assuming that its GDK supported the card's interfaces) and your version of Gnome would be totally independant of the card (except for the screen saver and window manager).

Such a device would give you much better Gnome performance, reduced footprint, a lack of need for the X server (in limited desktop environments where existing X applications were not needed) and an API that even Qt could be ported to (yes, Qt could be implemented on top of GDK).

Re:Another thought...

[Graymalkin]

The DirectFB project is already doing this. They've got a setup to do entity rendering directly into the hardware framebuffer. Look around the site and see for yourself. It looks pretty impressive and does pretty much exactly what you're saying if I'm reading you correctly. GTK+ runs right now on top of DirectFB as well as directly on the system frame buffer. Gotta love GDK!

Re:Another thought...

[ajs]

No, not quite. There's still got to be glue between GDK and the hardware (which is what directfb is). If the hardware provided a GDK API, then directfb would just be a bunch of ioctls....

Re:Another thought...

[be-fan]

Actually what you're thinking of is already here: E17. A hardware accelerated desktop. Runs fast, looks pretty. Mostly only the graphics routines need acceleration, since the other stuff doesn't take much processing. (If it does, you're using bad algorithms, and bad algorithms suck software or hardware rendered!) I only wish all apps could some how take advantage of E17's features. Raster should really think about maybe forking GNOME or something to create a E17 DE.

Re:Another thought...

[be-fan]

Please learn how a computer works...

Let's say you have N active processes that are using X. Then, for every event, you must search a table of at least N entries to see which process that event is to go to.
>>>>>>>
Only if the developers are monkeys. Say you have a keypress event. The event automatically goes to the frontmost window, which is O(1). Say you have a timer event. If you keep the timer list sorted (which is pretty easy, its called a binary tree), then the lookup is quite cheap. Rarely should X have to use an O(n) algorithm, unless you want to visit every process anyway.

Then, you have the problem of when one (or more) of those active processes themselves generates an X event. X must then pull that event into its event handler and farm it out appropriately.
>>>>
Again, quite cheap. Say you want to send a message to another app. The destination is embedded in the message, so delivery is again O(1) (not counting copying of the message data!)

Since a microprocessor can only deal with one thing at a time, what you have is the following:

* Process fires event
* X receives event
* X directs event
* Process receives event

Not too bad, you might think. But each of these requires a context switch, and those aren't cheap.
>>>>>>>
Actually, events are buffered. So for every few dozen of these transactions, there are only two context switches. Say a process draws a thousand lines. Each one doesn't get sent to X. Instead, they all get put in a buffer, and when the app asks for sync, the buffer is sent to X as one big transaction. (I don't know if X specifically does it this way, but most window servers do).

Now, when you start throwing in GNOME stuff, it gets worse, as you have to bury your way through Gnome's libraries, the lower-level libraries, gtk/glib to Xlib, or vice versa. Again, each of these requires a context switch.
>>>>>>>
Except it doesn't. Library calls are just indirect function calls, and they are quite cheap. On a PII, an indirect function call takes less than 10 clock cycles.

(One context switch = dump current state of current process; load in new process; set up registers for correct state)
>>>>>>>>
Fortunately, context switches only happen a few hundred times per second (very rarely, by processor standards).

Since, in a logical sense, there is no real difference between GNOME and X, context-wise, all those extra context switches are simply wasted computer resources.
>>>>>>>
Except that GNOME is a library and X is a seperate process!

Re:Another thought...

[Graymalkin]

Well there are always the GTK+ and Qt running inside the system framebuffer.

Re:Another thought...

[jd]

Let's see... Ten clock-cycles for an indirect function call...

Well, 4 clock cycles are required to load a long register, with the address, 4 are required to perform a long jump, which leaves you with 2 clock cycles to:

• Determine if the address is even in memory at the time
  
• Load the information from swap, if it isn't
  
• Preserve the state of the calling function
  
• Swap out information as needed, in the event of the called function being swaped in
  

Something tells me that your model isn't, umm, 100% complete?

Then, we get to the library bit. Yes, much of the GNOME stuff is in libraries. But X is an event-driven model, not a sequential model. Thus, you have multiple threads going through your program, not just one.

Now, for the lookup bit. Yes, I know about binary trees. Actually, the "correct" implementation would use an n-ary tree, for much faster lookups. Binary trees simply take log2(N) to search. Which seems fine, until you realise just how many damn things X considers an event!

Then, you've got a secondary problem - sending an event to more than one application. It's certainly possible, which means that your check system can't just search the tree for the first hit, it has to search the tree for EVERY hit. Which reduces it to a linear search. The only advantage in using a tree, for these situations, is that you can get most of the important checks done quickly.

Let's now look at that line-drawing example. 1000 lines get drawn, all get buffered, until there's a sync. Hmmm. That's true, but not typically how it's done. To have smooth graphics, you need to have near-fixed intervals between updates, so you can't just hang around until some coder decides to sync things up. The usual way of coding is to double-buffer and do small amounts of updating at any given time interval.

Re:Another thought...

[be-fan]

Well, 4 clock cycles are required to load a long register,
>>>>>>
I was assuming the code and data were cached.

with the address, 4 are required to perform a long jump
>>>>>
On what proc?

which leaves you with 2 clock cycles to:

Determine if the address is even in memory at the time
>>>>>
Done automatically by MMU during the memory access to get the code. Also, only happens if the instruction pointer crosses misses the TLB.

Load the information from swap, if it isn't
>>>>
Well, swap kills performance on any system. Why do you think KDE and GNOME require so much RAM?

Preserve the state of the calling function
>>>>
There's the bulk of the few clocks. Assuming the write is cached, its a piddly amount of data on x86 procs.

Swap out information as needed, in the event of the called function being swaped in
>>>>>
Again, swap isn't a factor here, since the code is assumed to be in RAM. Swapping will kill even the best code.

Something tells me that your model isn't, umm, 100% complete?
>>>>
Something tells me you should read up on the GCC function calling convention.

Then, we get to the library bit. Yes, much of the GNOME stuff is in libraries. But X is an event-driven model, not a sequential model. Thus, you have multiple threads going through your program, not just one.
>>>>>
I'm going to love the explanation for this one. What exactly are you talking about? You've got event driven, threading, and libraries all messed up. First, events are queued, so the cost of doing a context switch to deliver them is mitigated over several events. Second, threads have nothing to do with event handling. X isn't multithreaded, and neither GNOME nor KDE use threads. GTK+ and Qt aren't even fully thread-safe!

Now, for the lookup bit. Yes, I know about binary trees. Actually, the "correct" implementation would use an n-ary tree, for much faster lookups. Binary trees simply take log2(N) to search. Which seems fine, until you realise just how many damn things X considers an event!
>>>>>
Umm, methinks you're mistaken. If you were doing a lookup to deliver an event, you'd lookup the process ID to deliver the event to, not the ID of the event. (The ID would be even easier. Only 255 X events, you could use an array).

Then, you've got a secondary problem - sending an event to more than one application. It's certainly possible, which means that your check system can't just search the tree for the first hit, it has to search the tree for EVERY hit.
>>>>>>>>
Sending the same event to multiple apps should be rare. X events aren't a general communications protocol. Also, multicasting is rare for any messeging system.

Let's now look at that line-drawing example. 1000 lines get drawn, all get buffered, until there's a sync. Hmmm. That's true, but not typically how it's done.
>>>>
Except that IS how its done. BeOS's app_server does it. QNX's Photon does it. X probably does it too (I would hope so!)

To have smooth graphics, you need to have near-fixed intervals between updates, so you can't just hang around until some coder decides to sync things up. The usual way of coding is to double-buffer and do small amounts of updating at any given time interval.
>>>>>
First, the system can wait for either a number of drawing events, or sync, which ever comes first. Second, while you are right that there must be fixed-intervals, you have to realize that the intervals are REALLY long. The human eye cannot detect changes faster than 60Hz. That's about 16-17 milliseconds per frame, which is an awefully long time. Thus, the graphics server can afford to wait for a large buffer of drawing events and draw them together. Double buffering does something similar. You buffer all the changes to the framebuffer together, and you display them all at once 60 times per second (really slowly for a computer!)

Re:Slower progress compared to KDE

[fault0]

Well, actually, KDE 3 alphas have not come out yet. The first one is due Friday, afaik. However, most of the rest of your comment is correct, I think. KDE 3 will probably come out sooner than GNOME 2.0 will too (KDE 3 alpha1 is a usable as a end-user desktop, while GNOME alpha1 seems to be a technology preview). So, according the the latest KDE 3 release timeline, it should come out in February.

More Detail?

[exceed]

I'm excited that GNOME 2.0 has finally debuted, but what else has debuted along with it?

Does/Will it have built in anti-aliasing? Is it considerably faster than 1.4? What is the main concern the GNOME development team is taking into consideration in regards to 2.0? Does anyone have any further information on it? The LinuxToday article doesn't really answer any of the questions alot of people are wanting to know.

Re:More Detail?

[rhavyn]

From everything I've read, the biggest user visible change in GNOME 2.0 will be that they are using Gtk+ 2.0. Gtk 2.0 includes anti-aliasing and lots of other fun features (look at the section about Pango at www.gtk.org).

Otherwise, I don't know if anyone knows how speed will or will not improve since the core libraries are only just now getting their API's completely frozen. Apps will need to be fixed to use the new API's, then we'll see how it performs (and developers will be able to tune accordingly).

Re:Frist Porst, GRR!

[J4]

Yeah, those damn newbies....

Re:A bit of thought on the evolution of the GNOME.

[lanbo]

I totally agree on that.
Of course I admire the GNOME team, but I'd like that their brains joined the KDE team.
They aren't enemies. They code for the same reasons so you are not doing anything bad joining KDE.

Re:GNOME==bloat

[Penguinoflight]

If you like windowmaker or blackbox, use them inside gnome, that will take care of a lot of the bloat right there. Mostly I use Gnome applications, I just got done trying out kde 2.2.1, it looked cool, but none of the apps outdid anything from Gnome.

If you don't like Bloat, use Gnome apps in Afterstep or Windowmaker.

Re:A bit of thought on the evolution of the GNOME.

[mal0rd]

Some people think that GNOME is far better than both Windows and KDE. Lately, the GNOME has got a valuable addition: Open Office, the remnants of StarOffice. This would really make it possible for GNOME to gain acceptance in the desktop.
...
I just don't understand why the talented GNOME developers don't start developing for the KDE instead?

Well, for the answer to your question look back earlier in your post. GNOME is better than KDE. Why would the GNOME workers want to start working on KDE? There would be catchup to do. Also, Qt isn't a as free as gtk. It is owned by Trolltech that sells more advanced versions of Qt. This means that if someone wanted to add new features to the free Qt, like for instance the ones included in the commercial versions, and Trolltech didn't like it, a new branch would need to be started. Then there would be two Qt's and that would be messy.

-1, dump it

[wiredog]

There're some redundancies in the story.

Find it at you can grab it ...There's some more information information

Get rid of the "Find it at" and the second "information". Fix those and I'll vote it +1,FP!

Anti-aliasing

[Kryptonomic]

Does/Will it have built in anti-aliasing?

Uh... have you ever used X with anti-aliasing?

I tried it with KDE 2.x but had to turn it off. The fonts were messy to the point of being almost unreadable.

Re:Anti-aliasing

[exceed]

Yes, I have. It requires some XftConfig tweaking so that the smaller fonts don't get anti-aliased (much like the way Windows does it).

Something like...

match
any size > 10
edit
antialias = false;

...in your XftConfig

You might want to refer to http://dot.kde.org/989808269/ for more information.

Re:Anti-aliasing

[be-fan]

I'm (not the original poster) using AA in Linux right now, and it looks great. I nuked the crappy Linux distro (X, urw, Abiword, Mandrake, etc) fonts that came installed and copied over the .ttfs from my WIndows partition. Edited my XftCache, and voila, awesome!

Re:Anti-aliasing

[be-fan]

Closer to 70%. While the Windows TT fonts made a huge difference, I can still see aliasing. AA makes it look a little nicer.

QNX's Photon GUI

[DABANSHEE]

is definitly elegant compared with the man 'X' based varients.

DisplaySVG?

[1010011010]

Hmm... how about "Display SVG" - like DisplayPostscript...

Not really...

[Penguinoflight]

Think is, KDE just finished the stuff they promised for KDE 2.0 with the 2.2.1 release. Gnome is still a better overall envirenment, and with support from Sun, the Office applications will become better, even though Abiword is still better than anything for KDE. Do yourself a favor and take a look at all the applications you really need from KDE... I did and found 0. You are trying to infer than KDE 3.0 will be out sooner than Gnome 2.0... It won't be.
It's no wonder you posted AC. :-)

Re:Not really...

[Cid Highwind]

. Do yourself a favor and take a look at all the applications you really need from KDE...

Kmail - becuase evolution is bloated and buggy, and if I wanted to use pine I would telnet to the school's UN*X servers from a Macintosh instead of running Linux.

Konqueror - becuase Mozilla is slow, Netscape 4.x crashes too often, and Galeon just won't compile on my system.

KFM - because Nautilus gobbles up monstrous amounts of memory, doesn't support tab-completion, and looks like Win95 on acid.

Gnome is winning in the office-software department, Abiword and Gnumeric are far ahead of the Koffice stuff.

Re:Not really...

[rhavyn]

1. Evolution is can hardly be considered buggy anymore. I've been following the nightly snapshots for 2 months or so and it is perfectly usable on a day to day basis.

2. Nautilus supports tab-completion (not that you need it since it tries to autocomplete anyways).

You could at least try using a recent version of the apps before you bitch about them.

Re:A bit of thought on the evolution of the GNOME.

[Jamie Zawinski]

Eazel and Ximian are the most productive GNOME companies,

By "most productive", did you mean "only"?

Is it because the GNOMErs only know how to code in C, and not in C++. There are several good books and web sites on C++ programming, you know.

I promise you that those of us who refuse to use C++ do not do so out of ignorance. Quite the opposite, in fact: I don't use C++ precisely because I know more about it than you.

Bloat?

[JahToasted]

I hope they remove the bloat that made 1.4 unusable. I think Nautilus was the biggest problem but not the only offender. From what I can see Bonobo hasn't been used to it's potential yet, I'll have to check out 2.0 from cvs to see what's happening with gnome now (I've been using KDE lately). Although KDE is winning the desktop environment wars now, don't count out gnome yet. As I see it these are what the priorities need to be for gnome to make me want to use it over KDE:

• Nautilus shouldn't suck - I don't mean to insult those developing Nautilus, but for a file manager you need something fast, not pretty. If it can be both then fine, but right now it's just eye candy. I prefer a GUI for managing my files but so far I have not seen anything that is as nice as Windows Explorer (95 version or 98 with all the shit turned off). Why is this so hard?
• Better Integration - Bonobo needs to be rock solid and needs to be used more often. This is especially true for Nautilus but also applies to many other apps. Nautilus should just give up trying to be a web browser and just load galeon as a component if it wants to view a web page.
• More Organisation - The gnome project is very disorganised. If I want to develop a C Programme, do I use gIDE or Anjuta? Why is there so much duplication? While gIDE and Anjuta are working on two IDEs, KDE has one KDevelop completed.
• Work with KDE instead of against it - Why all the hate between these 2 groups? They both want a free DE for unix, so why do they dislike each other so much? There needs to be more cooperation, or neither will be viable as a desktop for the average user, while microsoft will continue to get them hooked on their projects.
• Make it fast again - I prefered 1.2 over KDE because it was twice as fast (or at least seemed so) after 1.4 I switched back to KDE because I got tired of waiting about a minute to open a text file.

I don't mean to bitch, I really like gnome and look forward to switching back from KDE. The terminal is nicer, GIMP is cool, Galeon is the best web browser i've ever used, and Open Office looks promising (I know I can use these with KDE but I don't like having both GTK and QT loaded, I have better uses for my RAM). But right now KDE works, so that's what I'll use. But I'll give 2.0 alpha a shot... and when gnome works again, It'll be my primary desktop.

Good luck to those working on gnome... and expect some bug reports from me soon!

Re:Bloat?

[reaper20]

Nautilus shouldn't suck

The latest Nautilus builds I have tried with the merges from the Red Hat guys have been AWESOME. Still needs some work, but it has come a long way towards becoming everyday usable.

Work with KDE instead of against it - Why all the hate between these 2 groups?

Why do people say this? I don't get it. I don't see Gnome developers trolling KDE, I don't see KDE developers trolling GNOME. What do I see? Users trolling for their preferred choice. Its not like KDE guys are making KDE apps not work in GNOME or vise versa.

Everyone talks about this huge war and how only one can survive ... give me a break people, the only ones damaging BOTH desktops are the people that are supposed to be pushing for open standards and competion! Don't believe me, then read the crap in this thread.

Re:Bloat?

[fault0]

The terminal is nicer?

How it gnome-terminal nicer than konsole?
Konsole's biggest feature is it's multiple terms in one window, of couse.

Re:Bloat?

[RPoet]

Work with KDE instead of against it - Why all the hate between these 2 groups? They both want a free DE for unix, so why do they dislike each other so much?

This perceived dislike is simply not there. I'm afraid the media has eaten into your brain with their constant scandalizing and crying scandal even if there is none. Developers across the two camps get along very well (see pictures from expos etc ;). There's also a gnome-kde mailing list on which they discuss how to better interoperate. I think developers and most users have long since realized that although people's preferences differ (hence two or more alternative environments), we share the same ideology. This has brought us TWO free desktop environments (more, actually) that are both usable, mature and popular. And what's more, I personally mix applications from both environment. Were there only one DE, I wouldn't have many of the great applications I use everyday.

So if you have this pent-up need for perceiving dislike, perhaps you should go into politics, or co-hosting Jerry Springer or something instead ;)

Re:Bloat?

[Emil Brink]

[...]for a file manager you need something fast, not pretty. If it can be both then fine, but right now it's just eye candy. I prefer a GUI for managing my files but so far I have not seen anything that is as nice as Windows Explorer (95 version or 98 with all the shit turned off).
OK, ObPlug: Tried gentoo yet? It's far from an Explorer work-alike, but more than one person have called it "fast". Of course, I'm highly biased, so... ;^) Anyway, here's a link: gentoo-0.11.17.tar.gz (717 KB, tar.gz source archive). Enjoy.

Re:Bloat?

[ethereal]

You know you can use GIMP under KDE, and KDE apps under Gnome, right? It's amazing how many people don't. Yes, you need to install both sets of libraries. No, it isn't the end of the world to do so.

Re:Bloat?

[fault0]

Yeah, I've heard about multi-gnome-terminal. I doubt that it looks nicer. The KDE default hicolor theme is imho, one of the best designed widget styles EVER. Another good one is Mosfet's liquid engine. There is __NO__ gtk+ engine/theme that can do what liquid does. And yes, KDE 2.2 added a lot of "effects", that GNOME does not have. Also, Qt, unlike gtk+, has builtin xft support for antialiasing (yes, I've tried gdkxft, but it doesn't antialias all apps and is not builtin). I'd say that KDE has a huge lead in the eye candy department for now. Gnome2/Gtk2 will have this builtin, but Qt3 adds complete xrender support, so it'll be interesting to see who wins in the next round :).

I think KDE and GNOME take about the sametime to bootup, I've tried both. I'd say they are equal here.

Nautilus is getting a lot better, but in terms of FEATURES, it's still not as good as Konqueror. Konqueror can basically replace an entire WINDOW MANAGER if you want it to. For example, open a new Konqueror window, split it into three frames. Open up a console frame in one, keep the file manager in another, and open a webpage in another. You simply cannot do these with Nautilus. Also, there are a lot of useful kioslaves, very few which have good, working, equivalents in Nautilus. Also, konqueror is a lot more useful for webbrowsing than Nautilus. Although Nautilus can view webpages (either through gtkhtml or gecko), it really is not designed to be a Web Browser like Konqueror is (ever wonder why Nautilus is always referred to as a File Manager?) I'd say KDE has a big lead over GNOME in file browsing until Nautilus can get as many features as Konqueror has.

As for reusable applications, KDE has a big lead over GNOME in this. And it has ever since KDE2, dcop, and kparts. Bonobo, although it has existed before kparts, has changed around so much that it simply isn't used much (yet, hopefully will change with gnome2).

Re:Bloat?

[hyperstation]

I'd agree that KDE and Gnome should be collaborating, but I sincerely hope that the GTK widget set wins through at the end of the day.

gtk is all blocky and and ugly looking, while qt is streamlined and smooth. if you're ever gonna convert all the windrones over to linux, it's gotta look pretty...

just my $0.02

Re:Bloat?

[be-fan]

Yes, you need to install both sets of libraries. No, it isn't the end of the world to do so.
>>>>>>>>>
There are two types of people in the world. Those that hate bloat, and GNOME/KDE users...

Seriously, though, there are more problems to loading GTK+ AND Qt than just bloat (which is still a terrible sin IMO). GNOME and KDE apps don't look the same. Some people (like me) just like everything to be nice and homogenous. My desk is perfectly neat and all my pens are in the perfect places. My tabletop has marks on it showing exactly where my speakers should go. Second, the two types of apps don't interoperate that well. In Windows, I'm used to embedding graphics in Word documents that are embedded in spreadsheets. In Linux, it just doesn't work that way (yet).

Re:Bloat?

[ethereal]

Fair enough, and I'll admit that the interoperation isn't there between the two. Although in most cases the actual office suites will support embedding provided you use a homogenous office suite - all OpenOffice, or all Koffice.

As far as the look, well, I guess it doesn't bother me that much. I imagine you could track down themes for one that would make it look pretty much like the other, although I don't know for sure. It still doesn't mean you can't use the Gimp along with KDE2, though, just that the look may be a little jarring.

Re:Bloat?

[hetz]

Funny that you mention that...

I did a test few days - I started X and used gnome on my machine, then I decided to start Konqueror from the konsole. It loads all the services (I know, memory usages is big) but it runs perfectly nice...

Now - I tried to switch. Restarted my X with KDE this time, opened a konsole and tried to run Gnome Meeting.. No luck, only crash...

Now, I'm sure I can load something before Gnome Meeting and it Gnome meeting will be running fine, but it's a problem for the end user who doesn't know anything about it..

Also - when I try to run some Gnome apps that needed services like Esound - why can't gnome either start Esound or run through aRTs if I run under KDE? aRTs IS compatible with esound after all (the app which I'm talking about is gnomeicu)

Feel free to reply...

Re:Bloat?

[Karn]

How can you say a toolkit is blocky when it's themeable?? Don't you mean that the themes you have been using are blocky?

Try the Eazel and Eazel-blue themes for GTK. I'd post links to screenshots, but t.o is down. They are great themes.

One advantage of GTK over QT that I never hear people talking about is eventually you will be able to port your GTK apps to Windows (I know it's sorta here now, but it's supposed to get better), and your program is still 'free'. From what I understand, if you want to port your QT application over to Windows, you have licensing to pay for. Am I correct on this? Doesn't QT cost you money if you want to compile under Windows?

Re:Bloat?

[omega9]

Either I'm using a special edition of KDE I'm not aware of you're just plain wrong. I've been running an Aqua-like* them on top of KDE for the past ~2 months and my icons have been themed.

*Theme name changed to protect poster from sue happy Apple.

Re:Bloat?

[hyperstation]

that's bs. i've had the an aqua theme in kde, with icons and the whole deal for some time, too.

The next step...

[Nooface]

X has its flaws (see Chapter 7 of the Unix Hater's Handbook), but it was extremely important for the evolution of UNIX. Now, it's time for the next step.

Yuck!

[drodver]

Problem is software has bugs, and the tolerence for hardware bugs is exremely low. What happens when a bug screws over said video card? Reboot! How long does it take before that will get old? Oh about 3 times before it goes out the window. Also, implementing these large,complex programs on hardware would be a nightmare, which means it would be expensive due to engineering costs.

Re:Yuck!

[jd]

What it would mean is that your engineers sit down and Get It Right. (Which is what programmers should do, but can afford not to.)

Implementing in hardware shouldn't be too bad. Since software equates to hardware, you should be able to simply treat the software as a "macro" of the hardware definition. This would give you a version 0.0.0, which your engineers can then run through VLSI emulators to turn into a 1.0.0 product.

Re:Yuck!

[David Greene]

What it would mean is that your engineers sit down and Get It Right.

Given the difficulties we have getting software to work correctly, do you honestly think hardware would be easier? Or even just as easy? Today's hardware only works because the specs are orders of magnitude simpler than even a mildly complex software system.

Implementing in hardware shouldn't be too bad. Since software equates to hardware, you should be able to simply treat the software as a "macro" of the hardware definition. This would give you a version 0.0.0, which your engineers can then run through VLSI emulators to turn into a 1.0.0 product.

So you want to use an HDL for this along with a synthesis tool? For synthesis to work, one has to either design a fairly simple piece of hardware or write relatively low-level HDL. In the worst case the designer will essentially write out the netlist. Not to mention the inefficiencies introduced by synthesis. Full-custom design is usually much more efficient, but also much harder to do.

Re:Yuck!

[drodver]

The source for KDE alone is easily over 100 MB. The time it would take would be prohibitive in the extreme. Hence it would be expensive, hence it would make the product expensive. It's just not practical, plain and simple.

Re:Yuck!

[quecojones]

Call me naive... and maybe even stupid, but what does jd actually mean here?

q

Link Broken

[krappie]

Actually, the link is wrong, it should point to:
ftp://ftp.gnome.org/pub/GNOME/pre-gnome2/releases/ gnome-2.0-lib-alpha1

the "GNOME" needs to be capital.

Re:GNOME 2.0--wheres my Enlightenment

[reaper20]

Why? Just go into the control panel and switch to enlightenment! It's wm independant, but it has to come with something!

It's easier to download an enlightenment rpm and have it appear in the control panel than it is for me to download seperate gnome rpms for whatever window manager I want.

Re:A bit of thought on the evolution of the GNOME.

[statusbar]

Unfortunately, too many people who are ignorant about the issues are jumping on the C++ bandwagon.

I've been using C++ since 1990! I helped port g++ v1.35 to the Atari Mega 4ST. I've followed the language evolution all the way till now. Many of my projects use C++.

Yet, many C++ projects that I see being done by other people are horribly misguided and doomed to failure. There are very good reasons to want to stick to C code!!!

Trolltech's QT lib is NOT one of them. For the most part, QT is ok.

--jeff

Re:GNOME 2.0--wheres my Enlightenment

[diamondc]

Im sure future Enlightenment releases will support the new NET Window Manager hints and the current Enlightenment supports GNOME well. Sawfish/Sawmill just goes perfectly with gnome panel, nautilus

Re:A bit of thought on the evolution of the GNOME.

[epukinsk]

Don't think that Eazel accomplished nothing. For one thing, they brought usability issues much closer to the forefront of the minds of the GNOME organization.

Also bear in mind that file managers like nautilus to an even greater extent the Windows XP version of Windows Explorer are becoming more and more like a document-centric operating environment in and of themselves (as opposed to the application-centric OS as a whole).

As it stands today, you can start Windows XP, maximize Windows Explorer, hide the taskbar, and still have a very functional OS. You can download pictures from a digital camera, edit them to a limited degree, burn CDs, browse the web, and do email all from within the file browser.

So don't discount the importance of a "half assed file manager". OS's are too set in stone to change the face of computing. Applications like the web browser (and now the file manager) grow from small incidental applications into robust environments that can change the way we use computers.

-Erik

Re:Slower progress compared to KDE

[PastaAnta]

Well, there is still one important issue left with KDE. The Qt library is released under a GPL license as opposed to the LGPL license for GTK+. This prohibits developers of commercial (non-GPL) applications from using the Qt library and therefore developing for KDE without paying royalties to TrollTech.

This might not be an issue for the OpenSource community, but it sure is an issue for all the companies that have to make a living. This is why companies like SUN, HP etc. has chosen GNOME as their next desktop.

Just my two bits "01" - It's a fact, like it or not.

Re:A bit of thought on the evolution of the GNOME.

[the_2nd_coming]

I always hear how C is better than C++, Blah, Blah....well please enlighten us all as to why? is there some feature that so out weights the OO properties that sticking with C is better though you need to work harder and can not reuse code as easy?

Re:A bit of thought on the evolution of the GNOME.

[David Greene]

Quite the opposite, in fact: I don't use C++ precisely because I know more about it than you.

I don't mean to start a language war (too late, I guess!), but what exactly do you know that makes you hesitate to use C++? I can think of valid reasons not to use this-or-that feature, but to dump the whole language seems extreme.

I'm honestly curious to hear your opinions.

Re:A bit of thought on the evolution of the GNOME.

[fault0]

Actually, QT is GPL, Gtk+ *is not*.

Re:A bit of thought on the evolution of the GNOME.

[the_2nd_coming]

As it stands today, you can start Windows XP, maximize Windows Explorer, hide the taskbar, and still have a very functional OS. You can download pictures from a digital camera, edit them to a limited degree, burn CDs, browse the web, and do email all from within the file browser.


I think that Konq is the best file manager/browser/document viewer/Media tool that Linux has, it is definatly on par with MS, though Konq was around about 1 year before Exploer XP.......all Konq needs is an IO_SLAVE to handle burning of CDs.

examples of hate between developers?

[Anonymous Coward]

in interviews, on web sites, etc., it seems like KDE and gnome developers constantly point out how they each admire the other's project, they get together, drink beer when geography allows, etc.

where do you see this so-called hate?

Are you sure it's between developers, or just people who latch onto one or the other and find defnding it / attacking the "other" (as if there aren't plenty of other ways to run a *nix box besides with one of those) necessary to their identity?

Re:A bit of thought on the evolution of the GNOME.

[David Greene]

Gnome is GPL. QT *is not*. (consider commercial implications as well).

This is clearly false. Qt-free is very much GPL'd. I don't know what commercial implications you are talking about. There is absolutely nothing in the Qt license to prevent it from being ported to Windows. The only commercial implication I can think of is that the application compiled against it must be licensed under the GPL. But that doesn't seem to be a concern for you.

Re:A bit of thought on the evolution of the GNOME.

[David Greene]

But that doesn't make any sense at all to me. You won't use C++ because it includes optional features you don't like? Ok, you can argue that if you strip out all the C++ features you essentially have C. That's not quite true. You have C with better type safety.

The features of C++ were added for a reason. I can't imagine not using templates and the STL these days.

The low-level nature of C/C++ is certainly a valid criticism in some domains. As always, one should use the right tool for the job.

Re:Have they dropped Nautalus?

[highcaffeine]

Maybe you should try reading the fine manual. You can *very* easily disable this behavior.

First:
Preferences --> Advanced

Then:
Preferences --> Windows & Desktop
and uncheck "Use Nautilus to draw the desktop"

Now, that wasn't so hard, was it? Don't knock a great piece of software (even though I rarely use filemanagers) just because you didn't read the docs.

Re:A bit of thought on the evolution of the GNOME.

[David Greene]

But what exactly don't you like about C++? I'm really interested to hear specific gripes, examples, etc.

Re:Agreed.

[snofla]

I like KDE too, however it doesn't have the flexible panels of GNOME. I don't care about using multiple desktops. I want cool panels.

Remember TIGA ?

[mbyte]

TIGA Graphics card used to do this :) but they were not exactly cheap :)

what is K5?

[idonotexist]

A site?

Re:what is K5?

[damiam]

kuro5hin.org.

[this here to get past the lameness filter]

GTK 2.0

[Greyfox]

Theyw ere talking about enhanced transparency support in GTK 2.0. Does anyone know if that got in there? I've got a great idea for a smoked glass GTK theme that was impossible to implement in GTK 1.2.

Supported Platforms

[Kaiser Sose]

Question . .

So did they decided to continue including FreeBSD as a supported platform for Gnome . . . or did they get us yet another gnome release where all the parts wont build/run on all the supported systems . . (eg. Nautilus, Evolution, etc.)

Re:Supported Platforms

[I_redwolf]

That's not the case. Gnome can be compiled on many systems including BSD's, Solaris, HP-UX etc.. Nautilus and Evolution run on diff platforms as well. GNOME libs are being ported to diff platforms as we speak.

Re:Slower progress compared to KDE

[jonathan_ingram]

Believe it or not, many companies *like* paying royalties for the widget set. Partly its because the beancounters can't get the idea of something worthwhile actually being free :), but mainly because it gives them a contact point for when they have problems, together with confidence that the widget set will continue to be developed.

Don't go getting the idea that Sun and HP hate the idea of non-free (or too-free) widget sets -- they kept CDE and Motif going far past the time when it should have been quietly taken out back and put down.

But that said, I hope all the money pouring into Gnome has a positive affect on the project. They are currently at the same stage that KDE were when they were changing to QT 2 -- 18 months between stable releases of the whole codebase. Gnome 2 will hopefully be as big a step in usability over 1 as KDE 2 was over KDE 1.

The UNIX software community needs healthy competition :)

No more flashing widgets.

[Flammon]

Apparently, the GTK widgets won't blink anymore when a window gets resized. I think double buffering was implemented to achieve this but can someone confirm this?

There is a cool new looking control center and I wouldn't mind seeing what the new tree widget looks like if someone has a shot of that.

Re:A bit of thought on the evolution of the GNOME.

[David Greene]

I like the control over memory structures. If I know I'm only going to need at most 500 instances of a particular object, I can statically malloc 500 structs and maintain freelists.

This is easily done with std-style allocators. You can even plug them into STL objects and use your custom allocator everywhere. There need be no overhead from new or delete. You can either override these operators for your classes or allocate using std-style allocators.

It's much more straightforward to use C in an object oriented manner

I find that extremely difficult to believe. C++ isn't all about OO, anyway. Generic programming plays a much larger role now, to the point that experts stress templates and specialization over inheritance.

then you have the ability to tweak your critical performance points.

Which one also has in C++ or any other language.

Once you know how to do it, it's just as easy as C++, maybe not as pretty and with more characters, but I spend most of my time in design, not typing, anyway.

Even if C is just as easy (which I seriously doubt), doesn't it make more sense to use a tool designed for the job (C++) than learn how to shoehorn another tool in addition to actually doing the job?

not true

[metalhed77]

there is an option to turn off nautilus's desktop drawing abilities, i'm using windowmaker + nautilus at this moment and have it configured to not draw the desktop

Re:A bit of thought on the evolution of the GNOME.

[statusbar]

Sigh... I just spent 10 minutes typing in my response and then slashdot/IE killed my post.

I'll do the short version.

#1 Most people who say they are C++ programmers actually are not properly educated in it, and have no or very little understanding of exception safety, const correctness, mutable, co-variant return types.

#2 Code re-use is a fallacy. Very often projects are factored way too much in the name of code reuse. What is important is GOOD DESIGN MEETING THE SPECIFICATIONS. Code re-use may or may not be part of that. When it is, it is a major thing. It does not come automatically because you typed 'class' instead of 'struct'.

#3 The C++ Fragile Base Class Problem. http://2f.ru/holy-wars/fbc.html

#4 C++ is a multi-paradigm language. Not only procedural, not only pseudo-OO, but generic programming too. Quite often the generic solution is the best solution under C++. I've never actually physically met more than two people who understood generic programming. sigh.

#5 Many C++ compilers just plain suck. You have to code for the lowest common denominator for the platforms that you are interested in.

#6 There is no (and can be no) standard binary API for C++ libraries. Other languages have a much harder time calling C++ libs than C libs.

--jeff

Re:GNOME==bloat

[MadAhab]

I agree with you. I went from Gnome to KDE to Windowmaker to Gnome to Windowaker inside Gnome to Windowmaker.

KDE just has way too many undocumented features that are hard to tweak - I use this stuff because I *like* to tweak things. Gnome *was* much sloppier than KDE, but has really caught up. When I finally realized I hate the desktop metaphor - windomaker doesn't need it, and I don't either - I switched back. It was around that time that I realized that I think the Gnome apps are way ahead. I've been using Gnumeric and I actually find it far easier to use than, say, Excel.

In the long run, it would be nice if their consitutent apps could run smoothly without loading the whole framework, if the background stuff (various little daemons) got loaded only when they are needed (KDE is moving away from this, Gnome towards), if someday they could settle on one sound daemon (I'm currently pitching for esound); personally, the cut-n-paste from X is about all I can see needing real soon...

Re:Slower progress compared to KDE

[mimbleton]

"but it sure is an issue for all the companies that have to make a living. "

So what are you saying is that paying for Qt can be a problem for commercial developers that have to make a living ?
Hmm ... I thought that is how humans operated for thousands of years ... you pay for my product which you can then use to create your own offering and try to sell it to others.
I mean, it worked well for hundreds of generations but what do I know .... obviously you have a better model.

PS.
Have you ever thought about how in the world TrollTech folks can make their living without charging for their fine product ?

Re:A bit of thought on the evolution of the GNOME.

[mimbleton]

"It is owned by Trolltech that sells more advanced versions of Qt. "

You know nothing about Qt.
Free Qt containst EVERY module offered by TrollTech.
There is nothing missing there.

The article doesn't mention it

[WildBeast]

The article doesn't mention that GNOME is free. How could they miss that?

You get the new control center with ximian

[led]

You can try the new control center using ximian (I always do my updates from there), it's on the preview channel in red-carpet...

My observation of why X sucks

[Pope Slackman]

X is very simple, for a windowing system, it's not complex at all. Plus no one has to see that stuff,
it's always hidden behind toolkits.

I think the major flaw with X is not it's excessive resource usage, complexity or speed, but the fact that it has no standard toolkit.

While a lot of linux kids see the ability to use any toolkit (or even implement their own) as a good thing,
I see it as a huge hindrance to usability.
A user has to learn the different behaviours of GTK, Qt, Motif, Athena
and virtually countless others, all with their own looks, hotkeys and ways of doing things.
Aside from the "feel" the "look" of X will always be discordant, further slowing the already
confused or annoyed user down in a quagmire of gradients and chrome.

IMO, if linux (or any UNIX aside from OSX) is going to have any chance at the desktop market,
X either has to standardize and enforce a single toolkit, or be replaced by something more modern.

C-X C-S

It's already being done...

[Lethyos]

The project you're thinking of is Rasterman's own Evas canvas project and the E17 that sits on top of it. http://www.enlightenment.org Yes, it will come back. :)

Re:Agreed.

[hackerhue]

I'll have to add my "Me too!" here. The panel was the feature that made me choose GNOME over KDE. The KDE panel didn't seem to want to let me set it up the way I wanted it.

Compared to MS Windows, Gnome ROCKS!!!

[BroadbandBradley]

I got trained on XP today at my company, (I do Tech support for an ISP)...they were showing us the new "luna" interface. I acidentally asked what window managers you can choose from, and if there were more than one desktop environment you could run..... DUH, this is MS, it's thier way or the highway.

go ahead an try and put windows into different layers on MS (Always on top?) Anyone who says that MS is easy to use just doesn't understand what's missing.

Re:Compared to MS Windows, Gnome ROCKS!!!

[sg_oneill]

Ain't Luna wierd? Like green-o wierd bubble skin. Sorta like Aqua with Herpes or something.

You of course can turn the skin off, and go back to a 2000-ish look, but truth be told it aint quite the same as getting peaved at a desktop and flipping across to an ENTIRELY different one (Ie gnome to KDE).

Having played with KDE 2.x recently , I've gotta admit that Linux world has *finally* pulled it off. With the exception of the "Office suite problem" (Star Office is OK I guess, but it still seems to goof MSoffice documents ocasionally.. Now Skinning star office with an MS Office look to make it easy on the plebs would be a damn achievement!). Linux is ready for Joe Desktop. Whoooopeeee!

Re:A bit of thought on the evolution of the GNOME.

[statusbar]

Qt is not as bad as most GUI frameworks. Gtk-- is better, but 'inti' ( http://sources.redhat.com/inti ) whenever it is done would be even better still (Anyone know what's happening with that?)

One of the unfortunate requirements with Qt is the ability to be compiled with VC++ 6. This alone causes problems with wanting a good design. I myself have found cygwin/mingw32 to finally be usable for all my win32 projects, so maybe now we can drop the 'lame compiler compatibility' requirements.

I think that the presence of the signal/slot preprocessor for Qt shows a fundamental problem with practical C++. I didn't say Qt was 'GOOD' I said for the most part it is OK. Better than Microsoft's MFC and Borland's VCL. Better than wxWindows. A real option for multiplatform apps.

--jeff

#define PROGRESS productive_end_user

[Ukab the Great]

Real progress in an end-user, GUI-based, for-the-masses desktop computing environment is not about:

• How many cool toys you have
• How slick the thing looks
• What language you use (those OO C is a pain in the ass to code in)
• How many graphics buzzwords like AA or DRI you support
• How little memory you use
• How technically elegant you make it

Real progress can be defined as whether the secretary, farmer, mechanic, CEO, or whoever else who isn't a card-carrying geek was able to be more productive and feel better about using than computer than they were with the last version. Anyone,GNOME, KDE, or otherwise, who does not understand this does not understand the desktop. If you do not understand the desktop, you will at best produce a successful user-hostile abomination such as Microsoft did and survive entirely by the politics of corporate IT or at worst get your butt slammed across the entire computing industry.

Wrapper?

[cgleba]

I have often wondered if it would be technically feasible for a gnome->kde or kde->gnome translator in the source of the respective apps.

For instance I LOVE some gnome apps (such as gnumeric, evolution, galeon), however KDE is by far my desktop of choice.

How tough would it be to move a gnome app over to kde? I know there are some substantial differences (qt vs gtk, dcop vs cobra, etc) however could a translator be build to translate the source of one desktop app's use of an API to another dektop's API?

It would be so cool to have gnome apps use qt (and thus have all apps look and feel the same). . .

I'm not a high-lever programmer at all (device drivers are my suit) thus I do not know much on the subject of GUI programming.

BTW I have a feeling that gnome will be making some big strides after Sun gets the ball rolling
(hopefully HP will follow Tru64's pursuit in this also -- however I think HP may still try to milk CDE otherwise known as Dashboard for those who remember the failed Windows 3.1 program manager :))

Product cycle...

[Junta]

It's cool to see this starting to come to fruition, but there are problems that we need to keep in mind.

Most things in linux have an incredibly short product cycle. While this means good things get to the public faster, it also discourages some developers. When you have a different libc, different toolkit API coming out every six months, it's hard to convince some people it is worth it to develop for. If you developed against Windows 95, for example, it still runs even without recompilation. Where were Linux systems back then? Everything about typical Linux systems has changed since then, from standard GUI toolkits (GTK and QT, don't think so..), desktop environments (Probably best you could do was CDE), to such fundamentals as the standard C library. Change is good, but in the world of Linux, the change is often done with little to no regard for running the programs of five minutes ago. Binary compatibility is flaky, and even the APIs have changed so drastically. These large projects need to give more thought to compatibility, rather than forcing people with GTK 1.2 apps to do rewrites for 2.0 rather than be left behind..

Re:A bit of thought on the evolution of the GNOME.

[the_2nd_coming]

thank-you, finaly, I am glad some one has give reasons. to often people just spout off crap because it is the party line. I realy would have liked to see your long post......to bad you were using windows ;-)

Re:A bit of thought on the evolution of the GNOME.

[statusbar]

>> too bad you were using windows

Yes, i'm sorry. I'm on linux-ppc with mozilla now!
feel free to email me though

--jeff

X is not slow

[marm]

Yet sitting down to a windows box is proof positive that X is slow.

Repeat after me:

X is not slow!
X is not slow!
X is not slow!

It is the toolkits that are built on top of X that are not tremendously fast, and in particular GTK+ and Qt (GTK+ seems somewhat worse than Qt in this respect but neither are examplary).

Proof:
Open up an application that uses one of the older, simpler toolkits such as Xt. A simple xterm perhaps, or xman, or xpaint. Enlightenment is also blazing fast. Play. See that X is in fact very, very fast indeed.

Now why is this? Why do the modern GUI toolkits appear to be slow?

Well, I think it comes down to optimization and architectural work. Both Qt and GTK+ are big libraries that attempt to do a great deal of work. But, for instance, neither of them use threads by default. Both use a technique known as an event loop to simulate threaded behaviour, but this is not ideal in terms of speed or efficiency.

Why do they not use threads? Because of cross-platform compatibility issues. Until very recently, FreeBSD's pthread implementation was thoroughly broken, and FreeBSD is a major target for both GTK+ and Qt. So, although Qt, for instance, has had its own thread API and the option of being threaded internally for some time (since qt 2), this has been switched off by default on all *nix platforms until FreeBSD got their act together.

Threading of the toolkits and the desktops and apps built around them will probably be the most significant single optimization to come, but there is other optimization work to be done too. Give it a little time, it will happen.

I'm sure I need not point out that the toolkits that sit atop the Windows GDI are, for the most part, pervasively multi-threaded, and this is where much of their perceived speed comes from.

But please do not blame X for the failings of the toolkits built on top of it. My (admittedly subjective) impression is that when blasting pure Xlib at X, it is at least as fast as raw GDI calls in Windows (see Xscreensaver vs. Windows screensavers for evidence of this).

Re:X is not slow

[Panaflex]

You must have missed my comment about larger caches and asyncronous graphics chips..

Yea, you can now fit the main X event loop and small applications into a processor's secondary cache. The major applications don't benifit from this, but more from faster busses and graphics chips. (Drawing is now a minor part of the time spend in X due to 2D acceleration)

Also, kiethp's reworking of the main event loop a couple of years ago was amazing.

My point was that architecturaly X encourages massive abstraction for client toolkits. Who would want to be tied to the color or font models X presents?

Older toolkits were designed for 68k processors - you're saying the equiv of open up windows 3.1 on a PIII. Enlightenment uses enormous amounts of pixmap copies - you are seeing X's good optimizations in SHM and protocol. Raster actually spends a good bit of time running test cases for optimization.

I will blame X for the failings of toolkits. The choice to delegate tookits to client-side is a failure that was realized years ago by most graphics programmers. News was a decent attempt to fix this, but went to far in aims and goals.

I think that the fear of loosing the few commercial applications that X has keeps X11 going as is. (Open source apps could easily be ported, slowly making more use of server side toolkits).

I don't want to deride X too much - it is a _very_ successful and usable windowing system. I just believe that it's time for X12. ;-)

Anyhow, one of these days I plan on putting my head where my mouth is. X is so modular now that it is probably very doable now. Alot more of the modules have good commentary and docs than ever before.

Pan

Qt Free is as good as it gets

[marm]

t is owned by Trolltech that sells more advanced versions of Qt. This means that if someone wanted to add new features to the free Qt, like for instance the ones included in the commercial versions, and Trolltech didn't like it, a new branch would need to be started.

Just to set the record straight:

Qt Free edition (licensed under either the GPL or the QPL, according to your taste) is identical in every way to the full Qt Enterprise edition that is Trolltech's premier commercial product.

Let me reiterate that: Qt Free edition is not cut down in any way whatsoever!

After all, why should it be? It is licensed only for Free software development, so it does not and cannot interfere with Trolltech's sales to commercial developers.

Thus your scenario of a Qt Free edition fork occurring due to people reimplementing features present in QT Enterprise edition will not happen - because there are no features to reimplement!

GNOME-KDE version relationship

[salimma]

kde.version = gnome.version * 1.5

:)

My observation of why UNIX sucks

[Anonymous Coward]

UNIX is very simple, for an operating system, it's not complex at all. Plus no one has to see that stuff, it's always hidden behind shells.

I think the major flaw with UNIX is not it's command line, complexity or speed, but the fact that it has no standard shell.

While a lot of linux kids see the ability to use any shell (or even implement their own) as a good thing, I see it as a huge hindrance to usability. A user has to learn the different behaviours of bash, csh, ksh, tcsh and virtually countless others, all with their own prompts, line editors and ways of doing things. Aside from the "look" the "feel" of UNIX will always be discordant, further slowing the already confused or annoyed user down in a quagmire of quotes and pipes.

IMO, if linux (or any UNIX aside from OSX) is going to have any chance at the desktop market, it either has to standardize and enforce a single shell, or be replaced by something more modern.

No, wait! make that no standard text editor. I mean, no standard window manager. I mean, no standard programming language. I mean...

Point is, you can standardize on a toolkit for X if you want to, but that doesn't mean everyone should.

:wq

Re:A bit of thought on the evolution of the GNOME.

[Goonie]

and GNOMElibraries are mostly LGPL, which makes it possible to write commercial apps on top of GTK royalty-free, whereas you need to pay Trolltech for royalties if you're using QT for a commercial app.

If all you're concerned about is free software, both are quite OK to use (from a legal and pro-free-software perspective). This was not always the case, but it is now.

Why not?

[Chainsaw]

Enlighten me - why shouldn't the X crowd standardize on a single widget toolkit? What are the developer and user drawbacks of this?

My observation of why you suck

[Pope Slackman]

(I don't know why I'm replying to this drivel, but anyways...)
Point is, you can standardize on a toolkit for X if you want to, but that doesn't mean everyone should.

If the designers of X-Windows built cars, there would be no fewer than five
steering wheels hidden about the cockpit, none of which followed the same principles --
but you'd be able to shift gears with your car stereo.
Useful feature, that.

- Marus J. Ranum, Digital Equipment Corporation

If the Linux Jihad wants to continue disregarding constructive criticism[1] on it's Path To Righteousness(tm),
fine - I don't really care - but don't expect to see average Joe using linux on the desktop anytime soon.

C-X C-S
[1]And really, the only criticism I have of linux (and UNIX in general) is X.
In virtually all other ways, UNIX is a superior OS archetype.

Re:My observation of why you suck

[MwtrV]

And, now, an interjection drawn from reality.

I think it should be clear that after 2-3 years of failed hype, scarce commercial products -- and all mediocre -- designed for the desktop, etc, Linux will not become a respected option for mainstream users (read: average). That silly pipe dream should be disregarded.

A desktop environment does not make an operating system suitable for "desktop" use, or, as people are so found of saying, "average user" use. It's the applications that do it and, obviously, we haven't seen enough mainstream applications ported. With the current economic downturn, especially in the technology sector, I find it highly unlikely many of the big companies are going to invest the time in porting an end-user application to what is best known as a server operating system.

Your blaming X for Linux' inability to make it as a mainstream operating system is really quite illogical.
Lastly, I really tire of hearing people complain about how Linux isn't world-dominating enough. Get over it. How many non-tech types do you think give a shit Windows starts up on their computer as opposed to an operating system created by a group of individuals rather than a fascist company?

Re:A bit of thought on the evolution of the GNOME.

[Guillaume Laurent]

> Qt is really quite bad for a C++ project.

No, it's the best C++ toolkit currently available.

> but it's a crufty design that shows that it's older than many features of modern C++.

Basically none of these features are widely portable, so for all practical purposes, you'll be quite happy with what Qt provides. And Qt's design is actually extremely good.

> you think their signal/slot system and rtti system and such are "good."

The slot/signal system is very easy to use and very readable. As for their RTTI, you don't have to use it.

> Requiring moc? Wtf?

moc is hardly seen by the developper. I've done Qt development both at work and at home for two years now, it has practically never been a problem, except when dealing with MSVC project files.

> GTK-- is much, much nicer overall than Qt, from a C++ engineering standpoint.

Have you tried programming a large application with both ? I have. Do so, and see how quickly and how far each one gets you.

that's one of the stupidest things I ever read

[chegosaurus]

And I've read some pretty clueless uninformed crap on /.

Re:Slower progress compared to KDE

[infiniti99]

Qt is GPL. KDE libraries are LGPL. KDE apps are GPL.

I thought that Trolltech had finally pulled their head out of their ass when they got away from the QPL...I guess not.

Ok, this I really don't get. Would you rather they stayed with QPL? Or perhaps you would rather they chose a different alternative license instead of GPL. Let my try to guess. I'll start by picking the obvious one. You want Qt to be BSD or similarly licensed so that you can develop closed source apps, or libraries to aid in someone else's closed source development.

No, of course not. You are immensely anti-closed-source. That's why you don't like the QPL. It's not compatible with GPL, which RMS liked to rant about, thus you dislike QPL. Fine, Qt is now GPL.

So which is it? What do you have a problem with? At least say something more obvious like "I don't want Trolltech making money" or "Down with the GPL!" or something. Right now I am confused. Perhaps I lost your point somewhere between my couch cushions.

Re:#define PROGRESS productive_end_user

[tubby]

You have a valid point, but i think you are forgetting something very important.

Real progress can be defined as whether the secretary, farmer, mechanic, CEO, or whoever else who isn't a card-carrying geek was able to be more productive and feel better about using than computer than they were with the last version.

If I, as a card carrying geek find that a new version increases my productivity or enjoyment when using the system, then it can be marked down as positive progress.
Creating a desktop environment which computer-illiterate people can use is a wonderful thing to do, and I am sure that most people here would rejoice. But it's not the only measure of success.

There are many reasons for developing Open Source Software, but non-UNIX-user satisfaction doesn't rate all that highly for me. Current user satisfaction and developer satisfaction seem at least as important.
Something that many people seem to forget is that stealing users from other OSs (any other OS) isn't - or at least shouldn't be - the goal.

tim

Re:A bit of thought on the evolution of the GNOME.

[statusbar]

LOL!!!

No, I am an escapee!!!

I'm in Vancouver now. (whew!)

sorry this is off topic

--jeff

Your off.

[Penguinoflight]

Kmail? Who said anything about evolution, mozilla is more than just a browser.

Konqueror? I must admit they have come quite far scince the origional kfm, but it still lags behind Mozilla.

KFM is really quite above Nautilus, but Nautilus doesn't look like Windows 95.