Date: Tue, 31 Jan 2023 16:19:30 +0900
Hi RObin,
I would recommend looking back on 2D graphics when considering potential
GUI library work.
Coworkers and I summarized our feedback around this space here:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1225r0.html
So for GUI library, I would suggest figuring out these kind of design
questions, and leading with them in a paper, before advancing to API design.
JF
On Tue, Jan 31, 2023 at 4:13 PM 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
>
I would recommend looking back on 2D graphics when considering potential
GUI library work.
Coworkers and I summarized our feedback around this space here:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1225r0.html
So for GUI library, I would suggest figuring out these kind of design
questions, and leading with them in a paper, before advancing to API design.
JF
On Tue, Jan 31, 2023 at 4:13 PM 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
>
Received on 2023-01-31 07:19:45