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).
> 
> 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 *wasn't* *used* at all. i can't see why the program should be broken by the thing that it is not using. when i commented out missing APIs, everything starts to work. using libraries in the proper way will not cause this problem. and if that API is required by a program, the program 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 place.

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

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

there is nothing wrong in using Derelict in people's projects, i just 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".

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

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.

GUI does not belong to Phobos.

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.

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

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.

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.

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.