[mcclim-devel] possible buglet in highlighting shapes

Wed Apr 27 23:02:38 UTC 2005

I've been working with McCLIM on and off for 18 months or so now I 
guess... mainly back end related stuff, but more recently I've started 
looking at actually building apps. I'll offer my opinions in the 
following...

On Wednesday, April 27, 2005, at 03:39 PM, rpgoldman at real-time.com 
wrote:

>
> My thanks to all of you who pointed me at the :single-box argument for
> with-output-as-presentation.  And an extra thank-you to Paolo for the
> ksnapshot pointer.
>
> A quick question, though, and this is not intended as a flame ---
> is this problem a manifestation of some issues with programming
> (Mc)CLIM?
>
> My impression is that there are two challenges to programming with
> McCLIM:
>
> 1.  The paradigm is radically different from any other interface
>     coding framework.
>

I'd agree with this to a certain extent; I've observed many 
similarities between CLIM and the Cocoa APIs from Apple in the 
windowing substrate (UI is based around NSViews (sheets) which can be 
scaled and rotated arbitrarily using affine transforms, whose coords 
are transformed into the coords of its parent; patterns can be used as 
inks (rectangular-tile); events are passed to NSViews as required, the 
NSView handles the event (or passes it on) which is similar to the 
event handling in CLIM, + other stuff).

Of course, that could be the 'easy' bit in CLIM. I haven't seem 
presentations etc. anywhere else and haven't grokked them properly yet, 
so that's pretty different.

For other GUI toolkits I've used, I'd agree the difference is radical.

I'm hoping that practice will make things easier.

>     This certainly isn't a killer for me, because I happily used
>     Garnet for many years (and if I understood X well enough to
>     modernize its back-end, I would probably go back to it today).
>
> 2.  There seems to be an awful lot of black art to getting a CLIM UI
>     to look right and behave in ways that users will perceive as
>     normal.
>

I'd agree with this too; I initially wanted to port DEUCE to CL when I 
started looking at McCLIM. Then I got a Mac, and decided to work on a 
back end instead. My plan was to implement a slow-but-correct 
Cocoa-based back end for McCLIM. I'm half-way there now (I have 
something that's slow) but getting the correct part is the trick. I've 
read certain sections of the spec repeatedly ('geometry substrate', 
'windowing substrate', parts of 'building applications' mainly), and 
inspected the McCLIM code in detail too in these areas and I still have 
no idea what the 'correct' behaviour is in many cases.

Some things seem not to work properly, but it's hard to be sure because 
the spec is vague (for example, how do you create a sheet whose 
orientation is :graphics rather than :default, and whose coords are 1 
unit = 1 inch? Sure, I can manually provide a transform to do this, but 
shouldn't picking a graft with these properties make this happen out of 
the box? Maybe it does, I don't know, because there doesn't seem to be 
a way to specify the graft options anywhere (without using 'find 
graft') - my expectation was (and sort of still is) that this should be 
able to be specified as part of the 'define application frame' 
functionality (i.e. done at a high level rather than a low level in 
application code). Assuming it can only be done at a low level, how 
does the application developer change the graft? Create all the sheets, 
find a new graft with the (non-default) options, degraft and then 
regraft the hierarchy on the new graft? Not use 
'define-application-frame'? The spec discusses graft options, but it's 
not clear if that's just for completeness (e.g. 'here's how CLIM on 
Genera works') or whether the facilities are actually supposed to be 
used. There's even a comment in the spec about "I'm not sure how much 
of this [graft functionality] is obsolete".

Also things like specifying an :application pane type in the :panes  of 
an application frame, passing ':scroll-bars t' but not having the pane 
become scrollable when output is drawn that doesn't fit on the mirror 
region. I'm not sure if this is user error or implementation error.

>     I don't have a good read on how much this is because McCLIM is
>     still evolving, and how much this is because of the nature of the
>     CLIM beast.

I think from my point of view it's 25:75. McCLIM is still evolving, and 
there are some obvious areas reading the code that are 'wrong' (in 
quotation marks because it's not actually obvious at all whether it's 
wrong or not. I'm thinking specifically about 'update-mirror-geometry' 
where comments in the code lead me to believe compromises are made 
because of 'X limitations').

(And should the native transformation of a graft be 
+identity-transformation+ (suspect it should depend on units & 
orientation)? Should the native region of a graft be +everywhere+? 
These seem to be reasonable assumptions, the spec is silent, so how to 
decide?).

Most of this (IMHO) is definitely down to vagueness in the spec (for 
another example, according to the LispWorks CLIM user guide, a 
platform-specific fontspec can be used as a text-style (e.g. an X 
fontspec), and this is intimated at in the spec too, but it's not made 
clear). I have no idea if McCLIM supports this though (I think: no). 
And then there's the 'design protocol' (section 14.7). Hrm. (+ see 
above on grafts).

>   Do we need better defaults to make things happen more
>     naturally?  How feasible would that be if we want to comply with
>     the CLIM spec?

I think the defaults used in the code correspond to those outlined in 
the spec. The LispM had a natty tool (well - Explorers had one) called 
'profile' that allowed settings to be changed easily by the user. I 
dare say one day somebody will write one for McCLIM (it doesn't 
actually look like it would be too hard to me). Then we would have the 
best of both worlds; defaults in the code that corresponded to the 
spec, but that were easily modified by the user.

>   Or should we provide macrology to wrap things up
>     more easily for new CLIM programmers?  I'm still fumbling around
>     myself, so I find it hard to say what would make things easier,
>     since I might just be doing things wrong.

I think some tools would help here - particularly a UI builder 
(presumably that has some support for defining presentations and 
commands). I feel that in the future (as tools are developed) things 
will be better (for the application developer) than they are currently 
(although I also think that just implementing as much of the spec as 
has been implemented already is quite an outstanding achievement).

-Duncan

>
> Best,
> R
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>