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

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.

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.

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.

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

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.

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.

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.

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