search

BachoSeven / mimi

a better xdg-open - an active fork
MIT License
32 stars 2 forks source link

Migrating from older versions of mimi #3

Closed vaygr closed 1 year ago

vaygr commented 2 years ago

After switching from original mimi I found http[s] links no longer working.

Turned out desktop files under /usr/share/applications have higher priority than those entries in ~/.config/mimi/mime.conf for x-scheme-handler/http.

I know ~/.local/share/applications should be prioritized over /usr/share/applications, but I think ~/.config/mimi/mime.conf should override both?

BachoSeven commented 2 years ago

@vaygr It does proritize that indeed; the issue here is that I renamed mime.conf to mimi.conf (in https://github.com/BachoSeven/mimi/commit/c8965a3404f0be0861005fd5ac54884a76693b9c); now the main reason for this was XDG compliance: the pattern ~/.config/program/program.conf is quite established among other programs; however I can understand if since you have been using mimi for a long time you are used to the other location.

I'm not sure what I should do, is it better to revert to the original name, allow both locations as a fallback or do you agree that the new location is more sensible?

vaygr commented 2 years ago

Oh, I see. Somehow I missed that during debugging.

Yes, mimi.conf totally makes sense. Now there are several approaches for the upgrade path:

  1. Do nothing and let people find out this issue.
  2. Add "Upgrade from older mimi" section / warning that the config file path has changed in README.
  3. Built-in upgrade path: a) [Silently] move ~/.config/mimi/mime.conf to ~/.config/mimi/mimi.conf if the former is detected b) Print a warning for the end user to do a) manually

From my experience 3.a is what the most software projects do. At the time of the operation a notice can be printed about config file change and deprecation of the old path.

Given that mimi is not popular among millions of users, 2. could be enough, but the ideal upgrade path is 3.a if you feel having backward compatibility is important and reflect it in the code.

yogeshdnumb commented 1 year ago

Is there a fix for this

BachoSeven commented 1 year ago

Oh, I see. Somehow I missed that during debugging.

Yes, mimi.conf totally makes sense. Now there are several approaches for the upgrade path:

  1. Do nothing and let people find out this issue.
  2. Add "Upgrade from older mimi" section / warning that the config file path has changed in README.
  3. Built-in upgrade path: a) [Silently] move ~/.config/mimi/mime.conf to ~/.config/mimi/mimi.conf if the former is detected b) Print a warning for the end user to do a) manually

From my experience 3.a is what the most software projects do. At the time of the operation a notice can be printed about config file change and deprecation of the old path.

Given that mimi is not popular among millions of users, 2. could be enough, but the ideal upgrade path is 3.a if you feel having backward compatibility is important and reflect it in the code.

I'll go with 2.