Input event model.

[Tom Kirby-Green]

One of the original ideas behind this graphics API was that it would be the pixel based equivalent to std::cin and std::cout. If we run with that analogy for a moment, plotting pixels is std::cout, but we've yet to address std::cin.

Subsequently theres been some talk that any input event model should really be the concern of a separate group.

What's the current consensus here? Is V1 going to be output only? Or will V1 ship with a pluggable input model and in subsequent versions the input event implementation will be provided by 'even...@isocpp.org' ( so to speak ) ?

Personally I think we badly need input in V1, this shouldn't just be an API for generating .PNG files...

[Jason Zink]

I personally would like to have some input in V1 - just drawing isn't what we are shooting for, and we can gain experience with each iteration of the API.  So my vote is to have an input model that is easily updated (i.e. plug your std::function into this slot for handling mouse events, another for keyboard, etc...).  Then we can refine the way those functions get called as we see fit.

 

Overall I think you are right on the money - we need both input and output for a starter kit...

[Herb Sutter]

I know that Michael is putting a sketch together of one approach. I think he was going to share some early notes in the next week or two (no rush, appreciate the contribution!). Others should feel free to do that too if they prefer a different direction for the API shape. We can do some discussion and iterative refinement of those draft proposals here on the list.

 

My short-term goal is to make sure the main stakeholders (including graphics library designers/vendors) know about this and can participate if they want, and to foster this initial design discussion to get one (or more) draft proposals(s) start coming together to an early-sketch-but-enough-to-see-the-shape stage. Then as we feel we’re getting to a point where the proposal(s) are well enough along that we could use a telecon or face-to-face subgroup meeting for higher-bandwidth discussion I can organize that. If there are multiple proposals that will be a good time to start getting a sense of which direction the group prefers.

 

I offered that one example (which BTW I did not create – it came from a blog post of Cinder DX support) just because I think it helps to have a couple of examples to see side by side how it feels to start using the API. I’m a big fan of proposals that are example-driven and include a few nice “here’s what you’d write to accomplish X” code demos.

 

Herb

 

 

--
You received this message because you are subscribed to the Google Groups "Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to graphics+u...@isocpp.org.
To post to this group, send email to grap...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/graphics/.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/graphics/a659b950-ca28-4efd-93c7-65177f3cbc6a%40isocpp.org.