Hi Robin and all people around.
I would recommend exploring first the possibility of creating a separate basic human-interface standard document that would describe APIs for I/O involving humans. Separate in the same way the tooling standard document is being made. In our case the point of such side-standard library spécification would be just to have a very simple (not ultra flexible) way to work with simple gui, simple drawing, simple input acquisition, simple audio with teaching, rapid development (of simple ideas) and scientific representation and interaction with models in mind.
The intent would be to have a common interface for these things but not require C++ implementations to provide them. If one do sell being compatible with that standard, such implementations would only be able to provide the specified API. Implémentation could then come both from the C++ willing implementations or from package managed other implementations.
Without such thing, I believe no effort in that domain will result in anything productive in the context of the C++ standard evolution, mainly because of the points risen by Guy (the package manager argument that conflates easy availability with standardisation of Apis, and the confusion from almost everybody that think being able to draw into a canvas is related to modern 3d GPU based rendering Apis, outside of the possible implementations).
I fear that your efforts will be wasted unless they are targeting not-the-C++-standard-library.
I also do not trust the current library and language evolution committees to be competent or even willing to learn about understanding why having basic human-interface tooling available by default is crucial for the long-term evolution of such a language (note that such competency is nécessary to achieve the goals set by the committee itself, so in my eyes it's all contradictory behavior).
As for such a gui interface, note that GUIs involve interacting with potentially asynchronous implementations. Even immediate interface libraries sometime have to use callbacks. You talk about event loops too of course. Because of all that, I believe any human-machine interface will have to expose Sender&Receiver to be composable with whatever else. Maybe consider imagining your Apis with that in mind?
I would strongly advise you *against* writing such a proposal without first writing a rationale and overview of the technical approach and its trade offs. Choosing a particular implementation without doing what I suggest will likely be a waste of time.
Thank you everyone for the feedback! Interesting.
Herb has advised that my first step should be to write a proposal. I've
collaborated with ISO before and understand the process. The proposal I
am planning is different from the past Cairo/PDF-inspired proposal. I am
thinking of proposing to make FLTK the C++ GUI standard. I will ask on
the FLTK list how folks there feel about it.
To both write a proposal and participate in committee meetings may be
more ambitious than what I can give now. I won't make it in-person to
the committee meeting in Seattle next week.
If I will draft the proposal, who would like to team with me to handle
the committee process?
Robin Rowe, CTO
323-535-0952 (Los Angeles)
Tech blog: goshrobin.com
SG13 mailing list
SG13 mailing list