rpgoldman@real-time.com writes:

is this problem a manifestation of some issues with programming (Mc)CLIM?

CLIM does require a lot of study. I frequently browse and re-read the printed copy of the CLIM manual I keep on my shelves. I also print and study all the CLIM code I can get my hands on (a rich source--no pun intended--of aha! moments).

In the case of the particular problem you mentioned, I immediately recognized a :single-box issue, but didn't exactly remember the argument name and the details. After telling you about ksnapshot, it took me a few minutes to check the manual and find the relevant information.

My impression is that there are two challenges to programming with McCLIM:

[...]

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.

Can you provide a few examples?

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.

Keep asking questions. I personally try to answer all the CLIM questions posted here and in other Lisp forums--well, I am not always successful :)

Paolo

I took a brief look at this tonight, and I see that the keystrokes are indeed not working as expected. I tried a variation on you example using a single character with no modifier, and that worked fine. I'm pretty sure this was working not too long ago (my old tests appear to include a command with :keystroke (#\g :control), and presumably they all worked). Or, maybe the situation is different in some subtle way than what I tested. I guess I'll take a look at what happened over the weekend..

The #\c-\q syntax is new to me.

On 4/27/05, Thibault Langlois tl@di.fc.ul.pt wrote:

The last (unsolved :-) problem is related to keystrokes when I define a command with the define-frame-command macro.

I tried to do as described in the allegro CLIM manual:

(define-test-commands-1-command (com-quit :name t :keystroke (:q :control)) () (frame-exit *application-frame*))

but C-q in the interactor does nothing.

The LW CLIM manual gives a different syntax for keystrokes that is not readable with cmucl/McCLIM: :keystroke #\c-\q

I tried to define a gesture: (define-gesture-name :quit :keyboard (#\q :control))

(define-test-commands-1-command (com-quit :name t :keystroke :quit) () (frame-exit *application-frame*))

I have seen examples like this one and I think it should work but it does not (C-q does nothing).

Andy Hefner ahefner@gmail.com writes:

I took a brief look at this tonight, and I see that the keystrokes are indeed not working as expected. I tried a variation on you example using a single character with no modifier, and that worked fine. I'm pretty sure this was working not too long ago (my old tests appear to

Does this involve the :use-keystrokes argument of read-command, or maybe read-command-using-keystrokes? I don't understand whether the user has to explicitly specialize a frame top-level in order to make keystrokes work.

Paolo

...

...

...

...

"PA" == Paolo Amoroso amoroso@mclink.it writes:

PA> rpgoldman@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

On Thursday, April 28, 2005, at 06:17 PM, rpgoldman@real-time.com wrote:

I think one thing that makes it more confusing for a newcomer to CLIM is the way many of the manuals are written.

Indeed.

I have looked at both the LW and the Allegro manuals, and maybe they're great manuals, but they are terrible to learn from.

For example, the Franz CLIM UG seems to be written from the bottom-up, in parallel to the architecture of the software. It starts with drawing planes and the screen, and then works up to gadgets.

I think both the Franz + Lispworks docs are derived pretty much from the spec, and as such follow a structure that makes sense in a specification but probably less sense in a tutorial. Whether the 'user guides' can be considered tutorials or not is a different question, I suspect many people would say they can't.

The specification itself seems to be written in the order the different layers of CLIM need to be implemented to have everything work; geometry comes first (most specific, the foundation of windows, sheets, output recording, etc.) followed by the next layer (Windowing) which is the basis for presenting information to the user and reading input from the user; then the input and output protocols (implemented on top of the fundamental windowing features) and finally 'application building'.

You almost want to read the spec from back to front as an application developer I think. Probably the most important thing to take on board is that CLIM is rigidly layered. The lower, more detailed parts can be used if needed but generally only the high level parts are necessary for a large class of applications (default behaviours, basic windowing, input handling and basic drawing).

There's a good paper floating around somewhere that describes this layering (for CLIM 1 I think but the general principles are the same even if some specifics are different). I don't have the link to this handy either, but it's called "A Guided Tour of the Common Lisp Interface Manager" by Rao, York and Doughty.

But if one looks at sources that try to teach a programmer how to do things, they always start with tasks the programmer might want to accomplish, and work down into detail. So a guide to using CLIM should start with application frames, move to gadgets, etc.

I agree with this; I think that this is the approach the McCLIM tutorial is taking (I seem to have mislaid this document, perhaps somebody else can provide a pointer). Here's another document (referenced from the McCLIM wiki) which takes the approach you propose:

http://constantly.at/lisp/ui.html

Again, I'm not trying to complain that this isn't in those manuals --- manuals and tutorials aren't the same.

And I don't want to be seen as a whiner who just wants everything given to him on a platter.

What I'd like to do is just share some perceptions of what I think might make things easier for McCLIM users and might make McCLIM more popular.

We could ask the same of Lisp in general perhaps ;-)

-Duncan

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

rpgoldman@real-time.com writes:

I think one thing that makes it more confusing for a newcomer to CLIM is the way many of the manuals are written.

I have looked at both the LW and the Allegro manuals, and maybe they're great manuals, but they are terrible to learn from.

The lack of good tutorial-style material and sample code has been a constant complaint raised in the CLIM mailing list archives. Some vendors, such as Symbolics, offered training, and some tutorial sessions were done at Lisp conferences. A suggestion for the next Lispnik events, large and small: CLIM tutorials.

What I'd like to do is just share some perceptions of what I think might make things easier for McCLIM users and might make McCLIM more popular.

Keep the questions going until my fingers bleed on the keyboard :)

Paolo

Friedrich Dominicus frido@q-software-solutions.de writes:

address-book example, but am now deriving. So what I like to know is how to make this part of the address-book example: (defmethod display-names ((frame address-book) stream) (dolist (address *addresses*) ;; PRESENT invokes the :PRINTER for the ADDRESS presentation-type, defined above. ;; It also makes each address printed out mouse-sensitive. (updating-output (stream :unique-id address) (present address 'address :stream stream) (terpri stream))))

work with a list pane. What I want is that that the list-pane entried get mouse-sensitive. I searched the examples but found nothing which

You may do something like this in the panes section of the relevant application frame (untested):

(define-application-frame ... ... (:panes (addresses (make-pane 'list-pane :mode :exclusive :items *addresses* :value-changed-callback 'select-address)) ... ))

Where #'select-address does whatever is needed to make the address selected by the user via the list pane the current one.

Paolo

The list-pane is a gadget, and not required or expected to integrate with presentations in the way you suggest (native window system gadgets can't be expected to know about presentations). Presently you must fall back to a more conventional toolkit model of programming where gadgets are concerned (performing action via the value-changed-callback, as Paolo describes).

How to better integrate gadgets with higher levels of the CLIM framework is an open question. The big thread a week or two ago touched on some of this.

On 5/9/05, Friedrich Dominicus frido@q-software-solutions.de wrote:

Well I'm starting to find my path into CLIM. The application I like to implement is an account keeping application. I implemented it before with LispWorks and CAPI and now I want to make it a clim application. I found out about the different panes but got a bit stuck with how to use one of them the list-pane. It seems that this is the pane I'd like to use to keep a list of short descriptions of the divrese accounts. I first modelled the accounts stuff as the address-book example, but am now deriving. So what I like to know is how to make this part of the address-book example: (defmethod display-names ((frame address-book) stream) (dolist (address *addresses*) ;; PRESENT invokes the :PRINTER for the ADDRESS presentation-type, defined above. ;; It also makes each address printed out mouse-sensitive. (updating-output (stream :unique-id address) (present address 'address :stream stream) (terpri stream))))

work with a list pane. What I want is that that the list-pane entried get mouse-sensitive. I searched the examples but found nothing which gives me a hint. Maybe some of you can?

Regards Friedrich _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel

On 4/28/05, rpgoldman@real-time.com rpgoldman@real-time.com wrote:

• 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.

Agreed. I don't think the omission requires a rethinking of CLIM from the ground up - you can certainly implement the notion of a selection yourself if you wanted to - but a standard approach and some utilities might make life easier. I have some thoughts on how to address this, and I think they can be implemented in terms of the spec (I haven't worked out specifics of what it would look like). It could be nice to provide the functionality ourselves so users don't have to reinvent the wheel. I've tried several times (unsuccessfully) to elicit discussion of this on IRC - perhaps the mailing list is a more appropriate forum. :)

I can imagine two approachs to this. The first would be to do it manually, undercutting some of the beauty of the CLIM command framework. Keep track of the current selection as a slot within the application frame, enable commands which are applicable to the selected object, disable commands that are no longer applicable, and use the value of the selected slot directly within your commands. Gadget callbacks or even commands on presentations would select/deselect objects, update the selection slot, enable/disable commands, etc. If you wanted command input at an interactor to work as expected, you'd need to define two versions of the commands, one which uses the 'invisible' selection from the selection slot and one to use from the command line which prompted for an argument as usual. I think this is more or less how apps written in a conventional toolkit end up doing things.

As an example I'll use a graphical file manager, where the frame represents the view of one directory of files. The application frame would contain a slot with a list of the currently selected files. You would define commands in response to the click, control-click, shift-click gestures which modify the current selection and redisplay the folder contents to reflect the modified selection. Commands such as com-delete-files would be defined with no arguments, and would act on the value of selection slot. To avoid confusing users, you want to disable com-delete-files and similar commands when the selection is empty.

The second (and more interesting) approach would be to extend the CLIM command framework to support a more conventional notion of selected objects. I think this can be reduced to simply a programmatic way of transparently providing default arguments to commands, ideally sensitive to context. I'll return to the file manager example. Using this approach you could define commands operating on files (such as com-delete-files) as taking an argument of type (sequence pathname). If a user enters the command at an interactor, it would prompt for a list a of pathnames. When selected from a menu the application can choose to provide default values however it wishes (from a gadget-value, some internal state, whatever), prompting only for any remaning arguments (preferrably via a dialog), or executing immediately if there are no more required arguments. For determining the current selection, applications could define their own selection commands as before, or McCLIM could supply an optional mechanism allowing you to select presentations within a stream pane. The method supplying the values for the (sequence pathnames) argument in our file manager would simply query this selection. Some rethinking of the behavior of the right-button menu also becomes necessary.

I'm not certain what the ideal interface would look like. Specifically, I'm not sure how you'd want to match arguments (by name? by presentation type? both? a specific argument to a specific command? by some extra data tagged on when the argument was declared?). I imagine a generic function which would be called on each argument of a chosen command which would have the first shot at providing a value for the command before the user is prompted. Application writers would define methods to provide the desired behavior for things like our file manager. It may be useful to specialize on the frame, context in which the command was invoked (:interactor, :frame-menu, :right-button-menu, etc), command name, argument name, and argument presentation type. Did I miss anything? There are many other ways I could imagine to acheive similar ends.

I'm sure an app could do most of this stuff within the existing spec. I haven't worked out exactly how, but providing a customized read-frame-command might be start. It's possible there is some hook in the spec doing exactly what I want that I've overlooked.

A tester for commands (similar to the tested user in CLIM presentation translators) which could be specialized on context would make both approaches easier (ex. command menu items could be greyed out if they are not applicable to the current selection or state of the application).

Something to keep in mind for hypothetical CLIM 3.0 discussions, anyway..

On Thursday, April 28, 2005, at 08:01 PM, Andy Hefner wrote:

On 4/28/05, rpgoldman@real-time.com rpgoldman@real-time.com wrote:

...

• 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.

Agreed. I don't think the omission requires a rethinking of CLIM from the ground up - you can certainly implement the notion of a selection yourself if you wanted to - but a standard approach and some utilities might make life easier. I have some thoughts on how to address this, and I think they can be implemented in terms of the spec (I haven't worked out specifics of what it would look like). It could be nice to provide the functionality ourselves so users don't have to reinvent the wheel. I've tried several times (unsuccessfully) to elicit discussion of this on IRC - perhaps the mailing list is a more appropriate forum. :)

I'm sure something about this came up on the clim mailing list (archives are linked from the CLIM cliki page somewhere) at some point and the point was made that this kind of thing can be done within the CLIM framework using some feature or other which I unfortunately can't remember at the moment...

Scanning mail archives ... done. [elapsed time: 1.5 hours]

Ack, every time I delve into those mailing list archives I'm stuck for hours. The thing I was thinking of was 'presentation actions' but having reread some of the messages I think I misremembered the advice about them. I don't think CLIM 2 has them anyway (the translation infrastructure was probably beefed up so they became unnecessary I'm guessing).

I've attached a couple of mails that looked relevent to this discussion. Any code probably won't work with CLIM 2, but should be relatively easily ported I guess. If nothing else, approximate dates and subject lines might make the rest of the related messages easier to locate...

I actually think this mode of interaction (using selections) might assist accessibility; particularly if there was a selection history that could be navigated trivially. Perhaps the presentation history mechanism would help here, but that's just a random guess since I know very little about that (yet).

I can imagine two approachs to this. The first would be to do it manually, undercutting some of the beauty of the CLIM command framework. Keep track of the current selection as a slot within the application frame, enable commands which are applicable to the selected object, disable commands that are no longer applicable, and use the value of the selected slot directly within your commands. Gadget callbacks or even commands on presentations would select/deselect objects, update the selection slot, enable/disable commands, etc. If you wanted command input at an interactor to work as expected, you'd need to define two versions of the commands, one which uses the 'invisible' selection from the selection slot and one to use from the command line which prompted for an argument as usual. I think this is more or less how apps written in a conventional toolkit end up doing things.

Why would this need to be done manually, undercutting the current command framework? I feel (i.e. it's purely subjective!) that the command framework could be bent sufficiently to support this automatically... well, maybe.

Selection functionality can be split into at least two parts I think. The first is how selections are made, and that kind of depends I suppose on what is being selected. The second relates to what to do with the selection once made. The right-click menu has already been mentioned. Being able to drag arbitrary 'selection sets' around seems like a useful thing, but so too would being able to set (say) the text style for a selection set (that contained text).

I'd have thought having a 'add-object-to-selection-set' command would be sufficient to maintain any selection (ok, I guess 'remove-...' might be needed too ;-). Some kind of specialization would be needed to cope with different kinds of selections (multiple presentations, window regions, blocks of text).

Is there any reason a command couldn't accept a "selection-set" as an input?

Then the commands that operate with a selection set could work as you describe.

However I strongly feel that using the current CLIM command structure (action - on what) is not suitable to commands that would operate on a selection set (on what - action). I would propose NOT having commands that requested selections at all. Commands operating on selections would either operate on the current selection, or report an error (no selection).

This is kind of the way Emacs dired works after all; use 'd' to mark files for deletion, then 'x' to do the actual delete. If you 'x' without any 'd', the result is a simple warning.

This feels (to my rather inexperienced mind ;-) to be something that is achievable largely within the existing framework (some extension of commands and 'presentations' would probably be needed).

I thought CLIM (under CLX at least) already supported some kind of selection mechanism? Or is that single-presentation only? I must confess to not having looked in detail yet, I have enough trouble hacking Beagle to support the CLX functionality of 12 months ago :-)

As an example I'll use a graphical file manager, where the frame represents the view of one directory of files. The application frame would contain a slot with a list of the currently selected files. You would define commands in response to the click, control-click, shift-click gestures which modify the current selection and redisplay the folder contents to reflect the modified selection. Commands such as com-delete-files would be defined with no arguments, and would act on the value of selection slot. To avoid confusing users, you want to disable com-delete-files and similar commands when the selection is empty.

We seem to be thinking along the same lines ;-) I don't think the commands would need to be disabled though (having said that, it would be nice to be able to make them unavailable from menus and such, so maybe they do need to be disabled).

The second (and more interesting) approach would be to extend the CLIM command framework to support a more conventional notion of selected objects. I think this can be reduced to simply a programmatic way of transparently providing default arguments to commands, ideally sensitive to context. I'll return to the file manager example. Using this approach you could define commands operating on files (such as com-delete-files) as taking an argument of type (sequence pathname). If a user enters the command at an interactor, it would prompt for a list a of pathnames. When selected from a menu the application can choose to provide default values however it wishes (from a gadget-value, some internal state, whatever), prompting only for any remaning arguments (preferrably via a dialog), or executing immediately if there are no more required arguments. For determining the current selection, applications could define their own selection commands as before, or McCLIM could supply an optional mechanism allowing you to select presentations within a stream pane. The method supplying the values for the (sequence pathnames) argument in our file manager would simply query this selection. Some rethinking of the behavior of the right-button menu also becomes necessary.

I like this, but I think it's a restatement of what's already been said. Maybe I'm missing something. The only thing I'd add is that perhaps prompting for additional arguments strikes me as a 'bad thing'. We'll be giving the user's familiarity on the one hand (click + operate) but taking it away with the other (start asking for additional stuff). Anything other than an 'are you sure [y/n]' dialogue seems unnecessary at this point IMO. Anyway, if we are going to break the 'standard' selection protocol (i.e. as implemented in most os'es at the moment) I think I'd rather not have it at all.

What are we hoping to achieve with all this? The ability to generate appliactions that can look and feel like native apps? Or just a fix for the 'one file at a time' problem of the LispMs (which may have been fixed anyway, I don't know). The implementation would be different depending on the answer I think.

I'm not certain what the ideal interface would look like. Specifically, I'm not sure how you'd want to match arguments (by name? by presentation type? both? a specific argument to a specific command? by some extra data tagged on when the argument was declared?). I imagine a generic function which would be called on each argument of a chosen command which would have the first shot at providing a value for the command before the user is prompted. Application writers would define methods to provide the desired behavior for things like our file manager. It may be useful to specialize on the frame, context in which the command was invoked (:interactor, :frame-menu, :right-button-menu, etc), command name, argument name, and argument presentation type. Did I miss anything? There are many other ways I could imagine to acheive similar ends.

I think I've stated my thoughts... this looks like it will be an interesting discussion.

-Duncan

ps. would the drag and drop stuff be tied in to selections too? It seems like that would be a good idea to me...

-D

I'm sure an app could do most of this stuff within the existing spec. I haven't worked out exactly how, but providing a customized read-frame-command might be start. It's possible there is some hook in the spec doing exactly what I want that I've overlooked.

A tester for commands (similar to the tested user in CLIM presentation translators) which could be specialized on context would make both approaches easier (ex. command menu items could be greyed out if they are not applicable to the current selection or state of the application).

Something to keep in mind for hypothetical CLIM 3.0 discussions, anyway.. _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel

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:

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

Having rapidly checked the spec...

On Thursday, April 28, 2005, at 12:36 AM, Andy Hefner wrote:

On 4/27/05, Duncan Rose duncan@robotcat.demon.co.uk wrote:

...

Also things like specifying an :application pane type in the :panes of an application frame, passing ':scroll-bars t' but not having the pane

<grumble> Can you find where in the spec this is required? I think this keyword is fictional, and I'm astonished at the number of people trying to use it. Maybe it is a vendor extension, but it doesn't make any sense to me. Scrolling is acheived by embedding the pane in another pane which

You are right; it's not in the spec. I'm actually quite suprised I didn't already know this considering how much time I've spend reading the thing ;-) I'll make an excuse that I haven't read chapter 29 in as much detail as some of the others...

Speaking purely personally, when I'm trying to struggle through a mysterious coding exercise, and printed docs make less sense than they could, I try to find a canonical (existing) application from which to copy and go for the 'it works for application XXX, why not me?'. In this case there's only one canonical application in my opinion (I choose to discount the address book demo). Can you guess which it is?

Here's it's define-application-frame form:

;;; Listener application frame (define-application-frame listener (standard-application-frame command-history-mixin) ((system-command-reader :accessor system-command-reader :initarg :system-command-reader :initform t)) (:panes (interactor :interactor :scroll-bars T :display-function #'listener-initial-display-function :display-time t) (doc :pointer-documentation) (wholine (make-pane 'wholine-pane :display-function 'display-wholine :scroll-bars nil :display-time :command-loop :end-of-line-action :allow))) (:top-level (default-frame-top-level :prompt 'print-listener-prompt)) (:command-table (listener :inherit-from (application-commands lisp-commands filesystem-commands show-commands) :menu (("Application" :menu application-commands) ("Lisp" :menu lisp-commands) ("Filesystem" :menu filesystem-commands) ("Show" :menu show-commands)))) (:disabled-commands com-pop-directory com-drop-directory com-swap-directory) (:menu-bar t) (:layouts (default (vertically () interactor doc wholine))))

I suggest if you want to see this option used less often, it should NOT be present here. Even if the :scroll-bars is left out, the application pane gets a scroll bar drawn in it, which then appears to be unusable. Could well be another user error though...

provides scroll bars and a viewport. If I expect :scroll-bars t to work as expected, make-pane would have to return the scroller pane rather than the the pane I asked it to create (which makes no sense at all), or there would have to be some magic backdoor whereby adopting my pane caused a chain of parents to be adopted in its place.

Sort of like the way every frame contains a raised pane with a menu pane in it, even if they never get used? I agree, it's annoying ;-)

I've attached a little utility I'm calling 'glimpse' at the moment; fire it up ('glimpse:glimpse' after building) and 'show sheet hierarchy' (hopefully it will work; it's a quick and nasty hack but might grow into more sometime. Perhaps others will find it interesting).

I don't much like that either (if I was modifying the UI dynamically, with a bunch of gadgets in a container, I'd no longer know which one to disown when its time came without walking the entire tree of children).

I have heard this complaint so often now that it is tempting to add a check which will yell at programmers who expect this to work.

Just take the code out of the listener and its use will probably disappear.

-Duncan

</grumble> _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel

OK, sorry. But for the stupid, what's the magic to put in make-application-frame that will give us something that's scrollable?

If there is no easy way to specify a scrollable pane, isn't that a problem?

I accept Andy's worry about losing the ability to grab onto the "real" internal pane, but it still seems that there should be an easy way to specify scrollable panes w/o having to go beyond the define-application-frame syntax. But I'm getting confused, so maybe I'm missing something.

Thanks, R

I think that magic IS required, but it goes on behind the users back. :)

On 4/28/05, Duncan Rose duncan@robotcat.demon.co.uk wrote:

I think the consensus is that all CLIM 'windows' (i.e. panes that are in fact clim-stream-pane types) DO (or at least, should) accept the :scroll-bars keyword in 'define-application-frame' and will default this to some sensible value (dependent of pane type) if not provided.

This *should* mean that no magic is required; just use an :interactor or :application (or :command-menu, :title, or :pointer-documentation) pane and scrolling should 'just happen' (well - some of these types have a default :scroll-bars of nil and so won't scroll out of the box).

...

...

...

...

"AH" == Andy Hefner ahefner@gmail.com writes:

AH> On 4/28/05, Robert P. Goldman rpgoldman@sift.info wrote: >> OK, sorry. But for the stupid, what's the magic to put in >> make-application-frame that will give us something that's scrollable? >> >> If there is no easy way to specify a scrollable pane, isn't that a >> problem?

AH> I think you are missing something. Use the 'scrolling' macro in your AH> layout, for example:

AH> (define-application-frame ... AH> ... AH> (:layouts AH> (default AH> (scrolling () my-pane)))) ;; Is that the sort of macrology AH> you're looking for?

Thanks, Andy. I was looking in the wrong place. This explains my wrong-headedness before, too. Scrolling is obviously an aspect of layout, rather than pane content. I retract my original comments...

R

...

...

...

...

"AH" == Andy Hefner ahefner@gmail.com writes:

AH> On 4/27/05, Duncan Rose duncan@robotcat.demon.co.uk wrote: >> Also things like specifying an :application pane type in the :panes of >> an application frame, passing ':scroll-bars t' but not having the pane

AH> <grumble> AH> Can you find where in the spec this is required? I think this keyword AH> is fictional, and I'm astonished at the number of people trying to use AH> it. Maybe it is a vendor extension, but it doesn't make any sense to AH> me. Scrolling is acheived by embedding the pane in another pane which AH> provides scroll bars and a viewport. If I expect :scroll-bars t to AH> work as expected, make-pane would have to return the scroller pane AH> rather than the the pane I asked it to create (which makes no sense at AH> all), or there would have to be some magic backdoor whereby adopting AH> my pane caused a chain of parents to be adopted in its place. I don't AH> much like that either (if I was modifying the UI dynamically, with a AH> bunch of gadgets in a container, I'd no longer know which one to AH> disown when its time came without walking the entire tree of AH> children).

AH> I have heard this complaint so often now that it is tempting to add a AH> check which will yell at programmers who expect this to work. AH> </grumble>

I have sympathy with both sides of this debate, because it seems like a clash of intuitions, and they are both right. And because I suffered through this with the Garnet toolkit, which had the same thing with its scrollable windows.

Andy does a great job of explaining why, from an implementation pov, it would not be great to have :scroll-bars t. He also explains why it might hamper developing new interfaces by specialization.

However, the other side is valid, too. It seems like an entirely valid intuition that scrollability is an ATTRIBUTE of a window, rather than a container around the window. OK, the latter corresponds to implementation better, but the former corresponds better to the intuitions of a programmer who is not familiar with the implementation of his toolkit. I also think we have plenty of evidence from other graphics toolkits that this is a reasonable intuition.

Having said that I see both sides of this debate as reasonable, I'm not sure what the hell to propose. Most unsatisfactory.

R

On Friday, April 29, 2005, at 08:54 AM, Paolo Amoroso wrote:

Duncan Rose duncan@robotcat.demon.co.uk writes:

...

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.

You may check the CLIM mailing list archives. They provide explanations and clarifications on many design decisions and implementation issues.

This is a useful resource (well... it's interesting) but not helpful in this case. I wasn't very clear but I was more talking about things that might relate the the back end. For example, what is a 'mirror region'? Is it the visible (presumably rectangular) area of the mirror that is visible, not accounting for occlusion? Or is it the 'physical' area of the mirror, which only makes sense when the mirror transform is taken in account? What does it mean to modify the mirror region?

I talk about this specifically because when McCLIM resizes a mirrored sheet, the size of the mirror also appears to change. This is a good thing in CLX since it appears to me that scrolling can be implemented just by informing the X server what the new offsets are, and the display is updated *by X*. This is not however so good for Beagle, since it just means I end up with a potentially huge window server object which then has to be redisplayed via the CLIM machinery. Now Cocoa has very good support for performing windowing operations that parallel CLIMs support in many ways, but it's hard to use them when dealing with a mirror that has a region of 550 x 16245 (say) and a mirror transformation that modifies y ordinates by -15800, when I could have a mirror with a region that's 550 x 445, and a noop transform.

The CLIM spec is very quiet on these kinds of issues, preferring to leave these kinds of things up to the back ends (which is a good thing) but it's very difficult to get any indication of what a 'mirror region' is INTENDED to be. I was toying with moving 'update-mirror-geometry' into the back ends, so CLX + Beagle could do this differently (and 'care-for-new-native-transformation' seems to never be invoked which is strange) but I haven't decided whether to do this or not.

It wasn't until I happened to read the glossary in the Lispworks CLIM UG that I understood that in CLIM terminology, a 'window' is just a clim-stream-pane class. Basic, maybe, but it certainly helps understanding what people are talking about sometimes ;-)

...

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:

The main problem with CLIM vendors manuals is that they don't make clear what is in the spec and what is an extension.

Paolo

Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel