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

[Hans Breuer <hans breuer org>]

On 26.09.2007 21:21, Lars Clausen wrote:
> On Wed, 2007-09-26 at 20:07 +0530, Sameer Sahasrabuddhe wrote:
> > Just to clue people in, the proposed solution is a actually a "text
> > editing" mode, that over-rides all Dia key bindings, not just Delete.
> > When you are editing the text in some object, the operation is "modal"
> > ... which means nothing else works until you somehow signal the app
> > that you have stopped editing the text.
> >
> > As an analogy, recall what happens when you are renaming a file in the
> > file browser ... Explorer in windows, or Nautilus in Gnome. While you
> > are editing the name of the file, how often do you really think about
> > deleting that file or others altogether? All editor commands only
> > affect the name of the file in that mode. Other actions start working
> > only when you press escape or enter, or maybe click somewhere else,
> > thus leaving the name editing mode.
> >
> > Lars is currently working on implementing that mode, and I am sure he
> > will appreciate help in terms of patches if people are interested. Why
> > spend time on workarounds when we could get the real fix in, instead!
>
> Bravo!  Bravo!  You've summarized my plan eloquently.  This is why I was
> asking for what the most reasonable way to enter a text mode would be -
> unfortunately, no clear answer came up.  

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.

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

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.

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

> For exiting text mode, I figure Esc or clicking on other parts of the
> diagram.  Tab should go to the next object selected that has editable
> text.  
Yes, maybe as outlined above?

        Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert