4 ms·

Qt5's qtbase module is over 2 million LOC, and doesn't even cover QML, QtQuick, etc. Just having proper abstractions over each platform[1]'s: - windowing - K

Qt5's qtbase module is over 2 million LOC, and doesn't even cover QML, QtQuick, etc. Just having proper abstractions over each platform[1]'s: - windowing - KB/mouse/tablet/touch input - raster painting - 3D APIs (Vk, D3D, GL, Metal...) - text layout and rendering - support for accessibility APIs + things such as generic data models for tables and trees, etc... is already an immense amount of work, and you haven't even started drawing a single button yet. * https://github.com/qt/qtbase/tree/dev/src/plugins/platforms https://github.com/qt/qtbase/tree/dev/src/plugins/platforms

badsectoracula 5y ago
You do not need to replicate all features of Qt to make a GUI toolkit, especially since Qt tends to have a ton of stuff outside GUIs and actually has two "widgets" approaches (classic widgets and QML). For example the 3D API stuff are pointless beyond context creation, unless you use only that 3D API (instead of underlying window system functionality) to put stuff on screen. Qt also recreates a ton of features found in C++ and if we're considering a new language, chances are the language itself has features that make Qt's unnecessary.
- jcelerier 5y ago
  Which features are you talking about ? Even in c++23 there isn't yet a way to replicate moc, rcc, uic with the same ergonomy for the end user and the same efficiency.
  - badsectoracula 5y ago
    I mean things like containers though in the context of a new language chances are the language itself may provide functionality that makes moc unnecessary. Also you certainly do not need something like moc to make a GUI library, which comes back to what i originally wrote in that you do not need to replicate Qt to have a GUI library.
    - ogoffart 5y ago
      "containers" was not in the list. There sure is some overlap with what Qt offers that most language offers (Containers, Networking, Database, threading, ...). But purely in the context of making a UI library, there is still a huge amount of things that Qt offers that needs to be replicated.
      - badsectoracula 5y ago
        The post i replied to was about how big Qt is, which includes containers, etc. That the specific examples given did not contain "containers" isn't relevant since they are part of the "2 million LOC" mentioned. Yes, you need to implement similar functionality, like abstracting the window system, input handling, text, etc but you do not need to replicate what Qt does to have a GUI toolkit. Qt is very complex and Qt is (among others) a GUI library but Qt being complex doesn't mean that GUI libraries have to be complex.
        rob74 5y ago
        ...but, as others have noted, even if you want to only support the "core" features that most people would take for granted for a GUI (cross-platform, all the "usual" widgets including complicated ones such as RichEdit, ListView, TreeView, text with Unicode support and subpixel rendering etc. etc.) it's already a massive undertaking.
        badsectoracula 5y ago
        That is another issue, yes, it is not trivial (though it isn't like making a browser or even a game engine - especially since game engines nowadays tend to have their own GUI toolkits :-P) but my point was that you do not need to replicate what Qt does to have a useful and usable library.
- jerf 5y ago
  Correct. You don't have to replicate anywhere near what Qt has to make a useful toolkit. However, here is your experience with almost every other toolkit: Download it, compile it, build a couple test screens with it, maybe even build a couple of your production screens with it, then the inevitable disaster: You have some requirement, and you need a calendar that can highlight certain dates, or that gives you mouseevents on each individual date, or allows Jewish as well as Gregorian calendars, or that allows you to add things between the month name and the month days other than what the widget already puts there, or that... etc., for any of dozens of specialized requirements. And then you bounce off the toolkit and tell people in online discussions that you really enjoyed working with it, it was nice that it was so simple, and it has a lot of promise and you hope the developers keep working on it, but it wasn't suitable for your needs and Qt had exactly the widget you needed or at least the widget you needed had the plugin points you needed to do your job. (In the meantime, the project stalls and dies because nobody else is using it either, but all for different reasons.) And you hadn't even gotten a tenth of your dialogs started. Another common one is, as people say, trying to add a rich text dialog and getting hit hard by bugs, counterintuitive behaviors, internationalization issues, etc. Nobody uses all of what Qt offers. I can't even imagine what it would look like for a program to use literally everything it has. Even a full office suite would be pressed to do that. But everybody uses lots of different things. Put 10 Qt GUI users together and they'll use very different subsets beyond the bare basics like layouts and simple buttons. Simply to write a binding to a GUI toolkit, ignoring all the other aspects of Qt, is itself a major project. There's been more than one Python project for it, and it is a project, generally more than one person could hope to do. To write a full toolkit that won't give people the experience above is enormous. And that is why it is important to select your language carefully if you're writing a GUI-heavy project. You can't just pick up your favorite language and casually expect every widget you need to be available. Even if you nominally have "a binding to Qt" in your language, in my experience it's important to still double check that the binding to the widget(s) you need actually work, because anything beyond those bare basic layout, buttons, and bindings to simple widgets everybody uses is still quite possibly broken, or incompletely bound so it can't actually be used (which means nobody can have ever even tried this widget), or straight-up missing, or it's present but there's no way to correctly subclass something then make the bound widget use your subclass (in the foreign language) correctly, or something. Nor can you just bide your time and hope a toolkit appears. They're enormous projects, even just to get one to the point that most developers don't generally hit a vital bit of missing functionality, let alone to get one full of all the features someone could reasonably want.
MaxBarraclough 5y ago
A few more for the list: * Internationalisation * Concurrency, parallelism, and perhaps async (probably less of an issue with modern C++, but Qt still has plenty on offer here [0]) * Integration with various platform-specific build tools and IDEs [0] https://doc.qt.io/qt-5/threads-technologies.html https://doc.qt.io/qt-5/threads-technologies.html

badsectoracula 5y ago

You do not need to replicate all features of Qt to make a GUI toolkit, especially since Qt tends to have a ton of stuff outside GUIs and actually has two "widgets" approaches (classic widgets and QML). For example the 3D API stuff are pointless beyond context creation, unless you use only that 3D API (instead of underlying window system functionality) to put stuff on screen. Qt also recreates a ton of features found in C++ and if we're considering a new language, chances are the language itself has features that make Qt's unnecessary.

jcelerier 5y ago
Which features are you talking about ? Even in c++23 there isn't yet a way to replicate moc, rcc, uic with the same ergonomy for the end user and the same efficiency.
- badsectoracula 5y ago
  I mean things like containers though in the context of a new language chances are the language itself may provide functionality that makes moc unnecessary. Also you certainly do not need something like moc to make a GUI library, which comes back to what i originally wrote in that you do not need to replicate Qt to have a GUI library.
  - ogoffart 5y ago
    "containers" was not in the list. There sure is some overlap with what Qt offers that most language offers (Containers, Networking, Database, threading, ...). But purely in the context of making a UI library, there is still a huge amount of things that Qt offers that needs to be replicated.
    - badsectoracula 5y ago
      The post i replied to was about how big Qt is, which includes containers, etc. That the specific examples given did not contain "containers" isn't relevant since they are part of the "2 million LOC" mentioned. Yes, you need to implement similar functionality, like abstracting the window system, input handling, text, etc but you do not need to replicate what Qt does to have a GUI toolkit. Qt is very complex and Qt is (among others) a GUI library but Qt being complex doesn't mean that GUI libraries have to be complex.
      - rob74 5y ago
        ...but, as others have noted, even if you want to only support the "core" features that most people would take for granted for a GUI (cross-platform, all the "usual" widgets including complicated ones such as RichEdit, ListView, TreeView, text with Unicode support and subpixel rendering etc. etc.) it's already a massive undertaking.
        badsectoracula 5y ago
        That is another issue, yes, it is not trivial (though it isn't like making a browser or even a game engine - especially since game engines nowadays tend to have their own GUI toolkits :-P) but my point was that you do not need to replicate what Qt does to have a useful and usable library.
jerf 5y ago
Correct. You don't have to replicate anywhere near what Qt has to make a useful toolkit. However, here is your experience with almost every other toolkit: Download it, compile it, build a couple test screens with it, maybe even build a couple of your production screens with it, then the inevitable disaster: You have some requirement, and you need a calendar that can highlight certain dates, or that gives you mouseevents on each individual date, or allows Jewish as well as Gregorian calendars, or that allows you to add things between the month name and the month days other than what the widget already puts there, or that... etc., for any of dozens of specialized requirements. And then you bounce off the toolkit and tell people in online discussions that you really enjoyed working with it, it was nice that it was so simple, and it has a lot of promise and you hope the developers keep working on it, but it wasn't suitable for your needs and Qt had exactly the widget you needed or at least the widget you needed had the plugin points you needed to do your job. (In the meantime, the project stalls and dies because nobody else is using it either, but all for different reasons.) And you hadn't even gotten a tenth of your dialogs started. Another common one is, as people say, trying to add a rich text dialog and getting hit hard by bugs, counterintuitive behaviors, internationalization issues, etc. Nobody uses all of what Qt offers. I can't even imagine what it would look like for a program to use literally everything it has. Even a full office suite would be pressed to do that. But everybody uses lots of different things. Put 10 Qt GUI users together and they'll use very different subsets beyond the bare basics like layouts and simple buttons. Simply to write a binding to a GUI toolkit, ignoring all the other aspects of Qt, is itself a major project. There's been more than one Python project for it, and it is a project, generally more than one person could hope to do. To write a full toolkit that won't give people the experience above is enormous. And that is why it is important to select your language carefully if you're writing a GUI-heavy project. You can't just pick up your favorite language and casually expect every widget you need to be available. Even if you nominally have "a binding to Qt" in your language, in my experience it's important to still double check that the binding to the widget(s) you need actually work, because anything beyond those bare basic layout, buttons, and bindings to simple widgets everybody uses is still quite possibly broken, or incompletely bound so it can't actually be used (which means nobody can have ever even tried this widget), or straight-up missing, or it's present but there's no way to correctly subclass something then make the bound widget use your subclass (in the foreign language) correctly, or something. Nor can you just bide your time and hope a toolkit appears. They're enormous projects, even just to get one to the point that most developers don't generally hit a vital bit of missing functionality, let alone to get one full of all the features someone could reasonably want.

MaxBarraclough 5y ago

A few more for the list: * Internationalisation * Concurrency, parallelism, and perhaps async (probably less of an issue with modern C++, but Qt still has plenty on offer here [0]) * Integration with various platform-specific build tools and IDEs [0] https://doc.qt.io/qt-5/threads-technologies.html https://doc.qt.io/qt-5/threads-technologies.html