Standard C++ GUI Library Proposal

[Mr Flibble]

There isn't one and there never should be: we have neoGFX for that! :D

/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."

[Lynn McGuire]

On 6/23/2020 11:46 AM, Mr Flibble wrote:
> There isn't one and there never should be: we have neoGFX for that! :D
>
> /Flibble

At the moment, I am being recommended to use:

1. GTK https://www.gtk.org/

2. wxwidgets https://www.wxwidgets.org/

Lynn

[Lynn McGuire]

On 6/23/2020 11:46 AM, Mr Flibble wrote:

> There isn't one and there never should be: we have neoGFX for that! :D
>
> /Flibble

And there is Tk:
https://www.tcl.tk/

Lynn

[Sam]

Mr Flibble writes:

> There isn't one and there never should be: we have neoGFX for that! :D

Proposals for GUI libraries are accepted only from those who have actually
written one.

[Mr Flibble]

I have written one, dear.

[Sam]

Mr Flibble writes:

> On 24/06/2020 12:05, Sam wrote:
>> Mr Flibble writes:
>>
>>> There isn't one and there never should be: we have neoGFX for that! :D
>>
>> Proposals for GUI libraries are accepted only from those who have actually
>> written one.
>
> I have written one, dear.

Do you have a Youtube video, that shows it off? Where's the source
repository, I'm curious to look at it, to see if I can pick up some tips,
for mine's.

[Alf P. Steinbach]

I guess you can find Leigh's neoGFX easily just by googling it.

Like him I've written a number of GUI libraries, but they've been
minimal. In the 1990's I found it interesting to experiment with various
ways to associate a Windows window with C++ object. In particular the
trick used in Borland's framework, namely a /trampoline function/: a
kind of pseudo function (as "window procedure") that just put an object
address in a register and jumped to a common dispatch function.

Later my interest for GUI framework design focused on providing the C++
initialization guarantee, that after constructor execution you have a
fully working usable object at hand, with class invariants established.

I.e., no MFC-style two-phase or multi-phase construction.

Nowadays Windows provides a standard window subclassing mechanism that
uses unspecified means internally, that's at bottom of the very thin
Windows API wrapper code that I'm currently developing and using for a
hobby project of mine. That hobby project is not public, but the so far
very minimal Windows API wrapper code is. Essentially this codes takes
care of the two issues mentioned above, namely associating a window with
a C++ object, and providing C++ construction, though destruction is
modeled as hara-kiri, plus, it works around various Windows bugs.

<url: https://github.com/alf-p-steinbach/winapi>.


- Alf

[Mr Flibble]

https://www.youtube.com/watch?v=KfHtoThyNkA
https://www.youtube.com/watch?v=WiHsFlyLuak
https://neogfx.org/
https://github.com/i42output/neogfx

[Manfred]

On 6/24/2020 5:44 PM, Alf P. Steinbach wrote:
> On 24.06.2020 16:38, Sam wrote:
>> Mr Flibble writes:
>>
>>> On 24/06/2020 12:05, Sam wrote:
>>>> Mr Flibble writes:
>>>>
>>>>> There isn't one and there never should be: we have neoGFX for that! :D
>>>>
>>>> Proposals for GUI libraries are accepted only from those who have
>>>> actually written one.
>>>
>>> I have written one, dear.
>>
>> Do you have a Youtube video, that shows it off? Where's the source
>> repository, I'm curious to look at it, to see if I can pick up some
>> tips, for mine's.
>
> I guess you can find Leigh's neoGFX easily just by googling it.
>
> Like him I've written a number of GUI libraries, but they've been
> minimal. In the 1990's I found it interesting to experiment with various
> ways to associate a Windows window with C++ object. In particular the
> trick used in Borland's framework, namely a /trampoline function/: a
> kind of pseudo function (as "window procedure") that just put an object
> address in a register and jumped to a common dispatch function.

I also seem to remember the peculiar Borland message handler:

virtual void onPaint() = WM_PAINT;

[Sam]

Alf P. Steinbach writes:

