[patch] Formatting in desktop entry spec makes meaning unclear

The typography of the Desktop Entry Spec makes it ambiguous whether dots are allowed in key names (reading the markup indicates that they're not, but the character class is at the end of a sentence, so the full stop that ends the sentence looks as though it might be part of the character class).

Re: Linux packaging system and file hierarchy

On Wed, 12 Nov 2008 at 18:51:23 -0500, Randy Kramer wrote: * user's real data (that is files containing things like user's documents, photos, music, ..., but not things like user defined or selected icons, backgrounds, ...)--$XDG_DATA_HOME and $XDG_DATA_DIRS That's not the intended

Re: .desktop file security

On Tue, 24 Feb 2009 at 13:29:05 +0100, Alexander Larsson wrote: On Tue, 2009-02-24 at 11:13 +, John Tapsell wrote: It's dangerous not to. If it's marked as executable, and you execute it, it will try to be parsed by bash. Most of the time this will just generate lots of file not found

Re: about IM status icons

On Mon, 08 Jun 2009 at 21:48:47 +0200, Jakob Petsovits wrote: On Monday 08 June 2009, Nicolò Chieffo wrote: In my opinion a status is currently missing: d-n-d. In KDE's Oxygen, we have user-busy for that. So +1 for getting an icon with this purpose into the spec, it's commonly used by all

Re: about IM status icons

On Tue, 09 Jun 2009 at 11:56:26 -0400, William Jon McCann wrote: user-online user-available - I can and wish to chat [...] But seems that at the moment we're likely going to consider online and available as the same. The terminology that Telepathy occasionally uses is that any status in

Re: basedir spec and plugins

On Fri, 26 Jun 2009 at 16:08:28 +0200, Thiago Macieira wrote: I think those could turn out to be useful. However, I just don't see why you'd want that right now. XDG stuff is there because it's shared among different applications, libraries and toolkits. They need to know how to find

Re: Standard mail location and format

On Mon, 29 Jun 2009 at 13:24:31 +0900, Daniel Bo wrote: Is there an XDG variable for user mail location? Should there be a standard location and format? I can see the spec being pretty simple: Default: ~/Mail Format: MailDir I don't think that's conventional? The locations I've usually seen

Re: basedir spec and plugins

On Tue, 30 Jun 2009 at 04:08:26 -0300, Thiago Macieira wrote: We'll need an architecture key, which is composed by the host OS plus at least the processor main type. Multiarch http://lackof.org/taggart/hacking/multiarch/ addresses this by taking the CPU and OS (or CPU and kernel+OS) from

Re: Summary of the fdo disussion at GCDS

On Wed, 08 Jul 2009 at 22:00:09 +0200, Olivier Goffart wrote: We agreed that freedesktop would have a wiki page listing the specification/implementations and saying whether they are blessed by each desktop, and the implementation status. It is not allowed to take namespace on

Re: DBus properties naming rules

(I'm not sure why this thread wasn't on the D-Bus mailing list... see xdg archives for history.) On Tue, 08 Sep 2009 at 15:07:06 -0600, Aaron J. Seigo wrote: we're talking about the allowed character set, not case or stylistic format. it's a slightly different matter, as the former says which

Re: Migrating the specifications to git (xdg-specs repo)

On Tue, 16 Feb 2010 at 15:33:32 +0100, Vincent Untz wrote: Right now, I just want to import all specs, each one with its cvs history and in its subfolder. OOI, why not one spec per git repository? This seems to be the case for a significant number of the specs you mentioned already, and it's

Re: base dir spec question.

(Cc'ing the author of the specification in question: Waldo, could you clarify whether I'm interpreting it correctly?) At the beginning of this thread, Sander Jansen s.jan...@gmail.com wrote: For my music manager I need to store a sqlite3 database file somewhere on disk. Which directory would be

Re: Icon Naming spec and Telepathy

On Thu, 15 Apr 2010 at 10:04:09 +0200, Guillaume Desmottes wrote: I'd like to propose to add 'user-invisible' to the list of status icons. Using user-invisible is probably better if some icon themes already include it, but for reference, this is called 'hidden' in Telepathy:

Re: Base Directory Specification and plugins

