KDE 3.1 RC1: Ready for a Short Test Drive

Tuesday, 29 October 2002  |  Dre

The KDE Project yesterday announced the release of KDE 3.1 RC 1. This release, while important, will have but a short lifespan (RC 2 is scheduled for next Monday), and so binary packages are not planned. A couple of points to consider: First, if you are wed to the hicolor icons, please note that they have been moved to the kdeartwork package; the other packages ship only with the new modern and attractive Crystal-SVG icon theme. Second, Klipper users who experience slowness or possible crashes in Konsole or KMail with this release should try disabling the Klipper syncing options, and then check the KDE 3.1 Info Page about reporting results. Please give this release a thorough testing so KDE 3.1 will be good and ready on schedule! A short but informative preview of the much-improved KDE 3.1 is available on the KDE Promo site.

Comments:

Highcolor Icons - David Johnson - 2002-10-29

"if you are wed to the hicolor icons, please note that they have been moved to the kdeartwork package" Aargh! These are wonderful icons. They have a classic and simple look without being ugly. Eye candy is good, but candy is desert. Sometimes a sensible main course is what is desired. At least keep hicolor in the kdelibs package.

Re: Highcolor Icons - Jeremy Huddleston - 2002-10-29

I disagree. kdelibs should not be bloated with redundancy. That's the whole reason theres a seperate package for the extra icon sets.

Re: Highcolor Icons - David Johnson - 2002-11-01

If we're worried about redundancy, then why wasn't Crystal put into -artwork instead?

Re: Highcolor Icons - Jeremy Huddleston - 2002-11-01

Because we need atleast one icon set in the main kde distribution. You can't have redundancy without something to be redundant about =)

Re: Highcolor Icons - KDE User - 2002-10-29

Agreed. All the new "eye candy" to me is just clutter. I don't like keramik and I don't like the crystal icons. Last I checked the hicolor default style was still part of KDE, so that's good, but it's unfortunate that the hicolor icons are now gone. You can bet I'll be picking them up to use as my main set.

Re: Highcolor Icons - Nick - 2002-10-29

They are not GONE, they are moved to a new package. That makes them an optional part of a KDE installation, but will still be very commonly distributed.

Re: Highcolor Icons - Aaron J. Seigo - 2002-10-30

i think it is important to remember that while there are those who will still install and use the HiColor theme and icons, there are many who will now go with the KDE default look. many already use a different style than the default (e.g. litev3 is very popular, which btw is now the default style for local displays) so while it means some will not use the default anymore, many others now will. judging by overall response, probably many more others.

Re: Highcolor Icons - Aaron J. Seigo - 2002-10-30

er, and by "local displays" i meant "locolor displays" *sigh*

Re: Highcolor Icons - James Richard Tyrer - 2002-11-01

I'm not really "wed" to the "HiColor" icons, what I AM wed to is my icons! There is more than one issue here: I don't like the 3D folders and so I use the old 2D folder icons. I now have quite a few folder icons for various purposes many of which consist of the 22 pixel icon combined with the 32 pixel folder icon for 32 pixels and a half size 22 pixel icon combined with a plain color background the same color as the folder (I use FFDCA8 for all folders, but have nothing against using different colors) for the 16 pixel icons. Note that it occured to me that this could be done automatically. That is, for example, there is a directory: "~./kpackage" so it could automatically have an icon as I have made for it. Many (non-kde) programs come with an icon or I have 'borrowed' one. These look best with the HiColor icons. They look very much out of place with the Crystal Icons. What happened to usability. Everaldo's icons may be great art, but at 32 pixels they are not very usable. They look fuzzy and lack contrast. They simply not easy to distinguish from similar ones. -- JRT

Nah, Crystal isn't SVG - TheFogger - 2002-10-29

Title says all. Still, it's a really nice icon set, I've been using it with KDE 3.0.4 for a long time now.

Re: Nah, Crystal isn't SVG - Anonymous - 2002-10-29

The delivered version is not, but all icon sizes are automatically generated from SVGs.

Re: Nah, Crystal isn't SVG - zelegans - 2002-10-29

I'd really like icons that scale with the size of the panel. That and 37 pixel wide desktop icons ;)

Re: Nah, Crystal isn't SVG - qwerty - 2002-10-29

There is a SVG variant of Crystal, just don't know if it's already in 3.1.

Re: Nah, Crystal isn't SVG - Tackat - 2002-10-30

Hi, Yeah, at the current point of time the name of the theme is a bit misleading. Actually we _do_ have vector data for most (about 70-90%) of the crystal-icons. And technically it _would_ be possible to use them on the fly as well as pregenerated. It's just that ksvg2png while giving excellent results for 98% of all icons needs more testing and that we still have some icons left for which SVG-data doesn't exist yet. So instead of releasing something that hasn't been properly tested we decided to use Pixmaps (which have been partially autogenerated from the SVGs) instead of using the "real" data. To make the transistion easier we decided to name the theme already "Crystal SVG" to make the transition easier. Wait for some news concerning this topic which will be released soon. Regards, Tackat

Re: Nah, Crystal isn't SVG - TheFogger - 2002-10-30

Wow, cool. I always a associated SVG with a rather cartoonish look, not "shiny" like Crystal is. I didn't know that you could create such icons with SVG.

Re: Nah, Crystal isn't SVG - Andreas Neumann - 2002-10-30

To my opinion SVG is one of the best web-technologies to watch, as a graphics-exchange format, as a graphics format for mobile devices, as a printer description language (combined with other XML-technology, such as XSL-FO), etc. ... I therefore think that the KDE team should give SVG top priority as a base-technology for the KDE-desktop (SVG enable all KDE-applications) and as an integral part of the Konqueror browser. Combined with other XML technology and scripting, SVG allows very useful applications and is for the first-time a fully documented vendor-neutral graphics format as an exchange format between different applications and platforms. I am very happy that ksvg (svg.kde.org) already exists - but I think that it should have more support and priority within the KDE team than it has now. Check f.e. http://www.svgopen.org/, http://www.kevlindev.com/ and www.carto.net to see some useful applications. As a conclusion: SVG for icons is nice - but with SVG you can do much more and it should really have more weight within the KDE project!

Re: Nah, Crystal isn't SVG - Rob Buis - 2002-10-31

As a ksvg developer, I am very happy with these comments :) As a matter of fact, I'll forward them :) I looked at carto.net and it looked very nice, but I havent really found the time to study it. Cheers, Rob.

Re: Nah, Crystal isn't SVG - Antialias - 2002-10-31

