Snow FAQ - Fictionally Asked Questions

That is, questions I'd like to be asked. Snow has too few users for "Frequently" to mean something relevant ;-)

General questions about Snow
Questions for Java programmers
Questions for Lisp programmers
1. How does Snow compare to other mature Common Lisp GUI toolkits, like LTK or Cells-GTK?
Installing and using Snow
1. Ok, Snow is great! Now, how do I use it in my application?

General questions about Snow

So, what is Snow?

Snow is a declarative language (DSL) targeted at building graphical user interfaces based on the Java Swing GUI library. It is somewhat similar in spirit to XUL or SwiX^ml, while adopting a unique approach which has many advantages over XML + scripting languages. Snow is a fully interactive language - you can prototype your GUI at the read-eval-print loop and see the results immediately, without a lengthy batch compilation phase.

Which technologies is Snow built upon?

Snow is written in a combination of Java and Common Lisp (particularly its implementation ABCL, which runs on the JVM). It uses MiG Layout for declarative, CSS-like component layout, JGoodies Binding for data binding (communication between the GUI and the application code) to Java objects, and a slightly modified version of Ken Tilton's Cells library to do the same thing (and more) with Lisp.
Snow can be thought of as a GUI extension for ABCL, and indeed it provides the GUI counterparts of some of ABCL's facilities - the REPL, a minimal debugger, and the inspector - although the main objective of Snow is to be a GUI library, and these add-ons exist more as examples of what Snow can do.

Who is Snow targeted at?

Snow is meant to be useful both to Lisp developers looking for an easy, cross-platform GUI solution, and Java developers in search of an easier way to write Swing code without sacrificing too much flexibility, as it is often the case with GUI editors. It can be used in a Lisp application without writing any Java, and it can be used in a Java application writing only a minimal amount of Lisp code (that is, the GUI code itself and little or no else). Of course, writing in a mix of the two languages might be necessary if you want to do something advanced, like writing your custom components in Java and integrating them with Snow. This practice is likely to be less frequent than when you write Swing code in Java, because Snow makes it easier to use aggregation rather than inheritance for component creation. Still, you may need to, e.g., use third-party components, or override some method in your custom component - in this case you need to write a little Lisp glue code to make Snow aware of your components.

Am I really forced to use Swing if I use Snow? What about SWT or other Java GUI libraries?

While Snow's API follow quite closely those of Swing (in terms of names of components, properties, layouts, ...), some care has been taken to make it possible to plug in other GUI backends. No other backend besides the Swing one currently exists, and the author has not enough time and expertise in SWT to create an SWT one, but it should be quite possible in principle, with the necessary adaptations.

What is the current status of Snow? How much of Swing is covered?

I consider Snow's core to be quite stable, although young. Coverage of Swing is poor, only a bunch of components are supported, and even those only have few properties mapped. This means Snow at this stage is too incomplete to be used in production; it can only showcase the basic ideas behind it. However, I'm slowly working on adding more components: if you're interested in one in particular, drop me a line, I'll be happy to prioritize work on it.

Which license is Snow distributed under?

The same license as ABCL and GNU Classpath, that is, GNU GPL + the classpath exception. Basically this means you can link your code to Snow without having to release it under the GPL. The GPL still applies to modifications to Snow itself.

Questions for Java programmers

The following questions are more likely to interest Java programmers. You may skip them if you aren't interested in Java, and/or you already know Lisp.

Common Lisp? What the heck is that?

The ANSI standard Common Lisp is a language in the Lisp family, one of the oldest families of programming languages still in use. It is a multi-paradigm, dynamic language with very regular syntax and advanced features that make it great for prototyping and exploration of new ideas, yet solid and fast enough to build big systems. Common Lisp can be both interpreted and compiled. Thanks to the work of Peter Graves and the people who took care of developing ABCL after Peter stopped working on it, Common Lisp is today one of the languages that can run on the Java Virtual Machine.

Uhm, and what does Snow code look like?

Here is an example:

(frame (:title "Snow Example" :visible-p t)
  (panel (:layout "wrap")
    (button :text "Hello, world!"
            :on-action (lambda (event)
                         (print "Hello, world!")))))

Whoa! Why all those ugly parentheses?

That's Lisp, baby! If it looks alien, you can just pretend it's XML in disguise: imagine the example above like

<frame title="Snow Example" visible="true">
  <panel layout="wrap">
    <button text="Hello, world!"
            on-action="function(event) { print('Hello, world!'); }" />
  </panel>
</frame>

Then why not use XML like everyone else?

While Snow (and to some extent Lisp) is structurally similar to XML due to its tree-based form, the similarity ends here.
XML is a markup language meant to describe documents or structured data. It *can* be perverted enough to use it as the syntax of a programming language (see X#), but the results are not exactly pretty (in this FAQ author's humble opinion).
Lisp, on the other hand, has been a full programming language from day one. See how in the fictional XML translation of Snow above a pseudo-JavaScript in an XML attribute was used to define an action, while in the original example an anonymous Lisp function was used - which is not a string to be fed to some external interpreter, but real Lisp code, which can e.g. be factored out in a function, compiled, easily tested in isolation and so on.
Consider also that you can mix "regular" Lisp code with Snow with no problems, thus getting much more dynamicity in building your GUI:

(label :text (if (some-condition-holds) "Yes!" "No!"))

(list-widget :model (make-list-model (generate-my-list-model-at-runtime)))

(dotimes (i 42) ;creates 42 labels with the text "Label No. n".
  (label :text (str "Label No. " i)))

and so on. You can't do that with XML unless you have a mechanism like e.g. JSP taglibs, and even that is not as easy and powerful. Furthermore, Lisp supports and encourages interactive programming: you can try and test your code while you write it, without recompiling, restarting, or redeploying anything.

Questions for Lisp programmers

The following questions are more likely to interest Lisp programmers. You may skip them if you're only interested in Java.

How does Snow compare to other mature Common Lisp GUI toolkits, like LTK or Cells-GTK?

Snow is much younger, and much more incomplete, than most other GUI toolkits available in Common Lisp. At this stage, I'd suggest that you use Snow only if you need a CL GUI app that closely interoperates with Java, or if you need your GUI to run on all the platforms the JVM runs on and you can't use a CL implementation (besides ABCL) that runs on all those platforms. That said, Snow already supports Cells (although it needs a modified version - distributed together with it - that can run on ABCL).

Installing and using Snow

Ok, Snow is great! Now, how do I use it in my application?

Refer to the tutorial for installation instructions and a brief explanation of Snow.