Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
KDE GUI

KDE & GNOME Cooperate 217

Posted by CmdrTaco from the come-together dept.
||Plazm|| writes " Here's an interesting article on what's in the future for these two dev platforms. Maybe they can play nice after all... 'This past week, there has been an impressive show of cooperation between the KDE and GNOME projects involving prominent hackers from both camps. The initial subject of discussion was concerning a common network-connection manager that would enable applications to detect whether an internet connection was currently available or not; both projects had already been working on the issue including two independent efforts from KDE developers Bjoern Kahl and Matt Koss. The discussion diverged to the larger issue of making GNOME and KDE play nice together including related CORBA matters.' "
This discussion has been archived. No new comments can be posted.

KDE & GNOME Cooperate More

KDE & GNOME Cooperate

Comments Filter:

  • Re:The important thing here (Score:1)

    by Anonymous Coward

    You are absolutely correct here -- this is the most critical piece of the whole desktop environent. Which widget set is used basically doesn't matter at all in comparison to the object model. If the Gnome and KDE object models don't cleanly interoperate, then each project will only be about a quarter as useful as they could be, since network effects absolutely dominate when you can plug lots of small components together.

    For those not hip to what component models can buy you, imagine that at the command line you had two different, incompatible piping mechanisms. If ps used one and grep each used a different piping mechanism, you wouldn't be able to do things like "ps au | grep '(dns helper)'"; basically it would make scripting much harder.

    This is what we will face on the desktop if KOM and Baboon don't learn to talk to each other. Without it, the desktop environment will be pretty but basically useless, because you won't be able to script common tasks, you won't be able to take pieces of different apps to do things the way *you* want, and rapid prototyping becomes hell.

  • Both bloated - Use neither (Score:1)

    by Anonymous Coward
    Both KDE and Gnome make my puny little P200/64MB system screetch to a halt. I use neither, and do not foresee the need to anytime in the near future. Neither one offers anything at the _current_ date and time other than fancy widgets to play with on the desktop, no applications that are _stable_ and can be used for _real_ work. I would rather save what ram I have to applications to work with, not fancy widgets on the desktop.

  • Re:KDE/GNOME (Score:1)

    by Anonymous Coward
    please dont make jokes on slashdot threads, this is slashdot..not laughdot.
  • I too have a Matrox card and use KDE (v1.1.1). I have no troubles with it at all. I have left a single X/KDE session running for over a month with no problems. Currently X is at just under 20mb, but with 128mb ram I don't really mind that amount.

    Where I lose memory is Netscape (recently hit 80MB after about 3 days), but it's no trouble shutting it down when I close my Internet connection or when I'm done with it.

    Since KDE isn't any one program, what programs were up to 128MB? Is that with counting the shared memories?
  • Why should he have to delete them? The developers of all those notepads should be responsible for that. Yeah.

    In all seriousness, I agree with others who've stated how these programs are great learning tools for a language/toolkit. I use vi for most things, but when it came to seeing just how to implement a menu or toolbar in Qt/KDE, I broke open the source to kedit and voila; let the learning begin.
  • There is still a sufficiently large crowd that does not want any software to be under anything but L/GPL licenses. It's tough to imagine, but there are people more rogue than RMS. :)
  • Ok, well, it's off-topic, but maybe it'll stop someone from becoming a crack addict:

    Chronic is not just another name for "marijahoonie". Chronic is marijuana laced with crack (at least, I think so. Maybe it's other things). Not good.
  • ...Catastropic Explosion Follows. Film at 11.
  • Duh. smoke another blunt
  • I sit here reading slashdot on a Windows98 PC which I just rebooted 10 minutes ago due to there being insufficient USER resources to deal with the 15 browser windows, the email client, the irc client, the development environment and the task scheduler, all of which I had running at the same time, and in *spite* of the fact that I have 128 Megs of RAM in this box.

    And yet, when I closed all of those applications, I still couldn't start any others up due to an error from Windows itself "Insufficient memory to start application".

    Windows is a far worse culprit than Linux in this regard. Hardcoded User Resource limitations? Sheesh.

    With Linux, I could've just restarted X and still had my scheduler, email program, development environment still in good shape, but with Windows I've had to reboot it fully in order to get it back in working order.

  • For some, its the same. For others, its not.

    In Windows land, you have no choice. Totalitarian technology!

    End of discussion.
  • He works with computers as his livelihood (good for him) but all he really proves is that he cannot claim even faint acquaintance with the fear and confusion average users feel in the face of computers.

    I didn't set out to prove that I have faint acquaintance with the fear and confusion average users feel so you'll have to excuse that shortcoming in my earlier post, though I can certainly back up the argument that I *am* familiar with this phenomenon if needed...

    I write music software for a living. The average electronic musician is a fairly savvy type, and I know that there are definitely reasons why musicians prefer Macs over PC's.

    That's not my point, however.

    My point is: People too easily *blame* computers rather actually take the steps to adjust *themselves* as needed in order to overcome the difficulties that they might encounter. To me, and many other 'techno geeks', this is makes the difference between someone who knows how to use a computer, and someone who doesn't - *not* some 'usability study' or 'focus group' that is supposed to make your AOL experience shinier and happier.


    GUI environments including details of configuration are necessary for average users, Jay.

    Are they? Really? Does a network setup dialog *have* to be a GUI in order for it to get its job done, or can it just be well laid out text, with good introductory text on what is occurring before and after, that guides the user through doing something they'll probably (on average) only ever do maybe 2 or 3 times for the lifetime of that computer?

    They just are. Wasteful? I'll grant this --for now.

    For now, meaning until we have terrabyte-level data storage for cheap, in which case multi-gigabyte dialog box-rendering code will not be considered as wasteful ... :)

    But even if in theory they weren't so necessary, the existence of two strong environments (Win & mac) on desktop personal computers means that in practice Linux must have the equal if it is to succeed at all in the desktop market.

    Not necessarily. A GUI configuration environment exists only to serve one purpose - to interact with the person using the computer and present them with information on terms they are comfortable with.

    A text mode Linux script could quite happily compete against Windows' "Network Control Panel" if the help text surrounding it were a *lot* more useful, friendly, descriptive, and resulted in the end user having a *much* better understanding of the process being performed.

    Graphical design is no replacement for competent literacy, either in the help-file author/programmer or the end user.

    People aren't going to convert to text based configuration and operating systems that exclusively cling to it because a)they don't like it and b)they don't have to.

    Who says they don't like it? Millions of Linux users can't be wrong, the majority of them are used to using text based config tools... This is just hearsay.

    Most people like it when the computer does what they think it is going to do, and they don't like it when the computer does something that wasn't predictable in the eyes of the user. GUI's just serve to buffer the 'experiencing' of this phenomenon in a visually appealing manner.

    Text based configuration isn't called "harder" because of some subjective state of preconditioning that we can ascribe to Win/Mac users and wish-away.

    I would say that its considered harder because peoples general perception is that screens of text represent study/schooling, and that is usually associated with a large deal of mental effort, often under 'duress' (i.e. school exams, homework, getting the best 'grade', etc).

    Whereas GUI's represent more of a 'video game' sort of perspective.

    My point is that this perception of text by average users is inaccurate, as automatic as it may be. If people were generally taught to read for the sake of reading, and not in order to get 'good grades' or experience the duress of modern educational methods, then a text mode configuration tool would probably not be viewed with as much disdain.

    Perhaps this explains why Linux and other text-ish operating systems are more widely used and more prevalent in the realm of formal education - since most students are already in positions where 'text' and the 'study of letters' is an ability they are already fully exercising in other aspects of their lives, such as college.

    (they'll get over it) It simply is harder.

    Define 'harder'. And give an argument for how you came to that conclusion...

    The reason behind "a) they don't like it" is the simple fact that text based confguration allows for an _infinite_ number of mistakes and misconfigurations.

    Does it really? I don't think the mode of operation of the USER INTERFACE has anything to do with whether or not infinite numbers of mistakes are possible. I would argue that its the 'smartness' of the application itself that allows this to occur - if something is wrongly entered in a text mode method of configuration, the program should be able to inform the user accordingly.

    Let me give you an example: /etc/sysconfig/network-scripts contains a few text files full of details about network configuration. ifconfig is run on the contents of these files, so they have to be fairly correct.

    If something is incorrectly entered, ifconfig usually complains about it by printf'ing to stdout. What if there were a 'help daemon' that ran on the machine to intercept these messages, interpret them according to a database of information, and send e-mail to the user giving them full details of what is wrong?

    So what's wasteful, then? Writing GUI based configuration dialogs that people will use only rarely, or writing an OS that people will frequently remove from their hard drives because they cannot get over the learning curve of service configuration?

    Whats wasteful to me is 'not writing adequate documentation that can be read by multiple levels of literate society' ... GUI's and text config arguments are not really my point.

    My point is mostly that people just need to be given better *mental* tools for them to use in overcoming computer-related difficulty, and that most of the modern pop-OS GUI's do not encourage the fostering of those *mental* tools, whereas Linux does, rightly or wrongly so.

    In fact, I would argue that pop-OS's like MacOS and Windows encourage entrophy of the mental accumen required to be computer-competent, and therefore have a destructive effect on the end users' computer competency, from a pure mental perspective.

    I'm not saying Linux is perfect in this regard, I'm just pointing out that it does encourage computer competency in many ways, and that knowing this difference, us, as members of the Linux/Slashdot community, should use this knowledge to further enhance Linux in the future, either by design of cool/interesting/useful Window managers, better admin scripts, etc.

  • ... from the point of view of joe bloggs pc user...

    This point of view is a result of that persons involvement with computers over time, their experience. The 'position in PITA scale' as measured by joe bloggs pc user is only relevant when they don't know whats going on... once a user is savvy enough (because no matter how you look at it, becoming savvy is definitely better than just being glib about computer usage) they will become to appreciate the true benefits of this separation from kernel and user interface, and will adopt an operating basis accordingly.

    Most people are confused by Windows when they first start using it because they don't know whats going on. As they learn what goes on behind the scenes, they become better and better at using it... the same formula holds true for Linux.

    ...but system and services configuration? Stone Age(from J.Bloggs' point of view and requirements.)

    Again, this is subjective based on J.Bloggs' experiences as he learns to use his computer. Sure, if he just came from a Mac and now has to learn how to edit a text file, he's more than likely not going to want to do this because he is taught that 'learning how to do something new in life' is hard work, and so will therefore find fault with the computer rather than with his own inhibitions towards discovery.

    And excuses such as "but I am too busy, I don't have time to learn something" may work to counter my argument that people should just become more literate, but as an argument it doesn't serve to solve the fundamental problem, which is that "learning something new" is misperceived as a slow and painful process.

    Actually, it gets faster and easier the more you do it, and most professional computer users take great pride in their ability to hone their causative discovery skills with regards to technology.

    I think that this is the fundamental reason behind the Linux movement, personally: people enjoy the process of refining their skill sets that comes from having access to Linux, its tools, and its source code. It builds character. (heh heh!)

    Whereas Windows and other Microsoft products are really more specifically geared towards the user *not* having to learn anything, and thus *not* improving their cognitive skills, and to many people this is limiting, and in some cases offensive.

    Additionally I would argue that system/services configuration does not *NEED* a large deal of sophisticated GUI - after all, it should be something that only ever happens once.

    I have 15 computers in my posession, and I've done major configuration to each one of them maybe 2 or 3 times in the last 5 years that I've had them - everything ranging from multiple windows machines, 5 linux servers, a couple of SGI workstations, etc. Sure, it was nice to have a GUI, but that GUI is just sitting there wasting space now that I've gotten everything working fine...

    So I don't agree that these are strong points in Windows' favour, at least not in the context of this discussion...

  • Small apps such as text editors and paint programs tend to be very good examples when it comes to learning a new programming language like GTK or QT. Since KDE/GNOME are open source, anyone just starting out can peek in at the source to see how things are done. I know I have personally done this with many of the smaller KDE apps, and now I have a much greater understanding on how things are supposed to work. From this standpoint, it's definately a benefit in my opinion.
  • No one said that KDE and GNOME were planning a merger. What the KDE and GNOME developers are trying to do is have it so that KDE apps and GNOME apps can interoperate with each other.
  • Posted by stodge:

    I've had several crashes. Mostly due to kfm collapsing in a heap
  • **sarcasm**

    What are we gonna do?? We can't bash each other any more about KDE and gnome cause the big shots from each camp are getting friendly!! The world is ending!! We must find a new enemy within the Linux camp to attack!!

    **end sarcasm**

    Why is there this obsession with identifying "ingroups" and "outgroups"? Why not all share and be friendly? Why not give Windows its occasional due (it still is generally a better gaming platform, and is the source of inspiration for a lot of Linux development)? As people here have noted, slahdotters tend to get overly religious about [window mangers/desktop environments/word processors/distributions/etc.]. There's such a thing as using what works for you and letting everyone else do what they like (as long as they're doing the same....after all, standing there getting flamed for being moderate isn't right).


    Who am I?
    Why am here?
    Where is the chocolate?
  • Strange. Netscape leaks memory like a sieve, sure. But I can recover from that by just killing it.

    I agree that as Mozilla gets closer, my anticipation grows. I've used M7, and they're definitely making progress.

    --

  • No longer being supported? I don't think that's the case. AFAIK, it's still being worked on. And I've got it running on a RedHat 6.0 box, so I'm fairly certain it works OK. I compiled it from source, though; perhaps there is an XFMail rpm out there that doesn't work right?

    XFMail is a very nice mail program; it supports IMAP, POP and local mail spools, and does all the stuff that Netscape Mail doesn't do (like "Include File"). I don't know how Gennady Sorokopud would feel about it, but I'd love to see XFMail ported to KDE and/or GNOME. Unfortunately, that's a bit beyond my capabilities at this point. I don't know how difficult it would be, because I'm not sure how hard it is to port from xforms to another widget set.

    xforms, for those who don't know, is a freely-available, but binary-only (the authors say they will open source ver. 1.0, but not under the GPL), widget set, that is considered by many to be the ugliest widget set on the face of the earth. I won't disagree very strongly on this point... Those that use it, swear by it, though, saying that it makes building GUI programs quite easy.

    --

  • I stand corrected. Yes, after looking further at the site, and perusing DejaNews, it does appear that Mr. Sorokopud has dropped off the face of the earth, unfortunately. The last thing I saw from him was from nearly a year ago. Too bad...he really seems to be a good programmer.

    Anyhow, I had no trouble building XFMail that I recall. I did not use the xforms rpm, though...just the regular tarball.

    Maybe try that, if you were using the xforms rpm.

    --

  • No. Just another American, I'm afraid.

    --
  • Not to nitpick, but neither KDE or GNOME are really windowmanagers.

    They each come with a WM, but you're over simplifying the significance of this announcement.

  • you're being serious? or sarcastic?

    I'm not really sure. If you're being serious, then congrats on finding IceWM...it's nice. if you're being sarcastic, then I might ask "why?"

  • HA HA HA!!!!

    that was so funny, ....laughdot :)

  • I think I'll make the safe assumption that that was a joke. Some people are a bit too sensitive and/or have rather weak sense of humor...

  • That can't be right ... moc is a vital part of the Qt architecture. So as long as KDE is built on Qt, I don't see how you can get away from moc.

    Unless, of course, Qt 2.0 is very different from Qt 1.x in this aspect....

  • The subject says it all.

    Lets face it. By combning the abilites of the GNOME and KDE folks we are starting to group together a very serious group of talented programmers without wasting time and effort trying to better the opposition.

    It's this kind of annoucement that will really start the linux/*NIX domination of the market.


    All credit is due to those people who can see past the differences and who work towards a common goal.

    Iggy
  • Part of the problem that has haunted Open Source is the fact that there are many people willing to develop their own code because the code that they have been using "doesn't quite cut it." Don't get me wrong, that is also part of what makes Open Source so great. It can also be it's downfall. GNOME and KDE being a potential example of this. Although both were designed as an X Environment, they have-for the most part-gone seperate ways in how each interacts with X.
    By meeting on common grounds on certain issues, they are giving your everyday user (such as myself) better choices without much hassle.

    Now keep in mind, these are my opinions...I am not all knowing, and not a very good speller. Please feel free to correct me if I am wrong.

  • This would be SO nice.. It would extend the applet library for BOTh systems drastically..

    I can only hope it happens,..
  • They each come with a WM, but you're over simplifying the significance of this announcement.

    Really? Gnome comes with a WM? I didn't know that. I've been using Gnome since 0.40 (or soemwhere around there) and I never knew it came with a wm. I've been using icewm with it. So what's the wm Gnome comes with?... I'd like to try it out.
  • Suffice to say, this benefits everyone. Personally, I run GNOME for the look and feel, and the interface, but there are some nice KDE applications. The fact that they run is nice enough :) Interoperability is the holy grail because it stifles the argument about incompatible development. You don't like Gnumeric? Use KSpread! You don't want the kde file manager? Use gmc. It works out beautifully. With theming support for KDE, even the widgets will (in theory) look similar, we'll be able to draw upon the efforts of both KDE and GNOME developers and have a unified desktop.

    Anyone who says this is a waste of time, is severely lacking in the 'big picture' department.
  • This is a step in the right direction (a common windowmanager support API would be nice also).

    It's not going the whole way, but that's to be expected; these things are usually taken in small steps. It's the sort of thing which should be encouraged; the more interoperable these DE's become the better for everyone.
  • Consider the Gnome/KDE sflamewars. Those of us who kept our heads all wanted to see the two cooperate, but I don't think anyone honestly believed it would ever happen.

    Therefore, two other things that aren't likely to happen but should: M$ going bankrupt and MacOS getting a bit of respect among the geek community.
  • I'm a gnome user myself, but I have a few KDE apps that I like to use also. I think it would be great if they could share themability and whatnot. It would allow the developer to use which desktop environment he/she wants, and the user to integrate the application with his/her interface.

    Mike
  • I'm glad to know you've been using Gnome since 0.40, but have you bothered to update to a newer version recently? Gnome comes with Enlightenment and has for some time. Granted, you do not need to download and install it, but that doesn't alter the fact that Enlightenment is the WM Gnome comes with, if you follow the directions on their FTP site, which instruct you to download everything in the "Base" directory, which includes Englightenment. (Even if they didn't tell you to, the fact that Enlightenment is in the Base directory ought to be a clue...)

    I assume you're trying to be sarcastic. If it weren't for the fact that you're dead wrong, it might even have been funny...

    --

  • I believe it's Paddington. :)
    --
    Aaron Gaudio
    "The fool finds ignorance all around him.
  • BIGOT - buy a dictionary.
  • The reason not to use an environmental variable is that already-running apps are not notified.

    The reason not to use an environmental variable is that it's redundant information which could be obtained just as easily from ifconfig.

    Put CORBA support in your ifup/ifdown program, which will then (de)activate an interface, report that action to all the apps who want to know, and exit when they're done.

    It would be necessary to have this ifup/ifdown program the default way of handling network interfaces, but if you could get Gnome & KDE to agree on it the free Unix distributions will all fall over backwards to accomodate.

    There's the question of proprietary Unix support - but is this network monitoring daemon going to be able to do anything better than polling 'ifconfig' on them anyway?

    I think that criticizing this sort of stuff before it's built is really a bad idea.

    I think doing planning & design consideration before you start writing code is a good idea. You can hack an inefficient or bad implementation of a program at your leisure, but fixing an inefficiently or badly designed program is something to avoid if at all possible.

    If you don't like it, then don't use it or come up with something better. For the most part, though, these guys know full well what they're doing, as evidenced by the quality so far of GNOME and KDE both. Just kut them some gslack.

    You'll get no argument from me there. But keep in mind, one of the mixed blessings of Open Source development is the thousand back seat drivers waiting in the wings to point out segfaults, memory leaks, and even potential bad ideas. I think leaving a process sitting on it's ass 99% of the time to provide the functionality containable in a short shared library is a bad idea.
  • Does someone want to explain to me exactly what advantages this "network connection daemon" will have over a few hundred shared library lines that call "route" (or play with /proc) and "ifup"?

    I've got enough sleeping processes taking up RAM on my system as it is.
  • It certainly is not done yet, but it really isn't all that hard to do. The Qt signal/slot implementation can be replaced entirely with libsigc++. The whole point of libsigc++ is to provide a tool to build reusable libraries with. Libsigc++ is a complete superset of Qt signal system.

    Now how does this work... the old system would be removed from Qt and its replacement from Libsigc++ can be used in its place. Internally, this a bit of work depending on the number of close interactions within Qt with the signal system. It is certainly doable as a similar task is being done with Gtk-- right now to upgrade versions of signal system. This can be done to applications with a simple flex/bison program that converts the code once, rather that over and over again like MOC. They just toss out the source for MOC and use the translated source directly. Considering the code had to be preprocessor safe to start it is not a great task.

    Since libsigc++ is LGPL incorperating it in this fashion is not breaking any licences and Troll Tech is able to use the modified Qt both in the free and comercial versions. Of course, it can never be as closely incorperated as another GPL project can, but it is certainly workable. GPL/LGPL projects can just directly incorperate Libsigc++ into the code base if they want and build stronger interactions to their benifit. However, I feel that it is complete enough that most projects won't have to do that.

    Since some of Qt tied code is tied by the Qt types and signal system, replacing these with free pieces is of great benifit to the free software comunitee. You could then take a piece without having to keep it linking back to Qt. Reuse is our strength and libsigc++ was built to encourage that reuse by making library callbacks very easy to do. (Not that Qt under the new license is all that restrictive, but it is not directly GPL compatable which the new piece is.)

    This of course will have to wait til Qt 2.2 or something when the KDE developers have time to make the changes. It is not a feature of Qt 2.0, because libsigc++ was not even seperated from Gtk-- til after Qt 2.0 went to Beta! As fundemental as the signal/slot implementation is to Qt, to applications it was only just another API.

    Hope this clears things up a bit.

    --Karl

  • The way I see it, this situation basically boils down to this--either a.) the two projects merge and we have a unified code-base, b.) the two projects do not merge, but cooperate closely with each other so that they are more or less completely compatible, or c.) they cooperate somewhat, but not very much(like now) and the two remain partially, but not wholly, compatible.

    I believe that (a) is strictly out. The projects are built on different philosophies on how everything should work. One wants C and other C++. One intends to be strictly LGPL while the other tends toward GPL. Both sides seem to want the other to give up their widget sets. Talking to both, I think hell will freeze over first. Unless some super kit comes allong that is far better than both and it equally usable for both C and C++, it is not going to happen.

    Therefore, it will always be (b) or (c). The best hope is that CORBA will saturate the 2 frameworks and thus the interoperablity comes down to the API which they are working on. This of course means more of (c) the most likely outcome. Since the underlying technology (different widgets sets, different framework libraries) is so different, they will most likely just share some compatablity between file formats and such. But at that level the user will always need both library sets installed for the user to run applications from both under one desktop.

    Of course, I don't really mind that solution as long as it doesn't bloat them both out as you mentioned. The simplest workable solution should be the one that they adopt. I feel a continued competition between the desktops is good to inspire inovation (unlike those who feel it a waste of effort.)

    --Karl

  • Signal Systems (Score:5)

    by Kenelson ( 4445 ) on Friday July 02, 1999 @12:46PM (#1820364) Homepage
    Asside from this development, there has also been some talk on irc between members of the KDE crew and myself on sharing the signal/slot implementation between Gtk-- and Qt. Although the meeting was slightly dampened by my over competive nature, it generally ended with a positive step towards working together. This would further interopablity between KDE and GNOME by allowing the KDE C++ code and C++ GNOME code to share library elements that do not depend on the widget sets.

    Sharing of signal/slot implementations would benifit KDE by removing the MOC preprocessor and improve the flexiblity of their signal/slots. GNOME will get the benifit that KDE libraries and applications will be less tied to Qt and thus more easily reused. Since libsigc++ [ucdavis.edu], the Gtk-- [ton.tut.fi] signal system, is a close translation of the capablities of gtk+ signal system, this should also reduce the burden of programmers trying to understand the two kits. For projects with multiple frontends, this would be a great help.

    Unfortunately, this development is not set to be planned until after the summer when the KDE people start a developers cut of Qt. Assuming that people are interested I can give some directions as to how the translation can be made, but I don't have time to work on it heavily myself. (Preliminary specifications have already been sent to Mosfet.) I can mail more info to other interested programmers.

    --Karl

  • No, it wouldn't. See RMS's comment on Netscape Public License problems on www.gnu.org for a similar situation, where he points out that one of the problems (according to him) of NPL is that it's not GPL-compatible, despite the fact it's free.
  • The X license is compatible. Basically, anything you can say is GPL by sublicensing (X, some BSD) or by changing the licence (LGPL) or because it is (Perl license, GPL & something else) is compatible.
  • I think one of the reasons there are a lot of "simple" apps instead of one GOOD app is that simple apps are much easier to code either as a single developer or in a loosely structured open environment. That is a main reason that office apps are so far behind in Linux... anyone can write notepad, but it's much more difficult to write a quality word processor. Steve
  • I think that more than just a (some) killer app(s), many people have been waiting for more mature attitudes and perspectives from most or all of the leaders in the Linux community. This is a great sign and, to me anyway, just about guarantees that Linux will be appreciated and used more and more as a primary desktop platform.

    Now, back to Civ:CTP :)
  • I didn't say it was *just* the Linux community that is maturing. I was refering to the people that develop and lead the Linux community, not Linux itself. I think that is an important distinction. The *BSD community seems to have a reputation for a little more level headed leadership overall than some of the Linux segments do. I don't really see what you got riled up about.

    An understanding of software as complex as an operating system and support applications isn't easy to come by. Many people don't trust the Linux and OpenSource communities because they see the bickering and wonder if it will last. They stick with what is the 'standard' because they are sure it has a future. The more that we can put aside our minor differences of opinion about methodology and approach and focus on the large issues that we agree on, the more progress and support will grow. That is much easier to implement on new projects, but is possible on existing work.

    Just so you know, I have an official OpenBSD 2.5 CD pack sitting in front of me and parts on order to finish a third system to run it on. I bought it from the OpenBSD booth at Linux Expo '99. I bet they would be confused by your attitude and response too.
  • That's great news!

    Compatibly is good for all GNOME and KDE app developers. It increases the potential user base, user choices and developer choices.
  • They are trying to do that.

    KDE already works pretty good on lesser known *nixes, such as SC0, AIX, or *BSD.

    GNOME has some worked need on this portablity, I am sure this will happen in the future. GNOME has some little issues on big endian systems, such as the PowerPC. It also has some problems with certain OSes.

    Niether one of them compiles easily enought on systems that use cc instead of gcc, but I think they are people working on those issues.

    That's a problem in general with the Linux community, most developers lack the resources to extensively test on commerical properity systems or on cc instead of gnu c compilers.

    Re: Apple Issue

    Apple chose to work with FreeBSD and NetBSD developers to create the foundation for Mac OS X, because at the last minute they realized that this mach stuff wasn't going any wheres quickly. They have worked hard to create a *BSD, known as Darwin that uses the best parts of Mach, that they spent millions of dollars on, but still use the speed of *BSD. The Darwin project, was a natural reaction to work with *BSD developers, since it allowed community influence on their server base.

    Wheither I agree with it or not, that's a whole another issue (maybe I am just to gpl biased).
  • I feel the same way. I use GNOME + E for my main desktop (at least for now), and I use KPPP and a few other KDE apps.

    People need choice. Not everybody wants a KDE or a GNOME feature, they should be able to use the other desktop's feature (or none). Desktops should be so intergrated that this is easy.

    When I first moved to GNOME, I used the KDE File Manger, since GNOME had nothing close at the time (gmc was a toy then).

    I am glad to see this all working out. Please don't bash a certain desktop enviroment, since someday you'll be using it.

    True developers don't bitch about desktop enviroment choices.
  • Nobody is forcing you to use both. Just use the one that you want to use, based on the features it has (that appeal to you). Everybody has different needs, wants and preferences. ONE size does not fit all!

    The nice thing is if KDE and GNOME interact, you *can* use both together, although it will use slightly more resources.

    Competition is good. Monopoly on the desktop is bad.
  • I don't understand what you are mumbling about.

    E and Window Maker are both Window Mangers, and one has to run at a time.

    If you are suggesting intergrating the code bases into one source code, that would not make sense, since Window Maker aims to be something totally different then Enlightenment.

    If you are talking about GNOME compatiblity, both E and Window Maker work great with GNOME. Window Maker also works pretty good with KDE, although E could use some intergration work.
  • I disagree.

    Most older people, who have never used a computer before, really don't care about messing with configuration that much.

    They really don't care about kernel version, or how much of a certain word the computer has.

    They want something that does their work reliabily, without crashing and quickly. They don't want to configure things (except maybe Desktop Pictures, or maybe even icons/widgits color).

    In my experience the vast amount of people want the following:

    1) A good point an click e-mail program (preferably supporting HTML) This is still lacking! Maybe Netscape 5.0 will give us that.

    2) A simple, easy to use web browser. Netscape 5.0, based on Mozilla could be great!

    3) Word Processor like Microsoft Word with spelling under lining features, and simple but functional formating controls (like Microsoft Works 1.0 for Macintosh). AbiWord could do great here (when it's ready)!

    4) Being able to print easily.

    5) One click access to all of these features, on the desktop.

    So little needs to be done to get this done. It can be done okay, today, but wait 6 months, and you'll find it is ready for the masses.

    Joe Blow could care less about source code, or enlightenment or configuring advanced settings.

    Leave them to the system adminstator. What?! Joe Blow is the system admin? Well, then we do need to intergrate GUI tools better.

    Linux today, has the technology today to be vastly point and click adminstation, but in my experience no distro does a good job at showing them.

    You would be hard pressed to find me a setting that you can not point and click on a Linux system (assuming you have the graphical tool installed.

    KDE and GNOME are great, appealing to their own groups of people. Now if they just work together better, that would be great!

    Simple things. You can do better!

    KEEP THE GREAT WORK UP GNOME AND KDE TEAMS!
  • Another reason why Office Apps are behind in Linux, is that Linux didn't become a platform to develop large flexable office Applications, until KDE/qt and GNOME/gtk+ were released.

    Yes, their was older toolkits, but many of them were limited, ugly or preformed horribly. (examples: Athena, Motif). Lesstif is a new thing, that finally allowed workable Motif apps to run on Linux for nothing.

    A good office program needs a good desktop enviroment behind it to work good, and compete modernly. APIs need to be in place from the desktop enviroment to work. That's what KDE and GNOME are all about. They provide APIs that make good office software possible.

    Office programs are quickly catching up, the speed of development in Linux is faster then most commerical development (what desktop enviroment has recieved a full featured desktop, a powerful imaging program and a office program in like 3 years?). Microsoft Windows didn't have a really good image editing program until like 1993 to 1994. Windows 3.1 was hardly a full featured intergrated desktop, it had many holes, and often required editing text files. DOS mode programs were the norm in the first few years. Windows 98 was the first version of Windows that fully intergrated the Internet into WIndows.

    The Mac OS didn't grow up over night either. Early versions of it were limited, you could run one program at the time, painting on a 9 inch screen was pretty limited, some of the first office choices sucked pretty bad (you want MacWrite or MacWrite with that machine?, MS Word for Macintosh was a distance awy).

    It takes time. But if history shows the progress of a rapidly growing OS, Linux will become full featured sometime from 2000 to 20001.

    Keep watching, developing, and enjoying!
  • I'm sorry, I screwed up!

    The network connection manager will do much more: like letting applications request a connection, bring down the connection, etc. It's exactly that, a network connection *manager*. Please read the list articles for more details.

  • Yeah (Score:1)

    by navindra ( 7571 )
    This is all my fault for leaving the kde-devel summary to the last minute.

    The network connection manager is meant to do more than just trivially detect whether the line is up or down. It will allow apps to request that the line be brought up or down, and more... It may or may not be implemented with CORBA, but the goal is to make sure KDE and GNOME don't do this in incompatible ways.

    Maybe check out Bjoern's page: http://home.netsurf.de/bjoern .kahl/netmgr/index2.html [netsurf.de] and the list articles [gnome.org] for all the proper details.

  • That's like saying that there should be memory leaks in the kernel because apps forget to free() all of their memory. Everywhere else in Unix, once the process dies, all its resources are freed.


    But when a process allocates some *shared* memory, it won't be freed by the kernel once it has died. And there are sometimes leaks this way.

    seb.
    --
  • I extend your line of questioning to display it's absurdity
    And I question your extension of the line of questioning to display it's absurdity.
    - Why doesn't everyone focus on writing good apps for Windows instead of Linux?
    Because Windows sucks. Don't you read slashdot?
    - Why do companies waste time developing non-intel processors?
    Because they are heathen infidels.
    - Why do people around the world waste time learning/reading/writing/speaking non-english languages?
    That is a damn good question. I have often wondered that myself. It would make my life much easier.
    - Why do students waste time doing problems listed in their books instead of inventing new problems?
    Because the professors are too lazy to come up with interesting novel problems. They are far too busy psychologically abusing their graduate students.
    - Why do we need a dozen search engines?
    Because they all suck. In combination, they suck a little less.
    - Why do all these little countries need their own government?
    Again, that is a damn good question. We should just all get together and agree that our governements suck, then find one that sucks less than the others, and let them take over. Perhaps Canada. They seem to be doing fairly well. Or Holland.
    - Why do we need all these programming languages. Can't everyone use Java for everything?
    Err, don't you mean perl?
  • I'm told that this will happen. Matthias Ettrich (kwm author and KDE founder) is supposedly working with several sombodies at creating a standard "applet" protocol. When that happens, I'll have those mods in KBiff within a day or so.

    For the record, I was going to put direct GNOME panel support into kbiff but didn't for two reasons:

    1) I couldn't get the gnome system working until *very* recently
    2) As soon as I got it working, I heard of the common applet collaboration and decided not to waste my time on code that would be thrown away in a few months.
  • Frankly speaking, it doesn't matter. Certain individuals have made it clear in this thread and in many others that they have no intention of co-operating. Again, it doesn't matter.

    As you can see from this thread, there *are* developers from both sides that are more than willing to co-operate. That's what it takes -- people that will do the actual work. If there is a clear consensus that co-operation and shared protocols are a Good Thing *AND* there is code to back that up, then those who stand in the way will simply get overruled or swept aside.

    It's in the best interest of both users and developers from both sides to go this route. Recalcitrant individuals can do nothing more than slow the process down...
  • > KDE already works pretty good on lesser known *nixes, such as SC0, AIX, or *BSD.

    And *ahem* Solaris. It's picking up a bit of popularity here at Sun actually, but it's a long way off from replacing the well-entrenched CDE. Here's my immediate impresson of why:

    1. Inertia, retraining, ego. Things KDE can't do a whole lot about. Not a small item, and will be a major inhibiting factor even if KDE were superior in *every* respect.

    2. KDE does not support multiheaded displays. Many apps like kwm act strangely when started on a second display. Alt-F2 on any display still uses the first display.

    3. No IMAP support in kmail. kmail also doesn't perform any kind of locking as far as I can tell, and isn't mailx compliant. dtmail, the standard CDE mail program, which replaces mailtool (sadly) is klunky beyond belief but is reasonably powerful. IMAP is an absolute must. vcard and LDAP support will probably soon be requirements as well.

    4. A calendar that supports CDE's dtcal standard and takes attachments dragged out of kmail onto the calendar icon. Do one better than CDE by giving some actual feedback when it's dropped, and not just silently dropping appointments if the calendar isn't running (which amazingly, is what happens now)

    5. Preferred web browser support. Solaris 2.7 has a one-click web-browser icon on the panel (the funky looking globe clock). It will launch either netscape or hotjava, using the equivalent of netscape-wrapper for both, in that it will not launch new processes if one exists, just open new windows.

    Oh, and KDE compiles just fine with devpro, which is what cc is on my system.



  • > But why not have ip-up and ip-down set a variable to ONLINE and OFFLINE?

    Because tripping over the phone cord and yanking it out does not call ip-down, that's why. In any case there IS a program that will notify a process when an interface goes down, but I forgot what it is. It also appears to need a separate instance of this process for every program that wants to watch the interface status.
  • > (a) MS developed DOS ? IBM did and (regrettably) passed development over the MS in 88 or something.

    IBM, with all its expertise, somehow couldn't find anyone who knew anything about small-footprint operating systems at all, so they got Micro-Soft, a compiler vendor with no OS development experience at all to pick one out for them. MS picked a hacked-up piece of crap called QDOS, handed it over to IBM, with the stipulation that MS be allowed to develop their own version in the future. IBM agreed.

    Sad thing is, not much else would have run with any acceptable performance, given the corners cut on the hardware. But then it wouldn't have been affordable, Apple would have annihilated the PC makers, and it would be Steve Jobs in front of a judge now.
  • No, you're just one of the annoying ones who pontificates upon this fact. Go back to your starbucks and microbrews, "drug-free" boy.
  • The dtcal standard should be documented somewhere, since the calendar sync for pilotmgr will sync CDE calendars. Try looking there.
  • > hat the GPL cannot be used with any non-GPL libraries

    the exact sitation is : if you want to mix GPl with non-GPL:
    - the other licence must allow everything the GPL allowes
    - the other licence may only restrict stuff also restricted by the GPL. more exact: may not have clauses not found in the GPL.
    thus, it's possible to mix GPL'ed software with much other stuff. as long as at least as much is allowed, and not more is restricted.
    example licences, where this is true:
    LGPL, BSD, XFREE, Apache, Artistic

    examples of licences with additional clauses, but still free software: MPL and QPL

    please let the "GPL only with GPL" syndrom die.
    GPL with LGPL, GPL with BSD and such stuff is very common and a good counter example. or even better: read the licence. i always wonder how many people didn't ...
  • Let me see if I can make this as unbiased as possible for I really *DO* like Linux...

    Windows applications are GUI. Period.
    Linux applications are half GUI, half Console, and half hidden configuration files.

    Windows sets up it's hardware with EASE.
    Linux drags it's ass and then you *STILL* have to be a genius to get PnP working right for just 3 cards.

    Windows is far ahead in the game and there are many more well-designed applications for doing what you want, so productivity and time it takes to get used to it are a lot better then Linux which...
    ...which has a million applications to do the same thing but 90% of them were designed for the console or by people that use the console a lot, so they are either very badly designed GUI's or need a *TON* of configuration.

    Windows is a pre-smoothed GUI so out of the box everything looks good (relatively speaking, that is).
    Linux on the other hand needs hours to get things working right, and that is IF you know what you are doing. I still to this day haven't figured out how to install and use another font in, say, the titlebars in E (other then installing a theme with it included). And truetype fonts? I still haven't seen them on my machine yet, still looks like hell.

    Now, back to my biased side here...

    Now I love Linux and I love to play with it and all but that is just it... play. I can't get anything done when it comes to work or anything else because Linux's GUI is so rough. Even working with Gnome & E, the applications are still tough to grasp. I have spent literally hours working at getting Linux usable for working and by that point, I don't want to work anymore, I want to go watch TV or go out or SOMETHING other then sitting in front of the computer. It's really frustrating.

    Now I saw a truely good idea in that recent install program by Caldera, and I don't see why people are knocking it because it'll make installation 10 times easier. Granted, Redhat's install is fairly easy, it still lacks details that I'd love to know. Like that question... "What services do you want running on startup?" How the hell should I know? I think I know what 2 of them are.. sendmail and I forget the other.

    Now, no offense or anything, but I put my money on the fact that if your mom got onto a Windows machine she'd start doing things faster almost instantly. She'd probably also catch onto the GUI a lot faster.

    8Complex
  • Oh please, if you wanna take issue with reinventing the wheel, take a look at Gnome, take your head out of your ass, and then comment.

    Right now, I have no plans to use pppd or Linux at all, and so diald would be useless for me. Oh but that's right, Gnome is Linux only, right?
  • The daemon aims to be more portable. Not everyone feels the need to be burdened by a GPL'd kernel, or by Linux ya know.
  • ...I still want to hear about an Enlightenment/WindowMaker partnership...
    Now that would be one slick combination...
    just waiting to hear more from Rasterman about how E's development is coming...
    can't wait..

    ------------------------------------------
    Reveal your Source, Unleash the Power. (tm)
  • I think things might not be so bad as that. Those small applications couldn't have been all that much work, in the scheme of things. (Not to put-down the applications, certainly!) It seems to me to be wiser to consider them to be simple test cases of the greater architecture of GNOME or KDE.

    Which brings us to the next point, which would be: "Yeah, but isn't the simultaneous development of GNOME and KDE a waste of resources?"

    Were it the case that we knew exactly how we want to go in the desktop-look-and-feel arena, I would say yes. But do we? I personally see GNOME and KDE not as a dangerous schism (though it once was, and could be again in the future), but rather as two experimental designs that could merge to the final product.

    It's not always good for everyone to agree. The increased contemplation that accompanies a disagreement could spur more innovation. It's just good old-fashioned competition.

    We just need to keep the competition healthy and friendly, and pray for some compatibility.
  • I can't wait. I really want to install Linux on my moms computer. :-) Cooperation here will hopefully speed up Linux On the Desktop.

  • ummm. ya. In general you can already do that. infact, you don't have to actually run either WM, just have the libraries and such installed. Thats what I do....

  • XFree is fast enough for normal applications. Maybe you're worried about games and the like, but there market share considerations are always going to outweigh raw speed.

    Personally, I think that the lack of an as-good-as-Windows web browser is more of a problem.
    --

  • You're right - Shift+Restart is the same as exiting Windows to DOS and then typing WIN to restart Windows. This is usually OK because most Windows users will have no drivers running in DOS.
    --

  • Re:The important thing here (Score:3)

    by IntlHarvester ( 11985 ) on Friday July 02, 1999 @10:13AM (#1820398) Journal

    Ah - but here's the problem. (My understanding is that any 'compound document' whether OLE or OpenParts is potentially an executable.) Sometimes you actually might wish to have scripts running automatically. (Think of JavaScript web pages for example.) As Microsoft has proved, flashing a "Do you really want to do this?" dialog box is no protection against stupid users.

    You can get around this by sandboxing, but the solution in Lotus Notes and MS Office 2000 is the ability to have all script macros cryptographically signed. An administrator-controlled excution control list defines what runs and what can't run. A client-server approach might also work, but it's looking like both Gnome and KDE are pretty much desktop-oriented, and some sort of controlling server might not jibe with Linux culture.

    Anyways, the standard Unix security answer of "it's a user space issue" ain't going to be good enough here. All MS Office viruses running under NT are user space only, and they're still raising plenty of hell.

    It's great to see that minds are converging on this issue. This give open projects a chance to develop a much better implementation than Microsoft, as well as develop an alternative to OLE/COM, which is pretty much the only game in town as far as user apps go.
    --
  • I do not see anything absurd in my original question. It is one thing to have choice of different word processing software and another to have 10 notepad clones on your system.
  • I am saying that it is Saturday morning and you are definately trying to piss me off. But that's OK - it is your right, specially on a day when I don't feel up to your level of irony...
  • Not much will change unless somebody comes up with something better than X. Current solution simply won't cut it - specially when compared with Windows ... It is much slower than Windows on the same hardware - this will be enough for many people to conclude that Linux is inferior to MS offerings ( and to tell the truth it is - when it comes to desktop functionality it definately is)
  • If GNOME served no purpose other than to encourage Troll Tech to open QT then I'd say in the big scheme of things that the redundancy of the GNOME effort was worthwhile. But, I think that's just scratching the surface of the advantages that two GUI's competing for Linux can give us as long as both sides stride for interpretability.
  • I would like to either see all GTK and QT applications supporting the panel of both KDE and Gnome eventually, or at least making it very easy for the user to switch at runtime with a parameter!
    That way applications like KBiff, etc could be used under Gnome, and those like GTop and the Pager could be used under KDE. *That* would rock.

    I'm sure these talks about Corba and compatibility between the KDE and Gnome implementations is definitely a step in the right direction.
  • ... collaborating and working along with one another? A short while ago, to suggest something like this would have generated a 300 post flame war on /.
    How far we've come... I hope we've all learned something along the way too.
  • XFree is fast enough for normal applications. Maybe you're worried about games ... speed


    Right, but games that need speed are in the 3D realm, no?

    So X by itself is OK, but we need a fast OpenGL implementation, right?


    I think that both researchers and gamers can agree on this and Daryll Strauss is working on it.

    (http://www.linux3d.org)



    an as-good-as-Windows web browser ...

    Netscape is sick old man. We know it, Netscape knows it, and it is being replaced while you are reading these lines

  • Superkit (Score:1)

    by ja ( 14684 )
    None of the sides wants to see their hard work being wasted just because some inexplicable whim favoured the other side. Therefore there is a natural tendency for collobaration.


    You say that the hardest part is the widget set?

    OK! Then this is the challenge then of the month:

    #define The unifying widgetset for Gnome and Kay.






  • What kinda AC humorless moron are you?

    The right to joke is everymans god given right... (or nature given, or whatever)

    A world (or Slashdot) without humor is a world I don't want to live in

    --Natalie Portman, topless
  • I think the point is that if KDE and Gnome cooperate,
    you'll be able to run all apps with only one desktop
    installed. That'd be the goal anyway.
  • Its bad because:

    Personally I would like either Gnome "or" Kde. I do not want Gnome "and" Kde. Here is why:
    I don't want to have two sets of libraries on my machine taking up twice the memory/disk they should. If one choice is made, then less bloat.

    This will inevitably add to feature bloat so they will be "compatible".

    Its good because:

    Its a good baby step towards cooperation that may lead to one widget/library set being dropped.

    Thats a dream eh?
  • Also recommended reading: Havoc's (sorry, forgot his last name!) weekly GNOME updates (availible from gnome.org). They paint a nice warm and fuzzy picture of GNOME and KDE getting along great, and they're pretty interesting. So both sides admit it; it's gotta be true!

    Though I would recommend not reading the gnome-kde mailing list (also availible at gnome.org) unless it relates to you. There is of course disagreement on the issues as they come up. I tried reading it, got scared, and am now happy with having my news filtered through GNOME weekly news. I lose details, but I can still be a Pollyana.
  • This is true, (it's probably more like going
    into single-user mode and then comming straigt
    back up). But I think the point was that
    it was a trick for restarting windows quickly.
    So, depending on how you use linux, this
    trick is _functionally_equivilent_ to restarting
    X, because it takes about the same time.

    Linux _has_ an advantage for people who do
    a lot of their work from the console though.
    (Like me).
  • By this logic, it's a waste of time to have Emacs, Xemacs, VI, Joe, Xedit, etc. all be separate projects. It's a waste of time for Enlightenment and WindowMaker to compete. It's a waste of time developing all these different Linux distributions to begin with.
  • I said that it's a perception. That some people believe this to be reality is unfortunate.
  • "Its a good baby step towards cooperation that may lead to one widget/library set being dropped"

    Having a choice of widgets/libraries is as important to a developer as having a choice of desktops is to the user.

  • KDE Moving Towards Artistic License? (Score:3)

    by Arandir ( 19206 ) on Friday July 02, 1999 @08:32AM (#1820416) Homepage Journal
    One thing not mentioned in this snippet, but which I've started to notice, is that KDE, and KOffice in particular, is moving more and more towards using the Artistic License.

    There is a perception (right or wrong) that the GPL cannot be used with any non-GPL libraries. Since Qt is free and open, but not GPL, there were many unwilling to touch the KDE code base. Strangely enough, by making KDE code Artistic, it will perceived to be more compatible with the GPL than if it remained GPL.

  • The important thing here (Score:4)

    by JohnZed ( 20191 ) on Friday July 02, 1999 @07:53AM (#1820422)
    will be the establishment of the common CORBA mappings. I'd love to see KDE's KOM/Open Parts component model broaden to the point where I can easily write an app in GTK+ or GTK--, throw a KOM wrapper around it, and then use it seamlessly with KDE KOM parts. Imagine... A Gnumeric spreadsheet embedded in KWord!
    --JZ
  • I used to think so, but not anymore.

    Let me give you an example. Both desktops come with their own text editors. The really neat thing is that they go about text editing different ways. The KDE Advanced Editor is lightweight and has nice features such as syntax editing. On the other hand, GEdit has a multiple document interface and plug ins.

    The same thing goes with everything else. The office suits are broadly different. KOffice are many applications made to integrate together from the start in one suit. And Gnome Workshop are separate applications that integrate at the file level (I may be wrong about this, please correct me) so that other programs may be added as needed.

    I can go on with differences between IDEs, Calenders, and the rest of the programs. This is what competition offers that wouldn't have existed otherwise. Just thing where Linux would be now if the Hurd matured a little quicker.

    I think this is a different Open Source model than we are used to. ESR should write another essay.

    --

  • So are satan and hussein coming soon?
  • No of course not. Emacs and VI have always iteroperated, but did that stop anyone bickering? ;)
  • I extend your line of questioning to display it's absurdity

    - Why doesn't everyone focus on writing good apps for Windows instead of Linux?
    - Why do companies waste time developing non-intel processors?
    - Why do people around the world waste time learning/reading/writing/speaking non-english languages?
    - Why do students waste time doing problems listed in their books instead of inventing new problems?
    - Why do we need a dozen search engines?
    - Why do all these little countries need their own government?
    - Why do we need all these programming languages. Can't everyone use Java for everything?
  • Heck, its a waste to develop multiple operating systems... and I'm sure microsoft will back me up on this one :)

    Doug

  • KDE/GNOME collaboration...or not? (Score:4)

    by GuidoDEV ( 57554 ) on Friday July 02, 1999 @01:03PM (#1820459)
    The way I see it, this situation basically boils down to this--either a.) the two projects merge and we have a unified code-base, b.) the two projects do not merge, but cooperate closely with each other so that they are more or less completely compatible, or c.) they cooperate somewhat, but not very much(like now) and the two remain partially, but not wholly, compatible.

    Now the question naturally arises, "Which solution is best for the community as a whole"? Should we unify the codebase, thinking that a standard interface would promote application development? Or should we just cooperate and come up with a CORBA standard, but not necessarily an identical codebase, in the hope that such a move would encourage folks to write applications to that standard API and yet not alienate others who like their way of doing things(i.e., there is the die-hard gtk+ developer and the die-hard qt developer, one or both of whom could be angered, depending on the implementation). But what about just sticking with the status quo, where a little cooperation exists, but not nearly enough to come up with a standard CORBA API. After all, it seems to have worked pretty well so far, right?

    Now let us examine the options we have at hand. KDE, since it uses C++, tends to put off alot of traditional C developers, and GNOME, being C, tends to have very few apps developed for it in C++. Now we could have a big argument about the relative merits of each language, but in my opinion that's pointless, because what we need here is choice--the choice to develop your application in whatever language you are most comfortable using(within reason, of course). Of course, we could do that by consolidating KDE and GNOME and merely maintaining two widget sets, but to me that seems rather pointless, for simplicity and utility is the philosophy of Linux and U*ix in general, so there is really no need for creating a lot of confusion by having a "standard" which isn't really a standard. It would be standard in the sense that all the applications would be written for that single environment, but it would simultaneously be non-standard in that for one desktop environment we actually have two developmental trees, which would probably lead to having two of everything anyway.

    On the other hand, we could let things remain as they are, but the disadvantage of doing that is that a developer is forced towrite his application to one environment or the other, or go through a huge amount of effort to make sure that his program is compatible with both standards. This is obviously a great waste of time and energy which could be expended in developing a new application.

    Now we come to the solution which I prefer, namely, the development of a standard CORBA API through collaboration between the KDE/GNOME developers. This solution does not, of course, come without its own pitfalls and minefields as well. For instance, both KDE and GNOME could become very bloated in the process of becoming compatible with each other. This is a legitimate concern, but considering the code that we have seen from KDE/GNOME, I believe the developers there are capable of preventing this situation from occuring, and this way the programmer has a real choice as to which language he wishes to use, and doesn't need to compromise by writing to one environment only. It also serves to promote choice for the user as well, since there would ideally be two desktop environments, each with its own respective strengths and weaknesses as interpreted by the user. I don't think we really these environments to convert to the Windows philosophy of a one-size-fits-all Environment for Everyone.

    I'm sure that there are things I left out, but this was intended to provoke thoughtful dialogue, so if you have any ideas or input then please, by all means, post them here. I am certain that there are many other things we could do besides the three I came up with. What we need before making any decisions about the direction which GNOME and KDE will follow is a debate as to the merits of each option, so that we may be assured that the one we select to implement(or not, as the case may be) is the right choice.

Slashdot Top Deals

You can be replaced by this computer.

Close