Family Historian User Group

Does anyone else think it would be useful to have one of more of the following facilities; or has anyone found a way to navigate to a plugin quickly, given that (for example) I have circa 50 plugins to scroll through to select one. I know you can navigate by typing the first few letters of the plugin title, but that depends on remembering the title (and on typing fast), and is not helpful if you have a lot of plugin titles that begin the same way. Of those 50 there are a lot that I use regularly which could usefully be pinned to the tools menu, except you run into the same volume problem...

• Group plugins within the plugins window
• Filter plugins within the plugins window
• Search plugins (by title) within the plugins window
• Ditto for plugins on the Tools menu

If nobody comes up with a solution that can be deployed now, I'll move this to New Wish List Requests.

Helen, I have a similar problem and no solution beyond what you described.

My preference would be Group Categories similar to the Query toolbar button and View > Query command.
That would apply to both the Tools command and the Tools > Plugins window.

The ability to assign any Plugin to a number of Group Categories just like Queries would work for me.

Remembering our discussions on a plugin calling a plugin a couple of months ago, could we have a simple plugin that does the bullet points? I know there are a lot of limitations to this approach, but if it is written with no global variables and unique function names it might be an option...?

I suspect it might be a highly niche requirement so wouldn't expect a high priority, but that doesn't stop it going on the list of course.

I've created a post in the New Wish List. Anything else is far down my priority list.

Mark's suggestion of temporarily renaming the plugin to start with == and so sort to the beginning of the list (I expect) breaks the Check for Updates plugin, and I've usually got more than 1 or 2 plugins I'm using a lot, but for a few plugins it's a workaround.

It occurs that segregating DEAs would kae a lot of sense.

I generally take the appearance of scroll-bars in the plugin window as a hint that I’ve got too many in the live folder. If there are plugins that I’ve not used for a while, I either archive my custom ones or delete Store ones altogether. It only takes a few seconds to reimport if needed, and it’s quicker and easier than scrolling a long list.

For anyone that uses DEAs, it would help avoid plugin proliferation if they had their own folder and didn’t appear in the regular Plugins Window at all. As things stand now, they appear and can even be run directly from the Plugins Window. The couple that I have tried don’t even give meaningful error message if run this way.

Sorting that doesn’t need a full fat plugin categorisation scheme - but it is one that only CP can address.

Snap! But I used a lot more words.

Some plugins are written to be used as regular plugins as well as DEAs but in principle you nmake sense.

Thinking about it some more, moving DEAs and Report Plugins to their own folders retrospectively will add complexity, as different versions of FH7 will have to look in different places.

A simpler fix might be to just add tick boxes to the Plugin Window for displaying these special plugin types or not. They would be unchecked by default, as only authors (both of you ) would need to see them listed there.

If anybody here has CP’s ear, perhaps they could suggest it...?

I am not sure it would be any kind of solution here, but I have started using AHK (Autohotkey) to save keystrokes (not just FH) with the help of key key/mouse recorder "macro creator". There is also the recent introduction by microsoft of "Power Automate", I have dabbled with checking emails, it sounds like it can do similar to AHK.

But I have to agree, as good as FH is, I wish they would spend a bit more effort on making it more navigationally flexible. Simple things like assigning shortcut keys, and simple macros.

When plug-ins were first introduced, I suggested to CP (During beta testing) that they were so useful (And there were only a handful then) that they should have there own toolbar icon. I still think that is the case, I also agree that the dea's and report plugins that shouldn't be run as standalone plugins, should not be visible as such.
Maybe the authors of those types of plugins can report that as a "Bug" to CP.

johnmorrisoniom wrote: ↑

15 Nov 2021 08:13

I also agree that the dea's and report plugins that shouldn't be run as standalone plugins, should not be visible as such.

From the help for writing plugins:

Source-driven data entry plugins can be run like ordinary plugins.

and also

Running Report PLugins

As well as running report plugins from the Plugins window, report plugins are also automatically listed under 'Custom Reports' on the Publish menu,

So they're included by design in the plugin window, not by bug.

Helen, I'm a bit confused (probably nothing new). When would a DEA be run from the plugin window? Do any of the current ones do that?

Mark, Rename Source Media DEA

But actually, all DEAs can be run from the plugins window -- if they rely on a Prepared Citation they would typically check that one exists and that it meets their prerequisites.

Wish list entry 584 has been created.