On Sun, 21 Nov 2010 at 02:28:20 -0500, Ryan Lortie wrote: On Sat, 2010-11-20 at 20:15 -0600, Gary Kramlich wrote: That leaves the data directory. However, the data directory on a unix machine ends up being ~/.local/share and putting a native plugin under a share directory seems to be

Re: Base Directory Specification and plugins

On Tue, 23 Nov 2010 at 13:42:32 -0500, Ryan Lortie wrote: With only slight hesitation due to fears of political correctness, I'd suggest using Debian arch names here. They tend to be an awful lot more sane for this purpose. Speaking as a Debian Developer: they're much shorter, but you might

Re: [RFC] Adding /local/lib and /usr/lib to default $XDG_DATA_DIRS search path

On Mon, 04 Apr 2011 at 18:06:38 +0200, Lennart Poettering wrote: Right now the XDG basedir spec says that $XDG_DATA_DIRS should default to /usr/local/share/:/usr/share/ if it is not set. I'd like to make one change to this: add /usr/local/lib and /usr/lib to it. Result:

Re: app id in desktop file

On Tue, 10 May 2011 at 11:25:34 -0700, Dylan McCall wrote: Right now my impression is we have a _convention_ where a namespace should be based on an Internet domain name the software's creator is in control of. I've opened a bug for the D-Bus Specification (which does say you should use a

Re: Base Directory Specification and plugins

On Thu, 01 Sep 2011 at 00:28:37 +0400, Yury G. Kudryashov wrote: I'm replying to an old thread. The original thread can be found here: http://lists.freedesktop.org/archives/xdg/2010-November/011722.html Simon McVittie wrote: The most general and widely used naming scheme for ABIs in Free

Re: desktop-entry-spec: Add an optional Keywords key

On Thu, 01 Dec 2011 at 19:21:21 +, Peter Brett wrote: You also specify localized strings in the description, which implies that the key SHOULD be translated. However, the localestring(s) type only indicates that the key MAY be translated. localizable strings maybe? The point is that it

Re: [RFC] X-Content-Rating key for .desktop files.

On Sat, 03 Dec 2011 at 11:33:15 +, Peter Brett wrote: For example, a .desktop file for the iD Software game Quake 4 might contain the following line: X-Content-Rating=BBFC:18;ESRB:M;OFLC:MA15+;PEGI:18+ If you're proposing this on the XDG list, and people like it enough to add it to the

Re: Document templates specification

On Wed, 07 Dec 2011 at 18:39:10 +0100, André Gillibert wrote: AFAIK, Nautilus (GNOME) and Thunar (XFCE) simply uses files in $XDG_TEMPLATES_DIR (~/Templates by default) I believe the point of this is to make it really easy for a user to create new templates, by having the directory be

Re: Base Directory Specification - XDG_*_DIRS syntax

On Mon, 26 Dec 2011 at 21:16:49 -0500, Charles Suprin wrote: Since no-one else has brought this up, there are portability considerations. There are colons in Windows paths. The ever famous c:\. Also old versions of Apple products used to use colons as well for directory separators. I

Re: questions concerning basedirspec

On 18/01/12 18:25, chrysn wrote: * /var vs. /usr/{local/,}. when i access globally installed data, i have to know whether they are static or variable, and according to fhs go to /usr/{local/,}share/ or /var/. (My personal opinion, others might disagree.) I think XDG basedirs are only

Re: Proposal: preferred-theme-spec - a spec for getting and setting default icon/cursor/sound themes

On 26/03/12 18:26, Jerome Leclanche wrote: FWIU, xsettings is a way of storing the data -- this standard defines the data to be stored. No, xsettings is a way of accessing the data at runtime. The storage in xsettings is transient (X window properties), so it's more like use xsettings instead

Re: Unexpected hash change on old file

On 09/11/12 01:19, Dario Niedermann wrote: http://cgit.../snapshot/... As far as I understand it, these are not permanent files that are stored anywhere: they're generated by the cgit interface on-demand. If the precise details of how it generates that snapshot change, so will the resulting

Re: Spec draft (was Re: Rework of the org.freedesktop.ScreenSaver API?)

On 21/12/12 15:16, Bastien Nocera wrote: So this is what I ended up with: http://people.freedesktop.org/~hadess/idle-inhibition-spec/ Idle inhibition is achieved by ... calling an Inhibit function ... on a well-known D-Bus name. s/function/method/ - D-Bus doesn't have functions. It seems

Re: structure of desktop file directories

On 04/10/13 11:11, Jerome Leclanche wrote: This seems like an implementation detail leaking into the spec. Why should the lib assume the caches are out of date based on the timestamp on applications/? System-wide changes are expected to run u-m-d. I think what Ryan is trying to solve here is:

Re: structure of desktop file directories

On 04/10/13 12:04, Jerome Leclanche wrote: On Fri, Oct 4, 2013 at 11:53 AM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: The search path is longer than that: ~/.local/share/applications by default, and setting XDG_DATA_HOME or XDG_DATA_DIRS changes it per-user and perhaps even per

Re: Linux Malware

On 18/11/13 20:41, Jasper St. Pierre wrote: Who is they? I doubt somebody would use a package manager to install a rootkit on your system. Are you sure what you're seeing is a rootkit? What new PolicyKit modules do you have installed? If a rootkit that already has the ability to execute

Re: New handling for URI scheme handlers

On 02/12/13 09:40, Jerome Leclanche wrote: - Identify whether it's potentially a file through its name (get a filename if there's one) That's not how http works. https://en.wikipedia.org/wiki/Favicon.ico is text/html, not image/x-icon; conversely, if you have a URL like

