KC KDE #24

Wednesday, 7 November 2001 | Aseigo

Issue #24 of KC KDE is available. Summaries include coverage of KDE language bindings, Synchronous KIO, ALSA and aRts, KPilot, CSS Media support, the new DCOP tools and more.

Comments:

Shutdown - Matt - 2001-11-07

In Mandrake 8.1 there is an option to shutdown the computer when logging off. I guess they added that to KDE themselves. It's nice and I use it all the time.

Thanks Aaron - KDE User - 2001-11-07

We've all said it, but thank you for these wonderful development summaries! It just goes to show you how alive and robust and exciting the wonderful world of KDE development is. Thanks for keeping us up to date.

KMail and KNode? - John - 2001-11-07

Is my memory playing tricks on me, or did I read some time back that KMail and KNode were going to merge for KDE 3.0? Or was it just a code share? KNodes threading and scoring is a delight to use, and I would really welcome that in KMail. John

Re: KMail and KNode? - Joe - 2001-11-07

I noticed that KNode has e-mail support. That's new, right?

Re: KMail and KNode? - Bryan Feeney - 2001-11-07

In as much as possible they're going to share the same code,e.g. message display (using a KPart I think) so there's no duplication of functionality. There's no chance of them merging though, most of the KDE developers prefer to have a separate app per function. It would be nice if some-one duplicated the KOShell with Kmail, KNode and KOrgainiser parts though...

Re: KMail and KNode? - John - 2001-11-08

I agree that for most things individual apps are best, but that's not necessarily true all the time, and each case should be judged on its own merits. In this case I think a combined app would be a good thing. Being able to save News articles and emails of common interest side by side in the same folder would be a very useful for me. You'd only have one folder hierachy to manage, and finding/searching for information would benefit too.

Re: KMail and KNode? - Michael Collette - 2001-11-10

Being able to save messages from the usenet into a mail app does not require both of these items to be the same application though. It would require KNode to be able to save messages to KMail folders. More chit chat between the two applications would be sweet, but I wouldn't want to see a Mozilla style solution making them the same application. This is similar to the notion of how KMail pulls from KAB to get addresses, or KNode now offloads sending E-Mail through to KMail. Better integration, not a merger.

Re: KMail and KNode? - Guillaume Laurent - 2001-11-08

On one hand I agree there's a clear need for a relatively simple mail reader like kmail, and an also relatively simple news reader like knode. However, it's also quite clear that there's a great need to have a single app dealing uniformly with both. Maybe aethera will eventually deliver this...

"sleep" option from KDM - JC - 2001-11-07

I want the option to put my computer to sleep for the night from within KDM!

Re: "sleep" option from KDM - Mike - 2001-11-07

Is this a joke ? Sorry, if it sounds harsh, but what do you mean with "sleep" ? Power management ? This is a kernel issue: It should put your computer into power-save-mode after 30 min for example if there is no user activity. You mean s.th. like "shutdown -z", see "man shutdown" for further details. Mike

Re: "sleep" option from KDM - Aaron J. Seigo - 2001-11-07

on my laptop a command that gets used fairly regularly is "apm -s" and it would be nice if this was available in KDM and the logout screen of KDE.

Re: "sleep" option from KDM - JC - 2001-11-07

Sorry I wasn't clearer - Access to "apm -s" from KDM is exactly what I'm asking for. I don't even have a laptop, but rather a desktop machine. I live in California where power is expensive and in short supply, why be wasteful? I can't run "apm -s" from an xterm because that leaves me logged it and since I've got multiple users, I may not be the user that wakes up the computer! (there is probably a way to work around this, but that's not the point). Currently I set up my BIOS to put the computer to sleep automatically after a couple of hours, but this tends to screw me up during long FTPs when there isn't any keyboard/mouse activity. A "suspend" option next to "logout" and "shutdown" in KDM would be very nice. Windows 2000 does something very similar that I use regularly at work.

Re: "sleep" option from KDM - Anonymous - 2001-11-07

Now if it's really about Energy-Saving: Turn off your computer and unplug it! If you run it in suspend mode (or even soft-off) it will consume energy for up to 100 USD/year.

