From: ludo@gnu.org (Ludovic Courtès)
To: Panicz Maciej Godek <godek.maciek@gmail.com>
Cc: guile-user@gnu.org
Subject: Re: procedure-source availability
Date: Thu, 04 Oct 2012 18:16:32 +0200 [thread overview]
Message-ID: <87r4pecivz.fsf@gnu.org> (raw)
In-Reply-To: <CAMFYt2a5zE1Dk2LYmNBy2fx59bcO-Xbn-4nJc3eu74TqCYZS1A@mail.gmail.com> (Panicz Maciej Godek's message of "Tue, 2 Oct 2012 21:29:34 +0200")
Hi,
Panicz Maciej Godek <godek.maciek@gmail.com> 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’.
prev parent reply other threads:[~2012-10-04 16:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-23 19:05 procedure-source availability Panicz Maciej Godek
2012-09-30 20:11 ` Panicz Maciej Godek
2012-10-01 3:40 ` Mark H Weaver
2012-10-01 16:31 ` Panicz Maciej Godek
2012-10-02 14:06 ` Ludovic Courtès
2012-10-02 19:29 ` Panicz Maciej Godek
2012-10-03 1:03 ` Daniel Hartwig
2012-10-03 16:27 ` Panicz Maciej Godek
2012-10-04 19:40 ` Ludovic Courtès
2012-10-07 0:07 ` Panicz Maciej Godek
2012-10-07 20:36 ` Ludovic Courtès
2012-10-08 20:11 ` Panicz Maciej Godek
2012-10-08 17:57 ` Mark H Weaver
2012-10-04 16:16 ` Ludovic Courtès [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r4pecivz.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=godek.maciek@gmail.com \
--cc=guile-user@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).