<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 2017-03-10 07:03, Maksymilian Owsianny wrote:<br>
<blockquote
cite="mid:CAJP_up51BS2LK=M+4aipCi3MojvRMhu+Um65RZUPyX5fp54bHw@mail.gmail.com"
type="cite">
<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.
</pre>
</div>
</blockquote>
<br>
Sorry to confuse. Ok, let's ask in a different way.<br>
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?<br>
<br>
Cheers,<br>
MarLinn<br>
<br>
<blockquote
cite="mid:CAJP_up51BS2LK=M+4aipCi3MojvRMhu+Um65RZUPyX5fp54bHw@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<div class="gmail_quote">On Fri, Mar 10, 2017 at 4:36 AM,
MarLinn <span dir="ltr"><<a moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true" href="https://github.com/haskell-ui/cef3-raw" target="_blank">https://github.com/haskell-ui/<wbr>cef3-raw</a>
[2]: <a moz-do-not-send="true" href="https://github.com/fluffynukeit/bindings-cef3" target="_blank">https://github.com/fluffynukei<wbr>t/bindings-cef3</a>
[3]: <a moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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>
______________________________<wbr>_________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
<a moz-do-not-send="true" 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>
Only members subscribed via the mailman list are allowed to post.
</blockquote></div>
</div>
</blockquote>
</body></html>