PR: Generate widgets' toolbars from the actions in their context menu & make toolbars toggleable

[d1manson]

the below description has been updated several times...

This is one of the things discussed in issue #2353.
Also relevant is: pending pull #2288 and merged pull #2426.

TODO:

• basic class/factory methods to make the context-menu => togglable-toolbar possible
• refactor File Explorer widget with new system
• refactor Outline Explorer widget with new system
• refactor Help (previously known as "Object Inspector") widget with new system - requires support for multiple toolbar "modes" (qtstacked) and combo boxes (custom ComboAction, subclassed from QWidgetAction)...there are a few bugs still with the OI.
• refactor Variable Explorer widget with new system - a more difficult job, lets leave it for now
  apply to other widgets?

I have created a helper widget called WidgetInnerToolbar and a utility function for constructing instances of that widget from a context menu - context_menu_to_toolbar. For the Object Inspector I had to add some more features, such as support for switching between multiple toolbar "modes" and supporting arbitrary subclasses of QWidgetAction, such as the custom made ComboAction.

The idea is that WidgetInnerToolbar can be registered as a nearly-proper toolbar using the new register_toolbar method of SpyderPluginMixin. It then takes part in the global toggling on/off of toolbars. It also seems a lot neater to collect together all the actions in one place (the context-menu) and then use that to populate other places (the toolbar). I decided to do it this way round because in all cases the widgets seemed to have a "main child" widget that already had its own context-menu, so it seemed easier to add to that and then build the toolbar from the amalgamated context-menu.

This is what the file explorer's context-menu and toolbar look like (note the name|size|type bit is not actually part of the toolbar -I should probably have cropped it out here):

This is what the outline explorer looks like (with toolbar hidden/showing):

And this is the help widget's toolbar and context menu. Note there are two modes: source/plain-text and rich-text.

[ccordoba12]

@goanpeca, would you mind to review this one?

[d1manson]

Since this PR is already touching quite a few files I'd prefer to stop here if possible and leave the other widgets for later - both the variable explorer and object inspector are more messy to deal with, but should be reasonably self-contained projects.

[goanpeca]

I will, but on the weekend!

[d1manson]

I got a bit carried away and decided to tackle the object inspector. It basically works now, with a few minor bugs in the history-combo interations. I have updated the original post with a new description and more screenshots to explain the state of this PR.

In terms of fixing the remaining OI bugs, I guess I will aim to do that in the near future, but I should say that I never quite understood all the expected behaviors of the original widget...both the code itself and the UX were a bit all-over-the-place...which is to say that maybe a more general refactor of the OI is merited (but not something I want to do here if possible).

@goanpeca, @ccordoba12 - if you have a chance to try this out and give me some feedback that would be good...As I said before, this PR touches quite a lot of files (11 currently), a few in fairly major ways (the three widgets) so it would be a great to get it processed quickly-ish..although that never ends up being easy I guess.

[ccordoba12]

@d1manson, tests are failing for this one, please review the Travis log :-)

[d1manson]

@ccordoba12 travis is happier now, although fix was a bit hacky.

Note that I'm not expecting you guys to be 100% happy with the code as it is, there are a couple of hacky aspects to it (e.g. import statements within functions, where global import wasn't working..not a big deal performance-wise because the functions should only be called a handful of times at startup, but still rather ugly code).

Mostly I was hoping for feedback on the functionality and possibly some suggestions on improving the way I've structured the code.

[goanpeca]

@d1manson can you rebase this?

[d1manson]

@goanpeca I've rebased.
Travis is passing but AppVeyor is giving a meaningless Command exited with code 1 error.

[goanpeca]

Thanks, @ccordoba12 can you take a look?

[ccordoba12]

The error is real (I rebuilt the PR to verify that! :-)

The error code means that codeeditor just crashes when running its test. So you need to run the test locally to see what's happening.

[d1manson]

@ccordoba12 I've installed 64 bit conda and setup a python 3.5 environment. When I run the command:
python "spyderlib\widgets\sourcecode\codeeditor.py"
It just launches a standalone instance of an editor widget. This is the same whether I am on master branch or my PR branch. Other tests (such as ...\base.py) run and terminate within a second or two (without complaint).

What am I doing wrong?
P.S. I'm a bit of a noob when it comes to CI testing.

[d1manson]

I dunno what was wrong, but following the latest rebase it's now working again.

[goanpeca]

@d1manson again can you merge with master (or rebase..) there seem to be some conflicts...

Also what is the status of this PR?

[ccordoba12]

Closing because (although interesting) we don't plan to go for this.