I love the plugin manager. Its ease of use is exemplary. One suggestion would be to add a catalog system that would allow you to select what you want (Isotaami, FTV, etc.) and, in doing so, automatically add the project to the corresponding tab. It would suggest the appropriate version of the addons based on the installed version of Gramps.
Are you serious? The plugin manager, enhanced or not, far from easy to use. A big part of that is that few of the plugins provide emough information to allow the user to assess whether that particular plugin would be valuable to them or not. To take a random example, consider the “Family Tree” report. Prior to installing it, the user has no idea what the report includes or looks like. Some of us don’t install things willy-nilly because we’ve been burned by bugs or incompatibilities in the past.
The plugin manager is not without its own problems. To start, the wide variety of “Types” is pretty much guaranteed to confuse a new user. What is a “Quick Report” versus a “Report”? What is a “Plugin lib” and why would I want one? What are “Import”, “Export” and “Database” plugins and does Gramps have to have these installed to operated? Do we expect new users to know the acronym “JSON” and how that may (or may not) help them in assembling family history?
Then there are the Gramplets that are only available in certain views. The user has to guess where the new Gramplet will show up. Delightful.
Why can’t we filter the list in the plugin manager? If I want a report, let me see only those. Let me see only those plugins that have updates available.
I could go on but I think my point is made.
Craig
One feature that would be very useful to me would be:
When you upgrade to a new gramps version, there would be a checkbox that would allow you to load all the equivalent matching plug-in/grampets that you had in the previous version.
Does this consider the broadening of the Help/Wiki links for the 6.0 release? A significant amount of effort was made to add links for all the built-in and (official repository) add-on plug-ins. (The third-party curated collections are still “hit or miss” and the addon descriptions tend to be rudimentary.) The Wiki buttons add the ability to quickly look up a plug-in from the Addon Manager, Plugin Manager Enhanced, and the Report/Tool toolbar dialogs.
Discussion has been raised about adding the Thumbnails URLs (displayed in the Addon List on the wiki) to the .gpr/py registration files and including the thumbnails in the dialogs too. This was primarily intended to make updating the wiki addon lists more automated and consistent. But it would greatly improve recognition of report types for people who remember visually.
mockup based on simply reusing the wiki table:
As you say, the purpose of the plugins types could be more intuitive. And this confusion will increase as new types are added. What solutions do you suggest. Tooltips? A header button in Types that goes to an article explaining about plugin types? (I’d discourage that idea because more space tends to encourage excessively technical/detailed articles.)
But Patrice’s point is well taken. A catalog feature could help users shop for addons. If it evolved into a real catalog. But what was described sounds more like a Project subscribe/un-subscribe list service.
I wonder? Perhaps if you copied the gramps52/plugins folder to a gramp60/plugins folder, maybe the Addon Manager would recognize the plugin version might be the same but the gramps_target_version version was outdated… and offer mass updates via the Addon Manager’s Settings tab? That only offers updates for installed addons.
That might not work. It might be dependent on the plugin Registration. And the registration would have refused to load plugins when the gramps_target_version is a mismatch.
I apologize that I haven’t looked at 6.0.x yet. I have some housekeeping to do before I want to install it.
TBH, though, the 6.0 Report Selection dialog shown above isn’t great. The thumbnail and the description are useful but space is wasted on the other 5 columns. (What does the column containing “4” mean? “All”? “Family Sheet” and “Report” are redundant.)
I could argue that many of the current plugins are unnecessary. For example, the “Detailed Descendants With All Images” shouldn’t exist as a separate report. The ‘All Images’ part should be incorporated into the existing Detailed Descendants report as just another report option. Several of the Gramplets (like Number of Ancestors/Descendants), Quickreports, and Rules should be part of the base Gramps distribution.
At least a couple of the Gramps Views are enhancements to the ‘default’ view. If the project decides these are stable and truly enhance usability, then replace the old default. I know people whine about change but keeping an old interface around means many people will never even hear about the new one.
Craig
Its a mockup that just re-uses the wiki’s addon table row. Just in the idea stage now with minimal time invested.
One of shortcomings of the current plugin docs is that NONE of them (including the wiki) consistently identify where the plug-in lives in the interface. When there is a Quick Report, you need to know which object (if any) will have a new context menu choice. With Tools and Reports, which submenu. With Rules, which category and submenu? With Gramplets, which Category/Categories? With View modes, which Category (new Views add their own category)?
With “General” plugin libraries and the other plug-in types, it is probably too complex to describe where it affects the GUI. You’d need more than a sentence. Those would probably have to to be explained in the Plugin’s wiki page
6 posts were merged into an existing topic: Observations and suggestions - combined view