4 ms·

I wonder what's the point of people touting about reusable code is when as soon as a set of 71 distinct libraries, most of them optional, (disclaimer: ls /usr/

I wonder what's the point of people touting about reusable code is when as soon as a set of 71 distinct libraries, most of them optional, (disclaimer: ls /usr/lib/libQt5*.so | wc -l) full of reusable code with a common API and coding conventions is not considered since it's apparently "too much". Do you really prefer to learn a different API and library for every different part of your app ?

deleted 9y ago
[deleted]
jstimpfle 9y ago
You should look into the sibling comments (nuklear, DearImgui, Casey Muratori), and try doing a simple toolkit for your own use. Then you will understand the difference. Qt is huge, and opinionated, and very difficult to control. Qt is not focused on being a useful tool that you simply put next to your other modules, and plays nice when it's called. Qt wants to be a framework that drives your application. Qt expects you to speak in its own datatypes, not type-agnostic flat memory. I mean, I've only used Qt very briefly, but how would I, for example, use Qt widget functionality to add a nice menu to my existing 3d game? It's uncommon enough that I can't easily find how to do it, and I wouldn't be surprised if it's next to impossible.
- billsix 9y ago
  Fully agreed. With Qt, Qt itself is the app, your code is just a plug-in. :-)
- jcelerier 9y ago
  > I mean, I've only used Qt very briefly, but how would I, for example, use Qt widget functionality to add a nice menu to my existing 3d game? I don't think that would be very desirable: Qt widgets are made to mimick the desktop OS themes... I doubt you want these in games. However, you could use QtQuick, here is for instance an example of integration with a 3d game engine: https://github.com/MaxSavenkov/nya_qt https://github.com/MaxSavenkov/nya_qt And another which integrates with the creative coding framework openFrameworks: https://github.com/aklevy/ofUnderQml https://github.com/aklevy/ofUnderQml ; doing for instance a HUD à la Scaleform with these is fairly realistic given the nice scene graph of QtQuick
  - jstimpfle 9y ago
    Both seem to integrate an existing thing into the QML runtime by using Qt-defined hooks and subclassing Qt-defined classes. I can't really understand it or map out the control flow. There's lots of magic involved. I don't think Qt, or QML for that matter, is flexible enough to fit into an existing, complex architecture with its own concepts and data structures. What I need is something that I can feed my own inputs through a simple plain data API, and get back plain data results that I can further process, preferably without any other side effects. I don't want to structure my code heavily towards a framework. I don't think that is flexible or maintainable. I don't want to use a framework that takes over the process and the processes' I/O and the main loop, and that I can't extend without plugging hard to maintain code into lots of magical sockets. Which also only gets you so far; you'll never be able to bend the framework to do quite what you need; and you'll waste hours and hours reading documentation and browsing obscure github projects to find clues how to bend it a little more. And of course, these clues will be invalid in the next version. This is my experience with Qt at least (as well as with CMake, for example).
    - jcelerier 9y ago
      > I don't think Qt, or QML for that matter, is flexible enough to fit into an existing, complex architecture with its own concepts and data structures. What I need is something that I can feed my own inputs through a simple plain data API, and get back plain data results that I can further process, preferably without any other side effects. What makes you think you can't ? Pass input events to the relevant Qt objects once per frame, tell it to render to an FBO and do whatever you want with the result. > through a simple plain data API, I'm working on large app made in Qt and the number of times where I call Qt functions taking Qt containers as arguments, eg QList or QVectors can be counted on the fingers of one hand. What do you have in mind for instance ? > I don't think that is flexible or maintainable. The number of reliable large applications based on frameworks certainly shows otherwise. Even in video games, could you cite more than five big AAA game in the last decade that were not based on UDK, CryEngine and its variants, or Unity3D ? > I don't want to use a framework that takes over the process and the processes' I/O and the main loop, That's what I was referring to when I mentioned code reusability. Event loops & IO have been abstracted away for a long time, yet people refuse to use these abstractions for reasons unknown to me and keep reinventing game loops in every game, instead of just referring to some lifecycle schema like Unity3D's (https://docs.unity3d.com/Manual/ExecutionOrder.html https://docs.unity3d.com/Manual/ExecutionOrder.html) or Qt's (http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html). These schemas did not come out of thin air, but of years of experimenting on different categories of apps and seeing what works and what does not ; 99% of the time you don't need to deviate from them, especially if you're not making an AAA. > This is my experience with Qt at least (as well as with CMake, for example). I feel like we're living in a parallel world. Qt maintains API and ABI compatibility for major versions, the last breakage was in Qt 4 -> 5 transition 6 years ago. And a large part of the apps I use still have CMake 2.6 - 2.8 level buildscripts while we're at 3.10, and they still work as-is.
billsix 9y ago
Modularity. In a project of mine, https://github.com/billsix/hurtbox https://github.com/billsix/hurtbox, I switched from "dear imgui" to "nuklear" trivially. I imagine that switching a project from qt to gtk or wxwidgets would be a massive rewrite.
- jamesaustin 9y ago
  Curious to know why you switched?

deleted 9y ago

[deleted]

jstimpfle 9y ago

You should look into the sibling comments (nuklear, DearImgui, Casey Muratori), and try doing a simple toolkit for your own use. Then you will understand the difference. Qt is huge, and opinionated, and very difficult to control. Qt is not focused on being a useful tool that you simply put next to your other modules, and plays nice when it's called. Qt wants to be a framework that drives your application. Qt expects you to speak in its own datatypes, not type-agnostic flat memory. I mean, I've only used Qt very briefly, but how would I, for example, use Qt widget functionality to add a nice menu to my existing 3d game? It's uncommon enough that I can't easily find how to do it, and I wouldn't be surprised if it's next to impossible.

billsix 9y ago
Fully agreed. With Qt, Qt itself is the app, your code is just a plug-in. :-)
jcelerier 9y ago
> I mean, I've only used Qt very briefly, but how would I, for example, use Qt widget functionality to add a nice menu to my existing 3d game? I don't think that would be very desirable: Qt widgets are made to mimick the desktop OS themes... I doubt you want these in games. However, you could use QtQuick, here is for instance an example of integration with a 3d game engine: https://github.com/MaxSavenkov/nya_qt https://github.com/MaxSavenkov/nya_qt And another which integrates with the creative coding framework openFrameworks: https://github.com/aklevy/ofUnderQml https://github.com/aklevy/ofUnderQml ; doing for instance a HUD à la Scaleform with these is fairly realistic given the nice scene graph of QtQuick
- jstimpfle 9y ago
  Both seem to integrate an existing thing into the QML runtime by using Qt-defined hooks and subclassing Qt-defined classes. I can't really understand it or map out the control flow. There's lots of magic involved. I don't think Qt, or QML for that matter, is flexible enough to fit into an existing, complex architecture with its own concepts and data structures. What I need is something that I can feed my own inputs through a simple plain data API, and get back plain data results that I can further process, preferably without any other side effects. I don't want to structure my code heavily towards a framework. I don't think that is flexible or maintainable. I don't want to use a framework that takes over the process and the processes' I/O and the main loop, and that I can't extend without plugging hard to maintain code into lots of magical sockets. Which also only gets you so far; you'll never be able to bend the framework to do quite what you need; and you'll waste hours and hours reading documentation and browsing obscure github projects to find clues how to bend it a little more. And of course, these clues will be invalid in the next version. This is my experience with Qt at least (as well as with CMake, for example).
  - jcelerier 9y ago
    > I don't think Qt, or QML for that matter, is flexible enough to fit into an existing, complex architecture with its own concepts and data structures. What I need is something that I can feed my own inputs through a simple plain data API, and get back plain data results that I can further process, preferably without any other side effects. What makes you think you can't ? Pass input events to the relevant Qt objects once per frame, tell it to render to an FBO and do whatever you want with the result. > through a simple plain data API, I'm working on large app made in Qt and the number of times where I call Qt functions taking Qt containers as arguments, eg QList or QVectors can be counted on the fingers of one hand. What do you have in mind for instance ? > I don't think that is flexible or maintainable. The number of reliable large applications based on frameworks certainly shows otherwise. Even in video games, could you cite more than five big AAA game in the last decade that were not based on UDK, CryEngine and its variants, or Unity3D ? > I don't want to use a framework that takes over the process and the processes' I/O and the main loop, That's what I was referring to when I mentioned code reusability. Event loops & IO have been abstracted away for a long time, yet people refuse to use these abstractions for reasons unknown to me and keep reinventing game loops in every game, instead of just referring to some lifecycle schema like Unity3D's (https://docs.unity3d.com/Manual/ExecutionOrder.html https://docs.unity3d.com/Manual/ExecutionOrder.html) or Qt's (http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html). These schemas did not come out of thin air, but of years of experimenting on different categories of apps and seeing what works and what does not ; 99% of the time you don't need to deviate from them, especially if you're not making an AAA. > This is my experience with Qt at least (as well as with CMake, for example). I feel like we're living in a parallel world. Qt maintains API and ABI compatibility for major versions, the last breakage was in Qt 4 -> 5 transition 6 years ago. And a large part of the apps I use still have CMake 2.6 - 2.8 level buildscripts while we're at 3.10, and they still work as-is.

billsix 9y ago

Modularity. In a project of mine, https://github.com/billsix/hurtbox https://github.com/billsix/hurtbox, I switched from "dear imgui" to "nuklear" trivially. I imagine that switching a project from qt to gtk or wxwidgets would be a massive rewrite.

jamesaustin 9y ago
Curious to know why you switched?