Re: Patch for Delete key behavior (for dia-0.96.1)

[Lars Clausen <lars raeder dk>]

On Wed, 2007-09-26 at 22:40 +0200, Hans Breuer wrote:
> This is what I tried to suggest, though not in the right thread but in this
> one. It may be possible to enter and leave explicit text editing mode just
> like it currently is: by clicking once into the text. But we need to
> support two selection modes for all object having selctable text.
>
> 1) the current text editing starts in DiaObjects::selectf(). It would need
> to be moved to an explicit DiaObject::edit_text().
>
> 2) a new DiaObjects::selectf() for text objects which in fact behaves like
> every other object select function: just selecting the object but *not*
> starting editing. To move a text object one would need to drag it outside
> of the text to avoid starting editing.

Therein lies the rub: How would you move the basic TextObject, then?  It
only has its text as clickable area.

> Together with an extra "text edit"-button in the toolbox the user has some
> visual feedback what is going on and can also toggle between :
>  - text editing all selected objects (another well hidden feature is
>    the ability to tab from one text edit to the next selected text edit)
>  - switch off all text editing to delete or move the objects

Hadn't considered that.

> On 22.09.2007 12:48, Hans Breuer wrote:
> > The real fix would be some managment of text edit mode, where all the
> > usuful keys (not only Delete but also cursor keys, Home, End) are
> > bound to text editing as one is used by other programs.
> >
> > This extra mode - maybe shown and selectable by a cursor button in the
> > toolbox - would allow us to distinguish between object editing, where
> > these keys are used for diagram modification.
>
> I think a lot of things could just work the same between selection mode
> (Modify objects) and text mode (Modify text). Just the already exisiting
> keybindings need to be routed to the proper object: either the text object
> or the diagram.
> Of course it would also be nice to have context aware cut, copy, paste
> which of courxe would directly manipulate the text when in text editing mode.

Absolutely.

> > However, making the code that
> > switches between the two modes could be done even before that is sorted
> > out -- keyboard accelerator changes need to be about the same anyway.
> As outlined above it may not be necessary to do any additional accelerator
> changes if we finally can differentiate modes.

I think there are some shortcuts that would be confusing in text edit
mode, unless we accept that a number of shortcuts cause us to leave edit
mode.  However, if we accept that text edit mode disallows a number of
object-specific shortcuts, we can use the otherwise
input-method-controlled accelerators in object edit mode.

-Lars