Announcement

Collapse
No announcement yet.

OpenShot Switches From GTK+ To Qt

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

  • #21
    Originally posted by kigurai View Post
    The difference is that using GObject Introspection the language bindings come more or less for free. No one has to actively develop specific library bindings. The language you use just need an implementation of GI.
    Qt has a meta-object system that also allows introspection. However, Qt has things like signals/slots and QML that generally do not have direct correlates in other languages, so support for these sorts of things in a manner that works well with the idioms of the language in question generally need to be programmed.

    So although basic access to Qt class signatures and methods is not difficult, being able to provide access to all the capabilities Qt provides in a manner that is well-suited to the language requires more than that.

    This is no different with GTK. Getting good idiomatic bindings requires more than just using the introspection, you need language-specific code that maps toolkit-specific concepts to the language in question. Try comparing pygtk's original gobject property handling, which involved parsing a dictionary with strings, to their modern method and decorator-based approach. That didn't happen automatically, it had to be specifically programmed (as PyQt4's property system did, although it doesn't look like they ever used the ugly dictionary method).
    Last edited by TheBlackCat; 04-26-2013, 07:40 AM.

    Comment


    • #22
      Originally posted by TheBlackCat View Post
      This is no different with GTK. Getting good idiomatic bindings requires more than just using the introspection, you need language-specific code that maps toolkit-specific concepts to the language in question. Try comparing pygtk's original gobject property handling, which involved parsing a dictionary with strings, to their modern method and decorator-based approach. That didn't happen automatically, it had to be specifically programmed (as PyQt4's property system did, although it doesn't look like they ever used the ugly dictionary method).
      Not sure I am following you here. Are we talking about the same thing?

      Using GTK from Python (to take an example) is now done via

      from gi-repository import Gtk

      which finds the Gtk3 .typelib file. There are no specific "GTK Python bindings", as this is handled by the introspection system.

      Comment


      • #23
        Too bad they GTK+ does not provide for being able to use a random rendering and javascript engine.
        Then they could have used Gecko and other things instead.

        Comment


        • #24
          As a user I prefer Gtk2 applications. As a programmer I donít like Qt.

          Comment


          • #25
            Originally posted by stqn View Post
            As a user I prefer Gtk2 applications. As a programmer I donít like Qt.
            What dont you like about gtk2 as a user? Personally as a user I much prefer Qt programs because I know using them cross-platform is less of an issue, and using them under different environments isnt going to butcher the looks of the program. (Gtk looks like crap under KDE because GTK refused to merge patches from the Qt/KDE guys that made sure it used the desktop's style. KDE merged GTK's patches however to make sure that KDE/Qt programs under GTK rendered correctly.)

            Comment


            • #26
              Originally posted by jumico View Post
              I think everyone realizes that gtk+ is not as suitable for cross platform apps.
              Yeah, GTK isn't necessarily "bad", but really the only thing its suited for is creating GNOME apps. for cross platform (and even cross-DE) its garbage compared to QT.
              Last edited by bwat47; 04-26-2013, 01:04 PM.

              Comment


              • #27
                Well, both have their uses. For me it comes down to bindings and use case. Since I like coding in D, and Qt support on D is not very good (the QtD project is mostly unmaintained and there is little hope for Qt 5 support), I'd rather use GTK. If coding in pure C, then GTK again has an edge, as Qt is not compatible with C. But if coding in C++, then of course Qt is the way to go. And if the program has to be cross-compatible, then Qt has an edge, if not, then GTK is just fine.

                Comment


                • #28
                  Originally posted by GreatEmerald View Post
                  Well, both have their uses. For me it comes down to bindings and use case. Since I like coding in D, and Qt support on D is not very good (the QtD project is mostly unmaintained and there is little hope for Qt 5 support), I'd rather use GTK. If coding in pure C, then GTK again has an edge, as Qt is not compatible with C. But if coding in C++, then of course Qt is the way to go. And if the program has to be cross-compatible, then Qt has an edge, if not, then GTK is just fine.
                  What, if you are coding in C and the program has to be cross-platform?

                  Comment


                  • #29
                    Originally posted by stqn View Post
                    As a user I prefer Gtk2 applications. As a programmer I donít like Qt.
                    Well, GTK2 is dead and OpenShot is not the only application that switched to Qt. VLCís switch was quite some time ago and more recently even LXDEís PCManFM switched to Qt: http://blog.lxde.org/?p=990

                    Comment


                    • #30
                      Originally posted by LightBit View Post
                      What, if you are coding in C and the program has to be cross-platform?
                      Then either compile the C code with a C++ compiler (and try ignoring all the warnings it spits out about "obsolete features"), and use Qt for the rest, or just use GTK. It's still cross-platform, just not as much as Qt.

                      Comment

                      Working...
                      X