interestingly, several of the items desrt brought up are actually free software desktop generic. x.org is obviously one of those items. here are some others:
- webkit: started in kde, added to by numerous companies since, it's awesome to see it making its way into so many places in the world including gnome
- policykit: we've already evaluated it for replacing the current "administration mode" buttons in control panels and work is underway to make that transition happen smoothly.
- telepathy: a spec that we're using in decibel
it's very nice to see the free software desktop world sharing so many things in common, helping make all our software nicer.
several other items on ryan's list look familiar to me, e.g. gbus which sounds like a start getting gtk+ apps a bit closer to the kind of sweet, sweet happiness that is QtDBus we've enjoyed for a while now.
other items are concerning. like vala. a whole new language? wowzers. i understand the problems they are trying to solve, it just seems like a rather inefficient way to address it. there are so many other languages out there ...
tracker also digs at me. i'm glad we have xesam now so at the desktop level we can pretend to ignore these things but ... really .. how many indexers do we need? realize that each indexer means re-writing file support plugins, redesigning the common bits internal to each and then trying to sort out the resulting mess. ubuntu gnome will apparently ship in the future with tracker, ubuntu kde will ship with strigi. try explaining to the user base why there are two different indexing systems. i'm all for personal experimentation; i'm all for innovation; i'm all for creating free software where it doesn't exist. i don't get the purpose of having strigi and tracker. beagle and strigi? sure, they are different beasts in various technological metrics. i do wish kde and gnome would share strigi as a solution, however. we could work on it together to the benefit of all. there is a reason, after all, that strigi has no desktop dependencies.
i'm not, btw, suggesting the tracker developers should stop what they are doing. it's not my place to tell others what to work on. i am of the opinion that projects such as gnome and kde ought to be aware of the ramifications of their technology choices. kde has been increasingly mindful of this, and you can see it from decibel to phonon to dbus to ...
if tracker gets proper xesam support then we can, at the desktop level, ignore it somewhat. but i don't think this is doing our user base a great favour.
i wish the gnome project the best as they push forward with their vision. i hope we continue to find ways to explore our individual directions while supporting, or at least not creating unnecessary interference, with each other's individual and our shared directions.
25 comments:
"finding their feet"?
C'mon Aaron, that one just hurt ;)
hehe.. i thought it was cute, but then i've always had an odd sense of humour.
ok, here's one in my own direction: kde is getting their gears to mesh for 4.0 ;)
Tracker was started long before strigi - the right question is why does strigi exist?
@anonymous: besides the fact that tracker is neither a broadly established nor overly old project itself, let's look at another example: dcop existed before dbus. there were other open source office file formats before ODF. kde had a mimetype database system before the share mimetype spec. etc, etc.
if it was simply a matter of "who was there first" then there's all kinds of decisions that would be taken differently, but it would suck for our users.
strigi came about rather organically from the desire to have the ability to recursively grep through compressed files combined with a project to create a jstreams type api in c++. kde has been experimenting with various search systems for years at this point, primarily with ones that approached us first. so this wasn't a conspiratorial NIH event, either. in any case, strigi evolved into a very useful indexing system from there and now has quite a bit of involvement from projects like nepomuk (an EU research project) and kde, supports a growing number of file formants and is quite fast.
honestly, i don't see the need for both tracker and strigi and it would be nice if the larger free software projects could coordinate on this matter.
will it suck for tracker if tracker is used by fewer projects? sure. will the tracker devs be defensive and argue against such a thing? i would expect so. is that in the best interest of the free software desktop user base? i don't think so.
it's a matter of recognizing where everyone's interests are and optimizing the decisions made in light of that.
note that i don't complain about beagle vs strigi. i see marked technical differences that make sense to keep both out there in the market to let the darwinian forces do their thing.
There's no reason why tracker and strigi shouldn't both exist -- it's like asking why we've got KDE *and* Gnome. As far as Vala goes -- it looks like a simple wrapper above the unholy mess known as GObject. Of course, it could be argued that they could just use a real OO language, but you've gotta admit that it's easier binding python to C than C++/Qt. In any case, the move to dbus-centric stuff should ease interop between worlds.
GNOME is slow and steady, while KDE regularly guts itself to add new features and applications that may take awhile to get stable. Different approaches to a unix desktop, but I agree with you they need to find more common ground than xorg. Although Okular uses poppler, it's a start.
@geneth: "it's like asking why we've got KDE *and* Gnome."
not at all. kde and gnome have rather different methodologies with not a whole lot of overlap of the type and extent strigi and tracker. kde / gnome is more like strigi / beagle.
@skeith: "while KDE regularly guts itself to add new features and applications that may take awhile to get stable."
if by regularly you mean every 5 years, then.. sure. otherwise you're repeating a recently born myth that just isn't true. the kde 2.0 -> 3.5.7 development process is the evidence of this for kde, while gnome 2.0 was hardly a evolutionary event.
"more common ground than xorg. Although Okular uses poppler, it's a start."
we have a lot more common ground. ODF, dbus, mimetype dbs, icon themes and naming, window manager hints, telepathy, taglib, webkit and on and on and on and on...
things are pretty healthy these days and getting healthier by the year. which is why we really ought to try and avoid regressing.
Creating a new language?
Hell Aaron, no!
Juerg is trying to make it as close to C# as possible. On the other hand, it's not any complex, in fact, is a such simple small piece of code, most of the work is done writting libraries on the own language, the translation itself is really simple. Then, GCC does the rest of the work :)
Is not that far from what the Meta Object Compiler already does. We're not that different ;-)
Regarding tracker, we are hitting a new ground, and people are trying their own approaches, competition is always good, and expertise around the topic is about to be built on the future.
You are assuming here that if we choose one and only indexer, all the people would work on that indexer, that's wrong.
With different approaches you fill different needs and you explore several ways, and with a standard interface on top (XESAM) we should just let them explore that ground.
If you ask me, on the future, I would like to see the better approach built right into the core of the desktop filesystems, that is The Right Thing To Do, however, meanwhile, let's let them explore the possibilities.
Competition is good, the lack of choice is what would make us weaker.
figure i should also add this:
@genneth: "Of course, it could be argued that they could just use a real OO language, "
i don't care if it is "real" OO, but how about not inventing a whole other language? i mean, how many people know vala compared to ... oh, i dunno ... let's pick something pretty odd.. ocaml? ocaml has way more market share than vala does now or ever will. this is why vala is such an amazingly odd idea.
it's not the issue of using something like vala, it's the issue of using vala itself which is just ... really odd.
the term is "not invented here". but hey, it is the gnome project's prerogative and i hope it works out. it just seems like a problem they could find a much better solution for.
"but you've gotta admit that it's easier binding python to C than C++/Qt."
the PyQt and PyKDE people do a pretty amazing job of just that. as do the ruby people, the java people, the javascript people... soon we'll be able to add c# to that list of successes.
if we can do it, i can't see why they can't do it.
i also don't think the point of vala is to bind python to it. bind python to c, sure.
Hi aaron,
I had this discussion with jos about a year ago where we compared technology. jos was keen to unite the projects but unfortunately a number of barriers existed
My lack of knowledge of c++ was the biggest and the acceptability of glib based tracker in KDE was unknown (or undesirable?) so uniting them became difficult
Tracker and strigi are not really the same thing. Tracker is more of a cutdown nepomuk + strigi all rolled into one. I always see strigi as a dedicated indexer like Beagle and these differences are crucial too (jos wants strigi to remain a dedicated indexer)
Interestingly, nepomuk are currently writing their own backend for strigi and they are writing their own indexer too which is almost exactly the same architecture as tracker. So yeah strigi+nepomuk and tracker are very similar beasts.
But still a profound philosophical difference exists -
Tracker likes to keep things simple and be extremely fast and optimised. Nepomuk prefers to be more complex for flexibilities sake and so requires more work and is likely to be less optimised. Overcoming these would need both projects to achieve a happy medium. (I have had lots of conversations with Phreedom on #xesam on freenode aout this too)
In an ideal world we would unite - its just getting there thats difficult. I am open minded and willing to listen to offers of course...
Hey Aaron,
You mention Vala being not such a good idea because there are plenty of languages available already.
I agree with that point of view (C#, Java, D, C++, Python, ... are indeed great languages that fulfill all the needs)...
Except for the fact that all these languages introduce new problems (both technical, like linking problems, as social-political ones).
Often small problems, problems that I personally don't see as a problem (like the social-political ones of C# with Mono) but that others do see as a major and significant problem for which they'd immediately quit the GNOME project.
In contrast with those languages does Vala integrate in a perfect way with with the existing GObject infrastructure of the many GNOME components and libraries.
Also note that Qt and KDE don't use "normal" C++ either: several things have been added to the object system. Which is definitely the right way. However, it does illustrate that even for Qt and KDE the standard C++ language introduced difficulties that required these modifications.
Anyway. Good that you mention how both the Gtk/GNOME people and the Qt/KDE are more and more cooperating. I also think we should do this even more. Visit each other's conference and talk more with each other.
I assure you I will talk with Qt/KDE developers as often as I can. Checking whether there's room for cooperating and synergy.
Let's hope our flaming users will finally stop arguing what the best camp is, and start accepting that this is not how the actual software developers doing it (for them) are thinking.
We love each other, we love competing each other. Competition is great. Let's with great passion compete on the things that we're good at. Let's share as much as possible if it makes sense to share. Like sharing D-BUS APIs and as much common infrastructure as possible.
"You mention Vala being not such a good idea because there are plenty of languages available already.
I agree with that point of view (C#, Java, D, C++, Python, ... are indeed great languages that fulfill all the needs)...
Except for the fact that all these languages introduce new problems (both technical, like linking problems, as social-political ones)."
Yeah, but I think the point trying to be made here is, wouldn't it be a better idea to start with an existing language rather than inventing a whole new one, which requires contributors to learn the foibles of a whole new system and compiler, and relearn syntax tricks...
@aaron:
Regarding bindings... well, just look at how many releases of PyQT, compared to the number of releases of PyGTK, (the same with RubyQT/Ruby Gnome) the reason for such difference is simple, maintaining C based bindings in other languages is just easy, and with GObject, is almost automatble. I know Richard Dale is doing a great work on the smoke front, however, it's still a hard issue to bind C++ libraries outside of C++.
And don't take me wrong here, I don't think that C++ is a bad language, or anything like that, but the facts are, maintaining bindings from C++ is just harder and implies more human work than with C. C++ on the other hand, has its own advantages over C in other fields.
Anyway, actually, the point of Vala, is precisely create automatic binding generators for libraries written or binded inside vala automatically to other languages.
Vala is to GObject what the meta objects are is to QT, just adding more high level object semantics to the existing object syntax.
@dark phoenix:
That's not a good idea, because it would prevent us to create GObject based platform libraries that could be binded from other languages.
We just cannot use another language to write platform libraries in the GNOME project.
@Anonymous "Regarding bindings... well, just look at how many releases of PyQT, compared to the number of releases of PyGTK, (the same with RubyQT/Ruby Gnome)..."
Well, PyQt version is 4.3, so are Ruby bindings to Qt... I mean, they are based on the last Qt version available, and new versions are released right after a new Qt is released too. So, what's the point ?
@lucio:
Bug fixes? Doc updates?
@Anonymous
http://www.riverbankcomputing.com/Docs/PyQt4/pyqt4ref.html
http://developer.kde.org/language-bindings/ruby/index.html
I recently read that article about Gnome and was frankly a little dissapointed to find that not much of interest to the user is in development - and this is coming from someone who really likes Gnome over KDE for its design principle. However, it looks like KDE4 is clearly going to have an edge over Gnome in being the more featureful and innovative release. On the other hand, Gnome has some very interesting project for mobile devices underway where KDE doesn't seem to be giving as much focus to. It just seems that both teams have a different way of working however and I don't see anything wrong in that.
As for the strigi versus Tracker debate, I thought people were used to it by now that the Linux community has several projects for doing essentially the same thing. Obviously the people who develop strigi are in favour of their project and would like to see widespread adoption of it and vice versa - I just wish the fragmentation would end in other areas as well (the different package management systems, for example). The debate about developing different projects with same purpose could start here and go beyond into the what makes Linux adoption that much more difficult for the new user. In other words it's never going to end and it's always going to be there.
@ aruiz: Juerg is trying to make it as close to C# as possible.
Why just not face reality and make a C# -> C translator?
@Diego:
Because, the reallity is, that Vala is a C# -> C translator.
:)
PD: Next time, read.
other items are concerning. like vala. a whole new language? wowzers.
I think it's more a case of getting something that can be truly included with Gnome for everyone to use. Mono isn't becoming a part of Gnome, and neither is Java.
However, I think the Gnome people are slightly missing the point. It's not a higher level language that's needed, but a solid, dependable, consistent and usable programming toolkit and framework for developers to use. A modern language might be nice, but it isn't going to solve the issues they think it will.
I think it's an inefficient way to solve the problems they want as well, but really, the only way they can achieve it.
It's not a higher level language that's needed, but a solid, dependable, consistent and usable programming toolkit and framework for developers to use.
Solid, Dependable, Consistent and Usable:
We don't break API/ABI stability.
We don't remove APIs in order to guarantee backwards compatibility.
We have strict time based release cycles, and we guarantee bug fixes for more than a year for each release.
Our APIs are on several languages, and on most languages, they feel quite natural and usable.
So, what if we have all that, and the only reason that kept people off to write platform libraries is that they have to use C?
I was going to go a bit further, but wasn't thinking straight. Bit of a long post, but I just find the infrastructure differences interesting here. Nothing else.
In response aruiz, yes, the API and ABI is stable, and certainly from a GTK and up point of view that is certainly the case, and is an admirable and difficult thing to achieve at times, and Gnome gets it right. KDE doesn't do half bad, and I've run lots of applications with different versions of kdelibs.
You slightly missed my point though. The problem for developers in Gnome is that they don't have a unified framework for doing things in a consistent way, such as with Qt in KDE, the Mono framework or Java classes, for example. Vala should be the start of pulling all that together, but it's not quite the same thing.
Another thing is the architecture. KDE scores, in many ways people don't realise, because it is built on a complete Qt, cross-platform toolkit. kdelibs is then built on top of Qt and the rest of KDE is built on that. This means that, strictly speaking, KDE does not directly depend on Qt. Qt remains cross-platform, and kdelibs might be by virtue of it being written with Qt, but it's not guaranteed with things like Solid etc. This means that things that KDE needs today can feasibly be built into kdelibs today for the benefit of everyone (subject to KDE's restrictions), in a solid, stable and officially released library, and if things get rolled into Qt in the future then they can be without breaking the API and ABI for KDE applications.
It also means that KDE can depend on more than one library, apart from Qt, and present a unified API to developers through kdelibs that looks the same as everything else, that makes life easier.
The problem with Gnome's underlying libraries is that:
a) There's more than one, and it's not just GTK.
b) It takes a long time to get any new features into GTK for the benefit of Gnome, simply because GTK is about more than just Gnome.
Point a) means that, from a developer's point of view, there are different libraries to pull in, and they're not all consistent in the way that code is written for them and how they are used. This hinders code reuse through the same library not being used by different applications.
Point b) is interesting in that a library like GTK is not independent from Gnome itself. GTK, by definition, is a cross-platform graphical toolkit, so stuff that people would want to see in GTK for Gnome's benefit and to improve it can't be unless it works or is handled cross-platform. This needs to be tested, bugs fixed, improved and then released. If there was a gnomelibs then all this could go in here in the meantime, but that's not the way Gnome is structured. If there was a gnomelibs then much infrastructure could be coded in there, released officially and then rolled into lower libraries like GTK as required without impacting anything.
All this has increased the proliferation of libraries like libsexy and libegg, and sometimes straight code copying, and has impacted cohesion severely. It also decreases consistency and usability.
Personally, this is the biggest reason why I think there should be a Gnome 3.
On top of that, a language that is good enough and easy enough to use across the project is needed. For KDE, C++ is just about passable.
Well, then we are not talking about consistency, we are talking about consolidation and effective reusability of the code, and I agree with you on that regard.
The APIs are very consistent already, even if you are using libsexy or libegg, the slowness for the inclusion in GTK+ is not due to the cross platform nature. The slowness is because API and ABI stability has a payoff, the code grows, and keep it clean while adding new features is not easy.
However, GObject APIs are very consistent already, as an example, using poppler-glib or dbus-glib is really easy when you are familiar with the GObject conventions already. You don't need them to be integrated into a monolithic framework.
The current approach is getting widgetry into GTK+ better and faster, and since the last GUADEC, it seems that GTK+ 3.0 to remove deprecated API and modernize the core is not that far, but we want to be sure that we make this without breaking everything.
Regarding the consolidation and effective reusability of the code problem, it's probably more related to the fact that to inherit in GObject is a copypaste annoying task rather with the fact that libraries are not altogether in the same sourcetree.
Post a Comment