-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reduce the "chrome" #2353
Comments
@goanpeca, this seems to be for you :-) |
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). 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:
Now I agree with:
|
@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! |
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. |
@Nodd short lines = more lines..which is the same problem! |
Ok, so since I will be probably working on this (according to @ccordoba12 .... 😈) here are my comments:
Thanks for the rant @d1manson, these things are sometimes needed, ;-) |
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. |
@goanpeca I agree with almost everything: @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. |
@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! |
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:
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: |
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. |
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 :-) |
Agree! |
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! 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. |
@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 |
Hello, 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. |
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 ! |
That's what I do ! |
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. |
It should be possible to provide a menu button for the toolbar. This way you could hide the menubar without messing with the titlebar. |
i just spent ages trying to put a button in the title bar but didn't make much progress. 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. |
(In case I wasn't clear, I meant in spyder's toolbar, not in the titlebar.) |
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 |
Closing because this is too old now. |
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
....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.
The text was updated successfully, but these errors were encountered: