Group rename: graphics -> i/o

[Herb Sutter]

Hi all,

 

At the WG21 meeting last week, there was strong feedback that “graphics” meant too many things to different people and a better name was needed to allude to that right now we’re looking at low-level primitives for basic drawing output and pointing input.

 

There were several suggestions, and the best was “I/O” – which makes a lot of sense to me given that a big motivation for our charter is improvements beyond stdin/stdout, “more than VT100! more than VT100! more than VT100!” (which would really be an awesome band name or stadium chant).

 

Since “more than VT100!” was too long, I’ve shortened it to “I/O”…

 

It was nice seeing a number of you in Issaquah! Thanks,

 

Herb

 

 

 

[Ville Voutilainen]

On 18 February 2014 20:23, Herb Sutter <hsu...@microsoft.com> wrote:
> Hi all,
>
>
>
> At the WG21 meeting last week, there was strong feedback that "graphics"
> meant too many things to different people and a better name was needed to
> allude to that right now we're looking at low-level primitives for basic
> drawing output and pointing input.
>
>
>

> There were several suggestions, and the best was "I/O" - which makes a lot

> of sense to me given that a big motivation for our charter is improvements
> beyond stdin/stdout, "more than VT100! more than VT100! more than VT100!"
> (which would really be an awesome band name or stadium chant).
>
>
>

> Since "more than VT100!" was too long, I've shortened it to "I/O"...


People will confuse this with an iostream replacement in 1..2..3.. ;)

[Daniel Krügler]

I tend to agree with Ville. What about GUI (Graphical User Interface)
instead of I/O?

- Daniel

[Tony Van Eerd]

>
> I tend to agree with Ville. What about GUI (Graphical User Interface) instead
> of I/O?
>
> - Daniel

But it is definitely NOT a GUI. No buttons et al.

[Ville Voutilainen]

Yes. GUI sends a message that will scare the community beyond measure. I'm sure
of that. I'm not sure of the reaction to i/o, so let's see how it plays.

[Klaim - Joël Lamotte]

I think that it's a good move. 

First because it is, in the end, about input and output (GUI, input or ouput device acquisition etc.)

Second because even if Ville is right, if there was such library proposal for a new default input/output, wouldn't it be under the same field of concerns anyway?

Or maybe there would be a need for sub-sub-groups. No, forget about that.

Anyway a I/O working group sure feel like it could provide building blocks for a future GUI library. The 2D drawing API is clearly only one part of the problems to solve.

[J. Daniel Garcia]

Unfortunately I missed the graphics meeting, as I was most of the time at the Evolution Working Group.

However, I tend to agree with Ville that I/O is a confusing name leading to missunderstandings. The first thing that also came to my mind was the replacement of iostreams as we have had a thread with a long list of participations.

Besides, in may mental model things like filesystem are also I/O. But of course each one may have his/her own mental model.

I do not want to start a bike shedding issue. But perphaps an alternate name would be graphics i/o (graphics.io).

Regards!

--

J. Daniel

--
You received this message because you are subscribed to the Google Groups "I/O" group.
To unsubscribe from this group and stop receiving emails from it, send an email to io+unsu...@isocpp.org.
To post to this group, send email to i...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/io/.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/io/CAOU91OMTBT9tLN4oonMNV53EP%2Bq10pexBhYPiKd%3DSuJfYDgr4g%40mail.gmail.com.

[Klaim - Joël Lamotte]

On Tue, Feb 18, 2014 at 11:15 PM, J. Daniel Garcia <josedani...@uc3m.es> wrote:

Besides, in may mental model things like filesystem are also I/O. But of course each one may have his/her own mental model.

True.

Maybe something closer to Man-Machine Interface or something like that would have been more ...."precise".

[Thiago Macieira]

HMI

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Cleiton Santoia]

 On GoNative many people, including Herb Sutter, remembered us, that in c++ we can "look under the hood", and get access to the hardware, I thought that I understood at time, but now I got a doubt. 

In modern architectures, many (if not all) I/O operations falls under some DMA programming + Port R/W operations, witch commonly are handled by operational system, the problem arises when some of them like, graphics primitives from OpenGL are not on concern of OS. The i/o low level operations of "write a sector on disk" or "put some bytes on a range between B000:0000 and B000:03FF" or "get scan code from input port 0x60" are respectively shielded by file, console and keyboard concepts in modern ( and much older ) OS and BIOS. But a texture render on a OpenGL 3D scene have a lot of DMA programming calls, without concern of OS, what about GUI based systems like windows that have some graphics concepts like "window" and DC, even more, somebody claims that you have DirectX "inside" the OS.

So, my doubt 1: Does DMA+Ports away of c++ standard limits ? is it a OS job ? Should we expect some help on graphic primitives from the operational system, like files and console ? Should we understand OpenGL/DirectX as a GOS (Graphic Operation system) like DOS was a Disk Operation System, not a full operational system, but, just a part of it ? Should C++ provide another layer on top of them ? What about other devices like robotic arms or hard-locks or whatever PCI/SLOT cards someone invent ? Does them falls on "not concern of OS" ?

Doubt 2: Although many people have some criticism over iostream library, I took this as sample, IMHO, streams are good conceptually, iostream are typed i/o flow of data, easy and simple, and C++ defined the concept of stream as another layer upon files, memory and network(in some libraries), to free us of system differences, does it will engulf a sound stream ? a texture stream ? it will be possible to write something like "OffscreamTextureStream << imageSurfaceClip", in the same way we do "ofstream << int" ? Does a video stream is a C++ stream of frames ?

[Jason Zink]

I tend to agree with Daniel on this one - graphics.io seems like a compact but clearly expressed description of what we are doing.  It is I/O, but it is limited to input on graphics surfaces (although keyboard deviates here...) and of course output of graphics surfaces.  This should also alleviate any fears of replacing iostreams, since it clearly indicates that it is relevant to graphics.

That's my two cents anyways :)

[inkwizyt...@gmail.com]

maybe "interactive I/O"? this would be clear distinguish it from old I/O where program wait (usually) for next input without doing anything.

[mats.ta...@gmail.com]

Hi,

When you decide on a name, can you please prepend it with SG13, like the other SG google groups?

Mats