Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
KDE GUI

KDE Adopting Mono 266

Posted by timothy 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.
This discussion has been archived. No new comments can be posted.

KDE Adopting Mono More

KDE Adopting Mono

Comments Filter:
  • 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.
    • The project will be move outside the US.... to somewhere where the IP cannot be inforced...{He dreams}
    • I believe MONO just uses the CLR standard that is given to the ECMA. The rest is just reverse engineering of the class libraries which i believe is still legal. Heck microsoft benefited from reverse engineering..
      this just my guess..

      alex
      • Actually the mono team is incredibly careful to adhere to all legal responsibilites. Their code and documentation contributing pages both detail how all interaction with the M$ implementations is to be avoided.

        The mono team is developing strictly independently of what Microsoft owns, projects such as the SSCLI/rotor and the MSDN documentations are only to be used very loosely as guides. Most contributions are based on the ecma standards.

        My point is, mono should have no fear of Microsoft intellectual property / proprietariness.

        • Actually the mono team is incredibly careful to adhere to all legal responsibilites.

          Actually, quite incredibly, they are not.

          1 POLICY
          General Declaration:
          The General Assembly of ECMA shall not approve recommendations of Standards which are covered by patents when such patents will not be licensed by their owners on a reasonable and non-discriminatory basis.

          1.1 In case the proposed Standard is covered by issued patents of ECMA members only: Members of the General Assembly are asked to state the Company licensing policy with respect to these patents.

          1.2 In case the proposed Standard is covered by issued patents by non ECMA members: A written statement from the patentee is required, according to which he is prepared to grant licences on a reasonable, non-discriminatory basis. The General Assembly and/or the Management shall decide in this case which steps must be undertaken in order to obtain such a statement.

          Now Microsoft has clearly stated that they own IP to parts of .NET and to the parts standardized by the ECMA specification. However, when asked for the license terms for this IP (as required by ECMA), there has been no answer. As stated by one of MS employees [google.com], "they're working on it".

          This puts Ximian and Mono or anyone implementing these ECMA specifications under a real legal threat.

        • I am not an IP expert, but i have seen the mono sources and the mailing lists, and they surelly ARE CONSTANTLY looking at the MS implementation, up to the degree of Miguel commenting in the changelog things like "change method X to assume enconding UTF-8, as this is what the MS implementation does". It may be legal, but there are so much comments like that that it's probably a reality one will infringe.
      • I believe MONO just uses the CLR standard that is given to the ECMA. The rest is just reverse engineering of the class libraries which i believe is still legal.

        And we all know there will never be a critical piece of code or algorithm that microsoft will patent once this gets traction. Why even dance with the devil?
    • Eeh.. that could only happen due to patents.

      The rest of Mono is not in any way Microsofts IP. It is just an implementation of specs Microsoft has opened up and sent to ECMA for standardization.

      Mono is about as much Microsofts IP as Wine, that is not at all. Mono shouldn't and probably hasn't even had to turn to reverse-engineering like Wine.

      Second. Neither GNOME or KDE have any plans at all to incorporate Mono into the core of the desktop. It will just be (a very nice) development platform for the two desktop environments. This means that some of the KDE and GNOME -applications might be based on Mono.

      As I said, the only concievable problem would be that Microsoft has patented some of the design, and enforces it. This would again only mean that Mono has to be changed to work around the said patent.
  • This is great news,
    Linux is hampered by the lack of a well adopted COM(ish) model.

    Now I can start wrapping my OOS up in a framework that I know will be usefull for everyone, and no more writing PHP modules, just instance through a generic mono wrapper. etc......

    • I don't see anything really new about this story. It is simply mentioning Adam Treat's Qt# [sourceforge.net] bindings and work on Mono integration. The Dot [kde.org] reported on this over a month ago.

      The story makes the bombastic claim that KDE is switching to Mono as the underlying technology, and shows no proof to that extent. What is happening is that KDE guys are simply adding C#/Mono to the list of bindings Qt/KDE supports. Don't get too excited just yet.

  • KDE-Gnome desktop integration (Score:3, Offtopic)

    by wiredog ( 43288 ) on Thursday September 12, 2002 @09:36AM (#4244116) Journal
    I run Gnome desktop, but use kmail and other kde apps. I can even cut and paste between them. Seems to me the integration is already, to a large extent, there.

  • Is it possible to make web applications with Mono that are served with Apache or something? And are their any GTK-C# bindings out yet?

    Also, is anyone actually using Mono for any projects atm, or is it just a case of 'work in development' which will never be widely used anyway?

    • Phonic [atoker.com] is a cross-platform Vorbis player written for the GNOME desktop in C#. It was developed with and runs completely within the Mono .NET runtime environment. There was a Slashdot article [slashdot.org] mentioning it a few months back.
    • http://haydn.sf.net is your embedding into apache.

      You can already embed ASP.NET in there (or if you werea the O'Reilly conference, you could have seen ASP.NET embedded into Gnumeric).

      Mono self-sustains, so that means that we can compile it with itself (the compiler and class libraries are written in C#). So you could say that for compiler work it is already usable ;-)))

      Other than that, it depends on the particular class libraries that you are looking for.

  • i am all for anythign that gives linux better apeal to the mainstream. hopefully this doesn't backfire.
    • i am all for anythign that gives linux better apeal to the mainstream.

      Exactly how would a KDE adoption of .NET [ignoring the fact that it ain't true] appeal to the mainstream? Will Ma and Pa Kettle suddenly leap for joy, dump Win/Mac and install *Nix/KDE?

  • Great (Score:3, Funny)

    by doc_traig ( 453913 ) on Thursday September 12, 2002 @09:37AM (#4244126) Homepage Journal

    Once KDE has mono (and it will for months), it will become sluggish, weak, and completely addicted to bad daytime television. I advise staying away for a while, and don't share any of its apps.

    - DDT
  • The great power of Open Source is choice. For any given itch, there are a multitude of different scratches on Sourceforge in various stages of feature implementation. It has always been possible to download 2 or 3 of these that, together, are adequate to solve nearly any problem. That's why I've always been a supporter of of so-called "splinter" projects from forked source bases.

    But now the two great camps of UI development, KDE and Gnome have conspired together to merge their underlying implementations. This is a terrible thing because it reduces choice in the community. Furthermore, Mono is a reimplementation of .Net which makes Linux look like an also-ran.

    I think KDE and Gnome should go in totally different, incompatible directions. That's the only way to maintain Linux solidarity.

    • > KDE and Gnome have conspired together to merge their underlying implementations

      Don't worry, they haven't.
      Don't believe everything you read.

      When, oh when will journalists *check* for facts first?
    • Um, how is incompatability going to make things better? While we're at it, let's make RedHat and Debian apps incompatible. One of the great things about linux is that from distro to distro, box to box, things are compatible. I don't run many KDE apps under Gnome now, but I'd be pretty annoyed if they broke the compatability that's there now.
    • I think KDE and Gnome shoudl go in totally different, incompatible directions.

      Bullshit.

      Different != incompatible.

      There's nothing wrong with the two interoperating. The entire point of the two is that there are two different schools of UI going on, and that gives people choice. Reimplementing, say, antialiasing is just plain stupid.

      For example, pango, the rendering library that gtk2/gnome2 relies on, has its sample app written in KDE. Now Ximian writes a .NET implementation that KDE is using. Sharing foundation code is good -- it means that stuff gets moving faster, gets better dested, and gets better performance. You can expose the functionality through different APIs if you want, but ignoring good code for ideological reasons is just stupid.

      Hmm...ignoring good code for ideological reasons is just stupid. This says something about Stallman. :-)

  • hope mono gets it right... (Score:5, Insightful)

    by TechnoVooDooDaddy ( 470187 ) on Thursday September 12, 2002 @09:39AM (#4244143) Homepage
    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.

    • Re:hope mono gets it right... (Score:5, Insightful)

      by Mr_Silver ( 213637 ) on Thursday September 12, 2002 @09:57AM (#4244257)
      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.

      • At my company, we do business apps in VB (with the occasional com object in C++) and engineering apps/realtime apps in C++. I imagine this is how it works at most companies.

        Believe me, there are many excellent VB coders out there. I'm personally in the business apps area, but I find that language is secondary. What really matters is being able to design your app properly (ie/ business layer, data layer, presentation layer), follow standards (for VB, SQL, and external docs), and document it well.

        It's not that C++ is necessarily more difficult (for me or a good number of the coders here), it's that coding an app in C++ means I have to actually pay attention to memory management, pointers, etc. That's great if the users care about speed and keeping the app slim, but pointless if they want an app yesterday. I could do two vb apps for every one C++ app. There are many problems with VB, but VB.NET (a much more true oop language) addresses many of them.

        Personally, the fact that mono is hitting Linux is a good thing - you may find more Windows programmers porting apps to Linux. Why would *anyone* complain about that? (Jokes about coding skills of Win32 programmers aside)
        • "It's not that C++ is necessarily more difficult (for me or a good number of the coders here), it's that coding an app in C++ means I have to actually pay attention to memory management, pointers, etc."

          This is what programmers due, pay attention to memory management, pointers, etc. If they want an app yesterday they'll have to learn that it doesn't work that way. Any well written app takes time and VB is like the McDonalds of programming languages. It's good, quick, fast, everything taste the same and it's not good for you.

          • 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.
            • 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.
      • * the Someone Who Gets It alarm goes off *

        * black helicopter lands next to Mr_Silver, thug in black suit and sunglasses gets out *

        "Excuse me, sir, we're gonna have to ask you to leave the premises. Can't have people like you on Slashdot."

        * thug pulls out bat and grins *

    • Re:hope mono gets it right... (Score:5, Insightful)

      by XaXXon ( 202882 ) <xaxxon.gmail@com> on Thursday September 12, 2002 @09:59AM (#4244266) Homepage
      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.
      • 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.

    • Re:hope mono gets it right... (Score:4, Informative)

      by Anonymous Coward on Thursday September 12, 2002 @10:13AM (#4244371)
      As somebody who works on large products for large firms, let me assure you that I truley appreciate programmers who can and do "lovingly craft inline assembler into their C routines for speed and keep an eye on memory utilization."

      However, there is a time and a place for that and most projects are not the time for that. I hate to crush you, but I find myself more and more hiring the type of programmer you are putting down. You know, the Business School MIS guys, instead of the Computer Science guys.

      They may not be able to "lovingly craft inline assembler into their C routines for speed and keep an eye on memory utilization", but they can understand the goals, delivering a complete system that does X, is delivered by Y, and comforms to specification Z, so maintainence isn't such a nightmare. They also tend to be more willing to fully document their work, why won't so many geeks do this? Really, I want to know!

      I recently had a major run in with one of my most talented code monkeys who had spent the last couple weeks branching his section of code off into a "more efficient design". He did save me 10% on my footprint, but he broke specs in doing so, which I am contractually obligated to not do. My MIS employees get that for the most part, they apparently understand things like business plans and liability. Oh yeah, the database guys would have to break specs and rework a couple weeks worth of work to implement his "more efficient design."

      Now the project is most likely going to be a week or so late. The money our client will lose during that week would be enough to buy 20-30% more memory. So the more efficient design is actually a net loss for my client, as well as my firm, since the cost of revision is much more than the cost of upgrading the hardware. He doesn't get that, he thinks it is a sin to code like I want him to. He needs business training.

      On the other hand, I do sometimes want to pull out my hair with the stupidity of some of my MIS guys, I sometimes wonder if some had ever even got beyond drawing forms in VB. But, I can teach them those skills much more easily than I can teach business skills to geeks with no interest in it.

      My best employees usually fall into two categories:

      1. CS guys who are interested in business, those who are geeks at heart, but hope to open their own shop some day, they will actually look at the BIG picture, not their little slice of the pie.

      2. MIS guys who really do like tech, they are business folks at heart, but they really do love technology and have learned on their own many of the skills the Business schools didn't teach them.

      PS- You are on crack if you think coding close to the metal is inherintly more stable and long lasting. Documentation and the ability to follow specs is key to creating systems that will work well immediately and in the future.
      • I totally and utterly 100% agree. If you want to write to the metal, and really give your l33t optimisation skills a work out, then writing business software is the wrong place to do it.

        If you're that shit-hot you should have no problems writing real-time embedded systems, or video games.
    • I'm surprised that your post was modded as "insightful" rather than "troll."

      "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."

      Excuse me but I program in VB and C and C++ and Kylix and Assembler and...

      VB programmers are as valuable as assembler coders. It's called the right tool for the job.

      Sure I could sit down and write an application in pure assembler. It would be extremely tight, fast and difficult to maintain. It would also take a very long time to code.

      In the real world most of the time programmers are required to get a product out the door very quickly. This is where RAD tools come in handy. VB, Kylix, Visual C++, C++ Builder etc are extremely valuable as are the people who know how to use them.

  • irony (Score:4, Funny)

    by sprytel ( 242051 ) on Thursday September 12, 2002 @09:44AM (#4244167)
    anyone else find it ironic that its microsoft technology that may finally enable integration between kde & gnome?

    that bill gates... he's all about love, unity, and linux... ;-)

  • The use of Qt has not been a problem in allowing the use of various languages to program for KDE. There are bindings for Python, Java, Objc-C, C, Perl, and interaction over XMLRPC and via command line tools for shell scripts. C# is just another one of the languages which can now program with the libraries, and presumably, so are any other Mono supported systems.

    Interested readers may wish to checkout the KDEBindings package in CVS, which is part of the KDE desktop officially since 3.0. Web CVS [kde.org]

  • WRONG (Score:5, Informative)

    by dfaure ( 115987 ) on Thursday September 12, 2002 @09:47AM (#4244185) Homepage
    What a load of mis-information....

    The Qt-C# / KDE-C# developer might be proud of his language bindings (undoubtly it's cool that those exist), but that's no reason to spread such wrong rumours. (I'm not accusing him, it could very well be the journalist from TheRegister who's making most of this up).

    There is NO decision from the KDE project to do ANYTHING with C#, .NET or Mono at this point.

    It's amazing how much bullshit people can invent.

    David, KDE/KOffice developer.

    • Re:WRONG (Score:5, Insightful)

      by manyoso ( 260664 ) on Thursday September 12, 2002 @10:00AM (#4244272) Homepage
      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

      • Re:WRONG (Score:4, Insightful)

        by dfaure ( 115987 ) on Thursday September 12, 2002 @10:30AM (#4244479) Homepage
        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.

        • Re:WRONG (Score:5, Informative)

          by manyoso ( 260664 ) on Thursday September 12, 2002 @10:41AM (#4244568) Homepage
          Well Gavin emailed Joseph and Andreas first. Then he emailed me and that's where he got the quotes. I pointed him to Miguel for questions about Mono. I think he mistated Miguel a few times too (read: Mono has 15,000 libraries) LOL

          Then he gave me a call last night and we talked. I explained a few things. Later that night he sent me the draft and called. He explained that he had 15 minutes for me to correct anything. I emailed him some suggestions later that night, but he apparently didn't get them in time.

          Oh well, the point of the article is that we are in the process of adding some cool bindings to KDE not just the Qt# ones, but also some DCOP as well as Joseph attempting to extend Kate to allow plugins written in Qt#.

          I stand by the quotes though. I think a Mono binding is good for KDE, because it allows multi-language support through one binding. To put another way, it adds C# _plus_ MonoBasic and all the other languages Mono and DotGNU support.

          It also holds the promise of more apps for KDE if some windows developers are intrigued. I think that's a winning combination :-)

          Adam

    • Re:WRONG (Score:2, Insightful)

      by JayateMo ( 607023 )
      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.
    • Actually I invented nothing, only pointed to The Register's story.

      • Re:WRONG (Score:3, Interesting)

        by dfaure ( 115987 )
        1) IMHO it's the responsibility of a journalist to check for facts before "forwarding" a story. The lack of doing so is how so many wrong stories appear everywhere. It's just too easy: as soon as one person says nonsense somewhere, all "news" sites pick it up... That's not journalism, that's "spreading rumours".

        It's especially frustrating for those who "know the truth", to see that we don't even have time to get the initial website corrected, all the other news sites make news out of it immediately.

        2) The article on theRegister does not say "KDE is adopting mono" like the /. headline said. It felt like this was being said behind the lines, the the headline on /. is really amplifying this wrong 'fact'.
    • I love GNOME, and really dislike KDE.

      That being said, this article summary was awfully slanted toward GNOME. Let's take a look at a couple of snippits: ...committing to use and support mono, Ximian's...

      some of the multilingual programmability it initially forfeited by its use of Qt

    • Let me see... it is now possible, or will soon be, to code KDE apps in mono. How is this not adopting? So you have not adopted C++ too, just because it is not mandatory? After all, one can code KDE apps in Assembler too, I guess!

      Note my comments did not say that KDE was switching to mono, but that members of KDE were committing to use and support mono. As far as I know this is pretty much what every KDE developer in this thread is asserting, that some of them are gonna use it.

      I wonder at how any hint at collaboration or change arouses such a flame war among developers -- and more so among KDE, BSD and the like folks. Usually I find the FSF folks to be more balanced. I wonder if that is because people who have rejected more sound, farsighted strategies know to have painted themselves in a corner?

  • KDE adopting Mono ? (Score:3, Insightful)

    by Seli ( 51600 ) on Thursday September 12, 2002 @09:55AM (#4244239)
    Just to make some facts clear:

    > The Register reports that members of KDE are committing to use and support mono, Ximian's independent .Net implementation.

    Relax, KDE is not going to be rewritten in Mono. There are some C# bindings for KDE, just like there are Perl ones, Python, Java and some else which I don't know because I don't use any of them. That's about it. C# doesn't have any special position, and in the near future most probably won't have. It's just bindings after all.

    > Not only does this provide KDE with some of the multilingual programmability it initially forfeited by its use of Qt

    I'm quite sure the list of available bindings above is still missing a couple of them. Sure, it's not as many as Gnome bindings, but who'd want to write KDE apps in COBOL anyway >;).

  • Using multiple languages with the Mono framework (Score:3, Interesting)

    by Carl ( 12719 ) on Thursday September 12, 2002 @09:55AM (#4244245) Homepage
    Hi,

    Is there a good example why/how something like Mono/DotGNU helps using libraries written in/used from other programming languages?

    How does one for example mix and match a program written in C# which uses the iconv C library and the Qt C++ library while using the Guile library to give the user a scheme scripting extension to the program.

    I looked at the IK.VM.NET [weblogs.com] a DotNet Java implementation using GNU Classpath. You will see that there is a lot of work needed to make for example Java Exceptions work correctly with C# exceptions (Java exceptions are mostly checked, C# exceptions are never checked at compile time). And even simpler things as mixing the basic Sting classes or the IO library seem like it is non-trivial.

    And C# and Java are really very much like each other. What about mixing more "exotic" languages like Logo and Scheme with Prolog or even basic C?

    The DotNet runtime seems to support multiple language on top of it but it is not clear how that helps adapting libraries to multiple languages. It seems to me that you still have to write wrappers around every library to make it work with the way for example Strings, Dictonaries or other standard datastructures are represented/used in the different languages. It seems to me that mixing multiple languages will always be a challenge when programming.

    • Well some of those more 'exotic' languages are already being implemented with Mono. Like Logo for instance has 'MonoLogo' :-)

      As far as mixing languages, it's quite easy. If you want to mix the libraries that you were referring to then there would have to be bindings for those libraries. But any library that Mono or DotGNU supports can be used by any language that Mono or DotGNU supports.

  • Bad headline (Score:4, Informative)

    by JamesKPolk ( 13313 ) on Thursday September 12, 2002 @09:59AM (#4244264) Homepage
    There is no Mono code in KDE cvs.

    Repeat: There is no Mono code in KDE cvs.

    The only Mono discussion on either kde-devel or kde-core-devel has been by the Mono developers plus some Ximian people, who were there due to the CCs from the Qt Mono announcements.

    Nothing to see here. Please disperse.
    • You have been misinformed. There is 'Mono' aka C# code in KDE's cvs. I repeat there is C# code in KDE's cvs and there has been for quite sometime. Have a look in the kdebindings module :-)

  • Very cool - but I want more (Score:3, Insightful)

    by avdi ( 66548 ) on Thursday September 12, 2002 @10:02AM (#4244291) Homepage
    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.
    • This is a very interesting idea. I suppose this will happen sooner or later when we start wrapping SWF with Qt#.

      Just so I understand? Are you suggesting a completely new toolkit (read: not Windows.Forms) that the Ximian/KDE/GNOME communities would develop together, in C# and would have gtk/qt backends?
      • I only suggested an "equivalent" to Windows.Forms because I don't know offhand whether Windows.Forms is a) part of the free ECMA standard; and b) suitably platform-agnostic that it could be usefully implemented in Gtk and Qt. If both of those are true, than I would *strongly* lean towards implementing Windows.Forms itself, since that signifigantly improve the chances of running .NET applications unchanged on Linux/etc.

        Now, is this "wrapping SWF with Qt#" an actual plan? Sounds very interesting if it is.
        • Sure! well about as much as any OS/FS development has a plan... ;-)

          But, yes we will work on a SWF wrapper eventually. In fact if you really want to see it happen then come join us on irc.openprojects.org #qtcsharp and help us out!
  • It's not just opening up KDE to developer's unskilled in QT, as the article mentions.

    It could (eventually) opening up the KDE desktop to applications written for the Microsoft Forms library. Mono, in a sense, would be playing a similar role to .NET applications that WINE plays for win32.

  • multilingual programmability what ? (Score:4, Interesting)

    by InodoroPereyra ( 514794 ) on Thursday September 12, 2002 @10:15AM (#4244377)
    Not only does this provide KDE with some of the multilingual programmability it initially forfeited by its use of Qt

    You mean you are ignoring this [kde.org]?. I just read David Faure's comment. Is it me or this article is a troll ???

    • You must be new here...
      Slashdot is a pro-GNOME site. You will never see an objective look at KDE here (or GNOME either). Every story will have some little (usually untrue) cheap shot at KDE (like this one does). If you want to know what's up with KDE, go read the dot [kde.org]. If you want to hear a bunch of GNU zealots foam and froth about how KDE and Qt are the next Microsoft, read Slashdot.
  • It seems that COBOL will be supported.

    My elderly relatives will be pleased - now they can be part of Open Source, too.

    Come to think of it, if something's written in COBOL, it may as well be closed source ;).

  • I really like QT/KDE, but I have to admit that one of QT's basic flaws is that it is tied to a simple one-owner memory management scheme. As a result the Python binding was a disaster - the binding had no way to prevent a QT object from being deallocated, so if you did certain things (like remove a widget from a window), you could easily segfault the interpreter.

    It would be great to have a nice C# binding, but I don't see how one could feasibly interface QT with a garbage-collecting language. It's pretty much designed to be used from C++ only.
    • How do you write new modules for garbage collection languages? You just keep track of what you've done and how to undo it.
    • Nope... we just keep track of QObjects. When Qt/C++ calls a QObject dtor, we know it and delete the corresponding C# QObject and all of it's children. We mimic the Qt/C++ way of doing things. We also have a way of making the GC deallocate unmanaged resources so it's all good!
  • I am pretty excited by the work that Adam has been doing with the Qt# bindings as well as the work of Mike and Rachel on the Gtk# bindings, they bring the toolkits to the .NET framework and to Mono.

    People building Gtk# apps and Qt# apps will be able to share components written for Mono and the .NET framework easily.

    So even if Gnome and KDE can not share a lot of code currently because of the two divergining code bases, in the future we will be able to exchange code and chunks of it more easily.

    For instance, Adam is working on a documentation system for Mono written in Qt# and some of his code will be reused for a web-based version of the documentation system, and perhaps a Gtk# version of the documentation system.

    Miguel

Slashdot Top Deals

For God's sake, stop researching for a while and begin to think!

Close