“So the forces of existing userbase, the easiest-to-reach future userbase, cross-platform applications, and funded development efforts are strongly pulling GNOME 2 toward conservatism. I think GNOME 3 should be a fork for that reason”. Read Havoc Pennington’s blog entry regarding Gnome 3.
The Gnome 3 Schedule and Plans
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
That guy is like Microsoft: dreaming, really dreaming of the next major version before making the current version right. Previous articles mentionned the long list of things to fix in Gnome 2, and it’s not by “forking” or developing a version 3 that those bugs, problems, lacks of cuntionalities, etc, will magically get solved.
Rating: 1/10
What’s wrong with Gnome 2?
I keep hoping that the Gnome folks will just concentrate on slimming down Gnome, optimizing it, making it easier to build, fixing bugs, and overall just tightening everything up.
I get the impression that there’s a small and particularly vocal group of “futurists” clamoring for all sorts of eye-candy and revolutions in UI for Gnome. The fact is, the GUI as we know it today does a pretty good job of what we need it to do. I once read somewhere someone making a comparision with the evolution of pickup trucks. Decades have passed, but pickup trucks have stayed pretty much the same as they always have. That’s because they do the job well, and fit humans pretty well. I think your typical MS Windows/Gnome/KDE GUI is a lot like that. Mac OS X adds some fancy stuff, but it’s still pretty much a pickup like the rest of ’em — and that’s a good thing.
“Making the current version right” could be a very difficult task if the vision for the current version doesn’t coincide well with the software architecture for the current version.
That’s what they’re talking about: rearchitecting the system to solve some of the fundamental problems that have cropped up from pasting new features on an old architecture.
Now if this rearchitecting just happens to be doable at the point where new features were pasted on, without affecting other things, that’s great, there’s no reason to go and break everything.
Is he asking for a real “fork” or something like an extended unstable/development branch?
I’m all in favor of some developers running ahead, coming up with cool/new/innovative features, implementing them even if it breaks things. But then those changes (or at least the ones that work) should be massaged back into the safe/stable/production version.
But an all-out fork? Maybe I’m not understanding things, or maybe it’s because I’m not in-the-know with the inside Gnome politics.
I’m guessing he means something more like what I called an “extended unstable/development branch”, since he says in the last paragraph:
“And I think this makes a temporary (but probably multi-year)…”
Ok, so we already have a situation where we have odd-numbered point-release development branches for Gnome (2.4, 2.6, 2.8, 2.10 are release versions while 2.5, 2.7, 2.9 are development). So is he just suggesting that they do odd-numbered whole-number-release versions be a “major development branch”?
Really, I’m asking.
i love osnews….not the content but certainly the comments!
i think this guy has a point… Innovation demands new design and creation, not more eye candy! As far as intuitive and easy to use, well that is probably a personal issue 
but i dont consider the way we use computers now to be all that intuitive or acually easy to use, sort of easy but not that productive… but it will take a quantum leap in all areas to have that IMO. Hard to explain that one…
What he’s describing is outside the usual odd/even release cycle – it’d be a project going on in parallel with that. The idea being to provide somewhere to work on major architectural changes that can’t be fitted into a six-month release cycle.
Havoc definitely *isn’t* talking about forking the Gnome project…
@Omega
That guy is like Microsoft: dreaming, really dreaming of the next major version before making the current version right.
You realise that “to make things right”, they have to break the major APIs/ABIs and that means they need a new version? It’s called release engineering. Learn it before ignorantly criticizing.
You realise that “to make things right”, they have to break the major APIs/ABIs and that means they need a new version? It’s called release engineering. Learn it before ignorantly criticizing.
Why weren’t things made right to start off with, with some careful thought?
You do realise that Microsoft over the years, even between major versions of Windows, has not been able able to break API/ABI compatibility. And they’ve still had to add new features to the system?
The only reason why Gnome can reasonably break that compatibility is because no one is using it, so no one will care.
What will be new in GNOME 3 so disruptive that it can’t be implemented in 2.x series?
I have read the Project Topaz page on live.gnome.org, but it just feels like a lot of hand waving to me….
You do realise that Microsoft over the years, even between major versions of Windows, has not been able able to break API/ABI compatibility. And they’ve still had to add new features to the system?
and currently they are paying out the ass for that, SP2 was a step towards fixing problems instead of containing them as much as possible and carrying them forward.
As has been mentioned here already, theres still a heck of alot that can be done to improve 2. If they do start 3 and dont fork it, chances are there will be a fork anyways, right after a massive exodus of users. Havoc hit the nail on the head when he said “Look at how much screaming we get for relatively tiny changes to today’s desktop such as the file selector, focus stealing prevention, or whatever.” People dont want innovation from linux, they basically want a free(as in cost), stable, virus free windows.
I hope to see gnome get some of the above niggling issues out of the way before a ton of huge paragigm shifting changes come down the pike in Gnome 3.0.
1. A menu editor (I know coming gnome 2.12)
2. Better network browsing (also gnome 2.12) — But will I be prompted for my username and pass when I browse into a host? Will browsing a windows network really work? Time will tell and I really hope because sometimes I don’t know the share name is I need.
3. Easy audio CD burning — Yes I am using it now with Rhythmbox .9 arch main branch. It rocks and so does tag editing and this is needed.
4. Launch feedback for desktop objects (Folders and such on the desktop)
5. Disable doubleclick on panel applets.
6. Improved user level System Tools (coming in gnome 2.12 as a goal) — we cannot leave it to the distros now can we.
7. Beagle or Storage inclusion — prefer Storage as a more flexible solution personally.
8. Replacement of esd as a sound daemon — (gnome 2.12 unassigned goal)
9. Browsing into an archive — (gnome 2.12 possible uri-chaining)
10. Skippy, expocity or some other form of expose style functionality in gnome.
Here comes the big one. The one I would trade all of the above advancements for. Let me preface this. The next goal should be the biggest and most important goal of the project imho, period. Gnome has a slick, sleek and minimal appearance. This has one unfortunate side-effect for the end user. It looks fast. Users expect it to be fast but gnome is NOT fast without a ton of RAM.
Why do I focus on RAM. My laptop with 128MB is sooo slow I use XFCE now on it. On the other hand, my blastwave package loaded ancient Sun Ultra5 with 256MB is faster, more responsive and livable with gnome. With 512MB on a (I admit it) faster laptop guess what? Gnome is as fast as XP on the same box.
Speed and memory footprint reduction — Gnome needs to place speed optimization and memory reduction once again imho as a major goal and I am very excited to see that memory reduction appearing as a a goal with even some bounties placed on it.
I really do hope that the gnome team can resolve all of these issues and I find myself also in higher spirits seeing a number of gnome developers wishing for a return and a new birth of a proper focus on a gnome office as oppossed to relying on the good will of the OpenOffice group. Maybe someone will become motivated to start working crawiaps or another project.
However, I seriously doubt that every issue I mentioned above can all be completely resolved in one release.
Why weren’t things made right to start off with, with some careful thought?
Why are society and technology always changing? Because what was right a decade ago won’t necessarily be right a decade down the road. By the same token, why did I need to buy a new computer and put my old IBM PS/2 to rest? Why didn’t IBM think ahead carefully and design that machine with the right technoklogy like PCI instead of MCA and DIMMs instead of SIMMs?
The only reason why Gnome can reasonably break that compatibility is because no one is using it, so no one will care.
Or to be more precise, Gnome can reasonably break that compatibility because modifying and recompiling open-source apps is trivial, and because running old and new apps alongside each other is possible — I remember having plenty of Gnome1/GTK1 apps running alongside my Gnome2/GTK2 apps when developers were in transition to the new APIs.
Along the same lines, earlier comments about pushing new compatibility-breaking technology without getting the current technology right are ill-founded: you can still (and Havoc makes a point of this) run old apps alongside new apps in a new environment. And beause it’s Free Software, the old “broken” Gnome2 never has to be abandoned, and probably won’t be — see Mozilla 1.x and FreeBSD 4.x for parallels.
@David
You do realise that Microsoft over the years, even between major versions of Windows, has not been able able to break API/ABI compatibility. And they’ve still had to add new features to the system?
You realise they haven’t. There are applications that will not run on Windows. Yes, for the most part they have been able to maintain ABI comaptability, but not 100%. Secondly, there is no rule or law that says you have to. Third, any programmer will tell you that being unfettered by having to maintain API/ABI allows mistakes of the past to be corrected and a system redesigned.
I want MONO to become a key requirement for GNOME 3.
@David
Why weren’t things made right to start off with, with some careful thought?
Because they’re human and humans make mistakes? Seriously. You’re never going to get things “right” the first or second time out, or even many times after that necessarily. Read The Mythical Man Month.
I don’t really see much of a problem with the incremental development of GNOME 2.x. GNOME has significantly matured from the original 2.0 release, and we’ve seen feature enhancements at every subsequent 6-month release since then. Granted there are some holes (e.g., menu editing) in the current DE, those will undoubtedly be filled over time. They hardly require a redesigned API.
The interface is well thought out and steadily tightening in terms of consistency and integration. Adaptation of developing, “behind the scenes” technologies and changes (cairo, xorg, kernel, etc.) should continue to enhance a user’s overall desktop experience.
GNOME’s 2.x series has full potential to compete with (and even transcending) commercial offerings. I would even go so far as to say that most limitations are back-end in nature. With that said, I think the best thing for GNOME would be to focus on internal code clean-up and optimizations within GTK and the core GNOME applications. This will not require a break in ABI/API compatibility, but it will translate to an even better user experience.
GNOME 3.x should be an innovative playground until a new and better way to interact with the desktop is discovered.
@Johnathan Bailes (IP: —.chvlva.adelphia.net) – Posted on 2005-04-21 21:11:22
You missed Havoc’s point entirely!! The things you listed are still 2.0 issues. The only reason to go to 3.0 is if the desktop changes in such a fundamental way that doing so in 2.0 would destabalize it.
Also to the person who said this was like Microsoft. You’re wrong. He has said nothing about him (or anybody else) starting 3.0. The focus is obviously still on 2.0. RTFB.
are they haven’t been able to develop their own personality on the framework level, they require greater presence.
This is where a lesson from KDE would be prudent. Examine the KDE projects richness of their framework, but don’t stop there, there are some issues. For instance, bindings, documentations and so on.
I think Gnome really needs to build up more powerful application frameworks. They really need to be able to leverage application embedding far more than they do now. Network transparency would be another big win, right now, it’s very hackish. They need to figure out what their relationship exactly is going to be with GTK+. In many ways, it’s unhealthy for them, since it limits them.
They have considerable strength in the meta-data department and the virtual filesystem and a good HIG and other good stuffs. If they capitalize on frameworks and really making the programmer’s life easy, they can attract fresh blood which will turn into a long and good relationship and old schoolers impressed with what they see — kinda like Mac OSX.
You realise they haven’t. There are applications that will not run on Windows.
Very few, but many, many will – even between totally different platforms like 98 and NT and onwards. How current applications do you bet will work and integrate with Gnome 3.x?
Yes, for the most part they have been able to maintain ABI comaptability, but not 100%.
That’s a cop-out I’m afraid.
Secondly, there is no rule or law that says you have to.
If you have a platform as widespread as Windows, yes there is.
Third, any programmer will tell you that being unfettered by having to maintain API/ABI allows mistakes of the past to be corrected and a system redesigned.
You can’t keep re-inventing things in that manner I’m afraid. And that, as they say, is where you fail.
Havoc is right, but failed to mention that RedHat (and others) has a vested interest in keeping things stable for the corporate desktop. RedHat has to worry about other people than hobbyists and server guys these days.
Like someone else mentioned, I’d make Mono part of the developer platform, that way developers can write in C#, Java, Python, Boo, maybe even C++ and C by the time 3.0 is shaping up. Not only that, but you’ll get a whole bunch of code that is being developed for .NET.
I would make an OO api specification for the languages bindings. Almost all other widely used languages that bind to gtk+/Gnome are OO.
DBus is moving along, but where’s the equivalent to KParts. You need that. Bonobo seems to be deprecated.
Why are society and technology always changing?
That doesn’t explain why Gnome made what were obviously broken, and religious, choices to start off with.
Because what was right a decade ago won’t necessarily be right a decade down the road.
We’re only about three years down the road.
Or to be more precise, Gnome can reasonably break that compatibility because modifying and recompiling open-source apps is trivial
I’m afraid you can’t when you’ve got a large installed base. Re-compilable or not, the vast majority of what you’ve got out there is all binary.
you can still (and Havoc makes a point of this) run old apps alongside new apps in a new environment.
I’m afraid this is the part you really don’t understand. You can run older applications alongside new ones, but it simply isn’t enough. Older applications still have to integrate seamlessly into the newer environment, along with newer applications, with as few problems as possible. I hate to say it, but no desktop other than Windows has achieved that.
“gnome is NOT fast without a ton of RAM.”
This is also a focus for 2.12 – optimization.
You acknowledge that most of your requests are due in 2.12, and combined with your main request being an emphasis for 2.12 (as well as further 2.x versions) we can see why this is such a muddy issue. Just exactly what is it that people want to do with Gnome that can not be done against Gnome 2? Why do we need Gnome 3? Nobody has listed a definitive reason that a major new version is required. Please, correct me if I’m wrong.
I’d like to see Python, gnome-python and pygtk become a core part the desktop in addition to GTK and family.
Mono and Java are marred by political and commercial interests which is harmful to free software development.
Python is independent of all that politcial nonsense, and as a bonus, it is a far more productive environment/platform.
Re: Gnome 3.0
By Jay (IP: 208.60.223.—) – Posted on 2005-04-21 21:27:28
@Johnathan Bailes (IP: —.chvlva.adelphia.net) – Posted on 2005-04-21 21:11:22
You missed Havoc’s point entirely!! The things you listed are still 2.0 issues. The only reason to go to 3.0 is if the desktop changes in such a fundamental way that doing so in 2.0 would destabalize it.
Even parellel development strips resources and time from the 2.0 desktop development.
Most of the things I mentioned are due to be fixed by 2.12 but that is a large list and I would very surprised if the gnome developers were able to add/fix all the things I mentioned in one development cycle.
I did not miss the point but should have more precise in my post. Until a number of important issues some Havoc himself mentioned like the typeahead or animation of some sort to indicate a clicked toolbar button, I think that parellel development may hurt the desktop overall and I like gnome a lot.
Re: Gnome 3.0
By Charlie (IP: —.range217-44.btcentralplus.com) – Posted on 2005-04-21 21:42:19
This is also a focus for 2.12 – optimization.
…
Why do we need Gnome 3? Nobody has listed a definitive reason that a major new version is required. Please, correct me if I’m wrong.
I believe there is no real roadmap right this second. However, there has been talk mostly by Havoc who seems to dictate a great deal in terms of the direction of gnome. The idea forwarded by him and others to make a fundamental shift from focusing the desktop on applications to focusing onto the manipulation of files as objects.
http://live.gnome.org/ThreePointZero
<hp> I’d say gnome3 should be motivated by some major UI-type changes
<hp> fundamental simplifications
<hp> and it’s probably a 2-year project
<hp> I guess I don’t mean simplifications
<hp> I mean shifting complexity to what users want to do instead of computer nonsense
<hp> – first-class user-interesting objects such as “email”, “conversation”, “document”, “contact”
shared between all apps
<hp> – less manual/micromanagey/annoying task switching (right now we have workspaces, tabs, windows,
blah blah, all essentially manual)
<hp> – rethink “extensions” from current many special extension types (applications, applets, etc.)
<hp> – arrange the UI around user-interesting objects instead offiles and windows
For example.
@David
You can’t keep re-inventing things in that manner I’m afraid. And that, as they say, is where you fail
And that’s where you’re wrong. Many commercial products work that way. I’ve worked in the software development industry for several years now. You paint dis-reality.
Secondly, you’re argument that GNOME is as widespread as windows is a laugh. Just because you don’t think they should break ABI or API doesn’t mean the rest of us realize that sometimes it’s necessary.
What I want in Gnome 3, or 2.14 or whatever is xcompmgr support. The acceration provided by it helps with Gnome’s slowness.
It’s good for Gnome to cut the fat where possible, but don’t start getting delusional and think that Gnome present day and beyond is going to run good on 128 meg.
As someone else mentioned, hardware acceleration can improve the experience by making the desktop feel less sluggish.
Time doesn’t stand still and to put a spin on a famous BillG quote “128 meg is not enough for everyone”.
Strange. KDE 3.4 has built-in (optional) xcompmgr support and I find it quite slow compared the the “plain X” KDE.
> Older applications still have to integrate seamlessly into the newer environment, along with newer applications, with as few problems as possible. I hate to say it, but no desktop other than Windows has achieved that.
Can’t let that one go. Windows 95 to XP has been bug fixing. The actual environment has hardly changed at all and where it has changed, it stands out like a sore thumb in old apps.
Mr Pennington’s comments relate to a much more drastic change. I think this is comming on the back of a wave of desire for innovation in Liunx as a reaction to the hype surrounding Longhorn. The F/OSS community would dearly love to release something significantly better than Longhorn and get it out the door before Microsoft do. This can been seen in the development of X.org, GTK+ and other GUI projects. KDE seem to want to implement a Longhorn-like enviroment before MS do.
Gnome 2 is very functional but uninspired. If Gnome 3 is to be a Longhorn killer, the groundwork needs to start now. The whole conception of the desktop needs to be re-evaluated in the light of new ideas. Hence the need to fork.
I’ll agree with you in that it needs to happen sooner than later. The discussion for the foundations that developers will be using has to start soon for Gnome to compete with Longhorn.
Longhorn will have .NET built in, Avalon, all sorts of things.
What is Gnome going to have, people hacking in C code still?
That doesn’t explain why Gnome made what were obviously broken, and religious, choices to start off with.
Care to explain rather than make vague complaints? Thousands of happy GNOME users don’t agree with you, which hardly makes their mistakes “obvious.”
We’re only about three years down the road.
And that’s why Havoc and the rest of the GNOME developers have been very reluctant to start on the next major version of GNOME — that’s what the article was all about: they’re planning for the far future. Did you read the article?
I’m afraid you can’t when you’ve got a large installed base. Re-compilable or not, the vast majority of what you’ve got out there is all binary.
No, “what you’ve got out there” is not at all a binary world. I challenge you to find me one “large installed base” that upgrades its GNOME to a new major version (2.x->3.x) while keeping all its binary GNOME application packages.
I’m afraid this is the part you really don’t understand. You can run older applications alongside new ones, but it simply isn’t enough. Older applications still have to integrate seamlessly into the newer environment, along with newer applications, with as few problems as possible. I hate to say it, but no desktop other than Windows has achieved that.
And you can still run GNOME 2 apps within GNOME 2 for a long, long time after GNOME 3 is released. My argument was that GNOME 2 doesn’t have to (and won’t) die as a result of GNOME 3. This is where open-source has an advantage over Windows, where all XP users are now being forced to upgrade to SP2 which breaks many apps.
P.S. I don’t think that you are really “afraid” of the things you say you are “afraid” of. You should stop using that term.
“I want MONO to become a key requirement for GNOME 3.”
This is an intresting point. A few things:
1.) Red Hat, Sun, and Novell/Ximian are very large backers of Gnome.
2.) Mono directly competes against Sun’s Java, both server and client side. Red Hat still has legal concerns over Mono.
3.) Both Red Hat and Sun are NOT pushing real alternatives to Mono. Obviously Sun can’t since Java isnt opensource and they refuse to back opensource implementations (GCJ, Kaffe, etc)
4.) Novell is pushing full steam ahead with Mono. Already Mono has a HUGE presence, many popular applications already rely on Mono.
If Mono becomes a dependency of Gnome, will Red Hat/Sun support it? Will they fork? Their position is just so strange. Why don’t they push an alternative?
A paradigm shift has already begun. With people being more connected then ever, we need to get away from the desktop/folder-type of thinking and get into really active destops (not the M$ version) with widgets, gadgets and everything else.
What Havoc is suggesting would create two camps… Old and New. Unfortunatelly, this means one of two things, 99% of programmers migrate to the new project and the old project suffers or there’s a split 50/50 that makes the new project suffer. Look what is going on with the 2.4 branch of the Kernel. I challenge anyone to give me the date of the last update off the top of their head and what improvements it had.
The trade off is to either make GNOME 2 really stable or to innovate with GNOME 3 to stay ahead of the curve but you cannot do both at the same time. I would suggest to take a really hard lesson from Microsoft… Upgrade, stabilize and tweak!!!
My hope for GNOME3 is that the whole system encourage a development style where front-ends declare the api’s instead of the back-ends.
With API-stable front ends mutliple back-ends could share front-ends instead of the otherway around, as it is now.
From the article:
GNOME 2 is in an important sense “the same thing” as GNOME 1, though it’s certainly much more robust and polished.
*gasp* That must certainly be the reason why I liked GNOME 1 better…
>What Havoc is suggesting would create two camps… Old and New.
If they go for that solution it gonna get interesting to see how they solve it. The Gnome project has a stellar example of some of the problems with this close to home, just look at Anjuta/Anjuta2.
“I want MONO to become a key requirement for GNOME 3.”
“I’d like to see Python, gnome-python and pygtk become a core part the desktop in addition to GTK and family.”
I’d like to see Gnome depend on as few languages as possible. Presumably that would reduce resource requirements? (not an expert here)
About Optimizations
By Lumbergh (IP: —.107.196.152.charter-stl.com) – Posted on 2005-04-21 22:22:03
It’s good for Gnome to cut the fat where possible, but don’t start getting delusional and think that Gnome present day and beyond is going to run good on 128 meg.
As someone else mentioned, hardware acceleration can improve the experience by making the desktop feel less sluggish.
I mentioned the 128MB earlier in a post to make a point that the slowness experienced in gnome appears from my personal experience to be very RAM related (memory footprint associated).
There was a time when Linux was known for its ability to run well on older workstations. I never expect gnome to run as well as XFCE for example but that desktop envrionment was built from the ground up for speed and works well with 128MB and it has a xdg compatible menu editor and browses my windows network with no issues all unlike the current version of gnome which I still prefer by the way in case you are taking me as a basher.
Hardware accleration can make things feel less sluggish but then again xcompmgr actually slows my desktop experience down right now. So that part of the other poster’s solution just does NOT pan out, yet. But man I am looking forward to the day it does.
Frankly the goal for gnome should be to be the faster desktop environment between it and KDE. The idealistic goal should be to be almost as fast as XFCE. But that is all IMHO. It looks lean, simple and clean. It gives the impression of speed with this approach and as long as it is considered slower than KDE then that will be a problem for the project in terms of users out there in the world.
Nobody waxes XP of their laptop and installs a new OS only to turn around and run the desktop everyone says is slower. It puts my favorite desktop project at a disadvantage.
@Jonathan
Frankly the goal for gnome should be to be the faster desktop environment between it and KDE. The idealistic goal should be to be almost as fast as XFCE. But that is all IMHO. It looks lean, simple and clean. It gives the impression of speed with this approach and as long as it is considered slower than KDE then that will be a problem for the project in terms of users out there in the world.
There’s one problem. While the goal of running on low memory systems sounds ideal and nobel, it doesn’t fit with reality. Modern operating systems, good or bad, small or large, all require greatly increased resources.
Users are becoming more and more demanding about how integrated their entire desktop is, and how much it does for them. There is a price to pay for a nicely integrated desktop with all the bells and whistles that are being asked for. You can’t have the ability to integrate calendars with clocks, all kinds of remote administration capabilities, graphics and multimedia support, resizeable graphics, multi-lingual support and a host of others in a desktop without using a lot of resources.
Additionally, there is always a tradeoff when developing between time to market and doing it right. Sometimes you can do something right, and have it work 100% correctly, but not be resource efficient or optimized. I’m not saying that it’s impossible to have efficiency as a focus with a major desktop, but you have to realize that the major desktops to innovate are going to have to leave the “slow old” and “low resource” systems behind. Desktop environment like XFCE and others will remain for those that must run on these lower systems. Targeting software for systems based on resources is always very hard to do when striking a balance against the desired featureset.
RE: Optimization
By Shawn (IP: —.everestkc.net) – Posted on 2005-04-22 02:21:00
….
There’s one problem. While the goal of running on low memory systems sounds ideal and nobel, it doesn’t fit with reality. Modern operating systems, good or bad, small or large, all require greatly increased resources
Oh my frickin’ goodness that is why I said that ideally it should be faster than KDE and apire to be almost as quick as XFCE.
NOT and I will say it again NOT to necessarily run on as low a set of resources as Windowmaker (as an example) or notice I did NOT say that it is a reasonable goal for gnome to be as fast as XFCE.
I do not feel it is unreasonable to feel that gnome should be at least faster than KDE (as a goal once again).
People get very defensive when I even mention this as if I am calling for gnome to be small enough to run on a Pentium 200 box with 64 MB of ram. I am — wait here comes the capital letters again — NOT.
I am just saying that even Novell and the gnome project members themselves realize that optimization is needed and hence the need for the memory optimization bounties.
Even when the gnome developers themselves place bounties becuse they know this work is needed, god help the user that says this should be a major goal because they are backwards facing feature hating trolls? No. I listed a ton of features that I personally think are important for gnome 2.x.
I just think that optimization is important and too many parts of gnome bleed memory and the desktop is not as fast as it could be without at least 512MB of ram and the fact that ram is cheap is not an excuse to ignore the fact that as we approach 2.12 (uh that is the 12th minor version of the gnome 2.0 series desktop) that it might be a good time to go back and hunt down those mean memory hungry bugs.
Whew.
Sorry rant off and all that. But I am always looking for speed increases in linux — optimized packages, faster bootups, dma tricks of harddrive and I am looking forward to a gnome-terminal that does not suck up inordinate amounts of memory and that is already on the way god bless those gnome hackers. I just think the platform is mature enough that is time to optimize.
KDE did optimized the desktop a bit from 3.0 to 3.1 I think and people praised them. Why would it be a sin for the gnome folks to try?
On my PII with 128 MB of RAM, IceWM flies, no problems. Recently, i did an experiment: installed ‘gnome-core’ to minimize the crud. Once i was inside Gnome 2.8 (using Sarge), i disabled the gnome splash screen, the wallpaper, switched the gnome-terminal with aterm, chose the default theme, nuked the default wm Metacity, and replaced it IceWM:
$ icewm –replace
logout/login
now i had the icewm look including the taskbar so i had no use for the gnome upper bar, so i disabled it, and ended up with a fast gnome that looked exactly like icewm but 183 MB fatter.
Gnome/KDE are obsolete. Nuked it with debfoster, back to good all IceWM. Regained all my space back.
“The Gnome 3 Schedule and Plans”
All I read was some guys opinion in his blog on how gnome3 should be developed……
RE: The Gnome 3 Schedule and Plans??????
By mendicant (IP: —.abhsia.telus.net) – Posted on 2005-04-22 04:25:01
“The Gnome 3 Schedule and Plans”
All I read was some guys opinion in his blog on how gnome3 should be developed……
To give you a better overall view of some general ideas about the direction for Gnome 3.0 —
http://live.gnome.org/ThreePointZero
I wish Gnome 3 features Thunar (http://thunar.xfce.org/wiki/ui:suggestion-20050320) instead of Nautilus, and a global menu
Keep in mind, there’s no actual backend code yet for Thunar (the screenshots are Python mockups for discussing UI). It does look promising from here, though
Couldn’t be worse than XFFM… 
Care to explain rather than make vague complaints? Thousands of happy GNOME users don’t agree with you, which hardly makes their mistakes “obvious.”
A decent development base and framework. Starting something and making decisions based on not quite liking particular licenses is never a very good start. If you don’t have the resources or software available to do something like a desktop environment with the right tools to start off with, then you’re always going to be running on empty at a later date.
they’re planning for the far future. Did you read the article?
Yes, and it doesn’t look like it. Besides, it doesn’t alter anything – good backwards compatibility is demanded in the wider world if you want to get anywhere. I take it Gnome 3 will be ten years away?
No, “what you’ve got out there” is not at all a binary world.
Yes, it is. When you have these little things called third-party applications it is ridiculous to assume that all of these are somehow going to be magically re-compiled and re-architected. However, because Gnome isn’t popular enough to attract widespread third-party ISV support you wouldn’t know about that, so at the moment, it isn’t a problem. If people want to get anywhere though, it is important.
I challenge you to find me one “large installed base” that upgrades its GNOME to a new major version (2.x->3.x) while keeping all its binary GNOME application packages.
That’s because:
a) Gnome isn’t popular enough to attract widespread ISV support for third-party applications.
b) All of the applications used on Gnome are either a part of a Gnome release, or are open source projects that can easily be re-compiled and re-architected.
You have to start as you mean to go on.
And you can still run GNOME 2 apps within GNOME 2 for a long, long time after GNOME 3 is released.
You haven’t read what I’ve written. Old applications need to be first class citizens, with transparent and full access to new any frameworks and the ability to transparently inherit new features and components where possible.
My argument was that GNOME 2 doesn’t have to (and won’t) die as a result of GNOME 3. This is where open-source has an advantage over Windows, where all XP users are now being forced to upgrade to SP2 which breaks many apps.
A term often used when anyone is having problems with any open source software is “upgrade to the latest version”. “Oh, it won’t die because it’s open source” is a very nice sentiment, but it doesn’t work in practice I’m afraid. Besides, many vendors are quite happy with things that way, whilst claiming that because it’s open source customers are somehow future proofed
.
P.S. I don’t think that you are really “afraid” of the things you say you are “afraid” of.
It’s called English.
You should stop using that term.
No.
Emotional rants, zealotism from both sides and trolls are over the place. But to cool it down, I would like to say something:
* GNOME has a rather large and very active user base – http://www.gnomefiles.org, http://www.gnomedesktop.org is to prove that;
Also I don’t want to discuss this because I’m not buy this common argument about user base as I don’t develop commercial software – I’m looking for improving GNOME expierence for myself, so I help developers with bug reports and testing. Yes, I’m geek with very big expierence with lot of desktops and systems, but I still prefer easy to use desktop. And somehow GNOME, which is something between OS X and Xfce, suits the best for me.
* Bashing about GNOME licence decisions and not being ‘developer friendly’ – for example GPL versus Trolltech commercial license question – is still bashing and not constructive discusion. Lot of things has been changed – GNOME/GTK libraries now are mostly LGPL, thus giving posibility to create commercial software, using GNOME interface, which is used by Real for Real Player and by Adobe creating it’s newest Adobe Reader. Both heavily beneficts from using modern GTK toolkit, as they look much better and sexy. Lot of free and commercial documentation from various aspects of GNOME development have been created, just check out gnome.org web page Developers section. GNOME developers are open to newbies and there is #gnome-love channel for them, Bug Thuesdays, etc. I love that community feeling, because, there is lot of disscussions and even disagreement, somehow we have managed to find a consensus about something we should have to.
Also I would like to point out that community like freedesktop.org was more supported by GNOME at the beginging. And I really love to see that it works.
I guess it all dependends what someone means when saying “should depend on $LANGUAGE” or should be in the core.
I think having the base libraries all written in the same language has some advantages, e.g. all libraries can equally be handled by language bindings, all core developers can understand all libraries if necessary.
Of course having base applications written in other languages would have the advantage of proofing the matureness of the respective bindings, thus attract developers familiar with that language.
Some things need a clarifying here:
* No, MONO won’t be used much in core services of GNOME 3. HOWEVER, it will be heavily supported to allow make lot of good desktop apps (and even port Windows ones) on GNOME. I guess other bindings like for Python, Perl, C++, Java, Rubby will be very up to date and in the right shape. I guess GNOME 3 will be more ‘development friendly’ for ANY language you will pick up to use for your app.
* Mono patent question was, is, and will be actual even after 5 years. However, with backing from IBM and Novell, I guess Microsoft wouldn’t even try to threat open source community. Of course, it is not like everyone has to agree with Novell decision to push Mono – but actually I have no other way but to trust them because they have rather big layers army which will work on our side if something bad will happen;
So Mono won’t be core, but will be heavily supported (even officially). I think it is what suites the best most of us.
You can’t be serious right???…. Why would you want to bloat Gnome even further?. You do not need to have a thousand different languages to make Gnome functional. Your idea of having so many libraries bundled into gnome doesn’t make sense. They should be kept as separate components so people have a CHOICE. I for one hate Mono and have not seen any application that depends on it do anything better than what’s already available. And as far as Mono being a Global player please provide some form of evidence to back up your claim. If and when RedHat and other major Linux distributions decide to ship Mono as a core component because it becomes a necessity, then ‘maybe’ I will agree with your statement.
What matters is that GNOME does not require too many packages. A language binding is an optional package, not a core package. Systems not running an application using a particular language binding should not have to install (and maintain, etc) that particular language binding.
It’s important to keep the core as lightweight as possible.
But of course it is also important to offer language bindings in optional packages so applications developped in any language can run using the GNOME look & feel.
However, I think that providing language bindings to GNOME, may be an error. The underlying library is GTK+, and language bindings already exist for GTK+. If apps starts using GNOME bindings, I fear those apps won’t be able to execute on a KDE distro. Hence providing GNOME binding has the potential to create the situation we had until 5-6 years ago when KDE or GNOME apps could not run in another other DE.
> You can’t be serious right???
Actually I am serious. Look using C (A structural Language) for a Desktop will get you nowhere on the long run. Applications often needs huge refactoring of code once some stuff is getting changed which of course is a drawback and requires a lot of time and resources. Recources that the GNOME people don’t have and the overall speed and process of creating new corporate applications is slow. To be productive in application development C is seriously a wrong choice and many core elements inside GNOME have realized this. When you dive on http://planet.gnome.org/ you see people celebrating MONO (A OOP based Technology and Framework) and expressing how productive they feel using MONO for rapid application development. They clearly getting more productive and more done in half the time they usually needed when using C. The best thing would be to rewrite core elements of GNOME in MONO over the next upcoming years and have everyone dive on MONO. You also don’t really need any bindings anymore because MONO replaces all them.
> It’s important to keep the core as lightweight as possible.
What you describe and want sounds more like XFCE. I think you should throw an eye on this nice Desktop Environment I think for hobbiest users like you this might be exactly what you want. It’s written in plain C, depends on C only. GNOME has been focusing on the corporate segement for the past couple of years and the key argument here is to satisfy corporate demands and having mother and father getting work done rather than fiddling around with useless stuff.
That may be so, but what your saying is to actually completely re-write Gnome.That task alone is one of massive proporation and I doubt that will ever occur too soon. By the time thats done some-one else will have come up with a better language and you will be starting from square one again. I think improving on whats already available is far better approach but of course thats my opinion only
Yes XFCE is nice, but My point was general about keeping cores light (whatever a core is).
But I am NOT a hobby user. On the contrary. The point I make is from a corporate point of view, where manageability is crucial.
This is why XFCE is attractive to corporations, and why for example, HP made it the default DE on some of their desktop systems.
Hobby users do not know or care about the internal architecture and see more as better. System administrators in businesses see more as worse/bloat.
That is why XFCE is, despite its limitations, a good choice for corporations, and why GNOME’s core must be kept as light as possible. Because system administrators do not want to spend time manageing, uprading, supporting Mono packages force feeded into GNOME when no one uses Mono apps on the desktops they manage.
> That may be so, but what your saying is to actually completely re-write Gnome.
This is happening anyways or is in the process to happen. There is a huge amount of stuff becoming DEPRECATED either it has already been DEPRECATED or will become DEPRECATED soon. Nontheless the huge refactoring will happen either way. Be it with GNOME 2 or 3 but peeking at all this in a whole you will conclude that rewriting everything in sane MONO by using C# will be faster and make you more productive than dealing with the huge refactoring of the old code. Some of this code still contain stuff from former GNOME 1 times.
Please explain “GNOME’s core must be kept as light as possible.” and also explain “what’s wrong on jumping on with MONO”.
Deprecation is an ongoing process with most things. It isn’t reserved for just Gnome. If something is deprecated it means something has usually been replaced with something better or simply isn’t required any more. It does not mean its written in another language. The applications which have been deprecated in Gnome have not been replaced with Mono applications
MONO is a global player and urgend requirement these days, there are hopes that with GNOME 3 towards GNOME 4 people can start rewriting key GNOME libraries using MONO for rapid application development.
What a great idea. People are already complaining that GNOME 2 is painfully slow on older computers. Writing key libraries in a managed language won’t improve that aspect…
It’s true that MONO (as much as I hate it; why the open source community decided to follow the specs of their “worst enemy” instead of developing a new language and a CLR/VM tailored for their needs?) is going to be an important aspect of GNOME, but it would just be too dumb to write everything in MONO.
come on guys mono dont have yet a decent gtk-sharp binding
(the actual stable release i guess is based on gtk2.2 )
how can unstable binding be a serious contender on our fine
c libraries well written ?
the gcj project has matured enough that it could be used to write gnome apps right now. I would prefer it to mono if a base different than C is going to be selected for gnome 3
As you can read in one of my earlier posts then you see that I welcome that more languages should be supported out of the core box.
Of course, but there is a difference between supporting multiples language and a complete rewrite of the core libraries for a single CLR. That’s what you are suggesting and that’s what I am not keen to see, not C#.
However, I think that providing language bindings to GNOME, may be an error. The underlying library is GTK+, and language bindings already exist for GTK+.
No, a desktop definitely needs bindings for its APIs, not only for the toolkit.
Otherwise applications written in other languages than the core language can’t use desktop services or desktop integration features.
That situation already shows today when applications only use GTK+ or Qt, they are neither GNOME nor KDE applications.
This might be desirable for some authors, but a lot of developers prefer to use the huge advantage that using desktop APIs gives them over only using toolkit APIs.
If apps starts using GNOME bindings, I fear those apps won’t be able to execute on a KDE distro.
That has never been a problem.
As long as both environments are based on X11, at least on Unix/Linux, their applications can alway be run side by side.
To be a boost for a desktop the API bindings don’t have to be in the core libraries, but they have to belong to the release, i.e. alway up to date.
If there are 21 persons there’s a demonstration that will exist at least 31 programming languages…
It’s a joke, but Gnome “platform” is getting fat and fatter: this new sw needs this binding to work and also the x plugin.. it’s not possible to continue in this way. I like Ruby language, but a lot of sw for gnome isn’t written in Ruby so i’ve the ram full of trash: I’ve 35mg for python, then I’ve to load ruby, perl, java,… I’m tired of this all virtual machines!!!!!! Please choose mono or java, there are already projects like jython jruby ironpython,.. we don’t need other projects like parrot! parrot will be an alternative is it can to run mono’s bytecode faster
Gnomw 2.x is not even close to ready yet.
First of all it is not feature complete in a sense that it can be used to manage all aspects of desktop computing. E.g. there is no user administration tools that can handle LDAP and other types of user databases. It still have a long way to go before it is even close to the functionality of KDE kio-slaves. The trashcan could do with a lot of improvements, such as a way to restore trashed file to its original position.
There are also a lot of application that need to be fully Gnomified, even ones that people take for granted in Gnome environmnets such as the gimp. If major changes are made to Gnome they will never catch up.
So, please wait 2-3 years before starting thinking of 3.0.
Windows hasn’t changed since NT4, and as it looks now it will not change much in Longhorn eiter, so why should Gnome.
Make 2.x work first.
By Uno Engborg (IP: —.sp.m.bonet.se) – Posted on 2005-04-22 there is no user administration tools that can handle LDAP and other types of user databases. It still have a long way to go before it is even close to the functionality of KDE kio-slaves
No administration tools that can handle LDAP?
http://diradmin.open-it.org/
Agree with a lot of what you say but directory administrator rocks socks.
However, I think that providing language bindings to GNOME, may be an error. The underlying library is GTK+, and language bindings already exist for GTK+.
–>No, a desktop definitely needs bindings for its APIs, not only for the toolkit.
Otherwise applications written in other languages than the core language can’t use desktop services or desktop integration features.
[i]
Agreed, but it’s only for a minority of applications which have to interact with a particular desktop. And if they have to interact with a particular desktop, these are desktop-specific “applets” or the desktop’s own tools which are non-portable across desktops anyway.
If apps starts using GNOME bindings, I fear those apps won’t be able to execute on a KDE distro.
–>That has never been a problem.
As long as both environments are based on X11, at least on Unix/Linux, their applications can alway be run side by side.
[/i]
No. Take the example of a KDE distro without the GNOME package (lastest debian for example, I think). Try to run a GNOME application. The GNOME libs are not installed and no GNOME-app will work. The exception is when KDE emulates GNOME-entry points.
So going back to the initial point, if you include Mono inside GNOME, and because of that bundling, force apps to rely directly or indirectly on Mono, those applications will not work on a KDE-only distro.
To summarise:
A programming language must not be included in a DE. Period.
A programming language and its libraries/runtime must remain a separate package.
Agreed, but it’s only for a minority of applications which have to interact with a particular desktop
Hmm, this could be different in GNOME, but in KDE all applications interact with the base libraries, for example to get the standard text/icons/shortcuts for menu items, etc.
The GNOME libs are not installed and no GNOME-app will work.
Well, obviously.
Without having libc installed a lot more other programs won’t work.
Usually the package manager takes care of that and has the respectve libraries as dependecies of the program, thus you install them automatically.
That would also happen with applications which are based on a binding, the respective binding would be installed as well.
That’s why I wrote that the bindings have to be part of the release packages, but they don’t need to be in the very core package.
The exception is when KDE emulates GNOME-entry points.
I am not aware of something like this, I believe a GNOME application always needs the GNOME libs, just like a KDE application always needs the KDE libs.