On 29/01/2015 3:07 p.m., Tofu Ninja wrote:
snip

> It still seems like a good idea to try to get window creation now as
> Aurora could take a very long time to get done(if ever) and Aurora could
> use it as well.

Pretty much all GUI libraries in D already could take advantage of Devisualization.Window.
I would rather we all focused on one library for this then 5+. Even if each GUI toolkit wraps it up into something not similar to any others.

They can be so fiddly its not funny.
Wxwidgets for example has about 5 different event loops for OSX and they all do pretty much the same thing. Just so you get the idea of why I'm really pushing this.

Also partly why I will openly admit why my implementation may not be the best. It's just too hard to get right by yourself.

On 1/28/15 5:34 PM, Jeremy DeHaan wrote:
> What about that Aurora project? Wasn't that supposed to fill this kind
> of role?

I think Aurora is dead in spite of significant goodwill and karma expenditure. I think there might be a lesson in there, but I don't know exactly which. -- Andrei

On Thursday, 29 January 2015 at 02:23:55 UTC, Rikki Cattermole wrote:
> Also partly why I will openly admit why my implementation may not be the best. It's just too hard to get right by yourself.

Got to start somewhere.

On Thursday, 29 January 2015 at 02:26:18 UTC, Andrei Alexandrescu wrote:
> On 1/28/15 5:34 PM, Jeremy DeHaan wrote:
>> What about that Aurora project? Wasn't that supposed to fill this kind
>> of role?
>
> I think Aurora is dead in spite of significant goodwill and karma expenditure. I think there might be a lesson in there, but I don't know exactly which. -- Andrei

I think the lesson is probably to not shoot so high, which is why focusing on a window library makes so much more sense as it is a much smaller project.

On 29/01/2015 3:26 p.m., Andrei Alexandrescu wrote:
> On 1/28/15 5:34 PM, Jeremy DeHaan wrote:
>> What about that Aurora project? Wasn't that supposed to fill this kind
>> of role?
>
> I think Aurora is dead in spite of significant goodwill and karma
> expenditure. I think there might be a lesson in there, but I don't know
> exactly which. -- Andrei

It's scope was definitely a little on the large side.
Also why with Devisualization I have split things up into very manageable small chunks. With very specific scope.

Before I started it I had a very specific game plan for it. Devisualization.Window is quite literally at the bottom and hence first to be made.

I'm now at the point that I may not have the best image implementation. But the abstraction is relatively pretty decent.

But small summary:
- window doesn't see many changes these days. Mostly documentation and fixes for updates to image definition
- image, bare minimum png export and a relatively decent png import with an ok mutable type
- font, rasterizes BDF fonts fine. No underline/strike through
- scenegraph, sort of the same situation for window. Although could have more implementations of the scenegraph interfaces.
- mesh, ehh is at the very very beginning of life, has Wavefront Object model loader
- util, has a bunch of sub projects
	- core, needs more work especially the linegraph (given line/curves get all points based upon the step)
	- opengl, huge number of opengl functions need wrapping up in D types for easy calling. Also more work on the wrapping of Opengl concepts like buffers.
	- photoshop_aco same situation as window
	- I want a basic glu implementation but its too much work
- gmaterial, GUI toolkit based upon Google Material Design. Long long long way off. I've only just worked out how to make half decent shadows for papersheets. Which was a killer on how to do it.

Reward for doing small amounts of work. It's working half decently for me.

On 29/01/2015 3:32 p.m., Tofu Ninja wrote:
> On Thursday, 29 January 2015 at 02:26:18 UTC, Andrei Alexandrescu wrote:
>> On 1/28/15 5:34 PM, Jeremy DeHaan wrote:
>>> What about that Aurora project? Wasn't that supposed to fill this kind
>>> of role?
>>
>> I think Aurora is dead in spite of significant goodwill and karma
>> expenditure. I think there might be a lesson in there, but I don't
>> know exactly which. -- Andrei
>
> I think the lesson is probably to not shoot so high, which is why
> focusing on a window library makes so much more sense as it is a much
> smaller project.

Agreed. Not to mention the barrier to make a GUI toolkit will suddenly decrease so much its not even funny. It's literally quarter of the work.
Another quarter is wrapping functions and concepts up into nice packages.
Another quarter getting a design together with e.g. shaders.
Last quarter actually implementing the controls ext.

I'm lucky because I've gone with Google material design. I'm just implementing a spec. So design work is already done. It's already been proven to be an excellent base. It has the theory ext. behind it so no mucking around.

Most likely if Derelict-GL3 gets into phobos I'll have to get Devisualization.util:opengl also in.
Great example pyglet and lwjgl do almost exactly what I'm doing there. Might as well remove more barriers to game development!

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.

On 29/01/2015 9:09 p.m., 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.

Right now I won't be suggesting any form of GUI toolkit. So even if this got into phobos it wouldn't help most people.
It'll take at least a couple of years even if we Devisualization.Window is agreed to be the standard window/context creation library in the D community.

Getting a GUI toolkit into phobos isn't in the near future. So I won't be pretending it is.

I do hope though in a few years time, we can work with GUI's semi decently cross platform.

I'm chipping away at a colour module, although I've been distracted with work the last little bit.

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.


On 28 January 2015 at 08:04, Rikki Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> 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.
>
> This cannot happen right now. It's blocked on many fronts.
> 1) Objective-C bridge. The most obvious one for OSX
> 2) An image definition depends on color
> 3) OpenGL loading mechanism such as Derelict-GL3
> 4) X11 bindings for posix (easy not an issue)
> 5) More WinAPI bindings (easy not an issue)
> 6) Cocoa bindings (easy not an issue, just dependent on the bridge)
> 7) A color definition
>
> So this idea will take a long time to happen, and that's ok.
>
> First off, Derelict-Util/Derelict-GL3 is a biggy here. Its old code, lets
> admit it. Its also a standard for loading shared library functions.
> So Mike Parker, would you be willing for this to be PR'd? And if so, are we
> ok with this?
>
> Manu Evans has said he is working on a color module, any update on that? Jacob Carlborg, how far off is the objective-c bridge? Has any definitions to e.g. Cocoa been started either?
>
> Once we have a color definition then it'll be time to start work on an image
> definition/implementation.
> There is a few already present, ae, dlib and Devisualization.Image exist.
> The color implementation will change, but most of the code should not for
> each.
> Anyone willing to start working on something?
>
> The benefits of this will greatly outweigh the work that this will take to do and maintain. Just having a standard window + context interface will greatly make GUI toolkits more interchangeable. Not to mention for game development.

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.