Originally posted by Adriano ML
View Post
Announcement
Collapse
No announcement yet.
KDE Software Compilation 4.5.2 Is Here
Collapse
X
-
-
Originally posted by Yfrwlf View PostI've never experienced 800 MBs. You might try looking at Firefox. But regardless it's always important to be watchful of optimizations. It is annoying how slow Gnome apps take to load though I very much agree there, but that may be due to pre-loading certain libraries. You could pre-load more, but have higher mem use. Ideally the most commonly used apps should all be pre-loaded though. Windows Explorer, for example, loads instantly. Perhaps "Linux desktops" could just really use some more pre-loading intelligence is all.
Comment
-
Originally posted by siride View PostYeah, the Oxygen theme is ugly and may be sluggish. Use QtCurve, which is heavily customizable (almost to a fault) and not ugly and also available for GTK+, giving you the possibility of having a unified look and feel for applications of both toolkits.
Originally posted by mat69 View Post@Yfrwlf installing themes is pretty easy in KDE, well if there were that many themes worth to install ...
Though the sound departement is really a mess if you happen to find the correct setting in systemsettings.
Originally posted by mat69 View PostBtw. most stuff a KDE application needs should be preloaded, since most use kdelibs -- not that much external stuff -- a lot of stuff should be in memory already.
Originally posted by mat69 View PostIt is often the programs themselves that are unoptimized and slow down things that way. Just when I profiled KGet I noticed so many -- completly retared -- slowdowns which I fixed mostly. Yet you have to profile and something that looks retarted afterwards might not look that way during implementing it.
So during my profiling I found also a nasty bug in the caching -- or rather non-caching -- of the icons in kdelibs and it showed me that there are multiple people who don't profile themselves. I suppose this is really a problem in the FOSS world and maybe elsewhere. People not analyzing their code with tools like valgrind, callgrind, xrestop ...
The same is true with testing, there are testcases which are broken for months and none realizing or talking about that.
Originally posted by kraftman View PostI did when I tried Ubuntu 10.04. Firefox wasn't consuming, so much of memory and I get rid of mono immediately. However, I suppose it was due to caching or something similar and if that's true it's a good thing. I was just answering some guy who was saying KDE apps consumes a lot of memory, but there's caching enabled too.
Comment
-
Originally posted by Yfrwlf View PostThen that explains the speed difference of loading apps on KDE vs. Gnome of course. Nautilus apparently has a lot of additional libraries than gnome-panel does as Nautilus takes forever to start, while as you said Dolphin's libraries are all or mostly already loaded.
But something like that has nothing to do with KDE or Gnome, rather with the tools you use, like prefetch.
Comment
-
Originally posted by Yfrwlf View PostCool, it would be mega-awesome if there was a way of unifying the theming somehow to allow for cross-DE theming for all themes, I thought wxWidgets may have been one solution and I know that such a thing may be challenging. I wonder now though if Gnome will switch to Qt if it is so much more feature-rich and nicer to program in than GTK+. One can dream. :P
This is equivalent to using a theme like Curve and being done with it, for people who want visual unity.
The FAR more important thing is that the desktop protocols and services are unified. Component embedding, window manager specifications, network transparency, you know the stuff that a DE is supposed to provide. It's not just a panel, like some people think.
Unifying DBUS was a step in the right direction. All desktop apps use it now, and this is exactly the way it should be. HAL was another good effort, which ultimately died, but the idea was correct. Akonadi is desktop-agnostic, and it could become another standard, although I don't know if GNOME people are still interested.
These things have to be standardised (and are being standardised, albeit slowly, through fdo), not the toolkit. Let people use whatever toolkit they prefer. Just make sure that they can use more advanced desktop services. Let every Linux/BSD app have network transparent file access (like KIOslaves offer on KDE, for example), easy multimedia interface for basic stuff, that sort of thing.
Then it won't matter if you use this panel or that panel, or this program or that program. Right now most of the stuff is duplicated.
Comment
-
Originally posted by siride View PostWindows NT never used cooperative multi-tasking, only Windows 3.1 and before used cooperative multitasking (although Windows 3.1 could preemptively multitask DOS instances -- treating all Windows programs as belong to a single preemptively multitasked process). All Windowses since 3.1, even including Windows 95, and certainly all of the NT line through Windows 7 and beyond have been preemptive multitaskers.
Preloading has nothing to do with preemptive vs. cooperative multitasking either. Preloading is an I/O efficiency management issue.
Comment
-
Originally posted by Yfrwlf View PostCool, it would be mega-awesome if there was a way of unifying the theming somehow to allow for cross-DE theming for all themes, I thought wxWidgets may have been one solution and I know that such a thing may be challenging.
I was able to write an app using Qt that is virtually indistinguishable from Gtk apps when it runs under Gnome, including button order, missing "apply/cancel/etc" buttons on Gnome, default keyboard shortcuts, instant-apply config dialogs, icons, etc.
If you want apps that look and behave natively regardless of desktop (and OS, even), then Qt is the only thing that works currently.
Comment
-
Originally posted by hax0r View PostThis software is unusable on most of the machines do to the unoptimized, slow, memory hungry code. It was such a pain on my laptop for the last few months, there's no word to describe it. Still has a stupid long logout and startup, plus disk grindage everywhere. Simple thing like launching kwrite requires serious disk grindage.
Comment
-
HDD sounds are produced when the disk is heavily used. I don't know, but optimal bandwith usage isn't wrong in my book.
Ofcourse the push for better tech is sometimes a "shoot first, ask questions later"-thing with KDE. 4.5 isn't the end of KDE4, so we'll see what happens. So far, I like the push
Comment
-
There was a bug with Oxygen, making it slow, that was present in all the 4.4 and 4.5 line and fixed precisely on 4.5.2. So, if your apps are running slow, first check if you are really running 4.5.2. If you are running 4.5.1 or older, you will be affected (Kubuntu 10.10 is affected: to get 4.5.2, you must enable the Kubuntu Backports PPA)
After that, if you are still experiencing slowness, change the Oxygen style to ANYTHING else. I had amazing results with Bespin, despite its theoretically higher tax on the system, due to improved animations.
Finally, KDE is indeed a heavy moving object. Don't expect it to run fast the first time you turn it on; it will index your drive and you'll think it's slow as hell. Give it half an hour. The full text index of your HDD and your mails will be done, and your system will be fast. If it keeps trashing your HDD, increase the memory available for Virtuoso (it defaults to 50 MB, if you have gigs of RAM, 192 MB is a good choice).
Comment
Comment