GNOME Bugzilla – Bug 80363
Location bar, Zoom and View Controls toolbar location should be configurable
Last modified: 2008-01-15 14:46:54 UTC
Some users (aka me) don't use the location bar. However this makes changing the view and zoom level sort of a pain. In macosX finder the view chooser is on the toolbar and i would find this in helpful too. Heres what i'm thinking and it may be a little cracky but anyways: zoom view | traditional navigation arrows | home favorites etc. This is sort of similar to finder, although it doesn't have the traditional navigation arrows. Just a post 2.0 idea
In theory it doesn't sound like a bad idea, however it has a couple of consequences. For one, it would make the location bar look rather empty. Maybe fine with you (since you don't use it) but bad for others who do. :( Also, if we are going to start putting "bookmarks" on the toolbar then this might eat into valuble space there. On the other hand , my second complaint might not be valid, given that that OSX evidently does this. I don't know. Seems bad to me though. Just curious, how often do you use the zoom/view features? I'm wondering cause I like to work on things that make nautilus more usefull so it's good to know what people use. :)
I use them occasionally. I had some other ideas, like moving the throbber to the menubar like is done in windows. perhaps we could have the following organization throbber | \/ ___________________________________________________________ | ___ | |file edit view go help |_T_|| |__________________________________________________________ | |back forward up stop reload |home favorites| zoom view | ----------------------------------------------------------- so that we could use the space the throbber currently uses for the zoom and view controls. I guess if it was possible to configure the location of the actual location bar widget, view control and zoom control via the nautilus-shell-ui.xml file i would be happy, this way someone could write a simple preference dialog to allow users to configure the look of nautilus anyway they want, while providing a good default too.
I really don't think it makes since to start moving things around. The problem is simply that there are too many usefull nautilus controls for one toolbar (and we shouldn't be marginalizing one bar in favor of another unless there really is a consensus that we want to get rid of one of the bars). Your right though, this would all be a mute point if the toolbars were totally configurable. That might be good (I don't know what the cost vs. value of the added complexity would be).
Just thought i'd add that in konqueror the zoom and view controls are on the toolbar, windows i believe has view controls on the toolbar, and in galeon the toolbar has the zoom controls. In each of these other browser type apps, the location bar is unique and only has the location entry box, so there is at least some precedent for my opinion. But i agree making the toolbars configurable, hopefully via the xml files, would make this point mute as long as we have good defaults.
*** Bug 93043 has been marked as a duplicate of this bug. ***
frb@ximian.com said this in the previously duped bug: there is a lot of unused space on the main toolbar, allowing the user to merge the location bar with the toolbar ala galeon's interface would be a better use of space.
I diagree with the idea of merging the location bar and toolbar. This is a problem with galeon and mozilla atm. Konqueror does it well IMHO: http://www.konqueror.org/pics/konq_icon.png. Not the toolbar, but the Location bar looks grand enough I like bordoley's idea of moving the throbber to the menu bar and moving the view and zoom items to the menu bar. I see no problem with having a full location bar. That will make CTRL+L make a lot more sense. I strongly disagree with the idea of making this configurable however. As was havoc's view on bug 86108, I think that by making this an option will remove the inscentive to find the "Right Way[TM]" to do this by default. There is nothing wrong with having a toolbar editor, but moving things from one bar to the other is IMHO not a necessary configuration option.
finding the Right Way would be best, and you do, please file bugs on the other gnome2 apps that don't use it :) Consistency is more important than my personal opinion here.
WEll epiphany's new toolbar editor definately seems like the right way. Unfortunately for nautilus, it uses the egg toolbar code, and I don't anticipate nautilus switching anytime soon.
Dave: Didn't epiphany have the toolbar editor before it switched to egg? Rhythmbox 0.4.x and galeon use the same code AFAIK. IMHO what needs to be done is this: 1. Move the throbber to the main menu and the view and zoom to the toolbar. 2. Try to get toolbar editing encorperated into gnome (ala KDE) within the 2.3 timeframe. If that is not possible add toolbar editing to Nautilus only. But I don't think that moving the items should rely on having toolbar editing. I think that that should be a sepporate bug and we should try and get this and bug 82017 through sooner. 3. Look at whether or not it makes sense to change the ui of our web browsers.
As marco will tell you, the galeon/epiphany bonoboui toolbar editor was no good. I don't know the issues on a technical level, but on a ui level it did not use direct manipulation (the current eph editor lets you drag and drop toolbar items ala macosX and phoenix). I'm incline to believe that implementing such a toolbar editor in bonoboui isn't trivial, but marco would have to comment. So i woudln't count on this for 2.4 really (especially with the nautilus maints decision to not branch for 2.4 development and instead concentrate on stabalization).
Even forgetting the technical problems, I dont think it make sense to hack a bonoboui toolbar editor, since EggMenu is going to be the only way to build menus/toolbars in the future. Quoting Havoc: "To correct one point, the purpose of the libegg toolbar is to replace the others, by becoming the official GTK toolbar. That's the only solution to toolbar problem. The GAL/bonoboui/whatever toolbars just need to be terminated." You may consider reusing galeon code ... Personally I'd dissuggest it for two reasons: - The user interface is far from usable (and there is no way to change it to something similar to mac, phoenix ...) - it's too hard to add new items Just my personal opinion, you may want to talk with ricardo@users.sourceforge.net to get another opinion about this.
I think the main problem is that Nautilus doesn't need a location bar. I mean that the location bar makes people think it's a web browser whereas it isn't (and doesn't want to be). I think the main locations should be included in the sidebar (which is on the way AFAIK). The location bar should be hidden by default and CTRL-L should pop up a location dialog for those who need things like ftp:// or smb://. Or, even better, you should have a network entry in the sidebar. Clicking on it should open a form in the main view containing: server address protocol (ftp/smb/nfs...) port user name password -> GO That way you would never need the location bar. What do you think of that ?
I think that the location bar should be hidden but should still be there for those who want to use it with CTRL+L or by turning it on.
With recent Nautilus versions, you can a) hide the location bar, which then behaves like described in comment 14 b) use spatial nautilus, since the browser is meant to behave like a web browser What remains is toolbar editing, which would not be hard for core Nautilus, but coping with items added by extensions sounds heavily non-trivial.
OK, I've done some hacking recently and the code already looks quiet good. There are some issues to resolve, like what to do if the toolbar doesn't have a location entry and you press ctrl-l (we have to handle that by adding an auto-togggled location bar, but only if it is not already contained in any of the eggeditabletoolbar-managed toolbars).
(In reply to comment #1) > In theory it doesn't sound like a bad idea, however it has a couple of > consequences. For one, it would make the location bar look rather > empty. Maybe fine with you (since you don't use it) but bad for > others who do. :( I feel like this could be written about 2.14. At the moment, the "buttoned" location bar is cut off by the zoom icons and view combo box and the main toolbar is rather empty. When you are browsing a directory a few levels deep, the locations can be cut off because of the zoom/view items. All in all, it's not really workable. > Just curious, how often do you use the zoom/view features? Never, so it seems silly (to me) to have them on the location bar, whose entire width is useful. I share the original sentiment to move the zoom/view items to the main toolbar, or in the case of the view combo box, since they are available on the view menu and are given a convenient shortcut, I would say that it doesn't need to be present at all. Do people toggle the views that often? I would be remiss if I didn't mention this: reading the history of this bug, it's nice to see how far Nautilus has come. At this point, though I'm "complaining", I think it's a very nice program.
Created attachment 71946 [details] tool bar image Because editable toolbars is probably not coming any time soon and and many people do not like the zoom and view as controls being on the location bar. I created a small patch. The patch is quite hackish, and it might not apply to well :(. But if people are keen I will clean it up. The attached is an image of this. It makes it so you can hide the location bar which is really good. The big problem with it at the moment is that if the size is to small you can't use the arrow to select the controls they just vanish.
(In reply to comment #18) > The attached is an image of this. It makes it so you can hide the location bar > which is really good. The big problem with it at the moment is that if the > size is to small you can't use the arrow to select the controls they just > vanish. I think this (screenshot) looks quite good. Again, as I said before, I'm not looking to hide the location bar, but moving the zoom/view controls to the main toolbar makes the location bar available for the full width (so directory buttons won't disappear as quickly). That makes two benefits. :)
Created attachment 71947 [details] [review] patch to move zoom and view as control Here is the patch.
Isn't this bug a duplicate of bug #42834 ?
(In reply to comment #21) > Isn't this bug a duplicate of bug #42834 ? Hmm... by most accounts, yes. However, the two bug reports seem to diverge significantly in the comments. I don't care for toolbar customization in general; I'm mostly interested in this bug for comment #18 and comment #20 (moving the view/zoom controls to the main toolbar). (Comment #12 and #13 on bug #42834 discuss the same thing.) I'm thinking it might be best to mark this bug as a duplicate of bug #42834 and capture that bug in a new report, complete with Stephen's patch from comment #20. Anyone object before I do that?
As per my last comments, I'm marking this a duplicate of bug #42834. I've moved the patch to bug #509660 so it doesn't get lost, and I'm going to push to see if we can get it freshened and accepted. *** This bug has been marked as a duplicate of 42834 ***