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

RE: [XaraXtreme-dev] Galleries and focus handling

Charles,

--On 03 May 2006 23:27 +0100 Charles Moir <CharlesM@xxxxxxxx> 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 applies
the newly selected settings in the gallery to the selection in the
document. That sounds exactly the same as the Align dialog to me.


Well sometimes they do and sometimes the don't. Selection handling
in galleries as compared to the document is random. The layer and
frame galleries cannot be described as "applying a selected gallery
item to the document selection" - as far as I know they don't
take the slightest notice of the document selection. In the colour
gallery, changing the doc selection highlights the line and fill
colours. In the font gallery, changing the doc selection does not
do this (i.e. the gallery selection is independent). The bitmap
gallery is different again. In all galleries except the layer and frame
galleries, changing the gallery selection (or otherwise clicking in the
gallery) has no effect outside that gallery until some form of
"use this" button is pressed; the layer and frame galleries immediately
apply. In all the galleries with "use this" buttons ("Apply", "Transp",
"Fill") etc., there are ways to achieve such effects without using
the button or pressing return, such as dragging and double clicking.

I don't think (with the arguable exception of the colour gallery),
they are reflecting the state of the selection, letting you
change it in the gallery without affecting the document, then applying
your changes in the gallery to the document (that's what a typical
non-modal dialog does, with cancel returning you to the state it
was at). Mind you the align dialog is slightly peculiar in this
way as if you bring it up and objects /are/ aligned, this isn't
shown in the UI (which would actually be useful).


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' and
'Apply as transparency' (but I hope the tool tips make it clear).


That's what I meant in that they apply an item. They don't apply a
set of changes you have made. For instance, if the colour gallery had
a "line colour" indicator column and a "fill colour" indicator column,
then you could change these, but it would only affect the document on
hitting "apply", that would be like a conventional non-modal dialog.
It would also be a horrible user interface.

Actually the existing colour dialog user interface is quite nasty
in this respect - you can't see why a colour is highlighted. It would
be nicer if the line colour and fill colour(s) were indicated with
dots the same way as on the colour line, and the selected colour in
the gallery (which just controls which one does "Apply") was independent.
You can't currently select a particular colour in the gallery,
select object A in the doc, hit apply, select object B, hit apply,
etc. etc. because selecting the object changes the gallery selection.


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.


I'll be happy if there is a definitive answer to the list of questions
I put in my reply to Phil (and if he fixes up some of the confusing
terminology around the word "window" but that will not be a functional
change). I think we have had answers on this list to all of them. I may
not /like/ every answer, but better to have a consistent set of 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
modal.

The align dialog is /not/ a special case. As far as I can see [snip]

No it's not and exception, and it should perform like the colour gallery
and follow Phil's rules. If we make all the others follow the rules what
is the cost? What valuable features do we lose?


I don't think we lose anything. I think my point was that they should all
be consistent, and that there is actually a fair change from Xtreme in
several cases here (I don't think that's bad, I'm just pointing it out).
The specific change I'm mentioning is that bringing up a dialog/bar will by
default not put the focus in an editable field / combo (we agreed that
should be the default), so Return will not work by default. Also, we agreed
non-modals should not close on escape. That's a change for most non-modal
dialogs (and, given we get consistency, a change for the better).

Moreover, if we fix it in a general way centrally, those dialogs which
perform poorly will stick out like a sore thumb. They may need Xtreme
kludges applied locally to the dialog reverted. Or they may need to be
special-cased anew but we can try and avoid this.


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
ALT-CLICK" etc.)


Highlight how?  Warning on start-up?


Warning on start-up that can be silenced, and some indicator in whatever
interface we use to change the key maps.


I'd like to find cross platform solutions to the Alt-click problem (e.g.
use the Windows key in parallel with the Alt key)


Well we know we can always use the shift key as I hope no window
manager or HIG is daft enough to steal that. We can /probably/ use
the control key in the same way, at least for drags though we
might be better off not (see below for why).

How about we (internally and in documentation) call the keys something like
"Constrain" and "Meta" (as so few Unix keyboards have a key with "meta"
actually written on it). Then have a mapping somewhere between "constrain"
and "meta" and CTRL, Windows/Start key, Left ALT, Right ALT, Right Shift,
Right Control, Keyboard Menu key in the same (yet to be invented) options
dialog pane that controls the rest of the key shortcuts. We can have a test
area where pressing the appropriate keyboard key lights up an LED type
effect on the options pane. They can then try dragging, clicking etc. and
see if it is eaten by the window manager. We'd then keep "SHIFT-CLICK" but
refer not to "ALT-CLICK" and "CONTROL-CLICK" but to "CONSTRAIN-CLICK" and
"META-CLICK". We could be intelligent in our status line messages and
say (for instance) "Press Meta (ALT) to select the object underneath
this one" according to configuration.

Alex