Re: Proposal: titlebar widgeting specification

Without having much say, ... 1. Add widgets to the title bar (such as labels, text inputs, buttons, checkboxes, combo boxes, etc...) to combine the benefits of CSD and window managers I extremely like this idea! I would hope that this brings back together window manager windows and the

Proposal: titlebar widgeting specification

I don't have any rock-solid plan for this specification, I'm just throwing it out there for discussion. I'm using the term "window manager" synonymously with "wayland compositor" throughout this email. The idea is that window managers could provide an API for applications to do either of the

Confusing Network category

Hello together, I was browsing GNOME Software today, and noticed some very strange "Socialize"[1] software, which included various crypto currency clients, Remote Desktop software as well as the Brasil Tax Form Software for 2022. While all this software is legitimate, I'm wondering how well it is

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

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

Re: Feature request to expand MIME in order to allow application register default treatment of directories with custom extension

Am Fr., 17. Juni 2022 um 08:16 Uhr schrieb Hossein : > > — > > To Whom it may concern / Dear XDG Team, > > I'm writing to you regarding "MIME" specification. > > If I'm not wrong, I was born after the internet has become accessible to the > average users in the United States, so I understand that

Re: Feature request to expand MIME in order to allow application register default treatment of directories with custom extension

To Whom it may concern / Dear XDG Team, I'd like to add a use case I consider important: You would finally be able to version complex file types like odt or odf (e.g. in git), which are currently unversionable, because they're zipping themselves. Regards Chris / DarkTrick On 2022/06/17

Feature request to expand MIME in order to allow application register default treatment of directories with custom extension

— To Whom it may concern / Dear XDG Team, I'm writing to you regarding "MIME" specification. If I'm not wrong, I was born after the internet has become accessible to the average users in the United States, so I understand that I might not have the same association with certain ideas and

Re: Standardized permission saving

Hi, I do not think there is any standard for that, as shrinkwrapping apps only makes sense with sandboxing and there has not really been many options for that so far. The closest thing are finish-args in Flatpak manifest [1] which takes a list of CLI arguments [2] I do not think it makes sense

override system mime type

hi members, how do you override a system mime type? in order to have a custom icon in my file browser (thunar), I would simply like to add to the application/x-vmdk-disk mime type defined in /usr/share/mime/ packages/freedesktop.org.xml : should I use/write the full type definition or is there a

Standardized permission saving

Hello, I'm currently working a project to sandbox AppImages and I was wondering if there was any existing generic standard way for applications to request system permissions (eg: xdg-downloads from filesystem, dri from devices), or any up and coming plans for something the like? The solution I'm

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

Re: Questions

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

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

Re: Questions

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

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

Questions

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 Digest, Vol 206, Issue 11

On Mon, Sep 20, 2021, 7:49 PM wrote: > Send xdg mailing list submissions to > xdg@lists.freedesktop.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.freedesktop.org/mailman/listinfo/xdg > or, via email, send a message with subject or body 'help'

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

On Mon, Sep 20, 2021 at 06:14:49PM -0400, Elsie Hupp wrote: > > 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

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

Correction, sorry I just noticed: On Mon, Sep 20, 2021 at 11:49:31PM +, Peter White wrote: > 2. Read in reverse order, so as to go from least important to most -> important, files in XDG_CONFIG_HOME, if it is set, move on otherwise. +> important, files in XDG_CONFIG_DIRS, if it is set, move

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

On Mon, Sep 20, 2021 at 03:04:39PM -0400, Elsie Hupp wrote: > 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

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

On Mon, Sep 20, 2021 at 05:37:02PM -0400, Eli Schwartz wrote: > On 9/20/21 12:03, Peter White wrote: > > The way I see it there will be two universes: FHS and a subtly different > > XDG Base Dir Spec, which breaks with the former in peculiar subtle ways > > and any dev used to the former is in for

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

Again, Peter, what are you looking for at this point? Perhaps you misunderstand the nature of this forum. It is a general discussion list, not a communications portal to a standard-setting body. I'm sorry if you feel frustrated with the response you have received, but feel free to chalk it

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

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

