[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
RE: [XaraXtreme-dev] UI question - constrain
- From: "Charles Moir" <CharlesM@xxxxxxxx>
- Date: Thu, 20 Apr 2006 13:14:39 +0100
- Subject: RE: [XaraXtreme-dev] UI question - constrain
This issue is part of a larger issue relating to various key short-cut
changes that either being forced upon us by going cross-platform, or
ones that we should be making to move towards an industry consensus.
> Phil Martin wrote:
> > Alt does nothing during transform drags.
> I was wondering whether we should use that.
And that's an example that won't work under Linux as Alt-drags and
Alt-clicks (select under) are taken over by the OS (some weird X 'move
window' thing I think).
So there are changes that will be forced upon us (if we want select
under to work on Linux we need to find another key combination), and
other changes that we could voluntarily make. I suggest the latter be
postponed until after LX 1.0 release and we stick to the original goal
of making an exact clone of the Windows version (so at least the manuals
/ help / movies are as close to accurate as possible).
> > Thinking about it though, it might make much more sense for
> Control to
> > toggle the aspect lock state temporarilly during transform
> drags than
> > it's current function!
> > Currently, the Control key modifier (which is supposed to mean
> > "constrain" in drag operations) constrains the scale factors to be
> > integer so that you get exact size multiples of the
> original object.
> > If you want to get exact scale factors that's probably better done
> > using the scale edit field in the infobar and I bet 99% of
> users don't
> > use scale constrain...
OK having said we shouldn't make these changes until after the LX 1.0
release, I'm happy to debate what those changes might be. Indeed I plan
to create a TalkGraphics thread about this as well, as of course all
existing users will have strong views on any key short-cut changes.
I agree that the current Ctrl constrain size option is nearly useless
and toggling the aspect ratio lock state would be a lot more useful.
BUT the industry standard (Adobe) use Shift for this and if we're going
to change it we should be changing it to be that.
> Even more confusingly, when doing the same thing with fills,
> it uses SHIFT to keep the aspect ratio (CONTROL seems to keep
> the angle constrained the same, i.e. prevents rotation).
> Whereas Shift in the selector seems to change the center
> point for scaling. I would guess the logical thing would be
> for Shift to mean "keep aspect ratio" (like it does on the
> fill tool), and Alt to mean "use alternative scaling point".
That would be a lot closer to the Adobe standard.
Another change that is forced upon us is that the Mac OS uses center
button as a short-cut to dashboard, and stops our page-push short cut
working (perhaps my most used short-cut). And this is another example of
the Adobe way (space bar) now becoming so common that people expect our
apps to work this way as well (I note that, for example OSX Preview uses
space bar as page-push short cut).
I'm afraid we will find many examples of where our way is better, and
that we may have to compromise this in order to move towards the
'industry way'. The Push page is an example. There was a thread on a
Adobe forum recently some guy complaining that our page push short cut
of Shift-F8 was a joke and why didn't we use spacebar like everyone
else. (Our fault because the tooltip tells them it's Shift-f8 ! Ooops)
The center mouse button is a much better way simply because you can push
the page without touching the keyboard at all. But the spacebar method
is now so common amongst graphics apps that we really have to change
(and that of course means changing our short cut to the Selector tool as
well - which currently uses the space bar (not working correctly on
But the technical issue right now is how do we restore the Alt key
behaviour (i.e. select under) on Linux. There was a suggestion that we
map to the Windows key as well, and that's the best suggestion I've
heard so far if it can be made to work.
PS Inkscape has (as we've always planned to) configurable key short-cut
files, as a simple XML file. I suspect this is the only solution that
will keep most people satisfied.