Linked by Thom Holwerda on Wed 6th Apr 2011 17:50 UTC, submitted by Cytor
Gnome The day is finally here, the day that the GNOME team releases GNOME 3.0, the first major revision of the GNOME project since 2002. Little of GNOME 2.x is left in GNOME 3.0, and as such, you could call it GNOME's KDE4. We're living in fortunate times, what, with two wildly divergent open source desktops.
Permalink for comment 469457
To read all comments associated with this story, please click here.
Member since:

Personally I'd sooner have each platform to be designed in a way that conforms to the operating systems UI specifications rather than a situation where each front end might use a native widget kit but they all try to 'feel' the same through everything laid out the same way. For me I'd sooner there to be a shared back end but when it comes to the front end that the GTK+ one behaves and laid out like a GNOME application or the Mac front end is laid out like a Mac OS X conforming application.

I've never really investigated much into as so far as the code base itself but from what I have read in terms of what programmers are saying about it on the mailing lists, it isn't a pretty thing to work with. Lots of dependencies for example, code that some people don't know what it does, very few programmers from a UI centric background whose focus is on fit in finish rather than solely on a utilitarian solution (does it get me from a to b), no real long term solution to move SAL further down and replace the UI parts of it with native widgets etc.

Well, you pulled it out of me. But I have little faith in LibreOffice. Thank goodness for Google Docs. However, I understand the "cloud" solutions are just not practical for many individuals and businesses.

What would excite me as a geek/developer would be if some brave soul went the "gnome-shell" route and started a productivity suite project that isn't a trying to be Microsoft Office. Bonus points if it's inspired by something like iWork from Apple.

I bet you that will get a lot of geeks excited. As far as LibreOffice is concerned, word on the street is that it's boring complicated stuff and nobody wants to play with it.

Well the big thing is the majority of the contributors are Linux developers so they're going to focus on the platform that they run, the responsibility for FreeBSD support in KDE and GNOME falls on the shoulders of developers who use FreeBSD as their platform of choice rather than it being the responsibility for Linux developers. I know for me if I was an x86 user I'd be more than happy to put up a bounty for a FreeBSD developer(s) to write FreeBSD backends to GNOME and KDE but since I'm a Mac user it wouldn't make much sense. If someone said to me, "hey, lets put together a bounty to pay for it" I'd be happy to throw some cash their way simply to see it happen but I'm really in no position these days given Mac OS X is my primary platform.

The bounty system is great for individual community members, but corporations just need to be more serious and become venture capitalist in projects like the BSDs. Given the huge number of companies that use FreeBSD it wouldn't cost much to higher 2 full time developers to work on maintaining and integrating GNOME in the BSDs.

With the move to the GNOME shell, are they going to update or replace the GNOME HIG? If they're going to change the paradigm that much then wouldn't it necessitate a revision of the HIG?

They have to update it or completely revamp it. The behavior of windows is different in GNOME Shell and sometimes inconsistent. Some dialogs slide down, others pop up. Some dialogs have a close button on their window decorations others don't. Many of my own applications won't focus properly because of the focus prevention behavior in GNOME Shell. The window management behavior is clearly different. So the HIG definitely needs a revamp. And of course more documentation is needed. Otherwise, many developers are going to be left confused for a long time and gtk2 applications will continue to behave like epileptic step children inside GNOME Shell.

Reply Parent Score: 2