This is one of the least relevant and useful articles I have seen OSNews carry. So it would be nice to have my compiles done 1/6th faster... but not as important as my working environment. Which is the sort of thing Eugenia reviews.
People who are actually working and not just drooling over hardware tend not to care as much about small fluctuations in performance (servers are of course a different matter; though even there things like reliability are much more important). When you're working at a workstation, people can hardly tell the difference until you *double* performance.
"Quantitative" data doesn't necessarily mean "better" data if its not measuring something terribly important.
In any case, whether you think its useful to have tons of benchmarks are not, there are a million sites already doing them. OSNews is doing something different.
I'm not as knowledgable in this area as the DBus developers, so I can't tell you all their reasons.
So one thing is that CORBA tends to take a lot of memory, at least relative to DBus and DCOP. A lot of developers will not add a small feature (and lots of lost small features is a big loss) if it means linking with a big library.
For this technical reason, and probably for other really good ones too, but also probably political/historical... I don't think a CORBA based solution would fly with KDE. A system DBus that daemon / linux platform developers can target to communicate with "desktop land", regardless of what desktop people use, is very important. Both KDE, GNOME et al need to be willing to *use* this bus. It doesn't even have to replace their old system (CORBA + Bonobo for GNOME and DCOP for KDE), though IMO it would be nice if it did.
SystemServices: Hardly wheel re-invention. If you read the linked-to article you'll find that none of the listed "init replacements" address any of my four major goals. They addressed their own goals, which are nice ones I'm sure, but not things that the desktop needs. In fact, the only thing they really add over init that's interesting to me is a dependency system + parallelization. And RH's internal work on init scripts has suggested this results in only small improvements (neighborhood of 30% I believe) in boot time... which is better but not dramatic. Dependency systems are pretty trivial to implement and a dime a dozen, in any case.
DBus: yeah, its a lot like CORBA. Its even more like KDE's DCOP. In fact, its a lot like DCOP. You could even think of it as a major iteration of DCOP. So look, GNOME has been using CORBA for IPC for several years and its still something people avoid using whenever possible. KDE used CORBA for a while, and even with the comparatively nice CORBA/C++ bindings found KDE devs avoided it when possible. CORBA is a freaking PITA to use for lightweight desktop-style stuff. DCOP was the solution (its a good solution, GNOME should have done this ages ago): make it easy enough to use that developers will actually readily communicate over DCOP. Communication protocols have no inherent value on their own. They acquire value when there's things to talk to. Developers won't use the API unless its simple. You can write very simple comm layers for KDE and GNOME around DBUS. Even if we GNOME folk wanted to use CORBA (we don't), KDE wouldn't, and a requirement for DBus being truly useful is that KDE+GNOME have to be willing to use it. End of story.
HAL: I'm not really familiar with discover, so I'm not going to shoot my mouth off (much *grin*). From ransacking the web page you linked to, it doesn't look like discover really supports the sort of "central daemon with notification signals" model that we need to provide good hardware support on the desktop side. Without that... its sort of useless to us. It looks a lot like Kudzu, which is a good thing (and trust me, Havoc who proposed HAL in the first place knows about Kudzu, and probably discover) but it simply isn't what those of us who are in the ditches writing this desktop code need.
Moral of the story: a superficially similar "solution" does not necessarily address the issues that we as desktop developers face. We propose these things because we have concrete problems to solve. Sometimes the problems are not obvious until you try to do something and end up butting into them. We're lazy people, just like anyone, and we don't like:-)
I suppose it is probably too late to inject comments and have them moderated to the point of visibility as the madness has largely subsided... but here's to futile acts;-) I was not really intending Storage to make a big splash right now, I wanted to keep it low-key, but I guess the damage is done so I might as well comment. I'm sorry that I didn't have time to put up a more technically-oriented exposition of Storage. *shrug*
Slashdot has focused almost exclusively on the "database backing". Guys, this is an implementation detail. Its an important one, but I didn't start off this design thinking "lets write a database backed filesystem store". A set of design goals was established (largely mirrored in the features page). Storage is a lot more than just a database backed XML store. Please read the features page. The "searchable" stuff is nice, but equally important is providing persistent objects, uniform access (the same URI for a local storage node works globally assuming your computer has a publicly accessible IP address), an improved model for revision and "saving", the ability to localize filesystem resources, and due to a standard object format greater transparency of filesystem resources to the OS which will be useful in weakening the barrier between "apps" and "desktop" found in PCs (and not so much in, say, cell phones and pdas). This is also a key piece in an overall design of the desktop's interaction structure which I haven't had time to write up for the web.
I'm not trying to make any claims to being the first or being highly innovative, but I am happy to make claims about improving the user experience. That said, contrary to what people are saying, to my knowledge other than the superficial layer of database backing, Storage's features do not have a "one to one" correspondence with any existing system, BFS and the only vaguely specified Windows Future Filesystem included. Most importantly these components do not seem to be a part of the same overall interaction design model that Storage is intended to support. Storage is just a stepping stone, albeit a pretty disruptive one.
I've been quiet about this project, even inside GNOME. Storage as written today was primarily written by a team of Stanford students as their CS senior project. I've since been working with a few good GNOME developers including the person working on Medusa (Curtis) and the Epiphany maintainer (Marco). They were independently developing a metadata system for GNOME, which it looks like we may implement on top of Storage as a first major test of its capabilities. But nothing is certain right now. But the short story is that although storage is being developed by GNOME developers and I serve as usability project lead, its not an official GNOME module at this point. GNOME developers would need to corporately buy into both the Storage vision and the overall desktop design. This may never happen, and if it does, its going to be very slow in the coming.
Some technical notes... that site is sparse on technical information so I'll fill in some for the curious.
The data store is backed by Postgresql. Postgresql rocks, though some of the features like instant notification of object changes and live queries do not fill well with existing SQL. We have ways to do all of this using Postgresql extensions, but sometimes its a little tricky and/or hackish.
A lot of the proposed interface will rise and fall based on the quality of the NL processing. Storage is currently using some pretty cutting edge linguistics theories and tools... notably working within the basic LinGo framework. This includes using theories/systems like HPSG (Head-Phrase Structure Grammar), MRS (minimal recursion semantics), and being able to use a set of existing wide-coverage grammars such as the ERG (English Resource Gramm
Most of his UI complaints seem to center around metatheme, the "Desktop theme editor" etc. Guess what? Metatheme was dropped from the GNOME 2.0 release about 4 months ago because it was deemed sufficiently unusable. While we plan to eventually have a single "themes" desktop preference page (that will, of course, replace the widget theme, etc, we're not going to be duplicating menu entries), we decided to for GNOME 2.0 because Metatheme's interface sucked so badly. It needs to be totally redone. I agree 100%.
It seems like 3/4 of his rant against GNOME usability is based on things installed by Metatheme. It is absurd to complain about GNOME's interface based on something that was dropped from GNOME 2.0 because we knew it sucked.
"Per the GNOME Foundation's charter, any contributor to GNOME is eligible for membership. Although it is difficult to specify a precise definition, a contributor generally must have contributed to a non-trivial improvement of the GNOME Project. Contributions may be code, documentation, translations, maintenance of project-wide resources, or other non-trivial activities which benefit the GNOME Project. While large amounts of advocacy or bug reporting may qualify one as a member, such contributions must be significantly above the level expected of an ordinary user." from the GNOME foundation membership qualification page.
I don't think RMS fits these qualifications. The GNOME foundation membership, and all the more the board (almost all GNOME contributors are foundation members) should be active members of the GNOME community. Simply "being RMS" does not qualify one; the foundation is intended to represent the interest of those who make it happen, that is contributors.
As a minor side niggly, the candidacy period is over and I didn't see a message from RMS, so technically he isn't qualified to run this year anyway.
Perhaps he'd like to contribute to the GNOME project and re-apply next year?
GNOME will come to Solaris, its just a matter of Solaris 9 being deployed before GNOME 2 is finished. Sun really wants GNOME 2 to be the first "officially supported" release of GNOME they ship (they have already done an unsupported technology preview CD). Lots of Sun developers are working on GNOME, and they're still pushing to get GNOME in Solaris as quick as possible (probably in an update to 9).
Bonobo has been distributed with GNOME since GNOME 1.4. It is a more flexible comprehensive architecture than KParts, and implements a lot more features you'd find in something like COM than KParts. The tradeoff is complexity...Bonobo is based on CORBA which has bright points, but also can make things more difficult for the programmer at times. Bonobo has undergone a lot of revisions for GNOME2 and promises to be even better than before. KParts is not an analogue to COM, it is basically an embedded rendering system with added smarts (which is very useful, but not really like COM). WRT to GTK....this is why we are about to release GTK2, which is a major rewrite. Bot the technical aspects, and user aspects, of the widget system have been redone and improved. Incredible font and internationalization support for "unusual" languages have been added through Pango, and a great accessibility framework have been included, making *nix environments accessible to still more users.
GtkHTML2 should be a major option for the GNOME2 desktop. GtkHTML1 already exists for light rendering. The Mozilla component is still the most comphrensive solution for browsing the web, but KHTML is putting on the heat. Good stuff, glad to see some competition in this arena.
KDEs ability to use XRender had little to nothing to do with "components". It had to do with KDE applications already making use of a font wrapper in QT rather than directly manipulating X fonts (probably a result of TrollTech having markets outside of X and hence needing this sort of system detail wrapped). GNOME anti-aliasing fixes have been very slow in the coming, but they're running just fine on the machine I'm typing on, and will be a part of the default environment in GNOME 2. "rendering large text and scaling it down" is sometimes called ANTI-ALIASING . Anti-aliasing is any sort of filter function that removes or alleviates artifacts caused by by aliasing, including scaling down. Nautilus uses freetype to do its anti-aliasing and it works just fine.
I really think this point is debatable either way. *shrug* I think GNOME is much prettier, but I understand why some people disagree. I suppose it all depends on your taste.
Yeah, that's whats going on. I work on GNOME because I'm trying to further the evil plans of GNU. Most of us have little or no affiliation with the free software foundation or the GNU system other than using the GPL license.
There are lots of points with great merit comparing and contrasting GNOME and KDE, so you really shouldn't have to resort to this sort of misinformation. I think the biggest thing KDE is doing right that GNOME is sucking at is having quick release cycles. We wait too long to get changes out to users, which tends to make user improvements to the core desktop more sluggish than they should be. We're gunning for a really quick turnaround release for GNOME2 - GNOME2.2 with primarily user improvements (using a lot of the new architecture that has been rewritten and/or added). Also, significant usability assesments and rewriting of problem areas is being done, both for GNOME2 and post GNOME2, which should improve the reach of the desktop to a whole range of new non-technical users in the years to come.
The glorified stature of the window manager is an odd architectural quirk of X-Windows. X-Windows is fundamentally concerned about, well, windows, so the window manager was pretty much *the* only application that every X system was running. Consquently if you wanted to add some feature (say a virtual desktop pager), you tried to get it into the Window Manager, because the window manager was already always running.
This "window manager is everything" view is actually sort of primitive. Most advanced operating systems have turned the window manager into a really mundane implementational detail that even programmers hardly care about. BeOS, Windows, MacOS, etc.
I hope this trend continues to GNOME & KDE...and we see the disappearance of those insanely bloated window manager preference dialogues and see the window manager behaving like the submissive quiet little technical detail it should be (at least from a user's perspective). Check out Havoc's latest project "Metacity" for an example of a well behaved CrackFree(TM) window manager.
Can you explain to me which fonts aren't in widgets? Pretty much
every piece of text you see in the screen, from the text in your
mailreader to the text in your web browser (though, due to evil
hackery, this patch doesn't work on Mozilla) is in a widget. Get
a clue dude. With regards to improvement...I notice a pretty big
difference at 1600x1200. I suppose it all depends how picky you
are about your text.
If display technology goes the in the direction of this particular LCD, you are probably in luck. Other than paying the cost for features you don't need (but we all do this to some extent or another when we buy almost any product), this LCD will give you a fairly normal viewing experience. It only splits the image between the eyes, no distortion or shuttering or other annoyances.
Also, this LCD has the option of switching to 2D mode which gives better resolution and brightness. As long as that tradeoff exists I suspect you'll see even 3D LCDs offer this option for a long time to come, so rest easy.
Your post is based on the (rather poor) assumption that the demise of Eazel is a step in the ultimate degredation of the GNOME project. Even as an (ex) Eazel employee I think you underestimate the resilience of the GNOME project. For one thing, many of us who worked on Nautilus as Eazel employees will continue to work on Nautilus. The reason Nautilus appears to have relatively few volunteer contributors is it tended to hire people who made significant contributions! I'm sure most of us who started that way will continue to hack on Nautilus.
It saddens me greatly to see so many in the free software community scrambling to exploit the fate of their brothers. Do KDE users truly enjoy seeing their fellow project suffer setbacks, or is it the out-spoken minority? Though I can't speak for other GNOME developers, I personally feel more of an affinity than dislike for the KDE project. We're doing the same thing. We're working for the same goal. Doesn't that make us comrades rather than enemies?!?
"but KDE would be the only desktop environment / component framework"
I might remark snidely that KDE does not yet have a component framework. It has a method for inter-program embedding (KParts), but this is not the same as a component framework. poke, poke. This is a great example of how it is *still* beneficial to both projects to have the other around. True, there is some duplicated effort, but my hope is that Bonobo and OAF will prompt the KDE project to strengthen KParts to the extent that it is a full component framework. Similarly, there are ways where we (the GNOME project) are lifting useful features from KDE. Lots of people seem to pay lip-service to competition but get squeemish when they see it at work.
"This really sucks for the GNOME users and developers. But what can you do?"
The same thing we have always done: Write code. Fix bugs. Write documentation. Translate. Polish. Add features. Keep improving. What do you do?
Nautilus runs on Solaris. This was something I put a lot of work into prior to release. We're not releasing binaries, but rather have been assisting Sun in creating their own performance pack for GNOME. Hopefully this will impact the largest number of Solaris users.
Nautilus also has packages available in Mandrake Cooker, I believe.
Just in case people take this wrong, it really was a hard situation. It wasn't really like "good job, you've finished 1.0 and now you are expendable". Things are really cranky in the market. In my case it was probably because I'm part-time and it was more important to hang onto full-time engineers. It hurts of course, but situations can be really hard.
Also, in a way Eazel showed that Nautilus development is its core. Most of the cuts happened in areas other than Nautilus development. A few of the people at the VP have turned their salaries off, etc. Things are really tight, but for the sake of GNOME and Linux on the desktop I honestly still hope Eazel will pull through (and of course, I will continue to work on Nautilus).
Its not about tech support. If that's all the problem was schools wouldn't care too much. The problem is really cross-platform/compiler compatibility. As sad as it may be...something written for g++ *might not* work on Code Warrior for Windows, or Visual C++. This is less of a problem with C compilers, but still an issue. Your TA needs to be able to compile whatever it is you wrote, and so they pick one platform they will use.
For example, at my school they recommend a particular compiler, and ask everyone to use it (under the Macintosh, since that's what dorm clusters have)...for lower level C/C++ classes. At higher levels they reccomend gcc/g++. But the issue is that you really should be running the same compiler that your TA/TF is, or the results will be somewhat unpredictable. You could probably get by, but its always a major risk. And if it doesn't work on their machine, you can't just say "well it worked on mine" because you were using an officially non-kosher compiler to test.
In contrast, Java classes (where most compilers are relatively conformant) encourage the use of whatever compiler you want. They say it might be wise to test on the "target" compiler (JDK 1.2/3 on Solaris), but that its not necessarily "required".
My advice is develop at home - just make DARN SURE you test it thorougly on the foreign compiler and fix all compiler errors before submitting. (and you probably will have some)
I'd encourage you to look at Nautilus. It is not a wrapper program. The difference in Nautilus is the use of *fine grained* components. That is what is powerful, not the use of big blocks like Mozilla (which we can and do do as well). For example, why write 40 image renderers? Nautilus uses the eye of gnome component to not only view things in window when you click on them (heavy big component use) but to render the thumbnails you see in windows. It wouldn't have made sense to rewrite this functionality...bonobo is sort of library APIs on steroids in the ways we're using it.
GTK+ 2.0 will have the ability to draw directly into the Linux framebuffer, meaning that GTK+ apps won't need X-windows to run (potentially). It only works for single applications thus far, but it *is* very cool technology.
Its a preview release. That means its not our final installation. And tarballs mean that you don't have to install as root...untar it wherever you want. Additionally have you ever heard of 'tar -tz' ? No? It lists the contents of a tarball. That way you know what its going to do. RPMs and DEBs are far FAR worse. Your complaint is ridiculous because in a sense tarballs are the method that gives you the MOST security and control, and that's what we're distributing (now). Additionally our tarballs install into their own path (/nautilus-preview or something) so they'd be easily removable when you're done playing with it. So its neither sloppy nor insecure unless *YOU* are sloppy and insecure in how you deal with them.
If you'd like to suggest a way to make the process not require root, but still be able to install to places like/usr/bin, we're open to suggestions.
Because when Bonobo components start being written (when GNOME 1.4 is released in a few months and the library starts shipping with dists), bonobo will stop being transparent to the user. It'll make a wealth of new, easy to write components become available. Its said that you say that it doesn't focus on the user since Eazel employs some of the best user interface experts (can you say Macintosh? NeXT?). We're definitely user focused, sometimes I think we're too user focused;-)
Obviously you don't understand how MIME types work on Linux. It sounds like you use a lot of Windows, because currently there is no heavily used MIME-type to application mapping. That's done by the filemanager. So *DUH* of course we're going to be giving you some defaults for that - nothing currently exists. And you'll be able to launch your MP3 files with whatever you want, Nautilus just lets you view them differently, its not an MP3 app.
Sorry, but Nautilus is also powerful. we use userlevels to provide a way to give a dumbed-down experience, and also a powerful hacker experience. Its the first GUI filebrowser I've actually found useful except for KFM (which I used for about a year before going back to the command line after I moved to gnome...gmc sucked!).
There are lots of things you can do in Nautilus that are useful to developers and sysadmins that aren't super convenient on the command line. Usability has two aspects - dumbing down, and making it easier to get from point a to where you want to go. The first kind doesn't appeal to me either (though there's a place for it), the second helps everyone. The 2nd is definitely going into Nautilus.
Its a little driven by LWE, but it coincided with a real milestone by about a week, so it made sense to do a preview release now. We'd planned to do a release in a week anyway at the end of the milestone, and we wanted to give people something to look at. Things like performance are going to see dramatic (like more than 3/4x) improvements in the next milestone.
The eyecandy is incidental...you can't see the architecture. But maybe you aren't a hacker so you won't be able to appreciate that...? There's a serious amount of really cool and flexible architecture under Nautilus. Performance will dramatically increase in the next milestone. You missed a lot of great stuff, sorry you didn't take the time to look closer...its a lot more than just eyecandy.
Slashdot Mirror
This is one of the least relevant and useful articles I have seen OSNews carry. So it would be nice to have my compiles done 1/6th faster... but not as important as my working environment. Which is the sort of thing Eugenia reviews.
People who are actually working and not just drooling over hardware tend not to care as much about small fluctuations in performance (servers are of course a different matter; though even there things like reliability are much more important). When you're working at a workstation, people can hardly tell the difference until you *double* performance.
"Quantitative" data doesn't necessarily mean "better" data if its not measuring something terribly important.
In any case, whether you think its useful to have tons of benchmarks are not, there are a million sites already doing them. OSNews is doing something different.
I'm not as knowledgable in this area as the DBus developers, so I can't tell you all their reasons.
So one thing is that CORBA tends to take a lot of memory, at least relative to DBus and DCOP. A lot of developers will not add a small feature (and lots of lost small features is a big loss) if it means linking with a big library.
For this technical reason, and probably for other really good ones too, but also probably political/historical... I don't think a CORBA based solution would fly with KDE. A system DBus that daemon / linux platform developers can target to communicate with "desktop land", regardless of what desktop people use, is very important. Both KDE, GNOME et al need to be willing to *use* this bus. It doesn't even have to replace their old system (CORBA + Bonobo for GNOME and DCOP for KDE), though IMO it would be nice if it did.
SystemServices: Hardly wheel re-invention. If you read the linked-to article you'll find that none of the listed "init replacements" address any of my four major goals. They addressed their own goals, which are nice ones I'm sure, but not things that the desktop needs. In fact, the only thing they really add over init that's interesting to me is a dependency system + parallelization. And RH's internal work on init scripts has suggested this results in only small improvements (neighborhood of 30% I believe) in boot time... which is better but not dramatic. Dependency systems are pretty trivial to implement and a dime a dozen, in any case.
DBus: yeah, its a lot like CORBA. Its even more like KDE's DCOP. In fact, its a lot like DCOP. You could even think of it as a major iteration of DCOP. So look, GNOME has been using CORBA for IPC for several years and its still something people avoid using whenever possible. KDE used CORBA for a while, and even with the comparatively nice CORBA/C++ bindings found KDE devs avoided it when possible. CORBA is a freaking PITA to use for lightweight desktop-style stuff. DCOP was the solution (its a good solution, GNOME should have done this ages ago): make it easy enough to use that developers will actually readily communicate over DCOP. Communication protocols have no inherent value on their own. They acquire value when there's things to talk to. Developers won't use the API unless its simple. You can write very simple comm layers for KDE and GNOME around DBUS. Even if we GNOME folk wanted to use CORBA (we don't), KDE wouldn't, and a requirement for DBus being truly useful is that KDE+GNOME have to be willing to use it. End of story.
HAL: I'm not really familiar with discover, so I'm not going to shoot my mouth off (much *grin*). From ransacking the web page you linked to, it doesn't look like discover really supports the sort of "central daemon with notification signals" model that we need to provide good hardware support on the desktop side. Without that... its sort of useless to us. It looks a lot like Kudzu, which is a good thing (and trust me, Havoc who proposed HAL in the first place knows about Kudzu, and probably discover) but it simply isn't what those of us who are in the ditches writing this desktop code need.
Moral of the story: a superficially similar "solution" does not necessarily address the issues that we as desktop developers face. We propose these things because we have concrete problems to solve. Sometimes the problems are not obvious until you try to do something and end up butting into them. We're lazy people, just like anyone, and we don't like :-)
I suppose it is probably too late to inject comments and have them moderated to the point of visibility as the madness has largely subsided... but here's to futile acts ;-) I was not really intending Storage to make a big splash right now, I wanted to keep it low-key, but I guess the damage is done so I might as well comment. I'm sorry that I didn't have time to put up a more technically-oriented exposition of Storage. *shrug*
Some technical notes... that site is sparse on technical information so I'll fill in some for the curious.
Most of his UI complaints seem to center around metatheme, the "Desktop theme editor" etc. Guess what? Metatheme was dropped from the GNOME 2.0 release about 4 months ago because it was deemed sufficiently unusable. While we plan to eventually have a single "themes" desktop preference page (that will, of course, replace the widget theme, etc, we're not going to be duplicating menu entries), we decided to for GNOME 2.0 because Metatheme's interface sucked so badly. It needs to be totally redone. I agree 100%.
It seems like 3/4 of his rant against GNOME usability is based on things installed by Metatheme. It is absurd to complain about GNOME's interface based on something that was dropped from GNOME 2.0 because we knew it sucked.
-Seth (GNOME Usability Project Lead)"Per the GNOME Foundation's charter, any contributor to GNOME is eligible for membership. Although it is difficult to specify a precise definition, a contributor generally must have contributed to a non-trivial improvement of the GNOME Project. Contributions may be code, documentation, translations, maintenance of project-wide resources, or other non-trivial activities which benefit the GNOME Project. While large amounts of advocacy or bug reporting may qualify one as a member, such contributions must be significantly above the level expected of an ordinary user." from the GNOME foundation membership qualification page.
I don't think RMS fits these qualifications. The GNOME foundation membership, and all the more the board (almost all GNOME contributors are foundation members) should be active members of the GNOME community. Simply "being RMS" does not qualify one; the foundation is intended to represent the interest of those who make it happen, that is contributors.
As a minor side niggly, the candidacy period is over and I didn't see a message from RMS, so technically he isn't qualified to run this year anyway.
Perhaps he'd like to contribute to the GNOME project and re-apply next year?
-seth (GNOME Usability Project Lead)GNOME will come to Solaris, its just a matter of Solaris 9 being deployed before GNOME 2 is finished. Sun really wants GNOME 2 to be the first "officially supported" release of GNOME they ship (they have already done an unsupported technology preview CD). Lots of Sun developers are working on GNOME, and they're still pushing to get GNOME in Solaris as quick as possible (probably in an update to 9).
cheers,
-Seth
There are lots of points with great merit comparing and contrasting GNOME and KDE, so you really shouldn't have to resort to this sort of misinformation. I think the biggest thing KDE is doing right that GNOME is sucking at is having quick release cycles. We wait too long to get changes out to users, which tends to make user improvements to the core desktop more sluggish than they should be. We're gunning for a really quick turnaround release for GNOME2 - GNOME2.2 with primarily user improvements (using a lot of the new architecture that has been rewritten and/or added). Also, significant usability assesments and rewriting of problem areas is being done, both for GNOME2 and post GNOME2, which should improve the reach of the desktop to a whole range of new non-technical users in the years to come.
-Seth (Nautilus hacker, GNOME2 Release comittee, GNOME UI Lead)
The glorified stature of the window manager is an odd architectural quirk of X-Windows. X-Windows is fundamentally concerned about, well, windows, so the window manager was pretty much *the* only application that every X system was running. Consquently if you wanted to add some feature (say a virtual desktop pager), you tried to get it into the Window Manager, because the window manager was already always running.
This "window manager is everything" view is actually sort of primitive. Most advanced operating systems have turned the window manager into a really mundane implementational detail that even programmers hardly care about. BeOS, Windows, MacOS, etc.
I hope this trend continues to GNOME & KDE...and we see the disappearance of those insanely bloated window manager preference dialogues and see the window manager behaving like the submissive quiet little technical detail it should be (at least from a user's perspective). Check out Havoc's latest project "Metacity" for an example of a well behaved CrackFree(TM) window manager.
-Seth (gnome usability project lead)
http://usability.gnome.org and usability@gnome.org are the primary mailing lists for the GNOME usability project...
-Seth
Can you explain to me which fonts aren't in widgets? Pretty much every piece of text you see in the screen, from the text in your mailreader to the text in your web browser (though, due to evil hackery, this patch doesn't work on Mozilla) is in a widget. Get a clue dude. With regards to improvement...I notice a pretty big difference at 1600x1200. I suppose it all depends how picky you are about your text.
If you want to see shots of it in action...see
http://www.stanford.edu/~snickell/
Every major operating system has already done this for years. This is serious catchup.
-seth
If display technology goes the in the direction of this particular LCD, you are probably in luck. Other than paying the cost for features you don't need (but we all do this to some extent or another when we buy almost any product), this LCD will give you a fairly normal viewing experience. It only splits the image between the eyes, no distortion or shuttering or other annoyances.
Also, this LCD has the option of switching to 2D mode which gives better resolution and brightness. As long as that tradeoff exists I suspect you'll see even 3D LCDs offer this option for a long time to come, so rest easy.
-Seth
Your post is based on the (rather poor) assumption that the demise of Eazel is a step in the ultimate degredation of the GNOME project. Even as an (ex) Eazel employee I think you underestimate the resilience of the GNOME project. For one thing, many of us who worked on Nautilus as Eazel employees will continue to work on Nautilus. The reason Nautilus appears to have relatively few volunteer contributors is it tended to hire people who made significant contributions! I'm sure most of us who started that way will continue to hack on Nautilus.
It saddens me greatly to see so many in the free software community scrambling to exploit the fate of their brothers. Do KDE users truly enjoy seeing their fellow project suffer setbacks, or is it the out-spoken minority? Though I can't speak for other GNOME developers, I personally feel more of an affinity than dislike for the KDE project. We're doing the same thing. We're working for the same goal. Doesn't that make us comrades rather than enemies?!?
"but KDE would be the only desktop environment / component framework"
I might remark snidely that KDE does not yet have a component framework. It has a method for inter-program embedding (KParts), but this is not the same as a component framework. poke, poke. This is a great example of how it is *still* beneficial to both projects to have the other around. True, there is some duplicated effort, but my hope is that Bonobo and OAF will prompt the KDE project to strengthen KParts to the extent that it is a full component framework. Similarly, there are ways where we (the GNOME project) are lifting useful features from KDE. Lots of people seem to pay lip-service to competition but get squeemish when they see it at work.
"This really sucks for the GNOME users and developers. But what can you do?"
The same thing we have always done: Write code. Fix bugs. Write documentation. Translate. Polish. Add features. Keep improving. What do you do?
-Seth (seth@eazel.com)
Nautilus runs on Solaris. This was something I put a lot of work into prior to release. We're not releasing binaries, but rather have been assisting Sun in creating their own performance pack for GNOME. Hopefully this will impact the largest number of Solaris users.
Nautilus also has packages available in Mandrake Cooker, I believe.
cheers,
-Seth
Just in case people take this wrong, it really was a hard situation. It wasn't really like "good job, you've finished 1.0 and now you are expendable". Things are really cranky in the market. In my case it was probably because I'm part-time and it was more important to hang onto full-time engineers. It hurts of course, but situations can be really hard.
:-/
Also, in a way Eazel showed that Nautilus development is its core. Most of the cuts happened in areas other than Nautilus development. A few of the people at the VP have turned their salaries off, etc. Things are really tight, but for the sake of GNOME and Linux on the desktop I honestly still hope Eazel will pull through (and of course, I will continue to work on Nautilus).
Here's to better days
-Seth
Its not about tech support. If that's all the problem was schools wouldn't care too much. The problem is really cross-platform/compiler compatibility. As sad as it may be...something written for g++ *might not* work on Code Warrior for Windows, or Visual C++. This is less of a problem with C compilers, but still an issue. Your TA needs to be able to compile whatever it is you wrote, and so they pick one platform they will use.
For example, at my school they recommend a particular compiler, and ask everyone to use it (under the Macintosh, since that's what dorm clusters have)...for lower level C/C++ classes. At higher levels they reccomend gcc/g++. But the issue is that you really should be running the same compiler that your TA/TF is, or the results will be somewhat unpredictable. You could probably get by, but its always a major risk. And if it doesn't work on their machine, you can't just say "well it worked on mine" because you were using an officially non-kosher compiler to test.
In contrast, Java classes (where most compilers are relatively conformant) encourage the use of whatever compiler you want. They say it might be wise to test on the "target" compiler (JDK 1.2/3 on Solaris), but that its not necessarily "required".
My advice is develop at home - just make DARN SURE you test it thorougly on the foreign compiler and fix all compiler errors before submitting. (and you probably will have some)
I'd encourage you to look at Nautilus. It is not a wrapper program. The difference in Nautilus is the use of *fine grained* components. That is what is powerful, not the use of big blocks like Mozilla (which we can and do do as well). For example, why write 40 image renderers? Nautilus uses the eye of gnome component to not only view things in window when you click on them (heavy big component use) but to render the thumbnails you see in windows. It wouldn't have made sense to rewrite this functionality...bonobo is sort of library APIs on steroids in the ways we're using it.
GTK+ 2.0 will have the ability to draw directly into the Linux framebuffer, meaning that GTK+ apps won't need X-windows to run (potentially). It only works for single applications thus far, but it *is* very cool technology.
Thanks man! You actually can manage the desktop with it, though the support is preliminary.
:-)
Run nautilus with "nautilus --start-desktop"
Its a preview release. That means its not our final installation. And tarballs mean that you don't have to install as root...untar it wherever you want. Additionally have you ever heard of 'tar -tz' ? No? It lists the contents of a tarball. That way you know what its going to do. RPMs and DEBs are far FAR worse. Your complaint is ridiculous because in a sense tarballs are the method that gives you the MOST security and control, and that's what we're distributing (now). Additionally our tarballs install into their own path (/nautilus-preview or something) so they'd be easily removable when you're done playing with it. So its neither sloppy nor insecure unless *YOU* are sloppy and insecure in how you deal with them.
/usr/bin, we're open to suggestions.
If you'd like to suggest a way to make the process not require root, but still be able to install to places like
Because when Bonobo components start being written (when GNOME 1.4 is released in a few months and the library starts shipping with dists), bonobo will stop being transparent to the user. It'll make a wealth of new, easy to write components become available. Its said that you say that it doesn't focus on the user since Eazel employs some of the best user interface experts (can you say Macintosh? NeXT?). We're definitely user focused, sometimes I think we're too user focused ;-)
Obviously you don't understand how MIME types work on Linux. It sounds like you use a lot of Windows, because currently there is no heavily used MIME-type to application mapping. That's done by the filemanager. So *DUH* of course we're going to be giving you some defaults for that - nothing currently exists. And you'll be able to launch your MP3 files with whatever you want, Nautilus just lets you view them differently, its not an MP3 app.
Sorry, but Nautilus is also powerful. we use userlevels to provide a way to give a dumbed-down experience, and also a powerful hacker experience. Its the first GUI filebrowser I've actually found useful except for KFM (which I used for about a year before going back to the command line after I moved to gnome...gmc sucked!).
There are lots of things you can do in Nautilus that are useful to developers and sysadmins that aren't super convenient on the command line. Usability has two aspects - dumbing down, and making it easier to get from point a to where you want to go. The first kind doesn't appeal to me either (though there's a place for it), the second helps everyone. The 2nd is definitely going into Nautilus.
Its a little driven by LWE, but it coincided with a real milestone by about a week, so it made sense to do a preview release now. We'd planned to do a release in a week anyway at the end of the milestone, and we wanted to give people something to look at. Things like performance are going to see dramatic (like more than 3/4x) improvements in the next milestone.
The eyecandy is incidental...you can't see the architecture. But maybe you aren't a hacker so you won't be able to appreciate that...? There's a serious amount of really cool and flexible architecture under Nautilus. Performance will dramatically increase in the next milestone. You missed a lot of great stuff, sorry you didn't take the time to look closer...its a lot more than just eyecandy.
It *is* all optional. Some of the options may have been missed atm, but they'll be dealt with before final release. We're all about customization :-)
Performance should be DRAMATICALLY improved in the next milestone too.