Re: Expand os-release spec with LOGO

On So, 07.10.18 15:39, hel...@opensuse.org (hel...@opensuse.org) wrote: > Hi, > > A few months ago a discussion happened about changing display logo for Gnome > depending on os-release file [1]. > > However spec [2] doesn't cover DEs wanting to add items to it, just OSes, > which > will still

Re: Expand os-release spec with LOGO

On Sun, Oct 7, 2018 at 5:47 PM, Jeremy Bicha wrote: On Sun, Oct 7, 2018 at 9:40 AM wrote: However spec [2] doesn't cover DEs wanting to add items to it, just OSes, which will still not be great, if support would have to be extended to SUSE_LOGO, DEBIAN_LOGO, UBUNTU_LOGO etc. I think

Re: Expand os-release spec with LOGO

On Sun, Oct 7, 2018 at 9:40 AM wrote: > However spec [2] doesn't cover DEs wanting to add items to it, just > OSes, which > will still not be great, if support would have to be extended to > SUSE_LOGO, > DEBIAN_LOGO, UBUNTU_LOGO etc. I think the GNOME proposal does do what you are requesting. I

Expand os-release spec with LOGO

Hi, A few months ago a discussion happened about changing display logo for Gnome depending on os-release file [1]. However spec [2] doesn't cover DEs wanting to add items to it, just OSes, which will still not be great, if support would have to be extended to SUSE_LOGO, DEBIAN_LOGO,

[PATCH] xdg-screensaver: fix inhibition for freedesktop(BR102124)

According to the spec the dbus-send approach is not working for inhibition. This will change that to a perl solution similiar to the gnome case. Also fix `reset` to call `SimulateUserActivity` --- I have yet to grok the codebase, but this fix my issues under KDE. scripts/xdg-screensaver.in | 73

Re: desktop-entry: make Icon field non-translatable?

On Sun, 2018-09-09 at 21:08 -0400, Jeremy Bicha wrote: > Originally, the desktop-entry-spec set the Icon field as "string". It > was changed in 2006 to "localestring" which means it is translatable. > > Recently in GNOME, many projects have switched from intltool to > gettext. gettext treats the

Re: desktop-entry: make Icon field non-translatable?

On 10/09/2018 11:33, Matthias Klumpp wrote: > Am Mo., 10. Sep. 2018 um 03:09 Uhr schrieb Jeremy Bicha : >> >> Originally, the desktop-entry-spec set the Icon field as "string". It >> was changed in 2006 to "localestring" which means it is translatable. >> >> Recently in GNOME, many projects have

Re: desktop-entry: make Icon field non-translatable?

Am Mo., 10. Sep. 2018 um 03:09 Uhr schrieb Jeremy Bicha : > > Originally, the desktop-entry-spec set the Icon field as "string". It > was changed in 2006 to "localestring" which means it is translatable. > > Recently in GNOME, many projects have switched from intltool to > gettext. gettext treats

desktop-entry: make Icon field non-translatable?

Originally, the desktop-entry-spec set the Icon field as "string". It was changed in 2006 to "localestring" which means it is translatable. Recently in GNOME, many projects have switched from intltool to gettext. gettext treats the Icon field as a translatable string without a way for projects to

Re: A spec to set default terminal applications?

Reusing `Categories` key would be nice, but we would still need `category-defaults.list` for actually choosing the default representant for each category, would not we? Caching is a good point, we would need to create some mechanism no matter which solution we choose – for instance, if some

Re: A spec to set default terminal applications?

I see three more possible problems: - There might already be some applications that implement those names. After DEs implement this, the apps would be recognized as terminals. - DEs not supporting the updated spec would allow user to trigger those actions, even though they cannot substitute

Re: A spec to set default terminal applications?

Hi again, There is another way to make this xdg terminal exec stuff more standard compliant by reusing XDG menu spec. https://specifications.freedesktop.org/menu-spec/latest/apas02.html We can parse all desktop entry files and collect every one with Category=TerminalEmulator to generate a list of

Re: A spec to set default terminal applications?

Hello, Just took a look at xdg-terminal-exec and I liked the idea. Actually I figured out something similar previously but did not write any code. There is, however, one thing I'd like to propose to make the spec more complete. Use the Desktop Entry Actions.

Re: A spec to set default terminal applications?

Couple of notes. xdg-terminal-exec in its current form is a minimum intervention solution: you need to place desktop files for some terminals, then use xdg-terminal-exec itself as a command to launch terminal. ArgPrefix has a solid generic use case: there was a bug in Ocrfeeder:

Re: A spec to set default terminal applications?

Relying on `Implements=` key should work, though I think the `ArgPrefix` should be part of the desktop file itself – it will be static and defined by the vendor. Also for the system to be efficient, DEs would want to add something like PCMan’s cache mentioned in the intents mail. However,

Re: A spec to set default terminal applications?

Huh, good find. I was about to type up an email about how the "Implements=" key that was added after that proposal is kind of useless in our case; as it says, "it is entirely up to the entity who defined a particular interface to define what it means to implement it." But then I realized that we

Re: A spec to set default terminal applications?

For what it’s worth, there already was a quite nice Intents proposal [1]. Android Intents [2] might be interesting as well. [1]: https://lists.freedesktop.org/archives/xdg/2014-January/013068.html [2]: https://developer.android.com/reference/android/content/Intent On Wed, 29 Aug, 2018 at 10:14

Re: A spec to set default terminal applications?

Hey, that's a thought. Something like an intent system sounds perfect to categorize these actions. And then desktops could stop abusing the MIME system or gconf or hardcoding for these things. Somebody's got to bring up that we could take the easy way out and have x-intent/ be a whole category of

Re: A spec to set default terminal applications?

That's an interesting area. For example, XFCE has generalizations like web browser, email client facilitated by their own reinvented wheel inside exo-open AFAIK. I found a way to do some without any special treatment: I have a bind in Openbox to open browser and mail client set up like

Re: A spec to set default terminal applications?

> No, it is just for terminals themselves. I know, by "application" I meant the terminal apps themselves not the apps that run inside them as you pointed out. At the time I thought it could be a little troublesome, but the more I've looked into it the more I'm thinking patching install scripts to

Re: A spec to set default terminal applications?

On 2018-08-29 00:27, Ian Huang wrote: Mostly just because it would require a second desktop file for each application to put under the xdg-terminals/ directory. No, it is just for terminals themselves. Ultimately, I think if the solution is to

Re: A spec to set default terminal applications?

Vladimir Kudrya > Last year I proposed a mechanism for this purpose: > https://github.com/Vladimir-csp/xdg-terminal-exec/ > I like this proposal a lot, but it seems to me to be a little inconsistent with the selection of other default handlers. Mostly just because it would require a second

Re: A spec to set default terminal applications?

I have my shell script mime types associated with my text editor, not my terminal emulator. Liam R E Quin schrieb am Di., 28. Aug. 2018 um 09:07 Uhr: > On Mon, 2018-08-27 at 17:26 -0700, Ian Huang wrote: > > Anyway, it was brought up—both in the issue and on GNOME's IRC—that a > > MIME > > type

Re: A spec to set default terminal applications?

On Mon, 2018-08-27 at 17:26 -0700, Ian Huang wrote: > Anyway, it was brought up—both in the issue and on GNOME's IRC—that a > MIME > type for terminal emulators (@borschty proposed something like > x-task/terminal) in the specification would make things a bit easier. There's a MIME type for a

Re: A spec to set default terminal applications?

Hello! Last year I proposed a mechanism for this purpose: https://github.com/Vladimir-csp/xdg-terminal-exec/ It addresses issues like inconsistent cli arguments of different emulators and general difference in paradigms between choosing a terminal emulator and

Re: A spec to set default terminal applications?

Apparently, this has already been discussed in 2015 https://lists.freedesktop.org/archives/xdg/2015-October/013583.html however, it seems to have fizzled out. ___ xdg mailing list xdg@lists.freedesktop.org

Re: A spec to set default terminal applications?

I would like to add that this looks like an omission in the Desktop Entry Specification, since the Terminal key is only described as > Whether the program runs in a terminal window. [1] but it is not clear what does that mean. The specification should clarify, link to another specification,

A spec to set default terminal applications?

Hello, I'm just a regular GNOME user, but I recently stumbled across an issue on GitLab that brought up the concern that there seems to be no good way at the moment to specify the default terminal to handle applications with the Terminal=true field

Re: query on systemd services ordering for daemonize process

