Date: Mon, 30 Jan 2023 23:12:55 -0800
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
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
Received on 2023-01-31 07:12:59