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.

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.

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.

Mike

On Thursday, 29 January 2015 at 08:09:16 UTC, user wrote:
> Apparently this is only my issue, all others seems to be ok with no GUI in phobos.

NO... I am not ok with no GUI in phobos. I am with you.

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.

On Thursday, 29 January 2015 at 11:17:32 UTC, Mike wrote:
> Is the concept of a *window* even that platform agnostic?

Is writeln even platform agnostic? I've used targets where it doesn't do anything.... including Microsoft Windows with the gui subsystem.

Generally, I think it is a mistake to reject something that is good for a great many users just because it isn't available everywhere. If it isn't right for your target, just don't use it.

I would caution against requiring the support libs in Phobos; we don't want programs to fail to start because Xlib isn't installed, for example. But there's ways to do that.

>  I thought that was mostly a desktop metaphor.

Any call to a create window function might fail at runtime, on a platform with no graphics support, all window creation can throw an exception. On a platform with just one screen, any beyond the first might throw.

A gui toolkit would probably need to do something about that to keep things like pop-up message and dialog boxes working, but for the basic stuff just saying it might throw should be good enough.

On Thursday, 29 January 2015 at 08:45:23 UTC, Manu wrote:
> I'm not convinced that D needs a custom GUI library though. That's a behemoth effort.

Indeed, but I find there's still quite a bit of value in even a small wrapper that just pops up a window and lets you do the basic drawing and input. My simpledisplay.d sets a low bar like that and I find it to be of enormous use.

(I'll probably be writing about it in the this week in D series very soon.)

On Thursday, 29 January 2015 at 14:45:19 UTC, Adam D. Ruppe wrote:
> Is writeln even platform agnostic? I've used targets where it doesn't do anything.... including Microsoft Windows with the gui subsystem.

Sure it does, it's just that by default the stdio handles are closed. You can still run your program with MyGuiProgram.exe > output.txt, or open them in your program.

I would consider writeln platform agnostic, it's just that it may not always be a console that it writes to.

On Thursday, 29 January 2015 at 11:24:22 UTC, Tofu Ninja wrote:
> On Thursday, 29 January 2015 at 08:09:16 UTC, user wrote:
>> Apparently this is only my issue, all others seems to be ok with no GUI in phobos.
>
> NO... I am not ok with no GUI in phobos. I am with you.


I ensure you there are many more waiting for standard gui library. I think this can be a killer feature for D.

For now I use QT for gui and would be happy to switch to D ASAP.

Piotrek

On Thursday, 29 January 2015 at 14:45:19 UTC, Adam D. Ruppe wrote:
> On Thursday, 29 January 2015 at 11:17:32 UTC, Mike wrote:
>> Is the concept of a *window* even that platform agnostic?
>
> Generally, I think it is a mistake to reject something that is good for a great many users just because it isn't available everywhere. If it isn't right for your target, just don't use it.
>

I agree 100%. Moreover C++ std lib have features not present on all targets, e.g. threads.

Piotrek

On 30/01/2015 3:45 a.m., Adam D. Ruppe wrote:

snip

> Any call to a create window function might fail at runtime, on a
> platform with no graphics support, all window creation can throw an
> exception. On a platform with just one screen, any beyond the first
> might throw.

I can think of a way to do that by using Derelict-Util ;) for xlib for example.
But it is an implementation detail. You won't build a D app for Android without being aware it is an Android app and need special treatment.
The thing I like about Google Material Design, is its basically designed to work as one "window" which makes things easier cross platform.

On Thursday, 29 January 2015 at 23:03:51 UTC, Rikki Cattermole wrote:
> I can think of a way to do that by using Derelict-Util ;) for xlib for example.
> But it is an implementation detail. You won't build a D app for Android without being aware it is an Android app and need special treatment.
> The thing I like about Google Material Design, is its basically designed to work as one "window" which makes things easier cross platform.

The one window thing is something that I have been thinking about a lot as well, it seems to really simplify ui design and the loss is fairly small. I am not even sure it is a loss, fewer windows can be seen as a plus to a lot of people. Also like you said, it makes it much simpler for cross platform.

One thing that is often never mentioned is metro apps, which is again a one window design. A lot of people seem to dislike them, but I attribute it to growing pains. Using them with a touch screen is an absolute delight and once you get used to them the mouse it just as good.

Touch should not be thought of as a less important feature, and pen input as well for that matter. Any attempt to make an input framework later down the road should have strong support for touch and at least good support for pen, as well as mouse and keyboard.