Announcement

Collapse
No announcement yet.

The GTK3 Port Of Firefox Is Making Progress, Firefox Can Run On Wayland

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

  • #31
    Ugh, the amount of Gtk+ hatred and misinformation going on here is utterly ridiculous, especially when it comes from people who have very obviously not programmed for it, and have not also programmed with Qt so they can make a proper comparison.

    1) Gtk+ doesn't "force" any GNOME anything, just like Qt doesn't force KDE. New features were added recently that GNOME makes use of, but the same features can also be used by other environments, such as tablets or Oculus Rift "desktops" or Ubuntu's Unity or whatever. But they are still and always optional. It also does't force Mutter or Clutter or Wayland in any way: these are all backends that are pluggable. Support for Mir, for example, was very easy to add. Heck, Gtk+ even has an HTML5 backend, letting you run any Gtk+ app in a browser (it has limited use cases, for sure, but still proved Gtk's flexibility). Of course, Qt can do all these things, too. So really one is not so much better than the other.

    2) The GNOME foundation manages a whole bunch of projects, and while a few work together, they are still separate projects. Gtk+ is used by GNOME but is not a slave to it. The team is very well aware of the very wide range of applications that rely on Gtk+, as well as a great many legacy apps, and planning for future apps written for emerging UIs.

    3) All APIs break upon major revisions, and Gtk+ and Qt are no exceptions. I've upgraded my Gtk+ apps a few times, and have found that the changes are usually quite small and make sense. Generally, Gtk+ adds features but doesn't remove them.

    If you hate GNOME Shell, that's a *totally* different issue, with its own justifications. But it really has nothing to do with Gtk+: you would hate Shell if it was Qt-based, and honestly it would look and behave pretty much the same, the user differences are quite minimal. What I think is going on is that people hate GNOME Shell and just want to punish all projects under the GNOME umbrella. That ain't right.

    Comment


    • #32
      @emblemparade:

      I agree in 100%.

      Comment


      • #33
        Originally posted by BSDude View Post
        It's long overdue to abandon GTK3 and move to Qt.
        Seconded

        Comment


        • #34
          Considering the amount of flaming that will probably go on in this thread, I'm curious as to what proportion of code actually uses GTK+.
          I was under the assumption that Mozilla made the UI's for their programs in XUL so that they would be cross platform.

          Comment


          • #35
            Originally posted by emblemparade View Post
            Ugh, the amount of Gtk+ hatred and misinformation going on here is utterly ridiculous, especially when it comes from people who have very obviously not programmed for it, and have not also programmed with Qt so they can make a proper comparison.

            1) Gtk+ doesn't "force" any GNOME anything, just like Qt doesn't force KDE. New features were added recently that GNOME makes use of, but the same features can also be used by other environments, such as tablets or Oculus Rift "desktops" or Ubuntu's Unity or whatever. But they are still and always optional. It also does't force Mutter or Clutter or Wayland in any way: these are all backends that are pluggable. Support for Mir, for example, was very easy to add. Heck, Gtk+ even has an HTML5 backend, letting you run any Gtk+ app in a browser (it has limited use cases, for sure, but still proved Gtk's flexibility). Of course, Qt can do all these things, too. So really one is not so much better than the other.

            2) The GNOME foundation manages a whole bunch of projects, and while a few work together, they are still separate projects. Gtk+ is used by GNOME but is not a slave to it. The team is very well aware of the very wide range of applications that rely on Gtk+, as well as a great many legacy apps, and planning for future apps written for emerging UIs.

            3) All APIs break upon major revisions, and Gtk+ and Qt are no exceptions. I've upgraded my Gtk+ apps a few times, and have found that the changes are usually quite small and make sense. Generally, Gtk+ adds features but doesn't remove them.

            If you hate GNOME Shell, that's a *totally* different issue, with its own justifications. But it really has nothing to do with Gtk+: you would hate Shell if it was Qt-based, and honestly it would look and behave pretty much the same, the user differences are quite minimal. What I think is going on is that people hate GNOME Shell and just want to punish all projects under the GNOME umbrella. That ain't right.
            You made these exact same false claims in the thread about audacious, then immediately ducked out of the thread when people corrected you. I, for one, responded in detail, which you completely ignored. I am not going to bother rewriting the same thing again if you couldn't be bothered to read it last time.

            Comment


            • #36
              Originally posted by ninez View Post
              This IS true, but a bit shortsided. GTK+, particularly with the 3.12 has a lot of improvements. it absolutely kills any other gtk+ release. Sure there has been breakage, but much of it needed to happen. And really, most people are frustrated over theming breakage or the perceived problem of CSD, more than anything else. in the CSD case, SSD sucks crap, imho ; ie: drawing the decoration separate from the rest of the app is whack. It doesn't look good, creates complexity, etc....
              The window manager and decorator should be responsible for drawing window decorations. The application should be free to request that decorations are not drawn and then it can go ahead and style its window however it wants. There should be a separation of duties the way I see it.

              However, I also see the window bar as being used for managing the window, and not being a place to cram all kinds of garbage shit from the app in there because somewhere along the line somebody got "inspired" and decided that menu bars and tool bars are "dated" concepts. So now we have 300px tall title bars with hidden menus and ugly icons. Big problem solved there.

              gtk/CSS theming is getting to a point where there will never be a need for gtk "engines". You can do it all in css, not need to maintain some chunk of code to draw buttons a certain way or whatever. On top of that, you can finally do some nice stuff in 3.12 - much nicer than previous gtk releases. [and it's not hard to hack together an "override" for adwaita to make it look how you want, without having to maintain a full gtk[2/3/metacity] theme and it will get even easier, when CSD is the norm.
              CSS is awful, idiotic, and slow as shit. There shouldn't be any web technologies in anything other than a browser and that's only because we have no choice in the browsers at this point. JS, CSS, HTML -- all that crap is absolutely awful means of programming anything. They are some of the worst software technologies in the world, completely made by the limitations of the browser. All those things do is drive developers to alcohol.

              Comment


              • #37
                Originally posted by emblemparade View Post
                Ugh, the amount of Gtk+ hatred and misinformation going on here is utterly ridiculous, especially when it comes from people who have very obviously not programmed for it, and have not also programmed with Qt so they can make a proper comparison.

                1) Gtk+ doesn't "force" any GNOME anything, just like Qt doesn't force KDE. New features were added recently that GNOME makes use of, but the same features can also be used by other environments, such as tablets or Oculus Rift "desktops" or Ubuntu's Unity or whatever. But they are still and always optional. It also does't force Mutter or Clutter or Wayland in any way: these are all backends that are pluggable. Support for Mir, for example, was very easy to add. Heck, Gtk+ even has an HTML5 backend, letting you run any Gtk+ app in a browser (it has limited use cases, for sure, but still proved Gtk's flexibility). Of course, Qt can do all these things, too. So really one is not so much better than the other.

                2) The GNOME foundation manages a whole bunch of projects, and while a few work together, they are still separate projects. Gtk+ is used by GNOME but is not a slave to it. The team is very well aware of the very wide range of applications that rely on Gtk+, as well as a great many legacy apps, and planning for future apps written for emerging UIs.

                3) All APIs break upon major revisions, and Gtk+ and Qt are no exceptions. I've upgraded my Gtk+ apps a few times, and have found that the changes are usually quite small and make sense. Generally, Gtk+ adds features but doesn't remove them.

                If you hate GNOME Shell, that's a *totally* different issue, with its own justifications. But it really has nothing to do with Gtk+: you would hate Shell if it was Qt-based, and honestly it would look and behave pretty much the same, the user differences are quite minimal. What I think is going on is that people hate GNOME Shell and just want to punish all projects under the GNOME umbrella. That ain't right.
                You made these exact same false claims in the thread about audacious, then immediately ducked out of the thread when people corrected you. I, for one, responded in detail here, which you completely ignored. I am not going to bother rewriting the same thing again if you couldn't be bothered to read it last time. If you actually care about having a discussion on the subject, you can respond to the people who addressed this post in the last thread.

                Comment


                • #38
                  Originally posted by shmerl View Post
                  How is Mozilla Shumway progressing? Flash won't work on Wayland, and in order to switch to GTK3, Shumway has to be a drop in replacement. I tried it a while ago, and it didn't work for video for example (which is probably 90%+ use cases for Flash these days).
                  Read the article - they've added the ability to have the main Firefox process run GTK3 while the plugins can still link to GTK2 in their own process.

                  That means Flash still won't work in wayland, but they can go ahead and port everything to GTK3 at least without breaking anything, and once there the Wayland port should be able to proceed easily enough.

                  It appears that the direct X11 calls are much fewer than i'd feared. Here's the link to the hack patch that got it running on wayland. Right now it's only commenting out a bunch of X calls and replacing them with nothing, and obviously needs a lot of work, but that doesn't seem like it will be too difficult to overcome once the GTK3 port is complete.

                  Comment


                  • #39
                    Originally posted by BSDude View Post
                    It's long overdue to abandon GTK3 and move to Qt.
                    +1

                    The arrogance of the GTK developers, who can not even be bothered to implement support for other fileselection dialogs, makes every day an application switches to Qt a good day.

                    We are at a point where application developers are implementing support for different file dialogs, even though this clearly is the job of the toolkit. Qt apps integrate pretty well in GTK based desktops but the other way round it's a nightmare. The arrogance of the GTK developers harms the user experience of all users of Qt-based desktops! The sooner GTK dies the better, the Open Source community has no need for these kind of developers, who play their little power games on the back of the users.

                    Shame on you GTK devs.

                    Comment


                    • #40
                      Originally posted by smitty3268 View Post
                      Read the article - they've added the ability to have the main Firefox process run GTK3 while the plugins can still link to GTK2 in their own process.

                      That means Flash still won't work in wayland, but they can go ahead and port everything to GTK3 at least without breaking anything, and once there the Wayland port should be able to proceed easily enough.

                      It appears that the direct X11 calls are much fewer than i'd feared. Here's the link to the hack patch that got it running on wayland. Right now it's only commenting out a bunch of X calls and replacing them with nothing, and obviously needs a lot of work, but that doesn't seem like it will be too difficult to overcome once the GTK3 port is complete.
                      I don't think any NPAPI plugin like flash will ever work in Wayland unless they can nest them inside the browser window as separate XWayland processes (probably using a subcompositor). That seems like a hard task to me.

                      Comment


                      • #41
                        What kind of design is this?

                        So you have a library with two users, one that needs UI elements and one that does not. In fact the second one needs a different UI library, causing the second use case to crash.

                        So the obvious choice is to add a new library that can be used to mask out the UI elements that the first and the second user needs, so that you can switch between those two at runtime. Wow, that is software design as it should be. Both process depend on a new library now and the second that used to load a lot of crap it did not ever need is still loading that.

                        The reason? "libxul was to intricate". So we add a new layer (a thin one, of course, has anybody ever added a thick one?), because the existing code is so interwoven that the developers do not dare to move one piece of functionality from one library into another. Great... so the code is bad, let's make it worth by adding more cruft that we actually know is unnecessary. That way we can get a new feature a bit faster, yeah!

                        That is exactly what I want in my browser. No wonder chrome is eating firefoxes lunch.

                        Comment


                        • #42
                          Originally posted by Temar View Post
                          +1

                          The arrogance of the GTK developers, who can not even be bothered to implement support for other fileselection dialogs, makes every day an application switches to Qt a good day.

                          We are at a point where application developers are implementing support for different file dialogs, even though this clearly is the job of the toolkit. Qt apps integrate pretty well in GTK based desktops but the other way round it's a nightmare. The arrogance of the GTK developers harms the user experience of all users of Qt-based desktops! The sooner GTK dies the better, the Open Source community has no need for these kind of developers, who play their little power games on the back of the users.

                          Shame on you GTK devs.
                          Have they turned down a patch to pop up the Qt file selector?

                          Comment


                          • #43
                            Originally posted by Temar View Post
                            +1

                            The arrogance of the GTK developers, who can not even be bothered to implement support for other fileselection dialogs, makes every day an application switches to Qt a good day.

                            We are at a point where application developers are implementing support for different file dialogs, even though this clearly is the job of the toolkit. Qt apps integrate pretty well in GTK based desktops but the other way round it's a nightmare. The arrogance of the GTK developers harms the user experience of all users of Qt-based desktops! The sooner GTK dies the better, the Open Source community has no need for these kind of developers, who play their little power games on the back of the users.

                            Shame on you GTK devs.
                            Oh, come on, calm down.

                            There are not that many gtk devs: They need to concentrate on their priorities. There is no use calling any of them names, just because their priorities are different from yours: That will only discouraging people from working on the library.

                            Check the statistics yourself: 90% of the commits in the last 30 days where done by 5 people (check ohloh). Those 5 people do a really heroic job at improving GTK, so please be more respectful.

                            Comment


                            • #44
                              I wish they'd use Qt. Then Firefox would finally honour mouse wheel scroll rate settings specified in KDE, instead of using the broken GTK+ black magic that requires messing with the bowels of about:config to work around.

                              Comment


                              • #45
                                Originally posted by shmerl View Post
                                How is Mozilla Shumway progressing? Flash won't work on Wayland, and in order to switch to GTK3, Shumway has to be a drop in replacement. I tried it a while ago, and it didn't work for video for example (which is probably 90%+ use cases for Flash these days).
                                Or you know they could finally stop holding up the web and support PPAPI

                                Comment

                                Working...
                                X