Re: "sleep" option from KDM - kidcat - 2001-11-08

What about us folks with SMP mashines? (multiprocessor machines) ... someone must have seen this comming out of the kernel at boottime: "APM is not SMP safe... omiting" (or somthing really close to that, cant check right now since im on a freind's 'net) So a way to tweak it would be in order. I imagine somthing like: # KDM cfg shutdown_exec=shutdown -h now sleep_exec=apm -s # /KDM cfg this would give me an opotunity to write a script that spins the disks down and shuts of the monitor... and hope HLT instructions kick in :-) /kidcat

wishes - Iuri Fiedoruk - 2001-11-07

Some wishes I have for KDE3: putting the new ksplash that there is at kde-look.org, it's really kool. putting a shutdown option on turning kde off should had already had on kde2 IMHO but, most of anything speed. YES I KNOW about the problems with c++, but why they happen? Because of too much libs and fat programs. Can't they try to simplify more the apps? I mean in source level, I know how a program can get REALLY better after 2 or 3 partial rewrites, because during the time you are programming the thing you learn a lot, and the original code aren't optimized as it could because the programmers didn't knew much, this really happens, even with skilled programmers, and happens more with open source and newbie programmers. So it would be a good idea simply programmers getting a look at old code and trying to clean it a lot after adding new functions. (remember, I'm not saying all programmers do it, but some do, I do) :)

Re: wishes - not me - 2001-11-07

> putting the new ksplash that there is at kde-look.org, it's really kool. Which one? There are tons at kde-look.org. The development version does have a new spash picture, it is Konqui on an orange and green backround and it says KDE 3.0 Coming soon to your desktop, or something like that. KDE 3 will definitely have a new splashscreen. > most of anything speed. YES I KNOW about the problems with c++, but why they happen? Because of too much libs and fat programs. No, they happen because the GNU linker is inefficient. They have nothing to do with "too much libs." Shared libraries are *good* because they reduce program size.

Re: wishes - off - 2001-11-07

he is talking about the ksplash replacement PROGRAM. it is pretty neat. all it needs is some UI tweaks in the kconfig. it'd also like to see some of the better code styles in kde-look make it into KDE, such as Qnix, Liquid, and KBox.

Re: wishes - Johann - 2001-11-08

The ksplash replacement program is here : http://www.kde-look.org/content/show.php?content=391 "it'd also like to see some of the better code styles in kde-look make it into KDE, such as Qnix, Liquid, and KBox" Yes, me too. Especially Liquid. Or better...

Re: wishes - Bryan Feeney - 2001-11-08

A point Mosfet raised at some point, which I think would be really useful, would be to add an alpha channel to the theme format so you could have translucencies in normal pixmap themes instead of having to write a custom engine like Liquid. Then we'd have one *foxy* desktop. Better yet, how's about doing the same thing for KWin themes, so we could have shadows under the windows too? Course I suppose this'll all have to wait till KDE 3.1

Re: wishes - kidcat - 2001-11-08

I want this too!!! The most users I have convinced that KDE is better fell in love with it because of the looks in it. Please hear my plea thy great and over-worthy developers: beg-beg-beg-please-please-please get this in before the code freeze... pease? pro: this would give us an extra point in comparisons like the one posted here on mon-nov-05 con: it would take some time from some more important things... but from what i've seen so far u guys knows some sort or magic? (can I get a copy of your bible: "how to become an enormously productive and cool hacker in no time at all") /kidcat

Re: wishes - lanbo - 2001-11-07

I also agree. KDE is so slooooowly....:-( I keep using it but the shitty windows 2000 it's a lot more responsive in the same machine. Explorer for example loads in a flash, the same with the file manager... Everybody is blaming the GNU linker, but the thing it's that maybe this is not the only reason. We should also review the KDE code. Please. Stability it's OK. KDE doesn't crash, next step it's speed and we should do this now. What about spending 6 months only in optimization of the code? It doesn't necessarly means that we would stop adding features, but concentrating a little bit more in the already written code, improveing it where possible... Please, please, please, just think a little bit about that.

Re: wishes - Greg - 2001-11-07

Explorer loads in a flash because it's part of the Win2k kernel. If konqueror was in the linux kernel - it would load just as fast (if not faster) than Explorer does in Win2k. Of course, putting konqueror into the kernel would be dumb. Your best hope for speed is the prelinking patches.

Re: wishes - L.Lunak - 2001-11-08

>Your best hope for speed is the prelinking patches. Actually, prelinking (not the objprelink hack) will be hopefully part of glibc-2.3 .

M$ double standard??? - Chris Bordeman - 2001-11-08

Huh? My IE and Explorer crash constantly, and on W2K at least, this NEVER brings down the entire system, it just automatically restarts. So if it is true that IE runs in the kernel, then it is at least done very well.

Re: M$ double standard??? - emmanuel - 2001-11-08

obviously (IMHO) IE is not in the kernel. however, it may be that MS made special entry points specially for it (i heard they did that for IIS as well). well, just rumours...

Re: wishes - Otter - 2001-11-08

>Explorer loads in a flash because it's part of the Win2k kernel. >If konqueror was in the linux kernel - it would load just >as fast (if not faster) than Explorer does in Win2k. Under MacOS, IE also loads really quickly and it certainly doesn't have any priviliged status there. It loads much faster than Konqueror running on the same hardware under Linux, and far, far faster than Mozilla on MacOS.

Re: wishes - Rayiner Hashem - 2001-11-08

Don't be retarded. Of course, Explorer isn't a part of the Windows 2000 kernel! Explorer is a userspace application just like everything else. Even if it gets preloaded at startup (like Office supposedly does) it shouldn't make a difference after the first run, because the (superior) Linux filesystem cache will have kept the data in RAM. KDE-2 is great, but its really bad speed-wise (of course, so is GNOME). Just resizing windows (using the very fast DotNET theme I might add) is enough to give my poor 300Mhz/256MB computer fits. In Windows, even complex apps like visual studio resize faster than I can move the freaking cursor. And don't blame X either. ROX-Filer (which uses GTK+) also performs really well. And its not Qt. Qt on Windows performs almost as well as native Win32 widgets.

Re: wishes - Aaron J. Seigo - 2001-11-08

if resizing windows is too much for your system, turn off the setting to show contents in windows when resizing (in Look 'n Feel -> Window Behaviour IIRC). it's that simple. and i do believe that this is an X related issue. as for Linux caching files in RAM making for faster subsequent execution, this does not (e.g. can not) affect run time issues such as linking. education ... _then_ open mouth.

Re: wishes - Thilo - 2001-11-08

this is a valid point - windoze (any version) can resize windows a whole lot faster than kde. also: try to take a window an move it around, quickly. i am running on solaris here, and it sure does not respond at all. at home und linux it is a lot better, but it does not even come close to snapiness windoze shows. on the other hand try the RMB-menu in win2k - its dogslow. basically my experience (ie. feeling) is, that startup times are slower in kde while application responsiveness (after app load is completeted) is faster. and graphics (like moving or resizing windows) is (a lot) faster in windoze. with todays prices for ram, i keep many apps in ram. Thilo

Re: wishes - Thilo - 2001-11-08

> windoze (any version) can resize windows a whole lot faster than kde. let me restate this: in windoze resizing is a whole lot faster than in kde/x11/linux

Re: wishes - Beubeu - 2001-11-08

Try to disable Hardware Acceleration in windows (Somewhere in Display Properties) and you will see that moving/resizing is not so fast. And I think there is no hardware acceleration for stuffs like that with X/KDE, at least not with my graphics card (Neogagic 128XD). But I think that sooner or later XF will provide efficient hardware accelerations for stuffs like scaling, and hopefully softwares such as KDE will greatly benefit from that. BW

Re: wishes - Thilo - 2001-11-08

yeah - that is what i think too. and i am glad that there are great guys working on making X even better. but for a "normal user" all the technical stuff does not really matter - he sees how "slow" (or not-hardware-accelerated) window resizing in KDE is, and concludes KDE (or Linux for that matter) is slow. i mean: it's not like i resize my windows the whole day, right?! often its more a question of how it "feels" - and long startup times and slow window resizing / moving make a system feel slow. still, i prefer KDE over any windoze (or desktop for that matter). Thanks to the brilliant minds behind it!

Re: wishes - not me - 2001-11-08

Acually, XFree86 does have hardware acceleration. There is just a problem with resizing windows. Something interesting to note, though, is that Windows XP is *much* slower at resizing windows than previous versions of Windows. It is almost as slow as KDE.

Re: wishes - emmanuel - 2001-11-08

let me reassure you... they did not wait to look for that. kde2.1 was noticeably faster than 2.0 for me, 2.2 even more. so, they did not "forget" (!!) about that issue... (by far). if you have ideas on how to make it even better, though, you are welcome. but kde developers are already doing a lot. PS: such messages are useless and rather irritating for developers (i remember a message in which some kde developer got really upset "what do you think we are doing? rolling our fingers????"), and they are not wrong either. so thank you already for the improvements and looking forward to see even more of them!!

Re: wishes - Aaron J. Seigo - 2001-11-08

first of all, as somebody already stated, the developers most deffinitely do not "forget" about speed when coding. to say such a thing is an unjustifiable slam on the people working on KDE. now, for some answers (hopefully =) to your questions. .. during the software creation process, correctness is first and optimization is last. if you pay attention to correctness, not only do you get robust apps (which is more important than speed) but you also get programs that can be optimized much more agressively later on, since the algorithms in use are efficient and designed for future optimization. are these optimizations occuring? compare the speed of 2.0 to 2.2.1 and i think you'll have your answer. with kde3, the libs are being streamlined in ways that have not been possible since 2.0, since binary compatibility is now allowed to be broken. there are even hackers that have been hired full time solely to work on efficiency issues in kde3 (lubos lunak comes to mind; thanks SuSe!). kde3 also marks a new point in robustness and completeness for kde, which means the optimization phase is just begining for some components/apps. finally, it is not a myth that the GNU linker is to blame for most of the start up time in a KDE app. with prelinking apps start up much faster. an alternative would be to statically link all the apps so there are no relocations due to shared libs, but this increases the total memory usage of the desktop as a whole, probably by several times for most users. this in turn causes new types of efficiency problems (including, but not limited to, slowness due to swapping). so static linkage is not a win. instead, efficent shared library linking (which includes prelinking) is the answer for that part of the speed puzzle.

Re: wishes - Iuri Fiedoruk - 2001-11-08

I do agree, but notice that KDE is progressing to a new version that can (or not) be slower than 2.x because of tons of new features BEFORE getting 2.x at a decent speed. I really don't want to blame developers, just point that the're "putting the car before the bulls".

Re: wishes - Aaron J. Seigo - 2001-11-08

well, i can't notice it since that isn't what is happening at all. 3.x is merely a port of 2.x. 3.x is a step towards making 2.x run at a "decent speed". personally, i'm fine with the current speed on my pII 400 w/256MB RAM, but it can be better, and the developers are working towards that. this perception that developers simply pile one tons of features without also doing optimizations, cleanups, etc is complete nonsense. each release of KDE2 was faster, and if you actually track the devel lists you will know why. as a point in fact, a commit was made to CVS just today to speed up klistview so that traversing a 5k long tree dropped from 800+ ms to <30ms. that sort of stuff happens rather regularly and is deffinitely what i would call "optimizations to make things run at decent speeds".

Re: wishes - Iuri Fiedoruk - 2001-11-09

heheh, you're right. What people simply wanted was that KDE team stopped for a while focusing more on speed than new features. And I am not confortable with KDE speed on a k6/2 500Mhz with 192 RAM, probaly because of the lack of obj-relink on redhat's rpms :( But let's wait and hope that KDE3 comes with lots of speed inprovements and not link 2.0 - the way 2.2.1 is way faster than 2.0 show that the speed work was done too lat IMHO

Re: wishes - Aaron J. Seigo - 2001-11-09

actually, it shows the speed work was done at the right time: post-stability. you can't do it before then, really. and yes, 3.0 will be faster than 2.0 was. 2.0 was a completely new architecture, which means tons of new code that lacked lots of real world testing and very little in the way of optimizations. 3.0 is 2.2 ported to Qt3 plus a few new features, so expect the sort of improvements we would normally have seen with a 2.3.

Re: wishes - aleXXX - 2001-11-08

About the gnu linker: konsole loads on my system in approx. 1.9 seconds. 1.5 seconds from this time are spent before the app enters main(), i.e. in the linker. Bye Alex

Re: wishes - Aaron J. Seigo - 2001-11-08

konsole is a great example of work being done to speed up KDE apps. in 2.0 konsole took quite a while to start up. a lot of work went into speeding it up and it really, really shows. load times dropped from >4s to <2s on my system. truly impresive. thanks for the hard work, it really paid off!

Re: wishes - Corba the Geek - 2001-11-08

I've only just turned off the "introduction" screen in konq. I didn't think doing so would make so much difference. Down from around 5 secs to 1,5 secs (Celeron 400, loads of memory). Konsole is certainly a lot quicker.. although doing ( konsole &) ; ( xterm & ) Is quite interesting... If I unset DISPLAY am I measuring the prelinking time? 0.02 secs for xterm, 0.51 secs for konsole.

Re: wishes - Aaron J. Seigo - 2001-11-08

w/out $DISPLAY i believe some code in main() is still executed, but extremeley little. almost everything you see in your number is linking AFAIK. scary, isn't it?

Re: wishes - aleXXX - 2001-11-12

For measuring konsole speed I use time konsole -e exit Bye Alex

Re: wishes - Rayiner Hashem - 2001-11-08

The best thing you can do to reduce program size is not stuff so much cruft into the programs! I'm sorry to say this, but the high-point of program evolution was reached in Windows NT 4.0. It provided just the right amount of features (object embedding, etc) at just the right "bloat level." These days KDE offers NT-4 features at WinXP bloat-level, and I don't see it getting much better from here on in. I think the BeOS coders had the right idea. Force all developers to work on slow machines so everyone will be pleasently surprised to see how fast things run on normal systems. PS> And no, features and speed/bloat are not inherently at odds. One just needs to be willing to take a little time out of implementing features to make things fast. It makes development go slower, but as Linus himself will tell you, that's often a good thing. Something like an alternating feature/quality cycle would be great (in essance, isn't that what major/minor releases are for?) That way you would do a major release with tons of new features, and then spend a year making the code top quality, then repeat the whole process.

Re: wishes - not me - 2001-11-08

Why does everyone think that the KDE developers are totally oblivious to performance issues and must be told how to develop KDE or else they'll get it wrong? The developers know that performance is important. They are always improving the performance (as can be seen by the progress from 2.0 to 2.2). They do not need to be told that they should develop a different way to get more code speed. If the progress is not fast enough for you, then buy a C++ book and get hacking! The current KDE developers already are going as fast as they can, and the progress is visible. "Something like an alternating feature/quality cycle would be great (in essance, isn't that what major/minor releases are for?)" In essence, isn't that how every major/minor KDE release has been? What is the problem? "That way you would do a major release with tons of new features, and then spend a year making the code top quality, then repeat the whole process." Yes. That's the idea of KDE's release schedule. They don't need to be told this, because they are already doing it!

Re: wishes - Aaron J. Seigo - 2001-11-08

please give some specific examples of this supposed "cruft". bonus points if you can offer how it should be fixed.

Re: wishes - Rayiner Hashem - 2001-11-08

1) DCOP. It's really cool and nifty and all that, but it is in essence just an ICP mechanism. There is a lot of overhead in DCOP, involved mainly in turning messages into function calls, that don't exist with a pure messaging system. Most ICP systems can easily pass a hundred thousand (small) messages per second around on a modern system, while DCOP is somewhere in the tens of thousands. By switching to a pure messaging model, you might lose some of the niftyness aspect (everything is an object and I can make remote function calls!) and it might not be quite OO in terms of programming, but you'd get rid of a lot of cruft. 2) aRts. There is no real need for a sound server these days (except for networked audio, and that's a special case). Sound servers are throwbacks to days when most Linux audio drivers didn't do hardware mixing, and a program had to do it in software. These days, almost everything has an ALSA driver (which can emulate software mixing for cards the cards that don't have programming specs for their mixer) and newer Open Sound System drivers (like the SB Live!'s) support hardware mixing as well. Plus, aRts doesn't provide a nice interface to hardware DSP features and such. Now, the other part of aRts, the media-framework, is quite nice. However, it could be implemented much more efficiently using a generalized messaging system and shared memory instead of MCOP. 3) I/O slaves. I/O slaves provide an interesting functionality, but they could better be implemented as shared modules with async I/O.

