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@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:
- 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).
- 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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel