After having to modify Preferences many times as I helped another user I thought “Would it not be great if Preferences had an Icon.”
This was not the first time I thought this.
But after figuring out how to add the icon and functionality, I realized that maybe for the average user this would be a nice but not necessary option
I added the icon next to (before) the Configure View icon so it shows in all views.
Attached is the proposed icon shown in both the light and dark Adwaita themes.
/ 
Submitted the Feature Request along with the pull request.
I added an Icon for the Plugin Manager and moved the icons to the last icons.
New Icon displays.
how about right-click on any menu item and this next menu has an option to make the icon. then if you choose it you get a subpanel with all the operations to make it. hot-key might be another choice there.
User customizable toolbar is essentially adding a single step macro interface. It seems like a step towards a bottomless pit of coding.
If you do pursue the idea, I suspect that “right-click on any menu item” would require adding code at too many places and be too hard to maintain.
Instead, right-click on empty space in the in the toolbar brings up a macro recorder dialog that monitors the GUI. And this allows a button to be assigned to the next menu selected. Alternately, that opens the log file and allows a button to be assigned to an action there.
as i see it, doing a right-click is just a user-input event with some information. that it is a right-click, what keyboard keys are down, if any, where the mouse pointer is (over what object), and the context (what is active, recent user history, configuration). with this as the search key, look up registered handlers from most detailed matching to least. i picked right-click as an example. the code that initializes doing icon management could register alt+shift+left-click. and that preference should come from the preference lookup. this might well mean well-coordinated library-API, but not a bottom-less pit of code. the icon manager would see it as a request for an icon by the code registration tags, which add to the context. it would see which object was referenced (where the click was made) and thus know that it is asked to deal with an icon for that object. it would not be needed to make code for each object as the common icon handler can do it as long as it has the context information. i hope Gramps is not using a run-away code design. its code should focus on genealogy specifics, not GUI specifics.
I wanted to tell you that I thought that we should add a separator in the icon bar … but there is in Gramps … I just noticed 
So I will say that these separators are much too discreet in Gramps because they have an important meaning at the interface level.
I attempted to add the separator but when I attempted it, my Gramps froze. I am NOT a coder. I can only take what others have created and attempt to make it do what I want.
The icons are now at the end of the list of icons. If a view (like Media) has view specific icons, they will get added between the Open Tools and the new Open Plugin Manager.
Spent a day and a half actually reworking the actual icons. Here is what was settled upon. Actually learned that we (Gramps) have an icon scheme.
I’d like to see your ‘gear icon’ replace the Config icon. (I believe the standard Tango icon for Preferences contains crossed Hammer & Monkeywrench.)
My reason is simple practicality. There is a 
Gear unicode glyph. That means we can use it for all the sections where there is user configuration documentation. There are a LOT of those. (It is searchable too.) But, besides the main Preferences Wiki section, there are only a few Add-ons that add a preferences tab.
HTML Entity (decimal) ⚙
HTML Entity (hex) ⚙
Nick H and I discussed using the Screwdriver/Spanner icon for Preferences. But this icon is superimposed on the generic Gramps view icon to set each view’s configuration. I do not think it wise to change an existing icon.
Gramps icons are pulled or derived from the Tango guidelines and icon set. So keeping the new icons “feeling” the same as the existing icons was limiting.
Personally, I do not see a conflict. The Gear/Cog will open Preferences from every view’s icon tool bar. The symbol is becoming universal to set user preferences for most applications.
That does not negate its use in the WIKI to highlight user configuration documentation. The Cog/Gear is taking the user to the area; within Gramps itself or in the documentation, where they can exercise control of their experience.
You dont need to add one … there is already one (but so small).
In the picture you have posted your icons are well placed.
I think a single separator (more than 1px wide) might suffice in the Gramps icon bar.
This separates the actions of the Gramps application from those that are context/category specific.
This would improve the look and feel of the interface IMHO.
Thank you
I tried again and found the right lines of code. Was using the wrong instance of the code.
The segment separators are faint but there.
The appearance of the separator is defined in the style sheet; so it should be the same across all Gtk applications. So if you want it wider, modify your system styles…
Here’s a curious alternative…
Developers can add a View mode toolbar icon via the registration in the .gpr.py of an add-on. And add-ons can be added or removed.
Perhaps a Tool shell addon could be created that Calls a menu command & adds to the Toolbar?
Personally I’m happy with the Preferences in the Gramps menu. I wouldn’t clutter the interface with an icon for it. CMD-, works just fine.
PS I’m very happy to have the developers work on GUI issues.
I’d give this a +1000 agreement, if I could.
all in a menu that’s not hard to find sounds sufficient to me. my thinking was user defined human interface customization. but do we need to spend valuable developer time on that? likely not.
Just to be clear, I am not a developer.
I was/am just offering up to the rest of the Gramps community a hack of the code that I am finding immensely helpful. I have offered it up, whether or not it is implemented is up to the developers.
Any other user can go the code and implement it on their system today. Or not.
i have the Gramps 5.1.3 version on my Xubuntu 18.04.5 LTS (bionic) system from the Ubuntu package. i would need to decide on how i want to manage unofficial patches before i can put your code in, if i wanted to do that. i didn’t catch how your code comes, a full new tree, a tree of replacement files, a tree of patches, a script to perform modifications … does it apply to the installed copy, a staged copy, a source copy to make a package. that would be a factor in how i manage it. i would want some kind of identity. then i would have a list of dependencies and a list of which i want (i depend on these).
just to be clear, i am not a formal developer, though i have done some development, but not with GUI apps, unless you count a few web apps as GUI. i have done both C and Python.
All the code is held at github. My pull request is here.
Files will show you what lines of code I added to one file and the 10 icon files. Re the icon files, all you really need are the 2 svg files.
Alter your existing grampsgui.py file and add the icons and the next time you launch Gramps, the icons will be on your tool bar.
Gramps is written with Python.
The proper way to manage patches through GitHub’s tools. There’s a learning curve there too!
(But managing via GitHub is not an option for me since my Gramps machine normally doesn’t have net access. I do my browsing via a smart phone.)
You can look at the diffs on GitHub and hand enter them. (It is a good way to become more familiar with the code.) Unfortunately, I tend to make too many transcription keying errors. So I prefer to view the Raw files for each changed file and create a text file on my phone that can be sneaker-netted to to my Gramps desktop.
Manually managed patches are really fragile. Install an update and it could be overwritten. Un-install via the Plugin Manager and the whole addon folder is deleted. (Not moved to the Recyle Bin either… just deleted.) So you have to make sure your manual backups are outside the Plugins folder of the User Directory.
When I put in a patch, I also add a Note in my Tree. (I have a Gramps ‘Source’ in my Tree to which to keep the Notes attached.) So, if I update Gramps to a whole new version, I just review those notes and repeat the tweaks that are still viable.