On 30/01/2015 3:30 p.m., Tofu Ninja wrote:
> 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.

I don't believe something like Google Material Design is appropriate for phobos. We're just too desktop focused.

> 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.

I can't really handle that right now, no gear that supports it.

On Thursday, 29 January 2015 at 08:09:16 UTC, user wrote:
> On Wednesday, 28 January 2015 at 12:02:25 UTC, Dicebot wrote:
>> GUI does not belong to Phobos.
>
> That's the only reason I use Java instead of D. If GUI is not in phobos, it has no guaranteed support. Of course this is because I only create GUI desktop application.
>
> Apparently this is only my issue, all others seems to be ok with no GUI in phobos.

Getting into Phobos does not add magical support guarantees. If there is a good GUI library in dub registry, you will get as much support from its author there as if it was in Phobos. Much more, in fact, as getting any changes is more difficult and time-consuming than into owned package.

Most important additions to Phobos are those that can define standard API for building user libraries on top. Very common utilities that have no real controversy about their implementation are good too, though less important.

But there are many different incompatible GUI options out there and no single option that would satisfy everyone. Even worse, there is no such "fits everyone" library out there at all, in any language.

I don't know, you sound like a perfectionist to me, like most of other community members. I can only give examples from my experience.

I am a controls engineer in my current day job, and I do SW coding in my free time (like couple of hours per week). In the past, I changed my D GUI libs from old-DWT --> DFL --> GTKD --> new DWT for obvious reasons. I cannot afford to keep doing that. Finally I gave up and picked python-TKinter and Java-swing. I know they will always work and they still keep working without any changes even after several update cycles.

My tools were such a hit that half the company (~ 0.5 * 2000 people) is using them now, which is nice. Had I written them in D, that would have been a nice advertisement for D.

Note that I don't care that the GUI lib has to be awesome or perfect. It just have to work, even if it is ugly like tkinter.

I think I understand the reasons for this philosophy of lean, mean and efficient std libs, they will help D compete with other heavily financially backed languages, but I guess the same philosophy is also hurting people like me. Maybe in another 10 years we will get a super efficient gui-lib in phobos, if at all, most likely we wont.

May be next time I will try to experiment once again with the gui-libs in dub.

- D user

On Thursday, 29 January 2015 at 09:13:17 UTC, Rikki Cattermole wrote:
> On 29/01/2015 9:45 p.m., Manu via Digitalmars-d wrote:
>> I'm chipping away at a colour module, although I've been distracted
>> with work the last little bit.
>
> I see, anything I can help with?
>
>> I'm not convinced that D needs a custom GUI library though. That's a
>> behemoth effort.
>> I tend to think a quality and well-maintained Qt binding/wrapping
>> would be a much more useful tool for us to have.
>> It's kind of a de-facto standard for portable gui these days. It will
>> also retain interoperability with other existing C/C++ code (of which
>> there is much), etc.
>> It will also get us mobile UI as a freebie, which is a market we
>> really want to get amongst.
>> You can't really overlook the man years in Qt, and the maturity of the
>> ecosystem.
>
> I agree about Qt. It would be definitely nice to get something like that on e.g. dub.
> I wouldn't call it a freebie for on mobile however. We would still have to manage binaries ext. outside of D land.
>
> Okay for argument sake completely hypothetical. Lets say I complete Devisualization.gmaterial.
> It uses OpenGL to render. Assuming symbols can be loaded via e.g. Derelict-GL3 on an Android device this way. The only thing limiting it is Devisualization.Window with window and context creation.
> This will be quite easy to do. Especially with my work with Djvm it would be very enjoyable experience.
> iOS is even easier, its mostly copy paste the OSX implementation and rename.
>
> It would be a bit of work. But it wouldn't be much considering. Now this I consider a freebie. Considering we could advertise it was purely D cross platform GUI toolkit with mobile support.
>
> I will say this about Google Material Design, its reasonably simple. I'm pretty close to getting the main infrastructure completely done. I was held up on shadows for paper sheets. I have figured out a simple way to do it however. At least to "fake" them.

I have very specific GUI requirements for future projects:
- the window I create should be child windows
- I'd prefer them *not using OpenGL*, can't risk that for consumer machines
- don't want native controls at all (others might want only them)

I tend to agree with Dicebot that no GUI lib can be uncontroversial. Note that C++ hasno GUI in the stndard library as well.
Even std.json is controversial and it's already pretty good. But it is replaced by DUB packages here and there.

On Thursday, 29 January 2015 at 11:17:32 UTC, 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.
>
> 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

ae graphics module has that, in a mostly untyped way. I like that.

> 2. 2d/3d geometry package

There are many, and they are already decoupled from images. I don't see why it's related.

> 3. Frame buffer package (Does OpenGL/DirectX make this obsolete?)

ae graphics module has a rich "CPU frame-buffer" package. I haven't seen a better proposal, only things that rely on one data-type or use virtual functions.

> 4. Imaging package

It's trivial to write image loaders against ae graphics module.
Also font rasterizers, image resamplers, etc.

> 5. Vector graphics package
> 6. SVG package

I'd _love_ to have those too.
But, again, ae graphics module show us how to write anti-aliased drawing primitive already (line, circle, ellipses...). Writing a vector renderer is a matter of extending these capabilities.

