Quantcast

CEF3 bindings and game dev in Haskell

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

CEF3 bindings and game dev in Haskell

Maksymilian Owsianny
Hey

I'm interested in making gamedev in haskell more viable and one thing
that I believe is missing in that part of the environment is a good
GUI story. So I decided to create proper bindings to cef3, you can
check out what I've done so far [here][1]. In this current version
I basically took the work done by Daniel Austin [here][2] split it
into parts to prevent my machine from dying from lack of memory and
packed it up with some nix glue for convenient usage. Now all this
doesn't look like much but it sill took me much more time then I'm
willing to admit in public. That's one of the eternal truths of
software development, that everything always takes an order of
magnitude more time then you suspect it would.

Anyway, what I would like to do here is add support for all platforms.
Create some nice scripts that help with automatizing building,
developing and deployment of code with this library for users.
Possibly write a script that automatically generates bindings from
c headers to bring this lib up to speed with the current version of
cef. Write some proper guides on using this lib for creating game GUI
or standalone desktop application. All of that is nice and well to
wish for but it is quite a lot of frankly not very fun work. If I had
to choose I would rather spend my time working on either something fun
or something that pays the rent, so usually at this point I stop and
walk away. But this time I decided to go about it differently, and ask
for community support. I have set up a BountySource campaign [here][3]
so I could focus on making this happen. Alternatively, if that's your
thing, I have set up a bitcoin address [4].

Depending on how well this campaign will go I'm also planing on
creating a full 2D game engine... but yeah, that's in the future.

So yeah, if you'd like to help me build this please support me.

Thanks,
Max.

[1]: https://github.com/haskell-ui/cef3-raw
[2]: https://github.com/fluffynukeit/bindings-cef3
[3]: https://salt.bountysource.com/teams/haskell-ui
[4]: 1LskxSUyLDLpMCBfUUnqcRT8mEFMW511Eq


PS. I have also created a reddit thread for this proposal here.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CEF3 bindings and game dev in Haskell

MarLinn

