RE: [XaraXtreme-dev] Galleries and focus handling

["Neil Howe" <NeilH@xxxxxxxx>]

> >
> >
> > --On 03 May 2006 10:28 +0100 Phil Martin <phil@xxxxxxxx> wrote:
> >
> >> The problem with focus handling in Camelot is that Charles is
right...
> >
> >
> > Well he isn't entirely right because the app does not in practice
> > behave the way Charles claims it does. And it is inconsistent
between
> > different non-modal dialogs, and between non-modal dialogs, bars,
and
> > galleries. That in itself can't be right.
> 
> Yes, but putting inconsistencies, bugs and Windows foibles aside it's
> clear what he's getting at: The user's attention is almost always on
the
> drawing, not the surrounding gubbins, so make keypresses do things to
> the drawing unless the user has very deliberately said otherwise (i.e.
> more deliberately than standard UI focus handling guidelines).
> 
> >
> > I think Charles' guidelines (which seem to be mostly the same as the
> > rules you put are) are the roughly right. They are similar (but not
> > identical) to what actually happens in Xtreme, and have the merit
> > of self-consistency, even if they aren't the same as the UI
guidelines.
> >
> > My plea is that whatever we do, we do something CONSISTENT in ONE
> > PLACE. Xtreme seems to do different things in different dialogs.
> > Why is focus handling in the colour editor (say) different from in
> > the align dialog (say)? There is no logical reason other than at
> > some late stage someone reported focus handling as a colour editor
> > bug when it is in fact an "all dialogs" bug. We have the opportunity
> > now to set the rules and get this right once and for all, rather
than
> > relying upon an incremental solution as per the early days of
Camelot.
> 
> Yes, of course - which is why we need to:
> * Set out the conceptual behaviour first (see above)
> * Then try to encode that in a broad set of rules (this is where
> consistency will come from)
> * Then worry about the specifics of writing code to implement those
rules

Ok Phil, can you take your list of rules and refine them to complete a
policy that we're all happy with? Hopefully we're nearly there.

The main difference between your rules and what Charles described is
that Charles specifically names text controls as being the only controls
that consume keyboard events in a non-modal window. So please update
your rules to take this into account. 

Also, we should list the events that non-modal windows are allowed to
process. And everything else they must pass on. I think that was Escape,
Return and window close events. Any others?

Neil