Linked by Eugenia Loli on Sat 30th Apr 2005 08:48 UTC
Gnome 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.
Order by: Score:
by Anonymous on Sat 30th Apr 2005 21:43 UTC

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.

RE: Anonymous
by Arron Washington on Sat 30th Apr 2005 21:54 UTC

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!

@Arron Washington
by Anonymous on Sat 30th Apr 2005 21:59 UTC

But that's why GNOME has bindings. These languages can access the core GNOME libraries via the bindings.

RE: RE: Anonymous
by Anonymous on Sat 30th Apr 2005 22:11 UTC

"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

@Anonymous
by . on Sat 30th Apr 2005 22:21 UTC

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.

v So true
by AnotherAnonymous on Sat 30th Apr 2005 22:28 UTC
Sad
by Uno Engborg on Sat 30th Apr 2005 22:36 UTC

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.

I dont get why Python hasnt been chosen
by Anonymous on Sat 30th Apr 2005 22:46 UTC

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?

Just a note...
by clausi on Sat 30th Apr 2005 22:47 UTC

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.

@uno
by Kman on Sat 30th Apr 2005 22:49 UTC

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.

Is this because of GNOME's archictecture
by Eric on Sat 30th Apr 2005 22:52 UTC

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

re: Sad
by Bill on Sat 30th Apr 2005 22:59 UTC

the real problem is that 50% of gnome libraries simply suck
bonobo is deprecated
gnome-vfs is orrible
gnomelibs ??
gstreamer is bloated

re: re: Sad
by Anonymous on Sat 30th Apr 2005 23:04 UTC

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.

RE: Bill
by Grumpy on Sat 30th Apr 2005 23:07 UTC

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.

RE: Just a note...
by clausi on Sat 30th Apr 2005 23:12 UTC

Sorry about the typo.

Obviously not a good day to post.

Re: Just a note...
by . on Sat 30th Apr 2005 23:18 UTC

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.

@Bill
by Uno Engborg on Sat 30th Apr 2005 23:18 UTC


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.

Re: re: re: Sad
by John Nilsson on Sat 30th Apr 2005 23:22 UTC

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...

v @Bill
by Praz on Sat 30th Apr 2005 23:22 UTC
@Uno
by . on Sat 30th Apr 2005 23:24 UTC

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?

It's not the languages
by Anonymous on Sat 30th Apr 2005 23:25 UTC

(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)).

v
by . on Sat 30th Apr 2005 23:25 UTC
They were wrong from the beginning...
by Anonymous on Sat 30th Apr 2005 23:30 UTC

...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++.

@clausi
by The Bitland Prince on Sat 30th Apr 2005 23:30 UTC

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.

Re: why Python hasnt been chosen
by Morty on Sat 30th Apr 2005 23:30 UTC

>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.

Re:They were wrong from the beginning...
by . on Sat 30th Apr 2005 23:33 UTC

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.

Re:They were wrong from the beginning...
by Anonymous on Sat 30th Apr 2005 23:40 UTC

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?

you know what I think . . .
by colin powell on Sat 30th Apr 2005 23:42 UTC

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?

@Morty
by Anonymous on Sat 30th Apr 2005 23:43 UTC

"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.

Well this might be a bit radical but...
by johnlein on Sat 30th Apr 2005 23:44 UTC

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.
:)

flop
by Praz on Sat 30th Apr 2005 23:47 UTC

gnome motto is less is more
less features
less documentation
maybe less developers

Um
by Chris on Sat 30th Apr 2005 23:52 UTC

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.

v @Uno
by Chris on Sat 30th Apr 2005 23:53 UTC
@Chris
by johnlein on Sat 30th Apr 2005 23:56 UTC

Good PyGTK app...

Pick one, the list is long.

http://www.pygtk.org/applications.html

@Kman
by Uno Engborg on Sat 30th Apr 2005 23:56 UTC


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.




What?!
by Chris on Sat 30th Apr 2005 23:58 UTC

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 ;) .

RE: Just a note...
by clausi on Sat 30th Apr 2005 23:59 UTC

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.

Re:They were wrong from the beginning...
by . on Sun 1st May 2005 00:00 UTC

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.

Not going to happen.
by Anonymous on Sun 1st May 2005 00:00 UTC

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.

@johnlein
by Chris on Sun 1st May 2005 00:02 UTC

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 ;) .

@Anonymous
by Someone on Sun 1st May 2005 00:03 UTC

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.

RE: Well this might be a bit radical but...
by clausi on Sun 1st May 2005 00:06 UTC

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.

@.
by Chris on Sun 1st May 2005 00:06 UTC

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.

@Chris
by Morty on Sun 1st May 2005 00:07 UTC

>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.

@Chris
by johnlein on Sun 1st May 2005 00:08 UTC

Cheese itches need scratching to. Look at most of the freeware/shareware on Windows. ;)

@clausi
by Chris on Sun 1st May 2005 00:09 UTC

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.

@Someone
by . on Sun 1st May 2005 00:10 UTC

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.

@Chris
by . on Sun 1st May 2005 00:13 UTC

Apologies, the response was directed to Anonymous, not you.

@IP: 144.80.185.---
by Someone on Sun 1st May 2005 00:14 UTC

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... ;)

Do IKVM and IronPython provide a solution?
by pobst on Sun 1st May 2005 00:14 UTC

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.

@clausi
by johnlein on Sun 1st May 2005 00:15 UTC

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.

@Anonymous (IP: ---.dip0.t-ipconnect.de)
by Morty on Sun 1st May 2005 00:16 UTC

>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.

IronPython
by Someone on Sun 1st May 2005 00:17 UTC

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

