Formal editor interface for tooltips

[corranwebster]

This is a refactor/cleanup that does a number of things:

• makes the tooltip methods a formal part of the base Editor interface. Previously these were supplied by the base toolkit implementations of the Editor classes, so they were there but not documented.
• moves out the logic for finding the tooltip text into its own method (which could be overridden if needed)
• moves out the toolkit-specific code into its own abstract method and making set_tooltip a method on the base Editor class, removing all duplicated code
• adds tests

There are strategic code-generation reasons why I want this done, but hopefully it is useful enough to stand as a clean-up action.

[rahulporuri]

Mostly LGTM with a few comments/questions.

There are strategic code-generation reasons why I want this done, ...

Can you elaborate on what you mean by "strategic code-generation reasons"? I have no clue what you're referring to.

[rahulporuri]

I dont understand why set_tooltip returns a boolean and i'm not sure where/who users the return value.

[corranwebster]

I did check: it is used. Not sure what for, I didn't dig in.

[corranwebster]

Can you elaborate on what you mean by "strategic code-generation reasons"? I have no clue what you're referring to.

"Code-generation" was bad phrasing: what I'm particularly interested in is that code like UIEditors, CodeEditor, and PythonShell which aren't simple wrappers around a toolkit control, but rather wrap TraitsUI or Pyface objects, we still have to have toolkit-specific classes (which in some cases like ArrayViewEditor simply inherit from the toolkit Editor and the common ArrayViewEditor with no other content). In these classes and for similar user-defined classes, I'd like it to be easy to have editors which don't need to have empty toolkit-specific subclasses.

So "strategically supporting new editor generation" is probably better. But as I said, this should be evaluated independently: there is an API that is implemented everywhere, we should raise it up and make it formal.

[corranwebster]

I should add: at some point I may make a similar PR about sizing, as there is an interface there that should be made common and formal, but I haven't looked into it.