After some delay caused by a severe hardware failure on KDE's ftp server,
the KDE Project has announced
the official release of KDE 2.2. This release brings a lot of goodies,
including: faster startup times (using the experimental
objprelink
method) and performance; numerous improvements to HTML rendering
and JavaScript support; the addition of IMAP support (including SSL and
TLS) to KMail; a new plugin-based print architecture with integrated
filter and page layout capabilities; a number of new plugins for Konqueror
(including a Babelfish translator, an image gallery generator, an HTML
validator and a web archiver); native iCalendar support in KOrganizer; and
a new personalization wizard. Compaq
has also announced the addition of KDE to
Tru64. Time to tell the boss to forget XP, and use KDE (hmmmm, back in my college days that would have made a nice chant: 'Forget XP, use KDE', . . .).
KDE 2.2 Ships (Visit an FTP Server Near You)
Dot Categories:
Comments
Its a KDE module like kdebase...etc
Just grab the rpm.
q
Those screenshots sure are beautiful. It seems the graphics artists have been working every bit as hard, and producing every bit as good a result as the coders, and that certainly proves a lot about the graphics artists!
Everyone involved in making KDE 2.2 deserves every positive comment they receive for their incredible work, and surely a lot more than that too! Too bad there aren't enough people in the world to think of enough superlatives. :)
In summary: I wish I never have to see that horrible redmondian user interface (what's it called by the way?) again. This release surely makes me confident that this wish might actually come true quite soon. You guys rule my computing world.
thanks for the screenies.... i do have a reason to d/l and show off to my XP-is-better-than-your-linux-crap friends...
Cool screenies... just a quick question:
It's obvious AA is enabled, so why is the 'Welcome to KDevelop' a jagged? Is that the way for all KDE help/intro screens?
--BN!
No, something must be wrong with Type1 fonts on that system. Usually that title is smooth.
Ok, when I tried 2.2beta alot of stuff failed and alot of stuff was missing. Can someone tell me the correct order / instructions on installing the RPM packages? And do I still need the kdesupport rpm? Where is it? Oh, and one more question: in the SuSE ftp directory they have a subdir called experimental which contains kdelibs, kdebase and something else (i forget) I'm assuming these rpms in this 'experimental' directory are the ones that feature the prelinking fast startup capability. Am I right? Thanks to the developers, you rock!
On SuSE 7.1 I had the same problems as mentioned above, installation failed because of missing libs etc.
That was when using the "rpm -i" or "rpm -U" command. So I tried using Yast, which has in the Software-Installation Part a possibility to Install Packages. There it works just fine.
Thanks for the tip; did you use YaST1 or YaST2?
There are perhaps cyclic dependencies so there is no "correct order", simply pass all rpms at once as argument to 'rpm' when installing. kdesupport doesn't exist anymore, just install the missing dependencies as indiviual rpms like that for libxml and libaudiofile.
Ok, typing:
rpm -Uvh *.rpm
from a directory with all of the rpm's did not report any errors, and seemed to work ok. After a while I noticed some things were not working, and checked:
rpm -qi kdeaddons
which reported "...not installed."
So I had to go through and manually install the remaining packages individually.
Shouldn't the first command have installed everything?!
Thanks,
Matt Fago
yes, maybe your rpm database is corrupt.
try a rpm --rebuildb
Yea, that's the first thing I tried. No effect. Odd.
Well, it took ages to compile KDE 2.1.1 on my FreeBSD box. Now KDE 2.2 has just come out :-)
I wonder if there are any FreeBSD native packages...I used to use Gnome 1.2, but they've been on Gnome 1.2 for ages, and I couldn't upgrade to Ximian Gnome (compile errors). Noone else seems to be interested in getting the latest Gnome up and running for FreeBSD !! Well, that's fine. They've definitely lost my market share. KDE 2.1.1 compiled fine. Has anyone had any luck compiling 2.2 for FreeBSD, and/or are there any packages for it ? I'm running 4.3-RELEASE
It's linked to from the announcement.
http://master.kde.org/pub/kde/stable/2.2/FreeBSD/
Hello, I posted this on slashdot too but i think it's better to write it here.
There used to be a Icon theme online manual on
http://www.mosfet.org/themeapi
but mosfet removed that one :-( I want to make such a theme for kde 2.x but I could nowhere find a manual and themes.org manual seemed outdated.
Hi,
If you are interested in creating a new style (not pixmapped, but coded), you should look at the tutorial at this URL :
http://www.geoid.clara.net/rik/knowledge.html
It's written by Rik Hemsley btw.
Have fun.
...to see that the most of the posts are dealing with problems with RPMs. Why don't install from source or use .debs instead? :)
Loranga, a.k.a Mats
well,
1) most don't have a debian or a fork of debian
2) compiling from source is hard and slow for some.
3) i compiled mine!
For those who asked for them, plenty of screenshots are coming, but q threw some together a few weeks ago to show some of the newer features, and I quickly threw them up on this temporary site for convenience -- the text needs fixing and all that, but it's still good to get a quick idea of some things that have changed.
Be patient though, I hear a lot more cool stuff is coming!
I like your wallpaper in the screenshots. Where did you get it?
Note that these are not my screenshots, they're q's. :-)
I believe this screenshot is distributed with KDE 2.2. Probably in kdeartwork if it's not in kdebase.
Later,
-N.
Hmmm... it seems I don't have it (?). By chance, does someone have the filename of that wallpaper available? I wonder if I am missing a kdeartwork package...
default_blue.jpg
Which of these *nice* window border decorations are shipped with KDE 2.2? Everyone except Liquid?
The decoration of shot 1 is not the Liquid one but an IceWM-Theme. All others are shipped.
Well that's just great! Now I hope that all major distributions will include the 'kdeartwork' module. Because it makes Linux attractive, in the true sense of the word.
I liked snapshot9 the most because it shows that you can have another type of digits in the digital clock than those usual ugly ones. :)
Finally Konqueror performs nicely on my slow computer (a measly P60), the GUI no longer becomes completely unresponsive when opening a website and images are displayed faster.
In the past using Mozilla on a Pentium 60 with 98 RAM was a more pleasurable browsing experience than with Konqueror. I'm glad to find that has changed since KDE2.2.
Thank you :)
Oh, by the way.. there was some mention about http pipelining. How would this affect performance and when will this be implemented in Konqueror (or is it already)?
I was pretty excited about the whole new printing thing, but now it seems that the Redhat RPMS for KDE2 don't recognise the fact that CUPS is installed. I know this isn't the Redhat standard print daemon (it should be IMHO), but wouldn't it be better to cover all bases.
Plus I have say that KDE 2.2 on RH7.1 seems unstable compared to 2.1.1/2. I've had a few total resets back to KDM since installing it yesterday.
I can finally pay my bills in Konquerer though ;-)
Well, I've got the same problem under Debian Woody; I installed KDE 2.2 form the Sid tree, then decided to upgrade to XF86 & Cups from Sid, while I was at it.
When I tried to test the printing, 2.2 could not see CUPS as one of the underlying printing engines (? hmmm, can I say that?).
No stability problems with KDE 2.2, though. It's just the printing that's not working.
I rebuilt the kdelibs RPMs for Redhat from the src.rpm file, and the configure script detected the presence of CUPS on my system and it now supports it. The missing file was called:
/usr/lib/kde2/libkdeprint_cups.so
I'm still having problems printing to one of our printers - it complains about "imagetops", I think that might be a local configuration problem however (although it works every other way I use it).
Imagetops is a small utility included in KDE-2.2. So again it seems to be a package problem.
Michael.
Did you install the kdelibs3-cups package. It contains the CUPS plugins for kde.
tix.64
No, I did not. Missed that one when I was installing the myriad of debs necessary for KDE 2.2 (man, if there was a good example for the need for KDE installer, that is it).
I did that and now KDE 2.2 can now see CUPS as one of the underlying printing engines. The only problem is that when I try to define a remote LPD printer (my printer is attached to my DSL gateway/firewall box that serves also print-server duties. It's running a two-floppy hybrid of Coyote Linux & Charles S.'s EigerStein LRP Linux that I haphazardly (sp?) cobbled up), the control centre segfaults. Every time. And only for remote LPD queues.
Did anyone else encounter that? I tried upgrading libc6 et al from Sid, to no avail: I still get segfaults on that.
Thanks, adding that kdelib3-cups file worked.
Though I wonder why Debians dselect did not pick that up?
Anyways thanks much,
Al
To have CUPS support in KDE, CUPS must be present at compile time. So it's more a packager problem. As CUPS is not the standard print spooler under RedHat, I'm not really surprised by this problem. The solution would be to have a separate kdelibs-cups package to include all CUPS-related stuffs. But this is a RH-packager issue.
Michael.
Look O' KDE developers, maintainers and project Leaders!
Again its rpm vs source headache for your KDE users. Missing dependencies, and many such troubles just to get our favourite Desktop Upgrade.
Remember, You people Promised KDE-Installer right in the HELP of KDE 1.1.2? Even After 1-2 years where is it??? No KDE installer yet and no relief to your users from upgradation troubles.
Just kick-off RPMs, DEBs, etc., and use generic + distribution dependent binaries (excuse the sources for now) like Netscape, Adobe Acrobat, Corel Wordperfect, StarOffice, and ... to Install and Upgrade KDE (making it more user friendly).
When these Non KDE people can develop packages generic and functional on any Linux distribution, why can't KDE yet have this capability or technology??? I can use adobe acrobat painlessly in SuSE, RedHat, Mandrake, etc., installed from one acrobat-4.0-tar.gz (binary) with an installation script.
I am not talking Unix specific installer, but KDE is by Linux, for Unix and of Linux/Unix.
I have to allege that you are denying our basic right of getting upgrades quicker and you are giving us trouble by only providing sources.
Please for goodness sake and for the unity of Linux distribution, create KDE installer and don't force KDE lovers to use Mandrake/SuSE just because they like different distros like Caldera, RedHat, Turbo Linux, etc.
I have to complain because it gives me lot of pain and anguish just to upgrade the next version of my lovely KDE on my RedHat (latest). Don't you feel the trouble we are going through all the time (well every six month ;).
This complaining about RPMs not working is pointless when you direct them at the developers. The don't package them, the write the code and put it in nifty little things of only source. It is up to a maintainer to create the packages for specific distributions (ie RedHat, SuSE... ). Please don't complain to the KDE developers for poor packaging. It isn't them.
And as for the binary install from a tarball, it can be easier said then done. Several distributions don't place the files in the proper places, probably the biggest violator being redhat. You can get rid of the dependencies and all with tarballs, but each system expects KDE in a different place. Scripts help, but then there is no promise all dependencies are satisfied. There is a solution. First get the source and spend the time to make it yourself. Second try other distributions. I have used many and SuSE always seems to work with the RPMs. They also place them in the correct locations on the disk. Ask for help on how to get RPMs to work is fine. Bashing the KDE team is not right when it comes to the RPMs.
Aside from that, thanks to the KDE team.
Entigo
We have KDE-Installer but in its ALPHA stage, which works (I guess) on Debian, RedHat, SuSE, Mandrake, and even on FreeBSD.
Please visit:
http://kdeinstaller.rox0rs.net/news/feb01/distroinfo.html
But if few or just few KDE developers give a very little time of their coding to improve this *Essential Application*, then we won't have any problem for upgrading and installing KDE on any flavor of Linux!
I love KDE team and developers, and I don't dare say anything bad to them! :)
Hope you understand that it's not about RPMS or DEBS or tar.gz's or RedHat or SuSE or Mandrake but it (topic) is basically about KDE upgrade trouble caused on every new release of KDE and the users (many, excluding me) are bothered by this trouble. And the will of KDE team before KDE 2.x to ease the upgrade process.
If KDE has an installer, I hope it´s better than ximian. I tried the Gnome1.4 for SuSE7.0
Downloaded 70mb in 3 hours and nothing worked.
Even all gtk-apps didn´t work in KDE.
So if a KDE-installer comes, then please provide an installer that knows all the distributions, knows the shipped compiler, & compiles all packages automatically, after resolving dependencies.
Go on with your great work.
I´m still downloading the 80megs with my 64k-isdn with Webdownloader 4 X 1.27 :-(
"I have to complain because it gives me lot of pain and anguish just to upgrade the next version of my lovely KDE on my RedHat (latest). Don't you feel the trouble we are going through all the time (well every six month ;)."
pain and anguish, come on people, the KDE developers are working their collective tails off for you for free and you have the nerver to complaing that its too hard to type 3 lines:
./configure
make
make install
it isn't rocket science.
in fact it can be cut down to 2 lines for those that have a little knowledge:
./configure
make all install
voila, do that in each directory of the source and you are done.
I have always used source to upgrade, in fact I upgrade all the time from the CVS tree. Never had a problem, and all my libs are enabled, including that pesky copyrighted mp3 lib.
So give the developers a break, this arguement is old, and most of the true KDE lovers don't want the delevelopers wasting their time with the distribution portion. If your binary packages don't work complain to the author of the package not to these wonderful people.
I hate to rant but this is ridiculous, every time there is an upgrade we hear the same people with the same complaints, if you don't like it create your own solution or use something different.
WWarlock
> I hate to rant but this is ridiculous, every time there is an upgrade we hear the same people with the same complaints, if you don't like it create your own solution or use something different.
Yes, I agree with you, but isn't my question of KDE-Installer which is still in Alpha stage and not seen any boost from March 2001 be released which helps install KDE on Debian, RedHat, Mandrake, SuSE and even FreeBSD. I feel sorry that I couldn't learn KDE programming; and there are many users who are non-programmers and hence can't contribute to KDE by algorithms.
I wish that some of the best developers (we have all the best ones) gives few hours to KDE-Installer improvement or say development then these _stupid_ complaints won't appear in future on every KDE release and Our busy developers don't have to listen to these irritating complaints regarding rpm, deb, tgz, etc.
Regarding the compile from sources, I did that too:
when I ran "rpm --rebuild kdelibs-2.1.1.src.rpm", I slept and woke up it took 3 hours to get only 1 package get compiled, could you expect everyone or say anyone to waste this much of time 15-20 hours just to get KDE upgraded. I guess this will discourage KDE user.
I appreciate KDE developers for creating such a great Desktop environment painstakingly and giving to others for free, but does that mean creating it with hardwork should also mean getting it with hardwork? I guess no!
> So give the developers a break, this arguement is old, and most of the true KDE lovers don't want the delevelopers wasting their time with the distribution portion.
KDE-Installer is distribution independent regarding installing part (it will choose appropriate packages and dependencies to install/upgrade) please visit: http://kdeinstaller.rox0rs.net/ for more info.
I feel that if fully functional (non-beta/stable) KDE-Installer is provided by our KDE team as a base package then the trouble is over (almost).
I find it ironic that KDE, whos goal is to build an *easy to use* and *graphical* user interface, yet requires you to go into *big trouble* of installing and upgrading it and/or knowledge of *commandline* tools and CVS use.
If you build a commandline software, then require commandline to install/upgrade. Perl is a good example of a very user friendly commandline installer/ugprader(CPAN.pm). In KDE's case they have to focus on a graphical interface. Be it just a basic interface to the commandline with three buttons (CONFIGURE/MAKE/MAKE_INSTALL) to install from source; or a more advanced interface. It doesn't matter.
Moreover, if I have already installed KDE 2.1.1 on some Linux distribution, upgrading to 2.2 should be one click. All the configuration details should be there since I already have an old version installed.
>> yet requires you to go into *big trouble*
KDE does not require *you* to do anything - they require the distro/OS provider to provide KDE through normal update channels. If that's a graphical icon labeled "Updates" on your desktop, then that's what you do. If it's a .tgz package that you must "tar zxvf", that's another.
Anyone who has a graphical apt-get front end, for instance, points and clicks to update. Is that what you're looking for? Get a different OS or flavor of that OS.
--
Evan
Don't tell me that KDE require you not to install KDE by yourself but wait for the distributions.
Precisely. KDE does not do any packaging. It is up to the distros to do so. Who would you rather have doing the packaging: someone who is making packages for a dozen distros, or the people who developed the distro?
--
Evan
Read my original post. It is not about packaging. It really doesn't matter. You need open your eyes and improve your vision. If you and other KDE guys keep repeating the same thing there is no need to discuss anything.
As I said, it doesn't matter. Be it installing from sources, using CVS, some special KDE packaging, etc. etc. it doesn't matter. It should have a graphical interface with user friendly on screen help. If you ask people to open README.txt, INSTALL.txt, etc. simultanously read all of them and execute command line files, edit some conf files, and other non-sense; and if you are KDE who aims to become a user friendly GUI; it doesn't make sense to me.
I'm afraid that over 95% computer users already use "something different" and it will be 100% soon if you keep answering to all that asking for help and complaining is "ridiculous" or "create your own solution".
I think that those posts are also read by packagers.
I absolutely agree... the original poster (Asif Ali Rizwaan) made a some good comments, particularly about the ability of Netscape, et al. to deliver a (mostly) distro-independant product.
Why is this not possible? At least in part. I can understand the need to possibly build the kdelibs as distro-dependant, but the rest of the system should be abstracted from this. Now that speed improvements are available (objprelink and the upcoming gcc optimisations) shouldn't the focus now be on making the installation process easier.
If the kdelibs/base layer were distro-dependant, couldn't this be downloaded with an X-app and compiled and then a KDE-native installer bring the rest of the compiled binaries down? These would (should?) not be reliant on the dependencies we're seeing at the moment.
I think the whole "we only do source code" argument is wearing thin. You make the product, you should at least take some charge of quality assurance. After all, if a distro releases a "bad" version of KDE, who do think will be the target of complaints?
So, getting back to Asif's comments: although I understand that KDE is much bigger than StarOffice, Netscape, etc... there MUST be a way to release a mostly distro-independant version of KDE... otherwise how do THEY do it?
Providing of binaries is the task of the distributors.
Every distribution has its own compiler ( which changes sometimes with the release ), uses its level of optimisations ( e.g. compiled for i586 in Mandrake vs i386 RedHat, prelinking? etc. ) and has different install directories.
Why should they provide useless ( non optimised ) generic packages - when distributors anyway will package KDE in the best form for their distribution? If your distribution doesnt provide good packages, then complain there, where you have paid for the service, not here, the developers have different things to do.
Quote"
I have to allege that you are denying our basic right of getting upgrades quicker and you are giving us trouble by only providing source
You have absolutely no right for anything
"
No you dont have any rights regarding the software. And calling an update a "basic right" is bad rhetoric.
Just look at the Acrobat binaries - Unix is not Linux ( PPC is missing of course ). What you are asking for is ridiculous.
Acrobat Reader+Search 4.05 for IBM AIX - English
Arobat Reader 4.05 for Linux - English
Acrobat Reader 4.05 for Sun Solaris x86 - English
Acrobat Reader+Search 4.05 for Dec Alpha OSF/1 - Acrobat Reader+Search 4.05 for HP-UX - English
Acrobat Reader+Search 4.05 for SGI IRIX - English
Acrobat Reader+Search 4.05 for Sun Solaris SPARC