Re: The Future?

Miroslav Rajcic <support@xxxxxxxxxxxxxxx> · Sun, 10 Mar 2019 07:29:33 +0100



    I think the question is a valid one and there is a plenty of
      evidence of people moving to Qt due to some issues of GTK.
    Some notable examples:
    - VLC
(https://ubuntuforums.org/showthread.php?t=316155&s=54b259f2cb2d1a30ca8dc269d0561537)

    
    - Wireshark 
      (https://blog.wireshark.org/2013/10/switching-to-qt/)
    - Subsurface by Linus
      (https://liveblue.wordpress.com/2013/11/28/subsurface-switches-to-qt/)
    - LXDE desktop
(https://www.zdnet.com/article/lxde-waves-goodbye-to-gtk-in-merge-with-razor-qt/)
    - GCompris educational software
      (https://mail.kde.org/pipermail/kde-edu/2014-February/007950.html)
    All these people have valid complaints, so someone should think
      about it.
    Same as Paul, if I would start cross platform now (I started in
      2003), Qt would be a no-brainer choice.

    
    My personal issues with GTK in comparison to Qt:
    1. GTK is not so cross-platform anymore: on Windows and macOS,
      you are supposed to build your own library binaries (gvsbuild for
      Windows and jhbuild for macOS exist, but are not foolproof).
      "Golden age" in this regards was when Tor Lillqvist was still
      doing the Windows builds regularly on each GTK release. GTK was easy to be used on Windows at that time.

      
    2. QT has more complete stack, for example integrating
      audio/video playing module (Phonon). gstreamer as an alternative
      for such module in GTK suffers from "build your own binaries"
      (i.e. issue #1) and a more complex interface.

    
    3. for me, this one is huge: QT has much better rich text editor
      widget (QTextEdit), supporting tables, all types of bulleted lists
      etc.. GTK's default widget GtkTextView (nor GtkSourceView) is not
      nearly close to this (no tables, no bullets, no htmL export). For
      advanced editor you are supposed to embed WebKitGTK, but you must
      first suffer through issue #1 and use complex JScript solutions to
      implement your rich text editor features (formatting actions, text
      change notifications).
    4. API stability: jumps from GTK2 to GTK3 were painful, many APIs
      were changed, what it looks like from here, without the strong
      need, but just to make everything better organized or similar,
      without thinking of library users. I have an app that must support
      GTK2 (even using hildon interfaces on old platforms like Maemo)
      and GTK3 in the same code base, so it is now littered with many
      #ifdef layers
    5. Many other parts are unsolved or hard to implement in GTK
      (drag and drop integration using types other than the basic ones,
      for example)
    6. Useful features deprecated, an example is native print
      preview, that worked in 2.16 if i remember correctly and was
      broken forever in next releases (at that time I did not want to
      port preview  to a new mechanism, so i had to remove that feature
      in my program)
    IMO, it seems that GTK does not have a coherent strategy when it
      comes to toolkit features and a cross-platform usage (i.e.
      lowering the effort needed to develop for all major OSes).
      Nowadays it is mostly focused on adding shiny things as support
      for shaders, animated transitions, GL rendering.
    Hard-to-implement things like an advanced text editor do not seem
      to be an a table.
    This was meant as an constructive critics, it seems strange that
      this topic got just one answer so far.

    
    Regards,
      Miroslav

    
    On 9.3.2019. 17:43, Paul Davis wrote:

    
          On Sat, Mar 9, 2019 at 5:19
            AM J.Arun Mani via gtk-list <gtk-list@xxxxxxxxx>
            wrote:

          
            2. How does Gtk address the issue of its users moving to Qt?

          
            What evidence is there of this? Who
              are the "users" of GTK that you're referring to? Moving an
              existing GUI app between toolkits is typically almost
              equivalent to a complete rewrite, so applications (which
              are the real "users" of a toolkit) generally do not move.
              Developers may start new projects using Qt having
              previously used GTK, but who counts this? How would we
              judge if it is significant?

            
          3. What makes them move
            to Qt? Why can't Gtk have that respective feature?

          
            Qt has as many issues as GTK once
              you start using it for complex, deep applications.
              Different issues, to be sure, but no GUI toolkit gives you
              a free ride. 

            
            Qt is also developed using a
              different licensing/income generation model than GTK,
              which changes quite a lot. 
            

            Qt mostly has distinct advantages
              over GTK, and to be honest if I was starting
              cross-platform development now (22 years after I actually
              did), I'd probably pick Qt for all the obvious reasons.
              But it's fairly pointless to ask "how can GTK be more like
              Qt?" when there's more or less no chance or pathway for
              that to happen. As it is, I don't do mobile so GTK's
              issues there don't affect me. I also have 75k lines of
              code that would have to be almost completely rewritten to
              use Qt, with no noticeable benefit for our users and only
              marginal benefits for our developers.
            

            Speaking of "why can't?", why can't
              I write a C application using Qt  ? :))
            

      _______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list

    
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list