"Wondering how C++ got this far? So does its creator" By Julia Schmidt

[Cholo Lennon]

Interesting article about the latest paper from Bjarne Stroustrup:

https://devclass.com/2020/06/18/cpp-creator-on-current-state-of-the-language/

--
Cholo Lennon
Bs.As.
ARG

[Mr Flibble]

"support for simple graphics"

no, just no.

/Flibble

--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin

“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."

[Cholo Lennon]

On 22/6/20 14:54, Mr Flibble wrote:
> On 22/06/2020 17:18, Cholo Lennon wrote:
>> Interesting article about the latest paper from Bjarne Stroustrup:
>>
>> https://devclass.com/2020/06/18/cpp-creator-on-current-state-of-the-language/
>>
>>
>> --
>> Cholo Lennon
>> Bs.As.
>> ARG
>
> "support for simple graphics"
>
> no, just no.
>

Yeah :-P it's a mystery to me what would be the scope for "simple
graphics", something half finished perhaps? :-O

I don't want to see something like Java AWT -> Swing -> JavaFX...

[Lynn McGuire]

"Other than that, Stroustrup sees promise in areas such as unicode
support, support for simple graphics and user interaction, new kinds of
hardware, and “exploration of improved styles and implementations of
error-handling”. Stability is vital in all of this and “requires a focus
on compatibility as well as resisting the urge to try to radically
improve C++ by adding a multitude of ‘perfect’ features to replace
imperfect or unfashionable older ways of doing things”."

And a simple user interface toolkit would be very nice.

Lynn

[Cholo Lennon]

Quoting the last quote:

"...as well as resisting the urge to try to radically improve C++ by

adding a multitude of ‘perfect’ features to replace imperfect or
unfashionable older ways of doing things"

IMHO they already have failed to accomplish that idea.

> And a simple user interface toolkit would be very nice.
>

I am afraid of the cited simplicity... too simple that nobody use it,
too simple that looks awful among platforms and, as a result, nobody
used it, etc.

[Ian Collins]

On 23/06/2020 07:00, Cholo Lennon wrote:
> On 22/6/20 14:54, Mr Flibble wrote:
>> On 22/06/2020 17:18, Cholo Lennon wrote:
>>> Interesting article about the latest paper from Bjarne Stroustrup:
>>>
>>> https://devclass.com/2020/06/18/cpp-creator-on-current-state-of-the-language/
>>>
>>>
>>> --
>>> Cholo Lennon
>>> Bs.As.
>>> ARG
>>
>> "support for simple graphics"
>>
>> no, just no.
>>
>
> Yeah :-P it's a mystery to me what would be the scope for "simple
> graphics", something half finished perhaps? :-O

ASCII art!

--
Ian.

[Keith Thompson]

Ian Collins <ian-...@hotmail.com> writes:
> On 23/06/2020 07:00, Cholo Lennon wrote:
>> On 22/6/20 14:54, Mr Flibble wrote:
>>> On 22/06/2020 17:18, Cholo Lennon wrote:
>>>> Interesting article about the latest paper from Bjarne Stroustrup:
>>>>
>>>> https://devclass.com/2020/06/18/cpp-creator-on-current-state-of-the-language/
>>>

>>> "support for simple graphics"
>>>
>>> no, just no.
>>
>> Yeah :-P it's a mystery to me what would be the scope for "simple
>> graphics", something half finished perhaps? :-O
>
> ASCII art!

Surely you're not suggesting disallowing EBCDIC art!

Turtle graphics, anybody?

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[Jorgen Grahn]

On Tue, 2020-06-23, Ian Collins wrote:
> On 23/06/2020 07:00, Cholo Lennon wrote:

...

>> Yeah :-P it's a mystery to me what would be the scope for "simple
>> graphics", something half finished perhaps? :-O
>
> ASCII art!

std::curses!

Seriously, I've waited for 25--30 for GUIs to stabilize. It hasn't
happened, so I don't think it ever will.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Chris M. Thomasson]

Being able to create a PPM. Wait, C and C++ already do that. Sarcasm...

C++ needs to fully support GLSL. lol. ;^)

https://glm.g-truc.net/0.9.9/index.html

[Chris M. Thomasson]

On 6/22/2020 10:47 PM, Keith Thompson wrote:
> Ian Collins <ian-...@hotmail.com> writes:
>> On 23/06/2020 07:00, Cholo Lennon wrote:
>>> On 22/6/20 14:54, Mr Flibble wrote:
>>>> On 22/06/2020 17:18, Cholo Lennon wrote:
>>>>> Interesting article about the latest paper from Bjarne Stroustrup:
>>>>>
>>>>> https://devclass.com/2020/06/18/cpp-creator-on-current-state-of-the-language/
>>>>
>>>> "support for simple graphics"
>>>>
>>>> no, just no.
>>>
>>> Yeah :-P it's a mystery to me what would be the scope for "simple
>>> graphics", something half finished perhaps? :-O
>>
>> ASCII art!
>
> Surely you're not suggesting disallowing EBCDIC art!
>
> Turtle graphics, anybody?
>

I a strange sense, I would not mind. ;^)

Hey man, C++ needs to support PILOT:

https://en.wikipedia.org/wiki/PILOT

lol. ;^)

[Juha Nieminen]

Cholo Lennon <cholo...@hotmail.com> wrote:
>> And a simple user interface toolkit would be very nice.
>
> I am afraid of the cited simplicity... too simple that nobody use it,
> too simple that looks awful among platforms and, as a result, nobody
> used it, etc.

While I don't think a GUI / graphics library in the standard C++ library
would be an excellent idea, I see one small advantage for it.

Currently there are like nine billion GUI/graphical libraries out there,
none of which follow *any* kind of standard (because there is no standard).
It's a complete wild west out there, when it comes to such libraries.
Every library developers does whatever he feels like, and almost all such
libraries are the product of adding kludges on top of kludges for years
until the entire interface for the library is a complete mess.

But that's actually a side rant. The main problem is not the variety and
poor quality of such libraries. It's the fact that there are so many,
and that they do not follow any standard.

Such libraries tend to be tied to a particular system and/or a particular
set of compilers. Thus there are myriads of programs/projects out there
that use some random GUI library, and if you try to compile them you'll
find out that they need that library... which depending on your particular
setup may be a real PitA to get to compile.

Most usually the GUI library will have decent support for unix-like
systems... but lack support for Microsoft's compilers for Windows.
And even if they have a project file for Visual Studio or something...
it will still be a PitA to try to compile it with mingw64 or something.
(Believe me, I know from experience.)

Almost 99.9% of the time all these libraries designed for unix-like systems
will be held hostake by a gigantic "configure" script, without which it's
almost impossible to compile the library.