[Ack. Forgot to reply-to-list, and ran into the list's bad handling of gmail addresses again. So sorry for possible multi-posts.]

I agree that our GUI story is still bad.

But I don't understand what chromium has to do with either game dev or a good GUI story? If I want to write a real game, I use SDL2 bindings. If I want to write a website, I use something like Yesod. If I want to write browser games or "dynamic web sites", I throw JavaScript libraries at the walls, see what sticks, call it "modern coding", go to the liquor store and reconsider my life.

All joking aside, it's nice to see someone take a different path than usual, organization-wise. I do disagree on the technical path though. We already have a lot of bindings to several cross-platform frameworks and libraries, including QT, GTK, FLTK, and the aforementioned SDL2. But they suffer from impedance mismatch and lack of use and thus, community support. To solve that I would say what we need is a nice middle layer to translate functional thinking into framework models. We do have the diagrams package for describing static diagrams in a functional way, but it largely lacks dynamic behavior. (There's some support for animations, but it doesn't fill me with confidence.) We also have several attempts at FRP libraries for dynamic behavior, but few interactions with bindings. What is still missing is something like a dynamic version of diagrams that is based on one of these FRP libraries and that can work with one or several of the bindings as a back-end – possibly with a Haskell-side widget library. Possibly with css-like runtime styling And if we have that, yeah, we can add chromium bindings or whatever. Or write our own browser engine for fun. As far as I know there were several attempts but all fizzled out at some point.

My own favorite approach goes even further. I propose that many of the problems arise because the existing frameworks impose too many non-functional ideas, so the "purest" way to go forward would be a fresh framework on the basis of only SDL and reactive banana. That might sound like overkill for a simple non-game GUI, but is it really if the alternative is a whole browser? And what's more, that approach could be pursued in a way that might be turned into the one mentioned above later on.

What these approaches need is not more c tools or more cross-platform shenanigans, but some ideas how to handle a complex dynamic tangle of widget trees in a generic, functional fashion. Which to me has the added benefit of sounding much more like "fun". So I'm still working on that second approach whenever I have some time, but like yours, my time is limited.

Be assured, I don't want to diminish your work, it's probably useful to a certain subset of programmers. What I'm disputing is just if it's the single best way forward.

Cheers,
MarLinn

On 2017-03-09 22:52, Maksymilian Owsianny wrote:
Hey

I'm interested in making gamedev in haskell more viable and one thing
that I believe is missing in that part of the environment is a good
GUI story. So I decided to create proper bindings to cef3, you can
check out what I've done so far [here][1]. In this current version
I basically took the work done by Daniel Austin [here][2] split it
into parts to prevent my machine from dying from lack of memory and
packed it up with some nix glue for convenient usage. Now all this
doesn't look like much but it sill took me much more time then I'm
willing to admit in public. That's one of the eternal truths of
software development, that everything always takes an order of
magnitude more time then you suspect it would.

Anyway, what I would like to do here is add support for all platforms.
Create some nice scripts that help with automatizing building,
developing and deployment of code with this library for users.
Possibly write a script that automatically generates bindings from
c headers to bring this lib up to speed with the current version of
cef. Write some proper guides on using this lib for creating game GUI
or standalone desktop application. All of that is nice and well to
wish for but it is quite a lot of frankly not very fun work. If I had
to choose I would rather spend my time working on either something fun
or something that pays the rent, so usually at this point I stop and
walk away. But this time I decided to go about it differently, and ask
for community support. I have set up a BountySource campaign [here][3]
so I could focus on making this happen. Alternatively, if that's your
thing, I have set up a bitcoin address [4].

Depending on how well this campaign will go I'm also planing on
creating a full 2D game engine... but yeah, that's in the future.

So yeah, if you'd like to help me build this please support me.

Thanks,
Max.

[1]: https://github.com/haskell-ui/cef3-raw
[2]: https://github.com/fluffynukeit/bindings-cef3
[3]: https://salt.bountysource.com/teams/haskell-ui
[4]: 1LskxSUyLDLpMCBfUUnqcRT8mEFMW511Eq


PS. I have also created a reddit thread for this proposal here.


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CEF3 bindings and game dev in Haskell

Maksymilian Owsianny
The thing about this solution is, its simplicity. You can use the
skills of front end (HTML/CSS) people to design your GUI, you can then
build it using something like threepenny and render it to texture
using cef. You can use the skills and tools that already exist.
I agree that this solution is sub optimal, that including a whole
browser inside your application can be a bit much. But I believe that
at least having an option will be much better for the community then
not.

Cheers,
Max.

On Thu, Mar 9, 2017 at 11:53 PM, MarLinn <[hidden email]> wrote:

[Ack. Forgot to reply-to-list, and ran into the list's bad handling of gmail addresses again. So sorry for possible multi-posts.]

I agree that our GUI story is still bad.

But I don't understand what chromium has to do with either game dev or a good GUI story? If I want to write a real game, I use SDL2 bindings. If I want to write a website, I use something like Yesod. If I want to write browser games or "dynamic web sites", I throw JavaScript libraries at the walls, see what sticks, call it "modern coding", go to the liquor store and reconsider my life.

All joking aside, it's nice to see someone take a different path than usual, organization-wise. I do disagree on the technical path though. We already have a lot of bindings to several cross-platform frameworks and libraries, including QT, GTK, FLTK, and the aforementioned SDL2. But they suffer from impedance mismatch and lack of use and thus, community support. To solve that I would say what we need is a nice middle layer to translate functional thinking into framework models. We do have the diagrams package for describing static diagrams in a functional way, but it largely lacks dynamic behavior. (There's some support for animations, but it doesn't fill me with confidence.) We also have several attempts at FRP libraries for dynamic behavior, but few interactions with bindings. What is still missing is something like a dynamic version of diagrams that is based on one of these FRP libraries and that can work with one or several of the bindings as a back-end – possibly with a Haskell-side widget library. Possibly with css-like runtime styling And if we have that, yeah, we can add chromium bindings or whatever. Or write our own browser engine for fun. As far as I know there were several attempts but all fizzled out at some point.

My own favorite approach goes even further. I propose that many of the problems arise because the existing frameworks impose too many non-functional ideas, so the "purest" way to go forward would be a fresh framework on the basis of only SDL and reactive banana. That might sound like overkill for a simple non-game GUI, but is it really if the alternative is a whole browser? And what's more, that approach could be pursued in a way that might be turned into the one mentioned above later on.

What these approaches need is not more c tools or more cross-platform shenanigans, but some ideas how to handle a complex dynamic tangle of widget trees in a generic, functional fashion. Which to me has the added benefit of sounding much more like "fun". So I'm still working on that second approach whenever I have some time, but like yours, my time is limited.

Be assured, I don't want to diminish your work, it's probably useful to a certain subset of programmers. What I'm disputing is just if it's the single best way forward.

Cheers,
MarLinn

On 2017-03-09 22:52, Maksymilian Owsianny wrote:
Hey

I'm interested in making gamedev in haskell more viable and one thing
that I believe is missing in that part of the environment is a good
GUI story. So I decided to create proper bindings to cef3, you can
check out what I've done so far [here][1]. In this current version
I basically took the work done by Daniel Austin [here][2] split it
into parts to prevent my machine from dying from lack of memory and
packed it up with some nix glue for convenient usage. Now all this
doesn't look like much but it sill took me much more time then I'm
willing to admit in public. That's one of the eternal truths of
software development, that everything always takes an order of
magnitude more time then you suspect it would.

Anyway, what I would like to do here is add support for all platforms.
Create some nice scripts that help with automatizing building,
developing and deployment of code with this library for users.
Possibly write a script that automatically generates bindings from
c headers to bring this lib up to speed with the current version of
cef. Write some proper guides on using this lib for creating game GUI
or standalone desktop application. All of that is nice and well to
wish for but it is quite a lot of frankly not very fun work. If I had
to choose I would rather spend my time working on either something fun
or something that pays the rent, so usually at this point I stop and
walk away. But this time I decided to go about it differently, and ask
for community support. I have set up a BountySource campaign [here][3]
so I could focus on making this happen. Alternatively, if that's your
thing, I have set up a bitcoin address [4].

Depending on how well this campaign will go I'm also planing on
creating a full 2D game engine... but yeah, that's in the future.

So yeah, if you'd like to help me build this please support me.

Thanks,
Max.

[1]: https://github.com/haskell-ui/cef3-raw
[2]: https://github.com/fluffynukeit/bindings-cef3
[3]: https://salt.bountysource.com/teams/haskell-ui
[4]: 1LskxSUyLDLpMCBfUUnqcRT8mEFMW511Eq


PS. I have also created a reddit thread for this proposal here.


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CEF3 bindings and game dev in Haskell

MarLinn
On 2017-03-10 01:19, Maksymilian Owsianny wrote:
The thing about this solution is, its simplicity. You can use the
skills of front end (HTML/CSS) people to design your GUI, you can then
build it using something like threepenny and render it to texture
using cef. You can use the skills and tools that already exist.
I agree that this solution is sub optimal, that including a whole
browser inside your application can be a bit much. But I believe that
at least having an option will be much better for the community then
not.

Cheers,
Max.

Mhh… I get what you're getting at. But what can you really do with HTML+CSS without scripts? Ok, admittedly you can do a lot via crude tricks. You can create tabs, menus, pop-ups and loads of other stuff with pseudo-classes and pseudo-elements if you really want. But your average front-end-web-dev will not be used to using such tricks because on the web, everything is JS. And such hacks are an abuse of the tools anyway. So basically what you will get in practice with HTML+CSS are static pages or forms that you have to tie together somehow. So far so good, it's better than nothing. But we already have a really great, convenient library for static "pictures" with loads of existing back-ends – diagrams! Diagrams can even carry generic queries that you could fill with stuff like FRP endpoints. What's missing to fulfill your goal is a Parser that creates diagrams from HTML+CSS – which, of course, is basically a variation of one of the main purposes of a browser engine.

While that brings me back to the beginning, it seems to open a perspective for the future. Would you say it might be possible to start with chromium integration and then push it out again bit by bit by replacing it with the existing tools? For example would it be possible in the mid-term to "only" use the chromium parser but not the presentation layer, or vice-versa?

I feel there might even be a hidden path to a solution to our core web dev problems hidden here, but for now I fail to see specifics.

Cheers,
MarLinn

On Thu, Mar 9, 2017 at 11:53 PM, MarLinn <[hidden email]> wrote:

[Ack. Forgot to reply-to-list, and ran into the list's bad handling of gmail addresses again. So sorry for possible multi-posts.]

I agree that our GUI story is still bad.

But I don't understand what chromium has to do with either game dev or a good GUI story? If I want to write a real game, I use SDL2 bindings. If I want to write a website, I use something like Yesod. If I want to write browser games or "dynamic web sites", I throw JavaScript libraries at the walls, see what sticks, call it "modern coding", go to the liquor store and reconsider my life.

All joking aside, it's nice to see someone take a different path than usual, organization-wise. I do disagree on the technical path though. We already have a lot of bindings to several cross-platform frameworks and libraries, including QT, GTK, FLTK, and the aforementioned SDL2. But they suffer from impedance mismatch and lack of use and thus, community support. To solve that I would say what we need is a nice middle layer to translate functional thinking into framework models. We do have the diagrams package for describing static diagrams in a functional way, but it largely lacks dynamic behavior. (There's some support for animations, but it doesn't fill me with confidence.) We also have several attempts at FRP libraries for dynamic behavior, but few interactions with bindings. What is still missing is something like a dynamic version of diagrams that is based on one of these FRP libraries and that can work with one or several of the bindings as a back-end – possibly with a Haskell-side widget library. Possibly with css-like runtime styling And if we have that, yeah, we can add chromium bindings or whatever. Or write our own browser engine for fun. As far as I know there were several attempts but all fizzled out at some point.

My own favorite approach goes even further. I propose that many of the problems arise because the existing frameworks impose too many non-functional ideas, so the "purest" way to go forward would be a fresh framework on the basis of only SDL and reactive banana. That might sound like overkill for a simple non-game GUI, but is it really if the alternative is a whole browser? And what's more, that approach could be pursued in a way that might be turned into the one mentioned above later on.

What these approaches need is not more c tools or more cross-platform shenanigans, but some ideas how to handle a complex dynamic tangle of widget trees in a generic, functional fashion. Which to me has the added benefit of sounding much more like "fun". So I'm still working on that second approach whenever I have some time, but like yours, my time is limited.

Be assured, I don't want to diminish your work, it's probably useful to a certain subset of programmers. What I'm disputing is just if it's the single best way forward.

Cheers,
MarLinn

On 2017-03-09 22:52, Maksymilian Owsianny wrote:
Hey

I'm interested in making gamedev in haskell more viable and one thing
that I believe is missing in that part of the environment is a good
GUI story. So I decided to create proper bindings to cef3, you can
check out what I've done so far [here][1]. In this current version
I basically took the work done by Daniel Austin [here][2] split it
into parts to prevent my machine from dying from lack of memory and
packed it up with some nix glue for convenient usage. Now all this
doesn't look like much but it sill took me much more time then I'm
willing to admit in public. That's one of the eternal truths of
software development, that everything always takes an order of
magnitude more time then you suspect it would.

Anyway, what I would like to do here is add support for all platforms.
Create some nice scripts that help with automatizing building,
developing and deployment of code with this library for users.
Possibly write a script that automatically generates bindings from
c headers to bring this lib up to speed with the current version of
cef. Write some proper guides on using this lib for creating game GUI
or standalone desktop application. All of that is nice and well to
wish for but it is quite a lot of frankly not very fun work. If I had
to choose I would rather spend my time working on either something fun
or something that pays the rent, so usually at this point I stop and
walk away. But this time I decided to go about it differently, and ask
for community support. I have set up a BountySource campaign [here][3]
so I could focus on making this happen. Alternatively, if that's your
thing, I have set up a bitcoin address [4].

Depending on how well this campaign will go I'm also planing on
creating a full 2D game engine... but yeah, that's in the future.

So yeah, if you'd like to help me build this please support me.

Thanks,
Max.

[1]: https://github.com/haskell-ui/cef3-raw
[2]: https://github.com/fluffynukeit/bindings-cef3
[3]: https://salt.bountysource.com/teams/haskell-ui
[4]: 1LskxSUyLDLpMCBfUUnqcRT8mEFMW511Eq


PS. I have also created a reddit thread for this proposal here.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CEF3 bindings and game dev in Haskell

Maksymilian Owsianny
I... I'm not sure I follow...  What I am talking about in that example
is using the threepenny-gui[1]. And yes I believe that there is a bit
of javascript involved to manipulate the DOM, but the thing is that
the user (of that library) doesn't need to know this. The user writes
all of the logic in haskell.

Cheers,
Max.

[1]: https://hackage.haskell.org/package/threepenny-gui

On Fri, Mar 10, 2017 at 4:36 AM, MarLinn <[hidden email]> wrote:
On 2017-03-10 01:19, Maksymilian Owsianny wrote:
The thing about this solution is, its simplicity. You can use the
skills of front end (HTML/CSS) people to design your GUI, you can then
build it using something like threepenny and render it to texture
using cef. You can use the skills and tools that already exist.
I agree that this solution is sub optimal, that including a whole
browser inside your application can be a bit much. But I believe that
at least having an option will be much better for the community then
not.

Cheers,
Max.

Mhh… I get what you're getting at. But what can you really do with HTML+CSS without scripts? Ok, admittedly you can do a lot via crude tricks. You can create tabs, menus, pop-ups and loads of other stuff with pseudo-classes and pseudo-elements if you really want. But your average front-end-web-dev will not be used to using such tricks because on the web, everything is JS. And such hacks are an abuse of the tools anyway. So basically what you will get in practice with HTML+CSS are static pages or forms that you have to tie together somehow. So far so good, it's better than nothing. But we already have a really great, convenient library for static "pictures" with loads of existing back-ends – diagrams! Diagrams can even carry generic queries that you could fill with stuff like FRP endpoints. What's missing to fulfill your goal is a Parser that creates diagrams from HTML+CSS – which, of course, is basically a variation of one of the main purposes of a browser engine.

While that brings me back to the beginning, it seems to open a perspective for the future. Would you say it might be possible to start with chromium integration and then push it out again bit by bit by replacing it with the existing tools? For example would it be possible in the mid-term to "only" use the chromium parser but not the presentation layer, or vice-versa?

I feel there might even be a hidden path to a solution to our core web dev problems hidden here, but for now I fail to see specifics.

Cheers,
MarLinn


On Thu, Mar 9, 2017 at 11:53 PM, MarLinn <[hidden email]> wrote:

[Ack. Forgot to reply-to-list, and ran into the list's bad handling of gmail addresses again. So sorry for possible multi-posts.]

I agree that our GUI story is still bad.

But I don't understand what chromium has to do with either game dev or a good GUI story? If I want to write a real game, I use SDL2 bindings. If I want to write a website, I use something like Yesod. If I want to write browser games or "dynamic web sites", I throw JavaScript libraries at the walls, see what sticks, call it "modern coding", go to the liquor store and reconsider my life.

All joking aside, it's nice to see someone take a different path than usual, organization-wise. I do disagree on the technical path though. We already have a lot of bindings to several cross-platform frameworks and libraries, including QT, GTK, FLTK, and the aforementioned SDL2. But they suffer from impedance mismatch and lack of use and thus, community support. To solve that I would say what we need is a nice middle layer to translate functional thinking into framework models. We do have the diagrams package for describing static diagrams in a functional way, but it largely lacks dynamic behavior. (There's some support for animations, but it doesn't fill me with confidence.) We also have several attempts at FRP libraries for dynamic behavior, but few interactions with bindings. What is still missing is something like a dynamic version of diagrams that is based on one of these FRP libraries and that can work with one or several of the bindings as a back-end – possibly with a Haskell-side widget library. Possibly with css-like runtime styling And if we have that, yeah, we can add chromium bindings or whatever. Or write our own browser engine for fun. As far as I know there were several attempts but all fizzled out at some point.

My own favorite approach goes even further. I propose that many of the problems arise because the existing frameworks impose too many non-functional ideas, so the "purest" way to go forward would be a fresh framework on the basis of only SDL and reactive banana. That might sound like overkill for a simple non-game GUI, but is it really if the alternative is a whole browser? And what's more, that approach could be pursued in a way that might be turned into the one mentioned above later on.

What these approaches need is not more c tools or more cross-platform shenanigans, but some ideas how to handle a complex dynamic tangle of widget trees in a generic, functional fashion. Which to me has the added benefit of sounding much more like "fun". So I'm still working on that second approach whenever I have some time, but like yours, my time is limited.

Be assured, I don't want to diminish your work, it's probably useful to a certain subset of programmers. What I'm disputing is just if it's the single best way forward.

Cheers,
MarLinn

On 2017-03-09 22:52, Maksymilian Owsianny wrote:
Hey

I'm interested in making gamedev in haskell more viable and one thing
that I believe is missing in that part of the environment is a good
GUI story. So I decided to create proper bindings to cef3, you can
check out what I've done so far [here][1]. In this current version
I basically took the work done by Daniel Austin [here][2] split it
into parts to prevent my machine from dying from lack of memory and
packed it up with some nix glue for convenient usage. Now all this
doesn't look like much but it sill took me much more time then I'm
willing to admit in public. That's one of the eternal truths of
software development, that everything always takes an order of
magnitude more time then you suspect it would.

Anyway, what I would like to do here is add support for all platforms.
Create some nice scripts that help with automatizing building,
developing and deployment of code with this library for users.
Possibly write a script that automatically generates bindings from
c headers to bring this lib up to speed with the current version of
cef. Write some proper guides on using this lib for creating game GUI
or standalone desktop application. All of that is nice and well to
wish for but it is quite a lot of frankly not very fun work. If I had
to choose I would rather spend my time working on either something fun
or something that pays the rent, so usually at this point I stop and
walk away. But this time I decided to go about it differently, and ask
for community support. I have set up a BountySource campaign [here][3]
so I could focus on making this happen. Alternatively, if that's your
thing, I have set up a bitcoin address [4].

Depending on how well this campaign will go I'm also planing on
creating a full 2D game engine... but yeah, that's in the future.

So yeah, if you'd like to help me build this please support me.

Thanks,
Max.

[1]: https://github.com/haskell-ui/cef3-raw
[2]: https://github.com/fluffynukeit/bindings-cef3
[3]: https://salt.bountysource.com/teams/haskell-ui
[4]: 1LskxSUyLDLpMCBfUUnqcRT8mEFMW511Eq


PS. I have also created a reddit thread for this proposal here.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CEF3 bindings and game dev in Haskell

Joachim Durchholz
In reply to this post by MarLinn
Am 10.03.2017 um 00:53 schrieb MarLinn:
> If I want to
> write browser games or "dynamic web sites", I throw JavaScript libraries
> at the walls, see what sticks, call it "modern coding", go to the liquor
> store and reconsider my life.

YMMD!

> My own favorite approach goes even further. I propose that many of the
> problems arise because the existing frameworks impose too many
> non-functional ideas, so the "purest" way to go forward would be a fresh
> framework on the basis of only /SDL/ and /reactive banana/. That might
> sound like overkill for a simple non-game GUI,

There is no such thing as a simple GUI, game or otherwise.
Look at whatever GUI toolkit you like, be it QT, Java's approaches, or
WWW apps: It took *two decades* (on the average) to get from "barely
workable" to "simple commercial form filling is actually simple for the
developer".
I looked into the all-new Vaadin 8 release just yesterday, and now,
after 15 years of development, they're proud to add type safety to some
APIs. And that's not because they don't know what they're doing, Vaadin
is considered one of the best frameworks for building cross-platform
commercial applications.

So: Whatever you're doing GUI-wise, /nothing/ is going to be overkill.

(For cross-platform stuff, you need expertise in SDL, GTK+, or whatever
you use on the desktop, Javascript in Browsers, and about the specific
shenanigans for both Android and IOS for which most people use
Javascript anyway.)

> Be assured, I don't want to diminish your work, it's probably useful to
> a certain subset of programmers. What I'm disputing is just if it's the
> single best way forward.

Even then it can be be useful lessons learned for the full approach I think.

Regards,
Jo
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CEF3 bindings and game dev in Haskell

MarLinn
In reply to this post by Maksymilian Owsianny
On 2017-03-10 07:03, Maksymilian Owsianny wrote:
I... I'm not sure I follow...  What I am talking about in that example
is using the threepenny-gui[1]. And yes I believe that there is a bit
of javascript involved to manipulate the DOM, but the thing is that
the user (of that library) doesn't need to know this. The user writes
all of the logic in haskell.

Sorry to confuse. Ok, let's ask in a different way.
Simplifying massively, a browser engine seems to offer four things a GUI can use: A set of parsers, a complex model of the interface layout, a set of tools to render said model, and a system to get a stream of meaningful user events related to the model. There's more but let's pretend that's all that's needed. Let's further say you had implemented all the bindings and tools you're imagining. Would it be possible to replace one of the four parts with a pure Haskell solution without changing the others? In other words, will it be possible to merge the engine into a bigger tool system as a set of tools, or will it likely stay a monolith?

Cheers,
MarLinn

On Fri, Mar 10, 2017 at 4:36 AM, MarLinn <[hidden email]> wrote:
On 2017-03-10 01:19, Maksymilian Owsianny wrote:
The thing about this solution is, its simplicity. You can use the
skills of front end (HTML/CSS) people to design your GUI, you can then
build it using something like threepenny and render it to texture
using cef. You can use the skills and tools that already exist.
I agree that this solution is sub optimal, that including a whole
browser inside your application can be a bit much. But I believe that
at least having an option will be much better for the community then
not.

Cheers,
Max.

Mhh… I get what you're getting at. But what can you really do with HTML+CSS without scripts? Ok, admittedly you can do a lot via crude tricks. You can create tabs, menus, pop-ups and loads of other stuff with pseudo-classes and pseudo-elements if you really want. But your average front-end-web-dev will not be used to using such tricks because on the web, everything is JS. And such hacks are an abuse of the tools anyway. So basically what you will get in practice with HTML+CSS are static pages or forms that you have to tie together somehow. So far so good, it's better than nothing. But we already have a really great, convenient library for static "pictures" with loads of existing back-ends – diagrams! Diagrams can even carry generic queries that you could fill with stuff like FRP endpoints. What's missing to fulfill your goal is a Parser that creates diagrams from HTML+CSS – which, of course, is basically a variation of one of the main purposes of a browser engine.

While that brings me back to the beginning, it seems to open a perspective for the future. Would you say it might be possible to start with chromium integration and then push it out again bit by bit by replacing it with the existing tools? For example would it be possible in the mid-term to "only" use the chromium parser but not the presentation layer, or vice-versa?

I feel there might even be a hidden path to a solution to our core web dev problems hidden here, but for now I fail to see specifics.

Cheers,
MarLinn


On Thu, Mar 9, 2017 at 11:53 PM, MarLinn <[hidden email]> wrote:

[Ack. Forgot to reply-to-list, and ran into the list's bad handling of gmail addresses again. So sorry for possible multi-posts.]

I agree that our GUI story is still bad.

But I don't understand what chromium has to do with either game dev or a good GUI story? If I want to write a real game, I use SDL2 bindings. If I want to write a website, I use something like Yesod. If I want to write browser games or "dynamic web sites", I throw JavaScript libraries at the walls, see what sticks, call it "modern coding", go to the liquor store and reconsider my life.

All joking aside, it's nice to see someone take a different path than usual, organization-wise. I do disagree on the technical path though. We already have a lot of bindings to several cross-platform frameworks and libraries, including QT, GTK, FLTK, and the aforementioned SDL2. But they suffer from impedance mismatch and lack of use and thus, community support. To solve that I would say what we need is a nice middle layer to translate functional thinking into framework models. We do have the diagrams package for describing static diagrams in a functional way, but it largely lacks dynamic behavior. (There's some support for animations, but it doesn't fill me with confidence.) We also have several attempts at FRP libraries for dynamic behavior, but few interactions with bindings. What is still missing is something like a dynamic version of diagrams that is based on one of these FRP libraries and that can work with one or several of the bindings as a back-end – possibly with a Haskell-side widget library. Possibly with css-like runtime styling And if we have that, yeah, we can add chromium bindings or whatever. Or write our own browser engine for fun. As far as I know there were several attempts but all fizzled out at some point.

My own favorite approach goes even further. I propose that many of the problems arise because the existing frameworks impose too many non-functional ideas, so the "purest" way to go forward would be a fresh framework on the basis of only SDL and reactive banana. That might sound like overkill for a simple non-game GUI, but is it really if the alternative is a whole browser? And what's more, that approach could be pursued in a way that might be turned into the one mentioned above later on.

What these approaches need is not more c tools or more cross-platform shenanigans, but some ideas how to handle a complex dynamic tangle of widget trees in a generic, functional fashion. Which to me has the added benefit of sounding much more like "fun". So I'm still working on that second approach whenever I have some time, but like yours, my time is limited.

Be assured, I don't want to diminish your work, it's probably useful to a certain subset of programmers. What I'm disputing is just if it's the single best way forward.

Cheers,
MarLinn

On 2017-03-09 22:52, Maksymilian Owsianny wrote:
Hey

I'm interested in making gamedev in haskell more viable and one thing
that I believe is missing in that part of the environment is a good
GUI story. So I decided to create proper bindings to cef3, you can
check out what I've done so far [here][1]. In this current version
I basically took the work done by Daniel Austin [here][2] split it
into parts to prevent my machine from dying from lack of memory and
packed it up with some nix glue for convenient usage. Now all this
doesn't look like much but it sill took me much more time then I'm
willing to admit in public. That's one of the eternal truths of
software development, that everything always takes an order of
magnitude more time then you suspect it would.

Anyway, what I would like to do here is add support for all platforms.
Create some nice scripts that help with automatizing building,
developing and deployment of code with this library for users.
Possibly write a script that automatically generates bindings from
c headers to bring this lib up to speed with the current version of
cef. Write some proper guides on using this lib for creating game GUI
or standalone desktop application. All of that is nice and well to
wish for but it is quite a lot of frankly not very fun work. If I had
to choose I would rather spend my time working on either something fun
or something that pays the rent, so usually at this point I stop and
walk away. But this time I decided to go about it differently, and ask
for community support. I have set up a BountySource campaign [here][3]
so I could focus on making this happen. Alternatively, if that's your
thing, I have set up a bitcoin address [4].

Depending on how well this campaign will go I'm also planing on
creating a full 2D game engine... but yeah, that's in the future.

So yeah, if you'd like to help me build this please support me.

Thanks,
Max.

[1]: https://github.com/haskell-ui/cef3-raw
[2]: https://github.com/fluffynukeit/bindings-cef3
[3]: https://salt.bountysource.com/teams/haskell-ui
[4]: 1LskxSUyLDLpMCBfUUnqcRT8mEFMW511Eq


PS. I have also created a reddit thread for this proposal here.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CEF3 bindings and game dev in Haskell

Joachim Durchholz
Am 10.03.2017 um 13:05 schrieb MarLinn:
> Simplifying massively, a browser engine seems to offer four things a GUI
> can use: A set of parsers, a complex model of the interface layout, a
> set of tools to render said model, and a system to get a stream of
> meaningful user events related to the model. There's more but let's
> pretend that's all that's needed. Let's further say you had implemented
> all the bindings and tools you're imagining. Would it be possible to
> replace one of the four parts with a pure Haskell solution without
> changing the others?

Not for the usual browser engines, not easily, and not very usefully
either because of interdependencies.
I.e. any Haskell solution that replaced just one part would have its
design massively constrained by having to server all the other parts.

I think Maksymilian is targetting the usual design: Use some Javascript
to establish whatever GUI model you want to see implemented (vanilla
HTML elements usually aren't good enough), use some more Javascript to
establish a smooth communication mechanism between backend and frontend,
and write a library on the backend side that drives the whole thing.
It's tremendously complicated, but it's well-isolated because the
program sees only a socket interface through which it drives the GUI and
receives events - which is pretty similar to any existing GUI toolkit
where you have an outgoing interface (function calls) and a stream of
incoming events.
I wouldn't have recommended doing such a thing a decade ago, but this
approach has become pretty well-understood so you can expect to see
solutions to any architectural decisions, though maybe a tad "too
imperative" for the Haskellish mind so you may want to design the socket
interface to make it easier to deal with on the Haskell side.

BTW on the Javascript side, you can do thinks in a pretty functional
mindset.
People may not be doing it because they do not have enough FPL
experience, so there's enough interesting stuff to do on that side.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Loading...