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 3.0 Alpha1 Available for Developers 294

Posted by michael from the as-unstable-as-windows dept.
Dre writes: "Just a few weeks after the release of the rock-solid KDE 2.2.1, the KDE Project today announced the release of KDE 3.0 Alpha1. Targeted at developers who want to get a head start on porting or writing applications to KDE 3, the release is pretty much a straight port of the KDE 2.2 branch to Qt 3. However, for developers this brings an impressive array of new features to KDE, including new database classes, new data-aware widgets, improved RAD development with a much-enhanced Qt Designer, a new powerful regular expression class (with full Unicode support), improved internationalization support (including the ability to mix different character sets in the same text), bi-directional language support (for languages such as Arabic and Hebrew), multi-monitor (Xinerama and multi-screen) support, better integration of pure Qt applications into KDE, and hardware-accelerated alpha blending. With the Qt port out of the way, the KDE developers can now focus on the planned KDE improvements. Read the full announcement here, or go straight to the source (alternative link)."
This discussion has been archived. No new comments can be posted.

KDE 3.0 Alpha1 Available for Developers More

KDE 3.0 Alpha1 Available for Developers

Comments Filter:
  • The planned features list seems a little unambitious to me. I know that many of the programmers working on KDE are top-notch, but there needs to be some other talent in there as well. In my opinion the KDE developers need to be concentrating on productivity features. They have the opportunity to be at the forefront of that kind of thing. Microsoft wastes plenty of money in researching that kind of thing, but they lack the flexibility to be cutting edge.

    • Re:The planned features list (Score:1, Informative)

      by Anonymous Coward
      There won't be huge changes because this is only a small improvement. The reason it makes such a large version jump is stay with Qt. Otherwise it would be called 2.3.
      • Yeah, I suppose so. I'll have to try developing a couple applications for it to see what it's like.
      • They NEED large version number jumps.

        But I wish they would start releasing two different product lines: "commercial" and "geek".

        • Re:Qt is 9/10ths commercial (Score:4, Insightful)

          by jonathan_ingram ( 30440 ) on Saturday October 06, 2001 @07:27PM (#2396408) Homepage
          No, Qt have never artifically inflated their version number. The first number changes with major binary incompatible changes to the library, the second with additional features that keep binary compatibility, and the third with bug-fixes. KDE uses this numbering scheme as well.

          Just because you might be used to other projects (such as the Linux kernel) completely changing interfaces within minor version revisions, doesn't mean that is how a properly managed piece of software is versioned.

    • Re:The planned features list (Score:4, Informative)

      by Spy Hunter ( 317220 ) on Saturday October 06, 2001 @07:14PM (#2396378) Journal
      Remember, KDE 3.0 is mostly just a port, with the same amount of new features you might expect going from, say 2.2 to 2.3. It is *nothing* at all like the nearly complete rewrite going from KDE 1 to KDE 2.

      That said, I expect that there will be far more new features in KDE 3.0 than what's described on that page. Most likely the developers just haven't bothered to tell anyone about all the new features they're going to add yet.

      And with KDE's blazing release schedule, 3.1 will be upon us before we know it, with all sorts of goodies :-)

    • KDE is a *desktop*, not a productivity suite. Microsoft may be attempting to add everything but the kitchen sink into their desktop, but that's not the way we do things in Unix land.

      In my never humble opinion, keep KDE a desktop and infrastructure, and spin off the extra stuff into their own projects (like they did with KOffice).

      • Re:The planned features list (Score:4, Insightful)

        by jilles ( 20976 ) on Sunday October 07, 2001 @04:27AM (#2397286) Homepage
        By definition, infrastructure should encapsulate every feature that is common to the applications that use it. The problem with UNIX is that such infrastructure is lacking. This has lead to a situation where in order to be able to compete with ms windows (which does have such infrastructure), applications have to include everything and the kitchen sink. Look at star office, it comes with its own widgets, its own printing subsystem, its own way of embedding components and until the recent beta it even came with its own desktop. Sure it is integrated with Gnome/KDE to some extent but since it also needs to be portable across the two it contains a lot of duplicated functionality.

        KDE developers have understood this and are currently working to deliver such an infrastructure. Ignorant critics complain about konquerors ability to be both a browser and a file manager. However, once you understand what infrastructure is supposed to be you recognize that same ability as a good working infrastructure. File managers and browsers have a lot in common and therefore you might as well integrate them so that you don't have to invent the light twice.

        The UNIX philosophy is to make something small and only once. Most unix applications only meet the first part of that philosophy and have to duplicate everything and the kitchensink because it is either not present in the infrastructure or not consistent enough to allow for easy integration (this should also be facilitated by the infrastructure).
  • from the as-unstable-as-windows dept.
    pff ... i bet it's stabler than slashcode [slashcode.com]
  • Or did they just not made into press release? Kde 2.2.1 rocks but a bit more speed & responsiveness would be nice. I hope kde guys can achive something like the speed change from 2.1 to 2.2.1.

    • Re:Are there no new speed enhancements... (Score:4, Informative)

      by Spy Hunter ( 317220 ) on Saturday October 06, 2001 @07:33PM (#2396426) Journal
      I think you just missed them. Look in the planned features list:

      icon server, Waldo Bastian bastian@kde.org
      KIO/KHTML: pipelined HTTP requests, infrastructure, Waldo Bastian bastian@kde.org

      I think the icon server in particular will help with startup times of KDE apps. The pipelined HTTP requests will make loading of webpages faster.

      In addition, a lot of the speed problems actually lie with GCC and the GNU linker, which KDE can't help with. The GCC and ld developers have been made aware of the problem, and a lot of work is going on on their end to speed up the dynamic linking of C++ programs. Once these optimizations start making it into stable releases of the linker, KDE will be much more responsive.

      • I don't know what an icon server is, that is why I "missed" :) Is it technically possible to prelink some commonly used programs using idle time? the first application start after kde start seq. would suffer but on average it may pay.

        • Re:Are there no new speed enhancements... (Score:4, Informative)

          by Spy Hunter ( 317220 ) on Saturday October 06, 2001 @07:58PM (#2396482) Journal
          I'm not familiar with exactly how the linker enhancements work, but I think they do something like you describe.

          About the icon server: Currently each KDE program that wants an icon (every one) goes and checks each directory where that icon might be found (of which there are a lot, KDE has a very customizable icon system). The icon server would catalog all the icons available on startup and serve them to the programs that need them whenever they ask, preventing a lot of disk reads. I think that's the basic idea.

        • Re:Are there no new speed enhancements... (Score:5, Informative)

          by debrain ( 29228 ) on Saturday October 06, 2001 @09:13PM (#2396645) Journal
          Yes, a pre-linker is what is being done with GCC. You might notice that kdeinit may run everything in KDE, from konqueror through konsole; that's because kdeinit is already linked. This is annoying when looking at the actual processes running. They're all kdeinit. Especially annoying for killing those zombieish konqueror sessions.


          The pre-linking relies on the fact that once libraries are loaded, they never move in memory. That could be a false assumption, but the gcc team is going to great ends to make sure it isn't. The issue as demonstrated is that 'helloworld' will be much larger, and much slower to load when it links against the QT libraries (or any large set of libraries). Thus, similar performance is lost when starting KDE applications linked against the QT libraries simply because they are all loading the QT library linkages.

      • KDE-2.2 seems to have made the startup thing a little better, but what really still bothers me is widget-drawing speed. Try this little experiement. Start up Word 97 (or 2000, don't know about XP). Resize it as fast as you can. Even on a low-end machine, it will keep up with out. The widgets will move to their proper places and the worst effect will be a little (faint) flicker. Now try the same thing With KWord. When resizing to make the window smaller, there is a visible delay in the toolbars moving to their new positions. When resizing to make the window larger, there is a visible grey area in the just-resized portion before the widgets draw in. For someone who spends a lot of time futzing with windows (me) the effect is really annoying.
  • Just curious. It seems to me that data aware widgets ties the view in too closely with the model and breaks the paradigm. Of course, MVC does have weaknesses, but it seems to be the driving paradigm of graphical user interfaces these days.
    • In OO design, you have the eternal war between cohesion and coupling. High cohesion is good (classes to only one thing). Low coupling is good (classes are independent). But high cohesion leads to high coupling, and vice versa.

      MVC is a good design and has a nice balance between cohesion and coupling. Unfortunately, like all good designs, templates and patterns, once you overlay it with a real application it's not so perfect anymore.

      Data aware widgets have high coupling. But in turn they get high cohesion. If that level of cohesion is desired (a component, for example), then there's not much you can do about it, MVC or otherwise.
  • Uh-Oh,

    From the planned feature list:

    * kpf - web server applet, designed for sharing files

    That does not sound like a wise thing to do, implementing webserver functionality into a desktop applet. That's what we've got daemons for, right? Small, self-contained, functional and modular. With the added bonus that the webserver keeps on running when the user logs out.

    If you really want to share some files on your box through the desktop, there's lots of P2P apps/'platforms' out there which make this possible. Jabber comes to mind, or JXTA, or... even a 'personal Apache controller applet' for all I care.
    But a webserver *in* the applet... Nein Danke...
    • It sounds like a fine thing to do, to me. Why would a user want their files shared while they were logged out? KDE is meant for desktop systems, not file-servers. Most users turn off their computer while they're not logged in. I like the idea of an easy-to-use filesharing mechanism that works over the Internet integrated with the desktop, it is something MS hasn't done yet but is really logical.
      • Uh... If those files the user shares are 'important' to collegues/friends/whoever, why would they only want to share them while logged in? Also, in many workplaces workstations are shared between many people, or used by many people ('flexible office' and such...), so the mere fact that the user is not logged in on a certain machine does not mean she does not want/need to share those files.

        The filesharing functionality in itself can be handy, but the place to implement this is not in a desktop applet. A controller for the 'server', sure, put that in an applet. But the server itself is better implemented as a small, self-contained daemon. This makes it much easier to audit it for security problems, and actually fix those problems.
      • So Microsoft throws in IIS, and it's a huge security hole. KDE does it, and it's a 'fine thing to do.'
    • Well.. I beg to differ.
      If you are speaking of the average techie.. sure, go use another piece of software.

      To a windows convert, being able to select a file/folder and hit 'share' would be great.
      • It is not the functionality (sharing files) which I dispute, but the place where it is to be implemented (in a desktop applet, as far as I can tell from the TODO-list). From a security standpoint it does not seem to be the best place to implement this functionality. KDE is huge, and has - as far as I know - not been subject of a rigorous check for the usual security-related problems (buffer overflows, etc). This webserver applet would use the KDE framework to serve files to the outside, so it would have to sit there listening on some TCP port. Now what if (and that's probably not an 'if' at all...) there's some exploitable problem in one of the libraries? And this applet is installed on all those KDE desktops which are popping up everywhere thanks to the huge success of free software and the downfall of the evil empire and such?

        We'd have the same problems as 'they' have today.

        Oh, and for those of you who think I'm disparaging KDE, that's not the case. Replace 'KDE' with 'GNOME' or 'CDE' or 'XFCE' or whichever big(gish) desktop environment you care to name, the same would hold true.

    • Mac OS X has a web sharing feature, but it simply fires up Apache (with some nice reasonable defaults). That's probably the best approach.

    • Re: kpf - web server applet: please don't (Score:3, Informative)

      by Anonymous Coward

      I'm the author of kpf.

      It's not supposed to be a fully-fledged webserver. As the comment says, it's designed for sharing files (e.g. with people you are chatting to on IRC.) It just happens to speak HTTP, because firstly that makes it easy to grab files (kfmclient copy http://some.server/some.file file:/tmp/, or wget if you fancy) and the HTTP protocol is a lot simpler to implement than e.g. FTP.

      Simplicity of implementation was a major factor in choosing a protocol because kpf must be secure. The less code, the easier to audit.

      Note also that the 'real' web servers are not easy to monitor and control in realtime. Because kpf runs as a panel applet, you can watch the connections and the traffic, and even kill off connections if you don't like what they're doing.

      You would be surprised how much traffic kpf can handle without threads, subprocesses, etc. - and running within the same process as kicker - all without slowing down kicker.

      The home page is here [clara.net] if you'd like to take a look at the current version (which is for KDE 2.x)

      Rik
  • "and hardware-accelerated alpha blending"

    buzzword or actually implemented in the new KDE/Qt? Alpha blending IMHO increases elegance (not to be confused with usability) of an interface when used properly. Any KDE developer(s) care to explain how and what this actually means? e.g. Render calls, which components use this, etc?

    Thanks,
    -adnans

    • Re:hardware-accelerated alpha blending?! (Score:4, Informative)

      by Spy Hunter ( 317220 ) on Saturday October 06, 2001 @08:08PM (#2396499) Journal
      The new QT has support for alpha-blending through the X Render extension. This means:

      Better (full) PNG transparency support in the browser
      Alpha-blending for all icons everywhere to reduce jagged edges (especially for small icons)
      Neat eyecandy effects

      What I'm interested in is what happens when Render isn't available? Do all those effects go away cleanly, or do they stay there using slow software emulation?

  • they state that they will have C bindings

    well that's new I wonder if they are going to anything like GTK C bindings ?

    and I think that a web server applet is a bad idea
    (although implemeting a control function for apache DAV would be good)

    and the really good news is
    Remapping/Naming of Modifier Keys: emulation of traditional Mac keyboard, where Ctrl is called "Command", Meta "Alt", and Alt "Apple", and "Apple" has the function of Ctrl. Let Meta be called "Win" for MS Windows users. Let a user without a Meta key easily select another modifier (e.g. CTRL_R) to act as Meta.

    that is a blessing, I hope that others follow the example and provide an alternitive mapping
    (RISCOS had it like this and I got on well with it, same as the mac I use)

    regards

    john jones
    • Please, oh please, don't call the meta key "Win"! Just because my keyboard has three keys with funny symbols on them, don't assume that I am a MS Windows users. I mean really! If I were a Windows user, I wouldn't be using KDE now, would I!

      There should be an explanation somewhere that the key on most PC keyboards with the MS logo is the "alt" key. That goes without saying. But don't rename it!
  • I'm currious from anyone who has used Gnome and switched to KDE: what do you think the advantages are? I'm open minded enough to consider KDE, but want to know what people feel is better. (Please be more specific than Gnome sucks. That's not going to sway me very much.)

    Also, anyone reading this who has left KDE for Gnome tell me what made you switch.

    I've always thought this Gnome vs. KDE thing was about as dumb as vi vs. emacs.

    • Re:Gnome User (Score:3, Interesting)

      by reverius ( 471142 )
      I switched from KDE to Gnome. The primary reason was an easy one... the latest GNOME is available (through Ximian) for Debian Stable (aka Potato, aka 2.2)... but the latest KDE is a bit harder to do.

      When I tried KDE 2.1 on this box, it seemed kinda sluggish. KDE 2.2 is a lot faster, but it ain't gonna run on Debian 2.2.

      A big plus for me as well is the customizability (albeit mostly hidden) of gnome. I can completely remove the desktop icons (and Nautilus itself ;)) and save on system resources. I can make my whole user interface look exactly like MacOS 8 (which I do). So I use Gnome instead of KDE.

      If Debian 2.3 (Woody) would come out soon, I'd be glad to try KDE 2.2 on it, and maybe stick with it. :)
      • I can make my whole user interface look exactly like MacOS 8 (which I do).

        With a working mac-style menu bar like KDE does, eh? ;)

      • debian 2.3? (Score:2, Informative)

        by mikey13 ( 458907 )
        I thought they decided Woody was going to be 3.0.

        "The code name for the next major Debian release after
        potato is ``woody''. This release will be
        numbered ``3.0''."
        http://www.debian.org/releases/testing/
    • I don't use either Gnome or KDE, because I like just a nice WM like E or WindowMaker so I feel my opinion is probably not very biased.

      After Gnome became stable (1.X) I tried both Gnome and KDE and found that KDE was like vanilla MacOS and seemed to lack the amount of neat features that Gnome had. But I still didn't use Gnome because it was too slow on my machine.

      I just recently used both and I have to say that I think the roles have reversed. The newest KDE is very sexy with good use of anti-aliasing and alpha. KDE seems to have gone the OSX route but with a more mature look.

      I would say that I think the latest KDE is even better than OSX, but I am biased in that I think that the Aqua theme is ass candy fugly.

    • Re:Gnome User (Score:3, Informative)

      by jonathan_ingram ( 30440 )
      Back when it was KDE 1 vs Gnome 1.2, I used Gnome... or bits of it. For ages I used Sawfish on its own, back when it was called Sawmill and wasn't the Gnome default window manager. I always hated GMC, and didn't use the panel much... so my use of Gnome was mostly restricted to the applications, and most of those (Gimp, XChat, ...) were GTK+ rather than Gnome.

      Once KDE 2 came out, I found myself using Konqueror more and more, plus Konsole, mostly because of the tabbed MDI interface it has (which is wonderful). From there it was a small step to actually running the whole KDE desktop -- I even got used to the KDE window manager, although it still feels a bit clunky in comparison to Sawfish (I see that KDE 3 will have active desktop borders back again though, which is wonderful).

      Of course, I can still run all the same GTK+ applications I used to use, and they work just as well. Kate, Konsole and Konqueror are the killer apps for KDE, plus the way it all feels much more integrated together than Gnome does (although it has the better individual applications).

      I've always thought this Gnome vs. KDE thing was about as dumb as vi vs. emacs.

      And it'll keep on going just as long as vi vs. emacs...
    • I prefer KDE but I'm not really a convert. I installed both for a time until I decided KDE was better and I had no use for gnome. As for why I think KDE is better, I can't really give concrete reasons. The looks are worse, localization is better, customizability is a bit better, default terminal is better, default browser is better, rpm manager is worse...but no real big differences between the two. I'll install KDE at work for the simple reason that its office suit and desktop can be configured to look quite like windows, to which folks at my company are used to.

    • Re:Gnome User (Score:4, Interesting)

      by hexix ( 9514 ) on Saturday October 06, 2001 @08:21PM (#2396539) Homepage
      Well I use both, usually GNOME more often as I like the look I can achieve with it and pretty much all my favorite programs are gtk+ based, so it's nice having the same look for everything.

      But the reason I think a lot of people like KDE is because of the level of integration everything has. It truly is a Desktop Environment, whereas GNOME at this point has more of a "most of the programs look similar" feel to it. Very little seems to be in place for the programs to talk to eachother and work the same from application to application.

      For example, in KDE2 every program that opens files (to the best of my knowledge) uses KIO (I'm guessing that stands for KDE Input Outout) and this makes it so you can open and save files from/to anything KIO supports. For example, you can open a file in a KDE text editing program by giving a http url like http://slashdot.org/ (that should give you the source code for slashdot's main page in HTML) then you could then save that file to some ftp site, just by putting ftp://blah.com/incoming/file.html in the save dialog.

      That level of integration is all over KDE2 and it really makes for a great experience. There is tons of other stuff too, like how konqueror embeds components so it can display many types of files. In fact, if I'm not wrong, the koffice office suite is made up of components so I think you can view kword files in konqueror without really launching the kword application, just embeds it into konqueror's window.

      Lots of other stuff to explore in KDE. For me though I just like the look and feel of GNOME. And I think all those nifty things in KDE give it a lot more stuff that can break (and from my experience it tends to do just that). Of course I could just have bad luck with it, I dunno.

      • Re:Gnome User (Score:3, Informative)

        by jfunk ( 33224 )
        Don't forget the coolest feature of KDE file dialogs: bookmarks.

        The GNOME file dialog is a royal pain to use. It's ugly (layout and widgets) and has no useablity features. I find myself frustrated whenever I use it.
        • "The GNOME file dialog is a royal pain to use. It's ugly (layout and widgets) and has no useablity features. I find myself frustrated whenever I use it. "

          Which is why it has been rewritten for Gnome 2.0 :)

        • Re:Gnome User (Score:2, Interesting)

          by hexix ( 9514 )
          Yeah definitely. I'm pretty sure that GNOME is getting a new file selection dialog, in fact in Ximian GNOME right now there is a new one, which is much nicer.

          My only gripe about the KDE file selection dialog is the fact that you can't specify directories in the same spot you type in files. One thing I've grown to love about the Gnome/GTK+ file selection dialog (no matter how ugly it is) is that I can use tab completion to specify a full path very quickly, just like in a bash shell. For example, if I want to get to the directory /usr/share/pixmaps/backgrounds I can type /usr/shpixba and that will usually get me there very quickly. And you can do the same thing with files of course, and if there is more then one match when you hit tab, that's what files/directories the file selection dialog will show so you can find files very quickly this way.

          With KDE's there is a seperate text input for the directory, which is nice and it should stay that way but I think they should add the ability to specify the directory in the file text input box.

          But, pretty small gripe considering all the things the GNOME/GTK+ selection dialog has wrong with it ;)

          • My only gripe about the KDE file selection dialog is the fact that you can't specify directories in the same spot you type in files.

            Uh... I just tested this with KATE. Alt-f, o, win/autoexec.bat [enter] -- works just fine. Same with saving.

            Now I don't have the nifty tab completion but if I type the directory in the directory text entry widget I can do /usr/sh[end]/pix[end] and then tab down to the file...

            • I meant you can't switch to a different directory without going and typing it in in the other field. with GTK+'s you can type the directory name and hit tab and it will show the contents of that directory. No need to switch to the other text field and type in the directory then switch back to the other text field. That's all I was trying to say.

          • I'm pretty sure that GNOME is getting a new file selection dialog, in fact in Ximian GNOME right now there is a new one, which is much nicer.

            Even more interesting: this is actually a complete remake of the file selection from Microsoft Office 2000.

          • Re:Gnome User (Score:4, Informative)

            by Jens ( 85040 ) <jens-slashdot.spamfreemail@de> on Sunday October 07, 2001 @04:35AM (#2397291) Homepage
            One thing I've grown to love about the Gnome/GTK+ file selection dialog (no matter how ugly it is) is that I can use tab completion to specify a full path very quickly

            Have you ever right-clicked on the file name input widget? It says right there: "Completion: (none, manual, menu, automatic, short automatic)"

            This goes for EVERY input widget that accepts URLs. Not only for file dialogs. KDE rocks. :-)

        • Actually, the only proplem I have with the Gnome file dialogue is that there is no way to display hidden files except typing '.' and 'tab.' New users don't know how to do this and experienced users don't want to have to move their hand from the mouse button to the keyboard and back.

          In KDE it takes three mouse clicks to show hidden files and three mouse clicks to hide them again. That's as annoying as gnome.

          Personally, I think Gnome's way of showing all files regardless of type is better than KDE's and microsofts way of only displaying certain types of files. This may seem usefull at first but it confuses newbies who wonder, "Hey! Who deleted all my files?!?" It is better to allow users to organize their own files into sub directories.

          In general, the only hidden files should be hidden files but you should be able to display or hide them again at the click of a button.

          (KDE file menu has some other nice features... I think the home button and bookmarks are nice.)

    • Re:Gnome User (Score:3, Informative)

      by fault0 ( 514452 )
      What I've used:

      KDE 1.0 vs. Nothing: KDE 1.0
      KDE 1.1 vs. Nothing: KDE 1.0
      KDE 1.2 vs. GNOME 1.0: KDE 1.2
      KDE 1.2 vs. GNOME 1.2: GNOME 1.2
      KDE 2.0 vs. GNOME 1.2: both (but more GNOME 1.2)
      KDE 2.1 vs. GNOME 1.2: KDE 2.1
      KDE 2.2 vs. GNOME 1.4: KDE 2.2
      KDE 3.0 vs. GNOME 2.0: I probably will use KDE 3.0

      Frankly speaking, both DE's are good, but I like KDE better since 2.0. Right now, I prefer KDE a lot more than GNOME. It's more mature, more stable, and has more features that I want and need. The only downside I can think of with KDE was the lack of eye candy and customizability. But, KDE 2.1 and KDE 2.2 really seemed to fill in the gap. KDE 2.2's panel is about as customizable as GNOME 1.4's panel. The theme support is about the same (although there is nothing like the KDE Liquid theme, with transparent menus, shadowed text, and strippled window backgrounds for GNOME). I think that the rest of the "look" aspect is better for KDE. It has builtin antialiasing (gdkxft for GNOME doesn't work for everything). I also like the alpha transparent icons in KDE. I think KDE 3.0 will really shine because of the builtin xrender support in Qt. This should allow stuff like truly transparent terminals and windows :).

      KDE also seems to be faster in some areas (Konq. vs. Nautilus, for example). Most of the rest of speed is about the same (provided kde uses objprelink). Application support is about the same.

      I think that the biggest thing going for KDE is probably that it is a lot more intregrated than GNOME is. I think that that's what a "desktop environment" should be, after all.
      • Your desktop environment timeline is very similar to mine :)

        although there is nothing like the KDE Liquid theme, with transparent menus, shadowed text, and strippled window backgrounds

        I really wish Mosfet hadn't had that stupid little spat with the core KDE developers -- KDE needs people like him who are interested in both graphics and programming. He just seemed to have a habit of checking code in 2 days after the final code-freeze deadlines...

        (for those of you new to the story -- Mosfet developed the KDE 2 style engines as well as Pixie. After being told that he couldn't add his Liquid style because it was after a feature freeze deadline, Mosfet decided to remove all his code from the KDE CVS and change the license on it to a form of the QPL. Most of the styles have been readded in the form they were before they were removed, and are now being developed independently. This is a picture of Liquid [mosfet.org], which is nice I suppose if you like that sort of thing.)

    • Re:Gnome User (Score:1, Interesting)

      by Anonymous Coward
      I'm one of the many who went from GNOME to KDE -- but in my case it's because I spent the last three years coding for BeOS, which had a wonderful c++ api. Just beautiful.
      When I realized I had to bail to another OS(choosing linux, obviously) I went to GNOME, since all the screenshots looked so damn purdy.

      But I spent, perhaps, 2 weeks *attempting* to make GTK+ cede to my will, without any worthwhile success.

      For reference, I'm not a c++-only kinda guy. I used to work at a software company writing device drivers for early set-top-boxes in assembler and c. So I _do_ know that kind of stuff. Quite well, in fact.

      The trouble was... GTK+ just didn't make any *sense* to me!

      And on the other hand, QT _did_ and KDE is, after all, written not just in QT/C++, but it follows the same naming and logical conventions (which are, I might add, well thought out.)

      In the end, I actually prefered using GNOME. I think it's nice and slick, and has good minimalist approaches to the user experience. Relative to KDE it's quite minimalist. By this point (6 months into linux use/programming) I've managed to learn KDE well enough that it's a good experience for me...

      but by god I'm never going to touch GTK/GNOME APIs again if I don't have to.

      Just my 2c
  • The release notes mentions hardware accelerated alpha blending. Does this mean that KDE will have a super smooth looking desktop like Nautilus but still be very fast? I love the look of Nautilus when the smooth graphics are turned on, but the performance hit sucks.

    Also this should get rid of the sharp edges of icons in the KDE menu and on buttons in programs right? Or are they only using it for fading out inactive items?

    Anyone have a screenshot of KDE 3.0 alpha showing how the alpha blending looks?

  • One thing to make this article better:

    from the developers-developers-developers [detonate.net] dept.

    :)
  • I don't like kde or gnome for that matter, If I wanted a cpu heavy WM I'd use windows. I know saying that will piss some people off but it's true. The reason I started useinglinux a few years ago was to NOT have a computer thats memory was all bogged down with the GUI (windows) so I turned to Linux. WM's like kde and Gnome are great for transition from windows but the reason for changing should be to get more out of your PC not just to be cool or whatever.I usually use XFCE or iceWM mainly because I don't carre what "theme" I'm using, I care about how well my apps will run. Please don't flame me for saying that.

    • Re:Don't get me wrong but... (Score:1, Interesting)

      by Anonymous Coward
      You don't need to run *all* of KDE *or* GNOME, which is the great thing about both projects.

      Take me. When I first ran across GNOME (around 1.0), it was really unstable. However, gnome-panel beat the snot out of AfterStep's wharf. So I just ran the panel, and ignored the rest of GNOME.

      Now that GNOME is all around better than before, I actually run gnome-session, and have GNOME start my WM. I still don't use gmc, which I don't like, and stick to bash for file management. No icons on the desktop, but I'm using GNOME and GNOME apps.

      So while you certainly don't have to run GNOME or KDE or GNUStep (It's Linux! The land of choice!), be aware that the parts may be worth more than the whole.

      This is NOT my home page [cmu.edu].
    • I've found for usability, Afterstep is the best. Before CmdrTaco had 1.5gigs of ram he used it :-) Afterstep is faster in my testing than blackbox, and it looks better/works better. I just don't like the lack of Afterstep support, but then again usually the elite are few.
    • So, the reason I switched from Windows to Linux full-time is that Windows sucked at its job. (It's gotten a lot better, incidentally, but still doesn't do it for me.)

      In terms of "getting more out of" my PC... it's a desktop machine. Its entire purpose in life is to provide me with a decent set of apps in a nice, convenient, featureful interfce. "Getting more" does not involve stripping down the UI to bare minimum so I can encode the occasional vorbis file a little bit faster. That's what nice(1) and renice(8) are for.

      Maybe it's just me, but the "just to be cool" factor seems to be more prevalent among people who use Blackbox, Enlightenment, and Windowmaker than among those who use a full Gnome or (especially) KDE desktop.

      KDE isn't leet, I'm told. Oh well.

  • Konqueror is much better than GMC IMHO, and more configurable than Nautilus, but some updates to the file-browser part of Konqueror would be nice. In particular, something emulating the functionality of Windoze's listview control would be nice. I hate having to view in large icon mode just to draw boxes around files to select them. When in detailed list view, selecting a file selects the whole row when it should ideally only select the filename in the first column.

    This might sound petty but this particular aspect when compared with Windoze Explorer makes the Konqueror file browser feel almost like winfile.exe when it comes to selecting files.

    Just my 2cents worth. I'm still going to use KDE regardless, though, because Nautilus is slow and has very few options for configuring it.
  • A new release of KDE is probably enough to drive new minor releases for a lot of distros. So, what other widely used stuff is seeing a new release these days? The news about the StarOffice beta isn't even cold yet, so I expect we'll be seeing that.
  • Microsoft is moving to C#/CLR. Apple's latest desktop is based on Objective-C and Java. Objective-C, C#, and Java have compelling advantages for developing large, component based software systems, foremost reflection, garbage collection, and (for C# and Java) runtime safety. Yet, the KDE effort is still largely based on C++, with little indication that there is any move to a more powerful runtime and more high-level language.

    It's amazing how far KDE has gotten in a few years. But the industry is moving on to different technologies, technologies that greatly simplify applications programming. What is KDE doing?

    • Simple!=better for everything. For something like an OS or the basic window interface, sometimes you need comething that lets you get a little down and dirty [which Java simply does not do, and from what I gather neither does C#]. Ease of code is fine and dandy, unless it translates into slower, buggier, clunkier programs. Sure, computing power is cheap these days, but even so, not all systems are GHz monsters with 512MB of DDR RAM and 80 gig HDs... have to pay attention to the lower end of the user pool, and make it a good experience for all [something I know Java is not good at]

    • Re:it seems KDE is falling behind (Score:5, Informative)

      by Jagasian ( 129329 ) on Sunday October 07, 2001 @01:52AM (#2397140)
      Most of my expertise falls into software development in Java, but recently I have been pushing myself to do more C++ development on Linux. I don't want to rely on proprietary languages. Anyway, the modern C++ is far far different from the C++ of many years ago. Things have changed, and C++ is growing up. Sure its a very complex language, if you try to learn the legacy aspects of it, but if you stick to the core OO constructs in C++, then you have a nice efficient programming language.

      I am coming to realize that Java has very little over C++. Garbage Collection is more of a buzz word than an actual worthwhile feature, and it should be noted that high-level memory leaks are still possible in Java. Sure they are memory leaks of a different kind, but unreleased yet unused memory is a big problem in many large Java software systems.

      In addition, for even an intermediate software developer, how difficult is it to code your own destructors? I mean, really, at worst you have a few loops in a destructor. Anyway, most JVM garbage collectors are unpredictable and hog performance at the worst of times.

      The most important thing that Java has over C++ is a comprehensive set of user-friendly yet powerful APIs. But in return, C++ as templates and STL, allowing for elegant generic software systems.

      When it comes down to it, C/C++ are here to stay, until some real yet practical innovation in Functional Programming languages, mobile/concurrent languages, or Declarative Programming languages is made. I am all for newer better higher-level programming languages such as Haskell, Pict, Lolli, and Mozart-Oz, but Python, Ruby, C#, and other newer procedural/OO languages are not the revolution, they are not the future, and at best, they are nothing more than slight iterative improvements on an overused overdone, and over talked about paradigm.

      Give me C, give me C++, and if you can, why don't you give me something new for once? I am tired of the same old Ford Tempo with a new paint job and a new name.
      • The most important thing that Java has over C++ is a comprehensive set of user-friendly yet powerful APIs. But in return, C++ as templates and STL, allowing for elegant generic software systems.

        The thing is for normal application development you'll need the normal APIs provided by Java. Take for instance the way of creating a socket. In C++ you'll have to use the C-Unix API. This does not look good and is definately not OO. With Java, you'll just create a new DatagramSocket. But with QT that is changing. QSocket provides a TCP-socket.

        I think that QT is providing some of the missing features to C++.

        Mikael
        • Exactly! That was my implied point. Java has a better (more modern, more complete) standard API compared to C++, and therefore, it is not KDE's job to change or augment the C++ language, or to replace C++ with another slightly better language. KDE exists so as to create a comprehensive platform API similar to the one available for Java. In fact, this is exactly what KDE has been doing all along. KDE's API isn't just about widgets. It is about modernizing the Unix API for Object-Oriented software development of interactive desktop applications.

          The question is, "will it succeed?" I claim that KDE is already succeeding in regards to modernizing the Unix API. There is more to be done, but I know that it will continue to succeed for two main reasons: First, it is open, and second, it has lots of initial momentum behind it because of the genius of its originators. It is the same two-part recipe for success that Linus used to bring the Linux kernel from just another pipe-dream to an industrial strength Unix kernel.

          Note that I am not implying that the original standard Posix APIs should be replaced. However, it is very important that another layer can be added ontop of the traditional Unix layer, so as to modernize Unix and bring it to the desktop.
      • Let me just counter a few of your misconceptions:
        • The purpose of garbage collection isn't to eliminate memory leaks, it is to enable runtime safety (important when building software from lots of components).
        • Destructors or reference counting in C++ are not substitutes for garbage collection because they don't accomplish the two things garbage collection accomplishes: runtime safety and factoring resource management out of interfaces.
        • Reference counting or manual storage management are neither cheap nor predictable.
        • The similarity between Java and C++ is mostly syntax; in terms of semantics, the languages are very different.
        • C/C++ lack reflection and runtime safety, both of which are very important features for building large, reliable software systems from components. You can emulate reflection and try to substitute testing for runtime safety, but it's a lot more work.

        I should note that I have used C++ since before cfront was released to the public, and I think C++ is a great language a number of specific purposes. Smart people can craft very efficient software and debug it in C++. But for getting a job done quickly, for working in large groups with people with different kinds of backgrounds, and for building reliable software from lots of components that are composed at runtime, Java and languages like it are simply better in my experience. And Microsoft, Apple, and many other companies seem to have drawn the same conclusion.

    • Huh?? (Score:3, Informative)

      by Ars-Fartsica ( 166957 )
      Why on earth would the KDE team move from a flexible, well known, openly standardized multiparadigm language to one that is closed, monoparadigm, and barely out of the gates????

      KDE should consider using a interpreted language for desktop productivity apps exactly one year after Microsoft does. Try again in 2005.

      • Re:Huh?? (Score:2)

        by MSG ( 12810 )
        Microsoft already does use an interpereted language for their "desktop productivity apps", and has for quite some time. Most of MS Office is written in Visual Basic.

    • Re:it seems KDE is falling behind (Score:4, Interesting)

      by Karellen ( 104380 ) on Sunday October 07, 2001 @08:22AM (#2397432) Homepage
      What's so great about a CLR???

      All it does is allow you to "compile" your source into a more obfuscated form of source that no-one can read but you can ship off to any other computer where it will get compiled for real (usually JIT - which is IMO more like a cached interpreter, but that's just semantics) before being run.

      All a CLR allows you to do is obfuscate your source a lot. We don't bother. Just ship the real source and allow someone to compile it themselves.

      CLRs are just a klunky workaround for people who feel a need to hide their source for whatever reason.

Slashdot Top Deals

As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality. -- Albert Einstein

Close