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

Update xdg-mime helper #4333

Closed
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@MoritzKn
Contributor

MoritzKn commented Aug 15, 2017

Description

This will respect the directory /usr/local/share/applications/ when fetching mime infos.

TODOs:

  • Changes to fish usage are reflected in user documentation/manpages.
  • Tests have been added for regressions fixed
  • User-visible changes noted in CHANGELOG.md
Update xdg-mime helper
This will respect the `/usr/local/share/applications/` directory when fetching mime infos.
@MoritzKn

This comment has been minimized.

Show comment
Hide comment
@MoritzKn

MoritzKn Aug 17, 2017

Contributor

I adjusted my changes according to the remarks.

I also checked the XDG spec and updated the code to actually comply with it.
Relevant parts of the XDG base directory specification:

$XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.

$XDG_DATA_DIRS defines the preference-ordered set of base directories to search for data files in addition to the $XDG_DATA_HOME base directory. The directories in $XDG_DATA_DIRS should be seperated with a colon ':'.

If $XDG_DATA_DIRS is either not set or empty, a value equal to /usr/local/share/:/usr/share/ should be used.

Other specifications may reference this specification by specifying the location of a data file as $XDG_DATA_DIRS/subdir/filename. This implies that:
[...]
Lookups of the data file should search for ./subdir/filename relative to all base directories specified by $XDG_DATA_HOME and $XDG_DATA_DIRS . If an environment variable is either not set or empty, its default value as defined by this specification should be used instead.

Relevant parts of the XDG desktop entry specification:

To determine the ID of a desktop file, make its full path relative to the $XDG_DATA_DIRS component in which the desktop file is installed, remove the "applications/" prefix, and turn '/' into '-'.

And two other questions:

  • What is with the po/*.po files? Those reference the changed and renamed functions and their descriptions. How would I go about updating those?
  • Should I squash the commits?
Contributor

MoritzKn commented Aug 17, 2017

I adjusted my changes according to the remarks.

I also checked the XDG spec and updated the code to actually comply with it.
Relevant parts of the XDG base directory specification:

$XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.

$XDG_DATA_DIRS defines the preference-ordered set of base directories to search for data files in addition to the $XDG_DATA_HOME base directory. The directories in $XDG_DATA_DIRS should be seperated with a colon ':'.

If $XDG_DATA_DIRS is either not set or empty, a value equal to /usr/local/share/:/usr/share/ should be used.

Other specifications may reference this specification by specifying the location of a data file as $XDG_DATA_DIRS/subdir/filename. This implies that:
[...]
Lookups of the data file should search for ./subdir/filename relative to all base directories specified by $XDG_DATA_HOME and $XDG_DATA_DIRS . If an environment variable is either not set or empty, its default value as defined by this specification should be used instead.

Relevant parts of the XDG desktop entry specification:

To determine the ID of a desktop file, make its full path relative to the $XDG_DATA_DIRS component in which the desktop file is installed, remove the "applications/" prefix, and turn '/' into '-'.

And two other questions:

  • What is with the po/*.po files? Those reference the changed and renamed functions and their descriptions. How would I go about updating those?
  • Should I squash the commits?
@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Aug 17, 2017

Contributor

What is with the po/*.po files?

Those are language translation files (known as "localization" and "L10N" files). In general you don't have to worry about those unless you happen to read/write one of the languages and want to help keep the translations in sync with the english messages.

Should I squash the commits?

You can but as a general rule you don't need to. Whomever merges your PR (me in this case) will take care of it if that's the appropriate thing to do.

Squash merged as commit 5eb0b34 and 6e02ec8. Thx.

Contributor

krader1961 commented Aug 17, 2017

What is with the po/*.po files?

Those are language translation files (known as "localization" and "L10N" files). In general you don't have to worry about those unless you happen to read/write one of the languages and want to help keep the translations in sync with the english messages.

Should I squash the commits?

You can but as a general rule you don't need to. Whomever merges your PR (me in this case) will take care of it if that's the appropriate thing to do.

Squash merged as commit 5eb0b34 and 6e02ec8. Thx.

@krader1961 krader1961 closed this Aug 17, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment