[mcclim-devel] Selection mechanism musings (was: possible buglet in highlighting shapes)

[Duncan Rose]

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

 >On 4/28/05, rpgoldman at real-time.com <rpgoldman at 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 at common-lisp.net
 >http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
 >
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: email1.txt
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050429/df463a17/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: email2.txt
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050429/df463a17/attachment-0001.txt>
-------------- next part --------------