On 9/20/21 15:04, Elsie Hupp wrote: > 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

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

On 9/20/21 12:03, Peter White wrote: > The way I see it there will be two universes: FHS and a subtly different > XDG Base Dir Spec, which breaks with the former in peculiar subtle ways > and any dev used to the former is in for some surprises, when not > reading carefully. Now, I get that by

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

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

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

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

On Mon, Sep 20, 2021 at 03:28:09PM +0100, Simon McVittie wrote: > 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.

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

On Mon, Sep 20, 2021 at 03:06:06PM +0100, Simon McVittie wrote: > 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

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

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.

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

On Mon, Sep 20, 2021 at 09:46:22AM -0400, Elsie Hupp wrote: > > 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

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: 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

> 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,

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

On Mon, Sep 20, 2021 at 08:50:45AM -0400, Elsie Hupp wrote: > > 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

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

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

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

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

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

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

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

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

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

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

Dear Peter, What XDG Base Directory does not particularly contemplate is that there might be a collision between the config or data file names relied upon by different applications (including different versions of the same application). Again, this has nothing in particular to do with how

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

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

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

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

On Thu, Sep 16, 2021 at 01:47:51PM -0400, Elsie Hupp wrote: > >>> 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?

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

Dear John, would you please reply on the list, it being the only recipient? By putting me first, I don't get the list headers cannot do a proper list reply. On Thu, Sep 16, 2021 at 05:38:37PM +, Bollinger, John C wrote: > Dear Peter, > > What XDG Base Directory does not particularly

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

On Thursday, September 16, 2021 12:51:05 PM Peter White wrote: > P.S.: Please reply to the list, so the headers stay intact. I almost did > not notice and would have replied to you privately. Also, please don't > break my formatting. I am trying to obey the netiquette of limiting line > length and

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

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

On Thu, Sep 16, 2021 at 01:21:15PM -0400, Elsie Hupp wrote: > >>> 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

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

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

On Thu, Sep 16, 2021 at 02:49:40PM +, Bollinger, John C wrote: > Your concerns seem to be focused mostly on how to deal with having > multiple versions of the same application installed simultaneously. Exactly. > The challenges involved in making that work for applications that rely > on XDG

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

On Thu, Sep 16, 2021 at 04:15:07PM +, 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 > separated by colon

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

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

On Thu, Sep 16, 2021 at 11:39:30AM -0400, Elsie Hupp wrote: > > 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

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

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

On Thu, Sep 16, 2021 at 01:10:30AM -0400, Elsie Hupp wrote: > I’m by no means an expert on this, but it may be possible that by not > implementing XDG_CONFIG_DIRS the distros’ intention may be for > applications to use, for example, XDG_CONFIG_HOME instead. It may be > worth asking your distro’s

XDG_CONFIG_DIRS an /usr/local/etc/xdg

Dear list, 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. Of course, the quick and easy answer could be: $ env XDG_CONFIG_DIRS=/usr/local/etc/xdg foobar But that is not something one can ask

Re: New `MimeType` fields in .desktop

Dear all, I snipped the above as it just confuses rather than makes life easy. There are two use-cases, a newcomer who comes to one of the distributions and desktops and wants to use it. S/he has no idea which applications are good with x or y because for her/him the applications themselves

Commit rights

Hi all, Recently the Wayland community has pushed for a few XDG spec changes. In the discussions it has come up that there's no xdg-specs reviewer with knowledge about Wayland, and that such a reviewer would be handy to ack Wayland-related xdg-specs changes [1]. What's the process to get commit

Re: Re: Re: Current version of mime-apps-spec?

Delete this account foud no hard drive. Nothing other than planted x3950. --Sent from my Android phone with GMX Mail. Please excuse my brevity.On 7/26/21, 5:45 AM Derek T wrote: Fuck off and remove my name for the fifty times This is bare hardware boot. Hack from early

Re: Re: Current version of mime-apps-spec?

Fuck off and remove my name for the fifty timesThis is bare hardware boot.Hack from early 2010 2013.Inside a bios. Nice excuse On 7/24/21, 5:37 PM Bastien Nocera wrote: On Sat, 2021-07-24 at 14:04 -0600, Kevin Locke wrote: > Hi All, > > I'm curious whether the current version of