Hi Rob, can you recommend some svg graphic tools for creating svg icons? Tackat & everaldo use Adobe Illustrator, but I don't want to use proprietary tools, especially not Adobe products (you know the story when Adobe lawyers threatened KDE with lowsuit for using name KIllustrator). So, can you recommend an open source graphic editor which can export svg fromats that can be read by ksvg? I tried Sodipodi, Karbon etc, but the results were poor. Either their exported svg files can't be read by each other or can't be read by ksvg properly. Now we have a situation that the next default icon theme for KDE 3.1 is being created by artists who are running windows or Mac platform with a graphic tool from a company known for threatening KDE and other open source projects. Regards, antialias

Re: Nah, Crystal isn't SVG - Rob Buis - 2002-10-31

Hi, >I tried Sodipodi, Karbon etc, but the results were poor. Either their exported >svg files can't be read by each other or can't be read by ksvg properly. >Now we have a situation that the next default icon theme for KDE 3.1 is being >created by artists who are running windows or Mac platform with a graphic tool >from a company known for threatening KDE and other open source projects. I agree, it is not ideal. Best thing to do IMHO is to support the oss alternative, karbon14, by sending in bug reports and wrongly exported svg files, then we can fix them. Believe me, we are really aiming to help the artists on a nice vector drawing app, that is our first major goal, just tell us where we fall short currently :) Cheers, Rob.

Compiling - Vic - 2002-10-29

I'm compiling RC1 on my home system from work as we speak. Can't wait to get home and try it. Ran into a few compile snags - one with kfontinst and the locations of freetype, one with kmail and a missing mStartupFolder declaration, and one large mess in kmidi. I fixed the first two - I just bypassed compiling kmidi since I don't use it. I suspect the first and last are more related to problems with my setup than with KDE itself. But as for the kmail error... I can't see that working without help on other systems... ?

Re: Compiling - Anonymous - 2002-10-29

Missing mStartupFolder declaration? I thought it was a duplicate declaration, patch to fix this: http://kdewebcvs.pandmservices.com/cgi-bin/cvsweb.cgi/kdenetwork/kmail/kmmainwin.h.diff?r1=1.147&r2=1.148

Re: Compiling - Vic - 2002-10-29

Well - I certainly had to add one, since there was none mStartupFolder is undeclared After adding it to the list of QStrings in kmmainwin.h it finished up happily.

Re: Compiling - Anonymous - 2002-10-30

Yeah, seems like two people added it to fix without coordination after tagging. :-)

Re: Compiling - Haakon Nilsen - 2002-10-30

It seems natural to me that the tarballs should be compiled cleanly before being released, to catch these things :) It may only be an RC, but we still want as many people as possible testing it, I presume. It was a simple fix, but other people may not think so. :)

Re: Compiling - Darren - 2002-10-31

Thanks for the tip.. I needed that

Why Realese Candidate? ;) - Dimitri - 2002-10-29

Well the beta2 is as stable as KDE 3.0.4. Never had any crashes. Again perfect work from the KDE team. Dim

Re: Why Realese Candidate? ;) - Jeremy Huddleston - 2002-10-29

Check out the feature status page to see what isn't quite finished: http://developer.kde.org/development-versions/kde-3.1-features.h And there are still minor bugs to take down (encapsulated messages in kmail, replys to html messages n kmail... get on the reporting, and some font problems to name some I've seen), so start reporting them so KDE 3.1 is as bug free as possible

Re: Why Realese Candidate? ;) - Anonymous - 2002-10-29

Check out the KDE 3.0 feature page to see what's not yet finished for 3.0. Remember, coders are lazy in updating documentation.

Re: Why Realese Candidate? ;) - Jeremy Huddleston - 2002-10-29

HAHA!!! Good point, but I noticed it was updated about 2 (3?) weeks ago, so it's atleast a starting point =). Plus there's that nice quick link to the critical bugs on top.

Re: Why Realese Candidate? ;) - Anonymous - 2002-10-30

I have some issues with Konqueror file manager mode with linux 2.5 series kernels, I use 2.5.44 currently and when i start konqueror it just hangs, the web browser mode works perfectly though I use offical debian packages for beta2 from kde.org ANybody experienced this issues?

Re: Why Realese Candidate? ;) - myself - 2002-10-30

mmmmm.... I'd like to give it a try, but 2.5.x series of the kernel really frighten me... aren't there any chances of destroying the filesystem or similar? My laptop uses only acpi, and I really need some upgrade, I hope they have done it right for 2.6. Sorry, I think the question might be out of topic...

Re: Why Realese Candidate? ;) - Anonymous - 2002-10-31

Well I use 2.5.44 on the laptop myself I have got everything to work including ACPI support, I haven't had any issues so far except the konqueror hang which is kinda strange given it only hangs in file manager mode

Re: Why Realese Candidate? ;) - myself - 2002-10-31

Thanks a lot for the info. Maybe this weekend.... after I do backups ;-)

Re: Why Realese Candidate? ;) - cm - 2002-10-31

I experienced exactly the same a while ago with a KDE version from CVS (on a PIII desktop machine on a 2.4 Linux kernel). So maybe the freeze is not related to the kernel or the laptop. Some days later the problem was just gone. I've no idea what the reason has been. I cannot remember doing anything about it like deleting my ~/.kde

Critical Patch - Jeremy Huddleston - 2002-10-29

A patch was committed today to address a critical bug, that I don't think got into RC1 (I'm not 100% positive about that, but I'm pretty sure). I advise you guys to apply it before testing out RC1. http://bugs.kde.org/show_bug.cgi?id=48923

Re: Critical Patch - Anonymous - 2002-10-29

Or simply keep in mind what http://www.kde.org/info/3.1.html says: - Deleting an icon on the desktop deletes all the contents behind it Bug #48923 )

Re: Critical Patch - Jeremy Huddleston - 2002-10-29

yes, but I'm saying it would probably be better to apply the patch rather than remembering not to delete stuff =)

KDE 3.1b2 was slow at startup - suggestion man - 2002-10-29

Isn't there a way to improve KDE start speed ? It's very too slow !

Re: KDE 3.1b2 was slow at startup - BesserWisser - 2002-10-29

Yes, just update your hardware :-)

Re: KDE 3.1b2 was slow at startup - antiphon - 2002-10-29

That is not an acceptable answer (even though you're joking) But the original poster may want to check inside his startkde script and delete services he does not need. Also, if you compile it with a newer version of gcc (or use Intel's), it will run faster. I do wish the developers would try to make speed more of an important area.

Re: KDE 3.1b2 was slow at startup - Snarf - 2002-10-29

I'm a little confused about compiling KDE with a compiler that's different from the system's default compiler. gcc 2.9x and gcc 3.x are binary incompatible. Does that mean I have to recompile all libraries that KDE depends on with the new compiler? What about system libraries such as glibc? It would be nice if some expert can write a two-paragraph "HOWTO" for ignorant folks like myself.

Re: KDE 3.1b2 was slow at startup - Sad Eagle - 2002-10-30

Only libraries that are written in C++. That includes the obvious Qt, and FAM, if you have it ( a lot of people miss that one ). There may be others, but I don't know of any.

Re: KDE 3.1b2 was slow at startup - Richard Moore - 2002-10-30

This is not something that should be attempted if you don't know what you're doing. If you want to use the new compiler I strongly suggest you upgrade to one of the newer releases of your distribution rather than trying to do it yourself. To gain the benefits you're looking for you need to upgrade glibc, gcc, binutils etc. and all C++ libraries. Rich.

Re: KDE 3.1b2 was slow at startup - Charles Samuels - 2002-10-29

Runtime and startup time are very different things. Upgrade to glibc 2.3 to improve startup time (with Prelink). The startup time problems you see in KDE are the results of problems in ELF and gcc. glibc 2.2.5 featured comb-relocs which speeds it up 30%-50%. prelinking should make relocation time negligible. Also something that kdeinit does. Intel's compiler won't make KDE run or start faster, it doesn't excel at code like KDE's (it prefers math-intensive stuff). gcc 3.2 is about 15% faster for run-time. Yes, you need to recompile all your libs for it.

Re: KDE 3.1b2 was slow at startup - Johan Veenstra - 2002-10-30

"The startup time problems you see in KDE are the results of problems in ELF and gcc. glibc 2.2.5 featured comb-relocs which speeds it up 30%-50%. prelinking should make relocation time negligible." It may make relocation time negligible, but startup time is not solely caused by relocation.

Re: KDE 3.1b2 was slow at startup - Aaron J. Seigo - 2002-10-30

of course it isn't, but it is a large chunk of the problem. KDE can always use more optimizations and continues to get them. there are limits, however. of course, having seen how fast the latest SuSe was even on ancient hardware, i'm quite impressed at how fast it can be when properly built and integrated.

Re: KDE 3.1b2 was slow at startup - Sad Eagle - 2002-10-30

Well, kdeinit doesn't help you much with dlopen'ing libs, though, so linking time is still major -- on my box w/ combreloc loading KHTMLPart, kjs_ecma, etc., takes a noticeable amount of time. Ditto for libkonq_sound - dlopening it seems to cause a 1/3 second lag, although I do not recall whether my profile-point would have caught it initialization (i.e. presumably connecting to aRtsd), so some of it may not be dlopen itself in this particular case

Glibc upgrade - Stof - 2002-11-02

How hard is it? Can I do './configure --prefix=/ && make install' and expect it to work? Will I break existing apps? Do I have to recompile everything?

Re: KDE 3.1b2 was slow at startup - Anonymous - 2002-10-29

I don't know what your problem is: Update binutils, glibc, gcc, your hardware, XFree, KDE & Qt, delete fonts, compile from source, change compilation settings, ...

Re: KDE 3.1b2 was slow at startup - Evan "JabberWokky" E. - 2002-10-30

Try poking around the startkde script and remove the bit that scans for plugins. I've told people to do this and be delighted - cutting the startup time to 50% or even 33% of what it was. I'm still of the opinion that it should be forked off in the startup, and executed after 60 seconds. -- Evan

Re: KDE 3.1b2 was slow at startup - ac - 2002-10-30

It shouldn't be there at all by default. Please file a bug for its removal and have it run by demand in some config panel. 50% slowdown is *serious*.

Re: KDE 3.1b2 was slow at startup - Anonymous - 2002-10-30

Don't file it to KDE, it's afaik a Mandrake messing of startkde.

Re: KDE 3.1b2 was slow at startup - socialEcologist - 2002-10-30

