Edd Dumbill, valuable member and developer of the GNOME Desktop Environment, author of the “Mono: A Developer’s Notebook” book, speaks up his mind about GNOME in one of his recent blog entries.
GNOME’s no fun anymore
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Meh, he’s just burnt out. However, I agree with some of his suggestions. Lower level libraries should be written in C/GTK+, every other stuff should be written in Python/GTK+. I’m not too sure about Mono. It’s not as popular as Python among free software developers.
NO! BAD! BAD! That’s his whole point: none of the cool functionality is being exposed to all of the higher level languages!
Since GNOME itself isn’t doing it, that means Novell is off making their own wrappins for *SOME* functionality, Red Hat is off doing different bindings for Java, and so are the Python people…
Which means stuff accessible via Python doesn’t have Mono wrappers, etc, etc, etc.
That’s bad–the major languages like Python, Java, Mono should have access to all of the good GNOME internals in a consistent manner!
But that’s why GNOME has bindings. These languages can access the core GNOME libraries via the bindings.
“Red Hat is off doing different bindings for Java”
No they arent. The Java bindings (java-gnome) are pretty much a one man (Jeff Morgan) show and he dosent work for Red Hat or Sun. RH isnt pushing anything, not even Python!
I blame the likes of Havoc/Red Hat for the state that Gnome is in. They are too conservative and seem content on letting Gnome continue to suck. Face facts, Gnome is broken, everything is being depreciated, the documentation problem is so severe now its almost impossible for new developers to work on Gnome, and to top it off their living in their own little universe when it comes to usability. Just because something contridictes the holy HIG dosent mean its not usuable!
I mean honestly, the only way Gnome is going to survive is if its fork. If it wasent for Red Hat, Gnome would have been dead years ago.
END RANT
Red Hat does have some fulltime developers working on GNU Classpath (i.e free software Java libraries). The Java bindings for GNOME is another story. I think GNOME’s problem is documentation. People are quick to start projects no one can contribute to because of no documentation.
Gnome developers seam to have an idea on how to make a good desktop but fight about the tools. KDE developers seam to have no idea on how to make something useful for ordinary users but have excelent well documented tools that works. Perhaps there is hope for Microsoft after all.
Does anybody really have a problem with using Python as a scripting language?
I mean, i’m no Python fan, I’ve used Perl so long that anything else just seems wrong, but both Java and Mono are so irrevocaably tied to corporate parents and the partisan battles that are unavoidable given this, that they should both be rejected in favour of an open standard, as defined by a respected leader (Guido van Rossum) and the wide community that has sprung up around Python.
Not only this, but the simple ‘performance and architecture’ arguments against Mono and Java remain.
Java sucks in terms of performance, because it comprises such an enormous class library – which essentially re-implements the bulk of glib and gtk+. If you want a Java environment, the entire desktop framework should just be written in Java – its retarded to have a huge framework (GNOME) which you then have to load an entire other framework (JVM+Class Library) on top of just to call the functions in the first framework as a scripting environment.
And Mono is the same thing, only written such that it is incompatible with Java syntax because of Microsoft’s arrogance and greed. I mean, I think its nice that there is an open source implementation of C#/.Net, but what is it really offering in real terms?
Personally, I think anything (of those choices) but Python is a recipe for disaster, and GNOME will cease to be useful for me (I run it on many machines with less than 256MB of RAM and sub-1GHz CPUs) at the point that major apps are implemented in Mono/Java.
Python is a choice we can all live with, I have yet to hear an reason why Python *shouldn’t* be used. can anyone offer one?
New languages (or bindings) doesn’t solve the central problem of the OpenSource development model: It won’t make developers start working together. It won’t make them develop solutions for user needs.
Is Edd Dumbhill’s blog entry helpful in this respect? Or posting a link to it here on OSNews?
As a site note, among the disadvatages of possible choices, the API instability of Python is a problem, the development community is at least able to deal with — unlike possible patents or getting non-free stuff distributed widely.
I agree with you. I will admit alot of the developer stuff is outside the scope of my knowledge. But basic business says infighting is no good. One of the things that scare me about open source is that a project can be droped just like that with no warning. Alot of people can come to rely and depend on a project like Gnome. Knowing that a project can just be droped makes users hesitant to use it. Didn’t this happen with Rad Hat? when they decided not to offer a free version of it’s product.
What a mess! It is a tough situation that the GNOME guys are in. The have Novell pushing them towards Mono, RedHat/Sun pushing towards Java, etc.
I think that the problem is that GNOME/GTK’s arcitecture is seriously messed up. I am not a Gnome developer, so I haven’t worked with the code, but my impression from what I’ve heard/read is that it’s a mess under the hood. This is why there is descrepencies in API’s and redundancy between GNOME/GTK libraries (which is getting better BTW).
They need a solid architecture that clearly isolates the different components. Make a very good library that can access EVERYTHING in a logical way. This would be similar to the Win32 api in Windows. Once you have a really godo base, THEN make wrappers/bindings for Python, Java, Mono, etc.
Hopefully things will get better, and hopefully what I wrote makes some sense!!!
-Eric
the real problem is that 50% of gnome libraries simply suck
bonobo is deprecated
gnome-vfs is orrible
gnomelibs ??
gstreamer is bloated
Planned library/module removals (deprecated during the 2.x series):
audiofile
esound
libart_lgpl
libbonoboui
libgnome
libgnomecanvas
libgnomeui
http://live.gnome.org/ThreePointZero
gnome-vfs will proably be rewritten from scratch again. Gnome is such a joke.
Bonobo is deprecated – long live DBus!
Gnome-vfs now that does sux
gnomelibs are no longer needed (except perhaps GConf?)
gstreamer is componentised so its bloat is very variable.
Sorry about the typo.
Obviously not a good day to post.
I do not think the API instability of Python is a big problem, especially in a free software project like GNOME. These projects adapt very dynamically and quickly to changes. There are lots of sucessful free software projects running on potentially volatile APIs.
the real problem is that 50% of gnome libraries simply suck
bonobo is deprecated
gnome-vfs is orrible
gnomelibs ??
gstreamer is bloated
Perhaps it’s time to reimplement Gnome on top of QT.
Gnome3 is the project name of a completely diffrent desktop than what gnome-vfs is part of, of course existing could will be “rewritten”
Now I am fairly certain that you will see a Gnome-2.12 Gnome-2.14 adn possible a Gnome-2.16 long before you’ll ever hear about Gnome3 taking off…
This is not a toolkit issue. Hundreds of successful applications have been written with GTK+. Qt is not any better or more capable than GTK+. What makes you think switching to Qt automatically solves the myraid of problems GNOME has?
(1) Developing GNOME in C is much better than any of the suggested alternatives which all seem to be one way streets. Interfacing Python with C# – huh!
(2) Documentation is not perfect but at least the API references are mostly there. Using Devhelp is quite convenient.
(3) Creating one monolithic library is definately wrong. Even Qt-4 will be split in different parts and as long as the various GNOME libraries follow the same guidelines it is ok. Besides–at least Gtk & Glib are quite well designed and easy to work with (considering that it is a C library). I don’t know about most of the other GNOME libs but if there are problems they can certainly be resolved in C.
(4) Finally, because it has to be said–C# and Java implementations are slow. Python is even slower (and I consider dynamic typing to be dangerous (in fact I prefer Ada to any of them)).
…when they decided to write a desktop environment in plain C. If Gnome was written in C++, there wouldn’t be such silly problems.
Look at KDE, nobody is planning to switch to a higher-level toolkit, and even if bindings exists (Ruby, Python, …) 99% of all the external apps are written in C++.
I agree with you about such arguments. The openness of sw licenses usually encourages people to think that they can fight and, eventually, split. They think no-one of them will actually loose something because they can retain codebase and start over. That’s just a suicide for a project but I’ve seen so many examples like that.
However, let’s not forget another basic thing: plain money. You can start contributing to a project for various reasons. Maybe because you feel productive, maybe because you like that project so much, maybe because you think that current developers are getting all that wrong or whatever.
If you get paid, you will hardly go away unless you have other nice big opportunity. However, when you do that for free, you start fights, maybe your own life is a mess and, most of all fun is over (Edd’s words), being committed starts getting very hard and sometimes you just can’t stand anymore.
Plus, many contributors could just disappear after a while and so a very few developers will face an huge growth of their responsibilities. There’s really NO fun in that.
I don’t know how much Edd is involved (and/or important. He wrote about Bluethoot…) into Gnome itself but it’s amazing how someone, which is part of a project which is not that tiny nor unsuccessfull, can have such bad feeling about his tasks and the project itself. That’s something about which people should think about.
>Does anybody really have a problem with using Python as a scripting language?
This is one of the kinds of statements which can make some people shy away from python for desktop use, and bringing in Perl to the discussion does not help. Scripting does not have any relevance tho this discussion.
Python is NOT a scripting language! Python is a object oriented multipurpose interpreted programing language. Referring to Python as a scripting language does it big disservice, even if it’s clean design and interpreted nature makes it superbly suited for scripting too.
C++ is as horrible as C to code in. Beside GNOME does not use pure C, it uses Glib. Glib provides several powerful abstractions over C.
C++ is as horrible as C to code in.
Nope, it isn’t. A good toolkit (e.g. Qt) can hide all the quirks of C++ and provide an easy and powerful object oriented environment. Writing OO programs in C is just plain dumb. C was never meant to do that.
No wonder Gnome developers need bounties to have people hacking on their code. Have you actually compared KDE codebase with the Gnome one?
Is it only apparent to me that each major release in the GNOME/KDE sphere is followed by flare-ups of support which segue into many fair-weather users losing their ( by definition, weak ) faith in the projects and decrying their downfall, only to have it the whole process start again with the next major release? I suppose in recent years GNOME has helped stymie this by doing point releases every six months so the flare-ups aren’t as big as they used to be.
As a rookie OSS user a decade ago I seem to remember switching desktops after every major release, thinking to myself, “this is so much better than that old GNOME/KDE crap.”
Let’s get serious people, the desktop metaphor probably only has a few good years left, a decade if we’re lucky. Maybe it’ll stick around longer in the software/hardware developer world for a bit longer than the end-user world, but one way or another somethings gotta give. Besides, if anyone in the OSS world really wanted to cast of the iron chains of windows, why not cast off the windows?
“Python is NOT a scripting language! Python is a object oriented multipurpose interpreted programing language.”
What “scripting language” usually implies is “not suited for the development of large scale, mission critical, reusable systems” and certainly Python/Perl/Lua are all limited in this regard. While dynamic typing for instance might be a blessing for small scale applications it’s drawbacks are getting more serious the bigger the system you are attempting to create. And yes, I know about unit tests.
The idea behind Gnome needs to be dumped. Gnome as a desktop? Yes please. Gnome as a development environment? Hell, NO!. Gnome started moving a lot of its infrastructure into GTK with 2.x and I think they should continue doing this. Think of GTK as a way to build fully freedesktop compliant apps and Gnome as a DE to provide those freedesktop extensions to GTK. But for those people that don’t like Gnome the freedesktop components could just as well be provided by KDE or XFCE.
Gnome shouldn’t need to worry about the next generation language that developers want to use. That’s up to those developers. Gnome shouldn’t need to worry about what languages libs are written in (it shouldn’t write libs). That’s up to the toolkits. Gnome shouldn’t need to worry about if the wrapper for one or another language is complete. That’s up to the wrapper people. All Gnome should need to be concerned about is to be a good desktop. No apps no, no libs, just a desktop.
P.S.: Don’t take this as an insult, its just my opinion.
🙂
gnome motto is less is more
less features
less documentation
maybe less developers
Where is all this python/mono progress? I’ve not seen very many applications in mono that I’d use and most of the python applications I’ve seen were either badly done or shouldn’t have been done in python (animation isn’t best done in high high level languages).
I’m just not seeing it. Most of the applications I use on a daily basis have been done in c or c++. I’m not against other languages; I just seem to see the general quality of high high level languages be terrible. Maybe it’s a maturity issue?
Does anyone have any good examples of really good python programs, other than gdesklets
. I know there are many out there, but I don’t see them massively increasing productivity. All that comes to my mind is things within gnome-panel that have been done using python.
Base libraries really need to be done in high level languages like C though, that way applications can take advantage of those stable c libraries in Python/Mono/w/e.
My opinion is that Gnome should use Python. I’m FUDed out on Mono, and I just don’t think Java would get much backing from people who are actually willing to do the hacking.
Good PyGTK app…
Pick one, the list is long.
http://www.pygtk.org/applications.html
One of the things that scare me about open source is that a project can be droped just like that with no warning. Alot of people can come to rely and depend on a project like Gnome. Knowing that a project can just be droped makes users hesitant to use it. Didn’t this happen with Rad Hat?
You have more reason to worry about closed sorce software, if the company making it goes belly up, or otherwise for some reson decides not to offer the product anymore you are fried.
This is not likely to happen in free software world. If there is sombody interested in the software it Red Hat dropping their free as in bear download is actually an example of this. Fedora continued the development, and Centos provides an alternative sorce if you don’t want the support that Red Hat offers.
Who just said c was never meant to write OO code? Do you have any clue what you are talking about? COBOL wasn’t written to create any kinds of objects or organization for that matter; c on the other hand provides structs, enumerations, strong typing, full scoping, and an arrangement of other things allowing and ENCOURAGING use of objects. What C doesn’t do well is information hiding. Information hiding is needed to keep idiots on the first floor from complaining when you change things you told them not to access in the documentation they didn’t read.
Just say no to digging into that struct directly
.
The Bitland Prince wrote: The openness of sw licenses usually encourages people to think that they can fight and, eventually, split.
IMHO, I mostly see a new languages or toolkits or toolkit bindings to be the reason to start something from scratch. Im most cases, that’s where either the functionality seems to be easy (Editors, EMail) or the basic functionality is already implemented in a external library or commandline app (audio players, or cd burning apps).
However, let’s not forget another basic thing: plain money.
Agreed. What’s *really* needed to get OpenSource going (on the desktop) is a place for users to aggregate money. There have been a few attempts in the past but either it was too early for them, or they made business newbie mistakes.
That, at least, provides a sort of proper feedback what current users really want and need, not what developers think might be fun to hack at, or what they think a user getting Linux preinstalled needs.
This will make users also independed on blog entries such as Edd’s: I’ve invested a great deal of time and inconviences on learing Linux, and I don’t like to depend this on the fun factor for developers.
OO is a concept, a paradigm if you will. It is not a programming language. You could implement OO constructs in assembly if you wish. But the success of a project is not dependent on the programming language, or whether or not the programming language has OO constructs builtin. That’s a popular and short-sighted misconception. OO gets ugly, complex and unweildy very quickly, just like C++. And even if you have drowned yourself in the OO hype, C++ is the last language you want to be promoting. Smalltalk, or even Python, should be your banner flag.
The main problem here is a lot of ideas but nothing happens. People here speak about deprecation of some libraries which of course is a good idea. The question is, who is doing the work to port or update the software ?
People speak about GNOME 3 and all the nice drastical stuff that might be changed but the question is, who is doing the work ?
If it hasn’t been done until now (and obviously it hasn’t) then what makes you people so sure it will happen anytime soon ?
GNOME 2, please pardon me, isn’t anywhere, GNOME 3 which arrives in another 1-2 years needs to get there first. The current deprecation in GNOME is fine but as long as it’s only labeled deprecated and no one is really progressing in doing all the dirty work of conversion nothing will be gained. It doesn’t help praising hymnes of the cool upcoming GNOME 3 if no one will do anything.
The amount of languages used inside GNOME is scary, perl, python, c, c++, mono, java and so on. For me this is quite scary to see.
A few of those look really cool (someday when I use python I’ll lookup that IDE for it again); but a lot of them are well “cheesy”. I don’t mean to degrade them, but it’s my word for things like calculators and flashy things
.
Couple of blog tools look good too. I wish my blog weren’t b2evolution
.
While dynamic typing for instance might be a blessing for small scale applications it’s drawbacks are getting more serious the bigger the system you are attempting to create
I read somewhere (Bruce Eckel’s blog maybe) that optional static typing is being once more considered by GvR, or at least it was discussed in the last PyCon.
I love Python but sometimes I miss the variable and type declarations, it’s easier to be sure whether the variable is being used for the first time or not and what it’s supposed to do.
You’re wrong (IMHO). A desktop on its own is useful only to a minority of geeks.
Apps matter. Thus, the only thing that matters for GNOME is the development platform.
I agree, although I don’t mind c++ except that I spend 3 times as long reading linker errors as I do debugging major memory errors in c. I was pointing out that c provides all the constructs one needs to easily make objects and pass them around. It just don’t babysit you.
I can’t even wrap my tiny brain around the idea of using OO ideas in assembly, that doesn’t sound like much fun at all!
I got completely burnt out on the overuse of objects after doing my intro to OO course’s homework on class heirarchy. You should have seen the assignment, it made no sense. 20 hours of fidling later I had made up a sort of class structure for something that I could have written much faster and easier inside one function in a language I had never used! Yea, it was a simple program.
>Does anyone have any good examples of really good python programs,
Easy, I think you even may have heard of them: Mailman, MoinMoin, Sketch, Eric3, Freevo, BitTorrent, Zope.
Cheese itches need scratching to. Look at most of the freeware/shareware on Windows.
You can make apps all day, but if you don’t have a stable environment for them to play together in it’ll be unusable.
For example: I’d love to use KDE on my desktop, but it crashes every 3 hours because of an issue with a graphics driver and I have the compositor off.
Python provides powerful introspection abilities to determine whether an object has been initialized, what type it is, what properties it exports etc. I think adding static typing to the language is a horrible decision of the part of Guido. And I’m pretty sure it is a corporate influence. The last think I want is Java style programming in Python.
Apologies, the response was directed to Anonymous, not you.
I mean, when I am reading source code, it’s simpler to see an explicit declaration, instead of a simple assignment.
But it’s a small detail, Python still is by far my favorite language, and if I could I’d switch from C# to Python for my professional projects any day…
How about integrating the mono vm directly into Gnome? It simply implements the ECMA CLI spec as a virtual machine, so there shouldn’t be any intellectual property concerns there.
On top of that, there would be multiple languages that all run on top of this vm integrated into Gnome: the rest of mono, java via IKVM/Classpath, and python via IronPython. The trick would be making sure that all versions are very compatibile with the native versions so that all the programs would Just Work.
A quick search on speeds shows that IKVM is roughly as fast as kaffe, and IronPython is claimed to be up to 1.7x faster than Python-2.3. Of course these numbers aren’t absolute, just that there shouldn’t be too much of a performance hit doing it this way.
That way you only have one vm running for all three languages that would share the high single instance startup costs so that’s not so much of an issue.
Not saying it’s the right answer, just wondering if it would work.
Apps matter? Dude, that was my whole point, but Gnome doesn’t write apps. Gnome writes a desktop. Gimp writes an app, Inkscape writes an app, neither of them are part of Gnome. Apps are apps, libs are libs, and desktops are desktops. If you mix them up, all suffer. Either way, do you think that if gnome tells me >>no you can’t develop with python you need to use C#<< I would give a shit? No, I will write my stuff in python anyway.
That’s the point.
>What “scripting language” usually implies is “not suited for the development of large scale,
> mission critical, reusable systems”
Exactly, and since Python are used and suited for all the above it is clearly not correct to imply it’s only a scripting language.
Since the guy started at Microsoft, looks like the project is going really slow, at least from the lack of updates in the project’s homepage.
I wonder if he’s still working on IronPython at the office in Redmond, or doing something else.
To have Python officially supported as a .Net language (P#? Python#?) would be great
Does anyone have any good examples of really good python programs, other than gdesklets
.
I can think of one really good program that uses python…portage.
Even if Python has powerful introspection abilities, static typing would make sure that I even would not need spend time stepping through my code, I would just see a clear error, fix it, and done! Much faster then debugging …
In my opinion, especially from the perspective of the user, who doesn’t care about toolkits, GNOME is all about a different philosophy when it comes to usability than that of KDE (neither is better or worse than the other … oh wait, although KDE suit my personal taste better). That said, there are only political reasons for not to using QT to implement those ideas. The gpl vs. lgpl issue is bogus – practice shows that the reasoning that lgpl is more business friendly is false. There are more commercial entities using QT (by a long shot: EPA, Volvo, Opera, Adobe, etc.) than gtk. Because it has everything that GNOME lacks according to this guy: professional grade support and documentation, a consistent api across multiple platforms, consistent api, etc.
I know this is ridiculous suggestion – so don’t take it too seriously, first and foremost because one cannot reasonably expect a GNOME developer to start using QT, if his or her preferred developing environment is GTK. This is just a utopian idea (using the same toolkit would have profound advantages) based on the fact that there is nothing in QT that prevents implementing the same GNOME philosophy that make their DE … well, gnomish.
The problem with mono is two fold.
1) Undue corporate influence, at least relative to the alternatives;
2) Possible patent infrigements, not just from anyone, but from the ewil corporation itself.
I do believe a free software project should be encumbered by those.
is this why Slackware decided to get ridd of gnome????
-2501
GNOME happens to write a development platform (‘ecosystem’ in modern marketing lingo) including a desktop _and_ apps. And the GNOME (core? main? whatever…) devs seem to have no glue about integrating third party apps or its developers. That was my point, dude.
“KDE developers seam to have no idea on how to make something useful for ordinary users”
I couldn’t disagree more. For me, an “ordinary user”, KDE is extremely useful. In Gnome if I click on a text file it doesn’t know what to do. Is that your idea of usability?
That’s actually a myth. The time spent debugging statically type programs isn’t much lower than that spent debugging dynamically typed programs. In fact, it’s usually the other way wrong.
The range of bugs static typing saves you from is totally negligible in real world projects. Do not be deceived into thinking static typing earns you shorter debugging cycles. It doesn’t.
The Gnome ecosystem you are talking about is mostly GTK. Make it all GTK, make Gnome only a desktop. Apps can live without >>integration<< into a desktop. Restore a clear separation between app, lib and desktop.
Already happening: the functionality of libgnome is going to get integrated into gtk+, AFAIK.
However, this or other rewrites won’t make gtk+ a known ‘brand’ among users. They don’t differentiate between GTK+ and GNOME. And the later is simply the more prominent. Thus, apps are either integrated into ‘GNOME’ or they are not (that is: Don’t use GTK+).
However, this has nothing to do with GNOME devs announcing that they just started to develop the ‘real’ GNOME app (ie. a more HIG’nified version of something already prominent).
Apps can live without >>integration<< into a desktop.
Not in Gnome, they cant’t. Take a look at how Evolution, the Clock and Gaim integrates. This is the where the future of Gnome lies, to the IDE (Integrated Desktop Environment).
> look at how Evolution, the Clock and Gaim integrates. This
> is the where the future of Gnome lies…
If this is really the future that you wish then amen. The stuff you just named are more hacked up than truly integrated. But I bet you are no developer and never threw an eye on these things.
I don’t care if an end user knows the difference between GTK and Gnome (or KDE for that mater), it is unimportant. As to Gnome functionality being moved into GTK, see my first post. The HIG is nice and all but it should be part of freedesktop (I think there is a hig there somewhere, an old abortive attempt to merge kde and gnome higs).
@John Nilsson:
Integration of app components should be possible regardless of DE.
Couldn’t agree with you more that desktop, libs and apps need to stay separate. I believe Havoc Pennington recently agreed with this view in a blog, saying that Gnome should get back to focusing on being a desktop, and let the distro makers do what they want as far as apps. It seems to me that most power users who want to just get work done will have both sets of toolkit libs installed anyway, because there’s always going to be at least one program that doesn’t match their desktop’s toolkit.
Unfortunately, the way things stand now the user has to install basically the entire DE just to get the complete toolkit on their system. I experienced this recently after installing Ubuntu–once I installed K3B and Scribus, I needed to install the Qtlibs AND KControl and everything that came with it if I wanted to get my Qt apps to be skinned correctly, instead of looking like crap. At that point, I may as well have added KDE itself and be done with it.
What we really need is desktops that play well with apps written in all toolkits, in all programming languages, rather than trying to impose only GTK+ or Qt apps on the user. The GTK-Qt theme engine is a good start–mainly targeted at KDE users, it lets GTK apps get drawn to screen by the Qt theme engine. Why hasn’t anyone tried developing a similar solution for Gnome users (to draw Qt widgets via the GTK theme engine)?
If Gnome wants to be a viable desktop, instead of an unsuccessful attempt at forcing one toolkit on users and developers, it needs to start focusing its efforts on being first and foremost a good, usable desktop, nothing more or less, that allows any and all apps to easily integrate. That means Mono, Python, Java, and even Qt apps will all get treated as first-class citizens. Only then will we experience an OSS world in which apps get judged and incorporated into distros based on their actual usability rather than simply what toolkit or programming language they were developed in.
I just want some way to edit menus in gnome (that works). Oh, and the whole spatial nautilus thing blows goats. Why do they keep pushing it after it failed in every other OS. Just admit you’re wrong and go back to a regular file browser. BTW, the regular file browser kinda sucks too, but no improvements are made to it because gnome devs think spatial is the way to go.
Part of the reason I now use KDE after using Gnome for years.
The solution is not QT. QT is GPL. When I write something, I want the choice of which license to use — I don’t want the GPL shoved down my throat (yes, I have released things as GPL, I like to have the choice of which to use). And no, I’m not going to pay TT $1500 for the choice. I don’t have to pay anyone when I write software for Windows/OS X/Gnome/Java/Etc. I’m not about to do it for QT.
This is not a toolkit issue. Hundreds of successful applications have been written with GTK+. Qt is not any better or more capable than GTK+. What makes you think switching to Qt automatically solves the myraid of problems GNOME has?
For one thing, QT is very well documented. This makes it very easy for new developers to get started. I was able to fix KDE bugs in just a few hours. In Gnome I wouldn’t have known where to start.
Having the same base, as that other big free desktop project would make it easier for these projects to cooperate and share ideas.
No I haven’t looked at the code, and I wasn’t talking about the code either. I know that the current state is somewhat of a cludge. What I was implying was that following the development of Gnome you can see the pattern.
@johnlein
But this is what Gnome development is currently up to. Making sure apps get integrated.
@Moochman
Personally I think the whole concept of an application has to die. This is one aspect I agree with Jeff Rasikins on.
I like all this HIG and Integration stuff, which makes my GNOME Desktop look just beautiful and awesome. Here a Screenshot from the most recent and most bleeding edge GNOME CVS.
http://img234.echo.cx/my.php?image=screenshot34ji.jpg
Pay attention to the cool Toolbars aren’t they HIG’ified ? Aren’t they just CONSISTENT and CLEAN ? I would really welcome that the GNOME HIG is being put on Freedesktop.org so other Desktop Environments can make their stuff look as beautiful as mine.
So what would you propose? That the apps become more and more a part of the DE? To me this sounds like a Microsoft-esque view, where if the app isn’t an integrated part of the desktop, that comes with it, they don’t want it. What this leads to is software hegemony from the makers of the DE, and ultimately stifles innovation that might come from other up-and-coming apps not written in GTK. This is why Gnome users are stuck with a second-rate CD-burning app and a media player (Totem) which still doesn’t compare to the Qt alternative (Kaffeine).
(Re,Re,Re,@,@,@ this forum should have threads…)
I’m not entierly sure actually. But more unixishy tools and interfaces to mix them in ways I can’t imagine. Take a look at how the vfs, bash and coreutils provides a really powerfull environment.
I guess I want UI to be developed by UI deveopers, and then service providing tools to be developed by developers that do that well.
There is a tendency for good applications to be developed into mosters of featurisis, and then a pluing framwork is added to really explode the disease. But mostyl I like this, Total Commander for windows is an example of this, plugins for everything. The Eclipse platform is another example.
As you have noted I’m rambling here. But really there are some signs of this in Gnome land.
The problem I see with applications is that they usually mean a box of tools that are confined to the data that that applications cares to understand.
Many applications bundle a set of tools to manipulate some data you can import and export from it. It seems more sensible that the tools are free from the application and availible for all compatible data objects. The new “mime” system apple invented is a step in the right direction to support this.
ok, reading my last post makes me realize I’m to tired to make any sese.
Take a look at http://rchi.raskincenter.org/aboutrchi/index.php for one stab at it (I’m not sure it suitable for the 21’th century though)
I think http://www.opencroquet.org/ has some insights into this too. http://www.cs.bell-labs.com/plan9dist/ is a classic.
I remember reading about a DOS based project a few years ago here on OSNews too, never found it again though…
“KDE developers seam to have no idea on how to make something useful for ordinary users”
I couldn’t disagree more. For me, an “ordinary user”, KDE is extremely useful. In Gnome if I click on a text file it doesn’t know what to do. Is that your idea of usability?
If you have found your way to osnews, and have heard of KDE and even can tell the difference between Gnome and KDE you do not qualify as an ordinary user.
The problem as I see it, there is no grand design. A complete design for the WHOLE desktop environment. Each project works on their own little thing, but the result is, you have a cobbled together desktop with parts that don’t quite fit, and other parts that are half-baked or not even baked at all.
People also talk about contributions; anyone who does make a suggestion is instantly yelled down. Want to contribute? good, then you have to follow the band, even if they’re going in the wrong direction.
This is the one weakness of opensource, you have developers egos deciding the direction of a project instead of moving a project in a particular direction because it is the right thing to do.
As for the person who complained about another bringing up MacOS X; excuse me, MacOS X is the most popular UNIX like operating system on the market. They got the gui right, they got the infrastructure right – the *only* people pissing and moaning about it, from what I see, are pissed of OSS desktop zealots thinking that their ‘rightful place” on the hill of beans has been nicked off them, when in reality, Apple got their shit together and produced a superior solution – one based on delivering to the end user what they demanding rather than what the developers egos demanded.
“That’s actually a myth. The time spent debugging statically type programs isn’t much lower than that spent debugging dynamically typed programs. In fact, it’s usually the other way wrong.”
Do you actually have a reference to back up this claim? Having worked on a number of fairly large pieces of software, I find it very hard to believe… however, none of these have been written in a dynamically typed language so maybe I am missing something.
It sure feels to me that I get a lot out of static typing when I need to do things like change some API in the system, and the compiler can give me an error if I miss changing some code that calls that API.
Heck, I think the static typing in Java is seriously flawed because of its lack of const. I want to be able to strictly define, check, and enforce at compile time as many interactions between modules as possible — the less the compiler can check, the more I have to check at run time by trying to excercise all of the code. In a large software system, this becomes a big problem.
Note that I am not trying to say Python is better or worse than statically typed languages. I happen to really like Python, but no language is great for everything.
Last time I checked it wasn’t too easy to get a mutithreaded python app built. Python also doesn’t compile to executables gracefully like a good language should (AFIK). Compiling not just a program but all the libraries it uses as well every time they are used is wrong. Perl, Java, Python all have this problem. I have no idea about Mono but since it’s just a rebuild of Java I suspect it’s that way too. High level languages are nice to program in but they need to focus on having the features low level languages have had since the beginning, like the ability to actually compile. There’s no theoretical reason why a high level language needs to be wildly slow and inneficient.
I hear they are doing great stuff in Parrot and Perl6. Lets hope they open up new worlds for high level languages.
For one thing, QT is very well documented.
And GTK+ is not?
This makes it very easy for new developers to get started. I was able to fix KDE bugs in just a few hours. In Gnome I wouldn’t have known where to start.
It’s called bugzilla.
Having the same base, as that other big free desktop project would make it easier for these projects to cooperate and share ideas.
Yeah, let’s dump Qt, and use GTK+ instead. It’s C, the most used language on Unix, and provides excellent bindings for higher level languages and a multitude of libraries which are eons more productive than C++/Qt. And if you are really dieing to use C++, then use GTKmm, at least GTKMM doesn’t try to reinvent the bloody wheel.
They seemed like a good idea for a while, but we would be much better off if everyone just used static linking, perhaps with improvements to ld to make it link only referenced symbols.
Shared libraries were a good idea back when:
a) memory was extremely scarce
b) computers were time-shared between multiple users, so text segments could be shared.
With static linking, aps start up much faster when there is no prebinding that needs to be done, and, as was pointed out, users always end up having both GTK and QT installed anyway, so there are no disk savings. The amount of memory saved in text segments by shared libs is minimal in today’s world, and would be offset if apps only linked in the actual functions they were referencing (which is only feasible with static linking) rather than the everything+kitchen sink approach taken by gnome and other FOSS apps today.
Before you flame me, think about it. It makes sense. It would also provide programmers with more precise knowledge of the text-size of their code, and it would eliminate the current dependency hell.
Only downside is that a security-upgrade needs to be applied to all apps rather than just a shared lib, but on the other hand that means the upgrade would be tested not to cause trouble for the app, before being applied.
And before you complain about lack of sharing of text pages, go read Carl Waldsburger’s paper on hash-based page sharing in VMware. Something similar would be trivial to implement for Linux.
Author wrote:
“Forget also about bloat. It’s really not the deal we think it is. Ask any OS X or Windows user.”
I’m a Gentoo Linux user, a Windows user and on occasion I’ve used OS X.
I *hate* bloat, and I think just because we have nice hardware that can handle it why does my chosen platform take just as long now the rough equivilant did ten or fifteen years ago?
———If you have found your way to osnews, and have heard of KDE and even can tell the difference between Gnome and KDE you do not qualify as an ordinary user.———–
As a former windows user who has converted two other windows users and given a computer to my mom and grandparents(both with fedora)…..
“ordinary users” like it or not can directly be translated into “windows users”. With 90,95% marketshare…. sad as it is windows is the norm.
KDE is much easier to welcome WINconverts with than GNOME is.(not that gnome is hard to use) I suppose the argument could be made for something like IceWM or something else being even easier than KDE to do WINswitching…….. but KDE is still “linux enough” for anybody to look and say “hey that isn’t windows” and get the response “but yet it’s still easy to use”.
As a former windows user….
I can’t make heads or tails of GNOME. I could if I tried, but see no reason to.
————As for the person who complained about another bringing up MacOS X; excuse me, MacOS X is the most popular UNIX like operating system on the market.———-
Tell that to IDC……..
————As for the person who complained about another bringing up MacOS X; excuse me, MacOS X is the most popular UNIX like operating system on the market.———-
Tell that to IDC……..
Provide a link. Provide a link to show that there are vendors out there shipping 1million units per-quarter. Even SUN doesn’t reach that level – and they’re the largest – by volume, of the UNIX vendors.
The fact remains, MacOS X has become popular because it focused on who brings in the dollars – the end user.
For one thing, QT is very well documented.
And GTK+ is not?
No, for one thing the QT documentation is heavily hyperlinked. Even the code examles contain hyperlinks to the API reference.
Having the same base, as that other big free desktop project would make it easier for these projects to cooperate and share ideas.
Yeah, let’s dump Qt, and use GTK+ instead. It’s C, the most used language on Unix, and provides excellent bindings for higher level languages and a multitude of libraries which are eons more productive than C++/Qt. And if you are really dieing to use C++, then use GTKmm, at least GTKMM doesn’t try to reinvent the bloody wheel.
I’m by no means any lover of C++, as it allows the developer to think in a non OO way and still get away with it. Smalltalk or Eiffel would be much more in my taste if we can’t have java or C# for political or whatever reasons.
However, using Smalltalk or Eiffel probably wouldn’t be realistic as there are much fewer people that know these languages than there are people who know C++.
Gtkmm would be OK as long as most parts of Gnome are written in it. Well written OO applications is usually much easier to modify than procedural ones.
Yes, I know that you can OO-like applications in plain C by applying an objectoriented ideom but that take dicipline that some developers seam to lack.
Another advantage of an objectoriented language is that most people that learn to develop software today do so in some OO language. They don’t think like people who grew up when Fortran IV was state of the art.
Why not let market forces decide?
Coders will pick the language they prefer…there is no crisis, well maybe in the short term.
And when you find a bug in one of the libraries you use, you only have to replace all your statically linked applications not just the failing shared library.
No thanks
And that’s the problem with software programmers today. They think that OO maps perfectly to all problem domains. The reason I’m in love with python is because it does not force any programming paradigm on its users.
I do not see the point of rewriting libraries in GTKMM. The libraries in existence today WORK! Why rewrite GTK+ is C++ for no valid reason? It can not get anymore OO than it is already. What does rewriting the whole library in C++ or Python or Java for that matter gain the community. Nothin!
The problem is not the language. This is an architectural design problem. The whole architecture needs to be refactored. And I hope to God it does not involve rewriting anything in another language. Some libraries need to die.
GNOME needs to adopt more freedesktop.org standards. GNOME needs to find a way to attract more developers. GNOME needs better documentation. GNOME needs a better more powerful and intelligent development tools, so that writing GNOME apps is fun and not tedious.
GNOME does not need to be written in your favorite language. Once again it is not a language issue. It’s just a lot of inconsistencies at the API levels.
If you don’t want a wrapper of wrapper of wrapper of …
Or lets abandon all of GNOME things and go for GNUstep + Objective-C !
😛
IMHO if anybody want a good DE for linux the low level API must be written in C or C++. The most important thing in this API the speed. The higher level API must be written in higher level language. C++ is good, Java is better, IMHO C# is the best. The most important thing is the stability and the prodictivity. IMHO the main reason of the success of KDE the C++ based API – but a C# based API can give better productivity. And it must be free and open source – IMHO the one of the biggest problem of KDE the Qt and it’s license.
The stable and well-designed high level API is also very important. It is also a big problem with linux: if you use any old program (witch is based on XXX.YY.ZZ version of any library or application) you can’t use it in the newest linux distributions if the original project is not maintaned.
Under windows you can use the most of old, Win3.1, win9x based programs – but the running of 4-5 years old applications under linux can be very problematic. If you want to create a hobby-os it is not too problematic, but for professional purpose IMHO the stability of the API one of the most important aspect.
His blog post is simply part of a GNOME internal dialogue in which many of the core dev’s have been participating. There has been a lot of talk about the future of GNOME: on one hand we have hyper-speculation about some ‘GNOME3’ technology which does not exist and would offer near zero compatibility with older apps, and on the other hand growing awareness of the legacy compatibility issues and the growing need for a stable reliable, albeit ‘traditional’ desktop.
GNOME, in it’s current manifestation, is being heavily pushed to meet the ‘traditional’ requirements of a desktop. Sun/Novell/Redhat are each using GNOMe to offer a ‘enterprise’ desktop. This bodes well with those who are content with the status quo and those who lament the kinds of shortcommings one sees from a traditional desktop vantage point.
But within this growing legacy there is not a whole of of room for manouverability. Tiny changes can lead to massive issues; as more and more people come to know and rely on GNOME the more pressure the dev’s are under to make things work. It is becomming harder and harder to change things and this is likely to increase before the situation gets any better. If one cannot change much due to legacy pressures the only immediately obvious solution is to expand-increasing the array of available tools at the developers disposal. Yet GNOME is going in the opposite direction right now- GNOME is cleaning house eliminating the old component technology (bonobo) and streamlining the libraries in use. This will not go on forever-but GNOME is not in an ‘innovative’ phase right now.
Apparently a lot of work is going on write now to recode certain libraries for better maintenance and more abstract notions of code purity (API ‘cleanliness’)-which is is somehwat disconcerting because this has zero visibile benefits to users in the short term-although these steps help the platform in the long run.
Additionally there is the step towards usage of freedesktop technologies. GNOME is trying to use freedesktop technology to provide solutions for things which were once done in an exclusively GNOME way. Yet this move is also difficult. It is mind boggling how difficult it is to get GNOME and KDE dev’s to agree to any particular one underlying tech solution-dbus almost became a desktop-independent IPC mechanism. But according Mathias Ettrich (sp?) dbus can’t really be considered a success – the NIHS ruled the day yet again-just look at the xdg mailing list it is painful indeed with the exception of a few clearer heads the antagonism between KDE and GNOME developers successfully moots most progress before the door even gets open. Both camps are equally guilty in my view. I still applaud the attempt by GNOME to utilize the freedektop.org as a way to provide cross-desktop inter-application support and I really appreciate the few active KDE dev’s who are jointly working towards freedesktop solutions-progress is being made albeit slowly, painfully.
The next big thing on the horizon is all of the new graphics stuff emerging from xorg. Yet GNOME does not seem to be preparing for rendering the new technologies avaliable to developers in a way which can stimulate development. The only people taking next ge graphics seriously are the Enlightment guys. Sure Owen Taylor is moving GTK+ to cairo but this exposes virtually nothing in the way of API for creating trully powerful graphical interfaces. What we will immediately see is composited GTK+-yes it will look nice and smooth but nothing really exciting. The ongoing shenanigans with the file-picker stuff in GTK+ leaves me little room for optimism about next gen graphics-I simply cannot fathom how GTK+ got itself into the predicament it is in now where so many GNOME apps can’t even effectively use the primray GNOME API-and this stuff is *basic* functionality-not anything exagerated.
Dbus/mime-spec presents perhaps 60% of a solution to what bonobo once provided. But in dropping bonobo GNOME has abandoned the last vestiges of a modular component technology. Everyone knows how buggy and bloated bonobo was-but without a modular component tehnology GNOME has no easy way to expand within the confines in which it now finds itself in. And if a solution to this vacancy is postulated as a something to do for GNOME3 GNOME as we know it may really run out of steam due to a lack of venues of possible development which don’t break with legacy compatibility.
The speculation around GNOME3 is only going to increase unless work is done to expand the available alternatives present within the GNOME-2.x line. And although I would love to see a GNOME3 eventually I have more faith in the Enlightenment folks regarding next gen technology. If the GNOME dev’s could simply iron out some of the more crack-inspired bugs in the current code base and develop a framewrok for expansion and experimention within the given legacy desktop-we as users could look forward to a gradually improving, self-consistent and bug free desktop-which itself is a *really* high goal, even if it is much less sexy…GNOME3 will be a fork- a fork which will break all compatibility and which willnot be releasable for a long,long time(think year 2001 and talk about E17). Getting a project off the ground which needs so much time before users can start using it is exxtremely difficult- E17 is going to succeed despite everone having written it off at least a dozen times over the years-I doubt that GNOME could pull it off-for I see no one in the GNOME camp with the same kind of fanatical dedication like Rasterman and co.I would love to be shown wrong….
/*rant
Now I would love to have some feedback from KDE supporters as to the following issues:
Why oh why didn’t Trolltech engage themselves in working on solidifying the cairo API ? Trolltech has developed Arthur which is the Qt/KDE only answer to cairo. Although I am really glad to see that Trolltech is now engaging some dev’s to help out with xorg-why didn’t they work together rather than competing on non-existant technology ?
Why oh why does KDE have to do *their own* zeroconf stuff rather than contributing to the avahi development ? Avahi is hosted at freedektop.org is this the problem ? the licenscing issues are the same for KDE and GNOME ie. these are distro issues ?
Why does KDE decide to implement their own nx client/server stuff instead of pushing to get nx proxy technology into xorg ? Don’t worry I already know the answer- there is no ‘KDE’ each and every developer for KDE works totally indepenedently and there is very little in the way of KDE-wide consensus or direction.
And of course now KDE is developing it’s own next-gen search technology competing with another non-existant technology and duplicating shitloads of research and work ?
I really appreciate people like Mathis Ettrich (sp?) and the few cool-headed KDE guys particpating at freedesktop.org. I also appreciate the quality of work the guys at KDE are doing-KDE is quite amzaing actually. But the Not Invented Here Syndrome so apparent in KDE actually hurts the future of the free desktop and makes KDE philosophically uninteresting to me….
rant/*
> And it must be free and open source – IMHO the one of
> the biggest problem of KDE the Qt and it’s license.
Stop that license trolling!
Qt is GPL, KDE is mostly under the GPL and the LGPL (especially the libraries).
All free and Open Souce.
>> What “scripting language” usually implies is “not suited
>> for the development of large scale, mission critical,
>> reusable systems”
> Exactly, and since Python are used and suited for all the
> above it is clearly not correct to imply it’s only a
> scripting language.
Your claim was Python is not a scripting language. I defined what that is supposed to mean and gave a reason why it is. You are again just saying it is not by mereley negating my argument. Pretty weak reasoning 😉
It is certainly *possible* to develop big projects in Python but that does not mean it is *suited* for this task. Btw. I also think that C is not a good choice for large scale development either. But its static compilation model make it unsuited for scripting as well. At least most flaws of C are well known.
> /*rant*/
Because KDE’s as well as QT’s implementation simply work. FreeDesktop.org is GNOME-land and most ‘technology’ *cough* there was written and implemented because GNOME lacked them and needed some solutions. The FreeDesktop.org people permanently force or trying to force KDE to adopt their technology and often the developers come to the conclusion that they have to drop their superior KDE technology in favor to the weaker GNOME (…err) FreeDesktop.org one. With the huge amount of dissatisfied people leaving GNOME and joining either KDE or Mac OS X, GNOME will become quite irrelevant to the public soon (or maybe it is already), regardless of FreeDesktop.org or not.
Q: Why oh why didn’t Trolltech engage themselves in working on solidifying the cairo API ?
A: Have you worked with Cairo? Have you worked with Arthur? Do you understand that Qt is cross platform? Do you understand the issues with Cairo? They aren’t comparable.
Q: Why oh why does KDE have to do *their own* zeroconf stuff rather than contributing to the avahi development ?
A: Avahi does not work. Avahi is not comparable to kdnssd – it is a peer to the apple mdns responder. The avahi code, when it works, will be an option for implementing kdnssd on top of. Also, there is a glib dependency in avahi that is an issue requiring rectification.
Q. Why does KDE decide to implement their own nx client/server stuff instead of pushing to get nx proxy technology into xorg ? Don’t worry I already know the answer- there is no ‘KDE’ each and every developer for KDE works totally indepenedently and there is very little in the way of KDE-wide consensus or direction.
A. Do you understand the issues with putting GPL’d code into X?
I think that there is some duplication of work, but you need to understand that this isn’t a zero-sum game. People work on what they find fun and interesting. Not working on something doesn’t magically allow you to finish something else.
I’m not involved in any of those technologies but from what I’ve read about them I get the distinct impression that you don’t know what you’re talking about.
[I cannot comment on Arthur <-> Cairo. But that’s a question to Trolltech and not to KDE anyway]
> Why oh why does KDE have to do *their own* zeroconf
> stuff rather than contributing to the avahi
> development ?
What avahi equivalent is KDE developing? KDE’s zeroconf support *uses* the library from Apple. No duplicate effort here.
> Why does KDE decide to implement their own nx
> client/server stuff instead of pushing to get nx proxy
> technology into xorg ? Don’t worry I already know the
> answer- there is no ‘KDE’ each and every developer for
> KDE works totally indepenedently and there is very
> little in the way of KDE-wide consensus or direction.
Bzzzt, wrong. nx is no KDE technology. It’s a GPLed product/lib from a company called nomachine that KDE happens to support. You may want to ask them… but do you really think x.org will link to a GPLed library? You must be kidding.
> And of course now KDE is developing it’s own next-gen
> search technology competing with another non-existant
> technology and duplicating shitloads of research and
> work ?
Beagle and Tenor are hardly comparable, Tenor is much broader in scope (which must reflect in the design, you cannot just extend beagle). And why aren’t any GNOME developers working on Tenor?
I would really like to see people understanding the first paragraph on the software page of freedesktop.org:
> “Software hosted on or related to freedesktop.org
> Some software has made its way here to live. None of
> this is “endorsed” by anyone or implied to be standard
> software, remember that freedesktop.org is a
> collaboration forum, so anyone is encouraged to host
> stuff here if it’s on-topic.”
Just the fact that a package is hosted there does not mean *anything*. Not using a solution from there has *strictly nothing* to do with NIHS.
Only if a solution is technically sound and superior to its competitors, and there are no integration issues (technical or other) it will get adopted by more than one desktop project and become a de facto standard in its field. Just hacking something up and putting it up at freedesktop.org is just not enough. So one always has to look at the details, not just say “project xyz is not using the software from freedesktop.org, must be NIHS”.
You killed a very thoughtful post with your speculation. You want examples of NOT INVENTED HERE. I’ll give you a few:
1) The kiosk tool has been around for a long time and works well now. Why do the Gnome folks have to invent Savayon, which is hardly out of the planning stages? Why don’t they use the kiosk framework to control Gnomeapps so that we have one single tool to lock down and do policy management of all apps, irrespective of whether they are a KDE or Gnome app?
And for what is worth the front end and back end for kiosk are separate. Thus, it would be trivial to do a Gnome front-end. Instead, Gnome chooses to reinvent the wheel.
2) Egroupware works great today and interoperates with KDE (Kontact) and with Outlook (plug-in is in the making). Why not create a plug-in for evolution and be done with it. Now you have a powerful, useful groupware solution, one that has been in the top-5 active projects in sourceforge for the last 2 years. What do the Gnome folks do? They make a huge hoopla about “HULA”, another project which basically has no users, no existing knowledge base, no deployed base. Useless, worthless duplication of effort.
3) On search. You should really go and read what Tenor is. It does so much more than what google search in windows or beagle in Gnome do. It is very worthwhile reading.
4) The Gnome camp risks self-implosing. Sun pushes Java, Novell pushes Mono and Red Hat doesn’t really care about the end-user desktop right now, even if they are making some cool technology. In the meantime, Longhorn and Mac OS will get another deployment cycle, which means that users will not be thinking of switching to something else for another five years. You see, there are these windows of opportunity and Gnome is losing them because it is lost in endless parochial battles.
For all of the above reasons, I think new developers should look at what KDE is doing and what it has to offer:
1) A world-class framework of libraries and classes that is documented and used by lots of big names. (Look at the roster on Trolltech’s site).
2) No infighting. No disagreements about development languages.
3) Stability, stability, stability and features that neither windows nor Gnome currently offer.
I could go on, but I’ll leave it here. All I am trying to say is that we all have certain perspectives on these isues based on our specfic experience. I was able to complete a complex cross-platform application to control IP cameras and record video output to HD with Qt/KDE in less than 3 months. No other platform offered the ease of deployment and productivity of KDE.
There are even other key GNOME people who think about stopping the work on their products. Read what Damien Sandras (author of GnomeMeeting) has to say:
http://ploum.frimouvy.org/?2004/10/25/6-i-dont-want-people-to-use-g…
Boy, that’s FUD at its best.
First of all, that’s not Damien Sandras’ Blog. That’s someone’s other that talks about Applications being so integrated in the desktop that they are not considered applications anymore.
Second, if you see the link there to Damien Sandras’ original message that provoked that entry, says this about gnomemeeting:
I started porting it to OPAL for SIP support, that is like writing a new GnomeMeeting. Is it worth it? I don’t know, but I’ll do it.
“Novell have pressed forward with Mono.”
ximian’s vapour marketing again. Astroturfing for Mono was never so subtile.
>It sure feels to me that I get a lot out of static typing when I need to do things like change some API in the
>system, and the compiler can give me an error if I miss changing some code that calls that API.
Not having static typing in the language is not a problem, since you can use external tools for this. Using those tools much the same way you use the compiler to find syntax errors and such. For python you have tools like pycheker(sp) and pylint(?). Similar tools also exist for other languages.
And that’s the problem with software programmers today. They think that OO maps perfectly to all problem domains. The reason I’m in love with python is because it does not force any programming paradigm on its users.
I think it’s even worse. They don’t know any other paradigm than OO so they can’t even have the oppinion that OO maps perfectly to their problem or not.
Not that this matter much in our case, as GUI application development is an area where OO usually is a good choise.
Anyway Gnome have to work with whatever human resources that are available.
I do not see the point of rewriting libraries in GTKMM. The libraries in existence today WORK! Why rewrite GTK+ is C++ for no valid reason? It can not get anymore OO than it is already. What does rewriting the whole library in C++ or Python or Java for that matter gain the community. Nothin!
I must have been unclear. What I meant was that applications should be built in OO languages (e.g. C++). What the libraries use doesn’t matter much as long as they work, and are well documented, and that they can be called in a way that looks native to the OO languages of choise for building applications.
The problem is not the language. This is an architectural design problem. The whole architecture needs to be refactored. And I hope to God it does not involve rewriting anything in another language. Some libraries need to die.
I doesn’t know enought to have any valuable oppinion on that. But the fact that I instantly felt lost when I tried to do something in Gnome but felt at home right away in KDE structure may be an indication that you are right.
GNOME needs to adopt more freedesktop.org standards. GNOME needs to find a way to attract more developers. GNOME needs better documentation. GNOME needs a better more powerful and intelligent development tools, so that writing GNOME apps is fun and not tedious.
Agree completely
GNOME does not need to be written in your favorite language. Once again it is not a language issue. It’s just a lot of inconsistencies at the API levels.
As long as application level stuff use OO I and have don’t care what language they use. I somewhat favor strongly typed languages such as C++ or Java at least for large projects as it makes it easier to catch programmer blunders. I don’t know C# very well but that would probably work fine too.
It is also easier to create good tools for strongly typed languages.