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@lists.isocpp.org> 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@lists.isocpp.org> 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@lists.isocpp.org
> https://lists.isocpp.org/mailman/listinfo.cgi/sg13
--
SG13 mailing list
SG13@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg13