guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: procedure-source availability


From: Ludovic Courtès
Subject: Re: procedure-source availability
Date: Thu, 04 Oct 2012 18:16:32 +0200
User-agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux)

Hi,

Panicz Maciej Godek <address@hidden> skribis:

> Well, the idea for now is that the associated .spec file containing
> the state of GUI is loaded on startup, and the state of the
> interpreter is dumped to that file on exit (or at GUI's request).
> Viewing the file will obviously be an option (for the curious user),
> but any modifications would probably be overwritten eventually (unless
> the file is write-protected).
>
> This approach allows avoiding the design of any specific file format
> to store information about the GUI -- everything is just scheme. The
> only requirement is that all used object (images etc.) can be dumped
> to scheme expressions, evaluation of which would re-create them. (This
> isn't yet fully implemented, but I'm on a good way)

This sounds like an interesting approach.

Instead of storing actual code that recreates the GUI, how about storing
high-level declarations that describe that GUI?

For instance, Ratpoison & co. store declarations like this:

  (frame :number 0 :x 0 :y 0 :width 1320 :height 1200 :screenw 1920
         :screenh 2000
         :window 12582930 :last-access 6 :dedicated 0)

They could instead store actual code (say, a procedure that creates a
window of the right size, using the X11 API, etc.).  However, the
advantage of declarative code is that it’s easy to maintain
backward-compatibility (compared to regular API churn), and it also
allows for portability between implementations (for instance, Ratpoison
vs. StumpWM vs. RPX.)

And, it’s also easily serialized.

Hope I’m not too off-topic.  ;-)

Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]