Re: keybindings/feature requests?

[Lars Clausen <lrclause cs uiuc edu>]

On 16 Dec 2003, David Fallon wrote:
> On Mon, 2003-12-15 at 14:09, Lars Clausen wrote:
>> On 15 Dec 2003, David Fallon wrote:
>>> More keybindings would be awesome! In particular, keys to toggle snap
>>> to grid, reset tool after create (and move to a menu instead of
>>> preferences), and a key for each of the default tools, or maybe a
>>> "next/previous tool" key. This is something I'm capable/happy to submit
>>> patches on if someone can confirm what keys it should be.
>>
>> Unfortunately, the text input mechanism gets in the way of this -- we
>> can't assign single-key shortcuts as long as text input happens in the
>> same mode as regular editing.  Something ala Nautilus' name edit thing
>> has to come in.
>
> Ah? Okay. I don't know about how the code is setup - I was presuming
> that whenever I didn't have a text object selected, you could setup the
> keystrokes to do stuff. Just that would be a significant improvement
> over the existing stuff, as it would give users a percentage chance of
> being able to do stuff. Perhaps the UI change is double-clicking allows
> you to edit, while single-clicking just selects? And when you're in
> text-edit mode, I don't think anyone would expect the keys to do
> anything other than add text.

Not good -- the users need to be able to trust what they can do when.  If
they don't happen to notice that they've selected an object with text,
their expectations can suddenly break.  The text-edit mode needs to be
highlighted, and there must be a way to have an object selected without
being in text edit mode.  I'd say clicking (without dragging) on a texty
object should put you in text edit mode, with an obvious box about the text
being edited, and at that point we can fiddle with the shortcuts.

>>> Anti-aliasing seems to have artifact issues as I scroll/work - when I
>>> turn it on it looks great, but has problems over time. 
>>
>> Can you give a more detailed description?
>
> Er, not really... but I can give you screenshots/send the diagram.

Would look great in a bug report:)

>>> Being able to configure what holding alt does would be awesome - it
>>> doesn't seem to do anything currently? The default should probably be
>>> the move tool, although it'd be cool if it was configurable so you
>>> could switch it to something you used often if you wanted to.
>>
>> Now there's an interesting idea.  Same could go for shift and control.
>> We've been holding off on assigning them simply because there's too many
>> different ideas of what should go where.
>
> Yes, although I'd assume control does the usual add/remove from
> selection rather than resetting the selection. I will submit this in
> bugzilla.

Actually, that's shift.  But that's just for clicking an object.  What
should it do when dragging an object?  Resizing it?  Control currently
limits drag and resize to horizontal/vertical only, but some might want it
to be aspect-ratio resizing or something.  Dunno if I want to put that much
configurability in there.

-Lars

-- 
Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| HĂ„rdgrim of Numenor
"I do not agree with a word that you say, but I   |----------------------------
will defend to the death your right to say it."   | Where are we going, and
    --Evelyn Beatrice Hall paraphrasing Voltaire  | what's with the handbasket?