Sujet : Re: 'Graphics' of libwy
De : david.brown (at) *nospam* hesbynett.no (David Brown)
Groupes : comp.lang.c++Date : 18. Dec 2024, 09:09:22
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vjtvvk$2787g$1@dont-email.me>
References : 1 2 3 4 5 6
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
On 17/12/2024 17:53,
Muttley@DastardlyHQ.org wrote:
On Tue, 17 Dec 2024 17:30:18 +0100
David Brown <david.brown@hesbynett.no> wibbled:
On 17/12/2024 17:02, Muttley@DastardlyHQ.org wrote:
Personally I'd go with Qt. Its mature and cross platform and does what 99%
of most people need.
>
>
No, it doesn't come close to that. It's a solid gui library with lots
of extra tools, and is useful to many people - but it's nothing remotely
like you suggest.
>
It has a license that is totally unsuitable for standardisation. I'm
not complaining about the license - the people that wrote the library
get to pick the license. But a standard C++ gui library, if such a
thing is ever made, has to have a very liberal license - BSD/MIT at most.
>
And Qt is hardly a lightweight choice either.
None of them are. If you want lightweight don't use a cross platform library.
That's not true - FLTK comes to mind. (I have not used it.)
Sometimes you want a heavyweight toolkit with lots of features, sometimes you want a lightweight toolkit. And sometimes you want something completely different, such as an immediate mode gui toolkit. This is why a /standard/ C++ gui library makes little sense.
Look at other languages - Python has a "standard" gui library based on Tkinter, but there are a dozen other popular gui toolkits used with Python. One size does not come close to fitting all for gui toolkits.
I think if there is ever going to be a standard gui library for C++, it
will be written specially for the purpose. That has some big advantages
- if the designers decide they need extra language features for signals
and slots, for example, then those can be added to the language rather
than using an external tool.
You don't want a library that only works with the latest bleeding edge versions
of C++. IMO C++ 2011 would be a reasonable oldest version.
I'd much rather have one that takes advantage of relatively modern C++ features than one that re-invented these same features in their one special ways - which is what you see with these older libraries. I'd put C++11 as a minimum stepping point - C++ post-C++11 is a very different language from that of pre-C++11. But if I were looking for a new, well-designed modern C++ gui library, I'd want to see concepts, std::format, ranges, and that the whole thing was organised in modules. That all means C++20. It's worth upgrading your tools for those for something like a gui library.
But if the C++ committee were to make a standard C++ gui library as part of the C++ standard, then it would by definition be part of a later C++ standard. So if it was targeted for C++29, then of course it could rely on all the language and library features of standard C++ up to and including C++29.