Checking out the Competition

Since I am somewhat new to C# and .net I decided to follow up on a
thread I had read on Joel On Software about the new Microsoft Visual
Studio Express
line which is targeted at enthusiasts and hobbyists. So I went, and
sure enough, Visual C# Express Beta was a free download, and only 50mb.
Note that they require that you give them a valid email address, and
also, from what I've read, the evaulation expires next year.

I find it interesting that Microsoft is releasing their tools like this.
They probably feel forced to
because they don't want to lose the hobbyist market completely to
Open Source offerings. If people want to learn how to program,
Microsoft has to do something to get them to try their tools, and this
is what they are doing. I remember when I was first starting out
programming and QBasic came free with DOS. Then if you wanted to
compile executables and have more IDE features, you had to buy QuickBasic,
which I ended up doing.

Luckily I had just enough harddrive space free in my Windows partition
for the Visual C# install. I must say that I was impressed by the
simplicity and clarity of the setup. It even had a little check box at
the very end saying
that you could send your usage data to Microsoft to help improve the
setup process (even though the setup process was already only a few
clicks). Clicking on the details of that message opened a
text file showing the click patterns through the various screens of the
setup wizard, and generic info like the free space on the hard drive and
the fact that the install was successful.

I think such functionality would be great for KDE. We could have the
apps completely control what got logged using a mechanism similar to
kDebug. For example:

kUsability << "Button 1 clicked!!" << endl;

would log the "Button 1 clicked!!" message to a log file along with the
time and the date (somewhat important for determining how long users
are staring at the screen with a confused look on their face). Then
something could trigger popping up a dialog to ask the user to send this
anonymous data to KDE to help us with our usability. Sending the data
could be accomplished via email as I believe we do for bug reports today.
Does any KDE app do anything like this?

The Visual C# IDE overall is very polished. I felt that the only Beta
quality part of it was some missing help files. With the form editor it
is very easy to create form layouts, including menu bars, tool bars, and
status bars. And just double clicking a button takes you to the code
that will run when the button is clicked. There was an example hello
world type console program as well as a simple windows forms application
with just one button. There is also a larger example program which is a
screensaver that downloads an RSS fead and displays headlines.

As someone who is relatively new to the C# programming language, it is nice
to see what looks to be a simple and powerful language, as opposed to the
C++ that I am used to. C# is type safe. It's not too complicated. It has
easy to use pass by value and pass by reference. Everything is in one or
more classes like in Java. It has namespaces. It has easy to use exceptions.
It has a built in string type. It has a foreach statement. It has object
properties and you can control the accessor methods and don't have to write a
lot of code for them. And by virtue of running in the .net environment it has
automatic memory management and can interoperate with code written in
other languages. I used to not understand what they meant when they used the
phrase "managed code." (They do use that phrase a lot.) But now it makes
sense that the environment "manages" the memory, specifically the
de-allocation. All of these things combine to make C# useful programming
language. I know this may sound like a stupid Microsoft commercial, but it
really isn't. Let's hope that C# on Mono with MonoDevelop can bring these
same qualities to Linux development.


I'm hoping to get C# support in KDevelop. We have Java support now and, although it doesn't compare to Eclipse offering, it is pretty darn good. If some enterprising KDevelop dev had an itch to write a new language plugin, I'd happily suggest C# ;) Otherwise, I hope to write one myself when I have Binge generating a KParts C# binding.

By Adam Treat at Fri, 07/02/2004 - 02:44

Yes, support for C# (or more specifically, language support for CLR implementations) is certainly interesting. C# does look good, but support for CLR applications will not be complete until there is the implementation of a RAD language like VB.Net. Things should really take off then.

In terms of business use, .Net is something that we are looking at but it is going to be several years before we do anything. We have way too much VB/COM lying around, and all of it are things we depend on day-to-day. We currently have no desire to re-write all of that, and no desire to have to iron out all of the problems we had when we rolled out or VB applications several years ago. That is a problem Microsoft is finding, and is an opportunity for everyone else. If people have to re-write their applications, why not target other platforms?

KDevelop could be well on its way to being quite a nice integrative IDE, with many good options. The only thing it doesn't really have is an integrated form and GUI designer as SharpDevelop has, and as MonoDevelop will have. Yes I know there is Qt Designer and KDevelop Designer, but you need it there in one place.

Developing KDE/Qt applications with a CLR environment, and a language like C#, it would be interesting to compare the experience to C++/Qt. Qt and C++ is good at what it is designed for - a fairly low-level, object-oriented language and toolkit that is designed to be natively compiled and to run fast natively. I, personally, think KDE has advanced tremendously based on that philosophy. If something is logically object-oriented in structure then use tools suited to the task, rather than providing bindings that no one will use.

Certainly, C# and a CLR environment would be extremely good to write GPL'd KDE desktop applications with and would make development a whole lot easier. However, having a whole desktop environment run through a CLR just isn't going to be on the cards.

On the other hand, what I would like to see is development tools and toolkits of different kinds being able to take advantage of KDE infrastructure without having to use Qt, or pay a license for Qt for using other licenses. This isn't a licensing troll at all, because if KDE is going to be an integrative desktop then it will have to cater for other development methods and licenses and do it without inconveniencing anyone. This would include Java, the CPL and other methods and toolkits, and binding everything to Qt isn't an option there. QtGTK is a step in the right direction. People will (and they will) pay for Qt because they want to, not because they have to.

If KDE can do that, and not confuse people regarding licensing should its popularity grow(!), then it will be onto a long-term winner as a really nice development platform.

By segedunum at Sat, 07/03/2004 - 13:17

We did discuss this idea of automatically logging and sending usability data a while ago. Aaron was trying to coordinate a by-hand collection of data for people's use of the navigation buttons in Konqueror, and the idea was discussed but it obviously never got very far.

Personally I think it'd be an excellent idea to have the facility coded into something like kdebug or the main application class, and to have a server set-up to automatically receive and process the data. It'd be a big job, but it would provide invaluable, scientific data on how people use KDE to finally end the pointless debates about whether or not people use feature X in a particular way, if at all.

By Tom Chance at Sat, 07/03/2004 - 09:06

I'm hoping against hope that C# will somehow in a meaningful and timely manner work its way into KDE.

The C++ nature of Qt and of course KDE which in the past have proved to be such an advantage in the speed and quality of development now pose significant technical challenges in implementing modern popular languages as at least 2nd class citizens. SMOKE bindings and similar C proxy libraries are maybe good for proof-of-concept, but are not acceptable long-term solutions.

I've read all of Adam's well thought insights on the subject, but until the dream of intermediate byte code generation either through gcc or llvm become a reality, i think possibly the next best thing is a managed extensions for C++ frontend to gcc. Aside from providing the ability to wrap unmanaged C++ classes, C++ interop carries significatly less overhead than PInvoke. But alas, this is also a long shot since there is no work going on with that that i know of, and mono doesn't currently support mixed mode assemblies anyway.

What other options are there? Switch to GNOME? I've tried to love GNOME, i really have...but it's not happening. This so-called "clean" look that others seem to like looks like garbage to me. I'll maintain my composure and not say what i really think about GNOME's complete and utter lack of form and functionality, since that's not what this post is about.

TT tends to be pretty tight-lipped about any future strategies, so i'll just hope it is impressed upon TT and the KDE community at large that tight linux/.Net integration is a very very good thing.

By rh at Sat, 03/11/2006 - 23:37