[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
RE: [XaraXtreme-dev] Galleries and focus handling
- From: "Charles Moir" <CharlesM@xxxxxxxx>
- Date: Wed, 3 May 2006 19:56:41 +0100
- Subject: RE: [XaraXtreme-dev] Galleries and focus handling
> Equally, I think if you clicked in a text field in the info
> bar (which can't close anyway) and hit CTRL-W you'd expect
> the document to close.
Ah there's the rub. Does it? I would have though Ctrl-W (or Alt-F4) in
text field would mean close this dialog. After all the dialog is the
window with focus and Ctrl-W means 'close this window'. It doesn't mean
'close that window over there that doesn't even have focus'
> That's (in my book) not relevant to the control. And as
> Phil's guidelines say, if the keypress is more likely to be
> useful to the document, it should be passed there.
Well the control is in the dialog, not the document and so Ctrl-W is
more relevant to the dialog than the document, in my view.
> If CTRL-W
> is relevant to a text control (as opposed to the dialog that
> it lives in), why isn't it relevant to (say) a checkbox or a
> radio button?
These can't have focus.
> The advantage of getting rid of this is then the (modeless)
> dialog NEVER has to handle any keypresses. Only the control does.
Still don't see the difference, which strikes me purely as a technical
implementation issue. Yes the control handles key presses, and Ctrl-W
should mean 'close the window I'm in'.
> There is a downside, which is complexity. CTRL-W will
> sometimes close the dialog (if the cursor happens to be in an
> editable field), and sometimes the document. For some
> dialogs, CTRL-W can never work.
That's consistency not complexity. That's no different than the
behaviour of all keys. i.e. using the arrow keys, or any keys, when in a
field has different effects than when it's not.
> > Yes surely it makes sense. i.e. the Apply button is what
> happens when
> > you press Return. So it should be there and highlighted to indicate
> > this (as is standard GUI).
> But it WON'T happen! If the dialog has no editable fields or
> combos, it CAN'T take focus!
Yes I agree in that case of a dialog with no editable fields, it can't
happen and so there should be no highlighted buttons.
> Case in point. I have one dialog with 4 radio buttons in.
> Another with 5 checkboxes in. Both have Apply and Close
> buttons. I open both dialogs. I do something on the page. I
> now alter one of the controls in one of the dialogs. I press
> return. By your own guidelines, the dialog has not got focus
> (it has no blue title bar). I press return. Where does the return go?
Neither dialog has focus or indeed can have focus and so return goes to
the main document (just as it does in the colour editor)
> There is another possibility here, which is to have two types
> of non-modal dialogs. Ones that are meant to be around for
> ages (bars, colour picker, galleries) which NEVER have apply
> buttons or close buttons (just the cross in the corner) and
> where the dialog never processes any keys (just the controls
> within it). These have the small title bar and are dockable.
> And "short lived" modeless dialogs (like options is at the
> moment) which consumes ALL keys like modal dialogs
Yes there is some value in that, but that does add complexity.
> the align dialog with its current UI would be a case in point;
> this would look like a normal dialog but NO document keys would work.
Er, unless you clicked on one of its menus to make it pop-up in which
case keys and arrows etc should navigate that menu.
> To be honest though, I'd rather just make the align dialog
> modal (or fix it's UI so it didn't have apply and close buttons, i.e.
> worked like the colour picker) than do this.
Modal - no way. This dialog is a great example of the benefits of
non-modal dialogs. You can change your selection, edit your document, do
anything you like and then just click Apply to apply the last align
settings to the new selection. I use it all the time.
Ah and there's a reason why the Apply button is needed still !
But generally yes those controls should be live preview (as should
everything) so adjusting the settings has an immediate effect. I agree
with that completely.
But then that leaves the above case, of wanting to apply various dialog
settings to a new selection. Can't see really why we can't have both
interactive controls and an Apply button. But perhaps that's a bit