KDE 2.2alpha2 is here! Blessed by release master Waldo Bastian only a few hours ago, this release has a ton of improvements over KDE 2.1.x. You can view the ChangeLog or glance at the alpha1 announcement for an overall idea of some of the changes versus the stable branch. However, to discover the rest of the cool stuff -- such as the new regexp filter in KNewsTicker or the Kicker taskbar/extension improvements -- you'll have to download KDE 2.2alpha2 and see for yourself. As usual, source is available as well as binary packages (read our policy) for Mandrake, Red Hat, SuSE and Tru64. Debian users should check the regular sources. Keep in mind that this alpha release is not for people who expect a stable desktop, there is a short list of known problems already.
Comments
a wicked tip this does help a lot thanks!
This might make your day.
http://gcc.gnu.org/ml/gcc/2001-05/msg01670.html
If you have ~64MB of RAM you should consider
upgrading to at least 128MB. I've experienced
a major speed improvement from that, with 64MB
my machine starts swapping way too often (when
I run KDE, that is).
I find it KDE to be very fast on my 300 PII, but then again I'm used to Windose.
Really, if don't care for bells and whistles boot up one of the windows managers.
This first time I open konqueror it can take ~5 seconds to load. This is on a Thunderbird 1100 with 128 MB RAM.
Opening konqueror after the first time is significantly faster (normally around 2 seconds). However even this FEELS much slower then opening a window in Win98 (which seems to happen instantly after the first time). Once konqueror is loaded it seems fairly responsive.
I'm running RedHat 7.1 with a new kernel (2.4.4). I've turned off a lot of daemons (cron, at, sendmail, gdm, ect) to speed boot time. DMA transfers are enabled (I get close to 30 MB/s transfer rate).
Maybe there should be an option to keep parts of konqueror loaded in memory (for people with lots of RAM)?
Rimmer
PS - Would compiling the KDE stuff affect speed significantly?
> Would compiling the KDE stuff affect speed significantly?
Depend if your distribution do a good job or not.
With suse (here) I don't see significant change
between i386 RPM and compiling source$
on my PIII 700MHz.
(sure they do some tuning in RPM)
The only thing witch affect speed is compiling QT.
This is easy to do and I can see the change.
Difficult to quantify but around 10 or 15 %
regards.
To build QT use the command :
./configure -sm -gif -system-libpng -system-jpeg -no-g++-exceptions
Hi Guys,
Do you still have any time to sleep after all?
Question:
When can we expect to find the new printing architecture on KDE ?
This would be one of the most important enhancements IMHO.
Thank you
Filipe
>When can we expect to find the new printing architecture on KDE ?
It will be part of KDE 2.2 and is therefore also included in this alpha release.
I`ve installed kde2.2alpha2 within syuse 6.4 via the available rpm`s, now I find I cannot print from some kde apps, noticably Kmail and knode and a few others.
Kde Control centre is asking for kdeprintd which I cannot locate anywhere.
Anyone any clues to its whereabouts? Or is it a bug...
Same thing with me. When I try and print to a printer from kmail or konqueror I get the following error:
Unable to start child print process. The KDE print server (kdeprintd) could not be contacted. Check that this server is running.
When I print to a postscript file and then print that from commandline with lpr it works fine.
I'm using RedHat 7.1 RPMs (with updated pcre, openssl, readline et c.) with these kde packages.
kdesupport-devel-2.2-0.alpha2.1
kdeadmin-2.2-0.alpha2.1
kdelibs-sound-devel-2.2-0.alpha2.2
kdeaddons-noatun-2.2-0.alpha2.1
kdesdk-2.2-0.alpha2.1
kdebindings-devel-2.2-0.alpha2.1
kdesupport-2.2-0.alpha2.1
kdelibs-2.2-0.alpha2.2
kdegraphics-2.2-0.alpha2.1
kdelibs-devel-2.2-0.alpha2.2
kdebindings-2.2-0.alpha2.1
kdenetwork-ppp-2.2-0.alpha2.1
kdelibs-sound-2.2-0.alpha2.2
kdebase-2.2-0.alpha2.2
kdenetwork-2.2-0.alpha2.1
kdegames-2.2-0.alpha2.1
kdeutils-2.2-0.alpha2.1
kdeartwork-2.2-0.alpha2.1
kdeaddons-kate-2.2-0.alpha2.1
kdeaddons-konqueror-2.2-0.alpha2.1
kdevelop-2.2-0.alpha2.1
kdesdk-devel-2.2-0.alpha2.1
kdepim-2.2-0.alpha2.1
kdebindings-kmozilla-2.2-0.alpha2.1
kdemultimedia-2.2-0.alpha2.2
kdetoys-2.2-0.alpha2.1
kdebindings-perl-2.2-0.alpha2.1
kdeaddons-kicker-2.2-0.alpha2.1
Ben
kdeprintd is a library loaded through kded (the KDE Daemon)... Dunno under what conditions it is loaded.. Try running kded explicitly, I guess..
I have exactly the same issue with a more recent KDE.
kdeprintd is out to lunch... running kded is all you
need to bring it back.
Strange.
2 years later... ;) Thanks for the tip. Just helped me a bunch!
Two more years later... running kded did it. Why is this problem still lingering? What is this Windows? Anyway, thanks.
Thanks for the tip. Running kded as a regular user got me printing again. Thankfully didn't have to reboot :)
Seven years of this error, I'm guessing it's either neglected or intended to catch miscellaneous errors. What would be nice is if the error window offered to restart kded, linked to information about how to restart kdeprintd, or anything else that would be helpful for end users who don't know anything about the KDE subsystem.
I'm glad this topic is here... Thanks.
I'm sure a few months, or years from now, someone will add a link to this topic in the error message.
I hope the the audiocd:/ioslave check for the encoding ogg and mp3 libraries at runtime and not at compile time. I think distributors can't add the libmp3 to their distribution. So it would be nice if I can _only_ compile libmp3 and the audiocd:/ioslave from the distribution rpm works with mp3 encoding.
I think there is a desire among the developers to check for external libraries at runtime when possible. I don't know if they have done it with libmp3, but they have with libssl. I guess it really depends on how easy the task is. Using dlopen() on LessTif libs at runtime would be nice, but I don't see it happening. libmp3 sounds more plausable.
-Justin
Has anyone made rpm's for Mandrake 7.2?
I don't really have the time to upgrade OS but I would love to try alpha2.
It was said about the last alpha that this release is for people that like to be on the edge of technological improvements and if you are that kind of guy, then you would have the latest version of your OS too. :-(
I believe this is the case with this alpha too.
> It was said about the last alpha that this
> release is for people that like to be on the
> edge of technological improvements and if you
> are that kind of guy, then you would have the
> latest version of your OS too. :-(
> I believe this is the case with this alpha too.
Well, I must admit there is some sense in that. Actually I'm eagerly awaiting for Suse 7.2 to arrive in my snailmailbox. I have mdk8.0 at work and realized that I prefer 7.2 to 8.0. The "User friendly" Mandrake desktop which is screwing up my menus and stuff is more and more getting to be a pain in a body part close to my chair. But I dont wanna start a distro war ;-)
I'm a huge mandrake fan but that Menu crap annoys me too. I'm wondering when corel will jump back into the distro arena? They had a good debian-- kde based distro.
Craig
There are two options...
1) Build KDE in another directory and add it to your kdm menu...
2) delete the menu stuff!
I did both. ;-)
The menu stuff is in /etc/menu something (been a while) and also the executable is /usr/bin/menu-methods if I recall. You still need to get a copy of the menu editor to have a real KDE desktop again. I used to have all the stuff for this on line but it's out of date. I know one other person kept up the menu stuff for a while on his page.
I have been one of the people yelling at Mandrake to at least make the menus optional. If you use many desktops they are handy (but not what they are billed as because they are still different). If you want to get anything done though you will probably just run KDE and get your work done. ;-)
> at least make the menus optional
They are optional, in 8.0.
Just launch menudrake, and "Disable Mandrake customizations".
There you go. Plain KDE menus.
which is of cause really nice, but I think the main complain about the mandrake menus is that editing them is a pain in the ... and still dosen't really work. Each time you compile a program (and decide to keep it) you have to fight that thing (i don't know what else to call it) and still it does no work. Weird entries sneaks in that are not accessible in the thing, and all one can do is delete all files in ~ related to mandrake menus, but then of cause the modifications are lost.
A shame, since besides the obvious inability of mandrake to create GUI apps and the scary lack of documentation, the idear of a global menu as well of th structure it self are actually nice...
Anders says :
> I think the main complain about the mandrake menus is that editing them is a pain in the ... and still dosen't really work.
For me it works. But, yes, it is a pain... And it is a similar pain with the KDE editor...
Comparing the KDE desktop and the Windows one, I think that the biggest weakness for KDE, is the menu editor. It is a pain to have such a programm (you have to call it, find the good directory, the good icon, modify/delete/add, save (it's long...), close, and go again in the menus to verify...). On windows you don't have such a "menu editor" You only have to to do right click, "Properties" to modify, "Delete" to delete", or "open" for adding a shortcut. It's very cool.
I hope that the QT team will someday do such a thing (but does Qt allows it ?)
========
About Mandrake menus, they exist for two good reasons, I think :
- merge the KDE, Gnome and others programs...
- allow an automatic update from drk.rpm
But good reasons have bad secondary effects. The first one, for us, is that the KDE users don't recognize the KDE programs. And they have to manage the menus with a Gtk program...
However, the two reasons are good. Isn't it possible that the KDE and Gnome teams work together to find solutions ? (with Mandrake ? and other distros ?) For instance by defining a common hierarchy with 3 main sets (1 KDE, 1 Gnome, 1 others), so that :
- the user choose (or not) a priority for one set (ex: KDE, the other sets go in a "Non KDE applications")
- each node is recognized by a key item so that package installations may update the menu at the good place
I feel that the management of the start menu is a big difficulty for the user, chiefly if he choose a new distribution (how to keep his menus ?). Mandrake, alone, tries a solution. But it needs the participation of the Gnome and KDE team...
I hope something as a "Universal Linux Menus Management" !! Ulmmmm...
Yes, there is some work going on between KDE and Gnome developers, to merge and harmonize the menu structure.
Yep, good news !
I hope it is ambitious and will give a good foundation for a long time... I also hope that all the distributions will work on this common basis.
Why not fork Red Carpet to KDE that would be cool
Yes it would, but remember there are expensive server resources involved. Even Ximian can't keep up anymore with the software updates: I hear people complaining all the time about how useless Red Carpet has become because of that.
I suppose things may change when there's a stable release, nonetheless a LOT of work is involved on the server end; those KDE-oriented channels won't happen by magic.
On the bright side, I hear people may be porting the Ximian Setup Tools to KDE. Hey Kent, I can't access any of your screenshots on Geocities. :(
Here are the link to the schreen shots
http://www.geocities.com/newyen/tcpip.png
http://www.geocities.com/newyen/summary.png
http://www.geocities.com/newyen/msn.png
http://www.geocities.com/newyen/route.png
That looks great!
When are Ximian Setup tools set to be ready?
When will the KDE version be ready?
Do they share the codebase?
Ask Ximian when their Ximian Setup tools will be ready.
The KDE version will be available when it's available. :) Hopefully by end of June, if I'm not lazy.
The backend is shared.
http://www.geocities.com/newyen/ksysconfig2.png
--kent
Attached is the file as well.
From your drawing, I can see an XML layer.
I guess it's needed to convert the various config files to a sane syntax...
Now, wouldn't it be better if Linux supported XML config files out of the box, a la MacOS X?
Just imagine, every /etc/ file written in XML... much easier to edit! No more "man fstab" to learn the syntax of every config file...
Red Carpet is still useful. They just don't update as fast as software is released.
Or just port it to KDE/QT and send it to the setup-tools mailing list.
They might just accept it and move it to their CVS.
I've tried 2.2 alpha a little (just the necessary to download 2.1.2 again), and Konqueror seems to be really broken... I know, I know, it's *alpha*, but Javascript in 2.2 alpha is really broken.
Someone talked about loading times... well, generally here things are fast (2.1.2 + SuSE 7), but I noticed a little slow down with 2.2 alpha... maybe, again, it's the "alpha" part. :-)
Some neat things tho. I tried some new settings in the control panel (like fade-in menus and such), and now that I'm back to 2.1.2, those settings still work. :-)
imho... alpha1 is the best of both worlds right now - I noticed specific fixes/improvements with Konqueror compared to 2.1.1 - but alpha2 gives Konqueror a set of crutches for things I was already enjoying with alpha1.
(hopefully the Konqueror problems get sorted out ASAP - I've already reverted to alpha1 again ;-)
Er, didn't the original KDE2.2 schedule call for a beta 1 release around this time?
Or did the KDE team change the release schedule, adding a second alpha release before beta 1? Does this mean we will have to wait until (end of) august 2001 before we get 2.2, instead of the original mid-to-end of july?
I'm wondering if this means we can kiss the Qt 3.0-based KDE 2.3 (or 2.whatever) goodbye for this year... Well, anyway, release it when it's ready not before.
But since beta means feature complete, bug fixing only and some coders/features didn't arrive in time and to emphasize the improtance the KDE team puts on high quality beta1 was renamed to alpha2.
Here is the release plan:
http://developer.kde.org/development-versions/kde-2.2-release-plan.html
As of now, we have renamed the first beta -> alpha since the code quality has not reached the desired level yet. Depending on 2.2beta1 we will decide whether to follow up with 2.2final or whether to add another beta.
We have good stable releases out there so there is little time-pressure on this release.
A Qt 3.0 based release will mostly depend on the availability of Qt 3.0 and gcc 3.0. Once those
are available we expect to be able to deliver KDE 3.0 fairly quick. We haven't planned major changes for KDE 3.0 in KDE itself.
With KDE/Qt/gcc 3.0 we will finally be able to deliver a stable binary compatible platform for some time to come.
Cheers,
Waldo
You'll have to excuse my ignorance, but why do you have to wait for GCC 3.0 to create a Qt 3.0-based KDE release? Couldn't you use GCC 2.9x?
Or does GCC 3.0 bring something to the table that you just can't ignore? Inquiring minds want to know...
GCC 3.0 will break C++ binary compatibility. Instead of breaking binary compatibility twice: one with the switch to Qt 3.0, and the other with the switch to GCC 3.0, might as well wait for them both to be available and then hope for stable KDE binary interfaces that will endure for at least a year...
Not to sound like a pessimist, but this juggling can f*ck up majorly.
KDE2 has already 2 different binary interfaces (MDK8 & RH7.x using gcc2.96 vs. the rest using gcc2.95).
What can happen is that some distros jump to gcc3.0 using KDE/Qt 2.x. Others provide KDE/Qt 3.0 packages for their gcc2.9x based distros. Then as both upgrade their gcc or KDE versions, voila, we have (worst case scenario) 6 different binary-incompatible KDE-packages (based on KDE2 technology) on people's machines!
This is definitely not something 3rd party KDE-compatible software producers want to target. Hope there will be careful coordination between distros and KDE developers concerning this. It certainly needs to be much better than it has been in the past (as we have already 2 binary incompatible KDE2-distributions around..)
KDE will have to change to gcc3.0 and qt3.0 eventually. There is nothing stopping the distros from making even more incompatible versions of KDE. The distros can also keep using gcc2.95 if they like, but they can not make a gcc3.0 based KDE before gcc3.0 is out.
The options for the KDE team are:
1) Release a qt3.0 based KDE before gcc3.0 is out.
Result: THEY will cause two incompatibilies.
2) Do as planned.
Result: The distibutions can decide when to use gcc3.0.
Well, releasing KDE3 before gcc3 is done can't really happen, as gcc3 is planned to be out in this June.
One thing KDE could do is demand that distros using gcc only distribute KDE3-packages compiled with gcc3.x, and "officially condemn" those who act against that (for example, by releasing the new packages to older 2.9x-based distributions using the old compiler).
That would assure that at least KDE3 is binary compatible across Linux distributions.
Linus "officially condemn"ed Red Hat for using gcc 2.96. That didn't make Red Hat revert to 2.95. Mandrake tries to be compatible with Red Hat no matter what stupid things Red Hat does.
If a major distribution release a new x.0 between when gcc 3.0 is released and KDE goes Qt 3.0, you can bet they are gonna use gcc 3.0, cause they wanna have all the newest stuff, they even include betas and cvs snapshots.
I used to work with sales people. They did things that made the company lose money, cause they got their commission anyway. Distributions sometimes gives me the same feeling ;)
PS! Gcc 3.0 based KDE will still be called KDE 2.x.
... not saying I haven't done something wrong here but this is linux 2.4.5 and latest gcc-3.0 pre-release
Don't get me started on the idea of compiling stuff on FreeBSD with gcc3.0 hahaha
HAHAHAH
Ouch. I was not aware of this. I wonder why (again, excuse my ignorance here) gcc 3.0 does that: does it produce (executable) code that is significantly smaller, what?
Anyway, if we have to wait for the new gcc, how close is it to actual release? Are we in alpha territory, late beta, ???
Thanks.