www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Window creation, for phobos?

reply Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Jan 27 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 28 Jan 2015 11:04:55 +1300, Rikki Cattermole wrote:


 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.


please, not Derelict! it's a great work and all that, but it's habit to=20
load ALL functions is nasty. not only it is unnecessary, it's sometimes=20
just wrong. i recall the problem with DlangUI, where Derelict tries to=20
load FreeImage function which is not in my (old) version of the library,=20
and DlangUI is not using that function at all. yet DlangUI builds=20
successfully and then failed to run until i commented out that function.=
Jan 27 2015
next sibling parent reply "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Tuesday, 27 January 2015 at 22:54:15 UTC, ketmar wrote:

 On Wed, 28 Jan 2015 11:04:55 +1300, Rikki Cattermole wrote:


 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.


 please, not Derelict! it's a great work and all that, but it's 
 habit to
 load ALL functions is nasty. not only it is unnecessary, it's 
 sometimes
 just wrong. i recall the problem with DlangUI, where Derelict 
 tries to
 load FreeImage function which is not in my (old) version of the 
 library,
 and DlangUI is not using that function at all. yet DlangUI 
 builds
 successfully and then failed to run until i commented out that 
 function.


Atleast in Derelict-GL3 its staged, so even if you don't have 
access to OpenGL 4.x it'll still load successfully 1.1.
Ugh I just checked there is no Derelict package for FreeImage, in 
fact dlangui doesn't depend upon it.
I'm now confused. Unless of course you are meaning Derelict-FT. 
In which case its not staged. And isn't aware of different 
versions.
Jan 27 2015
next sibling parent reply "desmond" <demsond dontask.me> writes:
https://github.com/DerelictOrg/DerelictFI

On Tuesday, 27 January 2015 at 23:07:46 UTC, Rikki Cattermole 
wrote:

 On Tuesday, 27 January 2015 at 22:54:15 UTC, ketmar wrote:

 On Wed, 28 Jan 2015 11:04:55 +1300, Rikki Cattermole wrote:


 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.


 please, not Derelict! it's a great work and all that, but it's 
 habit to
 load ALL functions is nasty. not only it is unnecessary, it's 
 sometimes
 just wrong. i recall the problem with DlangUI, where Derelict 
 tries to
 load FreeImage function which is not in my (old) version of 
 the library,
 and DlangUI is not using that function at all. yet DlangUI 
 builds
 successfully and then failed to run until i commented out that 
 function.


 Atleast in Derelict-GL3 its staged, so even if you don't have 
 access to OpenGL 4.x it'll still load successfully 1.1.
 Ugh I just checked there is no Derelict package for FreeImage, 
 in fact dlangui doesn't depend upon it.
 I'm now confused. Unless of course you are meaning Derelict-FT. 
 In which case its not staged. And isn't aware of different 
 versions.
Jan 27 2015
parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Tuesday, 27 January 2015 at 23:58:23 UTC, desmond wrote:

 https://github.com/DerelictOrg/DerelictFI


Huh, I have no idea how I missed that.
Anyway I was right in that it doesn't do staging of versions.
Jan 27 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 27 Jan 2015 23:07:44 +0000, Rikki Cattermole wrote:


 dlangui doesn't depend upon it.


that dependency was removed since then.


 And isn't aware of different versions.


