faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
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 |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
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 ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
