[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] Galleries and focus handling
- From: Phil Martin <phil@xxxxxxxx>
- Date: Thu, 4 May 2006 09:54:20 +0100
- Subject: Re: [XaraXtreme-dev] Galleries and focus handling
Can you summarise the conclusions you've reached from this
discussion, please? It's difficult to extract them from these snipped-
up email exchanges.
I propose to clarify the rules to say that in Modeless dialogs:
* The Return keypress should commit uncommited values and should be
thought of as being associated with an Apply button, whether an Apply
button exists or not and whether it's labelled Apply or not. The
Return keypress should return focus to the Active View.
* The Escape keypress should abandon any uncomitted values and should
be thought of as being associated with a Cancel button as above. The
Escape keypress should return focus to the Active View.
* Neither keypress should close the dialog.
I could also say that a modeless dialog or its controls may choose to
interpret other keypresses as commands to close the modeless dialog
according to whatever seems best under the native operating system
and/or hotkey configuration???
On 3 May 2006, at 23:27, Charles Moir wrote:
Apply buttons in modeless dialogs. Er, in fact of course
our galleries have Apply buttons.
Yes but they do a different thing. They apply a selected
gallery item to the document selection. They don't apply
something you've changed in the dialog to the selection.
Er, what? Yes they do. I select a new font and click Apply. That
the newly selected settings in the gallery to the selection in the
document. That sounds exactly the same as the Align dialog to me.
It's also confusing them being called apply. The fill gallery
calls them "Transp" and "Fill".
Yes, but that's just because there's no room to put 'Apply as fill'
'Apply as transparency' (but I hope the tool tips make it clear).
The colour gallery calls the
button "Apply" when it should be called "Fill" (and there
should be a "Line" button there),
Yep agree and the tooltips should say 'Apply as fill color' and 'Apply
as line color'
In a conventional
dialog, you'd expect changing the (document)
selection to be reflect in the dialog. And (if there's an
apply button) for any alterations to that to be reflected in
These can all be enhancements for future versions.
But right now I'll revert to the original goal again, to
port what's there, as close as we can to what's there
I actually don't care hugely as to WHAT we implement, so long
as we have a consistent set of rules. Phil's rules were a
good start but didn't specify the entire behaviour.
Well I think they do describe a set of rules than can be applied to
almost all modeless dialogs, bars and galleries. There are only minor
tweaks to those rules, if any.
If there are specific
dialogs that should do things differently, let's hear why
they should deviate from Phil's rules.
I think the only glaring problem is the Options dialog, and even that
could probably be bent to fit Phil's rules without having to make it
The align dialog is /not/ a special case. As far as I can see
on LX, all non-modal dialogs apart from the colour editor,
galleries, and bars perform identically to the align dialog
(see the options dialog for instance).
No it's not and exception, and it should perform like the colour
and follow Phil's rules. If we make all the others follow the rules
is the cost? What valuable features do we lose?
While I remember, half the key shortcuts (and modifiers) seem
to be window manager settings which the app can't override
(or can't easily override). If possible, it would be useful
to highlight these ("your evil window manager has stolen
Highlight how? Warning on start-up?
I'd like to find cross platform solutions to the Alt-click problem
use the Windows key in parallel with the Alt key)