Olive extensions proposal

[mcroitor]

I propose to implement extension system in the Olive GUI. This system will work in the folder extensions and will allow to use import / export / analyze extensions.

directory structure:

+ extensions
    +-- import
    |      +-- pbm
    |      +-- fen
    |      +-- ...
    +-- export
    |      +-- pdf
    |      +-- image
    |      +-- ...
    +-- analyze
    |      +-- modelmate
    |      +-- miniature
    |      +-- ...

import extension

Import extension must implement interface:

class ImportExtensionInterface:
    def file_type(self) -> str:
        pass

    def description(self) -> str:
        pass

    def import_from(self, path: str) -> []:
        pass

Olive scans import extensions folder and provide access to the extension from File --> Import --> <file_type> menu link. For example, the pbm import logic can be moved here.

export extension

Export extension must implement interface:

class ExportExtensionInterface:
    def file_type(self) -> str:
        pass

    def description(self) -> str:
        pass

    def export_to(self, problems: [], path: str):
        pass

Olive Gui implements some exports, all these exports can be standardized and moved to the export extensions.

Analyzer

An analyzer must implement the following interface:

class AnalyzeExtensionInterface:
    def description(self) -> str:
        pass

    def analyze(self, problem) -> str:
        pass

Validation logic can be moved here (validate.py).

[dturevski]

Olive scans import extensions folder

In the py2exe compiled version (that is what 99% of users are using) there is no folder with the source code. How is that supposed to work?

import extension

Importing functions were removed from Olive. Regarding the interface, please keep in mind that the file path alone is often not enough to correctly import a file, for example, when importing from the save formats of non Unicode programs like Problemiste or Fancy, the user must implicitly specify the original character encoding.

export extension

This part could indeed benefit from a little refactoring, I guess :)

Analyzer

What is wrong with the existing analyzer interface exactly? The existing analyzers are significantly more advanced than simple description / analysis result strings. There is a whole formal language for predicate documentation, matching and counting.

[mcroitor]

... here is no folder with the source code. How is that supposed to work?

Olive will be compiled as is, without extensions. Extension as python source code (or compiled) can be added in the installed app, or, if an extension is delivered with the application, will be added by the installer in the package.

[mcroitor]

What is wrong with the existing analyzer interface exactly?

Nothing wrong ☺️.

I just propose to reorganize code a little bit, and this will allow for others to use / write extensions without changing something in the application source code.

Also an analyzer can be used in other way: I think about pgn file import and analyze a diagram with UCI engine, Stockfish, for example.

[dturevski]

The problem is only with the exporters. Importers do not really benefit from the Olive infrastructure and are more useful as standalone converters.

New analyzers (in the current sense - that is something that looks at the solution and finds themes/effects) can be added with small trivial changes to the code/documentation. I can't see an issue here.

Importers are a bit of a mess at the moment, that is true. If you could reorganize them in a uniform manner I would happily merge it upstream.

pgn file import and analyze a diagram with UCI engine

There are too many programs already that can do it better.

Extension as python source code (or compiled) can be added in the installed app, or, if an extension is delivered with the application, will be added by the installer in the package.

I think you are trying to solve a problem here that simply doesn't exits. I'm still not sure how is that supposed to work, but it will definitely overcomplicate the cross-platform support for unclear benefit for a few (if any) developers. Separately distributed extensions is a solution from the non open source world where they have to have it to keep the source code private. Olive doesn't have this issue.

[mcroitor]

The problem is only with the exporters. Importers do not really benefit from the Olive infrastructure and are more useful as standalone converters.

It is may be true in your case or in my case, but not for a regular user. Some users ask me if exists any possibility to open a FEN file in the Olive or to store each diagram as separate image.

If you are agree, I will prepare the solution and will share with you for review.

[dturevski]

Sorry, I don't agree.

For one thing, I have no idea what a "FEN file" is. I imagine someone may want to convert a collection of FEN codes into a collection of images files as a part of some development pipeline, but it's not something a common Olive user may want. I just don't understand the use case of this feature.

[mcroitor]

What is wrong with the existing analyzer interface exactly?

Nothing wrong ☺️. I just propose to reorganize code a little bit, and this will allow to use / write extensions without changing something in the application source code.

[mcroitor]

Ok, you are chief in this case. But from my point of view, importers from other files allow you to do a collection migration from one format to olv. For example, my colleague keeps his problems in pvm format and he doesn't try to migrate his base in any other format because time costs.

As I understand, filters and ordering are bad ideas too?

[dturevski]

The best solution for you collegue would be a standalone format converter in my opinion. More generally, the idea behind Olive is to streamline repeating tasks for chess composer - rotate position, test problem with Popeye, create PDF for submitting to a composing tourney, etc. Converting a personal collection of problems is not a repeating task.

As I understand, filters and ordering are bad ideas too?

Why? Filters and ordering (and more generally collection views) are okay if done with smart UX in mind - unobtrusively and intuitevely - think about how the user would expect ordering by distinction or stipulation to work, for example.