RE: Chris
by Abraxas on Sun 1st May 2005 00:19 UTC

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.

@.
by Legend on Sun 1st May 2005 00:20 UTC

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 ...

My ridiculous opinion :)
by molnarcs on Sun 1st May 2005 00:20 UTC

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.

Re:Do IKVM and IronPython provide a solution?
by . on Sun 1st May 2005 00:21 UTC

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.

slack
by 2501 on Sun 1st May 2005 00:22 UTC

is this why Slackware decided to get ridd of gnome????
-2501

@ johnlein
by clausi on Sun 1st May 2005 00:25 UTC

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.

@Uno
by Anonymous Penguin on Sun 1st May 2005 00:29 UTC

"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?

@Legend
by . on Sun 1st May 2005 00:29 UTC

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.

@Clausi
by johnlein on Sun 1st May 2005 00:35 UTC

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.

@ johnlein
by clausi on Sun 1st May 2005 00:46 UTC

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).

@johnlein
by John Nilsson on Sun 1st May 2005 00:51 UTC

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).

@John Nilsson
by Anonymous on Sun 1st May 2005 00:56 UTC

> 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.

@clausi
by johnlein on Sun 1st May 2005 01:02 UTC

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.

@johnlein
by Moochman on Sun 1st May 2005 01:04 UTC

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.

Menu Editing
by jojo on Sun 1st May 2005 01:05 UTC

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.

QT
by jojo on Sun 1st May 2005 01:07 UTC

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.

RE:@Uno
by Uno Engborg on Sun 1st May 2005 01:09 UTC


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.

Re: @John Nilsson
by John Nilsson on Sun 1st May 2005 01:11 UTC

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.

.
by Anonymous on Sun 1st May 2005 01:18 UTC

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.

@John Nilsson
by Moochman on Sun 1st May 2005 01:25 UTC

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).

@Moochman
by John Nilsson on Sun 1st May 2005 01:37 UTC

(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.

...
by John Nilsson on Sun 1st May 2005 01:47 UTC

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...

@Anonymous Penguin
by Uno Engborg on Sun 1st May 2005 01:52 UTC


"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.

v Wow
by xVariable on Sun 1st May 2005 01:57 UTC
Problem
by kaiwai on Sun 1st May 2005 02:19 UTC

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.

@Legend
by Dianne Hackborn on Sun 1st May 2005 02:27 UTC

"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.

Does anyone have a problem with python?
by egarland on Sun 1st May 2005 02:53 UTC

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.

@Uno
by . on Sun 1st May 2005 02:53 UTC

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.

The problem is shared libraries
by Jacob on Sun 1st May 2005 02:58 UTC

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.

Re: Gnome isn't fun anymore
by Nathan on Sun 1st May 2005 03:20 UTC

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?

ordinary user means.....
by halfmanhalfamazing on Sun 1st May 2005 03:30 UTC

---------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.

market share
by halfmanhalfamazing on Sun 1st May 2005 03:36 UTC

------------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.

@(IP: 144.80.185.---) - Posted on 2005-05-01 02:53:53
by Uno Engborg on Sun 1st May 2005 04:13 UTC


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.

Much ado about nothing
by CrapFilledTeaCup on Sun 1st May 2005 04:19 UTC

Why not let market forces decide?

Coders will pick the language they prefer...there is no crisis, well maybe in the short term.

RE:The problem is shared libraries
by Uno Engborg on Sun 1st May 2005 04:21 UTC

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

@Uno
by . on Sun 1st May 2005 04:34 UTC

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.

GNOME 3 based on GNU Classpath + Java ?
by bact' on Sun 1st May 2005 07:47 UTC

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 !

:P

Desktop requests
by LC on Sun 1st May 2005 07:57 UTC

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.

I think Edd Dumbill overstated his case....
by karl on Sun 1st May 2005 08:53 UTC

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/*

Re: Desktop requests
by cm on Sun 1st May 2005 09:44 UTC

> 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.

@Morty
by Anonymous on Sun 1st May 2005 10:05 UTC

>> 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.

@karl
by Anonymous on Sun 1st May 2005 10:16 UTC

> /*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.

KDE technology choices
by Brad Hards on Sun 1st May 2005 10:26 UTC

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.

@karl
by cm on Sun 1st May 2005 10:27 UTC

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?


Freedesktop.org
by cm on Sun 1st May 2005 10:44 UTC

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".

@karlk
by Eu on Sun 1st May 2005 11:24 UTC

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.

v Cry,Cry,Cry.....That 's all you guys do.......
by Rick James on Sun 1st May 2005 12:25 UTC
Another one bites the dust.
by Anonymous on Sun 1st May 2005 12:27 UTC

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...

v @Rick James
by johnlein on Sun 1st May 2005 13:03 UTC
Re: Another troll bites the dust.
by Dekkard on Sun 1st May 2005 13:56 UTC

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.

astroturfing MONOpoly
by gerd on Sun 1st May 2005 14:03 UTC

"Novell have pressed forward with Mono."

ximian's vapour marketing again. Astroturfing for Mono was never so subtile.

@ Dianne Hackborn
by Morty on Sun 1st May 2005 14:09 UTC

>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.

@(IP: 144.80.185.---) - Posted on 2005-05-01 04:34:29
by Uno Engborg on Sun 1st May 2005 14:12 UTC


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.

Not that bad
by John Nilsson on Sun 1st May 2005 16:10 UTC

I instantly felt lost when I tried to do something in Gnome

I recently gave an Ubuntu disc to someone fed up with Windows. So far she has managed to play CD's with oggs, surf the web for help and copied a complet fat32 partition to her home folder. Not the action of someone beeing lost is it?

Granted, I had to help her setup /etc/fstab to have the disc availble, and help her find the right /dev/ttyS (echo atdtblah ;) ) for her modem to setup ppp.

This is stuff that Gnome could handle better, there allready is facilities to manage /etc/fstab and scaning for a modem can't be that hard... but it isn't a problem with UI architecture, simply lack of tools.

RE: Not that bad
by Anonymous on Sun 1st May 2005 16:33 UTC

Go back and re-read the thread, perhaps you'll answear in the right context next time.

better development tools needed
by Brian Delard on Sun 1st May 2005 17:01 UTC

Glade is a step in the right direction but Gnome needs more easy to use development tools. Writing a Gnome application is still a hassle and that's not what it should be. It prevents many prospective programmers from contributing. Overall Gnome is making slow but significant progress and the availability of better and easy to use development tools will tremendously speed up the process.

@Karl
by Michael Thaler on Sun 1st May 2005 17:27 UTC

Your "rant" was a very interesting to read, thank you for taking the time and writing all this up. I agree with most of what you have written. To answer some of your questions concerning KDE:

Arthur was developed by Trolltech and not by the KDE developpers. Arthur can in principle use Cairo as a backend, but right now it doesn't. Zack Rusin, a KDE developer recently hired by Trolltech to work on X wrote in his blog, that currently it just doesn't make sense to support Cairo because Cairo is not mature enough (http://www.kdedevelopers.org/node/view/978)

KDE also does not use its own zeroconf stuff, but Apple's client library. There is an interview with one of the KDE zeroconf developers: http://dot.kde.org/1114696139/. It seems that Apple changed the licence of their zeroconf client library at some point so that KDE could use it. The developers says Avahi is just not mature enough.

KDE also doesn't decide to implement their own nx server/client stuff. They basically used the GPL'ed code from NoMachine. Maybe it would be nice if this would be implemented within the XServer but I am not sure if this is feasable.

And I think the answer why KDE developers do not contribute to Beagl is pretty obvious: Beagle is based on Mono and I doubt that we will see any Mono based code in KDE soon.

But there is obviously another point: many of the KDE people code on KDE in their spare time, it is their hobby. It is obviously much more exciting to code your own search engine then to just take a project and help to improve it.

I would also really like to see more corporation between KDE and GNOME. Right now both DE's are lacking a lot of things, especially applications and things like X could really need some helping hands. But on the other hand I don't blame people for doing what they like best in their spare time, even if I would prefer if they would work on something else.

v RE:mac vs linux marketshare
by halfmanhalfamazing on Sun 1st May 2005 18:13 UTC
server link
by halfmanhalfamazing on Sun 1st May 2005 18:24 UTC

http://www.themacobserver.com/article/2002/10/28.7.shtml

Just to round out what an above link doesn't seem to state.......

We could be nice for argument's sake and say that in the past 3 years, apple has grown so incredibly fast that they multiplied their server share by a factor of 10.....

they still can't touch the 20-something percent of linux on the server.........

v xfce
by wally on Sun 1st May 2005 18:35 UTC
Re: What?!
by David on Sun 1st May 2005 18:45 UTC

Who just said c was never meant to write OO code? Do you have any clue what you are talking about?

Yes. C was never meant as an OO language at all. Even C++ can do a lot of strange things in terms of OO development (down to the programmer and/or the toolkit really), but it was designed to support OO development.

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.

If you think C is an object oriented language because it provides some of these things then you're totally mad and don't understand the OO concept. Encouraging the use of objects is not object oriented programming.

Re: QT
by David on Sun 1st May 2005 18:55 UTC

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.

Then you'll continue to be using programming tools and libs that aren't good enough to get where some people want to go. I hate to paraphrase Microsoft, but nothing is completely free in that context.

Besides, if it comes down to it then I'm sure we'll see LGPL, Qt-compatible extensions to Qt to allow people to do what they want.

@ .
by David on Sun 1st May 2005 19:05 UTC

And GTK+ is not?

No.

It's called bugzilla.

Using Bugzilla doesn't magically get anything fixed.

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.

Oh yer, that's why people are complaining about the Gnome and GTK development infrastructure and talking about higher level environments and languages? Give me a break. If you think that's eons ahead of something like Qt then you've got some very strange ideas.

The fact is that a desktop environment (or anything at a desktop level) is inherently object-oriented in its nature, and that's what C++ and Qt gives you. You need to have that solid base - bindings don't bloody cut it!.

And if you are really dieing to use C++, then use GTKmm, at least GTKMM doesn't try to reinvent the bloody wheel.

Pardon? If you're referring to the C++ standard then for the Nth time, the C++ standard is rubbish and is not condusive to actually getting any work done.

Re: Another one bites the dust.
by David on Sun 1st May 2005 19:23 UTC

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:

Just because somebody is asking questions and is possibly suffering from a bit of burnout (possibly), that hardly means that GnomeMeeting is somehow dead.

I just wonder how many bits of software we would think ar totally dead if we could read internal posts and e-mail at Microsoft and Apple.

Good Python Prog
by Anonymous on Sun 1st May 2005 22:14 UTC

Large parts of VegaStrike are also written in Python.

http://vegastrike.sf.net

Vegastrike and Python
by MamiyaOtaru on Sun 1st May 2005 23:38 UTC

And we (the vegastrike and privateer remake devs) wish we hadn't used python. The lack of static typing makes debugging and following someone else's code utter hell.

In a statically typed language, when I see some varialbe I am not familiar with I can look for where it was declared and know what sort of object it is: I can quickly find the code for that class and see what methods and variables it has available.

With Python, Something gets passed in from another file and I have no idea what it is. I have to hunt down the file that passed it in (and sometimes yet another file passed it there) and so on until I can get a clue what sort of object it is supposed to be.

Debugging is also hell. There's nothing less fun than launching Vegastrike and trying to ensure that every possible random occurance in the random universe happens so we can be sure there isn't some type error in the code. It would be so lovely to know at compile time if there were any glaring errors or omissions. I'm sure there are some workarounds, some way of type checking beforehand but who needs workarounds? I'd rather simply have the functionality in the language.

In short, after having used python in a large project, we wish we hadn't.

It always comes back to this...
by Saem on Mon 2nd May 2005 00:22 UTC

Developer technologies. If you feed your developers, they'll feed your desktop with apps. KDE is executing comparatively better in this regard, the core team spends a lot of time on frameworks and making the developers life easier. I'm always surprised that even the smallest one off KDE apps, are of rather high quality and are complete in a rather short period of time, accompanied by loads of goodies, largely because the environment is rich.

I've said this many times before, but it bears repeating, gnome needs to work on developer technologies by way of frameworks and libraries so that they're more compelling. Build technologies and make them easy to roll in.

The desktop is basically a run time environment, language support is an issues you have to deal with. If you're going to do it in a language make sure it's not going to create problems for you down the road. Gnome could be smart about things extend C, C99 or what have you so it's easy for them to develop like Qt/C++, rather than maintain some moronic attachment to "purity" and get things going. Due to C heritage, they could still interface with languages easily.

It's because of KDE's rich libraries. In actual fact besides core classes and QT tutorials, KDE documentation is really poor, it's just that it's well made and rather digestable that you can really fly through it and do some amazing stuff.

As for Freedesktop.org and KDE. KDE technology has moved into FD.o so KDE does put in. Others put out solutions and then morons here and elsewhere say, "why doesn't KDE use it?" That's simple, FD.o is not a standards body, so just because it's up there, doesn't make it relevant or legitimate in anyway. Also, these "compelling" technologies aren't quite there yet, usually they're immature; moreover, KDE has existing, tested and understood versions, why change for the sake of changing? Remember, it's not a standard, so that's not the answer. Even still a lot of them already exist in KDE.

kde / freedesktop
by MamiyaOtaru on Mon 2nd May 2005 00:33 UTC

Speaking of KDE and freedesktop, one thing I never understood is how KDE could have the excellent DCOP only to have someone else decide to make DBUS and convince a load of people that KDE should switch to it.

KDE implements something, someone else makes a knockoff and pushes it as the standard. Seems pretty much par for the course.

Re:Vegastrike and Python
by Morty on Mon 2nd May 2005 01:57 UTC

>It would be so lovely to know at compile time if there were any glaring errors or omissions. I'm sure there are >some workarounds, some way of type checking beforehand but who needs workarounds? I'd rather simply have the >functionality in the language.
Not a workaround, you can consider it a part of the compile. Set it up to be a part of your makefile if you like.
PyChecker: http://pychecker.sourceforge.net/
PyLint: http://www.logilab.org/projects/pylint/project_view

As for the code folowing problem, have you considered using a better tool(editor)?

Another one bites the dust.
by Anonymous on Mon 2nd May 2005 03:13 UTC

Another of the core developers who feels like Edd Dumbill. Read the blog from Mickael Hallendal

http://micke.hallendal.net/archives/2005/05/what_is_gnome.html

RE: kde / freedesktop
by Spark on Mon 2nd May 2005 03:14 UTC

Sigh... Comments like this only provide food for the haters. The DBUS situation is really very simple and unspectacular:

KDE has DCOP, which is excellent but was never really meant to be used outside of KDE (or Qt).
DBus was created when some people realized that it would be mighty cool to have this kind of simple interprocess communication throughout the whole system, ideally spanning multiple desktop environments and even the kernel! So DBus was built with a goal to be as simple and independant as possible, to make it an interesting and feasable option for as many projects as possible (including KDE).

Now DBus exists and is getting used left and right. Everyone is fairly happy with it, even the KDE developers who participated in the design of it. If people ask for KDE to use DBus, they don't do it because it's "recommended by freedesktop.org" (it's not) or because "Havoc says so" (he's not), but simply because those people see the value of KDE communicating not just with itself but with everything else out there. It is _not_ important which technically ends up being used, as long as it was carefully designed to not step on anyone's toes. DBus now exists and you may use it or not. That's all.

Personally, I'd love to see the KDE project pushing for more desktop independant software in the future, that would be a huge win for everyone. But right now most KDE technology depends on KDE, so it's just silly to complain about everyone else developing new technologies!

Re^2: Vegastrike and Python
by cm on Mon 2nd May 2005 03:17 UTC

> PyChecker: http://pychecker.sourceforge.net/
> PyLint: http://www.logilab.org/projects/pylint/project_view

Are there any equivalents to these for Ruby?

@Spark
by Anonymous on Mon 2nd May 2005 03:28 UTC

> Now DBus exists and is getting used left and right. Everyone
> is fairly happy with it, even the KDE developers who
> participated in the design of it. If people ask for KDE to
> use DBus, they don't do it because it's "recommended by
> freedesktop.org" (it's not) or because "Havoc says so" (he's
> not), but simply because those people see the value of KDE
> communicating not just with itself but with everything else
> out there

Well it's not only DBus that makes a whole Desktop. Now we have DBus inside GNOME but does it do anything spectacular yet ? or is it embedded in a way to make it look less hacky ? DBus besides Bonobo is what we have now and all the other stuff to be deprecated. Atm GNOME is getting bigger and bigger and I ask myself what problems are we going to solve ? Temporarely we cause more problems than solving them.

KDE also asks what problem does DBus solve for them ? Their Desktop seem to work perfectly, has a good framework, nice tools and the applications look and feel similar. Maybe DCop wasn't meant for outside KDE but think back, the KDE people warned Miguel de Icaza years ago because they ran in the same problems, they initially wrote one Object Model based on CORBA, failed and then invented DCop. Miguel de Icaza could have easily jumped on the DCop process with KDE during that time and would have till now a forked, working version of DCop for GNOME.

DCOP
by Saem on Mon 2nd May 2005 04:21 UTC

DCOP is for IPC, so programs can communicate with other programs and scripts can work with programs and all that jazz.

Anonymous (IP: ---.dip.t-dialin.net), you are thinking of kparts, which allows embedding and is a "leaner" version of CORBA. Problem with CORBA is weight, problems with KParts is if the part crashes, the app crashes and it's a C++'ism.

But yes, KDE learned a lot from KDE 2.x and got a lot of wonderful technologies out of it, KDE 3.x a testament to that work, it's absolutely wonderful how things, just come together, especially for the developer and thusly for the user.

The minor improvements that have been made since are made by standing on that foundation. The really slick thing is that KDE will be another slew of wonderful technologies in addition to what KDE has now.

Re: MamiyaOtaru
by Anonymous on Mon 2nd May 2005 05:11 UTC

You can use reflection to determine the type of a parameter passed from anywhere in your code base, to enumerate its methods and attributes, and read its documentation.

Re: Python
by MamiyaOtaru on Mon 2nd May 2005 06:48 UTC

Happily, I only work with the python code infrequently. Nonetheless, Python is a big part of the project now so it behooves me to learn it better; thank you all for your pointers.

It certainly has its place, I'm just not convinced it has a place as part of a large codebase. I've got a slew of fun comments from old IM logs where the guy who does work with the python code mitches and boans about python ;) It has done a good job controlling the AI and random universe logic once the code gets solidified, so it's not all bad ;)

a plan
by johnMG on Mon 2nd May 2005 07:52 UTC

Here's a wild idea: Use Free Java with Gnome. Wait -- read on.

Step 1: Take the GCJ and Classpath projects, rename the language they implement from Java to something else, like, say, "tofu". Remove all mention of that word "Java". This should remove any legal worries about using an "illegal" or non-compliant Java implementation. Hmm... GCJ-->GCT ? ;) Of course, Tofu happens to be just about exactly like Java (who knows; maybe it will even have const. (There ya' go Dianne ;) ).

Step 2: Use Java-Gnome (Tofu-Gnome? ;) . Since the Gnome and GTK+ libs provide much of the foundation classes/API that's needed, *much* of Classpath can be omitted for simple use with Gnome. This eliminates tons of overlap (with regard to API functionality).

Step 3. Tell the now teeming and excited masses ("Java" devs who want to write desktop Gnome apps) that they can now start using Java^h^h^h^hTofu with Gnome via Tofu-Gnome for their apps.

@Mamiya Otaru
by johnlein on Mon 2nd May 2005 09:13 UTC

Check you incoming type like this if you want.

foo = 5
if type(foo) == int:
print "its an int"

Bloat *is* a problem!
by Anonymous on Mon 2nd May 2005 09:51 UTC


Contrary to what this guy says. Bloat is a major problem with GNOME. Sure, Windows suck but is that a reason to be content with sucking as well?

The recent initiative which aims to reduce the memory footprint of common GNOME components is very much needed.

That the project is a mess of small libraries that nobody can untangle and use without everything else is another, and totally different bloated beast...

bah....i goofed....
by karl on Mon 2nd May 2005 12:32 UTC

Regarding my oriiginal post:

My question about the work of KDE to integrate nx instead of puishing towards gettting it into xorg was, well, somewhat baked. I realized what I had written not 5 minutes afterwords...oh for hindsight. Yes, as others have mentioned and thoughtfully corrrected- nx is GPL'ed which means it could not go into xorg even if there were no orther outstanding political issues involved therein. So basically that part of my rant was nonsense...just erase your memory of it and we will act as if I didn't say it _;)

@Brad Hards
by karl on Mon 2nd May 2005 12:33 UTC

@Brad Hards...

"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."

No I have not worked with Arthur and my 'work' with cairo has been closely following it's evolution.

And yes I am sure that cairo and Arthur are considerably different with only a degree of overlap. But I made this comment after having learned about Lars Knoll and Zack Rusin contributions to render. The fact is that for years there was virtually no distro/toolkit direct participation in the XFree developpment process-due, at least in no small part, to the structure of XFree itself-Xfree has been replaced by xorg which is open and inviting, actually encouraging participation. When I saw the what those 2 developers were contributing my initial reaction was -hey great, someone is finally addressing some of the performance problems with render that Rasterman has been bitching about over and over again. And of course I am very happy that they, trolltech employees, are now actively contributing- but I can't suppress the reaction- why only now-why haven't they been working more closely together. Of course it's foolish to complain about something after the fact but it is mind boggling how little communication, let alone cooperation actually occurs.

Keith Packard wrote the original implementation of Render- something which was part of the reason why he got locked out of CVS commit access to Xfree-precipitating the formation of xorg. People have been lamenting render's performance since it came out-although everyone has greatly benefitted from the work which Keith Packard did. Finally Trolltech has decided to contribute the man-hours of some of there dev's to help common cause-great. Of course Arthur and Cairo are different-but cairo would be stable by now if more talented developers had been contributing to it all along.

Cairo has tremednous input from Owen Taylor from GTK-it is being desgined to be usefull for toolkit developers-now if Trolltech, or the KDE community at large, had invested more energy into Cairo, Cairo might be better suited for the range of things dev's need in QT...of course there may be other issues involved which I am no looking at- but the participation of Trolltech/KDE dev's in the core technologies involved in xorg is paramount-the benefits go far, far beyond QT/KDE-everyone benefits....I am sure that the cross-platform aspect of QT/Arthur refers to QT rendering independently of Xorg-x11...but more communication and working together between the respective groups can help both projects...

As regards Avahi:
My point is that all of the desktop environments are confronted with the same licenscing problems-the distributors have the say over what tech is used in the last instance. If you are saying that there is no licenscing issues involved in using the Apples mDns software then I have to ask why the hell someone is working on avahi...I suspect that the people working on Avahi are workin on it due to some percieved licensce issues. And if this is the case it would just make far more sense for the KDE and GNOME folks to use the same underlying code.

I know that KDE dev's don't want to touch anything with a ten-foot pole which dependes on glib-asied from gstreamer...And I know that such issues are akin to religious holy-wars...but I really wish there were more people involved in this who would keep an eye towards the broader issues involved-the issue of seemless integration of such tech into all cross-desktop applications far outweighs, IMHO, such relatively small issues like whether or not one needs to depend on glib....

@cm
by karl on Mon 2nd May 2005 12:34 UTC

@cm,

I seriously doubt that Tenor goes far beyond the scope of Beagle let alone Storage. I read the posts about Tenor written by the author and aside from his 'this is soo much better than x,y,z' I see little in the way of concrete fuinctionality which it provides which is adressed in Beagle/Storage. And of course the dependency issues which preclude most meaningful cooperation are exagertaed once mono comes into spiel. I am aware of this-but again I only wish to see the people involved in these projects actually communicating with each other and sharing ideas-sharing code is secondary-because if they share ideas then there is a possibility of convergence in the future.

What Beagle is bringing to the desktop is the equivalent of NT/XP streams implemented via xattr attributes-a fundamentally differnet and superior way of dealing with metadata. If Beagle is suscessfull we may be looking at an actual change in how people work with metadata and consequently things like xattr may become a new requirement for the future Linux desktop..Now if Tenor shares some of these ideas then work can be done to enable a comprhensive and inclusive approach to providing such functionality system wide-beyond the confines of this or that metadata searching utility....

@eu
by karl on Mon 2nd May 2005 12:36 UTC

@eu,

Firstly I completely agree with you regarding Egroupware and Hula is just Novell hot air...

Secondly, although I admire the work that has gone into kiosk and wish that GNOME had more of this functionality I see little in the way of overlap between saybayon and kiosk- saybayon(sp?) is only really usefull for prototyping and then deplyoying the unique arangement of the desktop/panel/icons-whereas kiosk can be used to lock down virtually all aspects of all programs. Saybayon is extremely useful and extremely vaulable for those admins that most tailor the look of GNOME desktops..particularly in LTSP settings-I simply cannot wait to try it out. Moreover something like kiosk is totally incompatible with the gconf system used in GNOME-i think kiosk is a function of the wonderfully simple kde .ini files-the configuration subsystem of KDE is far, far simpler to administer than the gconf system- but gconf offers certain benefits such as dynamic apply which is where things like saybayon are needed...manyually hacking exported gconf trees into something usable a true nightmare and saybayon can make this step really, really simple-open up a Xnest login and create your desktop-save it and apply it for that group which needs this desktop....

Again I am not so convinced that Tenor is so much 'more' than Beagle...

@ Michael Taler
by karl on Mon 2nd May 2005 12:37 UTC

@ Michael Taler,


Thanks for not ripping me to shreds over the my nx remark...;)

If Apple did change the license on Zerofconf such that KDE can use it I see *zero* reason for the GNOME folks to be working on a replacement library. My point was, and is, that where it's possible both projects should be using the same code, where this is not possible they should be sharing implementation ideas.


Thanks for the links posting to more concrete information much appreciated.

to everyone...or why exactly am I talking aout KDE here?
by karl on Mon 2nd May 2005 12:38 UTC

to everyone:

I really appreciate the hard work that the Trolltech/KDE dev's are doing. My *rant* was not meant to belittle the ongoing work or to make light of the contributions involved. But I am not the only one who percies this Not Invented Here Syndrome. And KDE is certainly not the only guilty party here-there are probably an equal number of GNOME devs who suffer from the same problem. But GNOME take on a whole is not known for a bad case of NIHS whereas KDE has been seen this way-perhaps unjustified, perhaps it is now changing.

The comments of some in this thread only serve to illustrate what I have pointed out here. Some view Mathias Ettrich(sp?) as a traitor due to his willing *collaboration* with Freedesktop.org. I witnessed the heroic battles around Dbus-and I saw some KDE dev's really work hard at making Dbus plausible and appealing for KDE. Dbus is after all the only tech worth mentioning in the past years where KDE and GNOME worked together for the benefit of everyone. I guess we must label Dbus a relative success-relative against the void of cooperation which has been the rule over the past several years.


And for those who rail against Freedesktop.org as some kind of front for GNOME-get a grip and come back to reality. There is a whole world of other WM's out there that are profitting everday from work at Freedesktop.org. Most of the stuff at Freedestkop.org does not come from GNOME developers and *gasp* not even Redhat employees. Sure Freedesktop.org is *not* a standardization body-standards bodies are of questionable utility in something as quick and free evolving as the free desktop. But you cannot at once both disdain freedesktop.org and the approve of the goals of cross-desktop interoperability- it is *the* venue for said such interaction-there is no substitute.

@Karl
by Michael Thaler on Mon 2nd May 2005 16:14 UTC

I don't really care if KDE and GNOME use the same library for, say zeroconf, as long as it works well. The real problem for the user is, that right now GNOME applications integrate terribly in a KDE desktop and the other way round. Everytime I have to use gimp (which is a really fine applicatio), I get totally annoyed by the gtk file selector. It is just a pain to use the gtk file selector if you are used to the KDE one. I don't want to start a flamewar which one is better. I just want to point out that it is really important that GNOME applications integrate well in KDE and KDE applications well into GNOME because neither of these desktops has enough (really good) applications and the big majority of people is probably using applications from both projects. I think this is far more important then sharing some underlying libraries (at least for the users). Maybe dbus can help with this, I don't know. But I really would like to see someone working on this.

@karl
by David on Mon 2nd May 2005 16:52 UTC

I seriously doubt that Tenor goes far beyond the scope of Beagle let alone Storage.

Beagle is pretty much nothing, and is simply a way of merging document search, e-mail and IM search within one application - albeit reasonably nicely. It deserves nowhere near the amount of hype it generates however. Microsoft has simply been doing this with their new search mechanisms now that WinFS has effectively died.

I thought Storage sounded interesting when I first read about it in detail, but it seems to have stagnated a bit now as implementing it in the Gnome infrastucture and the VFS seems to have presented some problems.

The way KDE infrastructure works and is structured means that they have a really good shot at making Tenor work well, but you always have to be careful about implementing layers above a filesystem in that manner, performance being a concern. Tenor, however, will do so much more than a simple search tool in that it is a framework programmers can use and it will save contextual link information so that you know what each document and bit of information was related to and searching those relationships.

@karl
by Aaron J. Seigo on Mon 2nd May 2005 17:26 UTC

i've read your comments in this thread and the errors and mischaracterizations in them just make my stomach turn. bleh.

Matthias Ettrich is not viewed as a traitor. i have no idea where you got that impression. we don't need people stirring up muck that doesn't exist and doing so is truly a low-class act.

asking why Trolltech hadn't done more for Free X in the past is to completely ignore the realities of X development politics in the past as well as Trolltech's position historically as a small company in the industry at large.

as for your assertion that "you cannot at once both disdain freedesktop.org and the approve of the goals of cross-desktop interoperability- it is *the* venue for said such interaction-there is no substitute." .. that is so amazingly flawed logically it's not even funny. i can support cross-desktop interop AND note problems in FD.o's current processes.

your statement is exactly akin to those who used to say "you can not at once like X11 and not approve of XFree86 - it is *the* venue for X development these days."

such ideas are amazingly dangerous to progress, because if we do not allow ourselves to examine (and re-examine) the structures and processes we put in place to achieve our goals, those structures tend to stop being useful at some point. FreeDesktop.org is not the purpose, interoperability is the purpose. therefore FreeDesktop.org is not the goal; it is a means towards that goal.

the only thing i'll comment on is Tenor, and to just say this: i completely understand that you don't see how it's more than Beagle. but when you get to play with it in KDE4 you'll understand. ;-) we've been doing development rather quietly, and experimented with "coming out of the closet" briefly. the next time you'll hear more about Tenor is probably when there are applications using it.

opinion - wxwidget - python
by sanctus on Mon 2nd May 2005 17:41 UTC

I think the layer between the toolkit and the X server should be a participative project. On top of that, we should have a toolkit/desktop that just follow a phylosophy and an ideology (a la windows(kde), a la apple(gnome), a la nostalgy(gnustep), a la what you want). Then Developpers should then use a something like wxwidget, which will be directly build against the toolkit/desktop/preference of the user. so if you are in kde, you the app will be native QT, gnome/xfce native GTK, windows ... Apple ...

This will also give a incredible advantage to un*x; develop once, deploy everywhere. What is not the case with MS nor Apple OS. KDE/XFCE/Gnome/what_you_want would shared instantly, without putting a mass of developer in a ideology war but in a co-operative work and then offert a real bunch of competiv and quality apps that all user and programmer will benefit.

Integration/interoperability of the too, will be an endless battle in my opinion.

@about python
I have start coding in my free time in python a year ago, and sincerely I think it is the best language I have used. But I don't think it is suit for everything. personally I prefere statically typed variable.

I think, that to write simple gui application or console tools, python is *the_ proper language.(mail, word, calendar, messenger, etc..., portage, top, parser,etc...) Fast enough, really powerful, rich in feature, rapid development and validation.

Python could, if it were more used, bring more powerful, more rapidly, more evolutionary programs to programmers and users. I also believe that a project Like OO.o would be far more advanced now if it was coded in python. (but we can debate endlessly on that ;-) But python need a good IDE. yeah I know boa-constructo, eric3 and company. In fact, gnome need a good IDE. and no gedit+glade is not one.
Secondly, python need a cleanup in is library, java+.net+gnustep should be closely look to help python library coders to regroup it nicely.

This thread show somehow, that opensource project are repeating history. The unix war that give Microsoft the easy opportunity to eat everything.

@david
by mattb on Mon 2nd May 2005 19:59 UTC

Beagle is pretty much nothing, and is simply a way of merging document search, e-mail and IM search within one application - albeit reasonably nicely

...using kernel hooks to do on the fly indexing, and adding a full, customizable metadata engine a la spotlight.

winfs and storage are about at the same level as a full document store, beagle/tenor/spotlight/longhorn search are all more or less the same thing, at various states of readyness, and with slightly different feature sets. as for tenor > beagle, its more that tenor has loftier initial goals, and beagle is alot closer to being done. more or less the same kind of tech.

Re: Aaron J. Siego
by karl on Mon 2nd May 2005 20:14 UTC

Aaron please note that I am simply reiterating what I have seen in the way of comments of others. Perhaps such rhetoric is purely an example of fandom/zealotry and I am sure that no serious dev's actually think that way. One only need frequent the venues where ongoing software developments are being discussed to find that attitude which I paraphrased-yes such comments are assinine, but the sheer contensiousness surronding such issues provides a fertile ground for fermenting such reactions.

As regarding your response concerning Trolltech please note that I did mention how closed XFree once was and that I am applauding Trolltech(and the their resp. employess Zack Rusin, Lars Knoll) for contributing to xorg. I know that Trolltech is rather small and that it only has become recently feasible, with the advent of xorg, for third-parties(distros/toolkit dev's) to easily make contributions. Perhaps I came across as harping at Trolltech, if so that was not the intended effect.

Aaron I read your blog concerning the role of f.d.o. Perhaps my way of enthusiastically embracing f.d.o. triggers such a negative response-almost all of these issues boil down to name- and word games, it's all about language,identity and communication. My pointing out that f.d.o is *the* venue is only pointing out the abundanlty obvious-at this point in time it is the only publicly known venue for such desktop interoperability. I myself have issues with the way certain issues are framed at f.d.o due to the particular interpretation of the boundaries and goals of the 'desktop'. Yet I do not see any other venues for such- perhaps due to my ignorance. My stating this does not mean that I wish to exclude other possibilities as your reading of my text supposes-on the contrary what I wish to see is more cooperation where such makes sense and fruitfull communication between GNOME and KDE dev's and all those other dev's of the other free desktop wm's and I would heartily applaud a multitude of venues for advancing a reasonable degree of common cause. I do not envision a totally unified venue which shoots for some kind of far-fetched uber-intergration. What I envision is talented intelligent people willing to do the horrificly difficult task of trying to slowly form certain specfic consensi-ie. multiple point of consensus without the need for some over-arching grand consensus. It most certainly is tiresome, wearisome work, something which requires immense patience and something which gives little in the way of short-term positive feedback. But over the long run it could produce the best software ever known.

I'll have to take your word regaring Tenor. But I wrote what I wrote because Beagle is actually necessitating the use of extended attributes for our filesystems and harnessing these for metadata (if I understand correctly). Such issues effect the entire operating system-requiring those fs's which support xattr's,kernel modules for support, recompilation of kernel-or alternatively becomming part of default distribution of kernels, etc. These are far ranging effects and the reason I made the comment I did about sharing of ideas between Beagle/Storage and Trenor is that if such were to occur we might be more likely to see a more powerful widely adopted metadata subsystem. From this viewpoint the questions become:a) will Tenor also require such complex changes in our configurations ? b) will Tenor be able to make use of the xattr's for managing metadata c) will it possible to have access to the same metadata in both ? I just hope that the interested parties can find points of common ground at least conceptually.

@karl
by Aaron J. Seigo on Mon 2nd May 2005 21:05 UTC

> but the sheer contensiousness surronding such issues
> provides a fertile ground for fermenting such reactions

i completely agree. in the complex system that is open source development, it's useful to allow such contention to take its course between those doing the work, and equally useful to try and restrain from reacting blindly.

i know how hard the latter is, as i have failed at that more than once myself ;)

re:FD.o:
> It most certainly is tiresome, wearisome work, something
> which requires immense patience and something which
> gives little in the way of short-term positive feedback.
> But over the long run it could produce the best software
> ever known.

i complete, 100% agree =) the challenge is to ensure that the tiresome, wearisome work is both encouraged and done. and that's been the problem recently, is that it has not been encouraged enough (this is mostly a marketing issue; i've discussed it at length with Waldo =) and too much non-productive work has tried to use the FD.o channel to gain canonicalization despite that not being FD.o is for.

it's the swapping of the concept that "we need interop" with "we need FD.o" that is, IMHO, unuseful. as you said, it's largely a matter of phrasing and how Fd.o is marketed to developers.

right now it's been marketed in such a way as to attract certain types of projects that are best done elsewhere, and it's made it harder than necessary to gain acceptance for the newer stuff that the people with their heads screwed on straight have been working on within the venue of FD.o =)

> a) will Tenor also require such complex changes in our
> configurations ?

no, or at least from the perspective granted from working on the third revision of the concepts, it doesn't seem that way at this point.

> b) will Tenor be able to make use of the xattr's for
> managing metadata

there's no reason one couldn't write (parts of) the storage system to use xattrs. for day 0 we are working at something that is platform agnostic and so aren't thinking we can rely on such things.

i fully expect/hope that once Tenor emerges into something resembling stability and usage, that people will target the backend towards things like reiser4, xattrs and .. well, who knows what =)

> c) will it possible to have access to the same metadata
> in both

this would be up to the storage backend, which is fairly modularized from the guts of what makes Tenor itself tick.

HIG...! Hit Ler! ... documentation....
by Big Moron on Mon 2nd May 2005 21:35 UTC

I feel that the thing about documentations is... REALLY BAD...

I mean...

The app that would allow me to connect to the net (modem, lan)... how do I see if the modem works, ...er... fives minutes later... OK so I go to the help file, and what do I get:

"Bla Bla Bla"

FOR REAL... I am not kidding you... and thats at the user end of things, if it is like that at the developer end they are doomed...

For all its virtues... they are laking in what they are supose to be better at... userability, which needs documentation which needs well documented programing so that others can jump in and help...