The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Mono
by Robert Knight on Saturday 16/Feb/2008, @19:39
|
> but that's okay as long as you won't start rewriting core desktop modules in C#
Unless I am much mistaken, gnome developers are not doing that and have not announced plans to do so. The only change that I am aware of is the decision to permit applications, which happen to be written in Mono (Tomboy, F-Spot) to be included in the default gnome desktop. Personally I like both applications and having read through some of the code for them I understand the decision to use the C# language. It really is considerably less painful than the combination of plain C and gtk. Contrary to popular misconceptions, Tomboy at least does not appear to use all that much of the .NET framework outside of the runtime and core IO/container classes. The GUI for example is created through C# bindings for GTK.
As far as KDE is concerned, the availability of free software implementations of high level languages gives developers an opportunity to write and publish innovative applications more quickly and with fewer technical pitfalls than they could with C++. Java / Qt Jambi might be the better choice at present since it is supported by Trolltech, although I'm sure Richard has a better informed answer to that. One key thing to note is that there is a completely open and free implementation of C# and enough of .NET. I'm not sure the same can be said of Java at the present moment in time.
|
[
Reply To This | View ]
|
Re: Mono
by Erik on Sunday 17/Feb/2008, @02:13
|
I personally don't know why people don't stop blaming Mono/C#/.NET. Is it because of the original inventor?
GET REAL PEOPLE: C# is ISO certified and patent free, the CIL is ISO certified and patent free, and so Qt, KDE and those bindings are!
There are technical and practical issues where a combination of C# and its framework or Java are superior to C++, more than ever when you forced to not use Qt. Just to mention one: Did one of you blamers ever use (N)Hibernate? I don't know another so flexible object-persistent database framework.
Regards
Erik
|
[
Reply To This | View ]
|
Re: Mono
by edomaur on Sunday 17/Feb/2008, @03:02
|
Well, there is Hibernate :) (and SQLAlchemy...)
just joking.
I like C# more than Java, but its main problem as I see it is that it is currently even less cross platform than Java. After that, well, that's matter of personal taste. Only that.
|
[
Reply To This | View ]
|
Re: Mono
by Ian Monroe on Sunday 17/Feb/2008, @09:30
|
We're not forced to not use Qt, which is why C# doesn't have as much to offer us as it does Glib/C programmers.
|
[
Reply To This | View ]
|
Re: Mono
by Leo S on Sunday 17/Feb/2008, @10:36
|
That's exactly it. I really don't see a lot of point in using C# or Java over C++ when you're using Qt. Sure C#/Java benefit from some nicer syntax and better code completion/refactoring support in IDEs, but aside from that I don't see much difference.
The Qt API is better than the class libraries of those languages, and I barely have to do any memory management at all with Qt, so the garbage collector really doesn't improve things for me. Cross platform is pretty much a wash as well. C++ requires recompilation, while Java/C# need a runtime installed. Security is contentious, but I haven't seen any convincing evidence yet on that front.
I can see that if you're using C/GTK you'd jump at the chance, because C# or Java would be far easier to use, but for C++/Qt I really don't see the argument. The next step easier is a scripting language.
|
[
Reply To This | View ]
|
Re: Mono
by Richard Dale on Sunday 17/Feb/2008, @11:11
|
Yes, I pretty much agree with you here, and you are quite correct when you say "next step easier is a scripting language", such as Python or Ruby. What is the value added by using QtJambi or Qyoto instead of the C++ api?
However, from my point of view, getting C# bindings working with Qt/KDE is a very interesting technical challenge. Currently Arno Rehn is doing great stuff with that. He is making the Smoke library that is used by the Ruby/C# and PHP bindings more modular. That will make it much easier to create Smoke libraries to cover various KDE plugin apis such as Plasma or Akonadi.
The Qyoto/Qt C# api is quite a bit different from the QtJambi one, although C# and Java are quite closely related. Slot/signals are done quite differently in Qyoto compared with QtJambi, and in Qyoto Qt properties are mapped directly onto C# ones. So if you are a Free Software hacker, the differences are larger than they first appear.
The is only a GPL version of Qyoto available, whereas QtJambi is dual licensed - the target market is very different.
Qyoto/Kimono should be able to cover important KDE apis be KDE 4.1, but there is no work being done on a KDE version of QtJambi as far as I know.
|
[
Reply To This | View ]
|
Re: Mono
by Erik on Sunday 17/Feb/2008, @14:53
|
It's not the point whether you are forced to use Qt, C++, C# or whatever. My point is: Qt/KDE C# bindings offer you a choice. A choice free to be taken, even to develop core modules with it. Why not develop core modules with Jambi?
Regards,
Erik
|
[
Reply To This | View ]
|
Re: Mono
by kwilliam on Sunday 17/Feb/2008, @17:32
|
I'm not sure what a "core module" is, but I know that when I installed Kubuntu, neither Java nor Mono needed to be installed by default. Obviously, depedencies aren't a big deal on laptops and desktops, but when I get around to buying something like an Open Moko and install KDE on it, I'd rather not have Mono and Java taking up space. Also, in my experience (as a user) Java apps tend to be slower.
I think it's awesome that people can write software in Java, C#, Python, or Ruby and tap into kdelibs and Qt goodness! Ideally ANY language could be used to write an app that integrates with the KDE. But preferably, the default install of KDE should not be dependent on all those other languages. (Qt's native implementation is in C++, so naturally KDE has to include support for C++.)
|
[
Reply To This | View ]
|
Re: Mono
by Riddle on Sunday 17/Feb/2008, @18:28
|
It's the extra dependency, slowdown, and lack of real advantage. In GNOME, I can understand why using those languages would make sense (the syntax), but for KDE (better syntax), there is no advantage. It also slows it down, and adds another dependency (the runtime.) I don't mind making bindings to those languages (for example, lets say your a company making a cross-platform app and you only want to compile once), but the core modules should not need it.
|
[
Reply To This | View ]
|
|
Re: Mono
by yxxcvsdfbnfgnds on Monday 18/Feb/2008, @03:33
|
According to http://www.ohloh.net/projects/272/analyses/latest 2% of the KDE code base are already C# but I have to admit that I have absolutely no idea how accurate that number is.
|
[
Reply To This | View ]
|
Re: Mono
by Riddle on Monday 18/Feb/2008, @19:00
|
Those measurements include non-official parts as well. I've compiled the 3 base packages kdelibs, kdepimlibs, kdebase. I've never seen it compile any C#.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
