Re: Design Issues (list_item, mod_key state)

You have one big problem with the modifier keys imo, because there can 
be multiple keyboards or none, so selecting which one is "active" or 
used seems troublesome to me, have to think a bit more on this though ;)
Darren Vincent Hart wrote:

> I have two design issues I would like some feedback on.
> 
> 1) Currently list_item is responsible for drawing itself, meaning
> drawing differently if it is selected, current, or both.  This is
> reasonable when it is used in a list, but those don't make since in a
> spinner for instance.  So do we want to A) leave them as they are and
> create a spinner_item class, or B) leave the drawing and gc setup for
> current and selected up to the parent container and have list, spinner,
> and their subclasses deal with it?
> 
> 2) I feel we need the ability to determine the state of the mod keys
> during times when we may not have a key_event (like when a mouse_event
> occurs for example: when a mouse_down event occurs in list, I would like
> to know if CTRL is pressed so I know if I should select_none() first, or
> just set the item under the cursor to selected).  Would an
> event_system::mod_state() be appropriate?  If so, should we bother with
> a mod_state in the key_events themselves, as it would be redundant ?
> 
> Darren