Announcement

Collapse
No announcement yet.

Firefox Might Finally Be Moving Closer To Better KDE Integration

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

  • #11
    I guess it's a chance for Firefox to pick up the ball that Google Chrome dropped. Chrome simply raised a giant middle finger to Linux users when they switched away from Gtk. They now use their own GUI toolkit (I forgot its name) that does not integrate AT ALL with Linux. It looks as alien as running a Windows application in Wine.

    Comment


    • #12
      Originally posted by RealNC View Post
      I guess it's a chance for Firefox to pick up the ball that Google Chrome dropped. Chrome simply raised a giant middle finger to Linux users when they switched away from Gtk. They now use their own GUI toolkit (I forgot its name) that does not integrate AT ALL with Linux. It looks as alien as running a Windows application in Wine.
      Neither mozilla gives much of a fuck about Linux but thats another story. In an ideal world we would have ports for all the toolkits (since XUL is supposed to be able to do that) wayland support and thunderbird wouldn't look like it came from 2005.

      BUt i understand. We are just a minority.

      Comment


      • #13
        Originally posted by rob11311 View Post
        A Qt based FF would be nice, I'm just not sure where/what is going to motivate the effort. On Desktop RAM has grown faster than FireFox memory consumption, just tried visiting same pages/tabs with Reqonq for a comparison and it did save 200MB overal, with more shared; but that's freshly started without all the Add Ons, syncing and vast bookmark collection that the frontline browser accumulates.
        I don't understand your point. Qt uses more RAM than Gtk, therefore a Qt-based FF would be even heavier than the gtk-based one?

        Comment


        • #14
          Originally posted by 89c51 View Post
          Does this mean we might see a Qt port of FF in the future
          To my knowledge, there have been at least two attempts to port FF to Qt, and both failed. Don't bet on any results this decade.


          Originally posted by curaga View Post
          I don't understand your point. Qt uses more RAM than Gtk, therefore a Qt-based FF would be even heavier than the gtk-based one?
          Qt is indeed a bit heavyweight if all you need is a XUL backend. But on a Qt based desktop, most of Qt is already in shared memory, so a Qt based browser can improve memory usage and browser startup time.

          Comment


          • #15
            Originally posted by RealNC View Post
            I guess it's a chance for Firefox to pick up the ball that Google Chrome dropped. Chrome simply raised a giant middle finger to Linux users when they switched away from Gtk. They now use their own GUI toolkit (I forgot its name) that does not integrate AT ALL with Linux. It looks as alien as running a Windows application in Wine.
            Mind you, in Win8 Chrome almost self-hosts its own operating system inside Windows.
            http://www.theverge.com/2014/1/14/53...e-os-interface

            Comment


            • #16
              Originally posted by rohcQaH View Post
              To my knowledge, there have been at least two attempts to port FF to Qt, and both failed. Don't bet on any results this decade.
              They didn't fail, they just were never finished fully because Mozilla never cared to mainline the effort.

              Comment


              • #17
                What I like the most in KDE's patches from OpenSuse is that when I choose to open the downloaded file's location (from Firefox's download manager) Dolphin is opened with the downloaded file preselected. I hope this functionality will be kept if better integration with KDE and Firefox comes.

                Comment


                • #18
                  Originally posted by rob11311 View Post
                  A Qt based FF would be nice, I'm just not sure where/what is going to motivate the effort. On Desktop RAM has grown faster than FireFox memory consumption, just tried visiting same pages/tabs with Reqonq for a comparison and it did save 200MB overal, with more shared; but that's freshly started without all the Add Ons, syncing and vast bookmark collection that the frontline browser accumulates.
                  The problem really isn't initial memory, it's how fast does it leak due to Javascript? Further How long does it take to completely flip out and start slowing down even with plenty of memory left?

                  For Firefox the answer is ~ 1 Day, irregardless of the number of tabs

                  Comment


                  • #19
                    Originally posted by Luke_Wolf View Post
                    The problem really isn't initial memory, it's how fast does it leak due to Javascript? Further How long does it take to completely flip out and start slowing down even with plenty of memory left?

                    For Firefox the answer is ~ 1 Day, irregardless of the number of tabs
                    Not really. If you have leaky add-ons it's not Firefox's fault. I don't have such kind of memory leaks for a long time already.

                    Comment


                    • #20
                      Originally posted by shmerl View Post
                      Not really. If you have leaky add-ons it's not Firefox's fault. I don't have such kind of memory leaks for a long time already.
                      Believe me it's not addons, and it's a problem with all browsers as it's a javascript problem not a addon problem, and if you look around this forum you'll find that other people are having the same problem (The other day in the x32 thread Marc Driftmeyer's firefox session was at 6GB, I've consistently had it leak out to 4GB, Chromium it's harder to track the overall usage but 40MB processes regularly bloat out to 200MB or more just leaving the browser sitting there).

                      Chrome so far is the nicest because its process model means that although it grows, and eventually you will have to restart the main process due to leakage the javascript leaks are usually confined to the page they're on which means I can close the tab to end the process and stave off that part of the leak whereas with firefox you're running a single process which means you can't reclaim that leaked memory without completely closing and reopening the web browser which I end up having to do.

                      Comment

                      Working...
                      X