Announcement

Collapse
No announcement yet.

The Biggest Problem With GTK & What Qt Does Good

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

  • #31
    Originally posted by Nth_man View Post
    New small and touch-screens require new developments, and an new approach. QML and Javascript allow descriptive and dynamic ("interpreted") management of interfaces, and so they ended up existing.
    Webos tried html5/js applications, as did ios, firefoxos is again playing with this. They don't keep them for long. Perhaps my analysis may not exactly apply but it seems qt5 just jumped on this bandwagon which hasn't been panning out.

    Qt is probably currently the most reasonable choice for a traditional cross platform desktop application library. But I do question people claiming that it's a great tookit.

    Comment


    • #32
      @bnolsen, for me whole QML concept seems like idea from Nokia (which used to own Qt at that time), mostly for use with their platforms (which they abandoned, after switching to Windows Phone).
      QML is currently only useful for small applications, only since introduction of... (almost) real widgets. :-D
      Hopefully nobody will ever force me to use it instead of QtWidgets.

      JavaScript was available for much longer as scripting language, very useful thing (and integrates well with C++, even including exposing C++ objects to QtWebKit), if not abused.

      And one of these additions in QtWidgets in 5.2 was QKeySequenceEdit.
      I'm not sure if maintenance only is really true after departure of Nokia. Also there are widgets modules for QtMultimedia and QtWebkit (and there will be for QtWebEngine too).

      Comment


      • #33
        if qtcreator is so cool how can i open automake project eazily or import anything ??

        I can't , right? So pls dont say its awesome IDE ...

        Comment


        • #34
          Originally posted by mir3x View Post
          if qtcreator is so cool how can i open automake project eazily or import anything ??
          Setting Up an Autotools Project | QtCreator

          Comment


          • #35
            Originally posted by mir3x View Post
            if qtcreator is so cool how can i open automake project eazily or import anything ??

            I can't , right? So pls dont say its awesome IDE ...
            File -> New -> Import Project -> Import Existing Project. Then you type the path and select the files you want included and it's done. It should run "make" when you build the project.

            If there is any other way to setup a Makefile-based build (automake, cmake, etc.), I don't use it.

            Comment


            • #36
              I prefer Kdevelop than QtCreator, I feel the parser more complete and it has great integration with cmake

              Comment


              • #37
                I have literally created an account to say QtCreator is something. The not intrusive CMake importer (more like plugin) got me. It feels modern and way more responsive than Eclipse (I have always thought Eclipse was a disaster anyway, so many bugs that can be encountered regular basic tasks). However the UI is somewhat complicated, different maybe, so I feel like I need to get used to it.

                I can't say anything on GTK vs. Qt though since I never developed UI apps. But the fact that QtCreator is written in Qt it shows that Qt is far from being a slow unresponsive framework. But having QtCreator on Qt's side seems like a big bonus for Qt. However total binary size that I need to distribute will be a deal breaker if I ever need to choose GUI lib. GNOME 3's looks vs KDE makes me lean towards GTK. On the other hand QtCreator also shows what is possible with Qt and the (possibly) well integrated helpers into QtCreator for Qt makes me lean towards Qt.

                I was also a Geany user but will definitely give QtCreator a try in the future.

                Comment


                • #38
                  Originally posted by JS987 View Post
                  You can't use hardware accelerated QML widgets in C++ application without using QML language and Javascript.
                  QML obviously implies the existence of a JavaScript interpreter, though it might not be used if all bindings are trivial enough.
                  But also obvious, using QML is not the prerequiste for using hardware accelerated UI.

                  Hardware accelerated drawing is a property of the used component technology, not a property of the technology used to create the scene's objects.
                  For example:
                  if you use QML with QtWidgets, then the drawing will most likely not be hardware accelerated (depends on the QPA plugin). On the other hand, if you use QML with QtQuick2 or BB10 Cascades, then it will be.

                  Same for C++: If you use C++ with QtWidgets then the drawing won't be hardware accelerated, on the other hand if you use C++ with a hardware accelerated component set such as BB10 Cascades, it will be.

                  QML is just another way to create an object tree. A UI component set can be hardware accelerated and be used through C++ and QML.

                  Originally posted by JS987 View Post
                  New QWidget class couldn't be added because you can't have two QWidget classes in same namespace. Extending one class isn't big change as Widgets consist of many classes.
                  Obviously it meant that a new widget, i.e. a direct or indirect subclass of QWidget, was added to the QtWidget module.

                  Cheers,
                  _

                  Comment


                  • #39
                    Originally posted by Emdek View Post
                    QML is currently only useful for small applications, only since introduction of... (almost) real widgets. :-D
                    You probably meant to write QtQuick, i.e. refer to the UI component set.

                    Originally posted by Emdek View Post
                    Hopefully nobody will ever force me to use it instead of QtWidgets.
                    Just to be sure there is no misunderstanding (like the possible QML <-> QtQuick mixup in the previous sentence), QML can obviously also be used for development of QtWidget UIs.

                    Cheers,
                    _

                    Comment


                    • #40
                      @anda_skoa, yeah, QtQuick and stuff, for me they mean almost one and the same thing (since they are closely related), but yeah, they are not exactly the same thing. ;-)
                      And yes, I'm aware that it is possible to combine them, just it is not as easy as it used to be with QGraphicsView.

                      Comment


                      • #41
                        Originally posted by Emdek View Post
                        @anda_skoa, yeah, QtQuick and stuff, for me they mean almost one and the same thing (since they are closely related), but yeah, they are not exactly the same thing. ;-)
                        The two technology names are often used synonymous but they are not. One is basically the enabled of the other. A bit like C++ and Qt not being the same thing. Qt implies C++, C++ does not imply Qt.

                        QML is, for example, also being used on BlackBerry's BB10 platform, which does not use QtQuick.
                        QML can also be used for QtWidget programming. E.g. see https://conf.kde.org/en/Akademy2013/public/events/20

                        Cheers,
                        _

                        Comment


                        • #42
                          Originally posted by JS987 View Post
                          You can't use hardware accelerated QML widgets in C++ application without using QML language and Javascript. Using QML and Javascript during runtime isn't necessary.
                          First sentence wrong, second one is right

                          New QWidget class couldn't be added because you can't have two QWidget classes in same namespace. Extending one class isn't big change as Widgets consist of many classes.
                          I think he meant a new widget, it means the development of the widgets module is not dead.

                          Non-trival QML application is written in 3 languages: QML, Javascript, C++. C++ and Javascript are incompatible with each other. You can't e.g. use regular C++ classes in Javascript code.
                          Javascript is very defective language compared to C++ because it is dynamically typed, prototype based, JIT compiled, garbage collected.
                          QML has syntax that is similar to JavaScript, but it is just QML, but there is no actual JavaScript in there. Also you can use Qt classes from QML. You can even access Qt in the two JavaScript engines Qt has (QtScript and QtWebKit).
                          Last edited by carewolf; 01-12-2014, 03:43 PM.

                          Comment


                          • #43
                            Initially I was skeptical about the whole Qml/Javascript stuff, but having used it for while I think it's totally the future. For those people saying that you can't write large/complex programs using Qml then take a look at Pixeluvo - it's a cross platform image editor with the interface done entirely with Qt/Qml. It's definitely not a trivial interface either, doing something like that using Gtk, or even tradition QWidgets would be virtually impossible.
                            Oh, and QtCreator is awesome. Only thing that comes close is VS + Visual Assist.

                            Comment


                            • #44
                              Originally posted by Ancurio View Post
                              On topic: what I was actually waiting for him to criticize was how GNOME folks tend to integrate things in GTK that are relevant to GNOME, but completely useless anywhere else (eg. the slider switch).
                              Actually, at the very end of the talk, he says in his view it seems like most of the GTK devs seem to see themselves as GNOME developers, and everything they do is for GNOME, and any 3rd party apps are viewed as on their own. While Qt seems much more focused on the 3rd party apps due to it's history at Trolltech and the fact that KDE is built off of Qt is the side project, while those 3rd party apps are what they really focus on.

                              The other thing i noticed he seemed to emphasize a lot was the mac/windows support. That seemed like it was one of the primary reasons for the switch. Only 15% of their users are on linux, so giving a 1st class impression on other platforms was important for his project, and while he got the GTK version working elsewhere, he was constantly running into weird bugs. While Qt views those other platforms as 1st class citizens and he's had better luck there.


                              Also, for people complaining about javascript - his project does not use QML. Though he stuck it in as something he wanted to look into for the future, to get it running on tablets and phones, but that there was a lot of work to do before that could happen.
                              Last edited by smitty3268; 01-12-2014, 06:58 PM.

                              Comment


                              • #45
                                Too bad that Gtk/Gnome devs are such morons, as GTK apps look now much prettier than Qt or KDE apps in my humble opinion.

                                Comment

                                Working...
                                X