of course. that's why it failed on my FreeImage: my library is older than=20
the one that Derelict is expecting to find, and loading failed,=20
complaining about missing API (which wasn't used by the program at all).=
Jan 27 2015
parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Wednesday, 28 January 2015 at 00:58:41 UTC, ketmar wrote:

 On Tue, 27 Jan 2015 23:07:44 +0000, Rikki Cattermole wrote:


 dlangui doesn't depend upon it.


 that dependency was removed since then.


 And isn't aware of different versions.


 of course. that's why it failed on my FreeImage: my library is 
 older than
 the one that Derelict is expecting to find, and loading failed,
 complaining about missing API (which wasn't used by the program 
 at all).


I am not really sure how its a problem... you were using the 
wrong version so its certainly reasonable that it did not work.
Jan 27 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 28 Jan 2015 02:32:44 +0000, Tofu Ninja wrote:


 On Wednesday, 28 January 2015 at 00:58:41 UTC, ketmar wrote:

 On Tue, 27 Jan 2015 23:07:44 +0000, Rikki Cattermole wrote:


 dlangui doesn't depend upon it.


 that dependency was removed since then.


 And isn't aware of different versions.


 of course. that's why it failed on my FreeImage: my library is older
 than the one that Derelict is expecting to find, and loading failed,
 complaining about missing API (which wasn't used by the program at
 all).


=20
 I am not really sure how its a problem... you were using the wrong
 version so its certainly reasonable that it did not work.


nope. nothing is wrong with that version, it just missing some API that=20
*wasn't* *used* at all. i can't see why the program should be broken by=20
the thing that it is not using. when i commented out missing APIs,=20
everything starts to work. using libraries in the proper way will not=20
cause this problem. and if that API is required by a program, the program=20
will break in compile time, not after it was successfully built.

it's wrong to break the program by something it doesn't use in the first=20
place.=
Jan 27 2015
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 1/28/2015 7:54 AM, ketmar wrote:

 On Wed, 28 Jan 2015 11:04:55 +1300, Rikki Cattermole wrote:


 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.


 please, not Derelict! it's a great work and all that, but it's habit to
 load ALL functions is nasty. not only it is unnecessary, it's sometimes
 just wrong. i recall the problem with DlangUI, where Derelict tries to
 load FreeImage function which is not in my (old) version of the library,
 and DlangUI is not using that function at all. yet DlangUI builds
 successfully and then failed to run until i commented out that function.


For several years, Derelict has had a feature I call "selective symbol 
loading" to allow people to load older versions of a library with a 
newer version of Derelict. All they need to do is implement a callback 
that checks the name of a missing function and return a value indicating 
if loading should continue or an exception should be thrown. Very few 
people use it.

After seeing your post about FreeImage in the DLangUI thread a few weeks 
back, I added a new feature to DerelictUtil which automates the 
selective symbol loading. It's now possible to specify a minimum version 
of a library and the loader will not throw an exception if a function is 
missing. It doesn't make sense for some Derelict packages to make use of 
it, but I did add it to the FreeImage loader.

At any rate, I can't automate it fully. There's no way for me to know if 
any given program requires a function that's isn't present in an older 
version of a library or not. Derelict users have to take some 
responsibility in determining the absolute minimum version they need to 
support.
Jan 27 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 28 Jan 2015 10:36:22 +0900, Mike Parker wrote:


 On 1/28/2015 7:54 AM, ketmar wrote:

 On Wed, 28 Jan 2015 11:04:55 +1300, Rikki Cattermole wrote:


 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.


 please, not Derelict! it's a great work and all that, but it's habit to
 load ALL functions is nasty. not only it is unnecessary, it's sometimes
 just wrong. i recall the problem with DlangUI, where Derelict tries to
 load FreeImage function which is not in my (old) version of the
 library,
 and DlangUI is not using that function at all. yet DlangUI builds
 successfully and then failed to run until i commented out that
 function.


 For several years, Derelict has had a feature I call "selective symbol
 loading" to allow people to load older versions of a library with a
 newer version of Derelict. All they need to do is implement a callback
 that checks the name of a missing function and return a value indicating
 if loading should continue or an exception should be thrown. Very few
 people use it.
=20
 After seeing your post about FreeImage in the DLangUI thread a few weeks
 back, I added a new feature to DerelictUtil which automates the
 selective symbol loading. It's now possible to specify a minimum version
 of a library and the loader will not throw an exception if a function is
 missing. It doesn't make sense for some Derelict packages to make use of
 it, but I did add it to the FreeImage loader.
=20
 At any rate, I can't automate it fully. There's no way for me to know if
 any given program requires a function that's isn't present in an older
 version of a library or not. Derelict users have to take some
 responsibility in determining the absolute minimum version they need to
 support.


please note that i'm not saying that Derelict is bad. sure, you can't=20
properly determine what API program requires... but the compiler can.=20
loading dynamic library by the way Derelict does has it's advantages, and=20
i don't want to tell that Derelict is "invalid". the only thing i meant=20
to say is that i don't think that using Derelict method of loading=20
libraries should be in Phobos -- 'cause people will forget to provide=20
callbacks, and 'cause someone may have library installed in some obscure=20
place, which 'pkg-config' knows, but Derelict don't, so linker is able to=20
find the library, but code using Derelict must be fixed manually.

there is nothing wrong in using Derelict in people's projects, i just=20
don't think that it is suitable for inclusion in standard library.

i'm sorry if it seems that i'm somehow marking Derelict as "done wrong".=
Jan 27 2015
parent Mike Parker <aldacron gmail.com> writes:
On 1/28/2015 4:59 PM, ketmar wrote:


 i'm sorry if it seems that i'm somehow marking Derelict as "done wrong".


No, I didn't take it that way at all. I just wanted to clarify for 
anyone reading this and wasn't aware that it's possible to avoid the 
issue entirely.
Jan 28 2015
prev sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Tuesday, 27 January 2015 at 22:54:15 UTC, ketmar wrote:

 On Wed, 28 Jan 2015 11:04:55 +1300, Rikki Cattermole wrote:


 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.


 please, not Derelict! it's a great work and all that, but it's 
 habit to
 load ALL functions is nasty. not only it is unnecessary, it's 
 sometimes
 just wrong. i recall the problem with DlangUI, where Derelict 
 tries to
 load FreeImage function which is not in my (old) version of the 
 library,
 and DlangUI is not using that function at all. yet DlangUI 
 builds
 successfully and then failed to run until i commented out that 
 function.


As Mike Parker says, you can support multiple library versions 
since years.

Example: 
https://github.com/d-gamedev-team/gfm/blob/master/enet/gfm/enet/enet.d#L30

And the support for multiple version has gone stronger recently.
Such a thing isn't even possible with static linking.
Jan 28 2015
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On 1/28/2015 7:04 AM, Rikki Cattermole wrote:


 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?


I have no objections to anything from Derelict being included. My 
opinion on whether or not graphics and windowing packages belong in 
Phobos is another matter :-) But feel free to do whatever you need to do 
with Derelict.
Jan 27 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-01-27 23:04, 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!