Here is the fastest setup I ever had : -gcc3.2 + new binutils (compiled together) -recompile new glibc -recompile your c++ libs, png, jpeg, etc, -recompile X -recompile qt with --no-g++-exceptions (and -qt-gif,-thread, etc) -recompile all kde with --disable-debug and --enable-final your system will be really faster. (but ok it's time consumming and not so easy to do) Hope this helps

Compiling it now - Haakon Nilsen - 2002-10-29

I'm compiling now! Since I've just installed Redhat 8.0, I thought I'd just skip their KDE alltogether :> It's been ages since I last compiled KDE from source, it's really grown ;) kdelibs took some 4-5 hours on my rusty old celeron433mhz. But it'll be worth it, 3.1 looks sweet. Also, thanks to the nice people on #kde-users at irc.kde.org for their patient support :)

NO! Why remove them! - Dont remove them please - 2002-10-30

They are simple and fir in with all linux apps. Crystal isn't even 1/4 done, there are so many apps that need to be crystalized! Leave Hi-Color in there for those who want a complet desktop. Please!

Will KDE-3.1 depend on a Qt-3.1? - Thorsten Schnebeck - 2002-10-30

Latest KDE-CVS needs a Qt-3.1pre (qt-copy). And it is soo unstable compared to the lastest possible KDE-CVS+Qt-3.0.5. Qt 3.1 seems to have problems with e.g. font-handling. Using a current qt-copy e.g. Konqi crash too often with stuff like this: [New Thread 1024 (LWP 1469)] 0x41015569 in wait4 () from /lib/libc.so.6 #0 0x41015569 in wait4 () from /lib/libc.so.6 #1 0x410913f8 in __DTOR_END__ () from /lib/libc.so.6 #2 0x40ece402 in waitpid () from /lib/libpthread.so.0 #3 0x406720c0 in KCrash::defaultCrashHandler (sig=11) at kcrash.cpp:235 #4 0x40ecc134 in pthread_sighandler () from /lib/libpthread.so.0 #5 <signal handler called> #6 0x40dfca2d in XGetFontProperty () from /usr/X11R6/lib/libX11.so.6 #7 0x409aab9e in QFontPrivate::fillFontDef () from /usr/qt/3/lib/libqt-mt.so.3 #8 0x409b09ed in QFontPrivate::initFontInfo () from /usr/qt/3/lib/libqt-mt.so.3 #9 0x409b245a in QFontPrivate::load () from /usr/qt/3/lib/libqt-mt.so.3 #10 0x409b148c in QFontPrivate::loadUnicode () from /usr/qt/3/lib/libqt-mt.so.3 #11 0x409b179d in QFontPrivate::load () from /usr/qt/3/lib/libqt-mt.so.3 #12 0x409a8e37 in QFontMetrics::QFontMetrics () from /usr/qt/3/lib/libqt-mt.so.3 #13 0x41bcfdcc in khtml::Font::update (this=0x84d0f20, devMetrics=0x80657a8) at font.cpp:194 #14 0x41be1780 in khtml::CSSStyleSelector::styleForElement (this=0x831c348, e=0x84d0a98, state=0) at cssstyleselector.cpp:362 #15 0x41b5c5ac in DOM::ElementImpl::attach (this=0x84d0a98) at dom_elementimpl.cpp:318 #16 0x41b6b8f9 in KHTMLParser::insertNode (this=0x8474310, n=0x84d0a98, flat=false) at htmlparser.cpp:308 #17 0x41b6b7cd in KHTMLParser::parseToken (this=0x8474310, t=0x8474214) at htmlparser.cpp:267 #18 0x41b748a9 in HTMLTokenizer::processToken (this=0x84741e0) at htmltokenizer.cpp:1561 #19 0x41b72f9d in HTMLTokenizer::parseTag (this=0x84741e0, src=@0x84742ec) at htmltokenizer.cpp:1094 #20 0x41b73ab9 in HTMLTokenizer::write (this=0x84741e0, str=@0xbfffe91c, appendData=true) at htmltokenizer.cpp:1348 #21 0x41b284b2 in KHTMLPart::write (this=0x83ddf48, str=0x84c1078 "<TABLE CELLSPACING=\"0\" CELLPADDING=\"0\" WIDTH=\"130\" BORDER=\"0\">\n<TR>\n<TD BGCOLOR=\"#eeeeee\" WIDTH=\"5\"> &nbsp; </TD>\n<TD BGCOLOR=\"#eeeeee\">\n<FONT FACE=\"Helvetica, Arial\" COLOR=\"#333333\" SIZE=\"-1\"><B>Sear"..., len=203) at khtml_part.cpp:1399 #22 0x41b261bf in KHTMLPart::slotData (this=0x83ddf48, kio_job=0x82f9be0, data=@0xbfffed54) at khtml_part.cpp:1109 #23 0x41b3d00a in KHTMLPart::qt_invoke (this=0x83ddf48, _id=9, _o=0xbfffeab0) at khtml_part.moc:344 #24 0x409e01d4 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #25 0x40183c21 in KIO::TransferJob::data (this=0x82f9be0, t0=0x82f9be0, t1=@0xbfffed54) at jobclasses.moc:728 #26 0x40174090 in KIO::TransferJob::slotData (this=0x82f9be0, _data=@0xbfffed54) at job.cpp:737 #27 0x40184487 in KIO::TransferJob::qt_invoke (this=0x82f9be0, _id=18, _o=0xbfffebd4) at jobclasses.moc:807 #28 0x409e01d4 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #29 0x40168d73 in KIO::SlaveInterface::data (this=0x8404448, t0=@0xbfffed54) at slaveinterface.moc:195 #30 0x401674ed in KIO::SlaveInterface::dispatch (this=0x8404448, _cmd=100, rawdata=@0xbfffed54) at slaveinterface.cpp:246 #31 0x40166ed8 in KIO::SlaveInterface::dispatch (this=0x8404448) at slaveinterface.cpp:191 #32 0x40164c2d in KIO::Slave::gotInput (this=0x8404448) at slave.cpp:221 #33 0x401665f9 in KIO::Slave::qt_invoke (this=0x8404448, _id=4, _o=0xbfffee68) at slave.moc:114 #34 0x409e01d4 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #35 0x409e0365 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #36 0x40c31904 in QSocketNotifier::activated () from /usr/qt/3/lib/libqt-mt.so.3 #37 0x409f678d in QSocketNotifier::event () from /usr/qt/3/lib/libqt-mt.so.3 #38 0x40996256 in QApplication::internalNotify () from /usr/qt/3/lib/libqt-mt.so.3 #39 0x40996054 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3 #40 0x40611290 in KApplication::notify (this=0xbffff378, receiver=0x8319718, event=0xbffff0b0) at kapplication.cpp:441 #41 0x4097b157 in QEventLoop::activateSocketNotifiers () from /usr/qt/3/lib/libqt-mt.so.3 #42 0x4095dcd2 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3 #43 0x409a621e in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3 #44 0x409a6186 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3 #45 0x409963d9 in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3 #46 0x416ab774 in main (argc=2, argv=0x805e500) at konq_main.cc:130 #47 0x0804dbd7 in launch (argc=2, _name=0x805e77c "konqueror", args=0x805e78f "\001", cwd=0x0, envc=1, envs=0x805e7a0 "", reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x805e7a4 "susi;1035933340;324242;23568") at kinit.cpp:547 #48 0x0804ecd7 in handle_launcher_request (sock=7) at kinit.cpp:1023 #49 0x0804f491 in handle_requests (waitForPid=0) at kinit.cpp:1189 #50 0x080506b0 in main (argc=3, argv=0xbffff934, envp=0xbffff944) at kinit.cpp:1534 #51 0x40f88671 in __libc_start_main () from /lib/libc.so.6 Bye Thorsten

Re: Will KDE-3.1 depend on a Qt-3.1? - John Morris - 2002-10-30

I have a similar problem with KDECVS.. I get this everytime I close konqueror: 0x40fde739 in wait4 () from /lib/i686/libc.so.6 #0 0x40fde739 in wait4 () from /lib/i686/libc.so.6 #1 0x4105b340 in sys_sigabbrev () from /lib/i686/libc.so.6 #2 0x40e2fa73 in waitpid () from /lib/i686/libpthread.so.0 #3 0x405eaeb0 in KCrash::defaultCrashHandler(int) () from /opt/kdecvs/lib/libkdecore.so.4 I dunno if this is my fault, but I didn't have this problem a couple of months back..

Re: Will KDE-3.1 depend on a Qt-3.1? - Anonymous - 2002-10-30

Don't confuse dot.kde.org with bugs.kde.org.

Re: Will KDE-3.1 depend on a Qt-3.1? - Thorsten Schnebeck - 2002-10-30

These are known bugs AFAIK. OK, a posting a complete backtrace is maybe a little bit too long ;-) but the question in the title is valid. Bye Thorsten

Yes - Anonymous - 2002-10-30

You answered your question yourself with the first sentence. :-)

Re: Will KDE-3.1 depend on a Qt-3.1? - Neil Stevens - 2002-10-31

Oh, so only praise, and not problems, are welcome here?

Re: Will KDE-3.1 depend on a Qt-3.1? - TrollDetector - 2002-10-31

*beep* *beep* *beep*

Re: Will KDE-3.1 depend on a Qt-3.1? - ac - 2002-11-01

The sensitivity on our new detector is a little high. It's supposed to only go off for trolls, but sometimes it goes off for grumpy gnomes. Any way we can recalibrate it? But...the beep message IS pretty funny!

