Announcement

Collapse
No announcement yet.

OpenShot Switches From GTK+ To Qt

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

  • #16
    huh

    I don't get how some of you feel OpenShot is "Stable" when the number one complaint is it's lack of Stability. Generally you can't edit more than a few minutes of Video without a complete crash. Anyway, I only do some basic cutting and encoding and have found that Avidemux suits my needs for reliability since VirtualDub isn't available on Linux.

    Exactly Pallidus, why Mac and Win need another Editor out of the hundreds already available is beyond me. What he should of done was just ask the Linux community to donate, I'm sure we would've been happy to do so. Now there is a huge burden on him to support three platforms, and I'm sure Linux will not be his top priority anymore.
    Last edited by Mike Frett; 04-26-2013, 04:28 AM.

    Comment


    • #17
      Originally posted by garegin View Post
      i'm not a developer, but as far as I understand gtk+ is technologically inferior to Qt. Other than ideological reasons, does gtk have any technical benefits over Qt?
      Well, apparently it is simpler to write GTK bindings for other languages, which is why you'll find dozens of them (Ruby, Lua, Python, Perl, PHP, JS ...),
      whereas the only supported binding for Qt is PyQt AFAIK.
      Also, once you write the necessary GObject binding, a large range of libraries are at your disposal without any further glue code needed.

      Comment


      • #18
        Originally posted by Ericg View Post
        OpenShot does NOT use MLT (See the blog post linked in the article, the developer addresses it).
        Learn grammar, please. OpenShot uses MLT (present tense). OpenShot 2.0 will not use MLT (future). OpenShot 2.0 currently does not exist.

        Comment


        • #19
          Originally posted by Ancurio View Post
          Well, apparently it is simpler to write GTK bindings for other languages, which is why you'll find dozens of them (Ruby, Lua, Python, Perl, PHP, JS ...),
          https://en.wikipedia.org/wiki/Qt_%28...rk%29#Bindings


          Originally posted by Ancurio View Post
          whereas the only supported binding for Qt is PyQt AFAIK.
          Depends on your definition of “supported”. If by that you mean you can go to a company and hire it to offer support, then yes, the choices are limited because most bindings are community-developed.
          Qt 5 is also still young. Many bindings are still not ported to Qt 5. Qt 5 comes with JavaScript bindings out of the box, obviously.

          Comment


          • #20
            Originally posted by Awesomeness View Post
            https://en.wikipedia.org/wiki/Qt_%28...rk%29#Bindings



            Depends on your definition of “supported”. If by that you mean you can go to a company and hire it to offer support, then yes, the choices are limited because most bindings are community-developed.
            Qt 5 is also still young. Many bindings are still not ported to Qt 5. Qt 5 comes with JavaScript bindings out of the box, obviously.
            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.

            Comment


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