: xdg On Behalf Of Peter White
Sent: Monday, September 20, 2021 11:03 AM
To: xdg@lists.freedesktop.org
Subject: Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
Caution: External Sender. Do not open unless you know the content is safe.
On Mon, Sep 20, 2021 at 02:09:00PM +, Bollinger, John C wrote:
So what are you looking for at this point, Peter? I think we're well past any
question of interpreting the details of the spec, and we've even delved a bit
into its history and design goals and its intended usage model. We get that
you are unhappy about how its use interacts with certain softw
w the content is safe.
On Thu, Sep 16, 2021 at 04:15:07PM +0000, Bollinger, John C wrote:
> The value of XDG_CONFIG_DIRS, if set, is expected to be a string
> designating one or more directories to search for config files, in
> priority order. If multiple directories are specified then they are
The value of XDG_CONFIG_DIRS, if set, is expected to be a string designating
one or more directories to search for config files, in priority order. If
multiple directories are specified then they are separated by colon characters
(:). This represents a search path, similar to the executable sea
Dear Peter,
XDG Base Directory specifies the significance of certain environment variables.
How those obtain their values is out of the specification's scope. It varies
with execution environment and with execution context.
Some of the tools at your disposal on various systems are:
- The /et
Indeed, inasmuch as Mac software packaged in “app” format is expected to be
pretty much self-contained, it may not make sense for such software to consult
$XDG_DATA_DIRS or $XDG_CONFIG_DIRS. Their default data and configuration would
normally be packaged together with them, instead. User-spec
Hi All,
On Monday, February 22, 2021 4:09 AM, Jehan Pagès wrote:
My last example about an hypothetical viewer which would have XCF display
support shows the problem even after the transition period, when all software
would have updated their desktop file.
Let me show with your proposal (I don'
On Thursday, February 18, 2021 4:49 AM, Jehan Pagès
wrote:
* GIMP would set XCF (and variants) as its NativeMimeType and PSD, ORA, PSP
(and other similar formats for raster editing) as IntentMimeType. Thus saying
that "XCF" is what they do best (and a XCF file was likely even created by GIMP
o
On Wednesday, February 17, 2021 3:07 PM, Jehan Pagès
wrote:
On Wed, Feb 17, 2021 at 8:26 PM Thomas Kluyver
mailto:tho...@kluyver.me.uk>> wrote:
This particular user reports that *updating* GIMP causes the file association
to change. That definitely seems like a bug: I can understand that some
d=0>
🤣).
Ah, one of my favorites.
On Wed, Feb 17, 2021 at 4:13 PM Bollinger, John C
mailto:john.bollin...@stjude.org>> wrote:
On Wednesday, February 17, 2021 6:30 AM, Thomas Kluyver
mailto:tho...@kluyver.me.uk>> wrote:
Distinguishing things like 'native' and 'equivalent in
On Wednesday, February 17, 2021 9:53 AM, Thomas Kluyver
wrote:
I can see what you're saying, but I don't think it's ridiculous to suggest that
a desktop file could encode some indication of how well an application handles
a particular file type. You could think of this as describing 'can open'
On Wednesday, February 17, 2021 6:30 AM, Thomas Kluyver
wrote:
On Tue, 16 Feb 2021, at 23:04, Bollinger, John C wrote:
But that does not imply that some applications should be able to claim to be
more equal than others with respect to particular file types.
I think Jehan's idea is
Hello Jehan and All,
On Tuesday, February 16, 2021 11:57 AM, Jehan Pagès
wrote:
On Tue, Feb 16, 2021 at 5:55 PM Bollinger, John C
mailto:john.bollin...@stjude.org>> wrote:
Hello all,
I think the decision to omit MIME-type priority is about scope, not about
concerns regarding specifi
Hello all,
I think the decision to omit MIME-type priority is about scope, not about
concerns regarding specific (mis)uses. Desktop files can express that an
application is _suitable_ for handling files of certain types, but it is not
their role to convey system policy, such as which applicati
Hi Group,
I think "write once" is a poor term for describing the contents of /usr/share.
Moreover, I disagree that the explanation of the intended meaning is an
accurate characterization, inasmuch as it focuses on a package manager, as
opposed to other administrative tools and agents. There d
(1) #basic-format says "A file is interpreted as a series of lines that
are separated by linefeed characters." #value-types says "The escape
sequences \s, \n, \t, \r, and \\ are supported for values of type string
and localestring, meaning ASCII space, newline, tab, carriage return,
and backslas
On Wednesday, February 26, 2020 1:41 PM, Simon McVittie wrote:
> The only thing that the XDG_CACHE_HOME specification needs to agree on is the
> contents and meaning of whatever file format gets used, not a concrete
> implementation of the interpreter for that file format (the same way
> freede
On Wednesday, February 26, 2020 11:19 AM, Benjamin Berg wrote:
> So, lets try to clarify a few points.
> I do think that it is a good idea to use tmpfiles.d and for applications to
> ship appropriate configurations. There seems to be an overall agreement that
> tmpfiles.d is an appropriate way
On Wednesday, February 26, 2020 8:51 AM, Benjamin Berg wrote:
> [...] I *do* want applications to explicitly ship an opt-out file if they do
> not want any cleaning ever. And threatening with automatic clean-up is
> probably a good idea, because otherwise no one will bother.
This is simply w
> The Breeze icon theme currently has an issue where we (KDE's designers) want
> to use different styles for different parts of a GUI, but what we want to do
> cannot be done without breaking compatibility with XDG icon specs.
What you're describing could be characterized as using different _the
> I do not want to simply create more folders and a finer distinction between
> them. I want to add directories for types of files that don't fit really well
> in the existing structure (see my mail from June; there are quite a few, but
> history+logs are the most important to me, and they can b
I have recently been studying the basedir spec pretty carefully in support of
work on basedir-related software. I consider myself to be pretty current,
though I confess I did not review the XDG_STATE_HOME patch request when it came
through in August. Having now given it a look, my knee-jerk re
> We could change Gettext to stop considering the Icon key as translatable
> *without* changing the specification, but that would be a violation of the
> spec
Would it? The spec does not say that localestrings are translatable. It says
that they are _localizable_, in a specific technical sen
Hi,
The problem seems to be that Icon is unique among the currently-defined keys in
that it identifies a _machine-actionable_ datum that may conceivably want /
need to differ between locales. It should not be translated because it’s not
intended for human readers, but it should be customizable
Dear XDG folks,
I'm working on an implementation of the XDG Base Directory specification, and I
ran into several issues on which I would like clarification or guidance. I
hope you can help.
1. Colons in file names
Colons (:) appearing in the values of $XDG_DATA_DIRS and $XDG_CONFIG_DIRS
25 matches
Mail list logo