Re: wishes - Rayiner Hashem - 2001-11-08

Re: wishes - Aaron J. Seigo - 2001-11-09

1: DCOP <nitpick>first, it is IPC (inter process communication) not ICP.</nitpick> RPC is not an optional item for a modern desktop to function effectively, as are many of the rest of DCOPs features. the ability to transmit 1000s of msgs per second is quite fast enough for its application: a graphical desktop. if it were a large transaction server it would be too slow, but that isn't its purpose. in fact, DCOP was created as a faster and more stable alternative to the CORBA tools they were using early on in KDE2's development life. creating a DCOP client takes extremely little time and only requires ~100K of RAM across the entire desktop, so it isn't a start up time or memory problem. and it does all of this with a rather clean interface that integrates well with the rest of the KDE framework. the overhead in DCOP you refer to is not really due to RPC but in the use of strings in the msgs and the fact that it is mediated by a server (vs direct process <-> process comm). but even then it still isn't bad enough to be an issue in a desktop setting, and the benefits of doing it this way outweigh the problems. for some decent info on the performance issues with dcop take a look at: http://www.arts-project.org/doc/mcop-doc/why-not-dcop.html 2: aRts ... i'm not into multimedia so i shouldn't comment on this one... 3: I/O Slaves. well, they are shared out-of-process components that provide async I/O (and recently Charles Samuels released an early version that does synchronous if you need that). so i don't see what your gripe is there as it does exactly what you suggest. making them shared libraries wouldn't improve anything. out of curiosity: have you actually developed for KDE at all?