Re: Current version of mime-apps-spec?

On Sat, 2021-07-24 at 23:30 +0200, Bastien Nocera wrote: > On Sat, 2021-07-24 at 14:04 -0600, Kevin Locke wrote: >> I'm curious whether the current version of the "Association between >> MIME types and applications" specification is 1.0 or 1.0.1.  Both >>

Re: Specifying sensible device types to use an application on in the desktop file

Hi, On Tue, Oct 20, 2020 at 06:48:08AM +0200, Matthias Klumpp wrote: > Am Fr., 9. Okt. 2020 um 18:03 Uhr schrieb Guido Günther : > > > > [...] > > > > I was thinking about appstream but my understanding is that as of today > > the desktop file is the canonical place for such information but it > >

[no subject]

i need the logging info to null account on xdg ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg

I'm THE WEBM AND MAIL MAN

It's my birth right! ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg

[no subject]

wen do i get the desktlp ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg

[no subject]

Free desktop? ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Help System Specification: Rationale of help path

On 15.05.21 14:35, notebook wrote: Apart from the KDE-guy this sounds like "it's already like this" and "others use it, too". Perhaps I should search for records of that meeting in 2010 - or even dig into the reasoning behind `localedir` (any input welcome). As one of the people involved

Re: Help System Specification: Rationale of help path

On Saturday, May 15, 2021 08:35:41 AM notebook wrote: > rhkramer: > > I am not likely to ever try to > > access a help file in other than my native language ((American) English), > > so getting into a directory with all the other English help files seems > > more natural to me. > > Unfortunately

Re: Help System Specification: Rationale of help path

Thank you for input on this topic! jtojnar: Note that filesystem hierarchy standard already turns the system into a big soup. I would guess it has been influenced by the localedir notably used by Shaun McCance: it is what it is. It's not worth the effort to change it at this point. The KDE

Re: Help System Specification: Rationale of help path

> On Sun, 2021-05-09 at 07:41 +0900, notebook wrote: > > Hello, > > > > Summary > > > > I'd like to know why help files are sorted by language first and then > > by application name, instead of the other way around. > > // I hope this is the right place > > Details > > === > > In [1]

Re: Help System Specification: Rationale of help path

On Sun, 2021-05-09 at 07:41 +0900, notebook wrote: > Hello, > > Summary > > I'd like to know why help files are sorted by language first and then > by application name, instead of the other way around. > // I hope this is the right place I can provide some insight into this, but the

Re: Help System Specification: Rationale of help path

> I'd like to know why help files are sorted by language first and then > by application name, instead of the other way around. I would guess it has been influenced by the localedir notably used by GNU gettext (/usr/share/locale). Or maybe mandir (/usr/share/man), which also supports

Re: Proposal for an intent-apps spec

On dimanche 9 mai 2021 07:49:40 CEST Thayne wrote: > On Fri, May 7, 2021 at 2:51 AM Thomas Kluyver wrote: > > On Fri, 7 May 2021, at 07:14, Thayne McCombs wrote: > > > 2. For terminals that don't natively support DBus (xterm, alacritty, st, > > > urxvt, etc.) would you then need a seperate

Re: InitialPreference (Re: New `MimeType` fields in .desktop)

Hi! A quick message! On Sat, May 8, 2021 at 8:00 PM David Faure wrote: > On samedi 8 mai 2021 14:53:39 CEST Jehan Pagès wrote: > > On Sat, May 8, 2021 at 11:18 AM David Faure wrote: > > > But as soon as two applications are installed, which both claim level > 2, > > > or both claim level 1

Re: Proposal for an intent-apps spec

On Fri, May 7, 2021 at 2:51 AM Thomas Kluyver wrote: > On Fri, 7 May 2021, at 07:14, Thayne McCombs wrote: > > > 2. For terminals that don't natively support DBus (xterm, alacritty, st, > > urxvt, etc.) would you then need a seperate desktop file for a wrapper > > that launched it with dbus

Re: New `MimeType` fields in .desktop

Thayne McCombs On Sat, May 8, 2021 at 2:42 AM David Faure wrote: > On samedi 8 mai 2021 08:08:17 CEST Thayne wrote: > > On Fri, May 7, 2021 at 8:35 AM Marc Pervaz Boocha > > > > wrote: > > > Another option is maybe have an option in the the definition of > > > mimetypes xml files to have some

Help System Specification: Rationale of help path

Hello, Summary I'd like to know why help files are sorted by language first and then by application name, instead of the other way around. // I hope this is the right place Details === In [1] is specified, that help files are found under `$XDG_DATA_DIRS/help/$lang/$path/`. That

Re: $XDG_OPEN (Re: New `MimeType` fields in .desktop)

Good suggestion! Will do that! On 5/8/21, David Faure wrote: > On mercredi 5 mai 2021 19:16:34 CEST Stefan Blachmann wrote: >> I have looked at the xdg-open script. >> >> I'd like best if I could just set an environment variable XDG_OPEN to >> another program. >> So xdg-open just passes through

Re: InitialPreference (Re: New `MimeType` fields in .desktop)

Some thoughts. There are several "usage criteria" that could be used for ordering. In a situation when one just wants to quickly view something then the criteria are different ones when one wants to edit. Some people prefer simplicity. Others prefer feature-completeness. And so on. I doubt that

Re: InitialPreference (Re: New `MimeType` fields in .desktop)

On samedi 8 mai 2021 14:53:39 CEST Jehan Pagès wrote: > On Sat, May 8, 2021 at 11:18 AM David Faure wrote: > > But as soon as two applications are installed, which both claim level 2, > > or both claim level 1 (with no level 2 available), this proposal would > > just > > move the problem, because

Re: InitialPreference (Re: New `MimeType` fields in .desktop)

Hi! On Sat, May 8, 2021 at 11:18 AM David Faure wrote: > On lundi 3 mai 2021 15:36:05 CEST Jehan Pagès wrote: > > Now if we comes into PSD or ORA files, these are not GIMP's native files, > > but they have clearly similar intent and since we support it, yes GIMP > is a > > very sane choice too

InitialPreference (Re: New `MimeType` fields in .desktop)

On lundi 3 mai 2021 15:36:05 CEST Jehan Pagès wrote: > Now if we comes into PSD or ORA files, these are not GIMP's native files, > but they have clearly similar intent and since we support it, yes GIMP is a > very sane choice too (but if Photoshop were on Linux for instance, I would > say it

$XDG_OPEN (Re: New `MimeType` fields in .desktop)

On mercredi 5 mai 2021 19:16:34 CEST Stefan Blachmann wrote: > I have looked at the xdg-open script. > > I'd like best if I could just set an environment variable XDG_OPEN to > another program. > So xdg-open just passes through to my script. This makes sense. In theory all implementations called

Re: New `MimeType` fields in .desktop

On mardi 4 mai 2021 16:05:20 CEST Stefan Blachmann wrote: > Shouldn't the DE, respective the file manager keep a LRU sorted list > of applications for each mime/file type, so that it sort of > "memorizes" and respect the users' favorite apps? > So the list of the applications shown on "Open With"

Re: New `MimeType` fields in .desktop

On samedi 8 mai 2021 08:08:17 CEST Thayne wrote: > On Fri, May 7, 2021 at 8:35 AM Marc Pervaz Boocha > > wrote: > > Another option is maybe have an option in the the definition of > > mimetypes xml files to have some kind of derivation. So all text/xml is > > will be marked as text/plain for

Re: New `MimeType` fields in .desktop

On Fri, May 7, 2021 at 8:35 AM Marc Pervaz Boocha wrote: > Another option is maybe have an option in the the definition of > mimetypes xml files to have some kind of derivation. So all text/xml is > will be marked as text/plain for applications. > that seems more complicated to me than a system

Re: Proposal for an intent-apps spec

On vendredi 7 mai 2021 11:05:33 CEST Bastien Nocera wrote: > On Mon, 2021-05-03 at 12:13 +0200, David Faure wrote: > > * lookup desktop file from intent > > * start that process > > * make a DBus call to it > > How do you plan on implementing that in, say, xterm, or rxvt? It doesn't have to be

Re: New `MimeType` fields in .desktop

Another option is maybe have an option in the the definition of mimetypes xml files to have some kind of derivation. So all text/xml is will be marked as text/plain for applications. On 07/05/21 7:46 pm, Thayne wrote: On Fri, May 7, 2021, 04:18 Stefan Blachmann >

Re: New `MimeType` fields in .desktop

On Fri, May 7, 2021, 04:18 Stefan Blachmann wrote: > On 5/7/21, Thayne McCombs wrote: > > > > I open text files in a lot of different formats, and I'd like to be able > > to open > > them all with the same editor, but adding an entry for every text/* > > entry that I > > could ever possibly use

Re: New `MimeType` fields in .desktop

On 5/7/21, Thayne McCombs wrote: > > I open text files in a lot of different formats, and I'd like to be able > to open > them all with the same editor, but adding an entry for every text/* > entry that I > could ever possibly use to my mimeapps.list is quite a pain. This is why my opinion is

Re: Proposal for an intent-apps spec

On Mon, 2021-05-03 at 12:13 +0200, David Faure wrote: > On lundi 3 mai 2021 12:04:30 CEST Bastien Nocera wrote: > > On Mon, 2021-05-03 at 11:44 +0200, David Faure wrote: > > > Hello everyone, > > > > > > I just created > > > https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/45 > > >

Re: Proposal for an intent-apps spec

On Fri, 7 May 2021, at 07:14, Thayne McCombs wrote: > 1. Where is the DBus interface for launching the terminal defined? It > isn't in this spec, is it part of a different spec? I think KDE & Gnome developers are planning to make a spec for that, but there isn't one yet. There's a lot of

Re: New `MimeType` fields in .desktop

On 5/3/21 1:36 PM, Eli Schwartz wrote: And then there is mimeo, a program that lets you take a desktop file and add default associations for it, for every mimetype matching, say, 'glob:text/*'. Because if you don't whack mimeapps.list with a big stick and add user preferences for every

Re: Proposal for an intent-apps spec

On 5/3/21 4:13 AM, David Faure wrote: On lundi 3 mai 2021 12:04:30 CEST Bastien Nocera wrote: On Mon, 2021-05-03 at 11:44 +0200, David Faure wrote: This still doesn't fix the problem of knowing _how_ to launch applications in those terminals when the options are different, and expect different

Re: Proposal for an intent-apps spec

On Thu, 6 May 2021, at 13:25, David Faure wrote: > OK, I'll use that, I'll just replace "But" with "Remember however that", > since > IMHO "But" sounds a bit too much like there's a flaw in the spec, while this > is perfectly normal and expected. That makes sense, thanks! Thomas

Re: Proposal for an intent-apps spec

On jeudi 6 mai 2021 12:27:21 CEST Thomas Kluyver wrote: > Better, but I think it still implies that reading all intentapps.list files > is sufficient to find all implementations of a given intent. I would say > something like: > > "It's also possible to put several implementations of an intent in

Re: Proposal for an intent-apps spec

On Thu, 6 May 2021, at 10:36, David Faure wrote: > OK, I added "In any case it should be consistent across runs rather than > random (e.g. based on the order of an unsorted list of files from a > directory)". Sounds good, thanks! > > I'm not sure about the last sentence you've now added: > >

Re: Proposal for an intent-apps spec

On jeudi 6 mai 2021 11:12:47 CEST Thomas Kluyver wrote: > Yup, I agree - this is a recommendation rather than a specification. I like > what you've written for this now. Given the confusion with the equivalent > case in mime-apps, I might add a sentence like: > > "However, whatever we do should

Re: Proposal for an intent-apps spec

Hi David, On Thu, 6 May 2021, at 09:35, David Faure wrote: > > Of course, a launcher may > > have a hardcoded default for specific interfaces it recognises - e.g. KDE > > might pick Konsole for org.freedesktop.Terminal1 - but it should be > > prepared to handle interfaces it doesn't know. > >

<    1   2   3   4   5   6   7   8   9   10   >