[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

RE: [XaraXtreme-dev] Galleries and focus handling

Charles,

--On 03 May 2006 13:49 +0100 Charles Moir <CharlesM@xxxxxxxx> wrote:


Suppose you click in the document, do stuff, then move the
colour editor. The DIALOG would get focus (or what I call
focus) and pressing return would OK it. However as no CONTROL
would have focus, it wouldn't make any difference to any key
the dialog itself didn't consume (i.e. "Return"). If you want
Return to work in non-modal dialogs, clicking on the title
bar MUST determine which dialog takes it.


No, I'm not sure this is what you want. Because just moving the dialog
out of the way a bit, stops your document editing working.  I'm in the
text tool typing away, I move the Document Info dialog out of the way a
little, and now I can't type (or at least Return and Esc don't do what I
expect).


Well if there is no way to GIVE a dialog focus so that return and
escape act as commit and cancel, then they should NEVER work as
commit and cancel - surely? But that would be a significant change
from Xtreme, where escape and return do the expected thing (cancel
and commit) on all non-modals.

That would be once conceivable option. It would have the merit
of great simplicity. It would also (oddly) be closer to the UI
guidelines in a way. Return and escape are meant to do "OK" and
"Cancel". But our dialogs in general have "Apply" and "Close" - these
are different in character. So arguably return and escape should
not activate them in the first place. I'd be happy with this
as a universal standard.


In the align dialog right now, if I move it a bit, I can't even use the
arrow keys to move my objects any more either, as that changes the
selection of one of the drop-downs that's randomly got focus (we
probably all agree this is wrong).


Yes that is clearly daft. Dialogs when brought up should not give
focus to controls that use keypresses (yes, I know they do at the moment
in LX and Xtreme). So either all keypress, or all keypresses but
for those used by the dialog itself (return or escape if there are
OK and cancel buttons) should be passed down.


Worse we continue to give every indication that the objects in my
document are selected and have focus (e.g. selection blobs around the
objects). So if my arrow keys really are not going to apply to the
selected objects on the page (or delete or whatever) we should be
showing this on the selected objects. The usual method is to grey the
selection indicators (which we cant do).


We could undo the selection completely when (say) a caret was
in a text field). But I don't think that's necessary. We don't
take blobs off when another /application/ has the focus. We just
remove the blue bar. So the blue bar above the little tab on
the document should dim - that should be sufficient to indicate
it's not getting keypresses. Possibly the main title bar too.


So I rather think the easier solution is that we do not give focus to
dialog by clicking on them. This would mean all key operations continue
to work on the main document all the time, *except* when focus is
clearly in a control. At that point typing Alt-F4 or Ctrl-W would close
the dialog (Esc never would).


That sounds consistent. I'm not sure if it is actually possible under
GTK for a TLW not to get focus when clicked on, and it would mean
dialogs had a grey title bar (not a blue/orange one) unless the caret
was actually in a control that took one (I take it you are limiting
this to controls that NEED keys, as opposed to say radio buttons etc.
that merely can get them).

I'm not sure it's right, but it's certainly consistent.

A possible tweak would be to make it react this way (by always
passing the key down, no matter whether it was escape, return, etc.)
but make the title bar always blue.



Take two dialogs that are meant to do something on pressing return.
Options Dialog, Align, DocumentInfo, Tracer, whichever you pick.
Return closes them (right now, in Xtreme). Surely clicking on
the title bar must determine /which/ closes.


Well I don't think it's right that pressing return should close these
dialogs (well it's certainly not right for the colour editor or
galleries).


I agree in the latter cases. And the colour editor doesn't have an apply/OK
button so it wouldn't close. Nor do galleries. I don't think they have
cancel buttons either, so escape wouldn't close them.

I could live with /no/ non-modal dialogs processing return or escape
(as you suggest), or alternatively only true OK and Cancel buttons
(as opposed to Apply and Close) working, which would indeed create the
options dialog as an exception.


Even the Align dialog I should be able to click on the align
menu, cursor to the required option, press return to action the
selection, but I really, really do not want that dialog to go away on
that operation.


Well that wouldn't close it anyway in my model, because return would
ACTION the "OK"-type button. IE return would /do/ the apply. That
doesn't close the dialog, it would be the equivalent of clicking on
the button. What it wouldn't do is be passed to the document (in
my model). In your model, I think non-modal dialogs NEVER process
return or cancel (which would mean return would not work to apply
the changes).

The compromise solution (return only does OK if there is an
OK button - not an "Apply" button, and Escape only does cancel
if there is a cancel button, not a close button) would also work well
here.


Isn't the whole point of non-model dialogs is that they
do not need to go away, indeed they should remain around up until
explicitly closed.


Yes indeed. Noone is arguing return should per-se close the dialog.
The question is whether it should do the same as an OK button (if
present), and whether it should do the same as an Apply button (if
present), or whether it should be passed to the document. Ditto
Escape (w.r.t Cancel and Close).


The Options dialog again seems to be an exception. I suspect if we made
this one modal, no one would ever notice even, and that's probably
better than removing all key driving capabilities from it.


I wonder if it is an exception because it has OK and Cancel buttons
(rather than because it is non-modal). It's mildly useful being
non-modal - think about testing things like magnetic snap radii.
But I agree it could just as easily be made modal.

Would you say the same thing about (say) the tracer?

Slightly off-topic (but not much) - There is a case to be made that
every non-modal dialog should be dockable. This is trivial to do
(and might even work well now wxAUI works well). This will compel us
to fix key handling. This would turn them into "palettes". They could
indeed all dock in one long docking bar and be "rolled up" (this
is a little harder, but not a great deal). Perhaps we could argue
that if this functionality would /not/ be useful, they shouldn't
be non-modal anyway.


I think it should also take those that don't make sense to
it. See delete key in read-only combos, for example.


Er, what does Delete do in a read-only combo? Right now it seems to do
silly things, so isn't this a case where the control should NOT take
Delete key, and should pass it back to the parent (or perhaps take it
but no to delete read-only menu options).


It should do nothing. My point is that writeable combos take letters
and the delete key. Read-only combos take letters (to select the
first item beginning with the letter pressed) and but don't
use the delete key (or could take nothing at all). Assuming read-only
combos take keypresses at all, it would be most confusing if they
passed down delete if they didn't use it, as that would delete
the user's selection, and would be unpredictable as the user would
not know that the combo box was write only at the time. Think about
the multi-purpose combos in the fill tool. In read only combos you
can still click the edit field and do CTRL-C for copy. If that's
going to work, it would be bizarre for clicking the edit field and
pressing delete to have an unpredictable action, depending on whether
the combo happened to be read-only. That's why I'm advocating the
"taking focus" behaviour to be dependent on the control, and whether
a blue highlight / caret appears, rather than on the particular
attributes of the instance of the control in question.

Alex