Date: Tue, 31 Jan 2023 10:55:52 +0000
Hi Robin
There was a paper I collaborated on a few years ago
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0267r10.pdf
which suggested a simple drawing library and prompted the reawakening of
this study group. Do you intend to propose a superset of that? Or do you
expect to offer hooks for the host to provide drawing facilities? The API
started as a Cairo-like API but evolved a long way beyond that. It was
inspired by the PDF standard: if it can render a PDF, it should be able to
do anything we need. This itself dates back to the early 80s drawing
libraries that emerged after the Fairchild display buffer launched in the
70s.
While there was many years of work on the paper and discussion about it,
ultimately it was deemed out of scope for the standard, and deemed more
suitable for a standard package library. The problem was more that people
confused Drawing with Graphics, so GPU vendors were rather agitated.
I would be delighted to see more drawing support in C++ as-standard, since
there appears to be no sign yet of a standard packaging solution. I'm happy
to talk further about it, but be advised that you may be facing a steep
climb.
Cheers,
G
On Tue, 31 Jan 2023 at 08:00, Peter C++ via SG13 <sg13_at_[hidden]>
wrote:
> Robin,
>
> fwiw, there exists a pure C++ alternative forked from QT when it was open
> source: CopperSpice (copperspice.com)
>
> Peter
>
> Sent from Peter Sommerlad's iPad
> +41 79 432 23 32
>
> > On 31 Jan 2023, at 08:13, Robin Rowe via SG13 <sg13_at_[hidden]>
> wrote:
> >
> > Anyone interested in having a GUI standard for C++, like the STL
> library is for containers?
> >
> > Be able to "#include <gui>". That it would just work out-of-the-box,
> instead of having to custom configure FLTK, Qt, GTK, or whatever, in order
> to be able to code anything GUI in C++.
> >
> > I wasn't here in 2013 during the previous SG13 attempt to create a C++
> GUI standard. I'm told that any GUI API providing windows and scrollbars
> will be a hard sell to the committee, that there's only an interest here in
> standardizing the display of graphics primitives, text rendering and
> mouse/keyboard handling. To produce a GUI API something like the classic
> MS-DOS library conio.h:
> >
> > https://en.wikipedia.org/wiki/Conio.h
> >
> > Many immediate mode GUI APIs take this approach, such as Nuklear. These
> GUI APIs are interesting. I wouldn't mind learning more about them:
> >
> > https://cpp.libhunt.com/nuklear-alternatives
> >
> > Before we travel into exotic APIs, shall we review what has been
> mainstream in C/C++ GUI API programming for 25 years?
> >
> > C++ has threads, so there is no technical obstacle to standardizing upon
> a main loop GUI API. FLTK and GTK are a couple open source GUI
> implementations in wide use that are portable across Linux, Windows and
> MacOS.
> >
> > FLTK is open source, small, portable and in wide use. Bjarne Stroustrup
> showed FLTK code examples in his C++ book. Standardizing on FLTK as a
> popular best practice seems the easy course. Am wondering, what is the
> obstacle to adopting FLTK as a C++ GUI standard?
> >
> > If there's baggage that makes FLTK undesirable somehow, an idea would be
> to look way back to OPEN LOOK, an industry-wide portable GUI API released
> in 1988 as XView on Solaris. We could write a C++ wrapper for all its API
> calls, which have been widely proven a best practice. Obstacles to that as
> a C++ GUI standard?
> >
> > I was programming in OPEN LOOK XView on a Sun Sparc20 back in 1995:
> >
> > // hello.c -- XView program to display a panel button that says "Quit".
> > // Selecting the panel button exits the program.
> > #include <xview/xview.h>
> > #include <xview/frame.h>
> > #include <xview/panel.h>
> >
> > Frame frame;
> >
> > void quit()
> > { xv_destroy_safe(frame);
> > }
> >
> > int main(int argc,char* argv[])
> > { Panel panel;
> > xv_init(XV_INIT_ARGC_PTR_ARGV, &argc, argv, NULL);
> > frame = (Frame) xv_create (NULL, FRAME, FRAME_LABEL, argv[0],
> XV_WIDTH, 200, XV_HEIGHT, 100, NULL);
> > panel = (Panel) xv_create (frame, PANEL, NULL);
> > xv_create(panel, PANEL_BUTTON,PANEL_LABEL_STRING,
> "Quit",PANEL_NOTIFY_PROC, quit, NULL);
> > xv_main_loop(frame);
> > return 0;
> > }
> >
> > Every popular GUI toolkit since XView seems a variation of its API
> design. Something I notice about OPEN LOOK is it is concise. Fewer lines of
> code to write a GUI Hello World.
> >
> > GTK was first released as part of GIMP in 1996. I am not thrilled by the
> verbosity of GTK, although I am a maintainer of the old GTK1 version. The
> later versions of GTK have fragmented, have broken API compatibility so
> extensively they seem different toolkits.
> >
> > I'm no fan of Cairo, what later GTK versions rely upon. That programmer
> opinion is divided between those who love or despise Cairo seems to have
> been the demise of the attempt at defining a C++ GUI standard ten years
> ago. I'm told that SG13 proposal went nowhere because it was based upon a
> Cairo-like API.
> >
> > Although I use Qt, I wouldn't want to standardize on Qt because it has
> an unnecessary Moc C++ extension (preprocessor) it uses to connect window
> signals. Qt is however quite popular. If we really like the Qt API, there's
> the Moc-free port CopperSpice. I've never tried it. I do like that Qt is
> available on desktop and mobile platforms. Qt licensing is perhaps the
> biggest obstacle. Not open source for commercial apps.
> >
> > Nukklear, neoGFX and many other immediate mode GUI APIs that exist in
> the embedded and game world are interesting. A concern is whether any are
> in wide enough adoption to consider them proven and suitable to adopt as an
> industry standard best practice.
> >
> > I would not propose a new GUI API developed mostly from scratch. That
> way seems madness.
> >
> > Thoughts? Who wants a C++ GUI standard and what approach should it take?
> >
> > Best,
> >
> > Robin
> > --
> > Robin Rowe, CTO
> > HeroicRobots.com
> >
> > --
> > SG13 mailing list
> > SG13_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg13
> --
> SG13 mailing list
> SG13_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg13
>
There was a paper I collaborated on a few years ago
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0267r10.pdf
which suggested a simple drawing library and prompted the reawakening of
this study group. Do you intend to propose a superset of that? Or do you
expect to offer hooks for the host to provide drawing facilities? The API
started as a Cairo-like API but evolved a long way beyond that. It was
inspired by the PDF standard: if it can render a PDF, it should be able to
do anything we need. This itself dates back to the early 80s drawing
libraries that emerged after the Fairchild display buffer launched in the
70s.
While there was many years of work on the paper and discussion about it,
ultimately it was deemed out of scope for the standard, and deemed more
suitable for a standard package library. The problem was more that people
confused Drawing with Graphics, so GPU vendors were rather agitated.
I would be delighted to see more drawing support in C++ as-standard, since
there appears to be no sign yet of a standard packaging solution. I'm happy
to talk further about it, but be advised that you may be facing a steep
climb.
Cheers,
G
On Tue, 31 Jan 2023 at 08:00, Peter C++ via SG13 <sg13_at_[hidden]>
wrote:
> Robin,
>
> fwiw, there exists a pure C++ alternative forked from QT when it was open
> source: CopperSpice (copperspice.com)
>
> Peter
>
> Sent from Peter Sommerlad's iPad
> +41 79 432 23 32
>
> > On 31 Jan 2023, at 08:13, Robin Rowe via SG13 <sg13_at_[hidden]>
> wrote:
> >
> > Anyone interested in having a GUI standard for C++, like the STL
> library is for containers?
> >
> > Be able to "#include <gui>". That it would just work out-of-the-box,
> instead of having to custom configure FLTK, Qt, GTK, or whatever, in order
> to be able to code anything GUI in C++.
> >
> > I wasn't here in 2013 during the previous SG13 attempt to create a C++
> GUI standard. I'm told that any GUI API providing windows and scrollbars
> will be a hard sell to the committee, that there's only an interest here in
> standardizing the display of graphics primitives, text rendering and
> mouse/keyboard handling. To produce a GUI API something like the classic
> MS-DOS library conio.h:
> >
> > https://en.wikipedia.org/wiki/Conio.h
> >
> > Many immediate mode GUI APIs take this approach, such as Nuklear. These
> GUI APIs are interesting. I wouldn't mind learning more about them:
> >
> > https://cpp.libhunt.com/nuklear-alternatives
> >
> > Before we travel into exotic APIs, shall we review what has been
> mainstream in C/C++ GUI API programming for 25 years?
> >
> > C++ has threads, so there is no technical obstacle to standardizing upon
> a main loop GUI API. FLTK and GTK are a couple open source GUI
> implementations in wide use that are portable across Linux, Windows and
> MacOS.
> >
> > FLTK is open source, small, portable and in wide use. Bjarne Stroustrup
> showed FLTK code examples in his C++ book. Standardizing on FLTK as a
> popular best practice seems the easy course. Am wondering, what is the
> obstacle to adopting FLTK as a C++ GUI standard?
> >
> > If there's baggage that makes FLTK undesirable somehow, an idea would be
> to look way back to OPEN LOOK, an industry-wide portable GUI API released
> in 1988 as XView on Solaris. We could write a C++ wrapper for all its API
> calls, which have been widely proven a best practice. Obstacles to that as
> a C++ GUI standard?
> >
> > I was programming in OPEN LOOK XView on a Sun Sparc20 back in 1995:
> >
> > // hello.c -- XView program to display a panel button that says "Quit".
> > // Selecting the panel button exits the program.
> > #include <xview/xview.h>
> > #include <xview/frame.h>
> > #include <xview/panel.h>
> >
> > Frame frame;
> >
> > void quit()
> > { xv_destroy_safe(frame);
> > }
> >
> > int main(int argc,char* argv[])
> > { Panel panel;
> > xv_init(XV_INIT_ARGC_PTR_ARGV, &argc, argv, NULL);
> > frame = (Frame) xv_create (NULL, FRAME, FRAME_LABEL, argv[0],
> XV_WIDTH, 200, XV_HEIGHT, 100, NULL);
> > panel = (Panel) xv_create (frame, PANEL, NULL);
> > xv_create(panel, PANEL_BUTTON,PANEL_LABEL_STRING,
> "Quit",PANEL_NOTIFY_PROC, quit, NULL);
> > xv_main_loop(frame);
> > return 0;
> > }
> >
> > Every popular GUI toolkit since XView seems a variation of its API
> design. Something I notice about OPEN LOOK is it is concise. Fewer lines of
> code to write a GUI Hello World.
> >
> > GTK was first released as part of GIMP in 1996. I am not thrilled by the
> verbosity of GTK, although I am a maintainer of the old GTK1 version. The
> later versions of GTK have fragmented, have broken API compatibility so
> extensively they seem different toolkits.
> >
> > I'm no fan of Cairo, what later GTK versions rely upon. That programmer
> opinion is divided between those who love or despise Cairo seems to have
> been the demise of the attempt at defining a C++ GUI standard ten years
> ago. I'm told that SG13 proposal went nowhere because it was based upon a
> Cairo-like API.
> >
> > Although I use Qt, I wouldn't want to standardize on Qt because it has
> an unnecessary Moc C++ extension (preprocessor) it uses to connect window
> signals. Qt is however quite popular. If we really like the Qt API, there's
> the Moc-free port CopperSpice. I've never tried it. I do like that Qt is
> available on desktop and mobile platforms. Qt licensing is perhaps the
> biggest obstacle. Not open source for commercial apps.
> >
> > Nukklear, neoGFX and many other immediate mode GUI APIs that exist in
> the embedded and game world are interesting. A concern is whether any are
> in wide enough adoption to consider them proven and suitable to adopt as an
> industry standard best practice.
> >
> > I would not propose a new GUI API developed mostly from scratch. That
> way seems madness.
> >
> > Thoughts? Who wants a C++ GUI standard and what approach should it take?
> >
> > Best,
> >
> > Robin
> > --
> > Robin Rowe, CTO
> > HeroicRobots.com
> >
> > --
> > SG13 mailing list
> > SG13_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg13
> --
> SG13 mailing list
> SG13_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg13
>
Received on 2023-01-31 10:56:04