Re: wishes - Carlos Rodrigues - 2001-11-10

I guess you're somewhat right about the hardware mixing thing, aRts should be able to use the multiple open capabilities that some audio drivers/cards provide. Think of it as hardware acceleration, that's what DirectSound does in Window$.

Re: wishes - Julien Olivier - 2001-11-08

Just remember that we (you, me and all kde users) are just USERS. We are not KDE developpers' bosses ! So, stop saying "your apps are slow ! Please make it faster ! That's bloated etc...". In fact, we all have three options: wait for developpers to do what they feel better (if they want to...) OR make our own patches and apps (<irony>of course FAR better than the ones they have already done</irony>) OR use anything else (including MS Windows / MacOS & co.). What I mean is that we all should always remember that we've not bought anything so we can't expect anything from anybody. I hope this point is clear for everyone. And for active KDE developpers, good luck in your already impressive work.

Re: wishes - Julien Olivier - 2001-11-08

sorry about the 3x post

Re: wishes - Iuri Fiedoruk - 2001-11-08

replying multiple times happens, no problem. About your comment, I do agree, It's like like we're screaming against developers, it's just that "asking dosen't hurst anyone". :-)

Re: wishes - Iuri Fiedoruk - 2001-11-08

What really hursts is my english when writing fast, what I really meanty is: It's NOT like like we're screaming against developers, it's just that "asking dosen't hurt anyone". Sorry for the errors.

