Text editing needs to improve. Several problems that can more or less be solved together:The last problems is what got me started thinking about this (think of the Delete key, and Copy/Paste), but may not be the most important. Tricky to convert all text to actual Text objects, both for backwards compatibility and for things like UML Class where a) fonts and size are set for a number at a time, and b) texts have a syntax. -- LarsClausen - 19 Mar 2004 An idea for the problem with text mode vs. edit mode, and how to easily edit text while avoiding the text shortcuts in edit mode (inspired by Gnumeric): By default we're in edit mode. Whenever a non-modified key is pressed, we enter text mode, marked by the text being edited getting an appropriate highlight and a cursor. Text mode can be entered by pressing Enter or Tab, too, one of which should highlight the old text so it can be replaced. Editing should use the standard GTK editor, embedded in the canvas. Pressing Tab in text mode moves the text edit field to the next text of the same object, or to the first text of the next object. Pressing return in text mode merely inserts a newline. Clicking anywhere in the canvas outside the text edit field puts us back into edit mode, as does pressing Esc.
- Some texts are only editable in properties dialog. Must be able to edit all texts in the diagram.
- Must click to edit a text in a diagram, should be able to tab between them.
- Can only have one text per object.
- Hard to tell when a text is being edited.
- Can't have text-edit keyboard shortcuts overlapping object-edit shortcuts.
-- LarsClausen - 16 Apr 2004 Starting to implement this in the dev branch. Text edit should probably be a feature of the display, but with an underlying model for each text. The current select function on the objects allows us to register what texts are available for editing, but there may be problems with unselecting parts of a multi-group. -- LarsClausen - 23 Apr 2004 Dropped the old editing attempt, as it tried to change too much at a time. Now keeping the old style of editing (home-grown cursor and key handling) while changing the way focus works. Here's the rundown on new focus handling (to be in 0.95, I hope): Each object currently calls request_focus if it has a text object. It can only have one area, as the focus is static. Also, there cannot be any tabbing between focused texts. These are the things I'd like to change, to allow all text edit to be done in the diagram. First thing is to allow more than one focus per object. To do this, lib/focus.c holds a list of currently requested foci. One of them (probably the last one) gets to have the active focus. Tabbing can move you back and forth. To show where the focus currently is, we highlight the object with focus (in yellow right now) as well as adding the cursor. (We should also move the diagram to show the cursor.). This is handled by app/textedit.c. There are various actions that can cause focus to change:
- What about single-character shortcuts?
- Can we change the menus while in text mode? Ghost out most, use std shortcuts for text edit? Or maybe have a separate set of shortcuts for text mode?
- Maybe Esc should be cancel?
- Should this happen regardless of current tool, or only for Modify tool?
The focus list should contain exactly the foci owned by objects that are selected. Any change in selection list should be accompanied by change in focus list (possibly through resets). Upcoming change would be to have an explicit editing state (when focus is active) which at first is activated same way as now (by selection/clicking), but maybe should change to something more explicit (starting to type? clicking on (selected) text? Pressing enter?) There's two conflicting issues: On one hand we'd like to have the immediacy of just selecting an object and typing into it. On the other hand, we'd like to be able to do single-keypress shortcuts. Edit mode by starting to type doesn't allow single-keypress shortcuts. Clicking and/or pressing Enter would be usable ways. With an explicit edit state comes also the question of when is it left? Basically, doing anything else in the diagram should lose the edit state, including selecting a tool, but probably excluding zooming/scrolling. To be considered some more. Right now, we let the edit state correspond to selection still. Thus, at first we get
- Click an object -- currently gives the active focus to one of the objects foci.
- Start typing -- should give the active focus to one object (which one?).
- Press Tab -- change to next (or previous if Shift is pressed) text, on same or other object.
- Deselect/remove object -- focus is deactivated and removed from focus list
- Move object -- should probably deactivate focus, as should really a number of other actions.
These are a few of my favorite issues with current text handling, especially the second point. If there are two strings in an object (e.g. name and stereotype), they should both be editable in the object. More advanced objects would probably like to know when their strings start and stop being edited -- for instance to validate the string or to add/remove the <<>> marks around a stereotype. This would require two new object functions. -- LarsClausen - 09 Aug 2004
- Ability to tab through editable texts
- Ability to have several diagram-editable texts on one object
- Better showing of where text edit takes place
| Edit -:- Attach -:- Ref-By -:- Printable -:- More |