Announcement

Collapse
No announcement yet.

KDE Software Compilation 4.5.2 Is Here

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Adriano ML View Post
    If you're experiencing lag in KDE, disable the composition.

    If it still does not solve your problem, use a different widget other than Oxygen.

    I also notice that some systems, mainly nvidia binary drivers enabled ones, tend to leak a bit of memory. In contrast, my Intel GPU netbook idles nicely at around 170MB after lots of programs have been used and closed.

    I would also like to note that you can use GTK network manager with KDE. It's not Gnome exclusive. This happens automatically if no other kde front-end is installed.
    Yeah, 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.

    Comment


    • #32
      Originally posted by Yfrwlf View Post
      I'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.
      I 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


      • #33
        Originally posted by siride View Post
        Yeah, 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.
        Cool, 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

        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.
        Sound theming is a definite disaster still, glad to hear DE graphics themes are easier though for KDE. I wish devs working for and working with the community surrounding Ubuntu would put more effort into major improvements like that, and not to fan the flames but RedHat/Fedora definitely seems to put way more effort into things like that, major desktop improvements, while Ubuntu is more busy with icing. Network Manager is Red Hat and Novell...I think the Sound Preferences util was Red Hat but not sure.

        Originally posted by mat69 View Post
        Btw. 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.
        Then 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.

        Originally posted by mat69 View Post
        It 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.
        Nice, hopefully profiling tools will become more commonly integrated into IDEs so help devs profile more frequently.

        Originally posted by kraftman View Post
        I 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.
        Yes, it's very important to understand the different types of memory and what kind(s) your memory monitoring tool of choice is showing you. RAM definitely shouldn't go to waste if you can help it, but ideally you want to monitor user behavior and attempt to pre-cache things that will be of use to them. A dumb pre-cacher that loads a lot of things a user never ever uses will just be wearing out a computer and wasting electricity.

        Comment


        • #34
          Originally posted by Yfrwlf View Post
          Then 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.
          In fact still a lot could be preloaded, though that would be application specific then, e.g. loading an application into ram because you use it often.
          But something like that has nothing to do with KDE or Gnome, rather with the tools you use, like prefetch.

          Comment


          • #35
            Originally posted by Yfrwlf View Post
            Cool, 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
            I have zero problems with different graphical toolkits. ALL operating systems, including MacOSX and Windows have this situation, only they do not support theming as extensively as Linux toolkits do, and have a clear standard that everyone adheres to.

            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


            • #36
              Originally posted by siride View Post
              Windows 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.
              I did not know that. See, told you I wasn't an expert

              Comment


              • #37
                Originally posted by Yfrwlf View Post
                Cool, 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.
                Currently, only Qt supports that. Apps using it will look like any other Gtk app on Gnome, XFCE or other Gtk-based DEs.

                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


                • #38
                  Originally posted by hax0r View Post
                  This 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.
                  Haven't noticed this, but that would certainly explain why KDE keeps messing with my hard drive accoustic management settings every time it starts...

                  Comment


                  • #39
                    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


                    • #40
                      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

                      Working...
                      X