About Slate and GUI

[Rastislav Kassak]

Hi,

what about to utilize liboop? It aims to provide the main event loop
compatible with any GUI loop, network server, system signals,
whatever...

On 10/25/05, Tony Garnock-Jones <tonyg at lshift.net> wrote:
> Hi Paul,
>
> Paul Dufresne wrote:
> > But now that I
> > know that GTK+ is LGPL, have signals much like QT, is now using CAIRO
> > graphics library, my
> > choice is made, and I prefer GNOME (GTK+).
>
> Wow, I really strongly prefer Qt - but not because Qt is good, although
> when I've coded for it it hasn't been too bad, but because GTK+ is
> staggeringly awful.
>
> > But I now feel that SDL is a bit too
> > low-level to serve as
> > the level under DUIM-morphic code. I now have the feeling GTK+ would be
> > more appropriate.
>
> I really disagree! GTK+ has one of the most horrible object-models I've
> ever used, and it's not at all shy about forcing you into it. I wrapped
> both GTK+ 1.2 and 2.0 for the Chicken Scheme compiler, and it was quite
> a painful process. (Mostly because GTK+ is very inconsistent and
> incomplete in the metadata it exposes.)
>
> Cairo, on the other hand, seems pretty good.
>
> > It is not so obvious to me (as it seems to be for Brian) why the
> > concurrency have to be
> > implemented in Slate, before working on the GUI code.
>
> Yes, this is the main problem. Without a framework for (something
> resembling) multi-threaded I/O, there is no way of mediating the many
> (pseudo-)parallel operations that together make up a functioning GUI.
>
> The main piece missing is an outer driver loop that calls select() to
> wait for I/O and timeouts, and dispatches I/O events and timeout
> callbacks. By itself, this isn't so tricky - but integrating with SDL's
> event sources as well adds a few wrinkles.
>
> Of course, given such a driver, having actual real concurrency is kind
> of optional, although having call-with-current-continuation would
> obviously be very nice :-)
>
> A few months ago (almost a year!) I implemented, in Scheme, a Slate-like
> language, and I got as far as implementing an SDL + SDL_net based user
> interface before deciding I'd learnt enough. The key idea is to avoid
> using SDL's SDL_WaitEvent, and instead to roll one's own from:
>
>   - SDL_PeepEvents
>   - a Slate-implemented Timer queue (heap)
>   - a customisable "delay" function
>
> The delay function is called when SDL-proper decides nothing has
> happened. The time-to-next-timer-event is retrieved from the timer
> queue, and passed in to the delay function. In simple cases, the delay
> function can be SDL_Delay, but to integrate with SDL_net, the delay
> function should be the piece of code that checks for socket activity,
> i.e. that calls select().
>
> Tony
>
>