Move default traitsui editors over to traitsui

[kitchoi]

After #932, traits will still have some dependency on traitsui caused by implementations of BaseTraitHandler.get_editor that imports traitsui, e.g.:

traits/traits/base_trait_handler.py

Lines 150 to 155 in 3075865

	def create_editor(self):
	""" Returns the default traits UI editor to use for a trait.
	"""
	from traitsui.api import TextEditor
	return TextEditor()

traits/traits/trait_handlers.py

Lines 156 to 178 in 3075865

	def get_editor(self, trait):
	# Make the special case of a 'bool' type use the boolean editor:
	if self.aType is bool:
	if self.editor is None:
	from traitsui.api import BooleanEditor
	self.editor = BooleanEditor()
	return self.editor
	# Otherwise, map all other types to a text editor:
	auto_set = trait.auto_set
	if auto_set is None:
	auto_set = True
	from traitsui.api import TextEditor
	return TextEditor(
	auto_set=auto_set,
	enter_set=trait.enter_set or False,
	evaluate=self.fast_validate[1],
	)

There are many like these. This causes cycle dependency between traits and traitsui in mission critical usage. This makes testing and deployment more difficult. There are already existing efforts for removing traitsui dependency from traits, e.g. #610

My understanding is that (1) this get_editor is only called by traitsui, i.e. traitsui is the sole consumer, but (2) users of traits can override the method to provide a different default editor, instead of writing default_trait_view (default_trait_view is preferred, I think).

For backward compatibility, we need to keep get_editor for use case (2). But if the assumption in (1) is right, we can move the default implementation over to traitsui.

Here are what I think should happen:
(i) Add a warning in all the default implementations of get_editor. This is to test the assumption in (1). Make a traits release with this.
(ii) Copy the many default implementation of create_editor or get_editor over to traitsui.
I imagine it would involve a mapping from TraitType to the default implementation as a function.
I believe this would copy the entire traits.editor_factories over to traitsui as well.
(iii) In traitsui's ui_panel, anticipate trait.get_editor to raise NotImplementedError, and use the default implementation in (ii) for that. In fact, the wx implementation already does it:
https://github.com/enthought/traitsui/blob/b7a409d4e869d1857fcf77e8be47de581e864d41/traitsui/wx/ui_panel.py#L879-L882
The Qt implementation does not.
(iv) Release traitsui
(v) Replace all default implementations of get_editor with a plain raise NotImplementedError. This should remove all the remaining dependency on traitsui (I think).

A few of these steps should happen in traitsui. If this plan sounds good, there should be another issue in traitsui associated with this one.

[kitchoi]

(i) Add a warning in all the default implementations of get_editor. This is to test the assumption in (1). Make a traits release with this.

Before the release, traitsui needs to anticipate and silence the warning, for that's the expected use case. Otherwise it is going to be very noisy for projects using traitsui.

[corranwebster]

The get_editor method is independent of default_trait_view: get_editor lives on a trait and gets the default editor for an item that uses that trait. default_trait_view lives on a HasTraits and gets default view for the entire object.

Both get_editor and default_trait_view (and all the other TraitsUI hooks in Traits, even edit_traits and configure_traits) are problematic, because we are putting TraitsUI-specific things into the Traits API. To some extent this is fine as long as there are no top-level TraitsUI imports and all of these methods are never invoked by anything non-traitsui-ish. But there is also little point in removing get_editor unless we have a path to a completely clean API.