KDE 3.0 Alpha1 Available for Developers 294
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)."
The planned features list (Score:2, Insightful)
Re:The planned features list (Score:1, Informative)
Re:The planned features list (Score:1)
Qt is 9/10ths commercial (Score:2)
But I wish they would start releasing two different product lines: "commercial" and "geek".
Re:Qt is 9/10ths commercial (Score:4, Insightful)
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)
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 :-)
Re:The planned features list (Score:3, Insightful)
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)
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).
Re:The planned features list (Score:2)
>>>>>>
Actually, there is nothing to be cynical about. Qt3 is a big step up from Qt2. For example, it is finally thread-safe. Qt2 was also, in theory, but threading features were unused in KDE programs because of the immaturity of Qt's thread saftey. Check out the Qt3 features list. [trolltech.com]
Re:The planned features list (Score:2)
I didn't say KDE had the kitchen sink included, but I will cede the point. What I am arguing is that it *shouldn't* have the kitchen sink.
Not every KDE application needs to be a part of the core KDE. Keeping KOffice as its own project is a Good Thing(tm). Other ideas of that magnitude should be separate projects as well.
Re:the tree and the forest (Score:4, Informative)
You sir, are one of three things: ignorant, a troll, or an idiot. KDE is entirely built on components, and I can swap them in and out and upgrade them and advance functionality without upgrading the whole.
Which brings up an important point - 3.0 should look just like the existing 2.2.1, with no new (user) features. The major number bumped up *because* of the component nature of KDE - the new version is the exact same (on the front end), but is binarily incompatable with 2.x. The back end gives advances that will allow the 3.x line to advance quickly on the front end.
--
Evan
Re:the tree and the forest (Score:2)
That means that it is a lot harder to build component-based applications in the KDE environment than in an environment based on a language that has such support.
But, sadly, your response seems pretty typical of the KDE crowd: you don't even appreciate the issue and label anybody who disagrees with you a "troll".
quite right (Score:2)
Re:the tree and the forest (Score:2)
That may be your list. In fact, Java is succeeding so spectacularly because it makes reuse and componentization much easier than C++. And, yes, Microsoft copied Java for just that reason. Now, why is KDE still mucking around with C++?
have you tried it mike? (Score:1)
pff
Re:have you tried it mike? (Score:1)
Re:have you tried it mike? (Score:2)
Are there no new speed enhancements... (Score:2, Insightful)
Re:Are there no new speed enhancements... (Score:4, Informative)
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.
Re:Are there no new speed enhancements... (Score:1)
Re:Are there no new speed enhancements... (Score:4, Informative)
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)
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.
Re:Are there no new speed enhancements... (Score:2)
It would be nice if xkill did kill the window owner's process, but with Konq, for example, it does not appear to.
Re:Are there no new speed enhancements... (Score:2)
Re:Are there no new speed enhancements... (Score:2)
Doesn't data aware widgets break the mvc paradigm? (Score:1)
Re:Doesn't data aware widgets break the mvc paradi (Score:2)
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.
kpf - web server applet: please don't (Score:1)
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...
Re: kpf - web server applet: please don't (Score:2)
Re: kpf - web server applet: please don't (Score:1)
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.
Re: kpf - web server applet: please don't (Score:3, Insightful)
Re: kpf - web server applet: please don't (Score:1)
This I think is really great and can help to spread Linux and KDE between more users. Another thing would be if this option will be by default on and will have security troubles.
Re: kpf - web server applet: please don't (Score:2)
Re: kpf - web server applet: please don't (Score:2)
Re: kpf - web server applet: please don't (Score:2)
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.
Re: kpf - web server applet: please don't (Score:1)
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.
Re: kpf - web server applet: please don't (Score:3, Informative)
Re: kpf - web server applet: please don't (Score:3, Informative)
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)
RikRe: kpf - web server applet: please don't (Score:2)
do you plan to implement webdav and do you know if there's a corresponding client for kde? Can konqui handle it?
hardware-accelerated alpha blending?! (Score:2)
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)
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?
Re:hardware-accelerated alpha blending?! (Score:1)
To optain a truely transparent terminal, when an area of desktop, or a window changed it's contents, X would have to repaint all the windows above that area or window, which previously would have been something that X deliberately would not have done (since it would have been pointless).
I don't think that the render extension changes anything fundamental about X, just provides an extension that applications can use to speed up certain things.
Though I could be wrong, since I have not really read much about it.
Re:hardware-accelerated alpha blending?! (Score:2)
Does that mean it could be possible to have a truely transparent terminal?
Yup - see the bottom of this page [xfree86.org]. Now, I *am* curious as to how fast this is in a real world system. And knowing how KDE works right now, it will porobably be easy to turn on and off (like current font and icon antialiasing), both explictly, and in a warm, fuzzy "Quality slider".
--
Evan
intrested in C bindings (Score:2)
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
Re:intrested in C bindings (Score:2)
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!
Re:intrested in C bindings (Score:2)
(*) "What You Mean is What You Type"
Gnome User (Score:2)
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)
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
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.
Re:Gnome User (Score:1)
With a working mac-style menu bar like KDE does, eh?
debian 2.3? (Score:2, Informative)
"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/
Re:Gnome User (Score:1)
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)
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...
Re:Gnome User (Score:1, Informative)
if still like sawfish, you can use it with > KDE 2.0. sawfish is fully compatible with the NETWM spec which GNOME 1.4 has recently adopted and KDE has since 2.0. I've used sawfish in the past too, but I gotta say that kwin simply r0x0rs.
Re:Gnome User (Score:1)
Re:Gnome User (Score:4, Interesting)
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)
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.
Re:Gnome User (Score:1)
Which is why it has been rewritten for Gnome 2.0
Re:Gnome User (Score:2, Interesting)
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
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
Re:Gnome User (Score:2)
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...
Re:Gnome User (Score:1)
Re:Gnome User (Score:2)
Even more interesting: this is actually a complete remake of the file selection from Microsoft Office 2000.
Re:Gnome User (Score:4, Informative)
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. :-)
Re:Gnome User (Score:2)
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)
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.
Re:Gnome User (Score:1)
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)
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
Re:Gnome User (Score:1)
Re:Gnome User (Score:1)
Alpha blending (Score:1)
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?
Re:Alpha blending (Score:1)
Re:Alpha blending (Score:1)
kcontrol->Icons->blend alpha channel
Currently, it uses software rendering to do it (Konq. seems a lot faster than Nautilus). KDE 3 will use xrender to do it, which will be hardware accelerrated (and so, there will be no performance hit because the video card handles it instead of the CPU).
Re:Alpha blending (Score:1)
Those shadows and true transparency in Terminal are my favorite pieces of eye candy on that OS.
Re:Alpha blending (Score:2, Informative)
"Just as unstable as Windows" - Ballmer (Score:1)
from the developers-developers-developers [detonate.net] dept.
Don't get me wrong but... (Score:1)
Re:Don't get me wrong but... (Score:1, Interesting)
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].
you're right, but use Afterstep (Score:1)
Re:Don't get me wrong but... (Score:2)
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.
Re:Don't get me wrong but... (Score:1)
Some Konqueror Updates Would Be Nice (Score:1, Interesting)
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.
Re:Some Konqueror Updates Would Be Nice (Score:1)
Here come the next minor releases of every distro (Score:1)
it seems KDE is falling behind (Score:2)
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?
Re:it seems KDE is falling behind (Score:2)
Re:it seems KDE is falling behind (Score:5, Informative)
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.
Re:it seems KDE is falling behind (Score:3, Insightful)
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
Re:it seems KDE is falling behind (Score:2)
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.
Re:it seems KDE is falling behind (Score:3, Insightful)
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.
Re:Java Garbage Collection vs. C++ destructors (Score:2)
Not at all. On some problems, manual storage management is faster, on many GC is faster.
the run time of a program that uses it becomes less predictable,
The only real-time, predictable dynamic memory management systems I have ever seen have been based on garbage collection. Theoretically, it's possible to implement real-time, predictable manual storage allocators, but nobody ever seems to.
and because it blurs the point at which an object is destructed releasing other resources (like files) becomes problematic.
Resources whose release has externally visible effects should be released manually, with safety checks. Unreferenced memory is a special case because it can be freed without any effect on the program and because checking access to it is too expensive.
Oh, and C++ has had reflection (aka RTI) for some years. It is an add on - just like it is for Java
C++ RTTI only gives you "instanceof". Java reflection gives you access to fields and methods (and it's not an "add on").
Huh?? (Score:3, Informative)
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)
Re:it seems KDE is falling behind (Score:4, Interesting)
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.
Why offtopic? (Score:1, Offtopic)
WHY?
It's about KDE. Absolutely ON topic...
I post this using my own nick because I'm stuck at +50 and need someone to mod me down...
Re:GNOME _is_ obsolete (Score:1, Offtopic)
When KDE was in transition from 1.1 to 2.0, a lot of people assumes that there was very little work going on, when in fact (as we now know) they were almost completely rewriting the core libraries. A similar thing is happening with Gnome -- and it's very hard to show people what you are doing until the main libraries are 90% complete. So lets give the Gnome guys a chance and see what they produce.
(the only thing I'm waiting for to make me happy is for Lyx 1.2 to come out so I can finally get rid of that xforms library...)
Re:Time to drop Gnome? (Score:1)
I doubt having them both is hurting anything, people developing for GNOME probably are wanting something else out of a desktop than KDE and vice versa. So I doubt that killing one project would mean all those developers would jump ships.
I think instead we should be trying to make the fact that two desktops exist just a trivial thing. Make them share stuff like application menus, desktops, etc. Another thing I'd really like to see is a common theme format, so the programs would look alike, although I doubt we'll ever see that.
Re:Great, just what we needed (Score:5, Informative)
> very slow to compile
use
this reduces compile times by more than half, in my experience
> and load.
Use objprelink.
> but the point is that KDE is a hell of a lot slower than GNOME.
From what? Load times? Look at other big applications written in C++ and compiled in g++, like Mozilla and OpenOffice. They tend to load slow too. If you actually look at speed of applications, KDE wins hands down. Konqueror versus Nautilus. Konqueror wins. KOffice versus StarOffice/OO, KOffice wins. Other components tend to be around the same speed.
> So, from my perspective, which is not that of a compiler designer, GNOME is a lot freaking faster than KDE.
Yeah, "ordinary users" don't even compile KDE or GNOME.
Re:Flamebait (Score:1)
How about KOffice, it is a more pleasant to work with than OpenOffice, and does not take the route of Microsoft's add-features-that-1%-of-the-population-uses way of developing Microsoft Office. Also, it actually features integration with the underlying desktop, unlike OpenOffice.
> add some SVG boys, KDE is starting to look butt-ugly:
> http://jimmac.musichall.cz/screenshots/e-sync.jpe
KDE already has SVG support in two different implementations. KDE's own and Qt's.
Also, I have yet to see transcluesent menus like in KDE:
http://www.mosfet.org/hpl1.png
KDE -- the desktop that doesn't have to continuously play catchup
Is it that, or they just don't have time... (Score:2)
Re:KDE. (Score:2)
A simple wrapper around one would only lead to a mess similar to Microsoft's MFC, which started out as a wrapper around old procedural windows APIs. Anyone who has used MFC knows the evils of such wrapper APIs.
Objprelink? WAS:Re:Rock solid? (Score:2, Interesting)
Greets,
Anno.