[Appendix] All Else is Not Enough

Taking a general outlook on CLIM, we can see that it uses CLOS, which is a very powerful OO system. A big part of CLOS flexibility comes from MetaObject Protocol, which is quite complicated, but it works. And yet, it's a classic OO system in the sense that classes and objects are separate entities.

Garnet, for instance, used KR which is a Prototype OO system. I discuss Knowledge-Representation in The Power of Structure.

If you don't have prototype OO, you will likely have kludges-by-design such as this one:

For example, a pushbutton has an "activate" callback method which is invoked when its button is pressed. For this particular callback, a method named activate-callback is invoked by default, and a CLIM programmer can provide a specialized method to implement application-specific behavior for a subclassed button-pane. But except in the case where the programmer needs a lot of buttons with related behavior, creating a subclass for changing a single specific callback is not economical. Hence upon gadget creation, the programmer can specify an alternative callback method for all callbacks available. By providing the :activate-callback initarg, the programmer can change the callback to any regular or generic function.⁸ A Guided Tour of CLIM (2006)

CLOS subclassing is a chore, indeed.

Lack of prototypes invites a flexibility penalty and can't be easily cured.

And since I have mentioned Garnet, I might as well note right away that CLIM is missing any sort of dataflow mechanism for its slots. Lack of dataflow is a major reason why so much of CLIM applications code is so imperative and riddled with setf's and callbacks. I won't say much else about it here.

Hey, look at this gem for no reason whatsoever:

The drag-callback method resets the background of drag-feedback-pane and delegates its redrawing to redisplay-frame-pane, while value-change-callback does the same for the frame’s current color pane.⁸ A Guided Tour of CLIM (2006)

A very important footnote.⁹ At this point I am starting to feel like I am beating down on a child. Some of you may even wonder why not simply say "CLIM sucks" and be done with it. Well. I didn't find a good resource that gives CLIM a critical overview, and since it's one of the two maintained non-proprietary CL-centric GUI framework as of the day of writing, it would have been strange had I just skipped it. Since I have already started, I might as well give a shot at the rest.

Before we continue, I want to say something actually good about CLIM. And maybe try to explain to the folks at home how it works, a little. And not that I would know how it works myself, of course, but I think I have managed to grasp a few grains of its basic working principles from all the pain of reading some of the works dedicated to it.

The good thing is that the interface in CLIM is presentation-based. Or maybe the good thing is not that it's presentation based, per se, but that it links objects on the screen to real Lisp objects.

Now, all those Lisp objects will have a type. You can then write a method of interaction for that type, and that method will apply to all objects of that type. That may be input, or modification and what have you. That's how you interact with objects in CLIM.

For instance, you may create a command that, say, takes an integer and a circle. In the command line, you can now type the name of the command and then click on something on the screen that represents an integer (the visual representation may be anything, say a line of length 10, which represents integer 10), and then click on something that represents a circle, and say, the result of that operation will be that circle radius will get that much larger by that integer amount (represented by the line).

Everything you draw (via usual means) will automatically be an object that you can inspect and touch and interact with. So, visual pixels on the screen have semantics. That's pretty nice.

The way presentations are accomplished is through output records. And since presentations are about all the good things I know about CLIM, let's discuss those output records now.

Now, if you want to create an application, you define an application frame.

Within that frame you layout your panes. A pane is where you draw stuff.

What you draw gets captured into something called output records. CLIM will do the actual rendering from those output records.

If your pane gets resized or scrolled, CLIM will automatically draw all the stuff based on these output records.

The programmer can change these records for the benefit of incremental redisplay: CLIM will only render the change (and redraw the effected surroundings for correctness).

Output records also hold all the information necessary to enable interactivity and presentations.

Output records may seem like a great idea: they enable so much!

But I think this is mistaken. Output records serve as a rather useless layer of indirection between objects and their semantic presentation on screen.

Look at it this way.

So, you have a tree of panes/gadgets within an application-frame. Well, is this tree not enough, is it somehow not powerful enough to represent itself? Why should it be duplicated as a tree of output records?