Re: Will KDE-3.1 depend on a Qt-3.1? - Aaron J. Seigo - 2002-11-03

it's about putting such reports where they will actually do some good, e.g. bugs.kde.org. they aren't nearly as effective or useful when posted as a comment to dot.kde.org.

Re: Will KDE-3.1 depend on a Qt-3.1? - spacefiddle - 2002-12-10

...and a month later, the original question was never answered. Ah well.

Re: Will KDE-3.1 depend on a Qt-3.1? - Anonymous - 2002-12-10

Who can read has an advantage: http://dot.kde.org/1035902091/1035933509/1035950008/1035958915/1035964613/

Artsd - Jesús Antonio Sánchez A. - 2002-10-30

Hi. Is it only me? or does anyone had experience artsd being a little bit buggy (kde-3.1rc1). It plays well for about 10 secs,then makes a noise, continues to play well, then makes a noise, and so goes on. I compiled it with gcc 3.2 Thanks

Re: Artsd - Richard - 2002-10-30

Nope, been working just fine for me. Sounds like a hardware-specific issue.

Re: Artsd - thefrog - 2002-10-30

Hmm, sounds like you are listening to the Rolling Stones ... Your description fits perfectly ):- Try mozart instead ))::--

Re: Artsd - KDE User - 2002-11-02

:-D

Re: Artsd - Xanadu - 2002-11-02

+5, Funny!

Re: Artsd - mar_10 - 2002-10-30

I've noticed the same yesterday on my Mandrake 9.0/KDE 3.0.3 desktop. I don't know the reason for sure but the only thing i've done since the sound worked fine was installation of HSF soft modem drivers (My modem device is Pentagram Hex 2 based on Conexant chipset). So I can suppose that my problem is caused by buggy modem drivers. Marcin

Re: Artsd and its future - Joe - 2002-10-31

I hope it's only you, because don't count on getting many aRts bugs fixed. It's largely a "one man project" and such projects are badly hurt if that "one man" loses interest. That _seems_ to be happening to aRts. Check the kde-multimedia archives for the last month and judge for yourself. I could be wrong, actually I hope I am.

Re: Artsd and its future - Anonymous - 2002-10-31

Do you expect the one man to have conversations with himself on the mailing-list? :-)

Re: Artsd and its future - Carsten Pfeiffer - 2002-10-31

Check kdenonbeta/arts for recent additions to arts.

Re: Artsd and its future - Joe - 2002-11-01

But I get a little worried when messages like http://lists.kde.org/?l=kde-multimedia&m=103588908821958&w=2 go unanswered.

Re: Artsd and its future - Carsten Pfeiffer - 2002-11-05

Matthias Welwarsky has taken care of that issue already.

Re: Artsd [is the same] - Luke-Jr - 2002-11-06

I don't think artsd has changed since KDE 3.0... at least, the version # has been the same for the last few KDE updates...

Re: Artsd - Benjamin Stocker - 2003-02-09

I have exactly the same problem using arts 1.1.49/KDE 3.1 on SuSE Linux 8.1. I use a Intel 82801. Playing MP3 files using noatun or xmms (arts plugin) results in noise with increasing volume after 1-2 minutes (or even 10-15 minutes) Noise will not stop until I terminate the player or restart artsd. Also when streaming sound or video using realplay, noise occurs after several minutes. Using xmms with stopped artsd and OSS output plugin works well.

Re: Artsd - Maxim - 2003-04-18

I have the same problem and even turning off artsd and playing mp3's on xmms through OSS does not help :(

Word wrap - antiphon - 2002-10-30

I've been hearing that the RC1 release is supposed to have soft word wrap which supposedly will even respect indentation. Can anyone tell me if this is true since I don't have the pipe or the time to get RC1 up and running? It has been absolutely ridiculous that line-wrapping in Un*x has been so rudimentary that we haven't been able to do this. Only the August HTML editor has word wrapping so far as I know but even its wrapping plays tricks w/the keyboard like Emacs's and GNOMEs crappy character wrapping does. I couldn't believe it when I found out that UNIX had no soft wrapping editors. Please tell me that this is no longer true! As it is now, I have to fire up Windoze programs under Wine to edit my HTML and keep my sanity :(

Re: Word wrap - Sad Eagle - 2002-10-30