Oh, it's time for GUI season again :).


 Now enough gabble.
 I'm proposing to get Devisualization.Window PR'd into phobos.


What exactly are you proposing, just to be able to get a window or a 
full GUI library? Will this include some event handler/event processing 
as well?


 This cannot happen right now. It's blocked on many fronts.
 1) Objective-C bridge. The most obvious one for OSX


A bridge is a bad idea. D needs first class support for Objective-C, 
i.e. extern (Objective-C). But perhaps that's what you're referring to?


 6) Cocoa bindings (easy not an issue, just dependent on the bridge)


It depends on what you need. It's not really hard, just tedious and time 
consuming. If you don't need a full set of Cocoa bindings it's hopefully 
not a problem.

BTW, DStep can generate bindings for Objective-C code.


 Jacob Carlborg, how far off is the objective-c bridge?


If you refer to extern (Objective-C) I'm redoing it for the third time, 
now splitting it up in multiple pull requests. The first pull request 
has been created [1], although it hasn't received much review yet, at 
least not from any core developers (that I know of).


 Has any definitions to e.g. Cocoa been started either?


Maybe. There's someone in the forums that has started to use 
D/Objective-C. He has created bindings [2] for AppKit, Foundation and 
WebKit. I have no idea about the quality of the bindings and how 
complete they are.

I also have a lot of bindings [3] for my old Objective-C bridge. It 
should be possible to do some regular expression search-and-replace to 
adapt them to D/Objective-C, if desired.

As said above, DStep can generate bindings for Objective-C.

[1] https://github.com/D-Programming-Language/dmd/pull/4321
[2] https://github.com/DiveFramework/DiveFramework/tree/master/Interfaces
[3] http://dsource.org/projects/dstep/browser/dstep

-- 
/Jacob Carlborg
Jan 27 2015
parent reply "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Wednesday, 28 January 2015 at 07:48:42 UTC, Jacob Carlborg 
wrote:

 On 2015-01-27 23:04, 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!


 Oh, it's time for GUI season again :).


I might be a little bored of web development. To the point of, I 
have an amazing idea to replace dlang.org entire ecosystem. 
Andrei already knows and likes the idea. I just can't be bothered 
to make it happen.


 Now enough gabble.
 I'm proposing to get Devisualization.Window PR'd into phobos.


 What exactly are you proposing, just to be able to get a window 
 or a full GUI library? Will this include some event 
 handler/event processing as well?


Just window creation with basic event handling.
Basically to spec of what Devisualization.Window's interfaces [0] 
are already.
Nothing special currently like touch. Although based upon current 
trends it should be in there.


 This cannot happen right now. It's blocked on many fronts.
 1) Objective-C bridge. The most obvious one for OSX


 A bridge is a bad idea. D needs first class support for 
 Objective-C, i.e. extern (Objective-C). But perhaps that's what 
 you're referring to?


Thats what I was referring to.


 6) Cocoa bindings (easy not an issue, just dependent on the 
 bridge)


 It depends on what you need. It's not really hard, just tedious 
 and time consuming. If you don't need a full set of Cocoa 
 bindings it's hopefully not a problem.

 BTW, DStep can generate bindings for Objective-C code.


 Jacob Carlborg, how far off is the objective-c bridge?


 If you refer to extern (Objective-C) I'm redoing it for the 
 third time, now splitting it up in multiple pull requests. The 
 first pull request has been created [1], although it hasn't 
 received much review yet, at least not from any core developers 
 (that I know of).


