Slashdot Mirror
An Interview with Jeff Waugh
An anonymous reader writes "LinuxWorld has published a nice interview with Jeff Waugh, one of the core members of the GNOME community. In the interview Waugh talks about the upcoming GNOME 2.6, his views on software patents and on the involvement of the big vendors in the GNOME development process. Waugh is the current chair of the GNOME release team."
Wasn't it supposed to be released on the 2nd?
http://gtk.org/plan/2.4/
New file selector, yum.
After a few lackluster attempts at installing Gnome on my OSX box I have to say that a nice easy step by step instruction would be most helpful.
For many users, all the untarring, compiling and whatnot is a major headache -- akin to grasping the concept of depth of field in photography for me. Once I finally got it, it was super easy, but getting it in the first place was a big struggle.
I guess there's something about the whole process that I either just don't get, or maybe I think it's a lot harder than it really is.
So anyone know an easy way to get Gnome on an OSX box?
When the "one note" seriously threatens the ability of the community to continue sharing, it has a tendency to cast a dark shadow over everything.
They seem to have loads of smart people working on Gnome these days. So how do they explain something like Epiphany? And why is gtk-2.0 so slow (compared to the first gtk certainly)?
A fundamental API like you're describing would be the 'lowest common denominator' between the two systems. No KIOSlaves for KDE and no Nautilus integration & panel applets on GNOME. Kinda like AWT from old java, and we all know how much that sucked.
A much saner approach is to ensure that the basic stuff is compatible. Window manager hints, preferences etc. Let application authors write with their preferred toolkit, but ensure it doesn't affect users.
Almost all linux users have both toolkits installed anyway. Yes, I realise some KDE users won't have gnome (Gentoo hackophiles etc.) however if they want to use CoolGnomeApp1.0 they'll just install some librarys and they're away.
Cheers Koz
Uhm, perhaps.
I've had a lot of trouble getting Gnome to run on my KDE (Xandros) box.
So you're saying that with Native Widget Framework and freedesktop.org we'll see more of a common package?
basically I'd like to be able to run _all_ linux software on my linux box without having to become an expert sysadmin to do it. Not a big thing to ask for, eh?
Software patents are important, that's why people talk about them. If software patents are granted universally it won't do much good to talk about the other things, software engineering breakthroughs, etc, because it will be *ILLEGAL* for us to make any such breakthroughs. But, and again I really do have to recommend reading articles before posting like this, the article was hardly an example of FOSS becoming a "one note wonder".
"Mission Accomplished" -- George W. Bush May 1, 2003
I think the thing that keeps me going back to Gnome is both its simplicity and its speed. KDE feels way too much like an overload of thrown-in features, although the 3.2 release really impressed me.
I often switch back and forth between the two as new releases come out--I will be using Gnome again when its new version is released.
Bah.
The problem you are complaining about is a problem with Xandros's distribution, not linux. If gnome doesn't run properly in Xandros that just means that they haven't bothered to properly package it. Many distributions have the ability to install GNOME and KDE on the same installation, and applications written for one DE have always run just fine in the other one in every distributions I have tested.
501 Not Implemented
Actually, I do the same thing myself. I find elements in each that I like, but GNOME seems to feel more polished and put together these days. I'm not saying that KDE doesn't, but... GNOME apps seem more flexible in terms of look and feel. I can't stress the importance of a really slick looking desktop when it comes to the usability of a computer from a non-techie perspective. It makes it much easier for me to introduce people to a new desktop when it looks more impressive than Windows XP.
I try to be fu
The problem is their *frameworks* are completely different. Because of this if you wanted to bring the two together you would have to scrap one DE's entire framework as "melting" them together would take so many man hours I don't even want to think about it. The closest your going to get is esthetic integration. KDE uses a lot of things that integrating into GNOME would be more work then it's worth. Kpart's(embedding applications in other applications aka konqueror), Kioslaves(doing ftp:// in kate and being able to remotely modify files directly), and many other things that make up KDE. I don't know much about GNOME's framework to tell you the truth.
There will never be true integration. Accept it.
75% of all statistics are made up!
this wasn't flamebait (no one is gonna bother flaming the first part of his post lmao), however, it may have been a bit redundant as this question comes up EVERY TIME an article like this rolls around...now i'm not karma whoring here, BUT there is only one answer:
USE BOTH... Whichever one you like better (and you will, its never a toss up!) use!
replacing it with NEW Folger's Crystals! (lets see if they notice the difference)
KDE is whatever you want it to be. I've got mine set up like OS X --- menubar at top, panel at bottom, toolbars and menus simplified. Out of box, its pretty Windows-y, but I'd wager most KDE users don't use the desktop the way it comes out of box.
A deep unwavering belief is a sure sign you're missing something...
gwhy gmust gall gnome gapp gnames gstart gwith g? git's gridiculous!
Qt and the STL are not at odds. They are two different approaches for two different problems. The STL is a general-purpose container library. Its not at all object-oriented, and aggressively static.
Meanwhile, Qt is specialized for GUI programming, and moc and the Qt container library fit that very well. Both allow for much more dynamic code, and in my experience, GUIs are extremely well-suited to dynamism in the language. After all, two of the best GUI languages ever (Smalltalk and Objective C) were of the dynamic/object-oriented variety.
I'm a C++ coder too, and also love the STL. However, I've spent a bit of time doing Qt programming, and really do agree that a more dynamic approach is better suited for GUIs.
A deep unwavering belief is a sure sign you're missing something...
You know, call me crazy, but I just don't believe this. Think of the apps out there that have an "advanced interface" button. With it turned off, the app adopts the KISS principle, with a streamlined interface with only basic options, but if the user selects the advanced mode, the interface expands or even alters itself to support the needs of the power user. So the problem with KDE is that they don't adopt a KISS interface as standard and hide the complex stuff by default, while GNOME doesn't have the complex stuff at all.
If the two camps really wanted to, they could work together, I don't buy the argument that a feature from KDE couldn't be ported to GNOME or vice versa, but the reason they still won't work together on a common interface is because of the problems that were present from the very beginning of both DEs:
Qt is not free on all platforms
GNOME=C but KDE=C++
Even though Qt is now free on *nix, that isn't enough for the diehard Free Software folks, while the latter reason is still the real fundamental stumbling block, because GNOME people refuse to work with anything other than C, and the KDE people refuse to use any language they feel is inferior to C++. Having "wrappers" for other languages is a smoke screen, the language issue for the core of the DE is still what separates the 2 groups.
Theoretically, if the 2 groups could agree on a common language for the core, the rest of the integration could happen with little technical difficulty. Having a default KISS interface that can morph into a power user's interface in the same DE is not some technically impossible challenge, its just a matter of agreeing on an underlying standard framework and then adopting a coherent policy on the cosmetic and asthetic issues. The real reasons they won't integrate their work actually goes back to the very old reasons that still separate them.
Admittedly, it is all compile-time, but that doesnt mean its not dynamic
---------
If its compile-time, then its *not* dynamic. C++ has very limited support for any sort of dynamism, and the STL and libsigc++ continue that tradition. Like I said, I'm a fan of "modern" C++, but I have to admit that its static nature isn't great for GUIs.
The MOC isnt going to make C++ into an interpreted language or anything.
-----------
Since when do you need an interpreted language to have dynamism? Smalltalk and Lisp are among the most highly dynamic languages out there, yet have the most advanced native-code compilers available.
that the code size tends to be small, and the executables tend to be fast.
----------
In my experience, Qt is a lot faster than GTK+. GTK+ is really glacial for redraws (especially resizing) and certain things like GtkListView and Pango are quite slow. It doesn't really matter if the language binding is faster if the underlying toolkit is slower.
A deep unwavering belief is a sure sign you're missing something...