Re: 'open' instead of 'xdg-open' for usability?

On 16/12/13 10:03, Robert Qualls wrote: Instead of making users google this, shouldn't we just have a universal 'open' command on all freedesktop environments? Unfortunately, that name is already taken. On my Debian system: archetype% which open /bin/open archetype% dpkg -S /bin/open kbd:

Re: Fwd: 'open' instead of 'xdg-open' for usability?

On 16/12/13 15:21, Robert Qualls wrote: The fact that one-word command names are such a limited resource means that they shouldn't be used by obscure programs. openvt is probably older than some of the people on this mailing list (its git history starts in 2007, but the man page is dated July

Re: open(1) removed from Debian? (was: 'open' instead of 'xdg-open' for usability?)

On 24/12/13 02:38, Liam R E Quin wrote: On Sun, 2013-12-22 at 00:28 -0600, Robert Qualls wrote: open belongs in a separate project for high-level, user-facing commands that's basically just a bunch of wrappers that can be easily personalized by users and maintained over time. If it uses such

Re: More about intents: Several improvements to desktop files and caches

On 06/01/14 01:25, Jerome Leclanche wrote: There's a lot TBD still. For example: Do we require apps implementing an intent to support every method of the intent? I don't think it's necessary due to dbus introspection letting us figure out whether a method is supported. With my D-Bus

Re: expanding the inhibit spec

On 07/01/14 18:16, Ryan Lortie wrote: I also find the use of delay inhibits to be slightly distasteful, at least for logout or shutdown. In my opinion, applications that want to do cleanup tasks on exit should register SIGTERM handlers and deal with them that way, exiting when done. I

Re: expanding the inhibit spec

On 08/01/14 07:08, Ryan Lortie wrote: Eventually, if we are convinced that it is widely useful, we may want to add an additional API to deal with (what I consider to be the separate case of) delaying the suspend process for a short while: Delay (in s what, out h fd); with

Re: More about intents: Several improvements to desktop files and caches

On 08/01/14 14:03, Dominique Michel wrote: It is another issue with the terminal emulators, some use -e to launch applications, other use -x, and I am not convinced the wrapper glue they done in Debian recently around gnome-terminal and x-terminal-emulator (Debian terminal), instead of fixing

Re: More about intents: Several improvements to desktop files and caches

On 08/01/14 18:15, Dominique Michel wrote: I agree with you that a protocol is the way to get interoperability, but if upstream is not following it, we don't get it. In that case, xterm is the reference and its man page is clear, we don't need after -e. (If you haven't already, I suggest

Re: volatile config data and XDG Base Directory spec

On 18/02/14 23:53, Richard Hartmann wrote: this discussion has stalled yet again. It has stalled because people aren't convinced that the extra category is worthwhile. Looking at the table on https://wiki.debian.org/XDGBaseDirectorySpecification, which I'll reproduce here in its current state:

Re: volatile config data and XDG Base Directory spec

On 19/02/14 13:03, Ryan Lortie wrote: Specifically, we feel that things should only be installed into ~/.local/share/. Things like fonts, plugins, desktop files, dbus service files, icons, themes, etc. -- essentially things that you would also find in /usr/share if the sysadmin had installed

Re: Draft of proposed new XDG Desktop Application Autostart Spec

On 18/03/14 01:04, Mark Edgington wrote: In an effort to rectify some of the issues which the current Desktop Application Autostart Specification has Which issues? I've drafted an updated version of this spec that includes some new keys which I think should make the spec a bit cleaner and

Re: relative paths in Exec= in .desktop and .service files

On 08/09/14 13:23, Simon McVittie wrote: 3) contains a path separator but is relative ... Reasonable possibilities include: [...] * it's relative to the getcwd() of the process that is interpreting the file, i.e. normally / or $HOME According to https://unix.stackexchange.com/questions

Re: Identifying the real display server

is tied to X11 anyway, so Wayland/Mir is a natural opportunity to get rid of it. -- Simon McVittie Collabora Ltd. http://www.collabora.com/ ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg

Re: XDG environment variables with substitute user

-privilege-escalation tool of choice. It uses an environment whitelist. That means no DISPLAY (unless you explicitly include it in the invoked command - pkexec env DISPLAY=$DISPLAY xterm), hence no X11 apps as root, but to be honest I think that's more feature than bug. -- Simon McVittie Collabora

Re: Identifying the real display server

a similar thing for DISPLAY for a long time, although nothing seems to have come of it. That's a future that I'd prefer to head towards. (tl;dr: PREFERRED_DISPLAY=wayland mir x11 would be better than PREFERRED_DISPLAY=WAYLAND_DISPLAY MIR_DISPLAY DISPLAY.) -- Simon McVittie Collabora Ltd. http

Re: DBus service for screenshots.

however, you do have to go to some effort to solve it. -- Simon McVittie Collabora Ltd. <http://www.collabora.com/> ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg

Relative paths in .desktop, .service files' Exec= lines

RFC === Are there any specific objections to this approach going into the Desktop Entry and D-Bus specifications? Does anyone have a better plan? I'm assuming that GNOME programs do what GLib does, which is to look up executables relative to getcwd(). What do other major desktop environments like

Re: Relative paths in .desktop, .service files' Exec= lines

On 23/06/16 17:53, Allison Lortie wrote: > On Mon, Jun 20, 2016, at 13:24, Simon McVittie wrote: >> One subtlety of the phrasing is that a single .desktop or .service file >> might be visible in more than one directory thanks to symlinks, hard >> links or bind mounts. Th

Re: Separate X Screens - possible on Intel Integrated HD Graphics?

lso possible to achieve within a single 'screen' by modifying or configuring a window manager or compositor to place windows where you want them. (For instance, tiling window managers like Awesome[2] tend to support this sort of thing.) -- Simon McVittie Collabora Ltd. <http://www.collabora.com/&g

Re: Definition of the current icon theme

On Sun, 29 Jan 2017 at 00:57:54 +0300, Роман Чистоходов wrote: > Super simple solution is to write the name of icon theme (and nothing else) to >  $XDG_CONFIG_HOME/icon-theme-name.txt file whenever DE is starting or setting > different icon theme I can't help thinking that a desktop environment

Re: Definition of command line in the Exec key

On Mon, 20 Mar 2017 at 05:09:19 +0300, Роман Чистоходов wrote: > Should it be considered shell command line No, the content of Exec= is not a one-line shell script. If you need to use shell constructs like if...fi, ``, ${} then you must invoke a shell yourself: Exec=sh -c "if foo; then bar;

Re: Relative `Path=` entries in .desktop files

On Sat, 15 Apr 2017 at 22:44:53 +0200, Matthias Klumpp wrote: > 2017-04-15 22:05 GMT+02:00 Sod.Almighty : > > We at the AppImage project (https://github.com/probonopd/AppImageKit) are > > wanting to use relative paths in *.desktop files to refer to locations > > relative to

Re: Dashes and underscores in desktop file IDs

On Wed, 11 Oct 2017 at 08:38:54 -0400, rhkra...@gmail.com wrote: > > If there is consensus that the recommendation should be dashes and not > > underscores, I'd be willing to go with that instead, but I think we > > should pick one. > > I'd like to cast a vote in favor of dashes instead of

Dashes and underscores in desktop file IDs

For historical reasons, D-Bus well-known bus names allow both dashes and underscores (but D-Bus object paths and interface names don't allow dashes). The Desktop Entry Specification has inherited this oddity. This causes intermittent problems in adjacent specifications like Flatpak app IDs and the

Re: [PATCH 0/2] XDG basedir bin dirs

On Wed, 02 May 2018 at 11:30:04 -0700, Josh Triplett wrote: > With the full benefit of hindsight, I'd have > suggested having a single $XDG_HOME that defaults to ~/.local, serving as the > root for > everything except $XDG_CONFIG_HOME, so that people could choose to point > it somewhere other

Re: [PATCH 0/2] XDG basedir bin dirs

On Wed, 02 May 2018 at 13:02:51 -0700, Josh Triplett wrote: > On Wed, May 02, 2018 at 09:52:44PM +0200, Lennart Poettering wrote: > > However, I really don't see the benefit of adding individual > > configurability for each of the home dirs, because you should already > > have that anyway though

Re: DBus interface for meeting creation

On Tue, 13 Mar 2018 at 13:11:45 +, David Woodhouse wrote: > We need to spawn a "new meeting" editor in the client of the user's > choice, pre-populated with meeting dial-in information, conference- > specific attendees, etc. Rather than inventing a small subset of iCalendar encoded into D-Bus

Re: DBus interface for meeting creation

On Tue, 13 Mar 2018 at 14:37:53 +, David Woodhouse wrote: > My concern was that I didn't want to just invoke Evolution — users > might be using something different. But of course doing it through > xdg-open resolves that. If you are using a platform/runtime library like GLib or Qt (presumably

Re: Discussion Proposal: Specifications about panels and widgets

On Mon, 05 Nov 2018 at 13:05:24 +0200, IFo Hancroft wrote: > It is not agreed on whether a panel should provide the taskbar/task > manager, menu, tray, widgets. This is a UX design question. If one desktop environment's designers think there should be a panel with a list of running applications

Re: License recommendation for specs

On Wed, 02 Jan 2019 at 14:02:12 +0100, Egmont Koblinger wrote: > For specifications, even for "free" ones, I think it's outright undesirable to > create and distribute modified work. In order to avoid incompatible > specifications competing against each other, resulting in quite a mess and > poor

Re: DBus signal to disable reminders/notifications

On Tue, 18 Dec 2018 at 22:21:24 +0100, David Faure wrote: > Is there some spec that would allow to implement a desktop-wide signal in > order to disable things like calendar reminders, chat notifications, new > email > notifications etc. during a presentation? Would it be better for your

Re: xdg-basedir for secrets

On Fri, 07 Jun 2019 at 15:19:25 +0200, Bardot Jérôme wrote: > Le 06/06/2019 à 23:15, Jonas DOREL a écrit : > > Currently, most secrets (SSH Keys, GPG Keys, OAuth token) seems to be > > located in XDG_CONFIG_HOME. > And they should not, secrets are data not config. (for me) For what it's worth,

Re: Cleaning of $XDG_CACHE_HOME and $XDG_CACHE_HOME/thumbnails

On Wed, 26 Feb 2020 at 14:39:06 +0100, Benjamin Berg wrote: > I don't think that $XDG_CACHE_HOME is designed to be used directly by > users. And if it is an application which generates those repositories, > then again, it can just drop-in the appropriate configuration to > prevent cleaning. It

Re: Cleaning of $XDG_CACHE_HOME and $XDG_CACHE_HOME/thumbnails

On Wed, 26 Feb 2020 at 19:19:29 +, Bollinger, John C wrote: > Let's do get some clarity on this point, as various comments have seemed > to say different things. Are you suggesting that the *configuration > format* consumed by systemd-tempfiles be reused by some desktop > component, or are

Re: [PATCH] Add XDG_STATE_HOME

On Sun, 22 Dec 2019 at 09:55:56 +0100, David Faure wrote: > On mercredi 13 novembre 2019 09:45:23 CET Jonas DOREL wrote: > > - the benefit from having XDG_CONFIG_HOME split from XDG_DATA_HOME is > > that you can use a VCS with it. > > This is exactly one of the reasons in favour of

Re: A standard for global/desktop environment shortcuts to prevent conflicts with Linux apps

On Wed, 06 May 2020 at 17:37:23 -0400, rhkra...@gmail.com wrote: > We already have formalized vocabularies for talking about these keys, for example in xkb and in the Linux kernel, so let's not invent new ones... > win* is a key with no letters but what looks like the Windows logo The

Re: RFC: deprecating crypto usage in secret-service

On Sun, 30 Aug 2020 at 22:34:24 -0600, Thayne wrote: > How about having some way to signal to D-Bus that a message is > sensitive so should be stored in non-swappable memory? Sorry, this is unlikely to be implementable. dbus-daemon (or dbus-broker or whatever other message bus implementation is

Re: RFC: Application icons/desktop files and their respective tools and specifications

On Sun, 14 Jun 2020 at 03:14:26 +0300, IFo Hancroft wrote: > 1. The Desktop Entry Specifications says the name of a .desktop file > should use be a valid D-Bus well-known name, and follow the reverse DNS > convention for the for the author and dot and then CamelCase. (Note that this is a

Re: XDG Default Applications specification proposal

On Wed, 22 Jul 2020 at 14:39:22 +0200, elek...@markus-raab.org wrote: > Would you also see dbus for notification as implementation detail? Yes; for Notifications, dbus *is* an implementation detail, but D-Bus is not. (I'm being very careful with case combination and spelling here.) The

Re: RCF: Basedir specification for non-Linux

On Mon, 26 Apr 2021 at 23:46:46 +0200, piegames wrote: > in discussions around applications adopting the basedir specification, > the handling of non-Linux systems (especially Windows and MacOS) is > something that really comes up a lot. I think the right way to think about this is Windows vs.

Re: New `MimeType` fields in .desktop

On Thu, 18 Feb 2021 at 00:36:22 -0700, Thayne wrote: > I'd like to point out that on Ubuntu 20.04 there are no system > mimeapps.list files provided (either for DE or globally). It seems like an Ubuntu bug report would be appropriate, if that's true. Debian has at least these:

Re: New `MimeType` fields in .desktop

On Wed, 17 Feb 2021 at 19:22:35 +0100, Jan Tojnar wrote: > For example, to edit a screenshot file in Pictures directory. In Nautilus, I > currently have to click “open with other application” and then find GIMP in > the dialogue. I just do not bother and drag the file on manually started >

Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg

On Thu, 16 Sep 2021 at 04:44:17 +, Peter White wrote: > I am having a hard time finding documentation about the best way to make > locally installed software recognize its config dir in > /usr/local/etc/xdg. One high-level approach to this is: give it sensible defaults, so that it will work

Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg

On Mon, 20 Sep 2021 at 12:28:43 +, Peter White wrote: > Why would XDG_CONFIG_DIRS need to contain ${PREFIX}/etc/xdg for that? > The app pretty much already knows where it is supposed to find *its own* > system-wide config. The location of which *should* be in > ${PREFIX}/etc/xdg//, yes, but

Re: A few questions about escaping in desktop files

On Mon, 22 Aug 2022 at 21:40:58 +0200, meator wrote: > Let the shell do the unquoting?! To quote (pun intended) the standard: > > > Implementations must undo quoting before expanding field codes and before > > passing the argument to the executable program. > > Isn't this forbidden? I guess the

Re: A few questions about escaping in desktop files

On Wed, 24 Aug 2022 at 16:24:24 -0400, Elsie Hupp wrote: > As an aside, if the two main reference implementations resolve a number > of ambiguities in the specification, might updating the specification to > reflect these two reference implementations be a good way of eliminating > said

Re: A few questions about escaping in desktop files

On Mon, 22 Aug 2022 at 09:41:45 +0200, meator wrote: > I've noticed that a lot of the special characters in the second phase have > something to do with the shell. Is shell supposed to be involved in the > execution of the program? I'm currently executing it directly (I'm not doing > sh -c ). If

Re: Is there a way to detect if the System is XDG independently of the environment variables?

On Fri, 29 Mar 2024 at 14:48:35 -0230, Jesús Gómez wrote: > I understand that the XDG_* environment variables are options for the users to > customize their system, but the lack of them doesn't mean that the system is > not following XDG. Correct. If none of the XDG environment variables are set,