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?


Joël Lamotte



Sent from mobile.

On Tue, Jan 31, 2023, 22:33 JF Bastien via SG13 <sg13_at_[hidden]>
wrote:

> Hi Robin,
>
> 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.
>
> JF
>
> On Wed, Feb 1, 2023 at 5:35 AM Robin Rowe via SG13 <sg13_at_[hidden]>
> wrote:
>
>> 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?
>>
>> Best,
>>
>> Rob
>> --
>> Robin Rowe, CTO
>> HeroicRobots.com
>> 323-535-0952 (Los Angeles)
>> Tech blog: goshrobin.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
>