[Haskell-cafe] CEF3 bindings and game dev in Haskell

MarLinn monkleyon at gmail.com
Fri Mar 10 04:36:08 UTC 2017

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.


> On Thu, Mar 9, 2017 at 11:53 PM, MarLinn <monkleyon at gmail.com 
> <mailto:monkleyon at gmail.com>> 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
>>     <https://github.com/haskell-ui/cef3-raw>
>>     [2]:https://github.com/fluffynukeit/bindings-cef3
>>     <https://github.com/fluffynukeit/bindings-cef3>
>>     [3]:https://salt.bountysource.com/teams/haskell-ui
>>     <https://salt.bountysource.com/teams/haskell-ui>
>>     [4]: 1LskxSUyLDLpMCBfUUnqcRT8mEFMW511Eq
>>     PS. I have also created a reddit thread for this proposalhere
>>     <https://www.reddit.com/r/haskell/comments/5yi1b7/cef3_bindings_and_game_dev_in_haskell/>.
>>     _______________________________________________
>>     Haskell-Cafe mailing list
>>     To (un)subscribe, modify options or view archives go to:
>>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>     <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
>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
>     Only members subscribed via the mailman list are allowed to post. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170310/e27de0de/attachment-0001.html>

More information about the Haskell-Cafe mailing list