I'll ping Andrei about it then.


 Has any definitions to e.g. Cocoa been started either?


 Maybe. There's someone in the forums that has started to use 
 D/Objective-C. He has created bindings [2] for AppKit, 
 Foundation and WebKit. I have no idea about the quality of the 
 bindings and how complete they are.

 I also have a lot of bindings [3] for my old Objective-C 
 bridge. It should be possible to do some regular expression 
 search-and-replace to adapt them to D/Objective-C, if desired.

 As said above, DStep can generate bindings for Objective-C.

 [1] https://github.com/D-Programming-Language/dmd/pull/4321
 [2] 
 https://github.com/DiveFramework/DiveFramework/tree/master/Interfaces
 [3] http://dsource.org/projects/dstep/browser/dstep


[0] 
https://github.com/Devisualization/window/blob/master/interfaces/devisualization/window/interfaces/window.d
Jan 28 2015
parent reply "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
What about that Aurora project? Wasn't that supposed to fill this 
kind of role?
Jan 28 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 29/01/2015 2:34 p.m., Jeremy DeHaan wrote:

 What about that Aurora project? Wasn't that supposed to fill this kind
 of role?


Window/Context creation is not the same as e.g. a GUI toolkit.
They are in fact very different.
A window/context creation library is usually within a GUI toolkit but a 
GUI toolkit is never in a window/context creation library.

If I was to compare Devisualization.Window, it would be to glfw.
We will not be agreeing on a GUI toolkit in the next couple of years. 
That's ok. We should at the very minimal be able to agree on how to 
create a window/context and get most types of events.
Jan 28 2015
parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Thursday, 29 January 2015 at 01:50:58 UTC, Rikki Cattermole 
wrote:

 On 29/01/2015 2:34 p.m., Jeremy DeHaan wrote:

 What about that Aurora project? Wasn't that supposed to fill 
 this kind
 of role?


 Window/Context creation is not the same as e.g. a GUI toolkit.
 They are in fact very different.
 A window/context creation library is usually within a GUI 
 toolkit but a GUI toolkit is never in a window/context creation 
 library.

 If I was to compare Devisualization.Window, it would be to glfw.
 We will not be agreeing on a GUI toolkit in the next couple of 
 years. That's ok. We should at the very minimal be able to 
 agree on how to create a window/context and get most types of 
 events.


Aurora is not intended to be a gui as far as I can tell, it is 
just a graphics library, it is supposed to include window 
creation as well as much more. But not gui. The plan was to build 
a gui library on top of it once it was done.

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.
Jan 28 2015
next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Thursday, 29 January 2015 at 02:07:26 UTC, Tofu Ninja wrote:

 ...


Also I just checked and Aurora has not been updated since june so 
it might be dead, I don't know.
Jan 28 2015
prev sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Jan 28 2015
parent "Tofu Ninja" <emmons0 purdue.edu> writes:
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.
Jan 28 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 28 2015
next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
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.
Jan 28 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
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!
Jan 28 2015
prev sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Jan 28 2015
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
GUI does not belong to Phobos.
Jan 28 2015
parent reply "user" <user user.com> writes:
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.
Jan 29 2015
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Jan 29 2015
prev sibling next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
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.
Jan 29 2015
parent "Piotrek" <no_data no_data.pl> writes:
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
Jan 29 2015
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
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.
Jan 30 2015
parent reply "user" <user user.com> writes:
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
Jan 31 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 31 January 2015 at 09:24:21 UTC, user wrote:

 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 judge exclusively by existing precedents and knowledge of D 
development process. DFL was officially endorsed at some point, 
it didn't make any difference. You hold an assumption that 
putting something in Phobos will oblige people to work on it 
further - but it doesn't work that way. We will simply have 
another bitrotting barely used Phobos package.

Only way to have long-living GUI package is getting critical mass 
of users and contributors for it. One doesn't need Phobos 
inclusion for that.
Feb 01 2015
next sibling parent reply "eles" <eles eles.com> writes:
On Sunday, 1 February 2015 at 12:33:31 UTC, Dicebot wrote:

 On Saturday, 31 January 2015 at 09:24:21 UTC, user wrote:



 development process. DFL was officially endorsed at some point,


err... DWT
Feb 01 2015
parent reply "eles" <eles eles.com> writes:
On Sunday, 1 February 2015 at 12:46:08 UTC, eles wrote:

 On Sunday, 1 February 2015 at 12:33:31 UTC, Dicebot wrote:

 On Saturday, 31 January 2015 at 09:24:21 UTC, user wrote:



 development process. DFL was officially endorsed at some point,


 err... DWT