On Fr, 03.08.18 09:29, Rajesh Kumar (myemail.rajeshku...@gmail.com) wrote: Please direct questions regarding systemd to the systemd mailing list, not to the XDG mailing list. Thank you for understanding, https://lists.freedesktop.org/archives/systemd-devel/ Lennart -- Lennart Poettering, Red

query on systemd services ordering for daemonize process

Hi All, We are facing issue in on system services. Problem statement: We have two process P1 and P2, both are getting daemonize using fork() command and parent exits immediately after fork(). We want process P2 to start once P1 is initialized successfully (means P2 should start when P1 is

Re: Ideas

First thx I don’t want force anybody i want offer a something for people want to work together and improve workflow. The fact is i m newbie with specification and how it’s work. I want to do it well. Maybe i should send a message to several projects in order to federate ideas and best practices

Re: Question about the XDG_SESSION_TYPE environmental variable

On pátek 20. července 2018 10:48:04 CEST Lennart Poettering wrote: > I have commented on the bug. TLDR: they have never been formalized as > fdo spec, but they are documented by systemd and are official API of > it. if you want to make them an fdo spec, by all means go ahead, you > have my

Re: Question about the XDG_SESSION_TYPE environmental variable

On Fr, 20.07.18 09:19, Michal Srb (m...@suse.com) wrote: > GTK currently unconditionally prefer Wayland and I have hit a bug when GTK > applications started from X11 session start in unrelated Wayland session. So > I > tried to advocate the use of this variable for backend selection in GTK: >

Thumbnail cache cleanup

Howdy folks! I don't see anything in the thumbnail spec[1] about thumbnail cleanup policy, and as a result, the thumbnail cache's size is unbounded and can become quite large for users with a lot of images. Should we add some kind of cleanup recommendation to the spec, or rely on distros to

Re: AW: Seeking Bug analysis assistance for systemd

On Thu, 2018-07-19 at 14:35 +, Pacal Mario wrote: > Dear sirs and madams, > > Apology in advance if contacting this mailing list was the wrong > thing to do. > If so, please advise me on where to find answers for my system > related problem. This isn't the mailing-list for systemd. The

AW: Seeking Bug analysis assistance for systemd

Dear sirs and madams, Apology in advance if contacting this mailing list was the wrong thing to do. If so, please advise me on where to find answers for my system related problem. I am seeking assistance in the underlying problem's root cause analysis caused by an unknown source. As well as the

Re: Ideas

Hi Jérôme, On Wed, Jun 27, 2018, at 10:11 PM, Jérôme Bardot wrote: > Like it’s done with ~/.config why not do the same for > > ~/.contacts/*.vcf > ~/.calendars/*ics > ~/.password-store > ~/.email > ~/.rss > ~/.bookmark > ~/.torrent > ~/.xmpp-message (maybe should it be merge with email) I think

Ideas

Hello, I tired so sry for my bad english. I don’t know if it’s the right place for this but you will say to me. Like it’s done with ~/.config why not do the same for ~/.contacts/*.vcf ~/.calendars/*ics ~/.password-store ~/.email ~/.rss ~/.bookmark ~/.torrent ~/.xmpp-message (maybe should it

XDG_RUNTIME_DIR: Periodic clean-up

Me again :-) XDG_RUNTIME_DIR has a number of useful guarantees, and I want to use it, but I'm finding it tricky to do so in a reliable way. I've complained before about the fact that processes running in screen/nohup can have the directory deleted from underneath them when the user

Re: some issues with mime types

On Sat, Jun 9, 2018, at 8:01 PM, kendell clark wrote: > OK, I feel stupid. Apparently linux doesn't identify everything with a > .bin extension as sega disk image, it also detects sega saturn rom > images. However, it does still identify everything else with a .bin > extension as sega cd disk

Re: some issues with mime types

hi OK, I feel stupid. Apparently linux doesn't identify everything with a .bin extension as sega disk image, it also detects sega saturn rom images. However, it does still identify everything else with a .bin extension as sega cd disk images, even windows software. I'm not sure what can be done

Re: some issues with mime types

    hi I have filed a new bug against shared mime info at, https://bugs.freedesktop.org/show_bug.cgi?id=106792. I accidentally commented on a bug that was not mine, I've attempted to find a way to delete the comment since it was clearly the wrong bug but I can't find a remove comment button. This

some issues with mime types

hi all I play a lot of emulated game consoles, from regular nintendo, nes to playstation 2, ps2. The freedesktop mime database has no magic detection for nes, snes, wanderswan, some of the older atari rom types, and doesn't support ps1 or 2 rom images, nor xbox images. I'd like to help improve

Re: Updating which specs have "pretty good" adoption

Thanks Simon; I've added some notes on the wiki pages of the relevant specs. Does anyone know about their adoption in other desktops? Thomas On Thu, May 31, 2018, at 2:31 PM, Simon Lees wrote: > Here is the status from Enlightenment as far as i'm aware > > On 31/05/18 05:09, Thomas Kluyver

Re: Updating which specs have "pretty good" adoption

Here is the status from Enlightenment as far as i'm aware On 31/05/18 05:09, Thomas Kluyver wrote: > I'm working on updating the list of specifications here: > https://wiki.freedesktop.org/www/Specifications/ > > I think several of the specs listed as "not yet widely used" are now well >

Updating which specs have "pretty good" adoption

I'm working on updating the list of specifications here: https://wiki.freedesktop.org/www/Specifications/ I think several of the specs listed as "not yet widely used" are now well accepted, and could be upgraded to "pretty good adoption". In particular, these specs describe files which are on

Re: XDG_RUNTIME_DIR: When is a user logged out?

Is there something else we can do to ask the system to keep XDG_RUNTIME_DIR around? Or should any application which might be run in nohup/screen just not rely on XDG_RUNTIME_DIR? Thomas On Thu, May 10, 2018, at 4:08 PM, Lennart Poettering wrote: > On Do, 10.05.18 15:27, Thomas Kluyver

Re: XDG_RUNTIME_DIR: When is a user logged out?

On Do, 10.05.18 15:27, Thomas Kluyver (tho...@kluyver.me.uk) wrote: > Thanks Lennart. Would it make sense for our application code to open > a Pam session in this scenario so it counts as a login? Sorry if > this is a silly question: I know ~nothing about how logins work. PAM sessions are

Re: XDG_RUNTIME_DIR: When is a user logged out?

Thanks Lennart. Would it make sense for our application code to open a Pam session in this scenario so it counts as a login? Sorry if this is a silly question: I know ~nothing about how logins work. Thomas On Thu, May 10, 2018, at 2:42 PM, Lennart Poettering wrote: > On Do, 10.05.18 09:38,

Re: XDG_RUNTIME_DIR: When is a user logged out?

On Do, 10.05.18 09:38, Thomas Kluyver (tho...@kluyver.me.uk) wrote: > The basedir spec says of XDG_RUNTIME_DIR: > > > ...if the user fully logs out the directory MUST be removed. > > What counts as logging out? For some application code, I assumed that if the > application was running as user

XDG_RUNTIME_DIR: When is a user logged out?

The basedir spec says of XDG_RUNTIME_DIR: > ...if the user fully logs out the directory MUST be removed. What counts as logging out? For some application code, I assumed that if the application was running as user X, that meant user X was still logged in, and the application could rely on

Fwd: Re: Licensing for file manager DBus interface spec

With the agreement of the author (see below), I've added license information to the file manager DBus interface spec, with a note that anyone contributing to that page in the future agrees to license their contribution the same way. Federico also agreed on this licensing for any other

Re: Consider adding license information to freedesktop.org wiki contents?

On Sun, May 6, 2018, at 3:36 PM, Daniel Stone wrote: > OK, done now. Thanks! By digging into that, I confirmed that Federico is the sole author of the file manager interface spec that kicked off this discussion. A couple of people, myself included, have adjusted formatting since the transition

Re: Consider adding license information to freedesktop.org wiki contents?

On Sun, May 6, 2018, at 1:56 PM, Daniel Stone wrote: > The wiki doesn't run on MoinMoin anymore. All the wiki content is I'm trying to get the history - a lot of the wiki pages in the current system were converted from moin, so that old data is needed to try to work out who wrote them. Sorry

Re: Consider adding license information to freedesktop.org wiki contents?

Hi, On 5 May 2018 at 18:50, Thomas Kluyver wrote: > I have found where the Moinmoin data is located > (/srv/www.freedesktop.org/moin/data on annarchy.freedesktop.org). Could > someone add me (takluyver) to the www-data group so I can investigate it > further? Or you

Re: Consider adding license information to freedesktop.org wiki contents?

On 06/05/18 21:25, rhkra...@gmail.com wrote: > On Sunday, May 06, 2018 05:49:15 AM Simon Lees wrote: >> if I wrote anything on the wiki which I don't think I did I would be >> more then happy for it to be relicensed under a BSD/MIT style license >> but would be less happy to allow because I

Re: Consider adding license information to freedesktop.org wiki contents?

On Sunday, May 06, 2018 05:49:15 AM Simon Lees wrote: > if I wrote anything on the wiki which I don't think I did I would be > more then happy for it to be relicensed under a BSD/MIT style license > but would be less happy to allow because I don't think its the right > license for the task. allow

Re: Consider adding license information to freedesktop.org wiki contents?

On 06/05/18 20:06, Thomas Kluyver wrote: > On Sun, May 6, 2018, at 10:49 AM, Simon Lees wrote: >> The only way that I think we can realistically make the wiki situation >> better is by changing it now to say new changes are under the following >> license, then in 10 years hope that enough of the

Re: Consider adding license information to freedesktop.org wiki contents?

On Sun, May 6, 2018, at 10:49 AM, Simon Lees wrote: > The only way that I think we can realistically make the wiki situation > better is by changing it now to say new changes are under the following > license, then in 10 years hope that enough of the content has been > changed that someone can

Re: Consider adding license information to freedesktop.org wiki contents?

On 06/05/18 17:40, Thomas Kluyver wrote: > On Sun, May 6, 2018, at 8:40 AM, Simon Lees wrote: >> Anyone >> who goes to the effort of editing a wiki knows and acknowledges that the >> content they have produced will be displayed on the wiki in its current >> form and are therefore giving

Re: Consider adding license information to freedesktop.org wiki contents?

On Sun, May 6, 2018, at 8:40 AM, Simon Lees wrote: > Anyone > who goes to the effort of editing a wiki knows and acknowledges that the > content they have produced will be displayed on the wiki in its current > form and are therefore giving permission for the content they have > created to be

Re: Consider adding license information to freedesktop.org wiki contents?

On 06/05/18 02:30, Thomas Kluyver wrote: > I also stole about 30 sheets of toilet paper from a hotel a few weeks ago. > Please, someone explain property law to me! > > More seriously, it's clear that my proposed solution is not going to fly, > because we're taking copyright Very Seriously.

Re: Consider adding license information to freedesktop.org wiki contents?

I have found where the Moinmoin data is located (/srv/www.freedesktop.org/moin/data on annarchy.freedesktop.org). Could someone add me (takluyver) to the www-data group so I can investigate it further? Or you could make all that data world-readable. On Sat, May 5, 2018, at 6:00 PM, Thomas

Re: Consider adding license information to freedesktop.org wiki contents?

I also stole about 30 sheets of toilet paper from a hotel a few weeks ago. Please, someone explain property law to me! More seriously, it's clear that my proposed solution is not going to fly, because we're taking copyright Very Seriously. Since we are taking copyright Very Seriously, there

Re: Consider adding license information to freedesktop.org wiki contents?

On 13.04.2018 13:11, Thomas Kluyver wrote: On Fri, Apr 13, 2018, at 11:48 AM, Bastien Nocera wrote:> This isn't how copyright works, sorry. Thanks, I was aware of this. No, it doesn't strictly adhere to 'how copyright works', but realistically, people who contribute to a freely available

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

Hi, I agree with Lennart it is not a good choice to just throw env vars onto everything. But I disagree that "best way to get this in quickly..." is something we should use as argument. About the patch: "at an appropriate place" does not add anything useful, remove it or suggest something

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: [PATCH 0/2] XDG basedir bin dirs

On Wed, May 02, 2018 at 09:42:44PM +0200, Lennart Poettering wrote: > On Mi, 02.05.18 21:13, Lennart Poettering (mz...@0pointer.de) wrote: > > > So yeah, Allison also suggested that having a single "XDG_PREFIX" env > > var would have been the much better option, rather than have > > individual

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

On Wed, May 02, 2018 at 09:52:44PM +0200, Lennart Poettering wrote: > Well, it's fine if people use different install prefixes. The question > though is if the xdg basedir spec really needs to care too much about > that. I mean, what matters really is that the XDG basedir spec defines > *search*

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

On Mi, 02.05.18 21:13, Lennart Poettering (mz...@0pointer.de) wrote: > So yeah, Allison also suggested that having a single "XDG_PREFIX" env > var would have been the much better option, rather than have > individual ones. Now, that ship sailed pretty much, but that's not > reason enough to go

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

On Wed, May 02, 2018 at 09:13:40PM +0200, Lennart Poettering wrote: > On Mi, 02.05.18 11:30, Josh Triplett (j...@joshtriplett.org) wrote: > > > On Wed, May 02, 2018 at 07:53:47PM +0200, Lennart Poettering wrote: > > > On Di, 29.08.17 18:42, Johannes Löthberg (johan...@kyriasis.com) wrote: > > >

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 Mi, 02.05.18 11:30, Josh Triplett (j...@joshtriplett.org) wrote: > On Wed, May 02, 2018 at 07:53:47PM +0200, Lennart Poettering wrote: > > On Di, 29.08.17 18:42, Johannes Löthberg (johan...@kyriasis.com) wrote: > > > > heya, > > > > > I've had some old patches around for the XDG basedir

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

On Wed, May 02, 2018 at 07:53:47PM +0200, Lennart Poettering wrote: > On Di, 29.08.17 18:42, Johannes Löthberg (johan...@kyriasis.com) wrote: > > heya, > > > I've had some old patches around for the XDG basedir spec, and figured I > > might as well finally send them in and see what people

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

On Di, 29.08.17 18:42, Johannes Löthberg (johan...@kyriasis.com) wrote: heya, > I've had some old patches around for the XDG basedir spec, and figured I > might as well finally send them in and see what people think. > > The first one just reformats some text and fixes some inconsistent >

freedesktop.org specifications list

I came across this page, linked from the homepage: https://www.freedesktop.org/wiki/Specifications/ There seem to be a number of discrepancies, if my understanding of various standards is correct: - The desktop notifications spec isn't mentioned at all. Gnome hosts a copy of it

Re: Consider adding license information to freedesktop.org wiki contents?

On Fri, 2018-04-13 at 11:40 +0100, Thomas Kluyver wrote: > On Fri, Apr 13, 2018, at 10:11 AM, Daniel Stone wrote: > > Sorry for the lack of reply, I've been quite busy lately. I also > > don't > > have a great answer for you. We cannot post-hoc enforce a licence > > on > > content: anything that

Re: Consider adding license information to freedesktop.org wiki contents?

On Fri, Apr 13, 2018, at 11:48 AM, Bastien Nocera wrote:> > This isn't how copyright works, sorry. Thanks, I was aware of this. No, it doesn't strictly adhere to 'how copyright works', but realistically, people who contribute to a freely available wiki about open source software are not going

Re: Consider adding license information to freedesktop.org wiki contents?

On Fri, Apr 13, 2018, at 10:11 AM, Daniel Stone wrote: > Sorry for the lack of reply, I've been quite busy lately. I also don't > have a great answer for you. We cannot post-hoc enforce a licence on > content: anything that is there is copyright to the actual author. We > can enforce a licence on

Re: Consider adding license information to freedesktop.org wiki contents?

On Fri, 2018-04-13 at 11:11 +0200, Daniel Stone wrote: > > > It would be great if anyone could help me get into contact with the > > original > > author of https://www.freedesktop.org/wiki/Specifications/file-mana > > ger-interface > > . Besides, I believe setting up a default license for > >

Re: Consider adding license information to freedesktop.org wiki contents?

Hi Boyuan, On 13 April 2018 at 03:03, Boyuan Yang <073p...@gmail.com> wrote: > Several weeks have passed and seems that there's no progress here; the mail > copy sent to original discussion participants got no replies and one of the > email address also bounces. Sorry for the lack of reply, I've

Re: Consider adding license information to freedesktop.org wiki contents?

On Fri, Apr 13, 2018, at 2:03 AM, Boyuan Yang wrote: > Several weeks have passed and seems that there's no progress here; the mail > copy sent to original discussion participants got no replies and one of the > email address also bounces. I get the impression that no-one really feels ownership

Re: Consider adding license information to freedesktop.org wiki contents?

Hello all, Several weeks have passed and seems that there's no progress here; the mail copy sent to original discussion participants got no replies and one of the email address also bounces. It would be great if anyone could help me get into contact with the original author of

mime info for z Machine game images

hi all > I play a lot of text adventure games of the z machine image format. To > avoid going into exhaustive detail, it's an old binary format from the > late eighties and early nineties made by a company called infocom. I've > created a frotz.xml file which has basic glob pattern support for

mime info for z Machine game images

> hi all > > I play a lot of text adventure games of the z machine image format. To > avoid going into exhaustive detail, it's an old binary format from the > late eighties and early nineties made by a company called infocom. I've > created a frotz.xml file which has basic glob pattern support

Re: Debian: Application not shown in section

I can confirm that, have seen such, too. Particularly with Midnight Commander not being shown. My wild guess is that there is some (undocumented?) setting "Show only graphical applications" or the like in Gnome or its derivatives. Seems some bug just looking at the mere presence of a Terminal=...

Debian: Application not shown in section

Dear xdg members, a Debian (stretch) user reported an issue where an application (freeplane) is not shown in the office section. So far I cannot reproduce this (GNOME3), but the user reported [1] that it is "fixed" by this change: --- /usr/share/applications/freeplane.desktop 2016-12-10

Unquoting rules in Desktop Entry spec need more examples

It's really hard to grasp the unquoting rules right. It would be easier for programmers to implement the spec if there was a list of examples that could be easily made into unittests on the target language. Like this: assert( unescape(`\\$`) == `\$` ) assert( unquote( unescape(`progname "\\$"`) )

Re: Consider adding license information to freedesktop.org wiki contents?

+1 to having a default license for the wiki contents. Code samples in a wiki are often meant to be copied and pasted, so it seems appropriate to license them permissively, like an MIT license, or even public domain. I don't feel strongly about the non-code content, but CC-BY would be an easy

Consider adding license information to freedesktop.org wiki contents?

Dear xdg list members, I think it might be a great idea if we could explicitly add license information for freedesktop.org wiki contents. I raised this question on #freedesktop@freenode before and heard from that current license is "undefined". To be more concrete, I would like to know the

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: DBus interface for meeting creation

On Tue, 2018-03-13 at 13:38 +, Corentin Noël wrote: > I wonder why is a D-Bus interface even required here. The simplest > solution (and already working one) is to just pass an ical file to the > calendar app with xdg-open. Yeah... that might work. In fact Milan implemented that for Evolution

Re: DBus interface for meeting creation

Le mardi 13 mars 2018 à 13:30 +, Simon McVittie a écrit : > 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.

Re: DBus interface for meeting creation

On Tue, 2018-03-13 at 13:11 +, David Woodhouse wrote: > As part of a conference protocol plugin for Pidgin (like the one for > Lync), we have the ability to create meetings. > > We need to spawn a "new meeting" editor in the client of the user's > choice, pre-populated with meeting dial-in

Re: DBus interface for meeting creation

I have a very limited knowledge in this field, but I would like to point out that in Thunderbird such task is performed by messages with attached ical files. So, why not to base meeting creation on opening ical (existing standard) data (as a file, for example)?

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

DBus interface for meeting creation

As part of a conference protocol plugin for Pidgin (like the one for Lync), we have the ability to create meetings. 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. I've implemented a

xdg-user-dirs – purpose?

Hello, I could not find within the documentation of xdg-user-dirs anything about the *purpose* of these directories. For some dirs, their purpose is obvious, for others not. DESKTOP *Some* file managers display this folder in the root window. Others, e.g. ROX, don’t.

Re: Xdg-user-dirs really upset...

Hi, it isn't reaching the code repo (I just added gnome-i18n to the CCs because in Damned Lies there's a link about the stuff of freedesktop.org ). So, as a direct consecuence, no software distribution can use it. Mikel just answered to me

Xdg-user-dirs really upset...

It passed a year, I highlight it A YEAR, since the publication of friulian translation on translation project for the xdg-user-dirs. On september 2017 the maintainer (Mikel Olasagasti) said he was waiting a gpg key from freedesktop. Well 2 months has passed, I tried to contact him again but no

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