I had headache whenevr I think about graphics in C++. Why C++ does not provide
a graphics library (lots complaint about this), not even a simplest one for demonstrating its 'power' of C++ itself?
On 12/16/2024 3:29 AM, David Brown wrote:
On 15/12/2024 11:04, wij wrote:
I had headache whenevr I think about graphics in C++. Why C++ does
not provide
a graphics library (lots complaint about this), not even a simplest
one for
demonstrating its 'power' of C++ itself?
There are 101 C++ graphics libraries, all with their pros and cons and
different use-cases. How could the C++ standard library pick just one
of them?
Open Source and LGPL would be a good place to start.
https://en.wikipedia.org/wiki/List_of_widget_toolkits
On 12/15/2024 4:04 AM, wij wrote:
I had headache whenevr I think about graphics in C++. Why C++ does not...
provide
a graphics library (lots complaint about this), not even a simplest
one for
demonstrating its 'power' of C++ itself? Then, I suddenly realized
that the
minimal answer is already there because the resolution of modern text
screen
(emulator) is barely enough (width can be >320).
I totally agree that C++ should have a graphics library and a user
interface library both.
Have you looked at
https://wxwidgets.org/
"wxWidgets is a C++ library that lets developers create applications for Windows, macOS, Linux and other platforms with a single code base. It
has popular language bindings for Python, Ruby, Lua, Perl and several
other languages, and unlike other cross-platform toolkits, wxWidgets
gives applications a truly native look and feel because it uses the platform's native API rather than emulating the GUI. It's also
extensive, free, open-source and mature."
On 17.12.2024 02:41, Lynn McGuire wrote:
On 12/15/2024 4:04 AM, wij wrote:
wxWidgets does work and is better than MFC, but not extremely so. Also,
it is not exactly light-weight, a git checkout is 803 MB. Good luck for
the standards committee to standardize anything like that.
Also, wxWidgets would be only part of the solution, it would still need
a graphics back-end for actually drawing anything, plus some fonts for >rendering texts. On some platforms the graphics back-end is built into
the OS, on others it is not.
BTW, what has happened with Mr Flibble and his neoGFX library?
On 17.12.2024 02:41, Lynn McGuire wrote:
On 12/15/2024 4:04 AM, wij wrote:
I had headache whenevr I think about graphics in C++. Why C++ does not...
provide
a graphics library (lots complaint about this), not even a simplest
one for
demonstrating its 'power' of C++ itself? Then, I suddenly realized
that the
minimal answer is already there because the resolution of modern text
screen
(emulator) is barely enough (width can be >320).
I totally agree that C++ should have a graphics library and a user
interface library both.
Have you looked at
https://wxwidgets.org/
"wxWidgets is a C++ library that lets developers create applications for
Windows, macOS, Linux and other platforms with a single code base. It
has popular language bindings for Python, Ruby, Lua, Perl and several
other languages, and unlike other cross-platform toolkits, wxWidgets
gives applications a truly native look and feel because it uses the
platform's native API rather than emulating the GUI. It's also
extensive, free, open-source and mature."
wxWidgets does work and is better than MFC, but not extremely so. Also,
it is not exactly light-weight, a git checkout is 803 MB. Good luck for
the standards committee to standardize anything like that.
Also, wxWidgets would be only part of the solution, it would still need
a graphics back-end for actually drawing anything, plus some fonts for >rendering texts. On some platforms the graphics back-end is built into
the OS, on others it is not.
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.
On 17/12/2024 17:02, [email protected] 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.
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.
<snip>
I don't know if that will stop the C++ committee from trying to pick or
make a standard GUI library - after all, it's certainly an appealing
idea. But if the "success" of C++'s threading support is any judge,
they have a hard road in front of them.
On Tue, 17 Dec 2024 16:38:49 +0200
Paavo Helde <[email protected]> wibbled:
On 17.12.2024 02:41, Lynn McGuire wrote:
On 12/15/2024 4:04 AM, wij wrote:
I had headache whenevr I think about graphics in C++. Why C++ does not >>>> provide...
a graphics library (lots complaint about this), not even a simplest
one for
demonstrating its 'power' of C++ itself? Then, I suddenly realized
that the
minimal answer is already there because the resolution of modern text
screen
(emulator) is barely enough (width can be >320).
I totally agree that C++ should have a graphics library and a user
interface library both.
Have you looked at
https://wxwidgets.org/
"wxWidgets is a C++ library that lets developers create applications for >>> Windows, macOS, Linux and other platforms with a single code base. It
has popular language bindings for Python, Ruby, Lua, Perl and several
other languages, and unlike other cross-platform toolkits, wxWidgets
gives applications a truly native look and feel because it uses the
platform's native API rather than emulating the GUI. It's also
extensive, free, open-source and mature."
wxWidgets does work and is better than MFC, but not extremely so. Also,
it is not exactly light-weight, a git checkout is 803 MB. Good luck for
the standards committee to standardize anything like that.
Also, wxWidgets would be only part of the solution, it would still need
a graphics back-end for actually drawing anything, plus some fonts for
rendering texts. On some platforms the graphics back-end is built into
the OS, on others it is not.
Does wx do 3D stuff? If not you'd need yet another library to do that too.
Personally I'd go with Qt. Its mature and cross platform and does what 99%
of most people need.
On 17/12/2024 17:02, [email protected] wrote:
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.
David Brown wrote this post while blinking in Morse code:
<snip>
I don't know if that will stop the C++ committee from trying to
pick or make a standard GUI library - after all, it's certainly an appealing idea. But if the "success" of C++'s threading support is
any judge, they have a hard road in front of them.
I was just going to say "imagine how long that would get tied up in
the standards committee."
Anyhoo, years ago I used Borland's OWL and it was decent for the time.
Years after that, Borland used VCL as it's C++ graphics library...
written in Object Pascal. Some weird shit went on in the debugger
with that one.
On Tue, 17 Dec 2024 17:30:18 +0100
David Brown <[email protected]> wibbled:
On 17/12/2024 17:02, [email protected] 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.
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.
David Brown wrote this post while blinking in Morse code:
<snip>
I don't know if that will stop the C++ committee from trying to pick or
make a standard GUI library - after all, it's certainly an appealing
idea. But if the "success" of C++'s threading support is any judge,
they have a hard road in front of them.
I was just going to say "imagine how long that would get tied up in the standards committee."
Anyhoo, years ago I used Borland's OWL and it was decent for the time.
Years after that, Borland used VCL as it's C++ graphics library... written in Object Pascal. Some weird shit went on in the debugger with that one.
On 17.12.2024 18:30, David Brown wrote:
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.
For curiosity I looked at the https://neogfx.org page. Among other
things it says: "C++ lambdas have made traditional signals and slots redundant".
It also promises "modern C++20 design" and "no reliance on macro-based
code generation".
NeoGFX itself has a too restrictive license (GPL), but at least it
suggests that C++ nowadays is expressive enough to actually allow for
some kind of self-contained and concise GUI library.
On 17/12/2024 17:53, [email protected] wrote:
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
new, well-designed modern C++ gui library, I'd want to see concepts,
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.
On Wed, 18 Dec 2024 09:09:22 +0100
David Brown <[email protected]> wibbled:
On 17/12/2024 17:53, [email protected] wrote:
You don't want a library that only works with the latest bleeding edgeversions
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
A lot of companies systems don't have their compilers upgraded if consistency are whats required. A security company I worked at a few years ago only
went up to C++14 because they didn't want any nasty security hole surprises if they upgraded the compiler and started using the new features (or even the older ones).
new, well-designed modern C++ gui library, I'd want to see concepts,
Ugh. Concepts and constraints are yet another syntatic soup solution to a problem almost no one has except in various academic ivory towers.
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.
Well they won't because sensibly they realise graphics capabilities are so variable - or non existent - between systems that there's absolutely no point trying to develop a standard library for it.
I was surprised they even
included a threading library given on various embedded systems threading is not available. Plus its inconsistent - why multithreading but no multiprocess?
On 18/12/2024 10:16, [email protected] wrote:
I was surprised they even
included a threading library given on various embedded systems threading is >> not available. Plus its inconsistent - why multithreading but no >multiprocess?
Threading in C11 and C++11 was too little, too late. And it doesn't
take into account the significantly different threading systems used in >different OS's. For embedded systems, how is anyone supposed to use a >threading library that doesn't handle priorities, stack size, and the like?
I think trying to standardise a C++ gui library would be like
standardising threading, but orders of magnitude worse.
On Sun, 2024-12-22 at 15:26 -0800, Chris M. Thomasson wrote:
On 12/22/2024 10:50 AM, wij wrote:
[...]
I just wrote two program (face_svr.cpp, face_cli.cpp) to test what I th= >ought.Well, sure. PPM's are rather easy to create. :^)
It looks plausible using C++ to write graphic programs without using an= >y
graphic library. Dream come true! 'C++ graphics' is possible and easy. >>=20
=20
Creating OBJ files in C/C++ is rather easy as well.
For simple GUI, e.g. drawing graph of math. functions, statistics, Mandelbr= >ot
set,...) is no problem.
int main() {
Array2D<Pixel> img;
draw_mand(img);
put_image("graphics_server", img);
zoom_event_handler();
}
The solution of C++ graphics (or GUI) is no graphics in C++.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 162:44:50 |
| Calls: | 12,095 |
| Calls today: | 3 |
| Files: | 15,000 |
| Messages: | 6,517,780 |