Capturing the draw operations is not necessary: you can represent all your draw output simply as a part of that tree.

Want to draw ten interactive lines and circles? Make each of them a part of the tree as gadgets.

Want to draw ten million lines? Define your own containers (which could be of rather a general nature, such as arrays) and teach those containers how to handle input. You don't have to be locked to a branch in the tree of output records.

Each branch and node can itself decide how to handle the input, how to draw itself, all in its own context and precisely how it wants to. The parent node can do the optimizing/culling part.

None of it has to be any harder or less efficient than maintaining a bizarre overgrown body-double of your original tree. In fact, it would be simpler, while yielding more control and efficiency.

Output records don't really simplify anything. Anything you can do with an output duplicate, you can obviously just as well do with a tree of your original panes/gadgets, and have more control when doing so, without any overhead.

Output records, for what they're worth, act as a caching mechanism for the element layout, and that mechanism is an ingrained fixture of CLIM experience. And one thing to know about caching: where there's caching, there's cache invalidation. You can't meaningfully bypass it because output records are coupled with the interactive capabilities of the system (i.e. a presentation is a type of an output record).

One of the two hard problems of computer science is enabled by default, and you can't bypass it. You read that right. Layouts get invalidated all the time. Programs are meant to be dynamic, especially UIs. Caching them is just not very reasonable, and when it is, it should be adjustable without having to compromise.

Output records may seem like a good abstraction, but they aren't. They prevent you from freely treating your interface tree as a data structure, taking up a part of the responsibility upon themselves. This latter point is exacerbated by the fact that there doesn't even seem to be a notion of tree node in CLIM. Let's see what it has to offer instead.

Let's take a look at a few definitions from the LispWorks CLIM Guide¹⁰ LispWorks CLIM Guide:

Panes

CLIM panes are similar to the gadgets or widgets of other toolkits. They can be used to compose the top-level user interface of applications as well as auxiliary components such as menus and dialogues.

Gadgets

Gadgets are panes that implement such common toolkit components as push buttons or scroll bars.

Say, what's the conceptual difference between panes and gadgets?

Why can't a push button be a push-button that inherits from pane and implements everything it needs? Why do these entities have to have a separate name for them?

And then, apparently, there's a notion of adaptive panes:

A subset of the abstract panes, the adaptive panes, have been defined to integrate well across all CLIM operating platforms.

Since gadgets inherit from panes, does this mean there are adaptive and non-adaptive gadgets too?

Damned if I know.

Now, it would seem that an application frame would just be a window in your OS. But get this:

Frames can be displayed as either top-level windows or regions embedded within the space of the user interfaces of other applications.

Application Frame

An application frame, or simply a frame, is the locus of all application-specific knowledge. It is a physical, bordered object that is composed of smaller, individually functioning parts, called panes.

So, why can't a pane or gadget be the locus of all application-specific knowledge? Why does application data need to be conceptually stored within the root element of the tree, essentially making it global with respect to the nodes of that tree?

Why not have just two concepts: a gadget and a window?

My answers are: I don't know. I just don't know.

The customization process in CLIM relies on dynamic variables. That's not ideal.

Here's some random, fairly typical draw call from McCLIM code base (as a part of some handle-repaint method):

(draw-line* pane x1 y1 x2 y1 :ink +dark-grey+)

To change the color, you would have to recompile the parent drawing code. Instead, we could imagine, something like this would also do the trick:

(let ((*ink* +dark-grey+)) (draw-line* pane x1 y1 x2 y1)).

Where instead of +dark-grey+, the class with this draw method would store a variable that the user can access. That would eliminate the need for recompilation.

But that won't really work: if you throw another shape into the mix, like a circle which you want to shade blue instead of dark grey, a shared *ink* customization won't work.

Each shape class would need its own ink variable for something like that, and that variable would have to be picked up by the draw call automatically.

