<div dir="ltr"><pre>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]: <a href="https://hackage.haskell.org/package/threepenny-gui" target="_blank">https://hackage.haskell.org/<wbr>package/threepenny-gui</a>
</pre></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 10, 2017 at 4:36 AM, MarLinn <span dir="ltr"><<a href="mailto:monkleyon@gmail.com" target="_blank">monkleyon@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><span class="">
    On 2017-03-10 01:19, Maksymilian Owsianny wrote:<br>
    <blockquote type="cite">
      <div dir="ltr">
        <pre>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.
</pre>
      </div>
    </blockquote>
    <br></span>
    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.<br>
    <br>
    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?<br>
    <br>
    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.<br>
    <br>
    Cheers,<br>
    MarLinn<div><div class="h5"><br>
    <br>
    <blockquote type="cite">
      <div class="gmail_extra">
        <div class="gmail_quote">On Thu, Mar 9, 2017 at 11:53 PM,
          MarLinn <span dir="ltr"><<a href="mailto:monkleyon@gmail.com" target="_blank">monkleyon@gmail.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div text="#000000" bgcolor="#FFFFFF">
              <div class="m_4955662848023495084m_-8882571256972453389moz-text-html" lang="x-unicode">
                <p>[Ack. Forgot to reply-to-list, and ran into the
                  list's bad handling of gmail addresses again. So sorry
                  for possible multi-posts.]<br>
                </p>
                <span>
                  <p>I agree that our GUI story is still bad.</p>
                  <p>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 <i>SDL2</i> bindings. If I
                    want to write a website, I use something like <i>Yesod</i>.
                    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.<br>
                  </p>
                  <p>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 <i>diagrams</i>
                    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 <i>diagrams</i> 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.<br>
                  </p>
                  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 <i>SDL</i> and <i>reactive
                    banana</i>. 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.<br>
                  <br>
                  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.<br>
                  <br>
                  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.<br>
                  <br>
                  Cheers,<br>
                  MarLinn<br>
                  <br>
                  <div class="m_4955662848023495084m_-8882571256972453389moz-cite-prefix">On
                    2017-03-09 22:52, Maksymilian Owsianny wrote:<br>
                  </div>
                </span>
                <blockquote type="cite">
                  <div>
                    <div class="m_4955662848023495084h5">
                      <div dir="ltr">
                        <pre>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]: <a href="https://github.com/haskell-ui/cef3-raw" target="_blank">https://github.com/haskell-ui/<wbr>cef3-raw</a>
[2]: <a href="https://github.com/fluffynukeit/bindings-cef3" target="_blank">https://github.com/fluffynukei<wbr>t/bindings-cef3</a>
[3]: <a href="https://salt.bountysource.com/teams/haskell-ui" target="_blank">https://salt.bountysource.com/<wbr>teams/haskell-ui</a>
[4]: 1LskxSUyLDLpMCBfUUnqcRT8mEFMW5<wbr>11Eq


</pre>
          <pre>PS. I have also created a reddit thread for this proposal <a href="https://www.reddit.com/r/haskell/comments/5yi1b7/cef3_bindings_and_game_dev_in_haskell/" target="_blank">here</a>.
</pre>
        </div>
        

        <fieldset class="m_4955662848023495084m_-8882571256972453389mimeAttachmentHeader"></fieldset>
        

        </div></div><span><pre>______________________________<wbr>_________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
<a class="m_4955662848023495084m_-8882571256972453389moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/haskell-caf<wbr>e</a>
Only members subscribed via the mailman list are allowed to post.</pre>
      </span></blockquote>
      

    </div>
  </div>


______________________________<wbr>_________________

Haskell-Cafe mailing list

To (un)subscribe, modify options or view archives go to:

<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/haskell-caf<wbr>e</a>

Only members subscribed via the mailman list are allowed to post.
</blockquote></div>
</div>



</blockquote>
</div></div></div><br>______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
Only members subscribed via the mailman list are allowed to post.<br></blockquote></div><br></div>