Open mcroitor opened 3 months ago
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.
... 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.
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.
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.
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.
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.
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.
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?
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.
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:
import extension
Import extension must implement interface:
Olive scans import extensions folder and provide access to the extension from
File --> Import --> <file_type>
menu link. For example, thepbm
import logic can be moved here.export extension
Export extension must implement interface:
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:
Validation logic can be moved here (
validate.py
).