[mcclim-devel] how to subclass a pane in good style?

[Andy Hefner]

On Wed, Jul 29, 2009 at 2:23 PM, Nikodemus
Siivola<nikodemus at random-state.net> wrote:

> There may be any number of dubious things in there, but the things
> that most confuse me are:
>
> * What to subclass? I currently subclass APPLICATION-PANE. I don't
> know if I should subclass something else instead.

Subclassing APPLICATION-PANE is fine. For your purposes, subclassing
BASIC-GADGET (or both) might be better (see below).

> * Unintended overriding. I seem to accidentally override the
> border-building stuff from APPLICATION-PANE. It is not obvious to me
> why this happens, nor do I know how to avoid this should I want to.

Not sure what you're referring to.

> * Event handling: to get pointer events I define a method on
> DISPATCH-EVENT that calls HANDLE-EVENT. Is this the way it is supposed
> to be done?

This works, but may inhibit built-in behaviors of the stream (like
text selection, or wheel scrolling). CLIM's input model is
brain-damaged, and event handlers on stream panes (including
application-pane) usually don't work like you want, because magic
input machinery steals the events and turns drives the input editor,
mouse sensitivity to presentations, etc. Gadgets are excluded from
this idiocy, so I've taken to mixing BASIC-GADGET into my classes when
I want a stream pane with custom event handling. For your purposes,
I'm not sure if you need a full CLIM stream at all, so you might
consider subclassing only BASIC-GADGET.

Also, calling tracking-pointer from an event-handler is.. interesting.
I'm sure it says something good about the CLIM design that this works.
I'd have tried this using separate press/release event handlers,
relying on X's implicit pointer grab, but I fear that doesn't give the
behavior you want when the pointer is out of the window.

> * Event handling & coordinates: to get coordinates relative to canvas
> when the pointer is outside the canvas area during the click-and-drag
> selection I transform coordinates through a common ancestor. This
> seems a bit awkward -- is there a better way?

I can't think of a better way. You could simply the code slightly by
using (graft sheet) as the common ancestor.