> 7. Perhaps some kind of an input package
This belong to a windowing library and should be decoupled from the imaging library as far as possible.
You can't have "windowing library X require image abstraction Y".

On 31/01/2015 11:49 p.m., ponce wrote:
> On Thursday, 29 January 2015 at 11:17:32 UTC, Mike wrote:

snip

>> 7. Perhaps some kind of an input package
> This belong to a windowing library and should be decoupled from the
> imaging library as far as possible.
> You can't have "windowing library X require image abstraction Y".

The only reason Devisualization.Window requires an image abstraction is to be able to support window icons. It may not seem like much. But I think that's a big deal to support that.

On Saturday, 31 January 2015 at 10:34:29 UTC, ponce wrote:
> On Thursday, 29 January 2015 at 09:13:17 UTC, Rikki Cattermole wrote:
>> On 29/01/2015 9:45 p.m., Manu via Digitalmars-d wrote:
>>> I'm chipping away at a colour module, although I've been distracted
>>> with work the last little bit.
>>
>> I see, anything I can help with?
>>
>>> I'm not convinced that D needs a custom GUI library though. That's a
>>> behemoth effort.
>>> I tend to think a quality and well-maintained Qt binding/wrapping
>>> would be a much more useful tool for us to have.
>>> It's kind of a de-facto standard for portable gui these days. It will
>>> also retain interoperability with other existing C/C++ code (of which
>>> there is much), etc.
>>> It will also get us mobile UI as a freebie, which is a market we
>>> really want to get amongst.
>>> You can't really overlook the man years in Qt, and the maturity of the
>>> ecosystem.
>>
>> I agree about Qt. It would be definitely nice to get something like that on e.g. dub.
>> I wouldn't call it a freebie for on mobile however. We would still have to manage binaries ext. outside of D land.
>>
>> Okay for argument sake completely hypothetical. Lets say I complete Devisualization.gmaterial.
>> It uses OpenGL to render. Assuming symbols can be loaded via e.g. Derelict-GL3 on an Android device this way. The only thing limiting it is Devisualization.Window with window and context creation.
>> This will be quite easy to do. Especially with my work with Djvm it would be very enjoyable experience.
>> iOS is even easier, its mostly copy paste the OSX implementation and rename.
>>
>> It would be a bit of work. But it wouldn't be much considering. Now this I consider a freebie. Considering we could advertise it was purely D cross platform GUI toolkit with mobile support.
>>
>> I will say this about Google Material Design, its reasonably simple. I'm pretty close to getting the main infrastructure completely done. I was held up on shadows for paper sheets. I have figured out a simple way to do it however. At least to "fake" them.
>
> I have very specific GUI requirements for future projects:
> - the window I create should be child windows
> - I'd prefer them *not using OpenGL*, can't risk that for consumer machines
> - don't want native controls at all (others might want only them)
>
> I tend to agree with Dicebot that no GUI lib can be uncontroversial. Note that C++ hasno GUI in the stndard library as well.
> Even std.json is controversial and it's already pretty good. But it is replaced by DUB packages here and there.

Regarding C++ that might change.

https://msopentech.com/blog/2015/01/28/experimenting-with-a-proposed-standard-gui-for-the-c-language/

http://isocpp.org/files/papers/N3888.pdf

On Saturday, 31 January 2015 at 11:34:42 UTC, Paulo Pinto wrote:
> On Saturday, 31 January 2015 at 10:34:29 UTC, ponce wrote:
>
> Regarding C++ that might change.
>
> https://msopentech.com/blog/2015/01/28/experimenting-with-a-proposed-standard-gui-for-the-c-language/
>
> http://isocpp.org/files/papers/N3888.pdf

Why not just anoint Qt the De-Facto standard?

On Sunday, 1 February 2015 at 05:10:52 UTC, Craig Dillabaugh wrote:
> On Saturday, 31 January 2015 at 11:34:42 UTC, Paulo Pinto wrote:
>> On Saturday, 31 January 2015 at 10:34:29 UTC, ponce wrote:
>>
>> Regarding C++ that might change.
>>
>> https://msopentech.com/blog/2015/01/28/experimenting-with-a-proposed-standard-gui-for-the-c-language/
>>
>> http://isocpp.org/files/papers/N3888.pdf
>
> Why not just anoint Qt the De-Facto standard?

I guess to call it de-facto is a bit strong. There are
alternatives for cross-platform GUIs... like WxWidgets.

On 1/02/2015 6:13 p.m., Craig Dillabaugh wrote:
> On Sunday, 1 February 2015 at 05:10:52 UTC, Craig Dillabaugh wrote:
>> On Saturday, 31 January 2015 at 11:34:42 UTC, Paulo Pinto wrote:
>>> On Saturday, 31 January 2015 at 10:34:29 UTC, ponce wrote:
>>>
>>> Regarding C++ that might change.
>>>
>>> https://msopentech.com/blog/2015/01/28/experimenting-with-a-proposed-standard-gui-for-the-c-language/
>>>
>>>
>>> http://isocpp.org/files/papers/N3888.pdf
>>
>> Why not just anoint Qt the De-Facto standard?
>
> I guess to call it de-facto is a bit strong. There are
> alternatives for cross-platform GUIs... like WxWidgets.

I enjoyed reading WxWidgets source. The five different event loop implementations for OSX was definitely quite useful. Other libraries like GLFW are awful in this reguard (reading/understandability).