(Side rant: I absolutely hate, loathe, detest and wish all such libraries
to burn in the deepest pits of hell, especially the ones that contain
absolutely nothing that couldn't be written in standard C or C++. Believe
me, there are loads and loads of such libraries out there. Libraries that
could perfect well be written in 100% portable standard C or C++... but
which are *still* being held hostage by a gigantic "configure" script
without which it's an astonishing PitA to try to compile the library
because the developers, for reasons probably not known even to them,
decided to litter the entire billion-lines-of-code library with names
that are only created by that configure script.

Being held hostage by such a configure script usually means that you can
pretty much forget trying to use the library in any environment for which
the script has no direct support for, such as cross-compiling for iOS.
Or just using mingw64 on Windows. This is espcially aggravating if, as
said, the library does nothing that cannot be done in 100% standard C
or C++.)

Anyway, a *standard* C++ GUI library would mean that you don't need to
burden your small project with a dependency to some random third-party
library, which may make it really hard for people to compile to some
particular environment.

I think that's already the case with standard library utilities like
<regex> and <filesystem>.

Of course a GUI library would be a beast completely on its own league, and
it might be more unfeasible than those.

[Bo Persson]

On 2020-06-23 at 08:23, Juha Nieminen wrote:
> Cholo Lennon <cholo...@hotmail.com> wrote:
>>> And a simple user interface toolkit would be very nice.
>>
>> I am afraid of the cited simplicity... too simple that nobody use it,
>> too simple that looks awful among platforms and, as a result, nobody
>> used it, etc.
>
> While I don't think a GUI / graphics library in the standard C++ library
> would be an excellent idea, I see one small advantage for it.
>
> Currently there are like nine billion GUI/graphical libraries out there,
> none of which follow *any* kind of standard (because there is no standard).
> It's a complete wild west out there, when it comes to such libraries.
> Every library developers does whatever he feels like, and almost all such
> libraries are the product of adding kludges on top of kludges for years
> until the entire interface for the library is a complete mess.
>
> But that's actually a side rant. The main problem is not the variety and
> poor quality of such libraries. It's the fact that there are so many,
> and that they do not follow any standard.
>

One standard to rule them all?

https://xkcd.com/927/

[Siri Cruise]

In article <rcqlkj$19ea$1...@gioia.aioe.org>,

Cholo Lennon <cholo...@hotmail.com> wrote:

> Interesting article about the latest paper from Bjarne Stroustrup:

C++: Algol meets Cobol.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
The first law of discordiamism: The more energy This post / \
to make order is nore energy made into entropy. insults Islam. Mohammed

[Manfred]

Agreed!

[Bart]

This has long been a bone of contention for me. Ridiculously complicated
build systems dominated by a 20-40,000-line auto-generated 'configure'
Bash script, sometimes bigger than the application source code.

Even when the developers deign to support Windows, that is in the form
of 'solution' or project files for MS tools, requiring VS to be
installed, an even bigger (multi-GB) and cumbersome dependency.

Although apparently the recommended solution for building on Windows, to
get around the myriad Linux dependencies, is not to get rid of those
dependencies, but to install half of Linux on Windows!

That is, using Cygwin, MSYS, MSYS2 or WSL.

This is even for applications that ought to be portable across OSes
anyway. Or portable by subsituting one OS-specific module for another.

> Currently there are like nine billion GUI/graphical libraries out there,
> none of which follow *any* kind of standard (because there is no
standard).

I quite like GTK, which is a C library (one I've never managed to use
except to manage the simplest test).

The interface is a mere 300,000 lines of declarations, across 600 header
files. The library itself is a set of 28 or 58 DLL files (I forget how
many). I think there are 7000 or 9000 functions in all.

So easy to quickly add a plotted graph display to your program and ship
with your executable.

I think what some people have in mind for a small graphics library is
what used to come included with any BASIC of a 1980s microcomputer.

[Juha Nieminen]

Bo Persson <b...@bo-persson.se> wrote:
>> But that's actually a side rant. The main problem is not the variety and
>> poor quality of such libraries. It's the fact that there are so many,
>> and that they do not follow any standard.
>>
>
> One standard to rule them all?
>
> https://xkcd.com/927/

It's not so much about following a particular standard, but to have a way
of doing it in a way that Will Just Compile as-is in any system with a
new-enough compiler, without requiring any third-party libraries (which,
as said, might be a real PitA to compile/integrate).

Consider for example the C++11 <regex> header: There is no "standard"
interface for a regex library, and the C++ committee chose one way of
doing it (or, more probably, the Boost developers did). However, if
you use this header, it Will Just Compile with any standard-conforming
C++ compiler, without requiring any third-party library.

If you use a third-party regex library then you would be putting an
additional burden to anybody who would want to compile your project
on their system (unless you include said library with the project
in a manner that requires zero effort from part of the other person
to make it work).

[bol...@nowhere.co.uk]

On Tue, 23 Jun 2020 12:16:22 +0100
Bart <b...@freeuk.com> wrote:
>On 23/06/2020 07:23, Juha Nieminen wrote:
>> Cholo Lennon <cholo...@hotmail.com> wrote:
>This has long been a bone of contention for me. Ridiculously complicated
>build systems dominated by a 20-40,000-line auto-generated 'configure'
>Bash script, sometimes bigger than the application source code.

It never used to be like that - back in the day you got a Makefile which
needed to be manually edited to work on a particular *nix but that generally
took a few minutes at most then type "make" and you were done.

>I think what some people have in mind for a small graphics library is
>what used to come included with any BASIC of a 1980s microcomputer.

You either do graphics properly or don't bother. There's no point doing some
cut down mickey mouse API that would be useless to 99% of users. Plus
graphics extends beyond the actual graphics - it needs to handle multiple
windows and event handling.

One think that would be nice to have , not as part of the core language but
certainly as a standard API would be sound handling. Its a lot simpler than
graphics and would let users escape from the badly documented and hopelessly
unintuitive APIs that currently exist , eg ALSA, Apples Core Audio, Pulse
Audio. All utterly dreadful.

[Juha Nieminen]

Bart <b...@freeuk.com> wrote:
> This has long been a bone of contention for me. Ridiculously complicated
> build systems dominated by a 20-40,000-line auto-generated 'configure'
> Bash script, sometimes bigger than the application source code.
>
> Even when the developers deign to support Windows, that is in the form
> of 'solution' or project files for MS tools, requiring VS to be
> installed, an even bigger (multi-GB) and cumbersome dependency.

Don't get me even started with how complicated it can be to compile one of
those "unix-style" libraries for iOS (or tvOS).

The big irony here is that both macOS and iOS are extremely unix-like
(in fact, I believe macOS is a genuine Unix, as I think it has been
ratified as conforming to the Single Unix Specification; I'm not sure
about iOS, but if it isn't, it's pretty damn close), yet you wouldn't
believe how complicated it can be to build one of these "unix" libraries
for iOS.

The main reason is that when you build for iOS you aren't building for
the current host system. You are cross-compiling in macOS for an iOS
target. And in this particular case it has to be cross-compiled with
very specific Xcode commands, using very specific development
libraries. Basically none of these configure scripts have been implemented
to support anything even resembling this.

