Re: Re: Design Issues (list_item, mod_key state)

On Tue, 2003-08-12 at 06:20, Marc Str=C3=A4mke wrote:
> You have one big problem with the modifier keys imo, because there can=20
> be multiple keyboards or none, so selecting which one is "active" or=20
> used seems troublesome to me, have to think a bit more on this though ;)

The multiple keyboard issue is similar to the multiple screen issue we
discussed before, and IMO, we should concern ourselves with it for this
release.  As in X, if you hold Shift down on one keyboard and press 'a'
on another, you get an 'A'.  At least I believe that to be the case,
someone correct me if I am in error.


> Darren Vincent Hart wrote:
>=20
> > I have two design issues I would like some feedback on.
> >=20
> > 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?
> >=20
> > 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 lik=
e
> > to know if CTRL is pressed so I know if I should select_none() first, o=
r
> > 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 ?
> >=20
> > Darren
>=20
>=20
>=20
> _______________________________________________
> Libstk mailing list
> [email protected]
> http://www.dvhart.com/cgi-bin/mailman/listinfo/libstk