Kate in HEAD/RC1 does support soft wrap -- View-> Dynamic Word Wrap ( not to be confused with the static word wrap stuff in the settings dialog); I am not sure what you mean by respecting indentation with that, though. However, I'd be *really* surprised if EMACS didn't support softwrap, seeing how it has just about everything imaginable in there. IIRC, Vim has a softwrap mode on by default (although it's handling of arrows confused me somewhat when I tried it, I think)

Re: Word wrap - antiphon - 2002-10-30

<i>I am not sure what you mean by respecting indentation with that, though. However, I'd be *really* surprised if EMACS didn't support softwrap, seeing how it has just about everything imaginable in there. IIRC, Vim has a softwrap mode on by default (although it's handling of arrows confused me somewhat when I tried it, I think)</i> When I say respecting line indentation, I am referring to that if a line is indented 4 tabs, when it is soft-wrapped, the wrapped portion of the line will be in alignment with the indentation of the first. Emacs does have _line_ wrapping but it is rather primitive (like vim and GNOME's) in that it is character based and not word based. Thus your words will be broken up if they're at the end of a line. Also, both have irritating keyboard motions, i.e. if you want to move down to a virtual line, you cannot do so by pressing a keystroke but must use the mouse (or some other irritating variation).

Re: Word wrap - Gerhard - 2002-10-30

Sorry, I've been using vi for ages, and it has always had word wrap :se wm=5 to WORD wrap at 5 characters from the right border Autoindent has been part of VI sine (at least) the mid 80s :se ai Vim has improved this a bit with it's smart indent option. Emacs has had what you want for ages as well (at least xemacs, I've never tried gnu emacs)

Re: Word wrap - Ian Eure - 2002-11-02

"Emacs does have _line_ wrapping but it is rather primitive (like vim and GNOME's) in that it is character based and not word based." Mm, nope. I use XEmacs on a regular basis, and it's line-wrap mode never breaks up a word. I don't think that it respects indentation (at least, not with the Fundamental major-mode), but I'm sure there's a way to make it do what you want. But you want to start out with: M-x auto-fill-mode

Re: Word wrap - g laden - 2006-09-26

I think the emacs M-x auto fill mode you are talking about inserts a soft return which then becomes part of the text stream. So, if you narrow margins or lengthen them, for instance, the text does not re-wrap. What the person way up stream on this thread was looking for really does not exist. One way to implement the desired feature may be found at this web site: http://penguinpetes.com/b2evo/index.php?title=howto_make_emacs_use_soft_word_wrap_like&more=1&c=1&tb=1&pb=1 I have not tried this so I cannot attest to it. It is important to me. If I can get it to work, I can use emax/xemax, otherwise, not really...\

Re: Word wrap - Ruediger Knoerig - 2002-10-30

No Unix editor with soft word-wrap? The _best_ editor available --> EMACS <-- is a typical unix app! I never found an editor with comparable auto-indent-capabilities, so this is still my preferred choice for all kind of programming jobs (C/C++, HTML, TeX and so on)

Re: Word wrap - not me - 2002-10-30

How do you enable soft word-wrapping in EMACS? The default is hard wrapping (not even word wrapping in programming modes).

Re: Word wrap - antiphon - 2002-10-30

Those who have recommended emacs to me have not read my original post in which I said that emacs (and xemacs and vi and GNOME) feature a primitive CHARACTER-based wrapping which breaks up words in the middle and puts them onto the next line. This is irritating and very confusing trying to explain to a person who knows about computers but has never used Un*x why such a basic thing cannot be done right. There is absolutely no reason why the wrapping should be based on characters rather than on words. I'm hoping that KDE doesn't follow in this bad precedent.

Re: Word wrap - fubar - 2002-10-30

I know that both vi(m) and (x)emacs both have ways to automatically format a section of text into 80 columns. I'm sure it's customizable, too. And I wouldn't be surprised if there's a way in each of the editors to have it do that automatically - it's just a matter of learning how to use the program properly.

Wrong in vim. - Moritz Moeller-Herrmann - 2002-10-30

'linebreak' 'lbr' boolean (default off) local to window {not in Vi} {not available when compiled without the |+linebreak| feature} If on Vim will wrap long lines at a character in 'breakat' rather than at the last character that fits on the screen. Unlike 'wrapmargin' and 'textwidth', this does not insert <EOL>s in the file, it only affects the way the file is displayed, not its contents. The value of 'showbreak' is used to put in front of wrapped lines. This option is not used when the 'wrap' option is off or 'list' is on. Note that <Tab> characters after an <EOL> are mostly not displayed with the right amount of white space.

More hints for vim - yuu - 2002-11-03

I have a file called updown.vim that makes vim behave almost like notepad. Some features are still missing, like indentation after wrap and the status bar (it will then show the paragraph number instead of line number...) " Up, Down, Home and End keys in normal and insert mode map <up> gk imap <up> <C-o>gk map <down> gj imap <down> <C-o>gj map <home> g<home> imap <home> <C-o>g<home> map <end> g<end> imap <end> <C-o>g<end> " Don't break words in middle set linebreak " Show incomplete paragraphs even when they don'f fit on screen (avoid @'s) set display+=lastline

Re: More hints for vim - Raven Morris - 2003-11-02

THANK YOU SO MUCH I have been trying to figure out how to get it to move the cursor by visual lines rather than stored-in-the-file lines. And the fucking hiding of paragraphs was driving me insane. I tried some other keybindings recommended to fix the visual lines thing, but they did not work half the time. Your method is flawless. Thank you, thank you, thank you ! - raven morris

Re: More hints for vim - James - 2007-02-09

That is a fantastic tip - you just (well, in 2002) solved the very last thing that was really annoying me about vim! :-) Thanks very much!

Re: More hints for vim - Stephan Sokolow - 2008-07-01

Ditto. Thanks a million.

Works great - Anonymous - 2003-05-06

It works great, you rock

Re: Word wrap - Count - 2002-11-14

Youre really cute...i KNOW that emacs is a very good editor and bla blah.. simply say how to enable the word wrap and howto set the margins ! like : M-x auto-fill-mode , left margin via (options-> advanced-> emacs -> editing ->fill -> left margin)(under xemacs)

Word wrap with emacs - Ralph Buse - 2004-08-10

Word wrap in editors like editplus / context and so on is fortunately different to the word wrap in emacs. emacs (via auto-fill or M-q) adds a kind of line-break that unfortunately prevents built in incermental search (STRG-F), search-replace, regexp search, 3rd party search (e.g. grep) etc from finding the string "xxx (linebreak) yyy" when you are searching for "xxx yyy". To me, that really is a pain in the ass. To me, that is THE reason for changing the tool, as a non-destructive (!) word wrap is essential (for me) when working with normal text. I have been searching the net for a workaround or even for ANY way to make the search / replace / grep oversee the added linebreak and haven't found it yet. Help is greatly appreciated but I am not expecting any. Ralph

Re: Word wrap with emacs - Jon - 2005-10-12

Don't suppose you could just write your own? Its real easy, instead of counting '\n' as a character, ignore it. For that matter, you could ignore anything that you don't want to be a break. I, for one, rewrote word count so that it didn't count hyphens as seperate words.

Re: Word wrap with emacs - 1052 - 2006-09-11

Use word-search-backward and word-search-forward. It would be great if this were the default in text-modes or when auto-fill is enabled.

Re: Word wrap with emacs - JanR - 2007-01-29

You might also want to consider longlines-mode (in Emacs 22 or http://www.emacswiki.org/cgi-bin/emacs/download/longlines.el)

Re: Word wrap with emacs - Alex - 2007-03-12

I am still studying Emacs, but they say that "C-s RET C-w" is able to find phrases even if they are separated by newlines.

Re: Word wrap - Trevor - 2002-10-30

KDE's text editors all have word wrapping IIRC, so does GNOME 2.0's gedit. And just about any formatted text editor for Unix - KWord, StarOffice, OpenOffice, Mozilla Composer, etc. - has word wrapping.

Re: Word wrap - Anonymous - 2002-10-31

The talk is about *soft* word wrapping.

Re: Word wrap - antiphon - 2002-10-31

Well, I have been informed that the GNOMEs have fixed their soft word wrapping in their 2.x versions. (I don't really like the direction they've taken in the 2.x versions so I don't use it that much, if at all; too MacOS < 10 for me.) I still haven't had any RC1 users tell me if KDE editors will have this feature yet.

Will there be Debian packages? - Plato - 2002-10-30

Will there be Debian packages of the RC? I'd like to test them, but I don't fancy uninstalling all my Debian stuff and compiling all the new stuff.

Re: Will there be Debian packages? - Macolu - 2002-11-04

http://shakti.ath.cx/debian But I don't think they are official...

ChangeLog - somekool - 2002-10-30

is there any place to find a list of fix being apply to 3.0.9 from 3.0.8 ? just curious.... thanks

Anyone compiled it successfully in Redhat 8.0? - ciicii - 2002-10-30

I got an errror message when I compiled the QT3.1. is there something I missed? /usr/bin/ld: cannot find -lXft collect2: ld returned 1 exit status make[1]: *** [../lib/libqt-mt.so.3.1.0] Error 1 make[1]: Leaving directory `/usr/local/qt-3.1/src' make: *** [sub-src] Error 2

Re: Anyone compiled it successfully in Redhat 8.0? - Haakon Nilsen - 2002-10-30

Try installing Xft-devel.

Re: Anyone compiled it successfully in Redhat 8.0? - Biz - 2002-11-02

That doesn't work either. I am having the same problem and I have Xft-devel installed. I get this same error in Redhat 7.3 :-(. Any help on this?

Re: Anyone compiled it successfully in Redhat 8.0? - Red Hat Lover - 2002-11-04

ln -s /usr/X11R6/lib/libXft.so.1.2 /usr/X11R6/lib/libXft.so and then, in your qt-copy directory, after you make -f and configure, run: find . -name Makefile | xargs perl -pi -e 's,-lXft,-lXft -lXft2,' The linking might be optional, but I'm not about to rebuild qt to find out...

thank you... - L1 - 2002-10-31

...guys for testing this non final version. i wait for debians official packages, but because of you, they will be rock stable!!!

thank you... - L1 - 2002-10-31

...guys for testing this non final version. i wait for debians official packages, but because of you, they will be rock stable!!!

panel - L1 - 2002-10-31

what i forgot: kde is really cool, but i hate one thing: this thousands of little arrows in panel. they are ugly and useless. i got rid of most of them in kcontrol, but this ones where you get this "Move,Remove,Preferences,Panel"-menu are still there. can i comment out some lines in sourcecode to remove them??? please, help ;-)

Re: panel - Gibler - 2002-10-31

I absolutely agree with you there. Those little arrows all over the place don't look good. I know that they are useful in terms of users being able to see that they can move stuff about but they look silly. There should be a control panel option -> Hide All Arrows.

usability at work - ac - 2002-10-31

This is a trend with the usability people. They seem to think more clutter is a good thing. Same thing applies to repeating the same instructions and text all over the place. It's *not* a good thing. It's a careful balance.

Re: usability at work - Aaron J. Seigo - 2002-10-31

actually, our real goal is to piss off people who post anonymously to web boards.

Re: usability at work - ac - 2002-10-31

Apple, the usability gods, avoid clutter too. Once you learn something you don't need to read instructions over and over again. It eventually becomes counter-productive.

Re: usability at work - Aaron J. Seigo - 2002-11-03

find, ignore my joke. second, Apple has shown with OS X that they are no longer "usability gods". they have some good ideas still (and occassionally great ones) but they are far more fallible than they ever have been. in any case, your "once you learn something" argument falls down at one particular point" you have to learn it first. and that was the entire problem with removing panel applets: people never learned how to do it. they needed help learning (and remembering). they got that help. problem went away. now we just get to put up with the occasional whine of "i don't like how it looks"

Re: usability at work - ac - 2002-11-04

I wouldn't ignore those whines. I am sure there is some fundamental UI rule that says clutter and redundancy is bad. The whines are just one symptom of violating that rule.

Re: usability at work - Timothy Seymour - 2002-10-31

Retard! Opening his stupid mouth and fear posting with his real name.

Re: panel - Elliott Martin - 2002-10-31

this has been taken care of for a while...here's how to make them fade away. click on one of those little arrows, choose "Panel Menu > Configure Panel..." click on the "Advanced Options" button at the bottom. check the "Fade out applet handles" box and then click OK a couple of times. easy, huh?

Re: panel - Anonymous - 2002-10-31

KDE 3.1 has an GUI option to fade out the applet handles. In KDE 3.0 you had to change kickerrc.

Re: panel - Aaron J. Seigo - 2002-10-31

as others already mentioned, you can fade out the applets via the panel config dialog. hopefully that is satisfactory. as to why those arrows are there: there were endless reports of problems with removing applets from the panel. people just didn't clue in that you could right click on the applet handle! when the arrows were added, the number of such reports dropped practically to zero. they may annoy a few people, but they can be turned off and that is far better than a good % of users not being able to figure out how to remove applets.

Re: panel - Andras Mantia - 2002-10-31

Ok, but check out bug #49969. Andras

Re: panel - Aaron J. Seigo - 2002-10-31

i just assigned it to myself. it's a bug in the control panel, not inherent to kicker. now the question is whether it will get fixed for 3.1, or 3.1.1 ... =)

Re: panel - mononoke - 2002-10-31

it is possible to hide the applet-handles, yes, but, why do they still leave a space ?! that's really unfinished.. that should be simple accessed and work similar to WindowsXP's "Fix Taskbar", that is easy accessible by right-klick on the taskbar !!! in KDE you need to open "Kontrolcenter", that's so heavy! really Big Work. hope things like that will be finally equal to "MS Windows", since, there is no copyright on that feature! and it is just logical to change that. thx

Re: panel - Aaron J. Seigo - 2002-10-31

the patch for this logical change is available where?

Re: panel - foo - 2002-11-01

Do it yourself, it's opensource afterall. >:-p

Re: panel - Aaron J. Seigo - 2002-11-03

you've got it backwards: mononoke wants the feature, s/he should provide the patch. it isn't something high on my priority list (lots of other things are, though). the things that bother(ed) me the most about kicker have mostly been fixed, hopefully we'll get to the remaining annoyances for 3.2.

Re: panel - Matthijs Sypkens Smit - 2002-10-31

With KDE 3.0.4 I can rightclick the panel and choose 'preferences'. Just make sure you click an empty region of the panel.

Re: panel - L1 - 2002-10-31

i don't know something about the XP way, but in my opinion. i like the applet-handles (especially with keramik), but not the arrows. so this fade out thing should only fade out the arrow, not the hole applet-handle. the empty area is better then a.-h. with arrow, but not perfect. and hey, to discuss about such stupid things shows the high quality of kde 3.x!!!

Re: panel - L1 - 2002-10-31

ok, thank you for all this informations!

Re: panel - donuthole - 2002-10-31

In ~/.kde/share/config/kickerrc in the [General] section put the following: FadeOutAppletHandles=true and the little vertical bars w/ the arrows will be faded in and out, so they're not visible unless you hover over them. -steve

KdeLibs WON'T Compile - James Richard Tyrer - 2002-11-01

Is there some explaination of why a tarball that won't compile was released? Is this GCC or Qt issue? I am using GCC 3.2 and Qt 3.1 Beta 2 and I consistently get this error: khtmlview.cpp: In member function `virtual void KHTMLToolTip::maybeTip(const QPoint&)': khtmlview.cpp:247: no matching function for call to `KHTMLToolTip::tip(QRect&, QString&, QRect&)' ???? -- JRT

Re: KdeLibs WON'T Compile - Sad Eagle - 2002-11-01

You need a newer Qt than beta2 - i.e. Qt-copy or a recent rsync snapshot for that function...

Re: KdeLibs WON'T Compile - James Richard Tyrer - 2002-11-01

This doesn't appear to be a very good idea to me -- releasing a release candidate that requires an Alpha version of Qt. In any case, I see nothing here: http://www.kde.org/info/3.1.html to indicate this problem. Perhaps at least a snapshot known to work would be a good idea. -- JRT

Re: KdeLibs WON'T Compile - Anonymous - 2002-11-01

> releasing a release candidate that requires an Alpha version of Qt Alpha? Qt 3.1 already had a Beta2 release and its current state is RC1. > Perhaps at least a snapshot known to work would be a good idea. Like ftp://ftp.kde.org/pub/kde/unstable/kde-3.1-rc1/src/qt-copy-3.1_20021024.tar.bz2?

Re: KdeLibs WON'T Compile - James Richard Tyrer - 2002-11-01

>> releasing a release candidate that requires an Alpha version of Qt > Alpha? Qt 3.1 already had a Beta2 release and its current state is RC1. We would all like to think that the development process results in software improving monotonically, but I think that we all know that this is not the case -- regressions DO occur. There can be no assurance that the current snapshot is as stable as the last Beta. I checked the TrollTec web site about 10 minutes ago and couldn't find that RC1 to download. >> Perhaps at least a snapshot known to work would be a good idea. > Like: >ftp://ftp.kde.org/pub/kde/unstable/kde-3.1-rc1/src/qt-copy-3.1_20021024.tar.bz2? Yes, too bad that that link isn't posted on the 3.1 info page with the 3.0.9 tarballs. -- JRT

Re: KdeLibs WON'T Compile - Martin Gacksche - 2002-11-01

Uhm ? Sorry, you like to try out KDE 3.1 RC1 (which is also more or less something to test) but you refuse to get and compile QT 3.1 RC1 ? What's wrong with you ?

Re: KdeLibs WON'T Compile - Anonymous - 2002-11-01

> I checked the TrollTec web site about 10 minutes ago and couldn't find that RC1 to download. TrollTech doesn't offer release candidates to the public, but makes them available to their friends at KDE. Get current qt-copy and you have Qt Free Edition 3.1 RC2. > Yes, too bad that that link isn't posted on the 3.1 info page with the 3.0.9 tarballs. Yes, that could be improved. But this is no normal release, I was even surprised to see the 1 week living release candidate announced so public on the dot.

Re: KdeLibs WON'T Compile - Thorsten Schnebeck - 2002-11-03

Well, latest RC2 seems to have stabilized my combination of KDE-3.1pre, Qt-3.1pre,Xfree, Freetype. Compilation on a gcc3.2+glibc2.3.1 system was without problems. Now it looks better. Hey, I can even launch kcalc again! :-)) Bye Thorsten

Re: KdeLibs WON'T Compile - Sad Eagle - 2002-11-01

Actually, that's a pretty good idea, since Qt 3.1 beta 2 had some serious bugs for KDE. I don't think you would be able to do any meaningful testing for the RC since there are some more visible bugs in that Qt version. As for this method the error was about: IIRC, that was added by request of KHTML hackers, so fix some bugs with tooltips in webpages. And, BTW, qt-copy is generally what is known to work with KDE well -- since if anyting is broken, patches are typically applied to fix it. And this is why, in fact, Qt snapshots are used like this -- so Qt bugs affecting KDE, if any, can be found and fixed before a Qt release happens.

More on icons - James Richard Tyrer - 2002-11-02

After compiling and installing: kdeartwork, I found that I still had icon trouble. Did anyone consider backward compatibility?? It seems that: "hicolor" is now called: "kdeclasic" and "lowcolor" is now called "Lowcolor". So KDE can't find my icons. :-( So, I know, just rename the directories. I already did that. BUT, applications that install icons in a directory other than the application's are going to be looking for: "hicolor" & "locolor". So, links are necessary. But, not only for the global directory, but for all of the user: $HOME/.kde/share/icons/" directories as well. My suggestion is to change it back immediately before the problem spreads. -- JRT

Re: More on icons - Anonymous - 2002-11-02

Some icon problems have been addressed after RC1, for rest http://devel-home.kde.org/~larrosa/iconthemes.html may help understanding.

Re: More on icons - James Richard Tyrer - 2002-11-02

OK. So, the global icons are not a problem. HOWEVER, there is a serious bug here. The icon loader did NOT find: "#HOME/.kde/share/icons/hicolor/" which is were OpenOffice (for one) installs its icons, and I presume that any locally installed application should install its icons. Has this been fixed? -- JRT

Re: More on icons - Anonymous - 2002-11-03

OpenOffice icons display fine here with CVS and either Crystal or KDE Classic themes.

wheeeeeeeeeee! - montz - 2002-11-03

most annoying bug of kde is fixed! now you can wheelscroll in konquer without having to worry about comboboxes on pages!! It was really annoying on sites like slashdot.

Re: wheeeeeeeeeee! - Anonymous - 2002-11-03

I liked this *feature*. Agreed, implementation was bad. It should have better be changed to work only when one presses e.g. Ctrl instead of turning it off completely.

what about "Second"? - Joerg de la Haye - 2002-11-03

Slowness is mentioned in the article, and I do notice it while typing some input in konsole, or in any HTML formular field like this one or at google.com. Compare typing a line in konsole to typing a line in xterm and a line in the konqueror addressfield, then delete these inputs via backspace - there're lags and delay, but only in konsole. Does anyone noticed this either? I didn't have these problems in older versions of KDE, not even in Beta 2. Also if you uninstall klipper, it doesn't go away. Maybe a bug?

Re: what about "Second"? - Anonymous - 2002-11-03

Try unsetting LC_ALL. If anyone has a hint how to solve this problem, please add your solution to http://bugs.kde.org/show_bug.cgi?id=49837.

Re: what about "Second"? - Anonymous - 2002-11-05

That's now fixed in Qt 3.1 final and the qt-copy distributed with KDE 3.1 RC2.

Runs fine on OpenBSD - Jimmy Mcnamara - 2002-11-03

just finished compiling it on my OpenBSD/macppc machine. runs smothly on a 500mhz G4. klipper tends to crash from time to time though, i recon it will be fixed in due time to the release aye?.

One thing I love about Nautilus - Rimmer - 2002-11-04

are the smooth, rounded edges around the icon name (when the icon has been clicked once to highlight it). In KDE, a highlighted icon has a plain box around the icon name. Even worse, the icon name isn't even centered properly in the box. Any chance of this getting changed in KDE 3.1? :)