KDE Adopting Mono

← Back to Stories (view on slashdot.org)

Posted by timothy on Thursday September 12, 2002 @01:30AM from the big-change dept.

leandrod writes "The Register reports that members of KDE are committing to use and support mono, Ximian's independent .Net implementation. Not only does this provide KDE with some of the multilingual programmability it initially forfeited by its use of Qt, it also spells well for cross-desktop application and even KDE-Gnome desktop integration, because mono is developed by Gnome's most prominent ISV, Ximian, and is intended for Gnome integration." Update: 09/12 14:22 GMT by T : Actually, the Register story overstates things a bit, it seems. According to KDE developer Hetz Ben Hamo (heunique), "Yes, you can use QT# to write QT/KDE apps, but it doesn't mean that KDE will support mono. you can use kernel 2.4, but you can use any linux kernel or any other unix based OS." See also this comment from David Faure for more insight.

12 of 257 comments (clear)

Min score:

Reason:

Sort:

So what about Microsoft's IP? by DamienMcKenna · 2002-09-12 01:34 · Score: 2, Insightful

What will happen when in a few years Microsoft discloses its licensing terms for .NET technologies, forcing the Mono team to either stop or pay vast sums of money - this will kill the two main Linux desktop environments, thus throttling most of Linux's desktop ambitions.
hope mono gets it right... by TechnoVooDooDaddy · 2002-09-12 01:39 · Score: 5, Insightful

otherwise KDE is going to suffer the same crippling crush of bloat that Windows is getting from .NET

I wrote a small maintenence application, and compiled it targeting non-.NET Win32, the file was 19 meg.. ok, yeah, it's probably got the runtime in there... a similar java runtime is 7 or 8 meg.
KDE is also going to suffer from a similar rash of programmers like windows VB programmers who thing that dragging and dropping an application together makes them every bit as valuable as someone who can lovingly craft inline assembler into their C routines for speed and keep an eye on memory utilization. The dot.bomb shakeup was good for scaring those VB types out of the industry for a bit, but MS is still trying to sway focus over to "productivity" over stability or longevity.
Yeah i know i'm ranting, but i've got mana to burn.
1. Re:hope mono gets it right... by Mr_Silver · 2002-09-12 01:57 · Score: 5, Insightful
  
  KDE is also going to suffer from a similar rash of programmers like windows VB programmers who thing that dragging and dropping an application together makes them every bit as valuable as someone who can lovingly craft inline assembler into their C routines for speed and keep an eye on memory utilization.
  If a VB programmer has "dragged and dropped" an application together that I need and I can afford, then I fail to see what makes them any less valuable than the C and inline assembler programmers who haven't done such a thing.
  There are plenty of good and useful VB applications out there, same as there are plenty of crap and bloated C and inline assembler applications out there.
  Rather than mainly scoring applications based on the language they were written in, you should give priority to the task they perform. Personally (as a user) I don't give a toss what language something is written in, if it works and does the job.
  
  --
  Avantslash - View Slashdot cleanly on your mobile phone.
2. Re:hope mono gets it right... by XaXXon · 2002-09-12 01:59 · Score: 5, Insightful
  
  KDE is also going to suffer from a similar rash of programmers like windows VB programmers who thing that dragging and dropping an application together makes them every bit as valuable as someone who can lovingly craft inline assembler into their C routines for speed and keep an eye on memory utilization.
  
  Personally, I don't care how a program is written. And I know very few people are going to complain about having more apps for Linux. Many applications have absolutely no need to be written in highly optimized C. This can cause more errors, and more time spent trying to optimize for an extra 20% boost and leaves less time for adding new features. Personally, I'll take the one that takes 20% longer to run with 80% more features..
  
  The dot.bomb shakeup was good for scaring those VB types out of the industry for a bit, but MS is still trying to sway focus over to "productivity" over stability or longevity.
  
  If you had been paying attention, the "dot.bomb shakeup", as you call it, had very little to do with technology and far more to do with business models. It didn't matter what programming language you used to set up your online dog-food website, it wasn't going to make it. These companies were doomed from the start, and did not go out of business because they hired VB programmers instead of K&R C programmers.
