Reduce the "chrome"

[d1manson]

This is going to be a bit of a rant, but hopefully I'm not alone in thinking the following...

It would be great to reduce the "chrome" in Spyder, as in what Google did with the web browser.

Compared to a web browser, the need for minimizing chrome is much greater in a complex IDE such as spyder, where you have a whole lot more to deal with than a single "page"...when it comes down to it, no (mainstream) webapp is much more complicated than a single list of stuff with a few areas you can edit...but Spyder has >10 widgets each of which can provide a great deal of information and one of which is a long page of code. Surely it's worth freeing up screen real estate to make room for more/larger widgets.

As the above image shows, I reckon that about 10% of the application's area could be got rid of...and that's with a reasonable sized screen and with the dockwidget titles and tabs vertical (it feels like it's taking up less space that way, it certainly helps for the number of lines visible in the editor).

I've had a quick go at removing the dockwidge titles using this technique in spyderlib\spyder.py:2140....

        if CONF.get('main', 'vertical_dockwidget_titlebars'):
            dockwidget.setFeatures(dockwidget.features()|
                                   QDockWidget.DockWidgetVerticalTitleBar)
                                   QDockWidget.DockWidgetVerticalTitleBar) 
        dockwidget.setTitleBarWidget(QWidget()) # import QWidget from from spyderlib.qt.QtGui

This already makes quite a difference, though you then have to implement a new method for closing, popping and dragging widgets. ..that's easy to imagine for when the widget is docked into a tab with other widgets, but I'm not sure how you'd do it when there are no other widgets in that area of the main window.

The statusbar is a massive waste of vertical real estate...it's reducing the number of visible lines of code by about 5%. It's true that many common applications do have a status bar (Matlab, Sublime, MSWord to name a few), but on the other hand Chrome, Firefox and IE do not....and users do not complain. I would say there are a few options: (a) make it possible to completely hide the status bar in preferences; (b) make a status widget that you can dock somewhere of you choosing (c) make a shortcut to toggle the status bar on and off; (d) condense the information as much as possible at put it somewhere else, e.g. beyond the end of the last menu item (... Tools | View | Help).

Then the toolbar at the top of the file explorer and outline. Both could be context-menu only (in fact, all the outline tools already are in the context menu).

I'm sure there are a few other things that could be pointed out and discussed, but that's enough to be thinking about.

As I am still pretty new to qt I'm not sure how easy it is to do any of the above and whether there are common solutions to some of these issues.

P.S. I would think that most people probably only have a single console running most of the time (as they would in Matlab). So it would be nice to ditch the tabs above the console...that'll save another couple of lines of code.

[ccordoba12]

@goanpeca, this seems to be for you :-)

[Nodd]

I have another solution to this problem: I code in a screen rotated by 90°, so I have plenty of vertical space! It's also useful to write reports, I see a full page at once (a bit more more actually).
I also remove the toolbars, I never use them.

Back to the subject, Yes it's possible to gain some space, but be aware that if the information is too condensed, it is harder to distinguish.

There are a few details where I disagree with you:

• Why gain horizontal space (your red rectangles) when 1/3 of your editor is just blank ? (That's even 1/2 if you keep your lines under 79 characters 😄
• Console tabs are very important for some people like me when execute their scripts in a dedicated console. I always have a minimum of 2 opened consoles: a standard python one for quick computations, and a second one for the script I'm working on. If I remember well there is an opened issue to merge the IPython consoles and the standard python consoles which I find quite interesting.

Now I agree with:

• An option to hide the statusbar (not sure that a shortcut is needed though)
• Add options to the context menu for panes.
• The dockwidget titles could be hidden when the panes are locked (as an option I think, otherwise we couldn't lock them by default).

[d1manson]

@Nodd If I had more horizontal space I'd have another column of widgets, or split my editor horizontally!

Regarding console counts...I'm sure there are a lot of people who use more than one fairly regularly, but it must be rare to have loads open in the way you have loads of editors open. And the console tabs don't really have names in the same way as editor tabs...my point being that you just need a little identifying number for each tab...anyway, this isn't crucial it's just I thought I'd add it to the list.

I agree that you do need to maintain an overall sense of separation between widgets, and new users will probably need more help understanding what each widget is called/what it can do...but once you're familiar with the application you just want more space to put stuff!

[Nodd]

Looking back at your screenshot: you really should shorten you lines of code, you'd have lots of space to add anything you want on the right ! 😜 (there are so many smileys in github!)

When using dedicated consoles for running scripts, the console titles are set to the name of the corresponding console, so it's still useful.

[d1manson]

@Nodd short lines = more lines..which is the same problem!
(Though I accept it's good practice to keep 'em short.)

[d1manson]

Another potential saving, just for the record...look at all this chrome...

On the right of the code editor is the issues strip (I don't know what it's called). In Google Chrome, you get a similar thing when you do Ctrl-F find, but there the find tool shares the scrollbar's section of the screen.

[goanpeca]

Ok, so since I will be probably working on this (according to @ccordoba12 .... 😈) here are my comments:

1. I will add a hide/close all toolbars in the view menu (Add option to toggle toolbars visibility #2426).
2. I can either add an option in preferences or in view (or both) to hide the status bar, although I must warn that I was thinking of putting there the dialog in charge of handling projects (Add option in preferences to show/hide status bar #2425)
3. As far as I know, there is nothing to be added to the menu bar except ... menus... without having to modify the native menu bar in Qt.
4. I can hide dockwidgets titlebars when panes are locked (PR: [WIP] Add maximize pane button inside dockwidget title bar #2288)
5. I will add tabs drag and drop for both editor (PR: [WIP] Add support for editor tab reordering #2372) and the tabbed dockwidgets (Add drag support for dockwidgets sharing same position #2369) so they can be rearranged (this means only altering tab order,,, not dockwidget position)
6. I could look if we can superpose the scroll bar and the warning messages, although it saves space, I am afraid it will look bad... it looks ugly in chrome (my opinion).
7. I do not plan to do anything about the console tabs, I use normally many consoles as @Nodd points out and the info the tabs provides is something I need (and probably many more people)
8. I agree the dock options (close, float) should be also in the menu in every single dockwidget (panes) so they can be used when there is no title bar
9. Although is true that the 79 line limit is a bit "old fashioned" when now we have multiple or large format monitors, I work a lot in the laptop (15.4"), and in this situation 79 lines is a must!, plus in Spyder we enforce PEP8 as much as possible, including the line length limit.

Thanks for the rant @d1manson, these things are sometimes needed, ;-)

[d1manson]

That all sounds pretty good to me...looking forward to it!

With the warning strip..perhaps you could keep it where it is now but make it really transparent so you can see code beneath it. The other related thing, which is probably more appealing to you is (to provide the option) to ditch the other warning strip - the one on the left of the line numbers - and instead display the warning indication as the background color of the line number...e.g. line numbers with a TODO are highlighted in blue.

[Nodd]

@goanpeca I agree with almost everything:
3. You can add a menubar everywhere you want, so to achieve this you'd have to add the menu to the toolbar. (not 100% sure about that)
4. should be an option, because even if I really like it it won't be the case for everyone, especially newbies.

@d1manson The ribbons on the left and right serve different purposes. The left one is for the visible part of the file, while the right one is for the whole file. I use the right one very regularely to check for style errors in files for example.
I don't know if it would look well superposed to the scrollbar.
A way to enhance it (but not gaining space) is to show a tooltip on hover, explaining why the marker appears (like it's done on the left side).

[d1manson]

@Nodd - yeah, I get what the two ribbons are for. Personally I don't often look at (or click) the one on the right, but I do refer to the one on the left a lot. The thing is, if all is well with your code both ribbons are mostly empty so it seems a real waste to have one let alone two taking up all that space. As I say, I think the one on the left is easy to get rid of (just highlight the line numbers with blue/red/orange rather than having an icon, and obviously keep the tooltip).

I agree that the distinction between newbies versus experienced users is an important one. Ideally both should be kept happy!

[d1manson]

Edit: This now exists as a PR: #2368

One final thought for the day!...

I've noticed that most of the time my variable explorer is not visible on screen (it's "behind" some other widget tab). The main reason for this is that its "area-to-usefulness" ratio is not that great...each variable takes up a lot of space vertically and you need to set the width of the widget to be pretty wide in order be able to see the value properly.

It occurs to me that there are 3 usage cases for the widget:

• find a variable that you can't remember the name of or aren't sure if you've currently got*
• check the value/type/size/min/max of a variable...or get a plot of it.
• edit a variable

For the first usage, you only need to be able to see the names of the variables (i.e. a nice compact list is sufficient). For the second case you are generally interested in a single variable at a given time (if you wanted to compare multiple values it's currently not really that easy unless the variables happen to be adjacent in the list), so you could have a tooltip showing you the info that you care about....

[Image updated after original posting]

d1manson/spyder@master...d1manson:compact-variable-explorer

The advantage of this is that because you are only displaying one variable at a time, you have the option to show more data and/or a plot/matshow thing.

For the third usage case, the editing, you either double click the variable name and launch a separate widget, or if you could edit it inline (using the current tool) you can still do it inline, just replacing the name of the variable with the edittext.

If there is a desire for this, then I would imagine it would be best to implement it as a "compact mode" which you can toggle on or off.

(and of course we've already decided to get rid of the toolbar)

Edit:
*this is perhaps a little unfair: there may be times when you cant remember the name of a variable but if you could quickly glance at all the properties [name/value/type/shape/min/max] of all the variables, you would easily find the thing you needed. You could partly address this usage case by letting the user switch which of the properties is the one shown in the list, e.g. the user could just show the value, and use the tooltip to find out the name. But that's a bit clumsy, and still doesnt let the user do a kind of "heuristic" search for the thing they care about (the heuristic might be something like: "a big float array with a time period in the name"). So really, this particular usage case is not well suited to compact mode...but I reckon it's also not particularly well served by the current design either.

[d1manson]

I've done a bit more on the "compact" variable explorer. You can now toggle it on and off from the context menu...but I'm not going to discuss that any more for the time being.

But...back on the question of multiple consoles...is it possible to dock other stuff into the same list? @Nodd mentioned docking all Ipython and standard consoles into a single widget, but wouldn't it be nice to put other stuff there too: personally I would put history, find in files, and internal console, but if there was some way to let the user choose that would be great. If you can manage that, then you save the "outer" level of tabs rather than the "inner" level of tabs.

[ccordoba12]

As I said to @Nodd in another issue: it's not technically possible to show Python and IPython consoles in the same dockwidget, much less history, find in files and the internal console ;-)

Our dockwidgets are not only simple widget containers, but they also have supporting code to communicate between them. So trying to add everything in a single dockwidget would be a total mess, not only from the code point of view but also from UI one too :-)

[goanpeca]

Agree!

[d1manson]

Ok. I've got the compact variable explorer thing doing roughly what I was hoping for, namely it now gives you "lots" of information when you mouse-over a variable, including a thumbnail of 2D arrays...see the updated screenshot above.

It is still a little rough and ready, but I reckon it's worth pursuing...hope you guys agree!
(I haven't submitted a PR for this but you can see my branch - link under the screenshot).

Part of the benefit of having the mouse-over event is that you can compute stuff only on demand (remotely or not), so the "stuff" can be relatively slow to compute if need be.

[goanpeca]

@d1manson can you please open a new issue with your variable explorer enhancement and we can have a discusion there. Lets try to keep issues simple.

Thanks

[d1manson]

@goanpeca I've opened a PR (#2368) for the compact variable explorer.

[ghost]

Hello,
👍 for the "hide all toolbars" option. (why not adding a button for this in the status bar ?)

In no-toolbar-mode, the user will need to keep an eye on the "current directory" while navigating through his files... The current directory path should be displayed somewhere I think, in the toolbar of the "file explorer" pane I suggest.

[Nodd]

I work fine without seeing the "current directory" because I use the option to always run from the directory of the file to be run. Maybe the file explorer should be synchronized the current directory (and the other way around). But it can be left for another PR: if you want to see the current drectory now, just don't hide all toolbars !

[ghost]

That's what I do !

[d1manson]

In terms of collapsing the menu into the window's titlebar (like Chrome and Firefox..although not neccessarily exactly the way they do it), it seems like it may not be completely impossible, at least on Windows..which is what concerns me!

See this gist which is a mirror of a qtforum question. Note also the SO question referenced.

[Nodd]

It should be possible to provide a menu button for the toolbar. This way you could hide the menubar without messing with the titlebar.

[d1manson]

i just spent ages trying to put a button in the title bar but didn't make much progress.
Clearly it can be done in raw C++:
https://msdn.microsoft.com/en-us/library/bb688195(VS.85).aspx
and I believe you can make it work with qt. ..which means you should be able to make it work with pyqt using ctypes...I failed to get it working in pyqt, and I didn't try the basic C++ or Qt-C++ implementations, so it's difficult to know where I was going wrong.

In case I, or anyone else, wants to come back to this at a later date, I've dumped some fragments of the python I wrote into a gist..it wont make much sense but there may be something helpful in there.

[Nodd]

(In case I wasn't clear, I meant in spyder's toolbar, not in the titlebar.)

[d1manson]

i know you didn't mean the titlebar, but I thought I'd have a go anyway...I'd hoped that it might be easier and neater than suspected, but I am yet to prove myself right

[ccordoba12]

Closing because this is too old now.