Re: wishes - Rayiner Hashem - 2001-11-08

Well, there are two ways to look at it. First, one could say that this is just a hobby of the developers and they can take the project wherever they want. Or, one could say that OSS developers should be treated just like any other developer, and they have a responsibility to listen to the requests of their users. Both points have their merits, but I'd tend to agree with the second one. The advantage of open source is supposed to be good software plus freedom. If the software doesn't do what users want it to, I think some (friendly!) criticism is warrented. I can complain to Microsoft, so why can I complain to the KDE developers?

Re: wishes - not me - 2001-11-09

>Or, one could say that OSS developers should be treated just like any other developer, and they have a responsibility to listen to the requests of their users. Both points have their merits, but I'd tend to agree with the second one. You are in the minority then. OSS developers should not be treated like any other developer. They didn't get into OSS to benefit YOU, they did it for their own reasons. They have no responsibility to you except what they take on themselves, of their own free will. Constructive criticism can be good, however if you are not a KDE developer yourself and you start making broad statements about how things are being done the wrong way you're not making constructive criticism. You simply start repeating what others have said before, and it adds to the noise. Then people get upset :-( If you're really concerned about the direction of KDE development, you can first of all find out why it is being done the way it is. If after that you still disagree, you can take your now constructive criticism to the developers, and have a reasonable discussion. Saying there's too much "cruft" in general is not constructive, and rather inflammatory.

