Window creation, for phobos?

[Rikki Cattermole via Digitalmars-d]

On 30/01/2015 12:17 a.m., Mike wrote:
> On Tuesday, 27 January 2015 at 22:05:02 UTC, Rikki Cattermole wrote:
>> I have dream! A dream, dream dream. A dream to see GUI's easy to use
>> in D! I must admit it will be hard, but it's time. Prime time I mean!
>>
>> Now enough gabble.
>> I'm proposing to get Devisualization.Window PR'd into phobos.
>
> I would love to see some facilities in D for GUI development, but I'm
> not sure about window creation.  Is the concept of a *window* even that
> platform agnostic?  I thought that was mostly a desktop metaphor.

Lets use iOS/Android as an example.
On Mobile an app only has one "window", so the implementation is defined 
to be singleton. Except Android can also be used with tv's, so its not 
really singleton.

Things like a window icon or minimize/maximize may not be applicable to 
certain platforms and that's ok. That's what exceptions / @disable is for.

> There are a few fundamental packages related to this domain that I think
> would fit nicely into Phobos, and could potentially plant a few seeds in
> this community that might spur exponential growth.
>
> 1. Color package
> 2. 2d/3d geometry package
> 3. Frame buffer package (Does OpenGL/DirectX make this obsolete?)
 >
> With those in place...
> 4. Imaging package
> 5. Vector graphics package
> 6. SVG package
> 7. Perhaps some kind of an input package
> etc...
>
> You get the idea:  Build a few platform agnostic fundamentals and I
> think the community will take it from there.  And once these are in
> place, a GUI toolkit isn't far away, and wouldn't need to have
> dependencies on 3rd party libraries.  But all this would be hard work,
> especially if it's intended to pass the high bar of standard library
> inclusion.

Yup, and now you know how I'm making Devisualization in general. We are 
100% on the same page!

> I have an interesting use case such for such libraries.  I sometimes
> build small HMIs (Graphical touch screens) for machines like
> thermostats, refrigerators, vending machines, etc...  The hardware is
> very resource constrained.  The LCDs are typically no greater than
> RGB666, so the primary frame buffer is RGB565 to save on memory. The API
> thinly exposes color as RGB8888, as that's a little more convenient to
> work with.  Almost all graphics is done in software with DMA being the
> only real hardware support.  I've been exploring D, Rust, and Nim for
> use in this domain.  I know this is a niche domain for D, but it seems
> these facilities, if designed to be efficient with resources, would
> scale well to, and perform superbly on, more resource abundant platforms.

Awesome!
It definitely is pushing anything I am considering, let alone proposing 
though. No way any of the libraries we will get into phobos will be 
designed for ultra memory tight.