Re: Deep Linking for the free desktop
I have an iPhone (which I dutifully hate), and part of how deep-linking URL handlers work is that there is a popup prompt directly *asking the user* whether they want to allow a particular app to open the URL, with options like “Yes”, “No”, “Always”, and “Never”, more or less in the same way that the operating system prompts the user whether or not they want to allow an application to receive the pasted contents of the clipboard. In other words, I assume the way deep-linking URL handlers would work in an XDG setting would be with Flatpak portals, which are generally implemented with this sort of prompt. As for things like Atom feeds… wouldn’t these have a MIME type? If so, wouldn’t this already be handled by a given web browser’s MIME type handling? In the context of Flatpak portals, then, I assume there is already something along the lines of which application should be summoned to handle a given data type and whether it should be able to do so without user confirmation (i.e. “Yes”/“No”/“Always”/“Never”). Anyway, yes, Flatpak is an XDG standard, but they might have their own mailing list that might be more useful for requesting a feature such as this: https://lists.freedesktop.org/mailman/listinfo/flatpak Hope this is helpful! Elsie Hupp > On Feb 12, 2024, at 8:35 AM, Soni L. wrote: > > what would deep linking (like the android/ios feature) look like for the free > desktop? > > obviously the android/ios feature is explicitly designed to restrict the > kinds of apps that can be deep link handlers (so e.g. only the official > twitter app can handle twitter links), which seems very anti-free desktop. so > what would a free desktop alternative look like? > > the point of deep links is that the same link works both in the browser and > in an app. > > also, would it be possible to extend them to, say, atom feeds? those > traditionally only open in an app, but it'd be neat if they could also open > in the browser. > > (disclaimer: we make fedilinks https://fedilinks.org/ and it is our goal to > become this, our goal is to be "deep linking for the free desktop". but > alternative proposals are welcome.)
Re: iTunes
Hi Adrian,Apple doesn’t follow XDG standards—and neither do Chromebooks, for the most part—but this might nonetheless be of some help…“iTunes” (the application), while it did incorporate ”iTunes” (the music store) pretty early on, was mainly designed for offline listening and synchronizing attached devices.“iTunes” (the application) no longer really exists (except as an unrelated standalone storefront on iPhones). In its place is a much more lightweight music-listening application and separate device-management frameworks.Unlike with their operating systems, Apple has tried to make its media stores and media subscriptions available on as many platforms a possible, and this includes making much of the core functionality available in a web browser, as with Spotify, Netflix, and the like.So while I don’t think you can “purchase” music from “iTunes” (the store) on the web, you should be able to listen to previously “purchased” on the Apple Music website, and if you “purchased” music from the iTunes Store in the past, you can export it (on Mac or Windows) and then reimport it into any web-based music “locker” service, most of which should work on your Chromebook.As for using “iTunes” (the application) on a Chromebook (such as for exporting “purchased” music), it may be possible to run the Windows version of the application using the framework “Wine”, either on the the Chromebook’s underlying Linux subsystem or on a cloud-based virtual private server, but… again, that really isn’t related to XDG specifications.If you want to try using iTunes on Wine, this DuckDuckGo search should help you get started:itunes wine chromebookduckduckgo.comBest,Elsie HuppOn Jul 16, 2023, at 11:20 PM, adrian Nira wrote:How can I download iTunes on my chromebook?
Re: Is pyxdg still actively maintained?
Hi Alex, In a comment on a pull request, the maintainer of pyxdg, Thomas Kluyver, described it as "only exist[ing] for historical reasons”: https://gitlab.freedesktop.org/xdg/pyxdg/-/merge_requests/13 > Thomas Kluyver @takluyver commented 1 year ago > > Hi Elsie, > > My argument is essentially that a single Python XDG package makes no sense, > and it only exists for historical reasons. XDG has a whole lot of > specifications and software for a really wide range of things, and it makes > no sense to try to combine them in one big Python package. So I'd say you're > better off making a new library for dealing with user dirs and publishing it > independently. > > If you still want it to be part of PyXDG, and you have (or can get) XDG > commit rights, you're welcome to take over as the maintainer of PyXDG. It's > been 9 years since I volunteered to take it over, and I'm not sure anything I > work on actually uses it now, so I'd be quite happy to pass on responsibility > to someone else. There is another package, xdg-base-dirs, that is actively maintained, and I asked the maintainer there, Scott Stevenson, about taking over pyxdg, and he declined: https://github.com/srstevenson/xdg-base-dirs/issues/83 > Scott Stevenson @srstevenson commented on Oct 30, 2022 > > Thanks for opening this @elsiehupp. I'm not looking to take on maintainership > of other packages at this time, however, I've commented on #75 to try to > renew efforts to find a solution to the namespace collision that doesn't > break existing code for either xdg or pyxdg users. IMHO at the very least pyxdg should be updated with a proper README for PyPI explaining the scope and status of the project. I touched on this in another pull request, but it wasn’t really the focus there. https://gitlab.freedesktop.org/xdg/pyxdg/-/merge_requests/12 So to answer your question, pyxdg is not actively maintained, but Thomas seems receptive to handing over maintainership of the project to someone who is qualified and willing to take on the responsibility. I don’t know if he’s on this mailing list (though it would make sense if he was), but if he doesn’t reply here you could just try opening an issue on the main pyxdg repository if you want to offer to be a new maintainer. Best, Elsie Hupp > On May 9, 2023, at 11:51 AM, Alex Lowe wrote: > > Hi there > > There seems to have been no maintainer activity for pyxdg in the last few > months. Obviously folks are busy with their own things, but that leads to the > question of whether it can be considered actively maintained or not. If not, > how can someone apply to become a maintainer? > > Thanks, > > Alex Lowe
Re: Question regarding $XDG_DATA_DIRS
There are some scenarios where using or not using the trailing slash does actually make a difference, perhaps most prominently in the command-line arguments for rsync. (I can never remember which is correct for a given behavior, so I invariably choose wrong. 路♀️) > On Oct 16, 2022, at 11:16 AM, Lennart Poettering wrote: > > On Do, 13.10.22 00:56, Akbarkhon Variskhanov > (akbarkhon.variskha...@gmail.com) wrote: > >> Hi. >> >> I noticed that the default value has a trailing slash for both directories: >> >>> If $XDG_DATA_DIRS is either not set or empty, a value equal to >>> /usr/local/share/:/usr/share/ should be used. >> >> I was wondering what's the benefit of including a trailing slash? Is >> there a specific purpose to it or is it a typo? With all due respect, >> it looks so out of place. Path-related variables usually strip it off. >> >> Sorry if I'm asking in the wrong place. > > Behaviour should be the same, hence it doesn't matter. > > Note that the root dir "/" necessarily ends in a slash, so it might > make sense to always suffix dirs like that, to make the root dir less > special. > > In systemd documentation we have the rule to always suffix dirs with > "/", to communicate that they are dirs. > > But seriously, whether to suffix dirs or not, effect is the same. And > to some level it's a bikeshedding questions wether to suffix or not. > > Lennart > > -- > Lennart Poettering, Berlin
Re: A few questions about escaping in desktop files
> It is considered valid and the right interpretation what GNOME and KDE both > do. 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 ambiguities? (I’m not remotely near familiar enough with any of the material to have any specific suggestions, though.)
Re: Feature request to expand MIME in order to allow application register default treatment of directories with custom extension
Some clarification via the documentation and also this StackExchange answer from 2008: https://stackoverflow.com/questions/121147 macOS `DocumentPackages` do not need an internal `Info.plist`; rather, filetypes are registered with the operating system via the `Info.plist` of an application that supports given filetypes. It seems like once a `DocumentPackage` extension is registered with the operating system, Spotlight will automatically set the Uniform Type Indicator “com.apple.bundle” and/or “com.apple.package” under `kMDItemContentTypeTree`. For example, if you append `.rtfd` to an arbitrary directory, then run `mdls` against it, among other output you should see: > kMDItemContentType = "com.apple.rtfd" > kMDItemContentTypeTree = ( > "com.apple.rtfd", > "com.apple.package", > "public.directory", > "public.item", > "public.composite-content", > "public.content" > ) It’s been a while since I’ve run into the issue, but if I remember correctly it’s possible to have a directory with a known package extension and have the operating system not recognize the directory as a package if you bring the directory over from another filesystem. I believe the above information is stored as an extended attribute under `com.apple.metadata:kMDItemContentType` and `com.apple.metadata:kMDItemContentType`, but I’m not 100% sure. Obviously an extension to the MIME standard shouldn’t use Apple’s internal extended attributes. At the same time, some degree of cross-compatibility on the Linux end would be nice, and an extension to the MIME standard would be more likely to be supported on the macOS and iOS end (i.e. at a bare minimum not mangling any packages following such a standard). Anyway, the way that macOS applications register package types seems very closely analogous to the way `.desktop` files register MIME types. That said, it could be nice if packages could “self-register” using internal `.desktop` files, albeit obviously without the the `Exec` key.
Re: Feature request to expand MIME in order to allow application register default treatment of directories with custom extension
My initial email from yesterday got held back because the size was too big. Hopefully this version makes it through. Begin forwarded message: From: Elsie Hupp Subject: Re: Feature request to expand MIME in order to allow application register default treatment of directories with custom extension Date: June 17, 2022 at 3:00:12 PM EDT To: xdg@lists.freedesktop.org Hi H.G., et al, One potentially useful precedent here is RFC 2557, or “MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)”: https://datatracker.ietf.org/doc/html/rfc2557 <https://datatracker.ietf.org/doc/html/rfc2557> I’m not entirely sure why this never caught on. … Another potentially useful precedent is the AppImage Project (discussed further in the conclusion): https://appimage.org/ <https://appimage.org/> … The related format for macOS is called `CFBundles`, specifically the `CFBundles` subtype `DocumentPackages`: https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/DocumentPackages/DocumentPackages.html <https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/DocumentPackages/DocumentPackages.html> CFBundles are structured something like the following: Note that this example has most of the contents removed, and I manually changed the icon of the topmost folder, because you can’t actually show the contents of a CFBundle in this way in the Finder unless you break the extension (i.e by literally adding the string “ ”). On an aggressively simplified level, the contents are as follows: (1) `Info.plist` is an XML manifest describing the contents so that the operating system knows how to treat the bundle. (2) The `MacOS` directory contains any executables. (3) The `Resources` contains almost everything else, such as, for example, the application icon, etc. `CFBundles` that are not applications only need a top-level `Info.plist` (with or without the `Contents` directory) and can use basically any directory structure they want, but historically `DocumentPackages` have used structures very similar to application bundles. Also IIRC at some point Apple added the ability to have `CFBundles` that are ZIP archives, but I don’t entirely know what’s involved with that. It’s worth mentioning that Apple has moved away from `DocumentPackages` (as evidenced by the fact that the documentation for them is no longer updated) as they have instead encouraged developers to use obfuscated storage in the `~/Library` folder, since this type of storage works better when cloud-syncing user data with iOS apps. … While it would be nice if Linux file managers had at least a basic level of support for `CFBundles` (i.e. showing them as “files" rather than as “folders”, along with some clever icon heuristic, even if only to keep users from accidentally mangling them), and it would be nice if bundles created by Linux applications also “just worked” on macOS, there isn’t any inherent reason an XDG standard would need to be 100% cross-compatible with the corresponding macOS format. That said, the basic idea of `CFBundles`, with a “file extension” appended to a directory and an XML (or similar) manifest explaining (though not necessarily enumerating) the bundle’s contents could be a good place to start for a similar XDG standard. Considering what standards XDG does already support, some starting points for a manifest format could be: The XDG Desktop Entry specification: https://specifications.freedesktop.org/desktop-entry-spec/ <https://specifications.freedesktop.org/desktop-entry-spec/> The XDG AppStream specification: https://www.freedesktop.org/software/appstream/docs/ <https://www.freedesktop.org/software/appstream/docs/> (The Desktop Entry specification is probably more applicable, though.) The AppImage Project may also be relevant to an extent (as it parallels the portability of macOS application bundles): https://appimage.org/ <https://appimage.org/> One potential option for cross-compatibility could be a mostly boilerplate `Info.plist` “wrapping” an XDG Desktop Entry (rather similar to or even compatible with the AppImage `AppDir`), though I know little enough about how either format is parsed to know how exactly this sort of hybrid bundle would be implemented. … Anybody else have any thoughts here? Best, Elsie Hupp
Re: Questions
Obviously, sandboxing everything doesn’t work very well if the operating system doesn’t provide APIs for sharing data. Unfortunately, these APIs tend to be much more developed on mobile than they are on desktop. (For example, smartphones have form autofill within applications, not just the web browser.) For Flatpak, this API is generally known as “Portals”, but these are not as developed or as widely used as the corresponding APIs that predate them on mobile. Regarding RFCs and the ISO…… the point of Freedesktop.org/XDG is precisely that, to develop and maintain shared standards. Flatpak is an XDG standard. Something that isn’t particularly clear to me is how to propose updates and changes to existing standards. Enough of what constitutes `xdg-user-dirs` is the toolset (which is not a standard) that I assume any changes would have to go through implementation in that toolset, rather than just in conversation in this mailing list. This isn’t really a priority for me to work on at the moment, but I would be curious to hear what other people on the mailing list think about how best to approach the limitations of the existing taxonomy. > On Nov 22, 2021, at 11:56 AM, BARDOT Jérôme wrote: > > Not agree with all your statement. > > Because it depends of users use case and developpers choices. > > For severals things we already have rfc/iso and more. Also database mostly > sql if can have several schema for pure data services (not application > metadata) have for mostly identify use cases a best case schema exist and > should be used by all application and extend with there own. It’s a pain to > try stuff (same functionalities) when software not share data. > > > Game the worst case of software industries. Maintain nothings embed instead > of using something like "DEFINE". And also the great of the great the missing > part of multi users system. > > Game data are just again stupidly store why not using .config .local and more > why i m not fucking able to use a file that set my username, my town name, my > default keybord layout !!! a simple xml file can do the job and can be easily > extends. Why not a save game directory that can be just add to a general > backup path ? it can also permit to all game to use the same protocol to > managing stuff. And when u see gaming is now more profitable than video > industry i think they can help us to help everybody. The concept can also be > use for game assets with a good format migrating system based on some > dimension rules. And one asset for ie a bannier or a fancy skin can be use in > several games. > > > I currently think some stuff need a separation between my stuff, the others > stuff i use. I see 3 different cases : > > - only personnal stuff : email, my own writing, passwords, internet bookmark. > > - mixed content (Images = personnal photo + a set of wallpapers ) > > - only "not" personal (except the fact data exist or not) like ebooks, > torrents file, rss link. > > > I always try to have a global approach to systems. > > I know i will have to deep dive inside in stuff like dbus(which is not > recommend to be used for security reasons if i remember well) and gvfs. > > I have lot and lot things to learn. : \ > > > and remember i m a crooker rules adept http://sl4.org/crocker.html so feel > free to improve my knowledge :) > > > On 22/11/2021 14:26, Elsie Hupp wrote: >> Hi Jérôme, >> >> The way I see it, applications only having access to certain things by >> default is a good security practice. There are ways for applications to >> access files outside their sandboxes, but they need to get explicit >> permission from the system (i.e. the user) in order to do so. >> >> The case of ebooks (as well as the case of notes) is similar to the case of >> email, where for performance and data integrity reasons it may work better >> for the items and their metadata to be stored in a database rather than in >> the filesystem. Additionally, items on disk may be a cache of canonical >> versions stored remotely. Items in the database can then be exposed to the >> operating system through DBUS or FUSE. >> >> My take on `xdg-user-folders` is that even if the data in them is >> technically stored elsewhere, in sandboxes or databases, they can still be >> important as a primary means for the user to interact with their files. A >> way of reconciling secure, high-performance backends with a user-friendly >> folder hierarchy is with a virtual filesystem library like GVFS. >> Unfortunately, GVFS is not easily extensible and not very approachable from >> a development standpoint. >> >> There d
Re: Questions
Hi Jérôme, The way I see it, applications only having access to certain things by default is a good security practice. There are ways for applications to access files outside their sandboxes, but they need to get explicit permission from the system (i.e. the user) in order to do so. The case of ebooks (as well as the case of notes) is similar to the case of email, where for performance and data integrity reasons it may work better for the items and their metadata to be stored in a database rather than in the filesystem. Additionally, items on disk may be a cache of canonical versions stored remotely. Items in the database can then be exposed to the operating system through DBUS or FUSE. My take on `xdg-user-folders` is that even if the data in them is technically stored elsewhere, in sandboxes or databases, they can still be important as a primary means for the user to interact with their files. A way of reconciling secure, high-performance backends with a user-friendly folder hierarchy is with a virtual filesystem library like GVFS. Unfortunately, GVFS is not easily extensible and not very approachable from a development standpoint. There does remain the issue of certain items not neatly fitting the existing taxonomy of `xdg-user-folders`, and I do feel like it could be useful to revisit the categories in use in order to make them a bit more comprehensive. Doing so without creating an even worse mess would be a bit of a process, though. Probably the tidiest approach would be to introduce more generalized synonyms in both the backend and localized frontend names, then let applications use either the original terms or their alternate versions. You would then get things like: • Images -> Pictures • Audio -> Music But also the reverse could be useful. As someone who uses both Linux and macOS, something that has repeatedly tripped me up is the fact that Linux has a folder called “Videos”, while macOS has a folder called “Movies”. So in order to catch typos it could be useful to have the more specific synonym also point to the more general one, like: • Movies -> Videos And, as you mentioned, there are items that don’t fit even in the more generalized categories, so we could have things like: • Projects (i.e. Git repositories, but in general this could include any type of media that “belongs” to a specific project rather than a shared “library”) • Reading/Reference (i.e. books, periodicals, and the like) And, along the lines of “Reading”, there could be a set of synonyms like: • Writing -> Documents Obviously these synonym categories have a lot of flaws and holes, so I’m presenting them not as a coherent set but as an assemblage of potential ideas for adapting the existing categories without discarding or breaking them. With regard to “Games”, though: “Games” can refer to either the applications themselves or their stored data, and saved game data typically isn’t shared with other applications, so Games are kind of the perfect use case for sandboxed per-application data folders. For the purpose of making per-application data more accessible to end users, I opened several related issues suggesting an extension to GVFS for that purpose: https://gitlab.gnome.org/GNOME/gvfs/-/issues/547 https://github.com/flatpak/flatpak/issues/4173 But implementing this is beyond my ability, and it doesn’t seem to be a priority for the GVFS maintainers. What other thoughts do you have? Best, Elsie Hupp > On Nov 22, 2021, at 2:28 AM, BARDOT Jérôme wrote: > > Thx > > Yes it is (helpfull). I already know some stuff i just need to make stuff i > need works. :) > > I first come here for some data approch too. > > Do you think about more data like ebooks that can be great to have ? > > > > where each application basically just has its own sandboxed home folder => > most stupid thing in the world > > > We need an appropriate data security policies tool with an real identity > manager. > > And i currently try to working on a such tool. If people here have ideas feel > free to share. > > > J. > > > On 20/11/2021 20:15, Elsie Hupp wrote: >> Hi Jérôme, >> >> The Arch Wiki has a pretty good guide to the `xdg-user-dirs` package >> installed on most Linux distributions: >> >> https://wiki.archlinux.org/title/XDG_user_directories >> >> I’ve dug around in the boilerplate code for *looking up* `xdg-user-dirs`, >> and it basically queries `XDG_FOOBAR_DIR` for `FOOBAR`, so you *should* >> basically be able to define any custom folder you want. You can check out my >> pending pull request on `pyxdg` for a version of the code that’s somewhat >> easier to read than the original C: >> >> https://gitlab.freedesktop.org/xdg/pyxdg/-/merge_requests/13 >> >> The actual Python file: &
Re: Questions
Hi Jérôme, The Arch Wiki has a pretty good guide to the `xdg-user-dirs` package installed on most Linux distributions: https://wiki.archlinux.org/title/XDG_user_directories I’ve dug around in the boilerplate code for *looking up* `xdg-user-dirs`, and it basically queries `XDG_FOOBAR_DIR` for `FOOBAR`, so you *should* basically be able to define any custom folder you want. You can check out my pending pull request on `pyxdg` for a version of the code that’s somewhat easier to read than the original C: https://gitlab.freedesktop.org/xdg/pyxdg/-/merge_requests/13 The actual Python file: https://gitlab.freedesktop.org/xdg/pyxdg/-/blob/8fa45fbbe4cd6676b388ca0549f875739301ed21/xdg/UserDirectory.py Note that this is a simplified line-by-line translation of `xdg-user-dir-lookup`: https://gitlab.freedesktop.org/xdg/xdg-user-dirs/-/blob/master/xdg-user-dir-lookup.c However, a big part of the functionality behind `xdg-user-dirs` is (a) the basic list is standardized across most Linux distros, and (b) the actual name of the directory is localized into a large number of natural languages. The main reason actually that I joined this mailing list was to ask about directories for difficult-to-categorize use cases, like ebooks or podcasts (or code repositories or, yes, games). So, hypothetically, yes, you could define your own `xdg-user-dirs`. However, `xdg-user-dirs` is a tool rather than standard, and even if you got a pull request approved for some additional directory, it would probably take years to percolate out through the install base and never actually reach 100% of users. Oh, and you’d also need to get it adopted by both GLib and Qt. (Qt would probably be easier, considering Windows does IIRC have a `My Games` directory, so there’s already a cross-platform precedent.) This is to say that if you define your own custom directories in `xdg-user-dirs` in application code, you should always define a fallback. And in some respects `xdg-user-dirs` is kind of falling out of fashion with the rise in Flatpak and Snap for end-user applications, where each application basically just has its own sandboxed home folder, rather than using a shared per-content-type directory, even though Flatpak portals do increasingly support arbitrary locations in userspace. Anyway, I hope this is helpful! Best, Elsie Hupp > On Nov 19, 2021, at 3:51 PM, Jérôme Bardot wrote: > > Hello, > > There is a way to to add this own stuff in XDG_CONFIG_HOME/user-dirs.dirs ? I > want a XDG_GAMES_DIR= > > Also can i access to XDG var from a shell ? > > thx > > More specifically someone can mentor me to push stuff if needed ? >
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
> I find it intriguing that you insult people > right back by calling an *extremely* common convention in technical > mailing lists, a "dusty cultural artifact" and suggesting that it is > malicious behavior. I’ve been using email for 25+ years. (I have people twice my age and people half my age find my technical generation incomprehensible.) Blockquotes have always been annoying and awful, but they had stopped being a constant thorn in my side until I joined this mailing list. They don’t even seem to be a problem on other mailman mailing lists I’m on. > a “dusty cultural artifact” Yes, this is a thing called “shade”. > I am sure we are all delighted to know that disagreeing over mailing > list etiquette "with intent to make smartphones do worse rendering of > the messages" is the point at which you believe it is necessary to > summon the code of conduct committee in order to report > passive-aggressive condescension. Oh, the problem was that that dude took credit for the technical issue and declared it to be righteous and true, all while complaining about a standard nearly as old as the RFC he cited. The irony on top of the irony is that the mangled blockquotes don’t even seem to be his doing; mailman seems to be the one making them terrible for everyone involved. I CC’d the conduct committee so that he wouldn’t respond to me directly. Obviously. Hence the “gently encouraging”. Conduct committees are there for the purpose of dealing with people you don’t want to deal with yourself, even if nobody has really done anything wrong. This was the third or fourth response where he had been lecturing me personally over nothing at all. Also for some reason John’s responses kept ending up in my spam mailbox, so I had gotten six or so green-ink emails in a row with nothing apparently in between them, and I was kind of suspicious this guy wasn’t going to stop on his own.
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
Mr. White, You write: > Be that as it may, one should not have to resort to such rather extreme > measures just to get sane behaviour back. And please stop drumming for > Flatpak. It does have its application but not for this. I mean, come on, more > layers of complexity just for this. Plus all the downsides I do not want to > discuss here, since they are out of scope Flatpak is a major—and standards-compliant—implementation of XDG_CONFIG_DIRS, alongside GNOME, KDE, etc. And you haven’t actually specified what your use case is; you’ve been consistently vague in a way that allows your text to maintain an unearned tone of righteousness and moral superiority. You write: > Yes, that is very much intentional, those are not “soft-wrap” but real line > breaks. You should read up on mailing list netiquette if this is news to you. > Yes, there is an RFC for that, and please don’t go “fixing” my text. As far as I know RFC 1855 is not part of any accepted email specification—i.e. the ones actually used by the more popular email clients—and several of the behaviors encouraged in it lead to undefined behavior on adaptive devices that did not exist in 1995, such as smartphones. Intentionally using formatting that breaks on the vast majority of computing devices in use is not “good etiquette”; this behavior is pedantic, condescending, and passive-aggressive, all attributes that directly violate the Freedesktop Community Standards, which are a much more important document than your dusty cultural artifact: > Examples of behavior that contributes to creating a positive environment > include: > > • Using welcoming and inclusive language > • Being respectful of differing viewpoints and experiences > • Gracefully accepting constructive criticism > • Focusing on what is best for the community > • Showing empathy towards other community members If you dislike that the vast majority of the internet has moved on to adaptive text rendering, I suggest you file an RFC about it, or perhaps chain yourself to the front of the Google headquarters. Or, I don’t know, you could use an email client with more normative text rendering? I assume they do, in fact, make ones that work on dialup ANSI terminals. Oh the irony that you’ve expended reams of text complaining about how you don’t like the long-standing XDG folder specification that everyone else seems to accept, right before you turn around and point to an obscure chain letter from the Clinton administration as if it were some sort of inviolable scripture. I’m CCing the conduct committee as a way of *gently encouraging you* to approach this forum in a modicum of good faith. Note: this is all good-faith, constructive criticism of your behavior, not your character. As such I’m sure it should be no great difficulty for you to take it to heart. Sincerely, Elsie Hupp
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
> Yes, and then there is XDG which expects exactly that, which then leads to > other hacks to soften the isolation of said containers, or the inclusion of > files which the go out of sync and out of date compared to what is in the > real /etc. If I need hard sandboxing to stop such behaviour, then there is a > serious bug in the spec. ;) Flatpak generally provides indirect access to system libraries through “runtimes”, so in order to provide access to, for example, whatever library you’re working on, the library itself could be added to the Freedesktop runtime, which would then provide properly sandboxed access to that library. Filesystem access within $HOME is generally provided through “portals” on Flatpak though I don’t really understand how those work, yet. — P.S. FYI your email client seems to add hard line breaks to soft-wrap text, which renders really strangely on my device. (And I wasn’t sure about the etiquette for quoted email history. I don’t know how much of the peculiarity is just down to how mailman works versus how various email clients work, since some of these issues other mailing-list platforms handle somewhat more gracefully.)
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
> The way you describe it, it would be OK for any app to just parse the config
> of any other. That just feels wrong, because app A should have no business
> snooping in /etc/xdg/B/Brc. If app B wants to make such information available
> to others it should export it instead of requiring those to parse the file.
To be fair, this is one of the motivations behind Flatpak and Snap. If you
don’t want one app snooping where it shouldn’t, then you make it technically
unable to do so.
> On Sep 20, 2021, at 8:28 AM, Peter White wrote:
>
> On Mon, Sep 20, 2021 at 10:20:05AM +0200, David Faure wrote:
>> On dimanche 19 septembre 2021 16:57:22 CEST Peter White wrote:
>>> On Sun, Sep 19, 2021 at 12:19:33PM +0200, David Faure wrote:
On jeudi 16 septembre 2021 18:48:41 CEST Peter White wrote:
> But, /etc should be off limits for software in /usr/local, right?
I don't think this assessment is correct.
For instance, I certainly expect KDE software installed in any prefix, to
respect the global settings in /etc/xdg/kdeglobals
>>>
>>> Why would software need to read that file?
>>
>> Well, that's the point of config files, to be read by software, isn't it?
>
> Well, duh, but not by *other* software. Why would any software have to
> read files it otherwise has no business with? kdeglobals is a file
> related directly to KDE. Plus, every app then also needs to *parse* that
> file. That sounds like an invitation for a whole lot of duplicated
> effort when, if those values are intended to be used, they should be
> available by other means, i.e. provide a library that abstracts that
> away.
>
> The way you describe it, it would be OK for any app to just parse the
> config of any other. That just feels wrong, because app A should have no
> business snooping in /etc/xdg/B/Brc. If app B wants to make such
> information available to others it should export it instead of requiring
> those to
> parse the file.
>
>>> Granted, I know virtually
>>> noting about KDE, but shouldn't there be a facility that makes those
>>> values available by other means, i.e. environment variables, or
>>> a settings daemon or whatever?
>>
>> You want one environment variable per setting in that file? That doesn't
>> scale. A settings daemon might be what gnome does, it doesn't mean that all
>> other free desktops want to have such an architecture. Surely reading files
>> is
>> still allowed in 2021?
>
> Yes, it very much is, just not files of other applications. You seem to
> taking an "illegal" shortcut here, by expecting apps to do things that
> are otherwise frowned upon.
>
>>> And BTW, shouldn't that be /usr/{,local/}share/kdeglobals [1]?
>>
>> No, config files don't go to XDG_DATA_DIRS.
>>
>>> > share/config/ ... A special case is "kdeglobals": this file is
>>> >
>>> > read by all KDE applications.
>>>
>>> and then XDG_DATA_DIRS is the relevant env var which already has the
>>> correct default, as you point out below. Now, I don't know why "config"
>>> files would go anywhere other than ${PREFIX}/etc but that is apparently
>>> what KDE deems the right place.
>>
>> The above documentation is really outdated, it says "kde 3" in many places,
>> it predates the XDG base dir spec (at least, its use by KDE).
>
> Then provide a better reference? That's what my search came up with. ;)
>
>>> Anyhow, if one really needs to make /etc/xdg/kdeglobals available to
>>> apps in /usr/local, then that is one special case that applies to KDE
>>> only
>>
>> I don't believe so. As I said, everyone agrees that /usr is available to
>> apps
>> in /usr/local (since that's the default value for XDG_DATA_DIRS)
>> so why not do the same with config dirs?
>
> And again, *you* talk about /usr and *I* talk about /etc. Compare that
> to PATH. There is no equivalent for /etc, because there doesn't need to
> be.
>
>>> and that is the only case I can think of right now.
>>
>> There are lots of other files in /etc/xdg...
>> For instance /etc/xdg/user-dirs.conf which is not KDE specific at all.
>
> And that also has nothing to do with the config of the app itself. It
> provides information about the environment.
>
XDG_CONFIG_DIRS was modeled very much after XDG_DATA_DIRS,
where I would have tons of other examples like: apps in /usr/local or
anywhere else should still see /usr/share, for e.g. /usr/share/mime which
has the mimetype definitions.
>>>
>>> That is not the same as /etc. The well known behaviour, prior to XDG,
>>> should not be broken for desktops and, as pointed out above, use the
>>> share/.. hierarchy then or whatever, since this seems very much like a
>>> KDE quirk to me and should not be baked into a standard that is supposed
>>> to agnostic of the environment.
>>
>> Please stop saying this is a KDE quirk. It's the XDG base spec that defines
>> /etc/xdg to be the default location for systemwide config files,
>
> And I welcome that effort very much
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
>>> I was hoping they would be, or is there a better way of contacting them? >> >> The authors all have individual email addresses at the top of the >> specification: > > I did notice that, but why ask them privately? Mailing lists are there > so a question can be answered *once*, and the record stays online for > others to find. I did my due diligence before asking here by searching > the archive. But I seem to be first one to ask. From now on others can > at least find that it has been asked and maybe won't have to bother the > authors again. Yes, indeed, asking here first is probably the best approach. The individual email addresses are just useful if you don’t hear back from any of the authors otherwise, and you really want their perspectives. Presuming they’re all on this mailing list, a fallback approach might be to send them a direct email (individually or in a group) nagging them to respond to this thread. (Of course, it isn’t fun to feel like a nag…) I should probably switch my own subscription here to digest mode.
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
>>> I have pondered this for a while now and could also not find >>> anything via search engine or on this list, so I figured I actually >>> ask the ones who wrote the spec. >> >> I did not write the spec, but I have implemented it. I'm uncertain >> whether those who did write it hang around here. > > I was hoping they would be, or is there a better way of contacting them? The authors all have individual email addresses at the top of the specification: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html Waldo Bastian Allison Karlitskaya Lennart Poettering Johannes Löthberg >> Anyway, your questions seem to fall more in the general system >> administration area than in the area of the spec itself. > > I respectfully disagree, since it is a question about what should or > maybe should *not* happen at compile time or at runtime, respectively. I > am asking for a general way to make the software redistributable but > still installable locally, like virtually every software project makes > possible. The admin/user *should* have nothing more to do than making > sure that PATH is set correctly to have /usr/local take precedence, but > that is already taken care of in virtually every distro. It may be worthwhile to add more guidance about “best practices” to the text of the specification, even without any changes to the underlying implementations.
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
> 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 > search path conveyed via $PATH. I did see that XDG_CONFIG_DIRS returns a single string with colon separators. GLib and Qt just use their own preferred data structures instead (as a convenience). > HOWEVER, Base Directory does not specify a first match wins rule. It > attributes more importance (the spec's terminology) to files located in > earlier directories in the list, but that does not imply that only one can be > used. A viable alternative is for applications to look for their config > files in all the specified directories, and to merge the contents according > to priority when more than one is found. At least a limited ability to merge > multiple configs is suggested by the provision for XDG_CONFIG_HOME, which > designates a user-specific search directory of even higher importance that, > alone among all these, is assumed to be writable by the user. This latter is > where a user would record their personal config customizations, and a > user-friendly application with many configuration options will not insist > that users provide a complete configuration just to customize a few items. Thanks for the best-practice advice!
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
> XDG_CONFIG_DIRS acts like PATH does: first match wins, which > I would not expect to happen with conffiles. In general I believe the expectation is for the XDG variables with the plural suffix (i.e. ending in “S”) to return array values. String arrays in C are weird, but it’s possible that you have the option of checking each item in the array rather than just using the first one. I just checked the GLib documentation, and g_get_system_config_dirs(), and it says: > Returns an ordered list of base directories in which to access system-wide > configuration information. > > … > > > Returns: An array of filename > > a `NULL`-terminated array of strings owned by GLib that must not be > modified or freed. https://docs.gtk.org/glib/func.get_system_config_dirs.html So how to access subsequent array entries would probably depend on if or whether you’re using one of GObject’s other language bindings. Looking at Qt’s implementation, by comparison, they have these values that look relevant: > ConfigLocation"~/.config", "/etc/xdg" > GenericConfigLocation "~/.config", "/etc/xdg” > AppConfigLocation "~/.config/", "/etc/xdg/" https://doc.qt.io/qt-5/qstandardpaths.html I don’t remember exactly how GLib implements this, but it probably returns the same values as QStandardPaths, albeit possibly in a different order. Basically if you have a preferred config directory (or an ordered list of preferred directories), you could check each directory on your own list against the directories returned by g_get_system_config_dirs(), or other define an algorithm creating an alternatively sorted array from the g_get_system_config_dirs() return values. It sounds like what you would want to do here is prefer any array value outside the user’s home directory and only use an array value inside the user’s home directory as a fallback. > I think that's why: you cannot write inside such a container, so system- > wide configs cannot be changed. XDG_CONFIG_HOME has the problem, that > one cannot provide a default for everyone, which is the purpose of a > system-wide config and it cannot be installed by make install, unless > each user installs the software to $HOME/.local. Now, that can't be > right. ;) If you’re specifically trying to work within Flatpak, the Flathub Discourse might also be a good place to ask: https://discourse.flathub.org/ Also the Freedesktop Flatpak list: https://lists.freedesktop.org/mailman/listinfo/flatpak I don’t know what the application you’re working on does, but it might also need to be a Flatpak runtime or be packaged within a Flatpak runtime, in which case it might also be worth asking the maintainers of the Freedesktop SDK about it: https://gitlab.com/freedesktop-sdk/freedesktop-sdk (I’ve been on this mailing list for a couple months, and it’s extremely quiet, hence why I’m suggesting other places to reach out.)
