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’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.
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.
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.