KDE 3.2 Release Candidate 1 Debuts
danalien writes "Before a early Feb. release of the (stable) KDE 3.2, KDE has today announced the first 'Release Candidate', and hopefully the last pre-release, for its 'Open Source graphical desktop environment for Unix workstations'. Get it from download.kde.org, or use Konstruct if you don't feel like calling configure by yourself."
Remeber the mirrors http://www.kde.org/mirrors/ftp.php Rus
CPanel + Root from $35/mo - 10% off with discount code SLASHDOT
KDE 3.2 Feature Plan
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
Request are taken, just send me an e-mail, any program, or theme can be snapshoted
As Usual, KDE ROCKS
I'm positive, don't belive me look at my karma
If you have ever worked or contributed in any way to a KDE project / KDE application, then you get some idea of just how dedicated the key people are. My own opinion of this phenomenon is that developers know (feel) that KDE is the best desktop suite we have, and we want it to be better. Also, with tools like QT Designer, and KDevelop, making applications for KDE is actually quite a pleasant experience (and this is from someone who loathes GUI programming). Well done chaps !
"I am not bound to please thee with my answers" [William Shakespeare]
I've been running KDE 3.2 built from CVS on 2004-01-14 for a week and so far, so good. This release should be nice. Now waiting for an ebuild...
It's a bit faster. I wish it would be much faster. But generally when this happens I reboot in XP for a day, then I realize that speed isn't all that counts. Prelinking helps, too.
I think I'll delete KDE 3.1.x entirely, since there is no need for it anymore.
-- Home is where you eat your heart out.
KDE does not run only on Linux, it also runs on the BSD's, Solaris, and (just recently and still in development) Mac OS X.
Liberal (adj.): Free from bigotry; open to progress; tolerant of others.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
People are trying to do just that: http://kde-cygwin.sourceforge.net/
#include "sig.h"
i've been using KDE3.2 built from source since the early alphas. even then it was rock-solid stable with just a few rough edges. once i knew all of the workarounds, i migrated my production/work environment up to 3.2 as well, for the cool/useful features. highly recommended upgrade.
Sorry 'bout that.
That particular poster just plagiarises other people's posts to get karma I guess. He posted another one earlier also copied from months ago. Rather sad really, poor guy probably never had an original thought in his life.
What about K3B, Quanta+, eric3, and scribus? There are tons more great KDE apps at the new KDE-Apps.org. The future of KDE application development looks bright. Remember that you're comparing KDE apps against the complete set of all other open-source applications. I think KDE is doing pretty well, myself.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
Um... No, it doesn't. GNOME uses GTK. GIMP uses GTK. That's how they're related.
/usr/lib/libgtk-1.2.so.0 (0x4002e000) /usr/lib/libgdk-1.2.so.0 (0x40139000) /usr/lib/libgmodule-1.2.so.0 (0x40169000) /usr/lib/libglib-1.2.so.0 (0x4016c000) /lib/libdl.so.2 (0x40191000) /usr/X11R6/lib/libXi.so.6 (0x40195000) /usr/X11R6/lib/libXext.so.6 (0x4019d000) /usr/X11R6/lib/libX11.so.6 (0x401ac000) /lib/i686/libm.so.6 (0x4028b000) /lib/i686/libc.so.6 (0x402ad000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ ldd `which gimp`
libgtk-1.2.so.0 =>
libgdk-1.2.so.0 =>
libgmodule-1.2.so.0 =>
libglib-1.2.so.0 =>
libdl.so.2 =>
libXi.so.6 =>
libXext.so.6 =>
libX11.so.6 =>
libm.so.6 =>
libc.so.6 =>
$
No GNOME libraries there. Compare it to the output of:
ldd `which gedit`
and you'll see what I'm talking about.
STOP . AMERICA . NOW
GTK+ - GIMP Toolkit. The widget toolkit used by GNOME.
Glib - GNOME utility library. Contains useful stuff like lists and hash maps.
Bonobo - Component toolkit to allow embedding of applications in other applications.
And before anyone flames, I've simplified, I know. But I have no idea of what the programming skills are of the parent poster.
Probably because some moderators feel that QT isn't "so much easier to code in than GTK/GTK+/Glib/Bonobo that it isn't funny". While some people may feel that way, others don't. If you're a moderator, and you see someone making a blanket statement, expressing opinion as fact, and you disagree with them, you're likely to mod them down.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
And now try:
/usr/local/lib/libgimpcolor-1.3.so.24 (0x00c13000) /usr/local/lib/libgimpmath-1.3.so.24 (0x00b0f000) /usr/local/lib/libgimpbase-1.3.so.24 (0x00c21000) /usr/local/lib/libgimpmodule-1.3.so.24 (0x002a0000) /usr/local/lib/libgimpthumb-1.3.so.24 (0x00506000) /usr/local/lib/libgimpwidgets-1.3.so.24 (0x0088a000) /usr/lib/libgtk-x11-2.0.so.0 (0x0061f000) /usr/lib/libgdk-x11-2.0.so.0 (0x00111000) /usr/lib/libatk-1.0.so.0 (0x0017e000) /usr/lib/libgdk_pixbuf-2.0.so.0 (0x005f3000) /lib/tls/libm.so.6 (0x00b3a000) /usr/lib/libpangoxft-1.0.so.0 (0x00371000) /usr/lib/libpangox-1.0.so.0 (0x00198000) /usr/lib/libart_lgpl_2.so.2 (0x001d1000) /usr/lib/libpangoft2-1.0.so.0 (0x00d0b000) /usr/lib/libpango-1.0.so.0 (0x001e7000) /usr/lib/libgobject-2.0.so.0 (0x003c4000) /usr/lib/libgmodule-2.0.so.0 (0x00394000) /lib/libdl.so.2 (0x00b5e000) /usr/lib/libglib-2.0.so.0 (0x00219000) /usr/lib/libfontconfig.so.1 (0x00db5000) /usr/lib/libfreetype.so.6 (0x00caf000) /usr/lib/libz.so.1 (0x00c53000) /lib/tls/libc.so.6 (0x00ddc000) /usr/X11R6/lib/libX11.so.6 (0x003f7000) /usr/X11R6/lib/libXrandr.so.2 (0x001a5000) /usr/X11R6/lib/libXi.so.6 (0x001c7000) /usr/X11R6/lib/libXext.so.6 (0x00c43000) /usr/X11R6/lib/libXft.so.2 (0x00d81000) /usr/X11R6/lib/libXrender.so.1 (0x00d01000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x009e7000) /usr/lib/libexpat.so.0 (0x00d5f000)
ldd `which gimp-1.3`
libgimpcolor-1.3.so.24 =>
libgimpmath-1.3.so.24 =>
libgimpbase-1.3.so.24 =>
libgimpmodule-1.3.so.24 =>
libgimpthumb-1.3.so.24 =>
libgimpwidgets-1.3.so.24 =>
libgtk-x11-2.0.so.0 =>
libgdk-x11-2.0.so.0 =>
libatk-1.0.so.0 =>
libgdk_pixbuf-2.0.so.0 =>
libm.so.6 =>
libpangoxft-1.0.so.0 =>
libpangox-1.0.so.0 =>
libart_lgpl_2.so.2 =>
libpangoft2-1.0.so.0 =>
libpango-1.0.so.0 =>
libgobject-2.0.so.0 =>
libgmodule-2.0.so.0 =>
libdl.so.2 =>
libglib-2.0.so.0 =>
libfontconfig.so.1 =>
libfreetype.so.6 =>
libz.so.1 =>
libc.so.6 =>
libX11.so.6 =>
libXrandr.so.2 =>
libXi.so.6 =>
libXext.so.6 =>
libXft.so.2 =>
libXrender.so.1 =>
libexpat.so.0 =>
It's a little bit more, gimp 1.2 is going to outdated soon, so gimp 2.0 would be more valid for your comment
Signature Pro version 1.13.2-3 release 83.5 beta3try7 after-breakfast edition
Many of the weekly CVS digests include merged changes from Apple. While I have no idea how many have been merged, a great deal have, and I would venture to say that the Safari team has been very helpful.
Texstar is busy building PCLinuxOSe x.html
http://www.pclinuxonline.com/pclos/ind
Preview 5 should be available any day now.
Go Texstar!!!
Can someone please explain what KDE is. Apparently it's not a window manager... So what is it? (I haven't used Linux since the days of fvwm.)
Don't take him so literally though (about his grandmother), he is trying to make a point: In order to make it on the desktop, Mr/Mrs. Average Citizen needs to be able to install and/or upgrade things, even as complex as kde, without a hassle. The thing is, Linux is not there yet, but it will be if folks as dedicated as the KDE team seem to be keep doing what they're doing. What will hold it back are the people who get in a huff when people point out the real need to make it easy for the average user.
No-one is taking your command line (and all the power that it has) away from you. vi will always be there. :-) But the great unwashed masses out there would rather things be easy so they can use most of their time using the software, and not configuring it, and certainly not learning to configure it. If it is so complicated they need to study, they won't use it, and the idea of Linux on the desktop will fail. Windows didn't become popular because IT profesionals recommended it. It became popular because the accountants and other business users understood it, used it at home, and wanted their companies to purchase a tool that they could use easily without requiring too much training. Don't get nasty about this, it is true. It is one of the reasons MS makes so much money. It is a system that has a very low learning curve. I think with the great new Linux install packages that come with most of the major distributions (e.g. Suse, Mandrake, Redhat), things are moving that way, and will continue to do so... it's just a matter of time. Rome wan't built in a day (and all that).
My criticism here is (trying to be) constructive criticism... from someone who likes Linux (and has used it for several years) but also is frustrated with sometimes spending more time installing and configuring things than being able to use them (part of the reason is that yes, I am trying things that most desktop users wouldn't need to do). For example, I would like to be able to install the latest version of MySQL (their binary at their advice) without it telling me that an rpm installed on my system is not the right version... causing me to research how to complete the installation. It may be a surprise to some that I would actually like to program something with it, and learn the new features of the latest release, without waiting for a new distro... and not necessarily on how to install it. Same goes for KDE (and I do prefer KDE over other Linux desktops). The MS advantage that people talk about is that you can install a new version of most software without worrying about getting version errors, or errors reporting that your rpm package is not correct... Mind you, I don't like MS's corporate practices so I keep trying to stick to Linux... and it is sometimes a trying experience.
Perhaps if there could be a way for rpm type installs (or others) to check 'levels' instead of just version numbers. If you have a level that supports a set of public API's you could set up a system where even if a different version is out, as long as the standard API's still exist, then all is well. So you could have version 1.0 and version 1.1 both able to meet API level 1. i.e. You might have changed the internal workings of a function (for security or whatever), thus creating a new version (which might tell you if the correct security patch has been applied), but you wouldn't get screwed up on dependancies when installing a package when it looks for the older version of whatever library it needs. It would check the API level, see the correct one, even if the vers
-- I ignore anonymous replies to my comments and postings.
Debian unofficial experimental packages here
/ un stable/
http://www.cs.uni-magdeburg.de/~aschultz/debian
my blog
I think that's because Konquerer is not just a hardisk file browser, but a more generalized browser that is network transparent. You can browse local stuff with location file:/xxx, remote stuff with ftp://xxx or a webpage with http://xxx, and more...
Commercial software does not always have to be closed source. You could develop a GPL application with commercial uses (you could even sell it), and still use the free QT under the GPL. It's a common misconception that commercial software has to be closed source / proprietary.
For instance, MySQL could bundle a QT-based query analyzer with their product, since MySQL is also GPL. That doesn't stop it from being sold and supported as a commercial product. Now, if they want to sell a version of MySQL that is under a non-GPL license, then they'll need a commercial license. But those are the rules.
KDE/Qt isn't any more monolithic than GNOME/GTK+. All the stuff that GNOME has as completely seperate libraries (libxml, etc) are seperate modules of Qt.
I think the "KDE is monolithic" viewpoint arises from the excellent integration between KDE applications and the desktop. Because they all operate as though they're a single, large piece of code, people assume they are. Ironically, it's the modularity of the code base that makes such seamless integration possible for a distributed development team.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
"The main idea remains that the idea of gnome was to to reuse as much stuff as possible (even when it shouldn't have), while KDE wrote much of these "from scratch" and has its stuff "more integrated" (just think about window managers)."
Actually...
According to Stallman and the GNU project, the idea of GNOME was to write a desktop to specifically replace KDE. The idea was that QT was not 100% free at the time, and the GNU project saw KDE's popularity as hurting the goals of the GNU project's operating system vision. So they started 2 projects: one to create a free replacement for QT, and another to create a replacement for the already free KDE. Since QT was GPL'd, the free replacement project was killed. But the GNOME project was already started and the developers decided to keep on working. In the process, GNOME made different choices on many aspects. Choosing to use CORBA to do their component technology was just one of the many different (than KDE's existing technology) choices the GNOME project chose. It just turns out that CORBA/bonabo (the Network Object Model part of GNOME) never got incorporated into many GNOME applications, and so now GNOME applications == GTK/glib applications.
When you think of the GNOME project, you should think of turning a primitive incomplete widget toolkit (the Gimp ToolKit) into what GTK+ is today, plus a set of applications which use this toolkit, plus guidelines on how these applications should behave. When you think of KDE today, you should think about the same things, but using already developed QT insted of GTK+ along with the ability to embed current applications into new ones efficienatly.
None of this has anything to do with KDE wanting to re-write everyting. In fact, they started with existing complete QT. and GNOME started with an incomplete GTK toolkit. The GNOME project is basically the GTK+ project combined with application rewriting with GTK+. So which project is the one that did the massive rewrites? I think that would be GNOME.
If you consider writing a program using GTK+ widget set and glib a GNOME application, you probably don't know the definition of Network Object Model Environment. (Hint, several KDE applications use such features, but most "GNOME" applications don't use bonobo.)
Two infinite things: your stupidity and mine. But I'm not sure about the latter. If my sig offends you, I'm sorry.
http://kde.ground.cz/tiki-index.php?page=Screensho ts