3. Re:hope mono gets it right... by Wiseazz · 2002-09-12 02:16 · Score: 2, Insightful
  
  If you had been paying attention, the "dot.bomb shakeup", as you call it, had very little to do with technology and far more to do with business models
  
  I don't agree with the original post, but I think you've misunderstood his point regarding the "dot.bomb" thing. The tech down-turn did force a lot of fat-trimming, and this was a Good Thing. There were way too many IT folks out there that just didn't know what they were doing.
  
  The original post was mostly pointless, IMO, so maybe it doesn't matter that it's interpreted correctly.
  
  --
  My sig sucks.
4. Re:hope mono gets it right... by samael · 2002-09-12 04:39 · Score: 3, Insightful
  
  This is what programmers due, pay attention to memory management, pointers, etc.
  
  Nope, what programmers do is take input and convert it to the desired output. If they can do so in VB and produce something that fulfills the requirements in half the time they could do it in C++ then they should use VB to do so.
  
  --
  My Journal
5. Re:hope mono gets it right... by IIRCAFAIKIANAL · 2002-09-12 04:56 · Score: 3, Insightful
  
  YOu pulled the words out of my mouth.
  
  There are two parts of my job - analysis and programming. If I can code faster in VB, Delphi, java, whatever, then I will ( of course, we have to consider company language/platform standards too, but anyway).
  
  If I have a production environment w/ 1 ghz intel boxes with 256 megs of ram and I am writing software to display reports, I don't give a shit if I save 2 megs of memory by managing it myself. I want to get that app out as quickly and with as few bugs as possible.
  
  I am quite capable of paying attention to memory management and other low level stuff (having learned asm before I learned VB) - I just don't see why I should bother.
  
  --
  Robots are everywhere, and they eat old people's medicine for fuel.
Re:A small error by cozziewozzie · 2002-09-12 01:59 · Score: 2, Insightful

This is exactly what you're looking for.
Re:WRONG by manyoso · 2002-09-12 02:00 · Score: 5, Insightful

You are right. I tried to correct some of Gavin's statements such as: 'Qt is a language'

LOL, but I was in the middle of dinner when he called and he didn't have time to wait...

KDE is not 'switching' to Mono nor has KDE 'adopted' Mono, but some developers are attempting to include support for Mono in KDE. That's it. It is a another choice for the developer and IMHO a very _cool_ choice :-)

Cheers,

Adam
Very cool - but I want more by avdi · 2002-09-12 02:02 · Score: 3, Insightful

This is an *excellent* sign, both of the ever-closer relationships of the GNOME and KDE people, and of good times ahead for coders. .NET/Mono is a great step forward for hackers like me who want to be able pick the right language for the job, rather than being forced to choose the language that happens to have the needed libraries.

On the other hand, it looks like the GNOME and KDE teams are poised on duplicating the same rift that currently exists between free GUI toolkits. Rather than standardize on either Windows Forms or a similar alternative API, both projects are porting their own toolkit APIs to C#, in the form of Gtk# and Qt#. Which means that developers will *still* have to commit to one toolkit or the other for a given project, because the APIs are totally different.

The opportunity GNOME and KDE have with this agreement is huge: write a unified GUI API equivalent to Windows Forms, with both Gtk and Qt backends. Let developers write to the single API, and let end users view the results rendered by whichever toolkit they prefer. Yes, it would be a lot of work. Yes, it would involve a lot of impedence matching. Yes, for some applications it would still be necessary to use the underlying toolkit for effects which have no equivalent on the other toolkit. But the gains in Open Source productivity would be huge - a prime source of unnecessary duplication of effort, the idea that every good application has to be written twice, once for KDE and once for GNOME, would finally be eliminated.

Take the opportunity guys - the community will be thanking you for years.

--

--
CPAN rules. - Guido van Rossum
Re:WRONG by JayateMo · 2002-09-12 02:13 · Score: 2, Insightful

If members of KDE denies this, could we *please* have an update on
the "Frontpage" i.e the actual newspost?? One cant expect people reading every comment to find out.
Re:WRONG by dfaure · 2002-09-12 02:30 · Score: 4, Insightful

Ah, so the interview was done over the phone and you had no way to check the printed version before it went online? That's very bad IMHO, they should check with the person interviewed first. That's how misunderstandings happen - such as this one.

The article was already very misleading IMHO, the slashdot headline even more so. I think many more statements should have been corrected in that article...

Well, thanks for the work on the language bindings, keep it up.
David Faure.