[Haskell-cafe] CEF3 bindings and game dev in Haskell
maksymilian.owsianny at gmail.com
Fri Mar 10 06:03:12 UTC 2017
I... I'm not sure I follow... What I am talking about in that example
is using the threepenny-gui. And yes I believe that there is a bit
the user (of that library) doesn't need to know this. The user writes
all of the logic in haskell.
On Fri, Mar 10, 2017 at 4:36 AM, MarLinn <monkleyon at gmail.com> 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
> 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> 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
>> 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
>> 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.
>> On 2017-03-09 22:52, Maksymilian Owsianny wrote:
>> 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]. In this current version
>> I basically took the work done by Daniel Austin [here] 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]
>> so I could focus on making this happen. Alternatively, if that's your
>> thing, I have set up a bitcoin address .
>> 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.
>> : https://github.com/haskell-ui/cef3-raw
>> : https://github.com/fluffynukeit/bindings-cef3
>> : https://salt.bountysource.com/teams/haskell-ui
>> : 1LskxSUyLDLpMCBfUUnqcRT8mEFMW511Eq
>> PS. I have also created a reddit thread for this proposal here <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
>> 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:
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe