1. 10
  1.  

  2. 7

    one huge pro for gtk (that i guess doesn’t feature here because it’s for c++ libraries specifically) is that it’s based on C rather than C++. which makes other language bindings a lot more feasible..

    1. 3

      The biggest problem with GTK to me is that it is very large and you have to ship 20+ megabytes of dlls for even a basic C++ “Hello World” application.

      05/27/2018  11:13 PM           135,553 libatk-1.0-0.dll
      01/15/2017  06:37 AM            74,400 libbz2-1.dll
      05/02/2018  01:46 PM         1,019,236 libcairo-2.dll
      05/02/2018  01:46 PM            37,749 libcairo-gobject-2.dll
      05/21/2018  01:06 AM         1,672,299 libepoxy-0.dll
      11/20/2017  02:00 AM           219,464 libexpat-1.dll
      07/21/2016  12:42 AM            34,176 libffi-6.dll
      03/11/2018  09:55 PM           289,868 libfontconfig-1.dll
      05/02/2018  10:27 PM           687,323 libfreetype-6.dll
      06/19/2018  09:40 PM           141,883 libfribidi-0.dll
      04/25/2018  01:32 AM            83,088 libgcc_s_seh-1.dll
      04/25/2018  07:00 AM         1,231,469 libgdk-3-0.dll
      04/09/2018  12:22 AM           172,637 libgdk_pixbuf-2.0-0.dll
      05/27/2018  11:44 PM         1,447,420 libgio-2.0-0.dll
      05/27/2018  11:44 PM         1,143,569 libglib-2.0-0.dll
      05/27/2018  11:44 PM            26,808 libgmodule-2.0-0.dll
      05/27/2018  11:44 PM           313,088 libgobject-2.0-0.dll
      03/11/2018  10:12 PM           235,198 libgraphite2.dll
      04/25/2018  07:00 AM         6,745,942 libgtk-3-0.dll
      06/14/2018  12:52 AM           711,178 libharfbuzz-0.dll
      05/31/2018  05:34 AM         1,055,010 libiconv-2.dll
      06/04/2018  12:30 AM           132,146 libintl-8.dll
      04/08/2018  10:08 PM           260,088 libpango-1.0-0.dll
      04/08/2018  10:08 PM            71,411 libpangocairo-1.0-0.dll
      04/08/2018  10:08 PM            95,066 libpangoft2-1.0-0.dll
      04/08/2018  10:08 PM           102,449 libpangowin32-1.0-0.dll
      03/21/2018  02:30 AM           286,369 libpcre-1.dll
      09/06/2016  04:07 AM           682,872 libpixman-1-0.dll
      10/02/2017  04:32 AM           231,566 libpng16-16.dll
      04/25/2018  01:32 AM         1,435,729 libstdc++-6.dll
      05/18/2018  04:48 AM            57,317 libwinpthread-1.dll
      01/16/2017  11:09 PM            93,830 zlib1.dll
                32 File(s)     20,926,201 bytes
      

      WxWidgets and Qt are similarly large.

      My preference is smaller and lighter toolkits that have a minimal set of dependencies or can be statically linked into a small (less than 2 megabyte) executable. On Windows my preference then is usually FLTK, FOX Toolkit, IUP (it’s basically like WxWidgets but somehow way smaller), or just using Win32 directly. Since the vast majority of Linux/Unix users probably have GTK installed I have no problems linking to gtk there but it certainly feels messy on Windows.

    2. 4

      If making a huge list including even fringe/niche stuff, probably the Enlightenment libraries should be added too? Then there’s Arcan. Also, I think the Allegro library had some windowy stuff in the ’90s, but I may well misremember.

      1. 3

        (Seriously asking - I’m a C++ newbie.)

        What’s not to like about Qt?

        1. 5

          I think the fact it is popular works against it slightly, as it’s old enough and established enough not to have a cool factor.

          It’s built in C++, which as another pointed out makes it trickier to write language bindings. They do exist, however - the Python bindings being decent, I hear.

          I think it’s hard to find reasons not to use it. It has been used for PDA (remember those?), phone and car dashboard applications - and an entire desktop environment with all its applications, so it scales up and down a long way.

          I see there is a complaint appearing that it makes a large binary. That’s pretty much a C++ issue - and has effects which don’t affect most applications - runtime linking speed, size on disk. When you’re at KDE scale, those issues become important, but for most use cases, these are less than a non-issue.

          1. 4

            Qt is not a lightweight dependency. It is massive.

            It’s a huge amount of code, and in some contexts, like compiling to WebAssembly or AppImage, it will result in a huge executable, which might cause problems, like long download times in a web application.

            There is a high learning curve due to the size and complexity of Qt. Qt has reinvented all of the wheels. Like, it replaces the C++ standard library with idiosyncratic Qt replacements that you need to learn. Eg, std::string is replaced by QString. See also, code bloat.

            Many C++ developers prefer to use a collection of small libraries with minimal dependencies. Each library solves one problem, and for each library, you get to pick the best of breed, the best tool for your job. Qt seemingly attempts to replace the entire C++ library ecosystem.

            1. 2

              Qt begun development (1991, according to wikipedia) when STL was not yet available (1994, according to wikipedia). That may answer the question why is it so huge and bloated. I guess today when we have c++11/14/17 it would look so different.

              1. 2

                There is a high learning curve due to the size and complexity of Qt. Qt has reinvented all of the wheels. Like, it replaces the C++ standard library with idiosyncratic Qt replacements that you need to learn. Eg, std::string is replaced by QString. See also, code bloat.

                Again please forgive my newbie question - doesn’t everything do this? When I worked with MFC in the 90s it did, and I know BOOST does, and as you say so does Qt…

                1. 2

                  No, not all C++ libraries are as huge and multi-faceted as Qt, Boost and MFC. The vast majority of the C++ libraries that you will find on github are in fact much smaller, much simpler, and much more specialized. This is natural, because most C++ libraries are created and maintained by a single author to solve a specific problem.

                  In a previous response, @drs said: “My preference is smaller and lighter toolkits that have a minimal set of dependencies or can be statically linked into a small (less than 2 megabyte) executable”. I have the same preference. Static linking and executable size become important considerations if you need to ship your application in a self-contained format that contains all of your dependencies. It’s particularly important if you are compiling your code into WebAssembly.

                  Since I’m writing a GPU-centric application, I chose GLFW to create windows and manage keyboard/mouse input, OpenGL for rendering 2D and 3D graphics, and ImGui to create GUI widgets. Note that these are three separate libraries, which are developed independently of each other. GLFW and ImGui allow you to replace OpenGL with other graphics APIs, and ImGui allows you to replace GLFW with other window/io APIs. This is quite different from how giant monolithic GUI libraries work.

                  1. 1

                    Thanks very much for explaining your choices and preferences, super useful background! I hadn’t heard of GLFW. Interesting that it’s a part of the OpenGL family.

            2. 2

              I hadn’t previously heard of NanoGUI but the code examples look clean and readable and the dependencies look minimal. Curious if anyone here has experience using it, and if so what feedback you have on the pros and cons.

              1. 1

                Great list w/ great comments, thank you for sharing.