[mcclim-devel] possible buglet in highlighting shapes
rpgoldman at real-time.com
rpgoldman at real-time.com
Thu Apr 28 17:02:35 UTC 2005
>>>>> "PA" == Paolo Amoroso <amoroso at mclink.it> writes:
PA> rpgoldman at real-time.com writes:
>> My impression is that there are two challenges to programming with
>> McCLIM:
PA> [...]
>> 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.
PA> Can you provide a few examples?
Sure, but not original ones:
- one thing that seems odd is the lack of a conventional selection
concept, which we see in the now-standard direct manipulation
interfaces. I.e., you select an object and that provides the focus
of all commands. I'm not sure that providing this is even feasible
with CLIM, because of its radically different paradigm.
- Examples of use of standard gadgets. E.g., on others' suggestion,
I've been meaning to get the file selector factored out of climacs
and put into mcclim, for example. Alas, my plate is already
overfull right now, so it will probably be at least a small number
of weeks before I get to this.
- An easier introduction to providing an application frame with a menu
bar, since that seems like a central UI paradigm these days. Note
that I may simply have missed some good sources.
- Earlier I was having a lot of difficulty telling when McCLIM would
decide that my input was complete, but I think this was just
transient accepting-values problems that seem much better...
>> 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.
PA> Keep asking questions. I personally try to answer all the CLIM
PA> questions posted here and in other Lisp forums--well, I am not always
PA> successful :)
At the expense of inviting flames, in my dreams there's some way to
get started with CLIM that's as easy as (or approaches as easy as)
getting started with Tcl/Tk. With that, in about 10 lines, one can
have a screen with buttons and stuff that happens. OK, admittedly you
end up with a dead end not too far down the pike, but that's what I
would dream of.
Somehow it seemed a lot harder to get over that initial hurdle of
defining an application frame, a presentation type, a command, a
and command-translator. Perhaps if I mull over some more macrology,
that will become clearer.
Maybe when there's a bigger palette of built-in gadgets, and more lore
about how to use them, this will be easier.
As a programmer, relatively familiar with the callback model, I have a
very hard time grappling with the paradigm which seems like: define a
case where you want to get a particular type of value, define ways of
presenting values, and then magic happens and the values you present
can be pulled back in.
Note that part of this is because I'm lazy, but that's a different way
of saying that developing CLIM UIs isn't a main part of what I need to
do. I'd like a smoother path from "here's a dead-easy way to do the
simpile thing to more and more complex stuff."
I realize that we're all volunteers here, and I'm not demanding that
this be handed to me on a platter --- to the extent I can help in this
project, I'd be happy to do so. I just don't see the way yet.
Best,
R
More information about the mcclim-devel
mailing list