Often the easiest (although it's not the only) way to compile a library
for iOS is to actually add its source code to your iOS project. Problem
is, if the source code won't compile without running a gigantic configure
script, you are stuck. (Also, adding a billion source files scattered
among a million subdirectories to your project can be a real pain,
especially if not all of those source files should actually be
compiled, eg. if they are some kind of test files or tools that are
not part of the library proper.)

> I think what some people have in mind for a small graphics library is
> what used to come included with any BASIC of a 1980s microcomputer.

I think it's actually a bit of an embarrassment for C++ as a language
that when a beginner asks me something like "I'm trying to learn C++,
how can I draw some lines on screen?" I always have to answer with
"uh... well... it's... complicated".

I sometimes just recommend them using javascript and a html5 canvas
instead. Saves a lot of trouble.

[Juha Nieminen]

bol...@nowhere.co.uk wrote:
> On Tue, 23 Jun 2020 12:16:22 +0100
> Bart <b...@freeuk.com> wrote:
>>On 23/06/2020 07:23, Juha Nieminen wrote:
>>> Cholo Lennon <cholo...@hotmail.com> wrote:
>>This has long been a bone of contention for me. Ridiculously complicated
>>build systems dominated by a 20-40,000-line auto-generated 'configure'
>>Bash script, sometimes bigger than the application source code.
>
> It never used to be like that - back in the day you got a Makefile which
> needed to be manually edited to work on a particular *nix but that generally
> took a few minutes at most then type "make" and you were done.

Too complicated. That's why they invented automake... and cmake... and...

Ok, I'll shut up now. :P

[bol...@nowhere.co.uk]

Except they often didn't work why configure scripts became popular.

[Öö Tiib]

Just compiling and running short snippet locally is not the reason
why we program. The ridiculously complicated build systems come
from what we actually need.

We need to compile (and cross-compile) programs with different
compilers for different platforms under different options; part
of it involves installing dependencies, part of it accessing
repositories, some part of it is about creating deployable
packages, some part is about deploying and executing something
automatically and some part of it is about generating reports
of any aspect of it.

Current tools have been made to simplify such needs in different
ways. What is and remains missing is at least something of it
being standardized at all.

[Bart]

On 23/06/2020 12:27, bol...@nowhere.co.uk wrote:
> On Tue, 23 Jun 2020 12:16:22 +0100
> Bart <b...@freeuk.com> wrote:
>> On 23/06/2020 07:23, Juha Nieminen wrote:
>>> Cholo Lennon <cholo...@hotmail.com> wrote:
>> This has long been a bone of contention for me. Ridiculously complicated
>> build systems dominated by a 20-40,000-line auto-generated 'configure'
>> Bash script, sometimes bigger than the application source code.
>
> It never used to be like that - back in the day you got a Makefile which
> needed to be manually edited to work on a particular *nix but that generally
> took a few minutes at most then type "make" and you were done.
>
>> I think what some people have in mind for a small graphics library is
>> what used to come included with any BASIC of a 1980s microcomputer.
>
> You either do graphics properly or don't bother. There's no point doing some
> cut down mickey mouse API that would be useless to 99% of users.

I think there is; you'd be surprised at how simple some requirements can
be; not everyone is developing the latest smartphone app with dazzling
graphics.

What happens at present is that many don't bother with graphics and just
stay with text, which really /is/ a Mickey Mouse way of doing things.

Plus
> graphics extends beyond the actual graphics - it needs to handle multiple
> windows and event handling.

There is plotting stuff on the display, and also dealing with
interaction or creating dialogs - all the GUI stuff which I find a PITA
and try to avoid.

But the basic plotting is simple enough. At present, other than text,
one option is to plot into an image array, write to a format like PPM,
and use an external tool to display. Which is not as handy as directly
drawing to the screen from the program, with some minimal interaction,
or perhaps there are changing or animated elements that can't be done
with a PPM.

> One think that would be nice to have , not as part of the core language but
> certainly as a standard API would be sound handling. Its a lot simpler than
> graphics and would let users escape from the badly documented and hopelessly
> unintuitive APIs that currently exist , eg ALSA, Apples Core Audio, Pulse
> Audio. All utterly dreadful.
>

I've dabbled with sound with libraries like SDL, and they leave a lot to
be desired.

I first played with graphics 40 years ago (putting aside Tektronix
termimals); first on experimental colour raster displays connected to a
PDP11, then building my own stuff. I can tell you the libraries to get
interesting things done needn't be complicated!

I can't do any of that now as simply as I used to, because everything is
so much bigger and more complicated, and OSes have got in the way. It's
just not fun.

I do have a little library for my script language, built on top of Win32
API (so could also be adapted to Linux - X11? - but have never
bothered). There graphics programming looks like this:

w:=gxcreatewindow() # defaults to 640x480, centered

to 100'000 do
gxpixel(w, random(0..w.dimx-1), random(0..w.dimy-1), 0)
end

eventloop() # keep it on the screen until close

(Screenshot: https://github.com/sal55/langs/blob/master/dots.png)

Slightly more elaborate than in BASIC (since it is necessary to create a
window and use its handle as parameter to drawing routines). There is
also more work behind the scenes to restore the display after it's been
obscured, but not something this code needs to worry about.

[Daniel P]

On Tuesday, June 23, 2020 at 2:23:22 AM UTC-4, Juha Nieminen wrote:
>
> Anyway, a *standard* C++ GUI library would mean that you don't need to
> burden your small project with a dependency to some random third-party
> library, which may make it really hard for people to compile to some
> particular environment.
>
> I think that's already the case with standard library utilities like
> <regex> and <filesystem>.
>

<regex> doesn't make your point. Compared to other available solutions,
its regular expression grammars are less expressive, it lacks support for
unicode encodings, and its performance is very poor. My understanding is that
the C++ committee thinks that it's unsalvageable, and wants to replace
it entirely.

But if it takes so much time and effort to get a good regex utility into the
language, what would it take to get a good gui library?

Daniel

[bol...@nowhere.co.uk]

On Tue, 23 Jun 2020 14:13:38 +0100
Bart <b...@freeuk.com> wrote:

>On 23/06/2020 12:27, bol...@nowhere.co.uk wrote:
> Plus
>> graphics extends beyond the actual graphics - it needs to handle multiple
>> windows and event handling.
>
>There is plotting stuff on the display, and also dealing with
>interaction or creating dialogs - all the GUI stuff which I find a PITA
>and try to avoid.
>
>But the basic plotting is simple enough. At present, other than text,

Basic plotting is simple enough - once you've decided where to plot. Will it
be a Window? If so how big will it be, will it have a title, whats the
background colour, or will be be VGA graphics? And if you go with the window
you need to handle creation, destruction, repaint, resize, map/unmap as the
basics then there's keyboard and mouse input events. And none of this has
anything to do with GUIs, its basic window system programming whether its
Windows, X11 or MacOS.

It ain't simple.

>one option is to plot into an image array, write to a format like PPM,
>and use an external tool to display. Which is not as handy as directly

Ugh. Who would bother?

>I first played with graphics 40 years ago (putting aside Tektronix
>termimals); first on experimental colour raster displays connected to a
>PDP11, then building my own stuff. I can tell you the libraries to get
>interesting things done needn't be complicated!
>
>I can't do any of that now as simply as I used to, because everything is
>so much bigger and more complicated, and OSes have got in the way. It's
>just not fun.

Perhaps not, but good luck having multiple programs open and visible at the same
time on that terminal in 24bit alpha blended colour with overlapping windows.
Nostalgia is lovely, but when you actually go back and use the old equipment -
I've got some old gear at home too including various 8 bit machines - you
realise just how rubbish it is compared to modern machines.

[Bart]

On 23/06/2020 15:42, bol...@nowhere.co.uk wrote:
> On Tue, 23 Jun 2020 14:13:38 +0100
> Bart <b...@freeuk.com> wrote:
>> On 23/06/2020 12:27, bol...@nowhere.co.uk wrote:
>> Plus
>>> graphics extends beyond the actual graphics - it needs to handle multiple
>>> windows and event handling.
>>
>> There is plotting stuff on the display, and also dealing with
>> interaction or creating dialogs - all the GUI stuff which I find a PITA
>> and try to avoid.
>>
>> But the basic plotting is simple enough. At present, other than text,
>
> Basic plotting is simple enough - once you've decided where to plot. Will it
> be a Window? If so how big will it be, will it have a title, whats the
> background colour, or will be be VGA graphics? And if you go with the window
> you need to handle creation, destruction, repaint, resize, map/unmap as the
> basics then there's keyboard and mouse input events. And none of this has
> anything to do with GUIs, its basic window system programming whether its
> Windows, X11 or MacOS.
>
> It ain't simple.

The user interface is what's simple, not necessarily the library,
although that should be kept small and simple as much as possible (I
realise I'm posting in a C++ group where that concept is unknown!).

It is necessary to know where to draw the line, otherwise your new
simple library will be be as comprehensive as all the rest.

This is where looking at libraries from the past can be useful. No, they
probably didn't handle resizing, but they still got things done!

(For that matter, smartphone apps tend not do resizing either; they
mostly run full-screen, one app at a time, just like those old machines.)

You obviously have a need for all the bells and whistle of a modern,
colossal library, so this wouldn't be for you. Some of us just want the
next step beyond a text console, which is only slightly more advanced
than a 1970s VDU, itself not much more capable than a paper teletype.

>> one option is to plot into an image array, write to a format like PPM,
>> and use an external tool to display. Which is not as handy as directly
>
> Ugh. Who would bother?

You'd bother if creating higher res images than your display. But if
doing vector-based drawing, or generating text, then you'd still need a
library to go with it. For pixel-at-a-time rendering, it is viable.

> Perhaps not, but good luck having multiple programs open and visible at the same
> time on that terminal in 24bit alpha blended colour with overlapping windows.
> Nostalgia is lovely, but when you actually go back and use the old equipment -
> I've got some old gear at home too including various 8 bit machines - you
> realise just how rubbish it is compared to modern machines.
>

I'm not suggesting using old equipment, with low-res and low-bit depths.
Just the simple interfaces that we used to have.

A current PC will have 24-bit colour (what I was playing with in mid-80s
actually), as much resolution as you want, and the overlapping Windows
are handled by the OS. But the raw OS API is very unfriendly, so you
wouldn't want to use it directly.

[Chris M. Thomasson]

On 6/23/2020 4:26 AM, Juha Nieminen wrote:
> Bo Persson <b...@bo-persson.se> wrote:
>>> But that's actually a side rant. The main problem is not the variety and
>>> poor quality of such libraries. It's the fact that there are so many,
>>> and that they do not follow any standard.
>>>
>>
>> One standard to rule them all?
>>
>> https://xkcd.com/927/
>
> It's not so much about following a particular standard, but to have a way
> of doing it in a way that Will Just Compile as-is in any system with a
> new-enough compiler, without requiring any third-party libraries (which,
> as said, might be a real PitA to compile/integrate).

Humm... That does sound fairly attractive in a sense.

[Juha Nieminen]

Öö Tiib <oot...@hot.ee> wrote:
> Just compiling and running short snippet locally is not the reason
> why we program. The ridiculously complicated build systems come
> from what we actually need.
>
> We need to compile (and cross-compile) programs with different
> compilers for different platforms under different options; part
> of it involves installing dependencies, part of it accessing
> repositories, some part of it is about creating deployable
> packages, some part is about deploying and executing something
> automatically and some part of it is about generating reports
> of any aspect of it.

Problem is, what happens when you need to compile the library for
a system or in a manner that's not supported by the configure script?

As mentioned before, my personal experience is trying to compile
libraries to be used in an iOS project. Configure scripts are
beyond useless for that. What's worse, since the library source
code usually heavily relies on the "config.h", Makefile, or
whatever files created by the configure script, and cannot be
compiled without them, it usually makes it extraordinarily
difficult to compile the library for iOS.

That's most aggravating in the case of libraries that do nothing
that requires platform-specific stuff and can be implemented in
100% standard C or C++ (eg. many number-crunching libraries operating
on native integer or floating point types for which you can find
perfectly good definitions in the standard library headers).

So it's one thing that the configure script is uselss for this.
It becomes worse when the configure script is pretty much
*mandatory* to compile the library.

Configure scripts usually seem to assume that you are compiling for the
current host system. When compiling for iOS that's not the case. You don't
compile the project *in* iOS. You compile it in macOS. Detecting the
stuff in macOS is pretty useless for compiling for iOS.

It becomes even more complicated given the fact that if you are compiling
the library into eg. a statically linkable library file (ie .a file),
you usually want at least two versions of the binary inside the library
file: One for the iOS device and another for the iPhone simulator.
(This is a simulator, not an emulator. It does not run iOS native ARM
code. It runs an x86 version of your software. It requires compiling
the code for a completely different target, which is still not the
same as the hosting macOS system. The CPU is the same, but pretty
much nothing else is.)

Doing this is a bit complicated, and needless to say, configure
scripts have zero support for any of this.

[bol...@nowhere.co.uk]

On Tue, 23 Jun 2020 17:31:04 +0100
Bart <b...@freeuk.com> wrote:

>On 23/06/2020 15:42, bol...@nowhere.co.uk wrote:
>> Basic plotting is simple enough - once you've decided where to plot. Will it
>> be a Window? If so how big will it be, will it have a title, whats the
>> background colour, or will be be VGA graphics? And if you go with the window
>> you need to handle creation, destruction, repaint, resize, map/unmap as the
>> basics then there's keyboard and mouse input events. And none of this has
>> anything to do with GUIs, its basic window system programming whether its
>> Windows, X11 or MacOS.
>>
>> It ain't simple.
>
>The user interface is what's simple, not necessarily the library,
>although that should be kept small and simple as much as possible (I
>realise I'm posting in a C++ group where that concept is unknown!).

You've missed the point. Everything I mentioned you have to do BEFORE you even
worry about a user interface.

>It is necessary to know where to draw the line, otherwise your new
>simple library will be be as comprehensive as all the rest.

Yes, you draw it in a window. How big will that window be? Do you want it to
appear as soon as the library is loaded or do you want an explicit creation
command? Will it accept input or be output only etc etc etc. I think its fairly
clear you don't understand how windowing systems work but they're hardly
bleeding edge - this is stuff Xerox solved in the 70s.

>This is where looking at libraries from the past can be useful. No, they
>probably didn't handle resizing, but they still got things done!

Then they probably weren't window based libraries.

>(For that matter, smartphone apps tend not do resizing either; they
>mostly run full-screen, one app at a time, just like those old machines.)

Which is why they're shit for doing any useful work.

>You obviously have a need for all the bells and whistle of a modern,
>colossal library, so this wouldn't be for you. Some of us just want the
>next step beyond a text console, which is only slightly more advanced
>than a 1970s VDU, itself not much more capable than a paper teletype.

Nobody - apart from you - wants a standard C++ graphics library that does
nothing except draw graphics primitives into a fixed size output only window.

>> Ugh. Who would bother?
>
>You'd bother if creating higher res images than your display. But if

Use a pdf or postscript library then.

[Bart]

On 24/06/2020 11:52, bol...@nowhere.co.uk wrote:
> On Tue, 23 Jun 2020 17:31:04 +0100
> Bart <b...@freeuk.com> wrote:

>> It is necessary to know where to draw the line, otherwise your new
>> simple library will be be as comprehensive as all the rest.
>
> Yes, you draw it in a window. How big will that window be? Do you want it to
> appear as soon as the library is loaded or do you want an explicit creation
> command? Will it accept input or be output only etc etc etc. I think its fairly
> clear you don't understand how windowing systems work but they're hardly
> bleeding edge - this is stuff Xerox solved in the 70s.

Hardly anyone among the general public used anything like that. Apart
from toy home computers, that didn't happen until they started using
Windows, and particularly Win95.

My job for about 15 years was creating graphics apps, starting on PCs in
the mid-80s which had very little graphics support (so I had to provide
drivers and libraries). The apps were full-screen mode - there was no
inter-process windowing. Actually there weren't any other processes,
only yours.

>> This is where looking at libraries from the past can be useful. No, they
>> probably didn't handle resizing, but they still got things done!
>
> Then they probably weren't window based libraries.

They would have had one implicit window covering the whole screen. Ever
used a Tektronix terminal? They didn't have windows either! Such things
were still considered a highly useful alternate to using a text display.

You seem to think that there only two possibilities - either a
1960s-style text display at one end, and a full blown 2020s windowing
GUI system at the other. Nothing in the middle.

BTW consider a program line like this which writes into an windowed
console/terminal window on a GUI graphics display:

printf("Hello, World!\n");

Tell where in that code you specify which window you you write to, how
big the window is, and how it handles resizing or overlaps. Oh, you don't?

Now imagine you had this line:

setpixel(124, 456, 0xFF00FF);

Do you get it now?

>> You'd bother if creating higher res images than your display. But if
>
> Use a pdf or postscript library then.

And how big will those be, how complex, and how standard? The script
below draws a solid, outlined circle into a giant bitmap. The functions
used are thin-ish wrappers around WinAPI, and using 1990s GDI (though
using dynamic code).

w:=gxcreatewindow()

bm:=bmcreate(24,16384,16384) # create in-memory image
gxclear(bm, getrgb(white)) # clear to white

r:=bm.dimx%2-10
gxfillcircle(bm,r,r,r,getrgb(green),1)

bmsave("circle.bmp",bm)

gxcopy(w,bm,scalex:0.01) # display copy at 1% scale

eventloop()

(Jpeg o/p had a problem. The bmp output is 800MB.)

[bol...@nowhere.co.uk]

On Wed, 24 Jun 2020 12:47:33 +0100
Bart <b...@freeuk.com> wrote:
>My job for about 15 years was creating graphics apps, starting on PCs in
>the mid-80s which had very little graphics support (so I had to provide
>drivers and libraries). The apps were full-screen mode - there was no
>inter-process windowing. Actually there weren't any other processes,
>only yours.

Its not the mid-80s anymore.

>>> This is where looking at libraries from the past can be useful. No, they
>>> probably didn't handle resizing, but they still got things done!
>>
>> Then they probably weren't window based libraries.
>
>They would have had one implicit window covering the whole screen. Ever
>used a Tektronix terminal? They didn't have windows either! Such things
>were still considered a highly useful alternate to using a text display.

Great, but its not the mid-80s anymore. If you want to do graphics then every
consumer OS requires you to deal with windows when doing graphics whether you
like it or not. The only exception is doing VGA graphics in a linux console
or running a raw X server with no window manager but they're both frankly of
little use in this day and age.

>You seem to think that there only two possibilities - either a
>1960s-style text display at one end, and a full blown 2020s windowing
>GUI system at the other. Nothing in the middle.

Windowing != GUI, at least not with Xwin.

>BTW consider a program line like this which writes into an windowed
>console/terminal window on a GUI graphics display:
>
> printf("Hello, World!\n");
>
>Tell where in that code you specify which window you you write to, how
>big the window is, and how it handles resizing or overlaps. Oh, you don't?

Thats because - on unix at least - stdout writes to the tty which may or may
not be linked to a virtual or physical terminal. Normally that terminal will
be the one you run the program from within but it doesn't have to be the case.

>Now imagine you had this line:
>
> setpixel(124, 456, 0xFF00FF);
>
>Do you get it now?

And where does it writes to? Are you going to implement a shell inside your
graphical window in order to kick it off? You might wish that we were still
in the past with a single output destination but consumer OS's are not like
that. But feel free to play about with some embedded kit like Micromite that
support bitmap displays out the box but don't expect any sane person to suggest
adding in your mickey mouse API to the C++ standard.

>>> You'd bother if creating higher res images than your display. But if
>>
>> Use a pdf or postscript library then.
>
>And how big will those be, how complex, and how standard? The script

Umm, pdf has been a standard interchange format for a very long time.
Postscript seems to be fading away a bit.

>below draws a solid, outlined circle into a giant bitmap. The functions
>used are thin-ish wrappers around WinAPI, and using 1990s GDI (though
>using dynamic code).

You're stuck in the past. Time for you to catch the clue train back to 2020.

[Öö Tiib]

On Wednesday, 24 June 2020 09:40:01 UTC+3, Juha Nieminen wrote:
> Öö Tiib <oot...@hot.ee> wrote:
> > Just compiling and running short snippet locally is not the reason
> > why we program. The ridiculously complicated build systems come
> > from what we actually need.
> >
> > We need to compile (and cross-compile) programs with different
> > compilers for different platforms under different options; part
> > of it involves installing dependencies, part of it accessing
> > repositories, some part of it is about creating deployable
> > packages, some part is about deploying and executing something
> > automatically and some part of it is about generating reports
> > of any aspect of it.
>
> Problem is, what happens when you need to compile the library for
> a system or in a manner that's not supported by the configure script?

Then I dump that script. I have to invest all man-hours that it
takes to make build system for the library that suits my needs. That is
why it is bad that exactly nothing of it is standardized. I likely
have to make everything from scratch. Autotools configure script
is good example of painful and useless tool in situation for what
it wasn't meant.

[Bart]

On 24/06/2020 15:47, bol...@nowhere.co.uk wrote:
> On Wed, 24 Jun 2020 12:47:33 +0100
> Bart <b...@freeuk.com> wrote:
>> My job for about 15 years was creating graphics apps, starting on PCs in
>> the mid-80s which had very little graphics support (so I had to provide
>> drivers and libraries). The apps were full-screen mode - there was no
>> inter-process windowing. Actually there weren't any other processes,
>> only yours.
>
> Its not the mid-80s anymore.

So? What worked then /within an application/ will still work now within
an application.

> Great, but its not the mid-80s anymore. If you want to do graphics then every
> consumer OS requires you to deal with windows when doing graphics whether you
> like it or not.

And you still don't get it. in the same way that you can just print text
to a console without worrying about windowing or multiple consoles for
fonts or anything like that, you can do low-level graphics.

This is an extract from Stroutrup's paper listing future directions:

* "Support for simple graphics and simple user interaction"

That doesn't sound like GTK or WxWidgets to me. Neither does it sound
like using rendering libraries like Cairo or using PS/EPS/PDF.

The only exception is doing VGA graphics in a linux console
> or running a raw X server with no window manager but they're both frankly of
> little use in this day and age.

If such a thing can plot a pixel of a particular colour, then it has
everything needed to do graphics. (In theory; in practice it'll be too
slow for most things, and you will need to build a higher level library.)

>> Tell where in that code you specify which window you you write to, how
>> big the window is, and how it handles resizing or overlaps. Oh, you don't?
>
> Thats because - on unix at least - stdout writes to the tty which may or may
> not be linked to a virtual or physical terminal. Normally that terminal will
> be the one you run the program from within but it doesn't have to be the case.

Fine, do the graphics via text escapes; it doesn't really matter. (I
used to develop graphics boards, and at least one was driven via a
serial interface.)

>> Now imagine you had this line:
>>
>> setpixel(124, 456, 0xFF00FF);
>>
>> Do you get it now?
>
> And where does it writes to? Are you going to implement a shell inside your
> graphical window in order to kick it off? You might wish that we were still
> in the past with a single output destination but consumer OS's are not like
> that.

Windows at least lets you have a handle to the current console such that
you can draw pixel graphics into it. You get results like this:
https://github.com/sal55/langs/blob/master/console.png

But I'd recommend creating a separate window. That that can become the
default for pixel-based output.

(I'd say that was a concession to the 2020s, but the first graphics
hardware I build 40 years also had separate circuits for text and pixel
graphics, in that case with a discrete switch; I can't remember if one
could be overlaid on the other. There was only one monitor anyway. That
system was used for 3D graphics and image capturing and processing - on
8-bit hardware.)

The idea is to keep it simple, yes? And also something that is
guaranteed to be available.

> Umm, pdf has been a standard interchange format for a very long time.
> Postscript seems to be fading away a bit.

PDF seems to be a development of encapsulated Postscript. I wrote CAD
applications where a variety of such things were rendering targets (and
NeXT showed that PS could be used for interaction). But I think a
dedicated screen library, with the possibility of capturing drawing
commands, would be better.

>> below draws a solid, outlined circle into a giant bitmap. The functions
>> used are thin-ish wrappers around WinAPI, and using 1990s GDI (though
>> using dynamic code).
>
> You're stuck in the past. Time for you to catch the clue train back to 2020.

Not me. Clearly you and plenty of others want things to remain
complicated (maybe you get better paid that way, I don't know), with
myriad choices of graphics libraries each more elaborate than the next.

I like looking to the past because things that were a piece of cake back
then are now a bleeding nightmare, so lessons can be learnt. Yes, things
are bit more complex now, but maybe 1 magnitude more complex not several
magnitudes.

[Paavo Helde]

23.06.2020 09:23 Juha Nieminen kirjutas:
>
> Currently there are like nine billion GUI/graphical libraries out there,
> none of which follow *any* kind of standard (because there is no standard).

There is a widespread standard for graphical layout and basic user
interaction which is supported by most platforms having graphics (and
even by some without). It's called HTML.

[bol...@nowhere.co.uk]

On Wed, 24 Jun 2020 17:47:30 +0100
Bart <b...@freeuk.com> wrote:
>On 24/06/2020 15:47, bol...@nowhere.co.uk wrote:
>> Great, but its not the mid-80s anymore. If you want to do graphics then every
>
>> consumer OS requires you to deal with windows when doing graphics whether you
>
>> like it or not.
>
>And you still don't get it. in the same way that you can just print text
>to a console without worrying about windowing or multiple consoles for
>fonts or anything like that, you can do low-level graphics.

Not on unix you can't. TTYs are text only. End of.

>This is an extract from Stroutrup's paper listing future directions:
>
>* "Support for simple graphics and simple user interaction"
>
>That doesn't sound like GTK or WxWidgets to me. Neither does it sound
>like using rendering libraries like Cairo or using PS/EPS/PDF.

Perhaps he'd had a few too many drinks when he wrote that as I have no idea
what he's thinking. Clearly he's spent too long with compilers and doesn't
understand how modern graphics systems work. C++ doesn't even support ANSI
text graphics natively and that WOULD be easy and portable.

> The only exception is doing VGA graphics in a linux console
>> or running a raw X server with no window manager but they're both frankly of
>> little use in this day and age.
>
>If such a thing can plot a pixel of a particular colour, then it has
>everything needed to do graphics. (In theory; in practice it'll be too

Sure , at the price of not allowing any other graphically based application
to run at the time including terminals and interactive debuggers. I'm sure
that would be a popular.

>> Thats because - on unix at least - stdout writes to the tty which may or may
>> not be linked to a virtual or physical terminal. Normally that terminal will
>> be the one you run the program from within but it doesn't have to be the
>case.
>
>Fine, do the graphics via text escapes; it doesn't really matter. (I
>used to develop graphics boards, and at least one was driven via a
>serial interface.)

Some old terminals used to do something just like that. But you still have the
issue of where the output goes.

>Windows at least lets you have a handle to the current console such that
>you can draw pixel graphics into it. You get results like this:
>https://github.com/sal55/langs/blob/master/console.png

So what? Its non portable. If you only care about windows graphics use a
Windows API, don't expect it to be put in the core language.

>But I'd recommend creating a separate window. That that can become the
>default for pixel-based output.

Presumably output only and a fixed size which can't be changed which for
backwards compatibility would have to be a maximum of 640x400 with 256 colours.

>hardware I build 40 years also had separate circuits for text and pixel

So did most PC graphics cards back in the 80s and 90s.

>> You're stuck in the past. Time for you to catch the clue train back to 2020.
>
>Not me. Clearly you and plenty of others want things to remain
>complicated (maybe you get better paid that way, I don't know), with
>myriad choices of graphics libraries each more elaborate than the next.

Its not a case of wanting things to be complicated, its a case of things ARE
complicated because consumer computers are multiprocess multiwindow machines
and applications have to play nice with each other. MS tried the 1 program
gets the whole display smartphone approach with Windows 8 and look how
popular that turned out to be.

[Manfred]

Probably one more reason to *not* put this kind of thing into the language.
However common, graphics does not belong to C++ as a language, IMHO.
It is primarily a matter of application libraries, that may well aim to
be cross-platform and at some level of standardization, still at a
different level than the language.

C++ works around a CPU model. Nowadays' GPU architectures are
substantially different from CPUs, and I don't see for them a converging
path either, rather the opposite looks much more likely.
From a different perspective, C++ as a language is designed at the
level of the process model. GUIs are designed as human interface models;
that's a different level.

If and when some agreement on GUI standardization will become realistic
(I think we are quite far from that), it might be that a dedicated
language could find its use. I understand GLSL is an attempt in this
direction - I have no idea how successful; it is a fact that some major
corporations try to push their solutions in this area - things like
Android and XAML clearly diverge from the C++ model.

[Bart]

HTML is more like a rendering target. It itself is a markup language
which has to be rendered into a graphical display. And even that is not
powerful enough by itself, it needs extras to get the needed
functionality (eg. embedded Javascript).

How would you draw a circle from within C++ (not just C++, this debate
is common to most such languages)? How do you then get user input (eg.
user clicks within the circle or outside it)?

Actually, forget graphics; is there even a standard way to detect
whether a key has been pressed, and which one?

This stuff used to be tricky on 70s mainframe computers, then the
informal microcomputer came along, and it became child's play. Now it
has long been difficult again.

[Paavo Helde]

25.06.2020 17:44 Bart kirjutas:
> On 25/06/2020 09:23, Paavo Helde wrote:
>> 23.06.2020 09:23 Juha Nieminen kirjutas:
>>>
>>> Currently there are like nine billion GUI/graphical libraries out there,
>>> none of which follow *any* kind of standard (because there is no
>>> standard).
>>
>> There is a widespread standard for graphical layout and basic user
>> interaction which is supported by most platforms having graphics (and
>> even by some without). It's called HTML.
>>
>
> HTML is more like a rendering target. It itself is a markup language
> which has to be rendered into a graphical display.

Rendering would be done by the web browser. For most C++ newbies it
would be easier to launch a browser than to launch a command line
interpreter.

> And even that is not
> powerful enough by itself, it needs extras to get the needed
> functionality (eg. embedded Javascript).

Isn't there something called WASM which can be programmed in C++? Also,
Javascript could be emitted from a C++ library as easily as HTML.

>
> How would you draw a circle from within C++ (not just C++, this debate
> is common to most such languages)? How do you then get user input (eg.
> user clicks within the circle or outside it)?

There would be a more or less specialized widget outputting:

<svg OnClick="..."><circle .../></svg>

OnClick would pass the click coordinates back to the C++ program which
would do whatever it wants with these numbers.

>
> Actually, forget graphics; is there even a standard way to detect
> whether a key has been pressed, and which one?

There are standard ways with JavaScript and I presume with WASM. I
gather they are a bit inconsistent across browsers, but this could be
leveraged by the C++ side support library, similar to how
std::filesystem leverages OS differences.

>
> This stuff used to be tricky on 70s mainframe computers, then the
> informal microcomputer came along, and it became child's play. Now it
> has long been difficult again.

It's not difficult but platform-specific. And with DOS it was extremely
platform-specific.

[Juha Nieminen]

I think that HTML is really off the mark here. A much more apt example
would have been, for example, OpenGL, which is exactly the kind of
standard I'm talking about. (Maybe I should have specified in my
post more specifically that I'm talking about an API standard, rather
than something else). Indeed, OpenGL is a very well-established and
very widely used standard, supported by almost all platfors that can
display 3D graphics.

Of course in this case OpenGL would not be the answer to the problem
because OpenGL is not a GUI API standard, but a 3D rendering API
standard, so it can't really be used to present a (native) GUI to
the user. (Also, OpenGL lacks many drawing utilities that would be
useful for the average user, like vector graphics, pixel graphics
etc.)

There are lots of GUI libraries out there, like tk, wxwidgets, gtk
and so on and so forth, but they all do their own unique thing when
it comes to their API, and do not follow any standard, because there
is no universal standard API for GUIs.

I suppose that the reason why I'm talking about GUI API standards here
is that if in C++ you would want to write and distribute a GUI'd program,
you would inevitably be tying it to one particular GUI library, which
cannot be replaced by another.

This is unlike most of the C++ standard library: If you write a program to
use the C++ standard library it doesn't really matter what the actual
library implementation is. It could be libc++, libstdc++, or any other.
The API is standardized, so it doesn't matter.

I don't know if this would be feasible with a GUI library, but at least
if one existed, it would make it much easier for people (especially
beginners) to just display graphics on screen with minimal effort.

Something that I myself would like a lot. I really hate the fact that
it's extraordinarily laborious to set up a system where I can easily
draw something on screen, using C++.

[bol...@nowhere.co.uk]

On Thu, 25 Jun 2020 19:02:50 +0300
Paavo Helde <ees...@osa.pri.ee> wrote:
>25.06.2020 17:44 Bart kirjutas:
>> On 25/06/2020 09:23, Paavo Helde wrote:
>>> 23.06.2020 09:23 Juha Nieminen kirjutas:
>>>>
>>>> Currently there are like nine billion GUI/graphical libraries out there,
>>>> none of which follow *any* kind of standard (because there is no
>>>> standard).
>>>
>>> There is a widespread standard for graphical layout and basic user
>>> interaction which is supported by most platforms having graphics (and
>>> even by some without). It's called HTML.
>>>
>>
>> HTML is more like a rendering target. It itself is a markup language
>> which has to be rendered into a graphical display.
>
>Rendering would be done by the web browser. For most C++ newbies it
>would be easier to launch a browser than to launch a command line
>interpreter.

If someone finds using a command line to hard then they've got no chance
learning C++.

[Alf P. Steinbach]

On 26.06.2020 12:27, Juha Nieminen wrote:
> Paavo Helde <ees...@osa.pri.ee> wrote:
>> 23.06.2020 09:23 Juha Nieminen kirjutas:
>>> Currently there are like nine billion GUI/graphical libraries out there,
>>> none of which follow *any* kind of standard (because there is no standard).
>>
>> There is a widespread standard for graphical layout and basic user
>> interaction which is supported by most platforms having graphics (and
>> even by some without). It's called HTML.
>
> I think that HTML is really off the mark here.

A bit off the mark, but there are at least 2 C++ GUI libraries with the
front end in HTML+CSS+JavaScript.

> A much more apt example
> would have been, for example, OpenGL, which is exactly the kind of
> standard I'm talking about. (Maybe I should have specified in my
> post more specifically that I'm talking about an API standard, rather
> than something else). Indeed, OpenGL is a very well-established and
> very widely used standard, supported by almost all platfors that can
> display 3D graphics.
>
> Of course in this case OpenGL would not be the answer to the problem
> because OpenGL is not a GUI API standard, but a 3D rendering API
> standard, so it can't really be used to present a (native) GUI to
> the user. (Also, OpenGL lacks many drawing utilities that would be
> useful for the average user, like vector graphics, pixel graphics
> etc.)

The colors don't work in Microsoft's OpenGL example in Windows 10.

I think that means that nobody now uses OpenGL for anything serious on
the Windows platform.

> There are lots of GUI libraries out there, like tk, wxwidgets, gtk
> and so on and so forth, but they all do their own unique thing when
> it comes to their API, and do not follow any standard, because there
> is no universal standard API for GUIs.
>
> I suppose that the reason why I'm talking about GUI API standards here
> is that if in C++ you would want to write and distribute a GUI'd program,
> you would inevitably be tying it to one particular GUI library, which
> cannot be replaced by another.
>
> This is unlike most of the C++ standard library: If you write a program to
> use the C++ standard library it doesn't really matter what the actual
> library implementation is. It could be libc++, libstdc++, or any other.
> The API is standardized, so it doesn't matter.
>
> I don't know if this would be feasible with a GUI library, but at least
> if one existed, it would make it much easier for people (especially
> beginners) to just display graphics on screen with minimal effort.

Herb Sutter started a proposal for a standard 2D graphics library based
on the Cairo library.

As far as I know that proposal fizzled out, no current work.

> Something that I myself would like a lot. I really hate the fact that
> it's extraordinarily laborious to set up a system where I can easily
> draw something on screen, using C++.

Yeah. It's especially a problem for educators. Dynamic graphics is
highly motivating, and not having graphics is demotivating.

But then, C doesn't have a standard graphics library, and neither does
Ada. Even Rust doesn't have that. But maybe C++ can take some direction
from Rust.

<url: https://wiki.alopex.li/AGuideToRustGraphicsLibraries2019>


- Alf

[Manfred]

I don't understand what you mean here, OpenGL is perfectly capable of
doing vector graphics etc.
Along the lines of your comment, one may however note that the
complexity of using OpenGL is not parameterized to the complexity of the
graphics operation: doing vector or pixel graphics is just as complex as
advanced 3D rendering. In this sense it is not much beginner-friendly.
It is true that its target is not GUIs indeed - even drawing text is
pretty intricate.

>
> The colors don't work in Microsoft's OpenGL example in Windows 10.
>
> I think that means that nobody now uses OpenGL for anything serious on
> the Windows platform.
>
>

I don't think so.
Windows' native support for OpenGL is minimal at best (I think it is
still at version 1.1, so to use more recent versions some extra legwork
is needed - however version 1.1 is sufficient for most standard 3D
rendering), and the documentation is poor, so I am not really surprised
that some example doesn't work.
However, it is a distinctive mark of OpenGL that the implementation does
not come with the OS, it comes from the graphics vendor instead, and
using its features does not really require much from the OS vendor.

In accordance with their policy of hindering what is "Not Invented
Here", they promote DirectX instead. This doesn't mean that OpenGL does
not work on Windows, especially since virtually all graphics vendors
have been supporting it for a long time already.

[Juha Nieminen]

Manfred <non...@add.invalid> wrote:
> I don't understand what you mean here, OpenGL is perfectly capable of
> doing vector graphics etc.

No, it's not. It can only render triangles and 1-pixel-width
non-antialiased lines and pixels. That's it. Has absolutely
no support for anything else.

[Bart]

That's what many think of as vector graphics. After all you pass it the
endpoints of a vector, not the intervening pixels. And it can do
antialiased lines of sorts.

But no it doesn't have the sort of control you can get with PostScript,
a 2D renderer designed for documents and illustrations, with lines of
any thickness and control over corners and endpoints.

OpenGL also supports texture mapping (this is from my nearly 20-year-old
knowledge so it's probably moved on).

[Juha Nieminen]

Bart <b...@freeuk.com> wrote:
> On 26/06/2020 17:36, Juha Nieminen wrote:
>> Manfred <non...@add.invalid> wrote:
>>> I don't understand what you mean here, OpenGL is perfectly capable of
>>> doing vector graphics etc.
>>
>> No, it's not. It can only render triangles and 1-pixel-width
>> non-antialiased lines and pixels. That's it. Has absolutely
>> no support for anything else.
>
> That's what many think of as vector graphics. After all you pass it the
> endpoints of a vector, not the intervening pixels. And it can do
> antialiased lines of sorts.

Generally "vector graphics" refers to drawing pictures using
drawing elements like lines, curves, ellipses, splines and so on
and so forth, and most often this supports defining line thickness,
color, fill color, fill pattern, and oftentimes all kinds of
effects. Most usually high-quality antialiasing is supported to
avoid a pixelated look. It is what, for example, the SVG file format
is all about.

See https://en.wikipedia.org/wiki/Vector_graphics

Even at its simplest a "vector graphics" library ought to support
at least a few primitivies, like lines, circles, rectangles, etc.

[Manfred]

There is a fundamental difference between a data format like SVG or PS
and a rendering API like OpenGL that is deliberately kept close to the
hardware.
The former provides higher level primitives to ease the job of the
content provider. Runtime performance is of secondary concern.
The latter aims at maximum performance by providing as direct as
possible access to hardware functions.

It could certainly be possible to make GPU boards that render SVG
directly, but this kind of trajectory would clash with the differences
between the hardware development cycle and standards evolution.

I'll admit that I am not up to date with the latest standards, however
curves and splines are supported by the earlier versions of OpenGL
(still available on all implementations) as part of the utility library,
that substantially converts them into step-linear paths. Antialiasing is
also part of the OpenGL API as a /hint/, which means that
implementations are free to ignore it, but this is a problem of QoI
rather than of OpenGL itself.

What I find more meaningful is that one fundamental power of vector
graphics is that it can perform exact and efficient vector
*transformations* like scaling, rotations, gradients and textures - all
of this (and much more) has been part of OpenGL since day one.