Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement: add the ability to export/import rules #72

Open
Giova84 opened this issue Jul 19, 2017 · 7 comments
Open

Enhancement: add the ability to export/import rules #72

Giova84 opened this issue Jul 19, 2017 · 7 comments
Labels
hacktoberfest Issues proposed to Hacktoberfest participants

Comments

@Giova84
Copy link

Giova84 commented Jul 19, 2017

I had this idea since I have a lot of rules (some of them are also complex), and I'd like to import them in another Haiku's installation where Filer is present. Ok, I can made them again, but the ability to save/import a rule (some of them or all) would be definitely useful also because can save time; I also imagine the ability to share Filer's rules between users.

@owenca
Copy link
Contributor

owenca commented Jul 19, 2017

I had this idea since I have a lot of rules (some of them are also complex), and I'd like to import them in another Haiku's installation where Filer is present.

Filer settings file formats are only backward, not forward, compatible, so Filer v1.1.0 can't read the formats post-v1.1.0.

When importing a compatible format, do you want the new rules to be added to the existing rules in ~/config/settings/Filer/FilerRules, if present, or do you want the new ones to replace the existing ones?

Whenever Filer is closed, it will save the rules from the Rules tab to the settings file, so adding an Export feature is not very useful as far as I can tell.

@humdingerb
Copy link
Member

Before investing efforts in managing rules, I'd like to suggest reconsidering the sqlite backend.

If each rule would be saved as a single file in ~/config/settings/Filer/rules/ as a flattened BMessage (as are the settings already), managing and sharing rules should get much easier.
The list in the RulesTab could accept dropped rule files, dragging an item from the list on e.g. the Desktop, could create a rule file that could be shared.

Backward compatibility seems difficult. I wouldn't mind calling it Filer v2.0 and drop compatibility to v1.

@owenca
Copy link
Contributor

owenca commented Jul 21, 2017

I had a quick look at the code that saves and loads the rules through sqlite, and it seems the rules are written to and read from the database sequentially. So why does Filer use sqlite?

Even without using sqlite, we can save all rules in the same file rather than one rule per file. Importing a Rules file should append the rules to the existing Rules file.

@humdingerb
Copy link
Member

So why does Filer use sqlite?

I think I remember DarkWyrm to use sqlite, because he never used it before and wanted to try it out. Maybe it looked like he needed an actual database at the start and he just stuck to it...

Even without using sqlite, we can save all rules in the same file rather than one rule per file. Importing a Rules file should append the rules to the existing Rules file.

Sure, putting all rules into one file is possible. Though, having one file per rule makes sharing rules and im/exporting by copying to/from ~/config/settings/Filer/rules/ or drag&dropping on/from the RulesTab much easier.

@owenca
Copy link
Contributor

owenca commented Jul 21, 2017

Oh, I see. But that would make the format overly complicated because each rule is assigned a unique id and the order of the rules must be maintained according to the comments in the code. If we change the current one-file format to one-rule-per-file format, we must deal with naming these files uniquely and have another file to keep track of their order. On the other hand, appending an imported Rules file to the current file (if it exists) will be safe: the user just needs to remove or disable the rules he doesn't want. I am now fairly confident that we can do without sqlite. :-)

@humdingerb
Copy link
Member

You could add a "rule-order" integer field to the rule BMessage. Adjust when the user sorts the rules list. Put at the end for imported rules.

Do we really need unique ids for every rule? Even if so, that too could be another integer field, when importing (and loading) a rule, make sure the id is unique.

Just thinking out loud... :)

@owenca
Copy link
Contributor

owenca commented Jul 21, 2017

The unique ids are for distinguishing different rules with the identical descriptions. We probably won't need it if we move away from sqlite.

I agree it's feasible to use the one-rule-per-file scheme, but going through all this trouble so that the user can import/export/share any single rule doesn't seem to be a good deal. It also comes with a downside from the user point of view because he would have to pack the files together if he wants to share more than one rule.

From the implementation point of view, the rules would be scattered, albeit in the same folder, and Filer must open multiple files and make sure not missing any. We also must come up with a naming scheme for the files, e.g., rule01, rule02, etc.

Maybe a new feature that allows the user to select one (or more rules) from the rules list tab and save it (by file panel or drag & drop) to a file of the user's choice will suffice (if we support additional rules files to be appended to the existing one.)

@scottmc scottmc added the hacktoberfest Issues proposed to Hacktoberfest participants label Sep 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hacktoberfest Issues proposed to Hacktoberfest participants
Development

No branches or pull requests

4 participants