Handling of multiple available plugins

[giumas]

Branched from: #73

If a resource/file can be accessible by more than 1 plugin (e.g., all the BAG files can also be read by the HDF5 plugin), it might be useful/handy for the user to be able to disable at run-time a given plugin provide a mechanism to select one of the available plugins.

[giumas]

@jreadey and @andrewcollette : I thought to two different approaches to this enhancement:

1. Modify the Store class by adding something like an active abstract property to the Store in the compass_model. Such a value can then be added as additional check to the can_handle function of each plugin-specific implementation. The disadvantage is that each plugin developer has to remember to use such a mechanism.
2. Add another list of stores: With 2 list of stores (e.g., _available_stores and _active_stores), it would be easy to add/remove active plugins. A couple of function would be required to be added as get_available_stores and activate_store. I am more oriented on such a solution since I cannot think to relevant possible issues.

[andrewcollette]

@jreadey, @giumas, I appreciate what you are trying to accomplish but this is getting really complicated. Nobody is going to open a preference window and manage their plugins. It needs to just work. Also, remember that "plugins" are not supposed to be a user-facing technology... for this reason I would avoid an info dialog like that shown in #73. Think of the plugins more like a list of supported file formats.

I absolutely agree there needs to be a mechanism to handle the fact that more than one plugin can handle a particular kind of resource. But I think the general approach to this should include just two features: (1) Compass should try to pick the "right one"; for example, we could prefer more-specific plugins over more-generic ones, and (2) there should be e.g. an "Open As..." menu item or similar so people can manually open it as whatever kind they want.

Since we are distributing Compass and all plugins we can hard-code whatever we want for (1). Don't be afraid to use heuristics, peek inside the file, etc. User experience is more important than keeping the design clean.

[giumas]

I thought that #73 was generally accepted as enhancement since it has been listed for a while in #79. If this list is not commonly accepted, it becomes quite confusing and time-wasting to contribute to this project.

In my personal opinion, the info dialog in #73 is useful to quickly get what is supported by HDF Compass, without having to read the long documentation. Said this, be free to revert the PR.

About this branch ticket, feel free to close it!

[andrewcollette]

Unfortunately the best thing about features is that everyone has an opinion on them. :) Despite my history with the project I'm not part of the HDF Group so ultimately I defer to their judgement... looks like @jreadey already merged #73 so I will respect that.

I would still suggest, unless others feel strongly otherwise, that we tend towards a lower-complexity UI approach to this problem. One of the things I love about Apple software, for example, is that a lot of care is taken in determining the default behaviors, which has the side effect of reducing user-facing complexity. It's easy to imagine some simple rules (prefer BAG if certain attributes are present, prefer HDF5 for local files, etc.) that will work 90% of the time.

[andrewcollette]

correction... I meant to say @jreadey was in favor of #73. And just to be clear... @giumas, thanks again for huge amount of effort you've put into making Compass better software.

[hyoklee]

I agree with @andrewcollette: "Nobody is going to open a preference window and manage their plugins. It needs to just work." & "User experience is more important than keeping the design clean."
I don't want Compass to follow HDFView's plug-in model that failed UX.
For example, HDF-EOS plugin for HDFView was so inconvenient to use because it's shipped and installed separately. Installation was very difficult, too.

[giumas]

@andrewcollette The overall structure of this project is so wonderful and elegant thank to you! Without discovering it, I would have surely ended up by doing something clunkier on my own for browsing just the BAG format...

@hyoklee I agree on the risk to quickly move toward a preference window, with all the related issues.

Said that, I would wait @jreadey 's opinion before closing this (originally) enhancement ticket.

[jreadey]

I'm in favor of #73, I think it's useful to be able to see the list of plugins. Sort of like a dialog to see what codecs you have available for your favorite video player - maybe a bit nebish but doesn't harm the user experience for those who don't care about such things. Also, the dialog will be a handy place to acknowledge plugin contributors.

I agree with @andrewcollette that a system to enable/disable plugins seems overly complex. To deal with the multiple plugins can handle the same file issue - would it be possible to extend the File Open Dialog with a "Open As" dropdown? The drop down could list all the plugins that can handle the file in question. (same methodology could be applied to open resource).

A step beyond this is to do the typical Windows Explorer thing and say: "Do you always want to use this plugin for this type of file?". And then the user could click yes to set his preference. We'd need to establish what "this type of file" means exactly. The file extension?

[giumas]

I agree with @andrewcollette that a system to enable/disable plugins seems overly complex. To deal with the multiple plugins can handle the same file issue - would it be possible to extend the File Open Dialog with a "Open As" dropdown? The drop down could list all the plugins that can handle the file in question. (same methodology could be applied to open resource).

What about something very simple as the "Open As" triggering two dialogs?

1. similar to the current "Open" dialog
2. only appears if there are multiple usable plugins, and shows a list from which to select

[jreadey]

For the automatic aspect - let's use the plugins file_extension as part of the heuristic for choosing the plugin to use.

For the manual override, I notice on Windows at least the File Open Dialog has a dropdown button (with the "Open" label). Can that be modified to invoke a specific plugin? I'd prefer to not have two dialogs.

[giumas]

For the manual override, I notice on Windows at least the File Open Dialog has a dropdown button (with the "Open" label). Can that be modified to invoke a specific plugin? I'd prefer to not have two dialogs.

It is a very good idea! Do you know how to do that?

[jreadey]

Unfortunately, no. Maybe the wxPython GetExtraControl() method has something to do with this? I couldn't find any documentation on it.

If that is unworkable, how about a variant of the two dialog approach:

File Open invokes the plugin for the file based on whatever heuristics we come up with.

If there are multiple plugins available for a particular file, a "Reopen As..." menu is enabled that allows the user to select an alternate plugin.

[giumas]

Do you propose to add a "Reopen As..." menu in the just created ContainerFrame? Or in the already open InitFrame?

[jreadey]

ContainerFrame I'd think. The frame needs to be associated with some file/resource for re-open to make sense.
Also, the Mac version doesn't have a InitFrame window!

[jreadey]

Trying out the BAG plugin makes me want to +1 this feature. It would be really useful to switch between HDF5 and BAG views of the same file.

Regarding @andrewcollette's concern about not over-complexifying the user experience, I think the File OpenAs paradigm is fairly well understood among users, so this should be a net value add.