Re: wishes - aleXXX - 2001-11-09

I think most developers are happy about feedback for their apps, good news and bad news. And many developers will probably also put wishes from users in their TODO, but they will always use their own priorities. If a wish is not on their top priority, well, you have to wait. But even this is better than closed source, did you ever post a feature request to MS ? And even better, if you are skilled enough, you can even try to do it yourself :-) Construtive criticism is good, it helps improving the software. Screaming "it sucks ! ", "it is bloated and dog slow !", "why did you put so much cruft in it ?" doesn't help anybody. Bye Alex

Re: wishes - aleXXX - 2001-11-09

Re: wishes - Iuri Fiedoruk - 2001-11-08

Ok, I forgot one to be done after the speed. I wish KDE and Gnome adn whatever-x-app, just behave and look similar depending on withc style/desktop env. you are using. Simply put: kde apps shold reconize themes and look prefs from gnome and vice-versa. Example: on kde you choose to toolbars having only 22*22 icons without text. Gnome apps opened inside a running kde should automatically use 16*16 or 22*22 (I don't know if gnome have 22*22 buttons) without text! This would be a BIG improvement to people start seriously thinking in using linux/kde/gnome at offices.

Re: wishes - Antialias - 2001-11-08

>putting a shutdown option on turning kde off should had already had on kde2 IMHO< KDE 2.2.1 here. Right click on desktop. Options I have here: logout, poweroff, reboot. >but, most of anything speed< KDE 2.2.1 'out of the box' IS fast. No wallpaper, no pixmap themes & styles, no antialiasing, no big icons, no nasty effects etc. It is a matter of choice. More money, more funny. If you want speed and all these effects and eye-candy invest in fast hard drive (which many people don't have), faster processor, and more RAM, more RAM, more RAM). Or when you make comparisons try to run Windows XP and KDE-2.2.1 on 64 Mb RAM, or Windows 98 and KDE-1.1.2 on 16 Mb RAM and tell me which one is faster. P.S. many people have a feeling that resizing KDE apps is so slow just because they use slow resizing animation.

Re: wishes - Rayiner Hashem - 2001-11-09

Or you could try WinXP and KDE 2.2.1 on 256MB of RAM and see which one flies! (XP, of course). I love KDE-2, but its slower than Win2k/XP on any config with enough RAM.

Re: wishes - Rayiner Hashem - 2001-11-09

Or you could try WinXP and KDE 2.2.1 on 256MB of RAM and see which one flies! (XP, of course). I love KDE-2, but its slower than Win2k/XP on any config with enough RAM.

Re: wishes - Aaron J. Seigo - 2001-11-09

including SPARC and PPC configurations? heh. (sorry, couldn't resist) on a more serious note i find that a compiled-from-source KDE to be markedly faster than most of the binary packages out there, which is unfortunate since most people's impression of KDE comes only from binary packages. but when it comes right down to it, what really matters is which environment allows you to get the most work done in the least amount of time and agony.

Re: wishes - Michael Collette - 2001-11-10

XP may very well be faster... with one itsy bitsy desktop. Running 10 of these babies on KDE on this PII-400 laptop, and it runs great! Compiled from source on FreeBSD. Thank you ports tree! :) While on the subject, are there any benchmark comparisons for desktop performance between the various distros as well as the BSD's? You'd think some folks would be curious about this point enough to actually do something like this up. Hmmm, got me an old PII-350 here that needs playing with.

Re: wishes - Michael Collette - 2001-11-10

wow, calm down all - Bharat - 2001-11-08

I think the KDE guys have done a great job till now. Ok KDE is not the best when it coems to speed, but it's not too bad, c'mon guys after all, Explorer is still far from being stable though it may be fast and it 's reached Version 6 and still ain't perfect! I don't really have a gripe against Microsoft, i feel what they do is strictly their own business, if they want to dig their own graves the way Apple did, they are welcome. but i believe in using what is best in the market, and as far as I can see KDE wins in comparision to all other Desktops including Gnome which I was using for a while. But I do wish you guys could improve the looks of this thing, I mean it is handsome, but liquid or Mac OS X is stunning. But anyway congratulations on creating a Desktop that doesn't suck.

Re: wow, calm down all - kidcat - 2001-11-08

touché! And when KDE 3.1 or 3.2 hits Planet Earth... whooohaaa! And lets not forget: KDE has an *impressive* framework which are a bliss for developers. And when an aceptable speed level is gained the world will be taken by storm... simply because things were done in the corect order: stable base, ease of use, ease of development, SPEED! (as oposed to 'that other guy's' system which is somewhat fast and nothing else!) /kidcat

Re: wow, calm down all - limaCAT - 2001-11-08

And when the new gnu linker which is C++ libraries friendlier will touch the earth... Woooooooooooaaaaah! :*) Other desktops teams will begin their transition to be more Kde compliant :*) (at least, it is my dream ^_^)

OT: kalliance? - me - 2001-11-08

has anybody recently had a look at http://www.kalliance.org? Seeing this site does not exactly make me happy... Any news about them?

Re: OT: kalliance? - kidcat - 2001-11-08

If u go to google.com and enter "www.kalliance.org", google will give u an option called "view google's cache of www.kalliance.org"... unfortunately that page seems to be from the early devel days :-( If u try to find them on www.ripe.net u get this: % This is the RIPE Whois server. % The objects are in RPSL format. % Please visit http://www.ripe.net/rpsl for more information. % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html %ERROR:101: no entries found % % No entries found in the selected source(s). Beats the crap out of me.... /kidcat BTW: was it a good site that just missed my attention?!? (HATE when it happens :-)

Re: OT: kalliance? - kidcat - 2001-11-08

DOOOH!!! www.ripe.net is for IP numbers... BUMMER!!! RTFM kidcat... and then start acting like ur in the know. LOL /kidcat

Re: OT: kalliance? - JohnAsh - 2001-11-08

The google cache is fine and all, but not completely ideal to check dead websites. For complete mirrors with graphics and everything, see http://web.archive.org/. Old www.kalliance.org pages are mirrored there.

Re: OT: kalliance? - me - 2001-11-09

Well, what I wanted to know was what the heck happened to them! What about magellan, the "root" of aethera? What about the developers? Have they given up? Is somebody else now maintaining magellan? I would simply have expected to hear some news about that, it showed so much potential!

Re: OT: kalliance? - Ian Reinhart Geiser - 2001-11-09

This happens a fair amount. Many projects start with grand vision no direction. Really magellen and kalliance are a waste of bandwidth and time. The developers of these projects are obviously not in the mood to work on these projects, so we should not care about them. Really I think we should care about projects like KMail. As much as it has problems, at least there are skilled developers working on the projects. We see the first step in most newbie KDE developers is to try to write: a) and outlook like client b) a kde installer c) write many many emails talking about a cool project that will never exist... Then they go on and start do something useful. Sorry for my jaded view, but I have no real respect for an email that talks about a new wizbang feature that does not include a patch. I mean there are a few but people like Waldo and David do not count. Just look at the cvs commits and you will know who to take seriously. In short advise for people getting started in KDE, start small. Do a dock applet, or a Konqi plugin. Most KDE core developers got their starts writing really small applications. I am not trying to discurage people here, I am trying to get more successes in open source so we dont have embaresments like kalliance or megellan haunting us... -ian reinhart geiser

Re: OT: kalliance? - aleXXX - 2001-11-09

Well spoken ! Alex

yep - dig - 2001-11-08

Issue #24 of LB LFR is available. Summaries include coverage of LFR language bindings, Synchronous LOP, SKDS and bTyd, LPilot, VDD Media support, the new FVPO tools and more.