> On 24.06.2020 16:38, Sam wrote:
>> Mr Flibble writes:
>>
>>> On 24/06/2020 12:05, Sam wrote:
>>>> Mr Flibble writes:
>>>>
>>>>> There isn't one and there never should be: we have neoGFX for that! :D
>>>>
>>>> Proposals for GUI libraries are accepted only from those who have actually
>>>> written one.
>>>
>>> I have written one, dear.
>>
>> Do you have a Youtube video, that shows it off? Where's the source
>> repository, I'm curious to look at it, to see if I can pick up some tips,
>> for mine's.
>
> I guess you can find Leigh's neoGFX easily just by googling it.

Yeah, Windows-based library, oriented towards game development, from the
looks of it.

Mine, on the other hand, is an X11 widget stack, Linux only, classic widget
set.

> Like him I've written a number of GUI libraries, but they've been minimal.
> In the 1990's I found it interesting to experiment with various ways to
> associate a Windows window with C++ object. In particular the trick used in
> Borland's framework, namely a /trampoline function/: a kind of pseudo
> function (as "window procedure") that just put an object address in a
> register and jumped to a common dispatch function.

My driver was a desire to get up to speed and learn C++11. Thinking about
what I could possibly practice on: writing an X11 widget stack was appealing
for some reason. I also found that learning X was quite interesting. I
intentionally set up my development environment to tunnel X over ssh, over a
wireless connection. This makes implementation inefficiencies very obvious.

These days, my toolkit targets C++20, after the introduction of constraints,
and other C++20 features, into my library.

> Later my interest for GUI framework design focused on providing the C++
> initialization guarantee, that after constructor execution you have a fully
> working usable object at hand, with class invariants established.
>
> I.e., no MFC-style two-phase or multi-phase construction.

Not familiar with MFC's two-phase construction, so I might be talking about
something else; but I did find a need for two-phase construction, for certain
specific use cases, myself. My definition of two-phase construction was a
requirement to call a class method after constructing an instance, in order
to finish something.

I found a workable solution by having the framework take care of it, without
really having to explicitly invoke the 2nd phase. I don't have to call the
2nd phase constructor, every time, myself. All my widgets and other objects
gets constructed by templates, and the templates use SFINAE to determine
whether the constructed class instance has a second phase constructor; and
if so invoke it automatically. Objects with a second phase constructor end
up getting instantiated identically to regular objects, without having to
think about it. Completely exception safe.

> <url: https://github.com/alf-p-steinbach/winapi>.

https://www.libcxx.org/w/

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

On Wed, 24 Jun 2020 19:35:26 -0400
Sam <s...@email-scan.com> wrote:
>These days, my toolkit targets C++20, after the introduction of constraints,
>and other C++20 features, into my library.

If you want it to be used by a significant number of people thats probably
a bad idea. Most people and companies don't upgrade compilers all that often
and Clang (on the Mac anyway) still doesn't support C++ 20 fully - eg
co routines still don't work properly and the <=> isn't yet supported (which
seems odd given how trivial it should be to implement).

[Sam]

This is not something where there's a large existing code base that could
potentially come into play. One might argue that aiming for general
compatibility with existing toolkits is an advantage, but I would argue that
this offers very little value-added. What value-added would there be, in
porting an existing code base to a different, unproven stack, when ol'
reliable is where it is?

So, without worrying about compatibility, targetting the current C++
standard makes more sense to me. I just dropped all relative comparison
overloads, and replaced them with three-way comparison overload. Not a major
deal, but the end result is cleaner, and better.

Otherwise, you end up with a situation like Qt, which stays compatible with
older C++ standards, but is full of reinvented wheels, and macros.

On top of that, my library's packaging allows for concurrent installs of
multiple runtime versions. If it ever catches on, there won't be an issue
with versions. Master can continue, effectively, track the current standard,
while older versions continue to remain installed and linked with whatever
software is fixed on them.

[Sam]

Mr Flibble writes:

> On 24/06/2020 15:38, Sam wrote:
>> Mr Flibble writes:
>>
>>> On 24/06/2020 12:05, Sam wrote:
>>>> Mr Flibble writes:
>>>>
>>>>> There isn't one and there never should be: we have neoGFX for that! :D
>>>>
>>>> Proposals for GUI libraries are accepted only from those who have actually
>>>> written one.
>>>
>>> I have written one, dear.
>>
>> Do you have a Youtube video, that shows it off? Where's the source
>> repository, I'm curious to look at it, to see if I can pick up some tips,
>> for mine's.
>
> https://www.youtube.com/watch?v=KfHtoThyNkA

I chose to represent color channel values as their native 16 bit values, in
decimal or hexadecimal, the actual values used by the underlying X protocol;
three individual sliders for each color channel, and a pallette limited to
the standard HTML 3.2 colors:

https://www.youtube.com/watch?v=KfHtoThyNkA

This video is slightly old. The rendering is more optimized now, and there's
also an alpha channel there, as well.

> https://www.youtube.com/watch?v=WiHsFlyLuak

I already mentioned that I use an intentionally degraded environment, with X
tunneled over an ssh connection, over WiFi, to see any performance problems.

Anyway, what I was looking for was a demo of the individual widgets, similar
to what's shown here:

https://developer.gnome.org/gtk3/stable/ch03.html

I think that some Gtk widgets are quite ugly. Look at Gtk's panes. A bunch
of flat squares. Three lonely dots separating them. That's the visual cue
for dragging the panes? Compare:

https://www.libcxx.org/w/panelayoutmanager.html

Perhaps the ugliest one, IMO, is Gtk's notebook. For the longest time I
thought that firewall-config had a bug with its tabs, where I couldn't get
to the last ones. It was not obvious at all how to scroll the tabs. And the
currently active tab is identified ...by a line under its name. Really?

Is it really too hard to show obvious scroll buttons, so that when the number
of tabs exceeds their allotted width, it's obvious how to scroll them?

https://www.libcxx.org/w/booklayoutmanager.html

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

On Thu, 25 Jun 2020 07:12:03 -0400
Sam <s...@email-scan.com> wrote:
>So, without worrying about compatibility, targetting the current C++
>standard makes more sense to me. I just dropped all relative comparison
>overloads, and replaced them with three-way comparison overload. Not a major
>deal, but the end result is cleaner, and better.

Very noble, just don't expect it to get much traction anytime soon, thats all.

[Mr Flibble]

On 25/06/2020 00:35, Sam wrote:
> Alf P. Steinbach writes:
>
>> On 24.06.2020 16:38, Sam wrote:
>>> Mr Flibble writes:
>>>
>>>> On 24/06/2020 12:05, Sam wrote:
>>>>> Mr Flibble writes:
>>>>>
>>>>>> There isn't one and there never should be: we have neoGFX for that! :D
>>>>>
>>>>> Proposals for GUI libraries are accepted only from those who have actually written one.
>>>>
>>>> I have written one, dear.
>>>
>>> Do you have a Youtube video, that shows it off? Where's the source repository, I'm curious to look at it, to see if I can pick up some tips, for mine's.
>>
>> I guess you can find Leigh's neoGFX easily just by googling it.
>
> Yeah, Windows-based library, oriented towards game development, from the looks of it.

neoGFX will be cross platform and can be used to create both apps and games.

[Mr Flibble]

On 25/06/2020 12:38, Sam wrote:
> Mr Flibble writes:
>
>> On 24/06/2020 15:38, Sam wrote:
>>> Mr Flibble writes:
>>>
>>>> On 24/06/2020 12:05, Sam wrote:
>>>>> Mr Flibble writes:
>>>>>
>>>>>> There isn't one and there never should be: we have neoGFX for that! :D
>>>>>
>>>>> Proposals for GUI libraries are accepted only from those who have actually written one.
>>>>
>>>> I have written one, dear.
>>>
>>> Do you have a Youtube video, that shows it off? Where's the source repository, I'm curious to look at it, to see if I can pick up some tips, for mine's.
>>
>> https://www.youtube.com/watch?v=KfHtoThyNkA
>
> I chose to represent color channel values as their native 16 bit values, in decimal or hexadecimal, the actual values used by the underlying X protocol; three individual sliders for each color channel, and a pallette limited to the standard HTML 3.2 colors:
>
> https://www.youtube.com/watch?v=KfHtoThyNkA
>
> This video is slightly old. The rendering is more optimized now, and there's also an alpha channel there, as well.

Eh? That is my video not yours.

/Flibble

[Sam]

That's ok, I'm never tried to win any popularity contests. I think I
mentioned that I had other reasons to engage in this endeavour; which I
found to be very valuable. If others can benefit too, it's just a plus, but
is not an exclusive goal.

[Sam]

Mr Flibble writes:

> On 25/06/2020 12:38, Sam wrote:
>> Mr Flibble writes:
>>
>>> On 24/06/2020 15:38, Sam wrote:
>>>> Mr Flibble writes:
>>>>
>>>>> On 24/06/2020 12:05, Sam wrote:
>>>>>> Mr Flibble writes:
>>>>>>
>>>>>>> There isn't one and there never should be: we have neoGFX for that! :D
>>>>>>
>>>>>> Proposals for GUI libraries are accepted only from those who have actually
>>>>>> written one.
>>>>>
>>>>> I have written one, dear.
>>>>
>>>> Do you have a Youtube video, that shows it off? Where's the source
>>>> repository, I'm curious to look at it, to see if I can pick up some tips,
>>>> for mine's.
>>>
>>> https://www.youtube.com/watch?v=KfHtoThyNkA
>>
>> I chose to represent color channel values as their native 16 bit values, in
>> decimal or hexadecimal, the actual values used by the underlying X protocol;
>> three individual sliders for each color channel, and a pallette limited to
>> the standard HTML 3.2 colors:
>>
>> https://www.youtube.com/watch?v=KfHtoThyNkA
>>
>> This video is slightly old. The rendering is more optimized now, and there's
>> also an alpha channel there, as well.
>
> Eh? That is my video not yours.

Another Firefox fail. Up until Firefox 72, clicking on the address bar
highlighted the URL and copied it to the clipboard. So I have muscle memory
for copy/pasting URLs: open in Firefox, click on the address bar to copy the
URL, click in the other window to paste in.

No, Mozilla, for some reason, decided to "animate" their address bar. End
result: clicking on the address bar still highlights the URL as before,
(now, with animation!), but doesn't copy it to the clipboard. Not the first
time this fail happened.

Anyway, here's the URL I meant to paste, there.

https://www.libcxx.org/w/fontcolorpickers.html

[Alessandro Volturno]

Il 23/06/20 18:46, Mr Flibble ha scritto:

> There isn't one and there never should be: we have neoGFX for that! :D
>
> /Flibble
>

I think adding standardized drawings and GUI facilities could be a major
benefit for the widespread of C++.

Console programs are now widely superseded by graphical UI (this
obviously doesn't mean CLI programs are not still used) and the last
standard editions of C++ added to it many advanced mathematical
features. It would be very useful, in my opinion, to offer the
programmer a unique, standard way to handle the screen and to permit a
uniform representation of these features graphically.

Someone opposes to these arguments performance issues, others that there
are many alternatives both proprietary and open sources. True, but,
personally, I believe that enriching a programming language, making it
more competitive and powerful, could be a big advantage for the language
itself.

Obviously using std facilities are not mandatory, but we can rely on the
advantages of standardized features.

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

On Fri, 26 Jun 2020 11:40:32 +0200
Alessandro Volturno <ale...@inwind.it> wrote:
>Il 23/06/20 18:46, Mr Flibble ha scritto:
>> There isn't one and there never should be: we have neoGFX for that! :D
>>
>> /Flibble
>>
>
>I think adding standardized drawings and GUI facilities could be a major
>benefit for the widespread of C++.

Jave has a standard GUI built in to the JVM but it ended up being lowest common
denominator and everyone hated it.

>Console programs are now widely superseded by graphical UI (this
>obviously doesn't mean CLI programs are not still used) and the last
>standard editions of C++ added to it many advanced mathematical
>features. It would be very useful, in my opinion, to offer the
>programmer a unique, standard way to handle the screen and to permit a
>uniform representation of these features graphically.

There is no standard way to handle "the screen" because there are no standard
screens. C++ is used from embedded systems with no screens to ones that may
have seven segment displays or 2 line alphanumeric LCD display all the way up
to supercomputers which can generate real time animated 3D 8K video streams.
Which one would you choose?

You might as well say that C++ should have standardized printer support.

>Someone opposes to these arguments performance issues, others that there
>are many alternatives both proprietary and open sources. True, but,
>personally, I believe that enriching a programming language, making it
>more competitive and powerful, could be a big advantage for the language
>itself.

Unlikely. The job of a systems programming language like C++ is to provide
control logic and low level access to the system. It is the job of libraries to
use that low level access to provide I/O and other support services that will
vary considerably from one machine to another.

[Bart]

On 26/06/2020 12:12, bol...@nowhere.co.uk wrote:
> On Fri, 26 Jun 2020 11:40:32 +0200
> Alessandro Volturno <ale...@inwind.it> wrote:
>> Il 23/06/20 18:46, Mr Flibble ha scritto:
>>> There isn't one and there never should be: we have neoGFX for that! :D
>>>
>>> /Flibble
>>>
>>
>> I think adding standardized drawings and GUI facilities could be a major
>> benefit for the widespread of C++.
>
> Jave has a standard GUI built in to the JVM but it ended up being lowest common
> denominator and everyone hated it.
>
>> Console programs are now widely superseded by graphical UI (this
>> obviously doesn't mean CLI programs are not still used) and the last
>> standard editions of C++ added to it many advanced mathematical
>> features. It would be very useful, in my opinion, to offer the
>> programmer a unique, standard way to handle the screen and to permit a
>> uniform representation of these features graphically.
>
> There is no standard way to handle "the screen" because there are no standard
> screens. C++ is used from embedded systems with no screens to ones that may
> have seven segment displays or 2 line alphanumeric LCD display all the way up
> to supercomputers which can generate real time animated 3D 8K video streams.
> Which one would you choose?

This program is standard C++ (well more C but I couldn't be bothered to
look up the C++ idioms):

#include <stdio.h>

int main(void) {
int c;
c=getchar();
printf("%c\n",c);
}

It waits for a line of text from a keyboard, and echoes the first
character to the screen. Yet, some machines that run C++ don't have a
keyboard, and don't have a screen; how can that possibly work then?

You can argue that it doesn't assume a keyboard or screen at all, but
just uses stdin and stdout. Somehow however it still works with a
keyboard and screen when they are present. So why can't a pixel display
(with alternate input such as a mouse thrown in) work the same way?

> Unlikely. The job of a systems programming language like C++ is to provide
> control logic and low level access to the system. It is the job of libraries to
> use that low level access to provide I/O and other support services that will
> vary considerably from one machine to another.
>

This stuff doesn't particulary need core language support. Just the
assurance that certain libraries are available in any implementation.
Compared with what /are/ provided as libraries, the requirements are modest.

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

On Fri, 26 Jun 2020 13:34:50 +0100
Bart <b...@freeuk.com> wrote:
>On 26/06/2020 12:12, bol...@nowhere.co.uk wrote:
>> There is no standard way to handle "the screen" because there are no standard
>
>> screens. C++ is used from embedded systems with no screens to ones that may
>> have seven segment displays or 2 line alphanumeric LCD display all the way up
>
>> to supercomputers which can generate real time animated 3D 8K video streams.
>> Which one would you choose?
>
>This program is standard C++ (well more C but I couldn't be bothered to
>look up the C++ idioms):
>
> #include <stdio.h>
>
> int main(void) {
> int c;
> c=getchar();
> printf("%c\n",c);
> }
>
>It waits for a line of text from a keyboard, and echoes the first
>character to the screen. Yet, some machines that run C++ don't have a
>keyboard, and don't have a screen; how can that possibly work then?

It doesn't:

fenris$ cat t.c
#include <stdio.h>
#include <unistd.h>

int main()
{
int c;
close(0);
if ((c = getchar()) == EOF) perror("getchar()");
return 0;
}
fenris$ cc t.c; a.out
getchar(): Bad file descriptor

>keyboard and screen when they are present. So why can't a pixel display
>(with alternate input such as a mouse thrown in) work the same way?

You could always write your own wrappers to ignore any errors so the main
program is unaware but it doesn't change the fact that building in graphics to
C++ is absurd.

[Bart]

Not sure what your point is. The Windows equivalent (the equivalent
everywhere I think) would be to close the input stream using
'fclose(stdin)'. But this would stop a lot of programs working too.

>> keyboard and screen when they are present. So why can't a pixel display
>> (with alternate input such as a mouse thrown in) work the same way?
>
> You could always write your own wrappers to ignore any errors so the main
> program is unaware but it doesn't change the fact that building in graphics to
> C++ is absurd.

It is very, very common for computer programs to be associated with some
sort of terminal providing text input and text output (my first time on
a computer was with an ASR33).

And this is generally supported by languages (either built-in like mine,
or via a standard library like C++), which often also go to the trouble
of providing text formatting features (eg. printf's format strings).

Is it that much of a stretch to consider that a standard terminal might
have been a pixel-based device rather than a character based one?
Especially considering that now, pretty much every output device is
pixel-based.

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

On Fri, 26 Jun 2020 16:21:24 +0100
Bart <b...@freeuk.com> wrote:
>On 26/06/2020 15:35, bol...@nowhere.co.uk wrote:
>> fenris$ cc t.c; a.out
>> getchar(): Bad file descriptor
>
>Not sure what your point is. The Windows equivalent (the equivalent

My point is that you asked this:

>>> character to the screen. Yet, some machines that run C++ don't have a
>>> keyboard, and don't have a screen; how can that possibly work then?

I showed you it doesn't work.

>> You could always write your own wrappers to ignore any errors so the main
>> program is unaware but it doesn't change the fact that building in graphics
>to
>> C++ is absurd.
>
>It is very, very common for computer programs to be associated with some
>sort of terminal providing text input and text output (my first time on
>a computer was with an ASR33).
>
>And this is generally supported by languages (either built-in like mine,
>or via a standard library like C++), which often also go to the trouble
>of providing text formatting features (eg. printf's format strings).
>
>Is it that much of a stretch to consider that a standard terminal might
>have been a pixel-based device rather than a character based one?

Yes it is. Some kind of character based I/O system is required to get data into
and out of a computer - certainly to program it - otherwise its just an
expensive brick hence all languages support character based I/O by design. The
same cannot be said for pixel based displays any more that it can for printers
or plotters.

[Chris M. Thomasson]

On 6/23/2020 9:46 AM, Mr Flibble wrote:
> There isn't one and there never should be: we have neoGFX for that! :D
>
> /Flibble
>

Graphics in C++? How about C?

http://codepad.org/lkknRnxq

____________________

/* Mandelbrot Set ASCII by Chris M. Thomasson :^)
______________________________________________________*/


#include <stdio.h>


#define SQ(mp_n) ((mp_n) * (mp_n))




struct mbrot_cp_pixel
{
double x;
double y;
};


struct mbrot_cp_plane
{
double xmin;
double xmax;
double ymin;
double ymax;
};


struct mbrot_vp_plane
{
unsigned int width;
unsigned int height;
};




void
mbrot_pixel(
struct mbrot_cp_pixel const* pixel_c,
unsigned int const imax
){
int i = 0;
struct mbrot_cp_pixel pixel_z = { 0.0, 0.0 };
struct mbrot_cp_pixel pixel_z_sq = { 0.0, 0.0 };

for (i = 0; i < imax; ++i)
{
pixel_z.y = pixel_z.x * pixel_z.y * 2.0 + pixel_c->y;
pixel_z.x = pixel_z_sq.x - pixel_z_sq.y + pixel_c->x;

pixel_z_sq.x = SQ(pixel_z.x);
pixel_z_sq.y = SQ(pixel_z.y);

if (pixel_z_sq.x + pixel_z_sq.y > 4.0)
{
putchar(' ');
return;
}
}

putchar('*');
}


void
mbrot_plane(
struct mbrot_cp_plane const* cp_plane,
struct mbrot_vp_plane const* vp_plane,
unsigned int const imax
){
unsigned int vpyi = 0;

struct mbrot_cp_pixel cp_pixel = { 0.0, 0.0 };

double const cp_width = cp_plane->xmax - cp_plane->xmin;
double const cp_height = cp_plane->ymax - cp_plane->ymin;

double const xstep = cp_width / vp_plane->width;
double const ystep = cp_height / vp_plane->height;

for (vpyi = 0; vpyi < vp_plane->height; ++vpyi)
{
unsigned int vpxi = 0;

cp_pixel.y = cp_plane->ymax - vpyi * ystep;

for (vpxi = 0; vpxi < vp_plane->width; ++vpxi)
{
cp_pixel.x = cp_plane->xmin + vpxi * xstep;

mbrot_pixel(&cp_pixel, imax);
}

putchar('\n');
}
}




int
main(void)
{
struct mbrot_cp_plane const cp_plane = { -2.0, 1.0, -1.0, 1.0 };
struct mbrot_vp_plane const vp_plane = { 64, 32 };

mbrot_plane(&cp_plane, &vp_plane, 64);

return 0;
}

____________________


;^)

[Cholo Lennon]

On 6/26/20 6:40 AM, Alessandro Volturno wrote:
> Il 23/06/20 18:46, Mr Flibble ha scritto:
>> There isn't one and there never should be: we have neoGFX for that! :D
>>
>> /Flibble
>>
>
> I think adding standardized drawings and GUI facilities could be a major
> benefit for the widespread of C++.
>
> Console programs are now widely superseded by graphical UI (this
> obviously doesn't mean CLI programs are not still used) and the last
> standard editions of C++ added to it many advanced mathematical
> features. It would be very useful, in my opinion, to offer the
> programmer a unique, standard way to handle the screen and to permit a
> uniform representation of these features graphically.
>

I don't know if your first assertion ("console programs are now widely
superseded by graphical UI") is true. Could you provide some
source/stats for that? IMHO the GUI apps are just the tip of the
iceberg... but a more or less 50-50 proportion is not crazy at all.


--
Cholo Lennon
Bs.As.
ARG

[alelvb]

Il 27/06/20 03:31, Cholo Lennon ha scritto:

No... I cannot give any statistics. I'm not competent on the
matter. I said that from my limited experience as amateur
self-taught programmer.

Sorry : )

[Manfred]

Even without accurate statistics one can easily get some idea: a typical
Linux (or *nix for that matter) server distribution does not include an
X server, which means there is no GUI at all.
It is an easy guess that there is quite a lot of server code running out
there.

[Manfred]

On 6/26/2020 1:12 PM, bol...@nowhere.co.uk wrote:
> On Fri, 26 Jun 2020 11:40:32 +0200
> Alessandro Volturno <ale...@inwind.it> wrote:
>> Il 23/06/20 18:46, Mr Flibble ha scritto:
>>> There isn't one and there never should be: we have neoGFX for that! :D
>>>
>>> /Flibble
>>>
>>
>> I think adding standardized drawings and GUI facilities could be a major
>> benefit for the widespread of C++.
>
> Jave has a standard GUI built in to the JVM but it ended up being lowest common
> denominator and everyone hated it.
>

[...]

>
>> Someone opposes to these arguments performance issues, others that there
>> are many alternatives both proprietary and open sources. True, but,
>> personally, I believe that enriching a programming language, making it
>> more competitive and powerful, could be a big advantage for the language
>> itself.
>
> Unlikely. The job of a systems programming language like C++ is to provide
> control logic and low level access to the system. It is the job of libraries to
> use that low level access to provide I/O and other support services that will
> vary considerably from one machine to another.
>
>

Agreed, C++ is not meant o be an "all purpose" language - Stroustrup
himself says that no programmer should limit themselves to one language
only.
This is different from Java, for which one of the goals was to run the
entire system (and for example Android followed this path by deprecating
any non-Java application) - and still the result is hardly usable unless
the GUI subsystem is deeply rebuilt.