Am 26.12.2012 16:31, schrieb evilrat:
> On Wednesday, 26 December 2012 at 15:21:08 UTC, David wrote:
>>
>> I just found out that keyinput making useable for awesomium is a pain, you know a trick?
> 
> no. a most simple way is to do ctfe function or mixin or template to convert chars to awesomium key codes, but i think it may be not portable and would require own version for each platform, though i may be wrong.
> 
> also awesomium 1.7 c++ api has function to do this "GetKeyIdentifierFromVirtualKeyCode", doesn't look to deep in 1.6 may be there is something similar

There is the same but, there is no C counterpart and it does something different.

On Wednesday, 26 December 2012 at 15:35:56 UTC, David wrote:
>
> There is the same but, there is no C counterpart and it does something
> different.

look at awesomiumgl demo, there is some example on using it. also it may worth looking at sdl(webflow) example, in webflow there is just simple mapping for this job but sdl provides crossplatform key codes unlike native system codes. and at last for C bindings it is possible to manually load one 1 c++ function.

Am 26.12.2012 16:44, schrieb evilrat:
> On Wednesday, 26 December 2012 at 15:35:56 UTC, David wrote:
>>
>> There is the same but, there is no C counterpart and it does something different.
> 
> look at awesomiumgl demo, there is some example on using it. also it may worth looking at sdl(webflow) example, in webflow there is just simple mapping for this job but sdl provides crossplatform key codes unlike native system codes. and at last for C bindings it is possible to manually load one 1 c++ function.

The c++ function isn't even needed. And meh SDL, using GLFW, I know that I have to map the keys, I simply thought you maybe already did it or knew a trick.

On Wednesday, 26 December 2012 at 15:46:12 UTC, David wrote:
> The c++ function isn't even needed. And meh SDL, using GLFW, I know that
> I have to map the keys, I simply thought you maybe already did it or
> knew a trick.

not yet :(
i've not finished callbacks stuff, then i would see if can find something.

but i agree, glfw and sdl sucks, also glfw has redundant call(glclearcolor) each frame :)

btw, may be u can try load that func for testing? should be not that hard, only finding mangled name is a bit problematic, but it's simple like this "nm awesomium.so | grep part_of_funcname"

> but i agree, glfw and sdl sucks,

No, only SDL sucks

> also glfw has redundant
> call(glclearcolor) each frame :)

That is not redundant, it's not the job of GLFW to do OpenGL stuff you're supposed to do

> btw, may be u can try load that func for testing? should be not that hard, only finding mangled name is a bit problematic, but it's simple like this "nm awesomium.so | grep part_of_funcname"

Got it working! (textinput and arrowkeys, didn't translate the others)
http://imgur.com/a4d6f

You don't need that func for the c-api (as it seems)

On Wednesday, 26 December 2012 at 16:14:11 UTC, David wrote:
>> but i agree, glfw and sdl sucks,
>
> No, only SDL sucks
>
>> also glfw has redundant
>> call(glclearcolor) each frame :)
>
> That is not redundant, it's not the job of GLFW to do OpenGL stuff
> you're supposed to do
>

this is OT, but ...

glfw does context creation, manages window and so on, it does same job as old glut does, but in drawing func callback it call glclearcolor each frame!(setting color to clear viewport), may be it is a bug or typo, but it is really bad - opengl is a state machine and constant switching one of the states(which also already has same value, unless user want to manually set this which is even more strange to call it) is bad for performance, anyway glfw is good for small samples and demos.

and thanks for info about old c api.

Am 27.12.2012 05:30, schrieb evilrat:
> On Wednesday, 26 December 2012 at 16:14:11 UTC, David wrote:
>>> but i agree, glfw and sdl sucks,
>>
>> No, only SDL sucks
>>
>>> also glfw has redundant
>>> call(glclearcolor) each frame :)
>>
>> That is not redundant, it's not the job of GLFW to do OpenGL stuff you're supposed to do
>>
> 
> this is OT, but ...
> 
> glfw does context creation, manages window and so on, it does same job as old glut does, but in drawing func callback it call glclearcolor each frame!(setting color to clear viewport), may be it is a bug or typo, but it is really bad - opengl is a state machine and constant switching one of the states(which also already has same value, unless user want to manually set this which is even more strange to call it) is bad for performance, anyway glfw is good for small samples and demos.

There is no "drawing func callback", we are probably speaking of two different glfw version (even though I don't know of such a callback even in glfw 2.7)

> and thanks for info about old c api.

On Thursday, 27 December 2012 at 10:35:20 UTC, David wrote:
> There is no "drawing func callback", we are probably speaking of two
> different glfw version (even though I don't know of such a callback even
> in glfw 2.7)

well ok i must be forgot something, but i clearly remember that bug(or 'feature'?)

Am 26.12.2012 02:27, schrieb evilrat:
> On Tuesday, 25 December 2012 at 15:35:02 UTC, David wrote:
>>
>> Oh wow it works!
>>
>> ─[dav1d@ArchBox][~/workspaces/d/awesomium_test]╼ dmd -I../awesomium -L-L. -L-lawesomium-1.6.5 short.d
>>
>> ─[dav1d@ArchBox][~/workspaces/d/awesomium_test]╼ LD_LIBRARY_PATH=. ./short
>>
>>
>> https://gist.github.com/4373754
>>
>> that is amzing!
> 
> yeah cool, but we need a OOP wrapper too that mimics C++ API, thats what i'm going to do ;)

I started with an abstraction: https://github.com/Dav1dde/wonne

Currently I've done only strings, I think I can add the rest today

On Thursday, 27 December 2012 at 13:16:33 UTC, David wrote:
>
> I started with an abstraction: https://github.com/Dav1dde/wonne
>
> Currently I've done only strings, I think I can add the rest today

just to mention, last time i tried D wchar with awesomium wchar it was pure fail, but may be i've just a bit messed up somewhere