The GNOME team has released GNOME 2.17.5. “This is our fifth development release on our road towards GNOME 2.18.0, which will be released in March 2007. This is also the release which marks the start of the API/ABI freeze for the platform and the start of the feature freeze.”
Who does he mean that’s from Australia?
From the Gnome site it seams that Gnome 2.18 will include the Tracker search engine.
http://www.gnome.org/projects/tracker/
Where does that leave beagle?
Could it be a result in Gnome people distancing themselves from Novell and C#?
I hope this is not the case. Gnome really need some modern language where object orientation is not just an ideom.
Languages like C# make development much faster than plain old C. Personally I would have preferred java, but C# does the job.
Edited 2007-01-11 02:02
I hope GNOME *does* distance itself from Novell and C#. Strategically, relying on an environment created by Microsoft is not a good idea, full-stop. Offering the option of a well-supported C# development environment for GNOME is one thing, but relying on it for core functionality is another kettle of fish.
As far as core system utilities go, and the system-wide search daemon counts as one, low-level C APIs are by far the way to go. There is still no alternative to C as the universal foreign-function interface. The CLR suffices if you can shoe-horn your language into its model, and you’re not concerned about performance. It’s great for “scripting languages”, where any sort of JIT at all is a step up. However, for languages that want to get within a factor of two of native C code, and there are several of those targetting GTK+, there is nothing like a good, lightweight C interface for a low-level native-code generator to target.
Edited 2007-01-11 02:05
Yes. Depending upon Mono for core infrastructure is a majorly bad idea. Just one more poor business decision on the part of Novell. (I swear, I wish we had a good example to display of a company that did everything right, made all the right decisions, and were crushed by MS unfairly. As it is, all we have is a parade of bumbling dunderheads that got squashed.)
At any rate, I’ve used Tracker. It is a lot faster than Beagle, but doesn’t have nearly the capability. The search functionality is not nearly as flexible. And the crawling is limited in comparison. No Evo or Tbird support, for example.
However, I would say that considering the resources of the Tracker devs compared to Beagle, with Novell behind it, Tracker has made some pretty impressive progress.
Especially considering that the core of Beagle is a Java->C# port of Apache’s Lucene[1], so the most interesting part of Beagle was handed to them on a silver platter.
In this case, I have been most *un*impressed by the supposed advantage in speed of development of Mono vs plain old C.
[1] http://en.wikipedia.org/wiki/Lucene
“At any rate, I’ve used Tracker. It is a lot faster than Beagle, but doesn’t have nearly the capability. The search functionality is not nearly as flexible. And the crawling is limited in comparison. No Evo or Tbird support, for example.”
Indexing support for Evolution, Thunderbird and KMail has actually been available in the development version of Tracker for at least a few months now. Look at Tracker developer Jamie McCracken’s blog:
http://jamiemcc.livejournal.com/3782.html
Because of this I do not see that Tracker is limited in any way compared to Beagle.
quote from blog:”I would like to say a big thank you to Laurent Aguerreche who has been behaving like a full time developer on tracker and has given us rocking patches for Evolution, Thunderbird and KMail indexing support”
“””Indexing support for Evolution, Thunderbird and KMail has actually been available in the development version of Tracker for at least a few months now.”””
I’m on the mailing list. But unfortunately I’m on so many mailing lists these days that I didn’t notice that bit.
Thanks for the heads-up. I favor Tracker over Beagle for a number of reasons. But I still think Beagle is ahead, for now.
I also expect that Tracker will overtake.
Time will tell, I suppose.
“Especially considering that the core of Beagle is a Java->C# port of Apache’s Lucene[1], so the most interesting part of Beagle was handed to them on a silver platter.”
Oh yeah?! And Tracker didn’t get sqlite and libstemmer on a silver platter did it?
The CLR suffices if you can shoe-horn your language into its model
You’ve described exactly the problem I have with panel beating a language into the .Net framework, and I just don’t think that language neutrality in .Net and Mono just doesn’t hold water.
Languages like C# make development much faster than plain old C. Personally I would have preferred java, but C# does the job.
Now that Java is GPL it would be stupid not to go for it.
Languages like Python are even more friendly, better supported, unencumbered, and are even saner to use than Java. Or if that’s not to your tastes, try Ruby. In other words, Gnome already supports higher level, modern languages quite well, and they are pervasive in it’s applets. See, for example, Deskbar, which I believe is in Python.
In general, these languages are nicer to use than Java, offer faster development, are better liked in the open source community, and really are generally feel less anal than Java or C#. Java and C# — at least to me — feel like the bastard son of C and C++ trying poorly to fit in with the high-level group of languages, try to add everything and the kitchen sink, and are generally unpleasant to use, in my experience. For god’s sake, Java doesn’t even have sane higher-order functions that you can pass around. even C has a reasonable approximation of this.
And furthermore, object orientation _IS_ just an idiom (and a buzzword). It’s useful in many cases, but it isn’t an end, just a paradigm for structuring programs (the polymorphism OO implies is a godsend for many things, however polymorphism is quite possible without object orientation)
Hi,
you can use Java of course. With java-gnome you can use (all?) gnome functionality with java. I fully agree with you, that some modern languages but python are needed. I’d prefer Java too, but C# is ok. It’s nice to see how fast new applications written in C# come up. F-Spot, Banshee, Beagle…
But since Java is “more free” now, maybe there will be some more gnome applications written for java.
Greetings
Mike
It’s nice to see how fast new applications written in C# come up. F-Spot, Banshee, Beagle…
If only mono-develop was python-develop…
Well, I agree with the previous poster’s comment regarding C. Very well written C code is as good (maybe even better than) any OO lang. But right now when you install gnome you also get Python, Perl, Guile and Mono/C# (may have missed some). I wanted a desktop environment, not a development environment. They should probably start by:
1) Consolidating the libraries and convert more to C based applications. Make the Gnome Desktop environment leaner.
2) Make sure it works well with other *nixs as well. Nowadays it seems its been built for ‘Linux’
3) Start work on a native Gtk/Gnome browser.
Edited 2007-01-11 02:44
1) Consolidating the libraries and convert more to C based applications. Make the Gnome Desktop environment leaner.
I think I’m right in saying that the only bits of *Gnome* not written in C are Deskbar (Python) and Tomboy (C#). Both of these are option, and neither runs by default (at least in a plain Gnome configuration — distributions might have different ideas).
2) Make sure it works well with other *nixs as well. Nowadays it seems its been built for ‘Linux’
Well Sun makes sure it works on Solaris, so that only really leaves the BSDs… and yes, more effort could be put into this, because every BSD installation I’ve ever seen runs KDE. But on the other hand, should the Gnome devs limit themselves to not using new technology like HAL and DBus just because FreeBSD is lagging behind Linux?
3) Start work on a native Gtk/Gnome browser.
Like, um, Epiphany?
http://www.gnome.org/projects/epiphany/
But on the other hand, should the Gnome devs limit themselves to not using new technology like HAL and DBus just because FreeBSD is lagging behind Linux?
Well actually HAL works just fine on FreeBSD. I’m not sure where you got the idea that any of the BSDs were lagging behind Linux. More than likely it was just a cheap shot, but anyways. I think a bigger issue would be to do some cleanup on the libs and code layout so it isn’t a complete son-of-a-bitch to build or upgrade on anything besides Linux. You see most BSD users tend to keep their installations and upgrade frequently rather than the backup-reload-reconfig cycle that seem to be the norm for the Linux crowd now.
Like, um, Epiphany?
Like, um, it was dropped quite a while back. Firefox is supposedly the official browser of GNOME now. I find that a bit sad actually since it’s designed for Windows first, and just happens to be portable to Unices because of it’s Netscape heritage.
Firefox is horrible in GNOME. The default Firefox in Fedora Core 6 has fonts that look like ass, while they look fine in Epiphany (because the latter gets its font configuration info from the standard GNOME mechanisms). The default GNOME browser should be a GNOME-oriented browser, not some cross-platform thing.
If you are talking about the fonts used on webpages, there is no difference between Firefox and Epiphany if Epiphany is compiled against Firefox.
Firefox works fine for me in Gnome. You have to modify .fonts.conf for font substitution (or install truetype/type 1/opentype variations of Helvetica, Courier and Times). Editing .fonts.conf will of course affect all Gnome applications.
AFAIK the same is true for Epiphany if it is compiled against Firefox. Or so it was the last time I had the full monty installed (before I ditched it for gnome-light).
In regard to fonts in menues and so on, you are completely wrong. Menues and dialogues are using Gnome-mechanisms. Perhaps your FC6 is broken
Gnome _is_ cross platform, so the browser should be it as well
The only distribution I’ve seen so far that actually does Epiphany right is Debian Etch. They changed the dependencies for it to xulrunner, which is the proper way to do it. Ubuntu screws this up and makes Epiphany depend upon Firefox itself, along with Yelp, etc. So in Ubuntu if you attempt to remove firefox, it’ll remove half of Gnome with it.
I’m not sure about Fedora Core 6, but it seemed like it was set up the same way as Ubuntu. It’s really sad, because once you learn the ins and outs of Epiphany, it really is an excellent browser.
So in Ubuntu if you attempt to remove firefox, it’ll remove half of Gnome with it.
Oh dear… does Ubuntu do it _that_ way.
Please don’t remind me of FC… I can still remember the distro, though I’m trying to suppress my memories
I’m not sure compiling against xulrunner is the correct approach yet. The officially recommended solution is still compiling against Mozilla (the full monty-solution) rather than xulrunner. But xulrunner is – in reality – good enough.
Personally I prefer Firefox since it works quite well in Gnome (perhaps it’s due to my use flags?) – and because we have a gazillion extensions for Firefox.
Epiphany however is better integrated visually – and to some extent also better integrated in regard to functionality. But not near enough to be a replacement for me. It’s too simple (a common complaint against Gnome
In regard to fonts in menues and so on, you are completely wrong. Menues and dialogues are using Gnome-mechanisms. Perhaps your FC6 is broken
Firefox only fakes these GUI elements by calling Gdk drawing functions to render them. It doesn’t actually use Gtk widgets, which causes a lot of inconsistencies and minor problems.
Gnome _is_ cross platform, so the browser should be it as well
GNOME is an application platform (which can run on other platforms, yes
) and Epiphany is an application built for this platform, Firefox is not.
“””Like, um, it was dropped quite a while back. Firefox is supposedly the official browser of GNOME now.”””
Bzzzt! Thanks for playing. Epiphany continues to be the official Gnome browser. It rocks, too, by the way. You should try it sometime.
Mozilla Corp is *far* too uncooperative and Windows-centric to be considered for the position.
Edited 2007-01-11 04:37
Like I said, it was. Now if it’s not too difficult for you please go do some research on the issue before posting smartass comments.
You’re also conveniently leaving out the fact that epiphany isn’t even a standalone browser and can’t run without having mozilla or fire fox installed to use the damn engine. So even if you were right, you’d still be wrong since epiphany isn’t a browser it’s a mozilla theme at best.
Edited 2007-01-11 04:40
“””Like I said, it was. Now if it’s not too difficult for you please go do some research on the issue before posting smartass comments.”””
It is you who are in error. Please post a reference supporting your position.
Technically, Mozilla is a browser, as is Epiphany. Gecko is the rendering engine that both use.
Epiphany has a dependency on Mozilla (Firefox or Seamonkey), but it’s only using the engine. Basically it’s the equivalent of K-Meleon. If you want to compile K-Meleon, you also have to compile Mozilla. But K-Meleon and Epiphany are more than just themes for Mozilla. They are browsers relying on a gecko-engine.
Epiphany is still the standard browser in a full Gnome distribution. If you – like me – are using a minimal Gnome installation (gnome-light in Gentoo), the default will be Firefox. But that’s because it’s a minimal system
“””But that’s because it’s a minimal system
“””
I believe our friend fsckit is confused… by the fact that Firefox is the default browser in most *distros*.
That is what I don’t understand. All GNOME based distros should have Epiphany, since it’s GTK2 and HIG compliant. Firefox looks horrible in Linux and is even slower than Epiphany…
I like Firefox. Works fine with Gnome, and FF is using GTK2 as well. True, Epiphany is HIG compliant, but that’s hardly a plus for a browser. Epiphany is crippled UI-wise. On my system Epiphany tends to be a bit faster in loading, but not by much.
I’ve said this before and i’ll say it again, you can customize the UI of Epiphany, it’s very good.
You can move the toolbars around, big whoop
What I’m talking about is the Gnome HIG compliant behaviour. Take a look at Epiphany’s preferences. They are sorely lacking with most of the essential functionality for a browser gone with the wind. You can install the epiphany-extensions and get a slightly less crippled UI, but many essentiel elements are still missing.
Galeon is better in that regard, but Galeon today is the same as Epiphany with extreme extensions
OTOH, Epiphany does have a lot of fancy functionality not essentiel to a browser, especially the way it handles bookmarks. Very fancy – and definitely a nice touch. And it feels more Gnome’ish than Firefox, but at the cost of essentiel functionality.
UI-wise it _is_ crippled. Moveable toolbars do not change that
dylansmrjones: UI-wise it _is_ crippled. Moveable toolbars do not change that
Out of sheer curiosity, WHAT part of the UI is crippled. Where is the functional difference to Firefox?
This is a default Epiphany:
http://www.gnome.org/projects/epiphany/images/screenshot1.8.png
This is a default Firefox (wow, it’s really difficult to find a default FF2.0 screenshot):
http://www.phoronix.net/image.php?id=471&image=mozilla_bonecho2_01_… (Early Alpha on Gnome)
http://scr3.golem.de/screenshots/0608/Firefox_2_Beta_2/Firefox_2_Be… (2.02b on MS Windows XP)
You and i know, i will not change your dislike for Epiphany and you will not change my preferences, but tell me, what in day-to-day browsing are you missing?
I like Firefox. Works fine with Gnome, and FF is using GTK2 as well. True, Epiphany is HIG compliant, but that’s hardly a plus for a browser. Epiphany is crippled UI-wise. On my system Epiphany tends to be a bit faster in loading, but not by much.
What’s crippled about Epiphany’s UI? I find it much better than Firefox’s UI. I prefer the one input box that Epiphany uses for URLs, Search, Smart Bookmarks, and History. I also love the hassle free adblock extension.
“””That is what I don’t understand. All GNOME based distros should have Epiphany, since it’s GTK2 and HIG compliant.”””
I agree. Add to that Mozilla Corp’s general attitude of noncooperation and focus on their Windows product. I don’t necessarily disagree with their focus upon Windows users; browser diversity in the Windows world, as well as competition with regards to standards compliance, is critical to us all.
But I fully equate Mozcorps attitude with the kind of uncaring BS that we put up with from David Dawes and the XFree86 guys for years. We supported them for far too long and are still recovering from the damage done by that “member of the community” whom some even thought we should credit by calling Linux “LiGnuX” or some such ridiculous name. (The ‘X’ stood for XFree86.)
Epiphany is Gnome’s browser and should receive the appropriate support and inclusion in distros that Konqueror does.
Continuing to go out of our way to support FF as the default browser in Linux distros is a grave error.
Probably, many people will disagree with me today. But , in the not so terribly distant future, I have an idea that few would disagree with these words.
Edited 2007-01-12 01:20
Continuing to go out of our way to support FF as the default browser in Linux distros is a grave error
I was of this advice the first time I saw Mandrake change to Firefox as default browser. I understand why they do it (compatibility mainly) but I never approve it.
1) It’s still under development:
http://blogs.gnome.org/epiphany
2) If it has been dropped, then why do the GNOME 2.16 release notes mention it?
http://www.gnome.org/start/2.16/notes/C/rnfeatures.html
You can now check the spelling of the text entered in the Epiphany web browser
And from the pages linked above:
http://www.gnome.org/projects/epiphany/
Epiphany is the web browser for the GNOME
3)As mentioned above, the Gecko engine IS NOT firefox or Mozilla. it is a library. Therefore browsers that use it are not just Mozilla skins.
Like, um, Epiphany?
Like, um, it was dropped quite a while back. Firefox is supposedly the official browser of GNOME now. I find that a bit sad actually since it’s designed for Windows first, and just happens to be portable to Unices because of it’s Netscape heritage.
Was Ephiphany really dropped? I know most distributions default to Firefox, but I thought Epiphany was still the “official” Gnome browser.
Edit: already answered. Sorry.
Edited 2007-01-11 19:24
Well Sun makes sure it works on Solaris, so that only really leaves the BSDs… and yes, more effort could be put into this, because every BSD installation I’ve ever seen runs KDE. But on the other hand, should the Gnome devs limit themselves to not using new technology like HAL and DBus just because FreeBSD is lagging behind Linux?
FreeBSD port it so it *just* works; basically, if it compiles, ship it mentality – take a look at KDE and how much of the KDE Administration tool features aren’t implemented on the FreeBSD platform.
I don’t blame FreeBSD, I blame the single mindedness of the desktop developers who failed to implement or work together to create a abstraction layer so that the only thing that needs porting is the abstraction layer rather than relying on poking into the low levels of the operating system.
Take a look at the gnome-cd application to see the mess that is how it handles cds and explicitly calls parts that are only provided by Linux.
As for Sun – their effort so far has been pretty half assed; they have no committment to the desktop; they can’t be stuffed porting the wpi/3945abg driver from OpenBSD to OpenSolaris, they can’t be stuffed updating their distribution to include the latest version of GNOME – it speaks volumes to be about, more correctly, the lack there of, of respect they have for users who have stuck with them, and pushed their products in their organisation even against the odds (Microsoftie fanboys in the fellatio position with their bosses).
Oh, and as for DBUS and HAL; DBUS is already ported, HAL is a POS nightmare of poorly documented code that the Sun engineers are wading through just to get the damn thing adequately working on Solaris!
Someone needs to whack the maintainer of HAL around the head with a clue-by-four and teach them the first rule of holy coding – thy shall maintain documentation as code is written.
Edited 2007-01-11 06:16
HAL is a POS nightmare of poorly documented code that the Sun engineers are wading through just to get the damn thing adequately working on Solaris!
Indeed. HAL, like NetworkManager incidentally, is a God awful mess of undocumented and much Linux specific code, with some embedded shell commands thrown in for good measure. Some people just need a lesson in writing OO code for these things.
Since when is “gnome built for linux”? Did you know that one of the biggest gnome contributors happens to be sun? That the original gnome HIG (Human Interface Guidelines) and much of the administration documentation was written by sun? Take a look at planet gnome and notice that several of the posters are sun employees. Gnome has benefitted a WHOLE LOT thanks to solaris specific features like Dtrace for profiling performance problems. Not only that, but the default desktop for Solaris happens to be Sun’s branded version of gnome named “Java Desktop System”. Don’t believe me, take a look for yourself:
http://www.sun.com/software/javadesktopsystem/faq.xml CTRL F and type gnome
why cant you just roll over and die, damn you gnome you have set back the FOSS movement- by weakening KDE
RIP
ROT IN PIECES
“””why cant you just roll over and die, damn you gnome you have set back the FOSS movement- by weakening KDE
RIP
ROT IN PIECES”””
You know what? I used to think like you. I felt that the community would be better off if we all got behind one desktop and put all our resources into it.
But then I realized that it could never happen. After that, I realized that it was not even desirable.
Acceptance of reality has a way of bringing clarity to a situation, don’t you think?
If Gnome has weakened KDE it was because KDE couldn’t compete. But I don’t think that Gnome *has* weakened KDE.
We can’t say for sure what would have happened. But I strongly suspect that your precious KDE is better off for having had some direct competition, and has benefited from the fruits of collaboration with a sister project.
My favored desktop, Gnome, has benefitted from the competition and collaboration as well, as has XFCE.
And while incompatibilities have marred the landscape, the current spirit of agreement upon common standards are making rapid progress possible.
We are all on the same side here, you know.
Edited 2007-01-11 05:08
We need gnome because no one can use KDE (i.e. Qt) for corporate development without paying a Trolltech tax. A tax which is about 10x higher than the MSFT tax. $2,000 per developer for the pleasure to program in Qt and no tools is not worth it.
Long live Gnome!
I think that C#/Mono is immune from any patent problems for now since the MSFT deal but it is still a risk. Too bad Python refuses to fix that whitespace dependency problem. If you can open a file, change a line, save it and break a totally unrelated line because your tab settings are different that is huge.
Just add the {} already so we can all just use python!
>We need gnome because no one can use KDE (i.e. Qt) for corporate development without paying a Trolltech tax. A tax which is about 10x higher than the MSFT tax. $2,000 per developer for the pleasure to program in Qt and no tools is not worth it. <
Tools are worth whatever you have to spend if they make you money. how is an excavator going to dig a basement with no back hoe? Should he get that back hoe for free simply because he needs it for his business?
It may not be worth it to you, but it is obvously worth it to many people or trolltech would be out of business. 2k is a drop in the bucket to medium to large corporations, If they have to spend 100k to get 50 licenses that is no biggy to decent sized companies.
It may not be worth it to you, but it is obvously worth it to many people or trolltech would be out of business. 2k is a drop in the bucket to medium to large corporations, If they have to spend 100k to get 50 licenses that is no biggy to decent sized companies.
It’s interesting how all the commercial/closed source software for Linux I’ve encountered so far (Acrobat reader, Helix player, NVidia utils, Xten) does not use Qt.
> It’s interesting how all the commercial/closed
> source software for Linux I’ve encountered so far
> (Acrobat reader, Helix player, NVidia utils, Xten)
> does not use Qt.
you forgot vmware player. you also need to get out more, because you evidently haven’t tried Google Earth which is written in Qt. there are hundreds of commercial Qt titles on Linux; well, probably more than that but i don’t have the #s near me at the moment and wouldn’t want to inflate numbers erroniously. the reason you may not have seen them is because they tend to be pretty serious apps like high end EDA.
Yeah and the funny thing is that google earth uses GNOME libs, oh the irony.
But hey, free software free world, use the one that feets you the best.
Yeah and the funny thing is that google earth uses GNOME libs, oh the irony.
No it doesn’t. I’ve had Google Earth install on a system with no Gnome libraries installed at all.
>It’s interesting how all the commercial/closed source software for Linux I’ve encountered so far (Acrobat reader, Helix player, NVidia utils, Xten) does not use Qt.<
yeah, you’re right, guess nobody really uses qt
http://www.trolltech.com/products/qt/qtinuse/qtcustomers
Adobe Agilent Boeing Bosch Brain Innovation Cadence Design Systems Chevron Texaco DaimlerChrysler Deutsche Telekom Duboi Earth Decision Sciences (EDS) European Space Agency Firstlogic Google HP IBM (Qt) Imagineer Systems Ltd. Intuisphere IZotope JD Edwards JMP, a division of SAS KDE Lockheed Martin Mainconcept Mentor Graphics Michelin Midland Valley Exploration, Ltd. NASA OpenMFG Perforce Software Rohde & Schwarz Sandia National Labs Scribus Skype SourceXtreme Synopsys
not that any of these guys really matter in the world, just little ma and pa shops mostly.
“A tax which is about 10x higher than the MSFT tax.”
And how much is the enterprise edition of Visual Studio plus a copy of the MSDN kit?
Its not a tax, its a cost to develop – business its called.
People that use Gnome are leechers – i bet they charge for their programs after they’ve developed them.
And how much is the enterprise edition of Visual Studio plus a copy of the MSDN kit?
$499 dls per develoepr and you get SQL server and all MS goodies too.
Its not a tax, its a cost to develop – business its called.
A cost to hight if you ask me only affortable by big companies.
I bet they charge for their programs after they’ve developed them.
That’s not a crime, sell your work is legitim.
$499 dls per develoepr and you get SQL server and all MS goodies too.
It’s seems to be pretty hard to find a price for Visual Studio Enterprise Edition. The only price I got was about $900 with a plus pack whatever it contains.
A cost to hight if you ask me only affortable by big companies.
Have you already seen this page: http://www.trolltech.com/products/qt/licenses/licensing/smallbusine… ? The Small Business program offers startups and small businesses the initial purchase of up to three Qt licenses (with optional Solutions and QSA add-ons) at a 65% discount.
So if the price is $2000, you can get up to three copies for your small company with just only $700 per copy. That isn’t much more than the price you gave for VSEE even though it costs only $499…
stop complaining about QT’s price- if you don’t want to license your software under the GPL then you shouldn’t be allowed to use QT.
if you dont like the GPL take a hike
GTK is lgpl which even RMS has publicly stated that he beleives it shouldnt be used
We need gnome because no one can use KDE (i.e. Qt) for corporate development without paying a Trolltech tax.
Oh dear.
For starters, you’ve never been in a corporate environment because they don’t value or use free development tools. It’s all Visual Studio or some expensive Java IDE.
Besides, with better integration of GTK into KDE (hint, hint, hint GTK developers) then you’ll have the option you want.
A tax which is about 10x higher than the MSFT tax.
No it isn’t. I’d like to see your itemised costing for this. A MSDN universal subscription is not cheaper, and Microsoft’s development tools are not used to create a free desktop environment, a free office suite, PIM suite, web browser etc. which in Microsoft’s world, you pay for. I take it you did factor that in?
I think that C#/Mono is immune from any patent problems for now since the MSFT deal
You think Microsoft’s deal with Novell makes Mono immune from patent trouble? Right………..
How hard is it to get all your dependencies satisfied and actually build Gnome from scratch these days?
Although I use Gnome on the desktop, last time I looked into build issues was about the same time Slackware dropped it. Back then it seemed that Gnome had so many darn pieces and dependencies that it was a hair-pulling experience to get them all together correctly. In fact, I see that there’s even specialized tools available (Garnome and jhbuild) just for the purpose of building Gnome (possibly in addition to the usual ./configure; make; make install? Dunno).
This isn’t a dig at Gnome. I’m a happy user. I’m just curious to know how much tightening up and trimming down there’s left to do for Gnome. When I see those Release email notices, the first thing I tend to look for is what’s been streamlined or simplified (or if any deprecated pieces are being chopped out).
How hard is it to get all your dependencies satisfied and actually build Gnome from scratch these days?
It’s as easy as before.
There are some more dependancies if you want the optional C# extensions. Some things disappear, some other disappeared. It’s actually better now, as every dependancies is clearly asked for in the configure stage, if it’s outdated or missing.
I use an automated build (with nALFS) since 2001, and most gnome revision go on without any change needed by me. Sometimes, I add or replace one or two dependancies.
As others have mentioned, C is the universal bindings language. There’s always a FFI to C. Even C++ is pretty much frowned upon for the problems it has with bindings. But even if it was just as easy to create bindings to a toolkit like Qt, a project like Eclipse wouldn’t use it, because in theory, Trolltech could go around to the commercial plugin vendors and ask them to pony up. Of course they could fight it based on it not being a derivative work, but it’s silly to take that risk.
KDE has the advantage of not having to worry about finding volunteers to work on their toolkit, but has always been plagued by commercial distro vendors not wanting to put many resources into it.
C++ is pushing the limits of what is reasonable to bind to, and just forget about binding to C# or Java in a high-performance implementation.
The pinnacle of a system library, from a binding point of view, is something like OpenGL or POSIX. Simple procedural APIs. Simple data types. Few to no macros in the interfaces. Trivial to bind to, easy to build richer abstractions on top of. GTK+ is close, though something like Carbon is actually better because it doesn’t try to to foist an OOP model on you. Win.Forms? Please. Unless you retarget your compiler to output CLR bytecode, there’s no hope.
C++ is pushing the limits of what is reasonable to bind to
Yes, but with C++ as opposed to C, you have more type info, and you have an object oriented class structure which already exists. This allows you to be able to automate bindings generation to a greater extent. With a C api you need to do quite a lot of work in annotating the header files with metadata in the form of ‘defs’ files or similar (although that is less of a problem if you can use the same metadata for multiple language bindings).
With the Qt toolkit you also have some quite powerful runtime introspection features you can use. Such as slots, signals and properties which can be queried and invoked at runtime, and integrated with the bindings language runtime.
The approach used by the Smoke library for Qt/KDE bindings is to automatically generate a dynamic runtime for the entire api, which can then be introspected and invoked dynamically. You can then use the same bindings library for multiple languages. The fact that it is hard to produce something like that in the first place is less important if you only have to do it once.
The pinnacle of a system library, from a binding point of view, is something like OpenGL or POSIX. Simple procedural APIs. Simple data types. Few to no macros in the interfaces. Trivial to bind to, easy to build richer abstractions on top of.
All this means is that there is a lower barrier to entry for simple C based apis. Because something is trivial to bind to doesn’t necessarily mean that it will produce a better final result than for an api that was harder to bind to in the first place.
You could argue ‘easier to build richer abstractions on top of’ is better, or maybe with a C++ underlying api you have less need to ‘build richer abstractions’ which could be a plus point. In my opinion there are merely different tradeoffs for C vs C++ as a basis for building language bindings. It is a lot of work to produce bindings for large apis like Gnome or KDE whichever way you do it.
Yes, but with C++ as opposed to C, you have more type info, and you have an object oriented class structure which already exists.
To be honest, I consider the existing OO class structure more of a liability than an advantage. Mapping C++ class hierarchies into certain languages is hard. I’ve worked on doing this from C++ to Lisp/CLOS, and its very difficult to address the semantic gap. If you’re not careful, you end up doing C++ in Lisp (or C++ in ML or C++ in Haskell), and its just not pretty. On the other hand, C’s semantics and datatypes are general enough that most languages contain a large subset of it. For example, even a straightforward automated translation of Cairo or OpenGL comes out as a quite natural, if low-level, Lisp API.
With a C api you need to do quite a lot of work in annotating the header files with metadata in the form of ‘defs’ files or similar (although that is less of a problem if you can use the same metadata for multiple language bindings).
This is certainly true. It’s a lot easier to specify “all QString’s in this API should be translated into Lisp strings” than to have to enumerate all the specific instances of “char*” that should be translated. I’ve contemplated some heuristic approachs for doing this, but in general it can’t be automated completely.
With the Qt toolkit you also have some quite powerful runtime introspection features you can use. Such as slots, signals and properties which can be queried and invoked at runtime, and integrated with the bindings language runtime.
Unfortunately, this approach is not compatible with high-performance language runtimes. In languages where “foo.bar” is in many cases expected to be as cheap as “foo->bar” in C, you just can’t override the member resolution in ways that would allow you to take advantage of such a feature.
All this means is that there is a lower barrier to entry for simple C based apis. Because something is trivial to bind to doesn’t necessarily mean that it will produce a better final result than for an api that was harder to bind to in the first place.
It is generally true that the quality of a binding (especially an automatically-generated one) decreases as the semantic difference between the source and target language increases. In general, the semantic difference between C and a given language is smaller than the semantic difference between C++ and the same language.
You could argue ‘easier to build richer abstractions on top of’ is better, or maybe with a C++ underlying api you have less need to ‘build richer abstractions’ which could be a plus point.
There is some truth to this, but on the other hand, its often true that the abstractions that exist in C++ libraries are ugly abstractions, from the point of view of code written in other languages. After all, if I liked C++, I would’ve just written the code in C++ to begin with! Then what you end up with is a bunch of abstractions that make the library difficult to bind to, that you can’t use anyway because they don’t fit in with the target language. For example, in Lisp you don’t want to have anything to do with QFile, because you’ve already got perfectly good Lisp files and Lisp streams. So the extra complexity of binding to QFile versus binding to open() and friends is absolutely not worth it.
To be honest, I consider the existing OO class structure more of a liability than an advantage. Mapping C++ class hierarchies into certain languages is hard. I’ve worked on doing this from C++ to Lisp/CLOS, and its very difficult to address the semantic gap.
I haven’t tried Lisp/CLOS, but I would say its object model differs more from C++ than Java, Ruby or C# do for instance. Those languages don’t have multiple inheritance, but they have either interfaces or mixins to do something similar. And the way their single inheritance works is a pretty close match for how inheritance works in C++.
Ruby doesn’t have method overloading and so you need to dynamically resolve overloaded method calls according to the types of the ruby arguments. That makes implementing the binding tricky, and it is something you don’t normally do in pure ruby code. But Ruby code using overloaded methods doesn’t end up looking ugly. I assume this is something similar to multi-method dispatch in CLOS, and you could map lisp calls onto C++ overloaded method calls in a similar manner.
On Qt’s runtime introspection:
Unfortunately, this approach is not compatible with high-performance language runtimes.
Well I’m personally more concerned with ease of use in my bindings projects (eg Ruby), and any performance loss is much of a problem as Ruby is so slow anyway. Maybe it is more problematic with C# or Java, and if high performance is a requirement for a Qt project there is no substitute for using C++ directly. Even then slots are more expensive to invoke via signals, than a straight C++ method call. There is always a trade off between flexibility and speed to be made even in C++.
There is some truth to this, but on the other hand, its often true that the abstractions that exist in C++ libraries are ugly abstractions, from the point of view of code written in other languages. After all, if I liked C++, I would’ve just written the code in C++ to begin with!
Yes, I don’t like C++ much either. But I find the abstractions you get by trying to make C do more than it was intended to do are even uglier still.
For example, in Lisp you don’t want to have anything to do with QFile, because you’ve already got perfectly good Lisp files and Lisp streams. So the extra complexity of binding to QFile versus binding to open() and friends is absolutely not worth it.
Note that QFile is a QObject and it emits signals such as ‘readyRead()’ which allow you to integrate reading from a file into the Qt event loop. You wouldn’t be able to do that with Lisp streams. But a lot of these decisions for a specific bindings language and a specific api to be wrapped come down to taste and judgement.
It doesn’t make sense to keep QStrings in the bindings language, and you would want to use the native numeric and array/list types of the bindings language too. Some types like QDate or QTime are problematic, and the best choice isn’t obvious with those.
I haven’t tried Lisp/CLOS, but I would say its object model differs more from C++ than Java, Ruby or C# do for instance.
Mapping from “classes own methods” to “generic functions are defined over a domain of types” is non-trivial, certainly.
I assume this is something similar to multi-method dispatch in CLOS, and you could map lisp calls onto C++ overloaded method calls in a similar manner.
Handling C++ overloading in Lisp is no fun. CLOS does allow a method to be defined multiple times, specialized on different types, but accounting for C++’s overloading rules, and the interactions between argument promotion and overloading is difficult. In practice, emitting a discriminator function that calls the right overloaded method is a more robust solution.
Maybe it is more problematic with C# or Java, and if high performance is a requirement for a Qt project there is no substitute for using C++ directly.
It’s not so much the performance of the binding, but the performance requirements of the language runtime. In Python, you can hook into name resolution and do a runtime query because a member access is a hash-table lookup with a key string. In Dylan or Lisp, you can’t do that, because the member resolution happens at compile-time, like in C++. So if you want to expose properties, you have to expose them as “get-property(name)” as you might in C or C++.
You’re confused. Gnome system libraries were never in danger of being written in C# or any other language for that matter.
I like KDE technically but hate them philopshically. KDE has this dendency to reinvent the wheel everytime they want to add some feature. For instance, KDE uses their own HTML (“KHTML”) rendering engine, while GNOME uses the better Mozilla “Gecko” rendering engine. They will reinvent something some complicated like an HTML rendering engine (more complicated then Qt), but hell if they will make their own widget engine. No, do not touch the holy Qt.
No disrespect to the KHTML team btw.
Edited 2007-01-11 17:31
I don’t think Gecko is the better engine. As a foreign language speaker, it has several issues rendering Unicode properly (take a look at their bug posts). KHTML is very tightly integrated with Qt rendering. I am quite disappointed with this since Pango is one of the best technologies out their for multi-linguale enablement and while Firefox can be compiled/made to use it, its layout output does not seem to properly made use of by the firefox display engine. A native Gtk based HTML rendering engine would be much better.
KHTML is very tightly integrated with Qt rendering.
Ah, well. It has been ported to Cocoa (Apple WebKit) and GTK (WebKit GTK backend by Nokia).
You call that tightly integrated with Qt rendering?
Edited 2007-01-11 18:25
khtml predates gecko and continues to provide us with features and use possibilities gecko simply can’t. this is why apple, nokia, adobe and others use it as well.
as for reinventing wheels, we just tend to get to new ground first. most times it’s other people ignoring what we’ve done and doing their own thing. personally i don’t have a big problem with that.
but your assertion really falls apart badly when you look at kde4 where we dropped dcop for dbus (improving the latter dramatically in the process, btw), dropped aRts for a wrapper over 3rd party back ends (aka Phonon), have done the same for hardware detection, ditto for voip and presence, same for spelling and grammar checking, or how we continue to move forward aggressively with ODF instead of our own office file formats, etc, etc… where we end to do our own thing is when the alternatives simply aren’t viable for our needs.
kde is actually one the most open projects when it comes to collaboration. and that’s a statement backed by code you can download today.
khtml predates gecko and continues to provide us with features and use possibilities gecko simply can’t.
like what?
khtml predates gecko and continues to provide us with features and use possibilities gecko simply can’t.
like what?
Like its light weight, small fingerprint? Like its quite small codebase for maintaining? Like its code’s cleanliness for developers? It also makes developers easy to embedded it to their own apps. Take a look at Akregator and KTorrent for example.
not to mention that khtml is much much faster, and supports various w3c things which gecko does not.
khtml is simply the best there exists today.
why do you believe that commercial distros dont put resources into kde.
i am not refuting you i beleive youre right- i m just curious as to the reason
i am not refuting you i beleive youre right
Well, this is really getting offtopic, but he isn’t.
For example Novell and Mandriva are employing several KDE constributors.
Canonical, Linspire, Xandros, etc. are sponsoring KDE events and participation of KDE contributors at other events.
why do you believe that commercial distros dont put resources into kde.
i am not refuting you i beleive youre right- i m just curious as to the reason
It’s all because of Qt. Novell, RedHat, and Sun don’t want to have Trolltech controlling everything at the core of a desktop system. They don’t want their customers held hostage to a Trolltech tax if they’re releasing stuff that isn’t GPL-compatible.
Here’s an idea.
Version 1.0 of the programming language D was recently released. Gnome should move their weight in that direction, instead of fumbling in the endless quagmire of C#.
APL? Lisp?, Smalltalk?
Gnome won’t move their weight behind any other systems language, because C is already the best at that job. The whole point of using C is so that the bindings are easy and available to the most variety of languages.
Gnome won’t move their weight behind any other systems language, because C is already the best at that job. The whole point of using C is so that the bindings are easy and available to the most variety of languages.
You don’t necessarily lose this capability when using D or Vala for that matter, since they are compatible to the C ABI. I don’t know how this looks like with D, but since Vala even creates GObject based header files, it should work very well.
D is certainly more mature, but Vala has a nice syntax (due to more or less imitating C#) and is based on GLib functionality, so it seems like a perfect match.
You don’t necessarily lose this capability when using D or Vala for that matter, since they are compatible to the C ABI. I don’t know how this looks like with D, but since Vala even creates GObject based header files, it should work very well.
D is certainly more mature, but Vala has a nice syntax (due to more or less imitating C#) and is based on GLib functionality, so it seems like a perfect match.
D or Vala (never even heard of it) are not ubiquitous platform languages. It’s pretty much pointless to say “Gnome should put their weight behind random language X” when it’s not going to happen.
The great thing about system libraries written in C is that you can go ahead and create the bindings for your random language of choice.
Here’s an idea.
Version 1.0 of the programming language D was recently released. Gnome should move their weight in that direction, instead of fumbling in the endless quagmire of C#.
Comparing apples and oranges here. Goal of D is to be functional language on its own. Goal of mono is to provide crossplatform CLR which is compatible with MS.NET.
I agree that D is better choice for Gnome, but I don’t agree that mono is not needed.
Here’s an idea.
Version 1.0 of the programming language D was recently released. Gnome should move their weight in that direction, instead of fumbling in the endless quagmire of C#.
Excellent idea!
Every single time something new pops up on the gnome front everybody turns it to a god damn discussion over witch language it should be developed on… it’s just so god damn stupid!!! Like, it’s been like this for years now!
Gnome is mainly built on C, aparenlty this is not so bad, cause the platform has been improving steadily… And it’s not like there’s not other options floating around. geez!
One of these days the gnome team develops a new interface to read the end user’s mind, Novell stocks sky rocket, and every comment anybody posts here on osnews goes something like:
“well, gnome its doomed in the long run, cause its built on c, blah blah blah”…
Just stop it, please! Lets talk about all things gnome for a change, not just the development platform.
Now that was a relief… feeling much better now… that said… screenshots, anyone?
well, it just seems everybody agrees Gnome’s foundation is it’s biggest weakness… so they argue about that. it’s not like being C will kill gnome – as long as there are some big companies willing to throw money on it, it’s ok, even tough many volunteers move away. But other Application Development environments evolve – Apple releases Objective-C 2.0, Microsoft comes with C#/dot.NET, KDE builds a next-gen platform around Qt4, while gnome doesn’t know what to do with all the java/C/C++/C# discussions.
anyway, i DO agree that talking about what’s new in gnome 2.18 would be much more interesting – it’s what i came to this topic for… but i guess it’s just not that much, like the last few releases (i’m generally not impressed by *great new stuff* which is new in gnome but i’ve been using for 3 or 4 years or more, like spellcheck in a webbrowser/mail/chat apps).
C# isn’t needed. You could write a Beagle-like thing in C++. Gnome should avoid Microsoft’s C# !
C, C++ are the only options for a good desktop.
GNOME has slowly deteriorated before our eyes and its time i speak.
When GNOME was first announced to the public i followed its progress, it was fast and
to the point!. What the hell happened ?
To install and maintain gnome nowdays we need Python(evil security wise, ram wise and speed wise).
We need liboil and gstreamer for the control-center.
HELLO World!, we have to recode this mess this way:…
Remove the few depends on python there is:
gnome-doc-utils:
The first once so mighty GNOME package to be installed.
Gnome-desktop:
Its got DND and a changeable background,
do we really need 50 microsoft people to screw in a lightbulb ? (i thought 10 was enough:)
Gdesklets are python shit too right ?
You have the mold, now fill it with gold (C/C++).
Taunt:
Why does Debian have microsoft bugreporters Simonr.. ?
Luckily people care about free software!
Claus de santae IV and Mange-Crew
On another note: Is Redhat destroying glibc for fun and pleasure:
http://mange.dynalias.org/linux/misc/broken_glibc/broken_glibc.c