GNOME Bugzilla – Bug 42834
please add a way to customize the toolbar
Last modified: 2017-07-28 03:35:57 UTC
Hey, a user might just feel like sticking the "stop" button in the bottom toolbar instead of the top, right? Or maybe he just doesn't want the url entry toolbar for whatever reason? Well, those uses are alittle absurd, but it would be nice, for instance, to stick all of the bottom toolbar items into the top and then remove the empty bottom toolbar, saving lots of vertical space. Especially in conjunction with, say, allowing the user to remove some toolbar items. This would be nifty. The less real estate the user can force nautilus to take up, the better! Regards, -Jared Johnson <solomon@futureks.net> ------- Additional Comments From arlo@workthatmouse.com 2000-09-06 00:30:37 ---- A post 1.0 feature request. I know we talked about eding the toolbar as a post 1.0 feature, but I can't find a bug for it. Perhaps we can make this one it (sans merging the location bar). ------- Additional Comments From arlo@workthatmouse.com 2000-09-06 00:31:18 ---- *** Bug 42833 has been marked as a duplicate of this bug. *** ------- Additional Comments From andy@eazel.com 2000-09-06 00:45:52 ---- Changing the name to "Toolbar Customization UI". It would be great to have drag and drop customization of the toolbars and menus - toolbar buttons are really just prominent menu commands, and it would be great for the user to be able to edit them. ------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:38 ------- The original reporter (solomon@futureks.net) of this bug does not have an account here. Reassigning to the exporter, unknown@bugzilla.gnome.org.
seth: do you have an opinion on this. I'm leaning towards wont fix, but what do you think.
If this is going to be implemented there is a toolbar editor shared between galeon and rhythmbox now that can be used.
Let's get the usability people into this discussion as well.
I like the idea of toolbar customisation in general, and it should certainely work the same between GNOME applications. I'm not a huge fan of RhythmBox/Galeon's toolbar editor. I'm not sure why this can't be done as direct manipulation of some sort (drag toolbar items onto the toolbar from a palette, that sort of thing). The reason toolbar customisation is good is that while most people use few items, many people use one or two items frequently that most other people do not. Allowing toolbar customisation can actually allow us to shrink the toolbar because its less important that, say, refresh or stop be on the default toolbar (hypothetically, not sure how I actually feel about this) if only 10% of people find it useful and important. A critical aspect of this working though is that customising the toolbar needs to *not* be some sort of advanced operation :-)
I can customize toolbar in Epiphany browser, maybe nautilus developers can steal toolbar customization code from Epiphany ?
*** Bug 144938 has been marked as a duplicate of this bug. ***
Its one of those indispensable features for me that allow me to use my lappie in this way: ftp://81.86.159.146/latest.png I personally really like some ideas in nautilus and galeon, but until the menubar and toolbar has some customization features like allowing you to toggle them on/off, I'm sticking with konqueror. In my opinion, gnome should take an example from osX and KDE and how they completely detach the menubar from applications for system wide concistency. But to each his own I suppose.
*** Bug 304710 has been marked as a duplicate of this bug. ***
Bug 304710 suggests that one should be able to drag the location entry to the toolbar as well.
What really produces headache is the fact that we have plugins which can add toolbar items themselves. These shouldn't be modifyable, should they?
*** Bug 309818 has been marked as a duplicate of this bug. ***
First, sorry for the dupe. The need for a epiphany-like toolbar editor was something I felt instantly after testing today's CVS which includes the pathbar. navigating using the pathbar is very nice, but the Zoom/View widgets really get in the way for longer paths and they are not very useful anyway. Zoom level is better set globally using the preferences, and for the (in my opinion very uncommon) case of per-folder-zoom control, we have the View->Zoom In/Out entries. Same for the views dropdown, this had a use in earlier versions where there was a html view and stuff like that but now, for only icon/listview changing, View->View as Icons/List is as fast or even faster. Also, not having used the browser mode after spatial navigation was introduced, I noticed that the "Views" dropdown is not there when the window opens but is inserted a few ms later... this makes the zoom control move to the right which looks... strange.
I pretty much agree with you Michael. The "View as" selector really looks redundant now that we even have view accelerators for fast view switching. The zoom control could be replaced by something like in ephy, which is essentially a combobox with various zoom levels.
@Christian: What plugins are you talking about? Things like nautilus-cd-burner? Those icons could just be added after a separator, following the main toolbar. I don't use epiphany myself so when evince added the toolabr editor, it was the first time I saw this used in a gnome application. First thought was: why would we need this? But it's obvious that different people have diffenrent usage patterns, so for some, having a given toolbar item makes sense, for others, it wouldn't. For example, why would someone who uses nautilus in browser mode with the playes sidebar open all the time want to have the "Home" and "Computer" shortcuts displayed in the toolbar? They just add complexity to the application, it gets harder to scan for what you are looking.
Michael: Yes, the Nautilus extensions. It may be a good idea to just attach them to the first visible toolbar. I'm not sure whether we want to distinguish between a special location bar and a "normal" toolbar. Epiphany just displays all of them or none, while for us a temporarily-visible location bar is still desirable if the user presses ctrl-l but has the location bar disabled. But then again, why shouldn't we just do what Ephy does in fullscreen mode - show a reduced toolbar with just the basic controls.
I've egg-editable-toolbar code floating around already, the problem is that it won't work properly with a temporarily showing location bar. Such a regressions isn't acceptable.
How have you implemented this, are all items on the main toolbar and the location bar editable? I think the way to go is getting rid of the "main toolbar" and "location bar" concepts and just let people add items as they please... Meaning today's "main toolbar" will tun in toolbar #1 with standart items: "back|forward|up|stop|reload|separator|home|computer|special items|flexible space|throbber" Note the "special items" here... This includes elements like the nautilus-cd-burner icon, which are only displayed/added to the toolbar if the current location uses such a special item. In the egg-editor there would be just a "special items" placeholder item. Also, "flexible space" is meant like it works in Firefox. In analogy to this, today's "location bar" would be turned to toolbar #1 with: "location/pathbar|zoomcontrols|views dropdown" The toggle-able location/pathbar element would just use all the space it can get besides the other items. This would keep the look&feel just as it is today, but you would be free to remove elements you don't need or move elements you need from one bar to the other and get rid of one bar. For example I would like a one-toolbar setup with just the elements: "back|location/pathbar" because the pathbar doesn't allow to navigate back in some cases (after using a vfs uri) and displaying a full main toolbar for this is overkill. Also, I don't need the other controls, the throbber, zoom or view elements so the space could saved. This would be... a file management dream come true ;-)
> How have you implemented this, are all items on the main toolbar and the location bar editable? Yes. > I think the way to go is getting rid of the "main toolbar" and "location bar" > concepts and just let people add items as they please... > Meaning today's "main toolbar" will tun in toolbar #1 with standart items: > "back|forward|up|stop|reload|separator|home|computer|special items|flexible space|throbber" > "location/pathbar|zoomcontrols|views dropdown" I've not yet implemented the extension bits ("special items"), and I've not yet done the toolbar editor dialog integration, but all the actions are loaded fine from a global XML file with the default toolbar layout. When it comes to extension items: I'd just append them to the end of the first toolbar we find, but before the throbber. Maybe we should also add a know in the toolbar editor which can be used to define whether the toolbar items should be added at all.
Personally I feel that using such a special entry to specify where extensions can place their icons is cleaner (one of this, globally, if there are more then one extension icons for a given location then put them all there). This way you don't have to check where the first toolbar ends and if a throbber follows and it is still configurable at no cost. However this will be implemented, i'll be happy if I can disable zoom and views. I suppose this will make it into 2.14 at best?
Yeah, it requires testing and we're feature frozen for 2.12 already.
Ok, 2.14 then. I'm amazed by the number of improvements nautilus has made during this cycle, anyway... some *really* nice stuff! But when a patch is ready, just attach it to this bug, missing testing won't prevent this from getting into 2.14 ;-)
So with 2.13.x on the way now, any news regarding this?
No. If I remember a discussion with Alex on IRC correctly, he wasn't too fond of getting this into Nautilus since he considered the gain relatively small compared to the major code changes required, and he feared bloat. Don't nail me on that, though. Alex, maybe you could drop a comment?
Hmm... IMHO, the zoom widget and the view dropdown is bloat. I was mainly looking for a way to get rid of this. For example, if I open my downloads folder, the the dropdown starts in a collapsed form, then expands a few centimetes to the left when the text is added and the zoom widget gets moved, too. Also, we already argued that both are not really useful for most users... making those elements optional would be the ideal solution... a toolbar editor would be the natural choice for that.
My opinion of this is that it is hardly a super-important feature. However, I don't think its actively bad, so I wouldn't mind if someone worked on this. (Given that the editor is easy to use, the code is clean and it doesn't regress anything)
Created attachment 54675 [details] [review] Very prelimitary patch I've ceased to work on this. I'm posting it so that my work doesn't get lost. A very prelimitary version which still has issues like - drag a singleton action (view, zoom, location action) => crash (is the model assuming that we destroy the proxies?) - no location bar in toolbar => ctrl-l won't work (maybe we'd have to reintroduce the location bar and pack the location entry into it whenever it isn't present in any of the EggEditableToolbars?)
Created attachment 54677 [details] [review] Additional files NautilusToolbarsModel also needs some more love.
Updating bug status.
I'd love to replace all the options: File, Edit, View, ... by just one: Menu using the rest of the space with buttons and having everything in just one line
I think this really is a pretty nice feature, not non-important at all, it's not that important, yes, however it's the solution for the zoom/view change/home/computer issues. I'd really hope to see this feature in 2.14 or 2.16 at least, (note: I'm not a coder (yet), I couldn't do it myself, although I'd love to). I'm actually just using the location toolbar, and I'd love to have a back|forward|stop (once bug 345192 gets love)|special items|location bar. I'm sure everyone would edit the toolbars from the current state they are, in one way or another. About the Ctrl+l when there isn't location bar... I think a bar like the one used by the new search stuff should be added with the textbox for the location bar and a go button... The code is all there, it's in epiphany, heck, even mail-notification has this feature having only three buttons available for the toolbar (yes, it's overkill... but if they can do it, whay can't nautilus do it too?)
(In reply to comment #25) > My opinion of this is that it is hardly a super-important feature. However, I > don't think its actively bad, so I wouldn't mind if someone worked on this. > (Given that the editor is easy to use, the code is clean and it doesn't regress > anything) > > My opinion of this is that it is hardly a non-important feature. This is among the first things a user would like to do on a fresh install. File management is a fundamental need, so customizing the file-manager is a priority. You have to realize that this feature is very important. Though the needs and uses of the toolbar might vary, having a customization tool is mandatory. I'm not a coder myself, otherwise I would try to do it myself. I just posted here in order to show that there is interest in having such a feature. Cheers!
I think this is a fundamental feature for a real user-oriented File Manager. Think an integration with nautilus-actions http://www.grumz.net/?q=taxonomy/term/5/9
i know i misse the main conversation, i just thought i would throw my two cents in. i'm using 2.18.3 now and i have yet to figure out how to "customize" the tool bar. personally i would like the following {| File | Edit | view | Go | Bookmarks | Help | Back | Forward | Up | Stop | Reload | Home | Computer | Location | Search |Throbber |} where {| Back | Forward | Up | Stop | Reload | Home | Computer |} would be set as small icons. pretty much the same way i have iceweasel set up. also i thought a "gnome-panel" like bar would be nice for adding launcher as they would relate to file management, for example a launcher for a script that will archive everything in the current viewing window, or tab, as i also thought that would be awesome.
*** Bug 80363 has been marked as a duplicate of this bug. ***
Bug #509660 has a patch that was introduced in bug #80363. The discussion there was to move the Zoom and View As controls from the main toolbar. (Comment #12 and #13 here discuss the same thing, with the possibility of removing them from the toolbar.) I separated the patch so it can hopefully get some more attention, and maybe even get committed. ;)
*** Bug 480379 has been marked as a duplicate of this bug. ***
*** Bug 379403 has been marked as a duplicate of this bug. ***
*** Bug 417353 has been marked as a duplicate of this bug. ***
1°) Actually, Evince/EoG/Epiphany (for instance) allow user to configure toolbar 2°) Besides, EoG 2.22 allow user to "reset to default" the toolbar. I'm convinced that the 1st functionality (configurable toolbar) goes with the 2nd (allowing reset) (it sounds like that GUI "principle" which say something like : allow the user to makes mistakes) There are bug reports related to the "reset to default" option : Bug 487643 (Evince), Bug 480975 (EoG - bug fixed in v2.22), Bug 319785 (Epiphany) Both options (configurable toolbar plus reset option) would be great 3°) i also think that there should be concertation between these projects to unify the way of implementing these fuctions in GUI Evince : Edit menu -> Toolbar (without reset button) EoG : Edit menu -> Toolbar (with reset button) Epiphany : View menu -> Toolbar -> Configure (without reset button) (since i'm running french versions, terminologies may differ) Nautilus : ...
this bug is related (but not exactly duplicate since the corresponding icon doesn't actually exists) : Bug 480382 – Add a "create new folder" button on the toolbar
Updating fields and setting patch to "needs-work" as for comment #26 and comment #27. This would be nice to have for 2.24.
... 2.26 ... 2.28. I don't belive that anyone is actively working on it, this way it will go in never. Original request is from September 2000. ... This is one of the things I dislike in GNOME. It's too slow, everything takes to much time and more. This here (8 Years), Project Ridley, GnomeVFS -> GVFS transistion ...
*** Bug 582475 has been marked as a duplicate of this bug. ***
Created attachment 138712 [details] Screenshot of WIP I've been working on getting Andrews patch up to date. Things are going quite well and I can now edit the toolbar although not all widgets are working yet (I missed the nautilus-singleton-action.* files from the patches, but I think I can manage without it). Screenshot attached.
Will there be also a way for extensions to provide new buttons? I hope this to be finished for 2.28 :)
I've got some question about the implementation. Should it be possible to select the style for each toolbar or the same for all of them? System default, icons, icons and text, icons and text horizontal, text? How to create new toolbars? Right click the toolbar in edit mode? Or in the toolbar editor window? Design team? Where to store configuration files? .nautilus xml file or gconf? (Both default and user setting) Where to edit the toolbar? Editor menu -> Toolbar? Right click Toolbar and Edit Toolbar? Both? Design team? Could we start with only customizing the toolbar and not the menu this first round? Right now I'm using the toolbar editor from Evince - should I stick with that or go with Epiphanys instead? Later I'll also need some help with the build script, atm it's kinda hackish. About widgets and stuff - I'll do that later when all the infrastructure is in place (extension buttons and stuff - gnome 3.0?). Christopher, me too :-)
i've made a few statements in my comment 39 since at present time Evince/EoG/Epiphany both allow user to configure toolbar there should be concertation between these projects to unify the way of implementing these fuctions in GUI Evince : Edit menu -> Toolbar (without reset button) EoG : Edit menu -> Toolbar (with reset button) Epiphany : View menu -> Toolbar -> Configure (without reset button) (since i'm running french versions, terminologies may differ) Nautilus : ... Also, note that Midori browser (which is a GTK+ application but not a GNOME one) has in git an extension which allow to edit its toolbar in a different way that Evince/EoG/Epiphany but i perfer the Evince/EoG/Epiphany way Besides i think that toolbar editor should have a reset option thanks
(In reply to comment #46) > I've got some question about the implementation. > > Should it be possible to select the style for each toolbar or the same for all > of them? System default, icons, icons and text, icons and text horizontal, > text? I'd go for an implementation similar to the Epiphany one, where the toolbar style is global for all the toolbars inside the application. > How to create new toolbars? Right click the toolbar in edit mode? Or in the > toolbar editor window? Design team? In Epiphany the toolbar editor has an "Add toolbar" button; I think that's a fine choice. > Where to store configuration files? .nautilus xml file or gconf? (Both default > and user setting) If you use EggEditableToolbar with EggToolbarsModel, you will have facilities to load/save from XML, so I think that would be a better choice. A better location for that should be .config/nautilus/ though, rather than .nautilus/ > Where to edit the toolbar? Editor menu -> Toolbar? Right click Toolbar and Edit > Toolbar? Both? Design team? I'd say both, but Epiphany puts the toolbar-related actions under the View menu. > Could we start with only customizing the toolbar and not the menu this first > round? Which menu? I don't think the regular menu entries should be customizable at all. > Right now I'm using the toolbar editor from Evince - should I stick with that > or go with Epiphanys instead? AFAICS both use EggEditableToolbar, maybe with some light customizations, so I think that's what we should use as well. > Later I'll also need some help with the build script, atm it's kinda hackish. Sure; do you work in a GIT branch somewhere? That could be useful so that other people could join development as well.
Cosimo Cecchi, thanks for answering. > Sure; do you work in a GIT branch somewhere? That could be useful so that other > people could join development as well. Never worked with git before (only svn), need help with getting that up and running. At the moment I'm kinda stuck - I've created action of all the special widgets (location, zoom and view chooser) but I can't get to work when moving the actions (using the controls from window->location etc) when re-parenting. Also as I'm new to both C and GTK, I'm not sure about when to use connect_proxy and create_tool_item. #nautilus?
Created attachment 138851 [details] [review] Early patch adding editable toolbar OK. Here's a very early patch that adds an "kind of" editable toolbar to nautilus. Is really unstable and code is not clean up yet. Just releasing if someone would be interested. Hopefully I could have a clean up version later this week. What I do need help with is the new actions, so if you got any tip of how to get them working (not crashing after moving) please share it with me :)
Created attachment 138852 [details] Obligatory screenshot (nevermind the button order, will fix later)
Cosimo, Marcus, I strongly suggest that Nautilus disable multiple toolbars, or at least make it difficult to discover by placing "Add new toolbar" in a menu. The decision to promote using multiple toolbars by facilitating their creation in the toolbar customisation window should be driven by user data, not by the mere fact that Epiphany has this feature. Ask yourself if this is a good feature -- why would users want multiple toolbars? How many users would benefit from more than one toolbar? You may actually be encouraging users to make Nautilus *less* usable with this feature.
(In reply to comment #52) > Cosimo, Marcus, I strongly suggest that Nautilus disable multiple toolbars, or > at least make it difficult to discover by placing "Add new toolbar" in a menu. > > The decision to promote using multiple toolbars by facilitating their creation > in the toolbar customisation window should be driven by user data, not by the > mere fact that Epiphany has this feature. Ask yourself if this is a good > feature -- why would users want multiple toolbars? How many users would benefit > from more than one toolbar? You may actually be encouraging users to make > Nautilus *less* usable with this feature. > Obligatory link: http://davidsiegel.org/nautilus-simplified/ Looks great David!
Created attachment 138943 [details] [review] Cleaned up some code I've done some cleanup on the code so its a little bit more readable, but still huge because of the copy-n-paste code from libegg. However, I need help on how to get the actions working. It would be great if someone could take a look at the code for the View Chooser action and give feedback whether this is the right approach, and if it is - how do I get it to work? I'm not sure when to use connect_proxy and when to use create_tool_item... If I get help with this one I think I could manage to do the other. TIA
(In reply to comment #4) > I like the idea of toolbar customisation in general, and it should > certainely work the same between GNOME applications. I'm not a huge > fan of RhythmBox/Galeon's toolbar editor. I'm not sure why this can't > be done as direct manipulation of some sort (drag toolbar items onto > the toolbar from a palette, that sort of thing). Haven't read whole thread, but here's an idea on customization UI. Provided there's an option somewhere in the menu for "Customize Interface", all elements in the UI get to be drag-n-doppable (possibly draw a square or something around "objects" to emphasize them). Additionally, the part of the UI where files were displayed now gets to show a row of buttons (something like the "empty trash" button, but with "Apply", "Cancel", "Reset to defaults") and below that all the available objects the user can drag to the interface (or drag from the UI into this last box to delete obj from the UI). |-----------------------| | current UI objs | | |-------------|| | | Apply, etc. || | |-------------|| | | available || | | UI || | | objs || | |-------------|| |-----------------------| It's still the same "drag-n-drop what you want to add/delete in the UI" idea, but it seems... don't know... nicer :) Additionally, the "available" list of obj can have a scrollbar and show nice things such as descriptions of objects. Just a quick thought. apa!
Cosimo, and others, I've now manage to get the patches into a git tree [1] with help of the friendly people in #nautilus (thanks again) and manage to get a buildscript that at least compiles code (more work is needed here). A short todo list exists in the TODO-toolbareditor file (it's not complete but it's a start). Overall, it works pretty well but I would like more eyes on the code telling me how it can be improved. Comments, suggestions (and patches) are of course welcome! [1] http://github.com/MDC/Nautilus-Toolbar-Editor/tree/toolbareditor
Created attachment 142435 [details] Updated screenshot of WIP
These patches are obsolete; some up-to-date code for this can be found here http://github.com/cosimoc/nautilus/tree/toolbareditor
*** Bug 605915 has been marked as a duplicate of this bug. ***
It appears that the Nautilus Elementary fork have integrated the toolbar editor from Midori browser http://www.omgubuntu.co.uk/2010/06/nautilus-elementary-adds-toolbar-editor.html
Patch from nautilus-elementary toolbar editor, patch generated from nautilus git commit 38986e1c0773299a7efa9f7333d5d0c513a8b66c http://dl.dropbox.com/u/4135996/ne_toolbar_editor.tar.gz don't forget to copy the following files attached in the archive: src/nautilus-toolbar-editor.c src/nautilus-toolbar-editor.h nautilus-toolbar-editor.c is an adaptation from the midori toolbar-editor extension to nautilus. You can launch the toolbar editor from edit menu, or simply right click on the menubar/toolbar. This right click menu contain some other view option that can improve usability like : - Show Hide Toolbar - Show Hide Sidebar - Show Hide Statusbar This patch was quickly adapted from nautilus-elementary code, and some widget may be uninitialized like ViewAS and zoom. It's just here for demonstration as you're not interested in this patch in it's current form (ie: you prefer an implementation like eog/epiphany (EggToolbarEditor) ). Happy testing !
Changing component as a part of ongoing bug reorganisation work.
We decided to streamline the nautilus design for 3.0, and we finally decided there's no use for an editable toolbar in Nautilus. Thanks to everyone who contributed code to this bug, but now it's time to close this as WONTFIX.