You could try walking output records and setting the colors by hand, but I don't really know if output records allow it. If they were a part of the tree gadget/pane/frame tree, it wouldn't have been a question.

Even if you can do it by directly modifying the output records, though, the point about class-specific settings still stands.

There's also no kind of advice facility, as far as I can tell (the :before and :after methods can be defined only once for a generic function).

The system is only flexible for the programmer of an application (and even then, to a degree). For the end user – not so much.

Sheets, grafts, windows, ports, panes, mediums, managers, streams, gadgets, frames…

All these terms have some defined meaning and purpose, but you inadvertently begin to wonder how many of them actually contribute to the utility within the realm of the problem at hand, and how many are artificial demarcations designed to make your life harder than it has to be. Of course, you can just ignore these if you don't use them. Of course…

And, of course, this terminological zoo exists not in the least thanks to CLIM's ambition to subsume native widgets of the OS's toolkit. Multiple toolkits, if possible.

CLIM supports the incorporation of toolkits written in other languages. A uniform interface provided by CLIM allows Lisp application programmers to deal only with Lisp objects and functions regardless of their operating platform.⁸ A Guided Tour of CLIM (2006)

So then you end up with issues like this, mentioned right in the spec:

Major issue: There is a general issue about how these menus fit in with the menus that might be provided by the underlying toolkit. For example, under what circumstances is CLIM allowed to directly use the menu facilities provided by the host? Should :leave-menu-visible t interact with the "pushpin" facility provided by OpenLook? — SWM

Thing is: the underlying toolkit zoo is just a zoo as well, and each one is a mess, so trying to abstract them all away is going to leak. The way I figure it is: the backend should configure your menu (or what have you) through runtime addition of slots/behaviors, and that's that.

CLIM, being based on CLOS, is a hard sell for this type of trick, though.

CLIM wants to be your window manager, your desktop environment and your toolkit box for your native toolkits. A kitchen sink of sorts, and all the tap water you have is cold, and the tap itself is somehow constantly bending out of shape, away from the sink and in the general direction of your face.

It seems to actively believe the idea that a widget tree should somehow be separated from its visual presentation by some other tree, and that's a cause of quite a few ills and clumsiness. I mean, yes, I can see how tempting it may be just to "capture" what you draw and call it something very important, like a "presentation", or something, but not once you realize that you can update your tree dynamically and keep whatever information you want in it, and it will do everything you want it to do, all much simpler and more straightforward.

That's a problem. Well, that and a few other dubious abstractions. And quite honestly, I don't think I have even seen a half of it. I haven't programmed anything in CLIM. So, I can't claim to know what it's actually like.

But I am always willing to listen to people who did:

I liked the idea of McCLIM but as I use it every time I try to do something that doesn't really fit into the pattern the library seems to assume you want to stay in (a static layout or set of static layouts, all textual input/commands are through the command loop, &c.) it's super painful and I have to dig through a bunch of mixins and the spec and it still often doesn't behave how I want it to.¹¹ Choosing from GUI Toolkits

I can't judge the validity of most comments about CLIM. But most certainly, "static" isn't a word I want to hear in the context of an interactive GUI framework for power users (or even for programmers). And, maybe, not all the negative comments are fair as some folks didn't give it a real chance (finding it too hard to get going with, for instance). But others seem to be well-informed. These comments aren't rare, and I won't list them here other than the (fairly random) one above.

Well, sometimes you will hear how someone had some sort of enlightenment about how CLIM works. I haven't had such an enlightenment myself. And I am not against any learning curve, per se.

At that, I think the existing manuals/documentation/papers aren't the problem. CLIM is not very beautiful, and it's just hard to explain well the things that aren't beautiful.

CLIM (whatever its incarnation) is not a very bad GUI manager/framework by any means. Some features like infinite drawing sheets are pretty cool. But I do think it's grossly over-engineered¹² Or as they like to call it nowadays: sophisticated., and, yet, accomplishes far from everything.

Must have been an interesting experiment, I guess (and it's ongoing). I, as a programmer, can't really see myself using it, though.