RE: [XaraXtreme-dev] Galleries and focus handling

[Alex Bligh <alex@xxxxxxxxxxx>]

Charles,

> There are probably other cases where I can think it valuable to have
> 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. It's also confusing them being called
apply. The fill gallery calls them "Transp" and "Fill". The colour
gallery calls the button "Apply" when it should be called "Fill" (and
there should be a "Line" button there), because there is no indication
of /what/ it's going to apply to. 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 the document. This is hard with galleries where the
selection is not necessarily intended to be something you want to
change in the document selection - you might be selecting your
colours (etc.) from a library, or indeed from an entirely different
document.

> But then there's an argument galleries should be
> live preview as well.

Yes. But this goes back to the possibility of making the gallery
selection, and the document selection entirely independent. For
instance, if I want to rename the colour "Green" in the gallery,
then clicking on "Green" to rename it (and thus selecting it in
the gallery) shouldn't make my selection go green. I should have
to double-click (or something) to apply it. Right now, galleries
are schizophrenic with respect to the document selection.

> 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, and that means we have an
> Apply button on the Align dialog. So we don't make the dialog, or
> galleries, live preview yet, and but we do make it consistent with
> Phil's rules, which is nothing more than fixing some bad bugs in the
> Align dialog as far as I'm concerned.

Up to a point, Lord Copper.

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. I will be happy to go with
ANY (reasonable) set of consistent and all-encompassing rules (even
if CTRL-W/ALT-F4/return handling is not entirely to my taste). But
I can't cope with "we port XaraLX" as there seem to be /no/ rules
there. Just different dialogs that do different things for no apparent
reason. Given wx keystroke handling is entirely different, I see no
point in attempting to replicate the same (random) behaviour.

The last thing I want to do is go modify a huge set of dialogs. Let's
work out what we want things to do, and get the handling in one
particular place. If there are specific dialogs that should do things
differently, let's hear why they should deviate from Phil's rules.

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).

> Yes I agree. We've been talking about Ctrl-W doing a window close, but
> in fact that's not even an existing Xara short-cut. It brings up the
> 'import from web' dialog, a feature I barely knew we had (it's quite
> good).
>
> However Ctrl-W is a Mac standard for close Window and a better one than
> Alt-F4 which is the Windows (and now Linux) short cut. So in this
> particular case I'd say we should default to both combinations working.
> But of course we have no alternative but to provide user-configurable
> bindings.

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.). It would also
be useful to have multiple keymaps in the resources directory, and
these easily configurable on a per distro basis. So KUbuntu would
use the WIN key instead of the ALT key (or similar).

Alex