or I might be wrong & mea culpa
Feb 01 2015
parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 1 February 2015 at 12:47:04 UTC, eles wrote:

 On Sunday, 1 February 2015 at 12:46:08 UTC, eles wrote:

 On Sunday, 1 February 2015 at 12:33:31 UTC, Dicebot wrote:

 On Saturday, 31 January 2015 at 09:24:21 UTC, user wrote:



 development process. DFL was officially endorsed at some 
 point,


 err... DWT


 or I might be wrong & mea culpa


Oh,those are not the same? Sort, have never used either. Anyway, 
one of them was :)
Feb 01 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-02-01 13:33, Dicebot wrote:


 I judge exclusively by existing precedents and knowledge of D
 development process. DFL was officially endorsed at some point, it
 didn't make any difference.


1. It was DWT

2. To be far, nothing in practice was done more than saying "DWT is the 
official GUI library for D" in a newsgroup post, probably deep instead 
an already existing thread. No mention on the web site, no move of the 
code to the same place as the core D repositories. Not bundled with the 
compiler, no contribution from the core developers, nothing. So no, of 
course it didn't help.

-- 
/Jacob Carlborg
Feb 01 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 1 February 2015 at 19:30:27 UTC, Jacob Carlborg wrote:

 On 2015-02-01 13:33, Dicebot wrote:


 I judge exclusively by existing precedents and knowledge of D
 development process. DFL was officially endorsed at some 
 point, it
 didn't make any difference.


 1. It was DWT


Yep, sorry, have never realized those are different, my mistake.


 2. To be far, nothing in practice was done more than saying 
 "DWT is the official GUI library for D" in a newsgroup post, 
 probably deep instead an already existing thread. No mention on 
 the web site, no move of the code to the same place as the core 
 D repositories. Not bundled with the compiler, no contribution 
 from the core developers, nothing. So no, of course it didn't 
 help.


Probbaly. But do you honestly believe including actual sources 
into Phobos would have made any real difference? I doubt core 
developers would work on it one way or the other - that is a huge 
waste of effort. And it wouldn't fit everyone on user side either.
Feb 01 2015
next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Sunday, 1 February 2015 at 21:38:33 UTC, Dicebot wrote:

 Probbaly. But do you honestly believe including actual sources 
 into Phobos would have made any real difference? I doubt core 
 developers would work on it one way or the other - that is a 
 huge waste of effort. And it wouldn't fit everyone on user side 
 either.


Having something would be better than having nothing, and I for 
one would be much more willing to contribute to a gui library if 
I knew it was going into phobos.
Feb 01 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 01 Feb 2015 21:38:31 +0000, Dicebot wrote:


 Probbaly. But do you honestly believe including actual sources into
 Phobos would have made any real difference? I doubt core developers
 would work on it one way or the other - that is a huge waste of effort.
 And it wouldn't fit everyone on user side either.


at least if it is bundled with compiler, people will see it as "official=20
GUI lib". there is no urgent need to include it in Phobos and moving=20
repository, it's enough to be "blessed" with bundling.=
Feb 01 2015
prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Jan 29 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Jan 29 2015
parent reply "ponce" <contact gam3sfrommars.fr> writes:
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.
Jan 31 2015
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
Jan 31 2015
parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
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?
Jan 31 2015
parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
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.
Jan 31 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
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).
Jan 31 2015
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.)
Jan 29 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 30 January 2015 at 00:47, Adam D. Ruppe via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

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


I didn't realise that this proposal was limited to appearing a single
window on screen.
There are progressions form that though, visibility, window flags,
positioning it, filling it with pixels... we now need to invent a
bitmap, or expose opengl for rendering to it. Where does it end?
If my requirements are really so simple that I just need to appear a
window and put pixels on it, I have no problem writing portable code
for that. It's only a few lines per platform.
Feb 01 2015
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 2 February 2015 at 05:50:29 UTC, Manu wrote:

 I didn't realise that this proposal was limited to appearing a 
 single window on screen.


Obviously not, that would be pretty useless. But popping up a 
window that lets you draw in it and respond to events in it, 
while exposing hooks for more functionality is pretty useful and 
not that hard; it isn't like rewriting Qt.
Feb 02 2015
prev sibling parent reply "Mike" <none none.com> writes:
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
Jan 29 2015
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Jan 29 2015
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Jan 29 2015
next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
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.
Jan 29 2015
prev sibling next sibling parent "Piotrek" <no_data no_data.pl> writes:
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
Jan 29 2015
prev sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Jan 29 2015
parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
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.
Jan 29 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Jan 29 2015
prev sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
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".
Jan 31 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Jan 31 2015