One of my m5 tasks was to implement consistent editing operations, and
I've just landed the changes I've made: they add a localizable context
menu in (almost all) the places you can edit text in Chandler, and do
their best to ensure that the main Edit menu's items work properly. (I
say "almost all" because the Calendar uses its own wxTextCtrl subclass;
I attempted to change it to use the AETextCtrl where most of this is
implemented - this didn't work trivially, so I decided to get this
working everywhere else and revisit the calendar later.)
This brought up a few issues (at the wx, CPIA, and UI levels), which
I've resolved for now to allow us to go forward; I expect they'll get
revisited as necessary:
- UI: We have a "Remove" operation, which removes the selected item from
the current collection; it looks like the intent was to use this
operation where the various platforms use "Delete" or "Clear" - the
operation that removes the selected text without putting it on the
clipboard like Copy would. It didn't seem right to me to re-use "Remove"
for this text operation, and doing so would have complicated things
internally a little, so for now, I've added a separate "Clear" item to
the Edit menu that only applies to text (and is disabled unless there's
a text selection to be cleared). I'd like the design folks to think
about this a bit and we can figure out (for 0.7) whether we need to
recombine them.
- UI+CPIA: The "Remove" menu item used to have "DELETE" as its built-in
accelerator key. Attaching this accelerator directly to the menu
prevented text controls from receiving the 'delete' key, which irritated
my good friend Pieter. I've removed this accelerator from the menu item,
and added a key-up handler to our Table code to replace it -- this has
the behaviour I think we want (the delete key works as Pieter expects
when editing text, and the delete key does "Remove" when the focus isn't
on a text control and there's a table with a selection somewhere in the
focus chain, and nothing happens the rest of the time) even though the
label on the menu item isn't there. (The accelerator label isn't there
on most apps/platforms, so I don't think this is a big deal).
- CPIA: I've implemented the popup menu for editing operations as a
wxMenu directly - I'm not using the CPIA menu-building mechanism. This
seemed like the simplest thing that would work, and we don't currently
have a need for a dynamically-built context menu for editing. Someday,
we will, and this'll get revisited. (Confidential to "Concerned in
Hawaii": I am using _('localizable strings') to build it)
- CPIA: The Undo and Redo CPIA events used to be sent to the active view
(ActiveViewBubbleUp); to allow edit controls to get these events (and
enable/disable the menu items, etc) when they have the focus, I've
changed the event definitions to FocusBubbleUp.
- UI: The Undo menu item's enabling/disabling mechanism used to also
change the text of the item: "Undo Command" if it was enabled, and
"Can't Undo" if disabled. I've turned this text-changing off: it doesn't
add anything (unless we're planning on having all menu items change
themselves to "Can't..." when we disable them ;-), and is incorrect if
the thing being undone is an edit operation, not a command (which, for
now, all undoable operations are). I expect this can get revisited when
we work on Undo support, which I know John has thought about.
- WX: The edit controls on different platforms work differently... I
didn't test everything everywhere, but I know that on Linux, the popup
menu isn't driven by wx correctly, so I wrote explicit code for that
platform to make it work. Also on Linux, the textctrl.Clear() operation
works as documented ("removes all the text in the control", independent
of the selection), though on the other platforms, it works the way we
want (I'll talk to Davids about this offline to see whether this is
something we should try to fix (or get them to fix) at the wx level. For
now, I think everything works on all platforms, but I expect their might
be inconsistencies I didn't find.
- CPIA: I noticed that the editing-related events (including copy, for
some reason) are marked commitAfterDispatch=True, which seems overly
general: it means that if you do one of these operations while editing
text in an attribute editor, a commit will happen that won't save the
edit you just made (because we don't write text changes back to the
content model after these editing operations - they're handled by the
textctrl directly). I didn't change this, but it seems like something
that might be better handled in the item-specific editing operation
handlers, instead of globally on the event itself.
Known bugs? Only two:
- Remove doesn't seem to work the first time in the summary view; I'm
waiting until after the sets merge to investigate this.
- Calendar-panel editing doesn't get these wonderous benefits yet.
...Bryan
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
