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