Re: Proposal for an intent-apps spec

[Thomas Kluyver]

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 discussion about it on the issue you created 
here:

https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/54

> 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 (ideally I'd like to see a generic wrapper 
> that could work with most/all terminals by passing in options when 
> starting it).

I assume you would need wrappers, yes. You could write one wrapper for many 
terminal emulators, but if you have more than one installed, you recreate the 
same problem: how does the wrapper decide which one you want?

The neater solution with the proposed intent-apps spec would be for each 
terminal emulator to have its own D-Bus wrapper, so you can use intent-apps to 
choose between them. If it gets traction, I imagine that distros would ship 
these wrappers in their packages for different terminal emulators.

> And if the result is just launching a DBus interface, how is this 
> different than the existing DBus service mechanism (defining a service 
> in /dbus-1/services for  a specific interface)?

A service file points to one specific program which provides an interface. The 
Implements= key allows several applications to provide the same interface - 
saying 'this is *a* terminal' rather than 'this is *the* terminal' - and the 
proposed intent-apps spec is for picking a preferred one.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Proposal for an intent-apps spec

[Thomas Kluyver]

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
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Proposal for an intent-apps spec

[Thomas Kluyver]

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:
> > 
> > "A similar algorithm, apart from stopping at the first success, can be used
> > to list all available implementations of the intent."
> > 
> > I don't think it can, because, there's no reason to think that a given
> > implementation is listed in any intentapps.list file. 
> 
> Right. I should say:
> 
> "Similarly, those intentapps.list files, parsed in the same order, can also 
> be 
> used to sort all available implementations by preference."
> 
> How does that sound?

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 order of 
preference by reading all intentapps.list files in the order above. But these 
files cannot be used to find all implementations of an intent; the desktop 
files are the canonical source of that information."
 
> > It would be possible to build a cache like mimeinfo.cache, but that's a
> > separate concern from selecting the preferred application.
> 
> And that can be implementation-specific (in KDE we already have such a cache, 
> called ksycoca, and IIRC mimeinfo.cache is glib-specific). There are benefits 
> to sharing caches, but let's not make that a requirement at this point :-)

I think mimeinfo.cache is meant to be shared - it's created by a standalone 
update-desktop-database command which is maintained under xdg 
(desktop-file-utils repo). But I agree that there's no need to detail caching 
in the spec at this point.

Best wishes,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Proposal for an intent-apps spec

[Thomas Kluyver]

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.
> 
> Not sure what you mean. The only (DBus) interface that we expect to use for 
> this is org.freedesktop.Terminal1. Maybe you meant "implementation" rather 
> than "interface"? In that case I agree, see below.

I did mean 'interface' :-) . I was just trying to say that the launcher 
(/desktop) wouldn't have a hardcoded default for every interface it has to 
handle. That's probably self-evident, and your edit resolves this concern.

> > - Pick the default in a simple, consistent manner (e.g. first desktop file
> > sorted by name), and make it obvious how the user should set their
> > preference if they don't like it.
> > - Pick an arbitrary default, and then
> > write it as the preference in XDG_CONFIG_HOME, so the same application will
> > be used until the user picks another one (or uninstalls that one).
> 
> Or Eli's suggestion of a GUI to ask the user.
> 
> In my opinion, all three possibilities make sense, but should only be 
> recommendations for an implementation specific behaviour. We don't need to 
> actually specify this part.

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 give a consistent result, e.g. it should not 
depend on the order of an unsorted list of files from a directory."

I'm not sure about the last sentence you've now added:

"A similar algorithm, apart from stopping at the first success, can be used to 
list all available implementations of the intent."

I don't think it can, because, there's no reason to think that a given 
implementation is listed in any intentapps.list file. As things stand, to find 
all implementations, you would have to scan all desktop files. It would be 
possible to build a cache like mimeinfo.cache, but that's a separate concern 
from selecting the preferred application.

Best wishes,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Thomas Kluyver]

On Mon, 3 May 2021, at 20:36, Eli Schwartz wrote:
> Once all levels have been checked, if no entry could be found, the
> implementations MUST query the user to pick one of the .desktop files
> associated with the mimetype, taking into account added and removed
> associations as per the next section. Optionally, the implementation may
> and probably should then default to saving this to "user overrides
> (recommended location for user configuration GUIs)".

I don't think there's really any point writing MUST. The spec can recommend 
things, but no-one can force desktops to follow it if they don't think that 
behaviour provides the best experience. There's certainly a case for prompting 
the user to decide, but the place to make that case first is to the desktops 
which could actually implement it (assuming most users don't reach the generic 
fallback in xdg-open).

> In the xdg-open program, update open_generic() to comply with the new
> version of the mime apps spec, by e.g. spawning a zenity selection
> dialog. If zenity is not installed, a CLI dialog could be printed...

I suspect that adding pop-up dialogs to something that didn't previously use 
them is going to cause some issues. It also means that you would need another 
level of detection & fallback (zenity/kdialog, terminal prompts) inside what's 
already a fallback. And you probably still want an ultimate fallback where none 
of the GUI dialog tools are available and it's not running in a tty.

> This change may very well obsolete much of the micro industry that has
> grown up around xdg-open, where the sole purpose of a program is to
> provide an alternative xdg-open that does not respect the xdg mimeapps
> spec, but uses custom rules (generally a mix of regex and desktop entry
> hints) and prompts the user on ambiguity, because their authors are
> positive that xdg-open is the literal devil and will never open the
> right thing ever.

I may be wrong, but I'd guess that the mystery of xdg-open is more because it's 
a wrapper around a bunch of different desktop-specific tools with their own 
peculiarities. xdg-open could be effectively a different tool on my machine and 
yours, even if we have the same xdg-utils package from the same distro. Maybe 
it would have been better to implement xdg-open as a standalone tool rather 
than a wrapper around desktop tools, but I imagine that ship has long since 
sailed.

(And of course, there's nothing particularly wrong with people using other 
launcher tools if they want to - though I agree it's worth thinking about 
whether that points to problems with the default mechanisms.)

Thomas___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Thomas Kluyver]

On Mon, 3 May 2021, at 10:58, David Faure wrote:
> I'd like to understand why 
> https://specifications.freedesktop.org/mime-apps-spec/latest/
> doesn't solve the issue. If the distro's mimeapps.lst says
> image/jpeg=gwenview.desktop;gimp.desktop;
> then JPEG files will be opened in gwenview (if installed) rather than in GIMP,

I think this is all about the case where no mimeapps.list gives any preferred 
application for the mimetype - how should the launcher choose a default default 
application.

Of course, one answer is to say that part of the distro's role is defining 
default preferences in a mimeapps.lst so this doesn't come up, but there will 
always be cases it doesn't cover.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Proposal for an intent-apps spec

[Thomas Kluyver]

There was a discussion recently about how a default application for a mime-type 
was chosen when no mimeapps.lst specified a preference - some launchers were 
giving semi-random results that changed unexpectedly.

As you said, the new spec closely follows mime-apps. I think it would be a good 
idea to head off similar issues in the future by giving a bit more detail in 
the recommendation for what to do when no preference is found. This is the 
relevant bullet point at present:

"if after all files are handled, we have not yet found a default application, 
select the most-preferred application (according to associations) that supports 
the intent"

But what makes an application most-preferred, apart from this spec? AFAIK, 
there is no other way to decide this in general. 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.

I can see two possible recommendations that make sense:

- Pick the default in a simple, consistent manner (e.g. first desktop file 
sorted by name), and make it obvious how the user should set their preference 
if they don't like it.
- Pick an arbitrary default, and then write it as the preference in 
XDG_CONFIG_HOME, so the same application will be used until the user picks 
another one (or uninstalls that one).

It might also be worth saying that the spec doesn't rule out using Implements= 
for cases where there's no default application - where you're interested in all 
the applications implementing an interface, rather than just one. I don't think 
anything in the new spec is a problem for that, but it might be good to make 
that explicit.

Other than that, I think it looks like a nice addition. :-)

Thomas

On Mon, 3 May 2021, at 10:44, David Faure wrote:
> Hello everyone,
> 
> I just created
> https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/45
> with the proposal for an intent-apps spec, modeled after the mime-apps spec
> (but without the concept of adding/removing associations).
> 
> For context:
> 
> * The desktop entry spec mentions Implement= already for some 
> time, but AFAIK this isn't used anywhere yet?
> 
> * What's missing is a way to let the user (or the sysadmin or the distro) 
> decide which alternative to prefer (possibly depending on the desktop 
> environment). mimeapps does this nicely for mimetypes, so intentapps just 
> reuses that solution, but outside the world of mimetypes
> 
> * This came up in https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/54
> where we're discussing "Have a standard way for users to specify which 
> terminal should open .desktop applications with Terminal=true".
> The solution involves implementing a DBus interface (dubbed 
> org.freedesktop.Terminal1). This is similar to the existing 
> org.freedesktop.FileManager1 DBus interface. All applications implementing 
> org.freedesktop.Terminal1 will specify
> Implements=org.freedesktop.Terminal1 in their desktop file, and intent-
> apps.lst files can then be used to pick the preferred one.
> 
> I am willing to implement this on the KDE side, I'm especially interested in 
> feedback from whoever feels like implementing this in glib and other 
> implementations.
> 
> -- 
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
> 
> 
> 
> ___
> xdg mailing list
> xdg@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
> 
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Thomas Kluyver]

On Mon, 22 Feb 2021, at 13:21, Mark Watts wrote:
> If I
> understand correctly, based on the excerpt of the desktop entry spec
> below, there's no prohibition on adding entries outside of those
> explicitly listed in the standard, so we're good there.

The spec says that additional non-standard fields should be prefixed with 
something like X-Gnome- , although it doesn't appear to be mandatory:

https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s12.html

I agree that it's probably a good idea to get a desktop interested in the idea 
before focusing on the specification. If you can get a desktop to implement it 
even as a non-standard field, I imagine it would be quite easy to get 
applications to use it.

Thomas

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

Re: New `MimeType` fields in .desktop

[Thomas Kluyver]

On Wed, 17 Feb 2021, at 22:46, Bastien Nocera wrote:
> I split it off anyway so that I could stop maintaining the shared-mime-
> info package and not have anyone who might come in's decisions about
> what the best default image viewer is impact GNOME. Here's the GNOME
> configuration:
> https://src.fedoraproject.org/rpms/gnome-desktop3/blob/rawhide/f/gnome-mimeapps.list

Aha, thanks. :-) Interestingly, on my (F33 workstation) system, 
/usr/share/applications/mimeapps.list and gnome-mimeapps.list are identical. 
Maybe this is some relic after upgrading through several versions. :-/

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Thomas Kluyver]

On Wed, 17 Feb 2021, at 18:22, Jehan Pagès wrote:
> I do agree it's not so much to start with. Anyway here is the recent report: 
> https://gitlab.gnome.org/GNOME/gimp/-/issues/6449 

Thanks!

This particular user reports that *updating* GIMP causes the file association 
to change. That definitely seems like a bug: I can understand that someone 
might want a newly installed app to take over from the previous default, but 
updating shouldn't affect it.

Reading the EndeavourOS thread about it, I think what's happening is that, with 
no default application set, something takes the first application listed in a 
mimeinfo.cache file as the default. It seems like an obvious thing to do. But 
the man page for update-desktop-database (which generates that file) is clear 
that you shouldn't:

> The  order  of  the  desktop  files  found for a MIME type is not 
> significant. Therefore, an external mechanism must be used to determine what  
> is  the  preferred desktop file for a MIME type.

The order of applications in that file is not even currently stable 
(https://gitlab.freedesktop.org/xdg/desktop-file-utils/-/issues/3), so each 
time it's regenerated you could get a different application. But simply sorting 
them would probably put gimp before gwenview, so it wouldn't have the result 
that user wants.

One way to address this is to ship a list of default apps - e.g. Fedora 
associates image/jpeg with Eye of Gnome by default. Fedora appears to set this 
regardless of desktop, but the mime-apps spec 
(https://specifications.freedesktop.org/mime-apps-spec/1.0.1/ ) allows for both 
desktop specific defaults and a sequence of defaults from which it will use the 
first available.

The desktop could (should?) also make a deterministic choice even without a 
default (e.g. sort the desktop files from mimeinfo.cache itself). It might be 
the wrong choice, of course, but a consistent wrong choice and a clear way to 
override it is less frustrating than something that might or might not go wrong 
every time you update it.

Best wishes,
Thomas___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Thomas Kluyver]

On Wed, 17 Feb 2021, at 16:42, Jehan Pagès wrote:
> Yes! Finally someone who reads emails before answering. :-)

I'll just note that this isn't a particularly useful tone in a discussion that 
already feels heated. I actually haven't read your emails particularly closely, 
I just think I've happened to pick up your general idea. ;-)

> It's an interesting idea, but wouldn't it be very hard to tell? Like if 
> someone asked me how much of PSD is supported on GIMP (on a scale, say from 0 
> to 10), I would have no idea where we stand. We do have support, and we try 
> to improve it regularly. We also accept patches with arms wide open. But how 
> much of it is supported? No idea.

I'm not suggesting it would represent exactly how well a format is supported. 
You'd map rough semantic guidelines onto numbers (e.g. 100=designed for this 
file format, 30=can import but not save, 10=can extract partial information). 
Strict categories always get awkward, putting them on a scale allows you to be 
a bit fuzzy about it.

But we're getting ahead of ourselves. Let's discuss problems before solutions.

> Yeah the default application on same level of intent is a difficult question, 
> which was why I was not really focusing on it. I'm not sure but it doesn't 
> look like all distributions/desktop do the same thing currently. It would 
> seem that some at least would just set the last installed software as 
> default. This is definitely wrong often, but I can see also how it can make 
> sense to some. I don't actually think there is a single right answer to this 
> problem unfortunately.

Do you have any idea which distro/desktop prefers the last installed 
application? Maybe a better starting point is to work out what (if anything) 
does that, and if it's intentional.

I think the problem needs to be pinned down more precisely before we can 
consider any solution. You've presented some mysterious GIMP users. What 
desktops were they using? What distros? Were they new to desktop Linux, or old 
hands with established preferences? How often does this come up, and is it 
increasing or decreasing?

Changing a specification and getting everyone involved to adopt the changes is 
a long, difficult process. If there's any chance the problem can be solved (or 
sufficiently mitigated) by changing software without changing the desktop file 
spec, it's worth trying that first.

Best wishes,
Thomas___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Thomas Kluyver]

On Wed, 17 Feb 2021, at 15:06, Bollinger, John C wrote:
> Ok, on re-reading I can see that, but it is even less the GIMP's role to say 
> "you should prefer other applications for opening JPEGs" than it is to say 
> "you should prefer me for opening XCFs".  Desktop files still are not the 
> right place to express policy.

I can see what you're saying, but I don't think it's ridiculous to suggest that 
a desktop file could encode some indication of how well an application handles 
a particular file type. You could think of this as describing 'can open' vs 
'can import'. A few more examples from my laptop of technically possible 
matches that you probably wouldn't want to be used by default:
 * Libreoffice Writer & text/plain
 * Libreoffice Draw & application/pdf
 * Pinta (bitmap graphics editor) & image/svg
 * File roller (archive manager) & application/x-chrome-extension
In my experience, things like this haven't really come up, so I'm inclined to 
agree with you that it doesn't warrant changing the standard. But I think it's 
better to understand what's specifically going wrong and work out how else it 
can be improved, rather than insisting that this could never be part of a 
desktop file. Labelling options with some kind of priority is compromise we 
live with in various places.

Thomas___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Thomas Kluyver]

On Tue, 16 Feb 2021, at 23:04, Bollinger, John C wrote:
> But that does not imply that some applications should be able to claim to be 
> more equal than others with respect to particular file types.

I think Jehan's idea is that applications should be able to claim to be *less* 
equal than others for a given mimetype, i.e. that GIMP could declare 'I can 
open JPEGs, but you should probably use something else by default'. Obviously, 
if the user explicitly set GIMP as the default handler for image/jpeg, it would 
override this priority.

Distinguishing things like 'native' and 'equivalent intent' filetypes seems 
tempting, but I suspect it would end up with a lot of awkward grey areas. If 
this is a problem worth solving, I'd be more inclined to make a numeric 
priority scale, something like the shared-mime-info database uses for assigning 
mimetypes to files (which allows e.g. ODT files to be recognised as ODT rather 
than general zip files).

Another approach to the stability issue (e.g. GIMP 'taking over' the JPEG 
mimetype) is for the desktop to fix it: if you open a JPEG file and there isn't 
already a default application for that, store whatever it uses as the default 
application, so it won't change unless the user manually changes the 
association or uninstalls that application. I think that could be done without 
changing any specs.

Thomas___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: RFC: deprecating crypto usage in secret-service

[Thomas Kluyver]

It's not clear to me that using file descriptors fulfils the same goal as the 
encryption mechanism. The secret service spec [1] suggests that the goal is for 
swappable memory to contain encrypted (rather than plaintext) secrets. Passing 
the secret over a separate channel wouldn't seem to do that - though I guess 
there would be one fewer copy of the data, as the bus daemon doesn't see it.

Approaching it from another angle, what threat would this protect against which 
could otherwise steal data from D-Bus over unix sockets? I think it would have 
to be something which can listen to another connection but not connect itself, 
but I don't know of a scenario where that's possible.

Passing file descriptors is only possible over Unix sockets, as far as I know, 
so it wouldn't be usable on Windows, though I don't know how big a concern that 
is.

Thomas

[1] https://specifications.freedesktop.org/secret-service/latest/ch07.html

On Sun, 23 Aug 2020, at 18:46, Daiki Ueno wrote:
> Hello,
> 
> Currently, the secret-service protocol suggests two mechanisms
> ("algorithms" in the specification) to transfer secrets: "plain" and
> "dh-ietf1024-sha256-aes128-cbc-pkcs7".
> 
> The former sends secret data in plaintext, while the latter transmits
> the data in an encrypted form, using a mechanism similar to to TLS.
> Although this works well so far and the algorithm choice is ok-ish, the
> custom encryption protocol requires low-level crypto primitives and the
> used crypto algorithm, the 1024-bit 'Second Oakley Group', is being
> deprecated[1].
> 
> At the D-Bus level, there is more secure mechanism to transfer sensitive
> data without imposing crypto: file descriptor passing.  I suggest
> replacing the existing mechanism with it at least on the platforms where
> file descriptor passing is available.
> 
> I have submitted a draft MR:
> https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/33
> 
> Is there any concerns / suggestions on this?
> 
> Regards,
> 
> Footnotes:
> [1]  https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
> 
> ___
> xdg mailing list
> xdg@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
>
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: improve PRIMARY buffer copy-paste behaviour, paste over

[Thomas Kluyver]

On Fri, Mar 6, 2020, at 11:26 AM, Johannes Thrän wrote:
> I'd like the middle mouse click to also be able to do that, i.e:
> 
> 1. select text (not drag)
> 
> 2. in another window select some other text, hold click
> 
> 2a, middle mouse click.
> 
> ... release.

I think that's what I was trying to describe as well - it seems the terminology 
is a bit tricky. ;-) I understand 'drag' as 'moving the mouse while holding a 
mouse button down', which could be used to make a selection or to drag & drop.

One thing that might get broken: creating a selection with the keyboard (shift 
+ arrow keys) and then middle clicking to paste it somewhere else. When you 
select with the keyboard, there's no mouse up event, and no other obvious event 
to mean a selection is 'finished'. Maybe this is an unusual pattern, but I bet 
there are some people who do it.

Maybe the answer to that is just to say that PRIMARY is updated when either the 
mouse button is released, or the selection is changed with the keyboard.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: improve PRIMARY buffer copy-paste behaviour, paste over

[Thomas Kluyver]

On Fri, Mar 6, 2020, at 1:43 AM, Thiago Macieira wrote:
> You mean middle click while the left button is still held down? That 
> effectively means dragging the text from source to destination.

If I've understood Johannes correctly, what he's proposing is slightly 
different from drag & drop:

1. Click & hold, drag to select source text, release (setting PRIMARY buffer)
2. Click & hold, drag to select text to be replaced, middle click (paste from 
PRIMARY), release

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Cleaning of $XDG_CACHE_HOME and $XDG_CACHE_HOME/thumbnails

[Thomas Kluyver]

On Wed, Feb 26, 2020, at 1:30 PM, Benjamin Berg wrote:
> I am *not* proposing to nuke these directories. I am proposing to nuke
> them by default, and ask applications like evolution, jhbuild and
> others to ship their own configuration.

I suspect that the practical upshot of this would be that ~all applications 
using XDG_CACHE_HOME get bug reports at some time in the next couple of years, 
waste some time working out what's going on, grumble about it, and then write 
whatever configuration disables this behaviour to revert to the way things were 
before (and presumably, the way they are on other platforms).

XDG_RUNTIME_DIR is specified to have periodic cleanup unless files have the 
sticky bit set, although this is on a scale of hours rather than days. As an 
application author, this was a source of bugs until we eventually gave up using 
the directory entirely.

> And I do see a huge advantage in requiring applications to specify the 
> clean-up behaviour they need or want.

Why not take that as the starting point? Provide a way for apps to indicate to 
the system when it makes sense to clean up their cache files, but don't punish 
those that don't know about it by randomly deleting their cache.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Reclassify Icon= in .desktop files as string, not localestring

[Thomas Kluyver]

I'd agree with Will: keep things simple unless there's real pressure from 
people who want to use localised icons, not just hypothetical cases. 

Best wishes,
Thomas

On Tue, Jun 25, 2019, at 3:23 PM, Bollinger, John C wrote:
> Hi,

> 

> The problem seems to be that Icon is unique among the currently-defined keys 
> in that it identifies a _machine-actionable_ datum that may conceivably want 
> / need to differ between locales. It should not be translated because it’s 
> not intended for human readers, but it should be customizable on a per-locale 
> basis. For example, it would probably be appropriate for a “fix it” icon 
> depicted in Western European locales as a red cross to be depicted in middle 
> eastern locales as a red crescent.

> 

> Whereas I concur that such cases are at best rare in practice, I suggest that 
> if a change is to be made at all then the alternative of creating a new value 
> type should at least be considered. That would permit the 
> locale-customizability to be retained while clarifying the intended use and 
> distinguishing such items from those that should routinely be translated.

> 

> 

> Regards,

> 

> John

> 

> 

> *From:* xdg [mailto:xdg-boun...@lists.freedesktop.org] *On Behalf Of *Will 
> Thompson
> *Sent:* Monday, June 24, 2019 5:06 PM
> *To:* xdg@lists.freedesktop.org
> *Subject:* Reclassify Icon= in .desktop files as string, not localestring

> 

> *Caution: External Sender*

> 

> Hi,

> 

> Currently, Icon= and similar fields in .desktop files are defined to be 
> "localestring", and are extracted for translation by tools like xgettext. I 
> propose to redefine them to "string" 
> https://gitlab.freedesktop.org/xdg/xdg-specs/merge_requests/2 
> 
>  and stop xgettext extracting them. 
> https://savannah.gnu.org/bugs/index.php?56543 
> 

> 

> I did some cursory archaeology and the only discussion I can find around 
> icons being translatable is this message 
> https://lists.freedesktop.org/archives/xdg/2005-June/005364.html 
> 
>  and its descendents. The argument given there is:

> 

>> I think Icon is intentionally a localestring - you might imagine an icon 
>> having some text or a cultural reference. I don't think it would be a good 
>> idea to have an icon like that and I haven't seen a localized Icon key in 
>> practice but ...

> 

> I agree with everything here – technically, it's correct to make them 
> localizable, even if I have never noticed a localised icon. (That said, 
> English is my first and only language, and I live in the UK…)

> 

> On the other hand, I have seen translators trying hard to translate icon 
> names, which are often strange collections of kebab-case-words or 
> com.example.reverse_domain.Words. I've seen many comments of the form "# 
> TRANSLATORS: please do not translate this".

> 

> Is there widespread use of localized icons that I'm not aware of? If so, 
> perhaps the right path is to add a flag to xgettext to opt in (or opt out) of 
> this behaviour; this might not be an easy sell since the specification is 
> clear that these are localestrings. If not, could we consider this a case 
> where the practical cost (in the form of wasted work for translators) 
> outweighs the conceptual upside, and change the spec (and implementation)?

> 

> Thanks,

> 

> – Will

> 
> 
> Email Disclaimer: www.stjude.org/emaildisclaimer
>  Consultation Disclaimer: www.stjude.org/consultationdisclaimer
> ___
> xdg mailing list
> xdg@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: xdg-basedir for secrets

[Thomas Kluyver]

On Fri, Jun 7, 2019, at 8:48 PM, Jonas DOREL wrote:
> To me, secrets are fundamentally different from data (even confidential
> data) because they serve as a mean to authenticate you or authorize your
> utilisation of some services.
> 
> I guess the question is: should there be a dedicated folder for secrets
> or should they just be in XDG_DATA_HOME and manage differently by the
> applications (through your configuration) ?

What would be functionally different if they were in a separate directory? What 
would be the practical advantage to using the hypothetical 'secret' directory 
rather than 'data'? What's the value in having different applications store 
their secrets in the same place? Hackers know which folder to steal first? ;-)

You started the thread with a mention of backups. I guess you want to exclude 
secrets from backups? Does it make a difference whether they're encrypted or 
not? Does it matter how strong the encryption mechanism or the key are? How 
useful would it be to specify a 'secrets' directory when there's no way to 
enforce the spec, so you can't assume it's the only place secrets are stored?

I don't think it's very useful to decide that things seem "fundamentally 
different". There are thousands of different kinds of data, and we could spend 
our entire lives arguing about what semantic categories they should go into. 
Focus on the practical impacts.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: A path to xdg-utils2 in python

[Thomas Kluyver]

Hi Simon,

On Thu, Feb 28, 2019, at 12:08 AM, Simon Lees wrote:
> Where ever possible i'm currently planning to use as much of the 
> existing pyxdg libraries especially for handling all the mime / .desktop 
> file handling.

As the not very active maintainer of PyXDG: much of the package is written in 
ways I would avoid for new code - e.g. it has its own ini file parsing instead 
of using the standard library configparser module. I'm wary of changing it 
because it's been around for a long time and people could be relying on all 
kinds of implementation details. But I wouldn't necessarily encourage you to 
use it for new code.

If there's useful functionality in there, by all means make use of it. But you 
might be better off extracting and refactoring any code you want, either as 
internal modules for xdg-utils2 or as separately packaged parts. I can probably 
find some time to help with this if you like.

When I first read your email,  I thought about a parallel 'pyxdg2' project to 
produce a modern version of that code without compatibility constraints. But on 
further thought, I don't think it necessarily makes sense to bundle together 
the different functionality that's in PyXDG. Historically, the limitations of 
the Python packaging tools pushed us towards fewer, bigger packages 
incorporating disparate functionality, and PyXDG is exactly that. Now the tools 
have improved, it's more practical to have more focused packages - e.g. maybe 
desktop file handling could be its own package.

Best wishes,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: License recommendation for specs

[Thomas Kluyver]

Hi Egmont,

I don't think it's important to use licensing to prevent incompatible
versions of the specification. Compatibility is important, but it's
ensured by having a single place which everyone agrees is the canonical
version of the specification. Many specifications are also usefully
amended and updated in later versions, to clarify details or add extra
capabilities - this could be harder if the license forbids modifications
and the original author is no longer actively involved.
If there's any doubt on whether an implementation is a derivative work
of the specification, I think it would be best to add a note that
implementations are not meant to be bound by license conditions on the
specification. But I'd favour using a simple permissive license for the
specification in the first place.
Best wishes,
Thomas


On Wed, Jan 2, 2019, at 1:02 PM, Egmont Koblinger wrote:
> Hello,
> 
> I'm new on this list. I've been working on a specification for a few
> months that will kindly be hosted on FDO.> 
> Pretty much the only remaining step is to pick a license for my work.> 
> I've seen some relevant discussions on this mailing list between March-
> May 2018. What I haven't seen, though, is some evaluation of the
> potential licenses and guidelines to pick one, nor the final choices
> you went for.> 
> I tried to read and interpret some of the popular licenses. The lack
> of good web search matches, and in particular [1] and [2] suggest to
> me that there isn't any designed or well suited for specifications.> 
> My first big dilemma: I'm wondering what does "free" mean in the
> context of specifications, and what does FDO want it to mean on its
> site and in its overall vision.> 
> My instincts tell me that a "free specification" should be one that
> everybody is free to implement, without imposing restrictions on the
> implementation. That is: okay to implement in a closed source
> commercial application. As per [1], it's unclear whether an
> implementation of a specification counts as "derived work" or not, and
> thus whether CC BY-SA allows this.> 
> Debian's guideline of being "free" instead seems to focus on the
> modification and distribution of the material in question instead.
> E.g. they only consider GFDL free if it doesn't have an invariant
> section. For a piece of software or documentation, Debian's is a
> reasonable approach. For specifications I don't think so. And this
> leads to my second big dilemma.> 
> For specifications, even for "free" ones, I think it's outright
> undesirable to create and distribute modified work. In order to avoid
> incompatible specifications competing against each other, resulting in
> quite a mess and poor interoperability between implementations,
> contributors should be pushed to improve the original specification
> whenever feasible (e.g. the project is maintained actively), or
> perhaps come up with extensions as separate new projects that
> potentially refer to the original one, but should not create forks and
> slightly altered variants (especially in backwards incompatible ways)
> of the original.> 
> Not sure if this restriction belongs to the license, though, or should
> sort itself out by other means, e.g. by the original work having some
> "respect" and the community refusing to go with forks.> 
> Also note that even if the license chosen for a specification
> disallows the creation of modified work, it should probably still be
> allowed if done with the explicit intent of sending suggested
> modifications back to mainstream. (If I understand correctly, CC BY-ND
> doesn't allow the creation of publicly visible merge request?)> 
> I would not like to release my work to the public domain / CC0 or so.
> Ideally I wouldn't want others to distribute my work (the
> specification itself, or parts of it) commercially, so I'm not keen on
> CC BY either. And, since I'm not a laywer, I wouldn't want to come up
> with something custom.> 
> Something that occurred to me as a little bit of custom, though, is CC
> BY-SA clarifying that implementing in commercial apps is okay. Since
> I'm not confident enough to amend the CC license by a sentence,
> technically I'm thinking of addressing it by dual-licensing my work
> under CC BY-SA and a self-written sentence along the lines of "okay to
> implement anywhere, all other rights reserved". Users would need to
> pick one of these two, contributors would need accept this OR-
> combination of them. This is the approach I like the most so far, but
> I'm not sure if it makes sense to you guys too, or if maybe you see a
> red flag.> 
> Or, what happens if I just release without any licensing? What are the
> downsides of that approach? Why is it important or encouraged to have
> a license? Aren't the "legal defaults" of any published work without a
> license good enough, and perhaps closer to what I imagine than any of
> these existing license texts? Note that most of the standards I used
> during my work, e.g. ECMA ones, come 

Re: Ideas

[Thomas Kluyver]

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 these would currently go in XDG_DATA_HOME, which is ~/.local/share by 
default. Here's the relevant spec:

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

> If that is do every software know where find data, people can choose
> their software, data can be sync with server *dav.

XDG has no power to make applications use standard locations or data formats 
for these things. So new standards for all these categories would probably be 
ignored.

If you want to get e.g. calendar data in a shared location and format, you'd 
need to convince the developers of calendar applications that that's worth 
doing. One way to do that would be to make some useful new piece of software 
which can do something with calendar data stored in the right place.

Once there are multiple projects trying to share data, then someone could look 
at writing down a specification describing what files go where so that more 
projects can join in.

Best wishes,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

XDG_RUNTIME_DIR: Periodic clean-up

[Thomas Kluyver]

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 disconnects. 
Today my issue is with periodic cleanup. Here's what the spec says:

> Files in this directory MAY be subjected to periodic clean-up. To ensure that 
> your files are not removed, they should have their access time timestamp 
> modified at least once every 6 hours of monotonic time or the 'sticky' bit 
> should be set on the file. 

This is awkward for application developers firstly because it's so easy to 
overlook: either you've discovered XDG_RUNTIME_DIR without reading the spec, or 
you saw the note in the spec but skipped it 'for the time being' because it's 
rare to need the files 6 hours later. Of course, 'for the time being' can 
easily mean 'until someone has filed a strange bug and we've figured out what's 
caused it'.

If you have got to the point of knowing & caring about it, it's still 
frustrating, because:

- How do you test for this? Our automated tests can't wait 6 hours. It's a pain 
even for a one off manual test.
- Does my system do the periodic cleanup? It's not required - maybe my setup 
doesn't do it, or does it only after 24 hours, or only when a certain amount of 
space is used.
- How do I even find out? Is it Gnome that would do it? Systemd? Pam? A 
separate service? I'm sure this is obvious to someone better versed in the 
components of a modern Linux system, but it's not obvious to me, and I'd wager 
that there are plenty of other people who wouldn't know.
- How does the access time/sticky bit check work if I make a subdirectory? Does 
it only apply to the first level under XDG_RUNTIME_DIR, or only to leaf files, 
or to every file and directory working recursively?
- If I try to set the sticky bit and a file is deleted anyway, how do I check 
whether it was my code that failed or whatever system component is doing the 
cleanup? I can't retrospectively check the sticky bit, because the file is gone!

Finally, if you do find something that works to protect you from the cleanup, 
you'll probably cargo cult it for every file you create in XDG_RUNTIME_DIR. 
That's certainly what I'd do. So there will gradually be more and more files 
that aren't being cleaned up, defeating the point of cleanups.

This cleanup feels like an awkward mechanism that pushes a lot of unnecessary 
work onto application developers - or leaves us with rare but real bugs if we 
ignore it. I guess the intent is to reclaim unused space, since the directory 
can be purely in RAM? But 6 hours is plenty of time for a misbehaving 
application to fill up RAM, even if it hasn't protected its files from cleanup.

Ideally, I'd like to see periodic cleanup phased out, to make the default 
behaviour less surprising. Maybe there could be a way to opt *in* to periodic 
cleanup instead of opting out? But if that's not possible, I'd like to at least 
clarify how the protection rules work with subdirectories, and maybe have some 
official XDG tooling to facilitate testing this.

Thanks,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: some issues with mime types

[Thomas Kluyver]

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 images, even windows software. I'm not sure
> what can be done about this, it seems impossible to automagically detect
> everything possiblt that uses a .bin extension. Maybe increase the magic
> priority on sega rom types?

Looking at the shared-mime-info xml file on my computer, there are three mime 
types with a '*.bin' glob pattern:

- application/x-sega-cd-rom (with magic string SEGADISCSYSTEM)
- application/x-saturn-rom (with magic string SEGA SEGASATURN)
- application/octet-stream (no magic)

The last is the generic 'unknown binary' type, so is what it should be using 
for .bin files unless they're one of the more specific types.

If the tool you're using looks at the file contents to check magic strings, I 
think it's a bug in that tool if it identifies arbitrary .bin files as Sega CD 
images. Those files should fail the magic checks for both SEGA file types and 
fall back to the generic one.

Unfortunately, if it's just going by filename, there's no way for it to 
reliably get the right type. Making the octet-stream glob higher priority would 
make it find that. But in that case, tools that follow the recommended steps 
would never detect the Sega formats, even if they were prepared to do magic 
sniffing, because if one glob match has higher priority, the recommended steps 
skip magic sniffing.
https://specifications.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html#idm140625828606432

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Updating which specs have "pretty good" adoption

[Thomas Kluyver]

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 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 
> > accepted, and could be upgraded to "pretty good adoption". In particular, 
> > these specs describe files which are on my (Fedora+Gnome) system, and I'm 
> > pretty sure I've been seeing some of the files around for several years:
> > 
> > - Icon naming: 
> > https://specifications.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
> Enlightenment is following the FDO specs here where possible I believe
> > - MIME application associations: 
> > https://specifications.freedesktop.org/mime-apps-spec/latest/
> Yes but only for stuff in the users home directory
> > - Sound themes: http://0pointer.de/public/sound-theme-spec.html
> No: Enlightenment (efl) ships its themes as single compressed binaries,
> all sounds are included as part of these themes
> > - Help: 
> > https://wiki.freedesktop.org/www/Specifications/help-spec/help-system-spec.xml
> No: But mostly because enlightenment doesn't have a built in way of
> viewing help files, its help files go into the standard directory set by
> autotools
> > - Thumbnails: 
> > https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html
> No
> > 
> > Can anyone confirm which other desktops do or don't use each of those 
> > specifications? And if you know, what version of the desktop added support 
> > for them?
> > 
> > I'm hoping to find that all major desktops have supported these specs for a 
> > long time, which makes life easy. If that's not the case, we can figure out 
> > what counts as "pretty good" adoption.
> > 
> > Thanks,
> > Thomas
> 
> -- 
> 
> Simon Lees (Simotek)http://simotek.net
> 
> Emergency Update Team   keybase.io/simotek
> SUSE Linux   Adelaide Australia, UTC+10:30
> GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
> 
> ___
> xdg mailing list
> xdg@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Updating which specs have "pretty good" adoption

[Thomas Kluyver]

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 my (Fedora+Gnome) system, and I'm pretty sure 
I've been seeing some of the files around for several years:

- Icon naming: 
https://specifications.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
- MIME application associations: 
https://specifications.freedesktop.org/mime-apps-spec/latest/
- Sound themes: http://0pointer.de/public/sound-theme-spec.html
- Help: 
https://wiki.freedesktop.org/www/Specifications/help-spec/help-system-spec.xml
- Thumbnails: 
https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html

Can anyone confirm which other desktops do or don't use each of those 
specifications? And if you know, what version of the desktop added support for 
them?

I'm hoping to find that all major desktops have supported these specs for a 
long time, which makes life easy. If that's not the case, we can figure out 
what counts as "pretty good" adoption.

Thanks,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: XDG_RUNTIME_DIR: When is a user logged out?

[Thomas Kluyver]

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 (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 generally something only privileged code can
> register, hence, no not really...
> 
> Lennart
> 
> -- 
> Lennart Poettering, Red Hat
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: XDG_RUNTIME_DIR: When is a user logged out?

[Thomas Kluyver]

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, 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 X, that meant user X was still logged 
> > in, and the application could rely on XDG_RUNTIME_DIR continuing to exist. 
> > However, some users have reported that if they run a process in 
> > nohup/screen and then disconnect, their XDG_RUNTIME_DIR is deleted because 
> > they have logged out. It looks like other people have had similar issues:
> > 
> > https://github.com/projectatomic/libpod/issues/659
> > https://unix.stackexchange.com/questions/386504/how-do-you-keep-systemd-user-services-alive-over-mosh
> > 
> > I tested this on a Debian system and I couldn't reproduce the problem: 
> > XDG_RUNTIME_DIR continued to exist when I disconnected and left a script 
> > running in nohup. But I don't know what to tell users who are experiencing 
> > this issue.
> > 
> > 1. When should the user count as logged out? Is my assumption that
> > the user is logged in while any process is running with their UID
> > reasonable? Can we clarify this in the spec?
> 
> I wrote the part of the spec initially, but I left this intentionally
> vague, to give impementors a bit of freedom to define their session
> lifetimes.
> 
> That said, on systemd systems the definition of "being logged in" is
> generally bound to "there's at least one PAM session around" for the
> user. And that is usually bound to "is there an utmp entry for the
> user"...
> 
> And by that definition just having a process with the user's UID
> around is *not* sufficient to keep the XDG_RUNTIME_DIR around.
> 
> Lennart
> 
> -- 
> Lennart Poettering, Red Hat
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

XDG_RUNTIME_DIR: When is a user logged out?

[Thomas Kluyver]

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 XDG_RUNTIME_DIR continuing to exist. However, 
some users have reported that if they run a process in nohup/screen and then 
disconnect, their XDG_RUNTIME_DIR is deleted because they have logged out. It 
looks like other people have had similar issues:

https://github.com/projectatomic/libpod/issues/659
https://unix.stackexchange.com/questions/386504/how-do-you-keep-systemd-user-services-alive-over-mosh

I tested this on a Debian system and I couldn't reproduce the problem: 
XDG_RUNTIME_DIR continued to exist when I disconnected and left a script 
running in nohup. But I don't know what to tell users who are experiencing this 
issue.

1. When should the user count as logged out? Is my assumption that the user is 
logged in while any process is running with their UID reasonable? Can we 
clarify this in the spec?
2. If my assumption is how it's meant to work, what component is getting it 
wrong? Is this the SSH server's job? Are there any known issues about it?

Thanks,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Fwd: Re: Licensing for file manager DBus interface spec

[Thomas Kluyver]

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 contributions he has made 
to the wiki. While we didn't yet agree that that's the licensing we want to aim 
to use sitewide, they're both very permissive licenses, so it's a good starting 
point.

Thomas

- Original message -
From: Thomas Kluyver <tho...@kluyver.me.uk>
To: Federico Mena Quintero <feder...@gnome.org>
Subject: Re: Licensing for file manager DBus interface spec
Date: Mon, 07 May 2018 21:53:34 +0100

Thanks Federico! I'll pass your message on to the list and mention the license 
on the page.

On Mon, May 7, 2018, at 9:49 PM, Federico Mena Quintero wrote:
> On Sun, 2018-05-06 at 19:23 +0100, Thomas Kluyver wrote:
> 
> > A discussion came up on the XDG mailing list about the licensing of
> > the file manager interface spec you wrote back in 2012, now hosted
> > here:
> > 
> > https://www.freedesktop.org/wiki/Specifications/file-manager-interfac
> > e/
> 
> Woah, this brings back memories :)
> 
> > 1. Are you happy for the file manager DBus spec (linked above) to be
> > licensed this way? It looks like you are the sole author of this -
> > later contributors have only adjusted formatting - so your agreement
> > is enough to apply a license to it.
> > 
> > 2. If we try to apply MIT/CC-BY to the freedesktop wiki more
> > generally, are you happy for your other contributions to this wiki to
> > be licensed under these terms? This includes contributions to
> > previous fd.o wikis which have been migrated into the current site.
> 
> Yes to both questions!  I have no problems with them being relicensed
> like that.
> 
>   Federico
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

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

[Thomas Kluyver]

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 to 
ikiwiki, but that's not a creative work. I've emailed Federico to ask about 
licensing, and I'll let you know when he responds.

I've also built a list of which users edited which page on the MoinMoin wiki, 
to make it easier to do this for other pages:
https://gitlab.com/takluyver/xdg-moinmoin-archaeology/blob/master/page_editors.json

This data would have been public when that version of the wiki was live, and 
the equivalent data is public for the current wiki, so I don't think there can 
be any privacy concerns. I haven't re-published the raw wiki data I generated 
it from, in case that has some sensitive info, but anyone with access to 
annarchy.freedesktop.org can get the raw data if they want to check. The repo 
contains two notebooks with the code I used to put that list together.

Thomas

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

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

[Thomas Kluyver]

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 for not explaining that clearly enough.
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

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

[Thomas Kluyver]

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 delete all the remaining non licensed content
> then get someone else to fill in any gaps. 

I'm hoping it might also be possible to work at the level of individual pages: 
find everyone who has contributed to a page and get their agreement to put a 
license on it. In combination with agreeing a license for new changes, of 
course.

>  If we were to go with the suggestion I wrote above
> there are many others who could make that change easier then myself who
> has no access. 

Do you know who these people are? Part of what makes this tricky is that I 
don't even know who can do admin stuff on the wiki.

> Either way if something is going to change there needs to be more
> discussion yet as no one has agreed on which license we would use, which
> you need to decide before contacting previous contributors.

OK, let's try to move that forwards. I propose that we use the MIT license for 
any code on the wiki, and CC-BY for text and any other non-code content. These 
are equivalent in spirit, but MIT is written for source code.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

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

[Thomas Kluyver]

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 redistributed by the wiki in its current form.

I'm fine with this 'implicit license' approach, but it's precisely the sort of 
grey area that other people insisted cannot possibly be allowed.

It's frustrating that people have the time and energy to argue about copyright, 
but nobody seems to be interested in doing anything to improve the wiki.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

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

[Thomas Kluyver]

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 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. Since we are taking 
> copyright Very Seriously, there are two problems:
> 
> 1. No-one can copy code samples from the wiki, or redistribute 
> specifications or anything, because they don't have a license. This is 
> what the thread was originally about, and it seems like a pretty major 
> flaw for a body making interoperability specifications for open source 
> software.
> 2. Whoever runs freedesktop.org is violating all the contributors' 
> copyright by redistributing the content they created, because you're not 
> asked to grant a license when you edit the wiki.
> 
> Is anybody interested in fixing this? Do we even have a record of who 
> edited what before the wiki was migrated to its current form?
> 
> If you think we can live with the ambiguous copyright situation as it 
> is, then you weren't really taking copyright law Very Seriously, you 
> were just picking an argument with me for trying to suggest a solution.
> 
> Thomas
> 
> On Sat, May 5, 2018, at 3:29 PM, Thomas U. Grüttmüller wrote:
> > 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 wiki about open source software are not going to sue you for 
> > > putting an open source license on it.
> > 
> > People might change their view on free software.
> > 
> > People might also die, and their rights will be inherited by their heirs.
> > 
> > > It's not even clear what they'd sue for: you can't lose revenue on wiki 
> > > content that is already accessible at zero cost.
> > 
> > It does not matter. Copyright violation is a criminal offense, just like 
> > trespassing or slander. It does not matter for it to be forbidden, if 
> > the victim suffers financial damage or not.
> > 
> > > As I said, this is something I have seen projects do. The Ubuntu wiki 
> > > underwent relicensing in 2011, for instance, with the wording in an email:
> > > "In the absence of a substantial number of objections, this change will 
> > > be made to the Ubuntu wiki after approximately one month."
> > 
> > This is dangerous for re-users of the work, because they rely on the 
> > license, but the license is invalid. So, without knowing, the re-user 
> > will do a copyright violation and might be sued.
> > 
> > Thomas
> > ___
> > xdg mailing list
> > xdg@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/xdg
> ___
> xdg mailing list
> xdg@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

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

[Thomas Kluyver]

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 are two problems:

1. No-one can copy code samples from the wiki, or redistribute specifications 
or anything, because they don't have a license. This is what the thread was 
originally about, and it seems like a pretty major flaw for a body making 
interoperability specifications for open source software.
2. Whoever runs freedesktop.org is violating all the contributors' copyright by 
redistributing the content they created, because you're not asked to grant a 
license when you edit the wiki.

Is anybody interested in fixing this? Do we even have a record of who edited 
what before the wiki was migrated to its current form?

If you think we can live with the ambiguous copyright situation as it is, then 
you weren't really taking copyright law Very Seriously, you were just picking 
an argument with me for trying to suggest a solution.

Thomas

On Sat, May 5, 2018, at 3:29 PM, Thomas U. Grüttmüller wrote:
> 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 wiki about open source software are not going to sue you for 
> > putting an open source license on it.
> 
> People might change their view on free software.
> 
> People might also die, and their rights will be inherited by their heirs.
> 
> > It's not even clear what they'd sue for: you can't lose revenue on wiki 
> > content that is already accessible at zero cost.
> 
> It does not matter. Copyright violation is a criminal offense, just like 
> trespassing or slander. It does not matter for it to be forbidden, if 
> the victim suffers financial damage or not.
> 
> > As I said, this is something I have seen projects do. The Ubuntu wiki 
> > underwent relicensing in 2011, for instance, with the wording in an email:
> > "In the absence of a substantial number of objections, this change will be 
> > made to the Ubuntu wiki after approximately one month."
> 
> This is dangerous for re-users of the work, because they rely on the 
> license, but the license is invalid. So, without knowing, the re-user 
> will do a copyright violation and might be sued.
> 
> Thomas
> ___
> xdg mailing list
> xdg@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

freedesktop.org specifications list

[Thomas Kluyver]

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 (https://developer.gnome.org/notification-spec/ ), but it is all based 
around the reversed domain name org.freedesktop.Notifications, so I assume it's 
an XDG specification?
- I think some of the specs should have graduated into the 'de facto agreement' 
category some time ago - e.g the file manager DBus interface, or icon naming, 
or the MPRIS media player interface. There are probably others, too, but I 
don't know which.
- Some can move from 'planning' to 'used by one or more', e.g. secret storage.
- Others should probably be retracted or deprecated. I won't try to name any in 
case I'm wrong, but there are quite a few I've never heard of that don't seem 
to have been touched in years.

I'd also like to add information to each spec about which major implementations 
support it, something like the browser compatibility tables MDN provides:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#Browser_compatibility

Even if there ambiguities and caveats, it's easier for someone to notice that 
it's out of date and change it than vague categories like "pretty good de facto 
adoption".

Thanks,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

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

[Thomas Kluyver]

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 to sue you for putting an open source 
license on it. It's not even clear what they'd sue for: you can't lose revenue 
on wiki content that is already accessible at zero cost.

As I said, this is something I have seen projects do. The Ubuntu wiki underwent 
relicensing in 2011, for instance, with the wording in an email:
"In the absence of a substantial number of objections, this change will be made 
to the Ubuntu wiki after approximately one month."

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

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

[Thomas Kluyver]

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 new content, but relicensing the existing
> content is quite a time-consuming process: first finding who wrote it
> in the first place, and then getting in contact with them. The former
> is difficult because we have moved from twiki -> MoinMoin -> ikiwiki,
> in most cases losing history. We can find the history, but it takes a
> lot of time. Secondly, this content dates back in some cases to 2004,
> and contacting people after 14 years is notoriously difficult.

I have seen other projects tackle relicensing by *attempting* to contact all 
contributors and explicitly giving some timeout - "if we don't receive any 
objections in a month, we'll go ahead". This seems like a sensible compromise - 
most people don't care about the licensing of two sentences they wrote on a 
wiki five years ago.

Of course, finding the list of contributors and valid email addresses for each 
one would still be quite a lot of work, but that strategy makes it a manageable 
amount rather than a crazy amount.

Is the history from the previous wiki systems preserved somewhere?
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

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

[Thomas Kluyver]

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 or responsibility for 
XDG. When GNOME or KDE developers chime in, they tend to drive the discussion, 
but I don't know who, if anyone, focuses on improving the Freedesktop wiki and 
specifications.

I think this is a pity, and I hope someone can tell me that I'm wrong. :-)

> It would be great if anyone could help me get into contact with the 
> original 
> author of 
> https://www.freedesktop.org/wiki/Specifications/file-manager-interface 

Looking through the mailing list thread linked from that spec, it looks like 
Federico Mena Quintero was one of the main people involved in writing it. His 
GitHub profile lists an email address: https://github.com/federicomenaquintero .

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

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

[Thomas Kluyver]

+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 default.

Thomas

On Wed, Mar 21, 2018, at 9:27 AM, Boyuan Yang wrote:
> 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 license and author for
> page [1]. Some downstream projects are including the XML file into
> their projects yet the uncertain license of code snippet caused some
> copyright troubles. Looking through git history is not helpful since
> the original page was converted from moinmoin wiki and the original
> author information is lost.
> 
> Daniels also suggested that any new content on wiki can (and should)
> have licensing information added. I think that the wiki should also
> choose a fallback license. When the author didn't point out the
> copyright information for page contents explicitly, the default
> license should apply. That could eliminate any licensing problem in
> the future.
> 
> 
> Also sending mail copy to those involved in the discussion for
> creating file-manager interface. Hope that the original author could
> read the mail and explicitly state the license for page [1].
> 
> 
> [1] https://www.freedesktop.org/wiki/Specifications/file-manager-interface/
> 
> --
> Regards,
> Boyuan Yang
> ___
> xdg mailing list
> xdg@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Questions about a unified API for file choosers (and platform/toolkit integration)

[Thomas Kluyver]

On Sun, Mar 26, 2017, at 07:18 PM, Roman Hargrave wrote:
> even though dbus and friends are omnipresent (I even
> found
> it on an old embedded ebook reader, in some form).

Was that a Kobo device, by any chance? I've got one of those to
experiment with, and also noticed that it starts dbus.
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Questions about a unified API for file choosers (and platform/toolkit integration)

[Thomas Kluyver]

On Thu, Mar 23, 2017, at 10:30 PM, Roman Hargrave wrote:
> Now, if there were a toolkit-agnostic set of interfaces for applications
> to call in to in order to prompt the user with the native file picker
> instead of that which the toolkits use would have the advantage of insuring
> that any settings applied by their desktop environment follow through to the
> application experience, thus allowing users to, for instance, not be  
> subjected
> to, for instance GTK file picker if they would prefer to use the Qt picker.

Flatpak has a system of 'portals', so that a sandboxed application can
ask the user to select a file which the application wouldn't otherwise
have access to. From the description, it sounds like the UI you see will
depend on your desktop environment, not on the application's toolkit,
which seems like what you want.

https://github.com/flatpak/flatpak/wiki/Portals

I don't know whether this interface is available to applications not
running in Flatpak, though.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Batis - XDG-based packaging for Linux desktop apps

[Thomas Kluyver]

On Sat, Nov 21, 2015, at 03:58 PM, Shaun McCance wrote:
> I think you're confusing understanding how a system works underneath
> with understanding how to use it. GitHub is a testament to the massive
> number of people who use git. A very small handful of those people
> really truly grok how git works under the hood.

I'm not confusing those things, but I think it's important that
developers can understand what's going on as well as how to use the
tools. This is a complex topic - clearly there's a lot of stuff we use
every day without really understanding - but broadly I'm not comfortable
with saying "don't worry about how this works, just use it". People use
git, but they're not exactly happy about its incomprehensible nature
(https://xkcd.com/1597/ ;-). One of my aims with Batis was precisely to
keep it easy to understand, not just easy to use.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Batis - XDG-based packaging for Linux desktop apps

[Thomas Kluyver]

Hi Matthias,

Thanks for your thoughtful reply.

On Sat, Nov 21, 2015, at 09:02 PM, Matthias Klumpp wrote:
> I suppose you have looked at existing solutions to the problem, like
> 0install, Limba and XdgApp. What is the thing which makes your project
> special compared to those (there must be some unique selling point,
> right?)?

I have looked at them. The main unique selling point of Batis is that
the packages are regular tarballs with a self-contained install script,
so they're usable even if users don't have Batis installed. I'm trying
to avoid the catch 22 where developers don't use a new distribution
system because it has no users, and users don't use it because apps
don't refer to it.

Simplicity is a secondary point. Batis is designed as a step up from
what many cross-platform developers already do for Linux - manually
creating tarballs - rather than a big rethink of software distribution.
This also means that it's simple to add Batis metadata to plain tarballs
that are already available; I've created scripts to do this for a few
applications here:
https://github.com/batis-installer/batis-adapt

> I didn't look a Batis very closely yet, but I have a few questions:
> 
>  * It looks like Batis allows apps to depend on distributor-provided
> software - how do you handle missing dependencies of your software?
> How do you plan to handle binary incompatibilities?

Apps can specify dependencies on Linux distro packages. If there's a
specification matching the distro you're running at install time, it
will try to invoke the system package manager to install the required
packages. If not, it will ask the user to ensure the necessary
dependencies are installed manually.

This is admittedly the crudest part of Batis. The idea is to automate,
where possible, what would otherwise be human readable instructions like
"MyApp relies on Python 3 and PyQt5. If you're on Debian/Ubuntu, run
'apt-get install python3-pyqt5'. For Fedora, run ...".

I would be interested in extending this to use AppStream metadata, but
that's another thing for application developers to learn about... and
another thing for me to learn about. Also, I'm not sure how many
packages provide appstream metadata; on my computer, there are not a lot
of files in /usr/share/appdata/.

>  * Batis allows scripts to be run at install time - how do you want to
> secure your installation processes, and adapt the newly installed apps
> to the system they are running on? IMHO and automatic configuration or
> a declarative interface would be much better than to allow the
> execution of arbitrary scripts at install-time.

The script is only a fallback option for users who don't have Batis
installed. The real interface is completely declarative: a couple of
JSON files, and a selection of icons, .desktop and mime XML files at
predictable locations. When you 'batis install ...' or click a batis://
link, no code from inside the package runs to install it.

The install.sh script inside the packages actually uses a copy of the
Batis code included in every package, and simply tells it to install the
directory containing install.sh. This assumes that desktop Linux systems
will have Python installed, which seems reasonable for the foreseeable
future. The code this uses is compatible with Python 3 or 2 (other parts
of Batis require Python 3).

Thanks,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Batis - XDG-based packaging for Linux desktop apps

[Thomas Kluyver]

Nearly a year ago, I posted to this list about the need for a better way
to distribute and install desktop applications [1]. There was some
interesting discussion, and people pointed out some existing
alternatives. But I remained convinced that something else was needed.

I've been thinking about the problem and tinkering for a while, and the
result is Batis:

https://batis-installer.github.io/

Batis allows developers to package their applications for users on any
distro to conveniently install.

Example applications: https://batis-installer.github.io/example-apps/

Key features:

- Users get Batis packages directly from application developers, rather
than going through a middleman like Linux distribution repositories. I
expect this to be controversial, but I think it's key for getting users
up to date software.
- Batis uses XDG specs for desktop entries, mimetype definitions and
icon themes, so that apps can integrate with desktop environments.
- Graceful fallback: Batis packages are tarballs, including an
install.sh which users without Batis can run. A developer could use
Batis to generate tarballs even if they didn't want to mention Batis to
their users.
- Keeps it simple: Batis packages are based on prosaic things like tar
and json - no fancy filesystem features or container technologies. It
should be easy for a developer to to understand what Batis does, as well
as how to use it.

Batis is ready for you to try out, but it's not battle tested yet.
Please don't judge it too harshly by the rough edges of 0.1! Bugs can be
filed here:
https://github.com/batis-installer/batis/issues

Thanks,
Thomas

[1] http://lists.freedesktop.org/archives/xdg/2014-December/013372.html
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Batis - XDG-based packaging for Linux desktop apps

[Thomas Kluyver]

On Fri, Nov 20, 2015, at 09:01 PM, Jasper St. Pierre wrote:
> Currently, the security model of Linux systems is "distro verifies
> security and adds to their own repo", with, of course, the step of
> "user trusts distro".
> 
> The security model of Batis seems to be "user trusts application
> developer"
> 
> The security model of xdg-app is "user trusts the sandbox mechanism".

That's right. I don't think the centralised verifier model can support a
really rich ecosystem without the kind of massive resources that Google
and Apple have to maintain their app stores. I like the idea of a
sandbox, but it's extra complexity and I'm not convinced that developers
will adopt it, since no-one's in a position to force people to use the
sandbox (unlike on Android, for instance).

"User trusts application developer" is what I end up doing every day.

> Even without that, there are difficult social problems to solve. The
> problem with tarball-based distribution is that applications are built
> for a specific environment. So an application built on Debian will
> probably assume some form of Debian-isms.

Many applications do solve this, at least to their own satisfaction.
There's no shortage of products which offer a single 'Linux' download,
including casual games (Powder Toy), programmer tools (Pycharm, Visual
Studio Code) and other applications (Telegram, CMapTools). These are
just a few things that I've come across, I'm sure there would be many
more if I went looking.

Several of those examples point to what I think is a common theme. Many
applications are already written in languages that run on a virtual
machine, whether that's Python, Java or Javascript. If I'm writing an
application using Electron, for instance, there are prebuilt Electron
binaries for generic Linux. So as an application developer, I don't need
to worry about ABIs. Of course, people do still write applications in C
as well, but clearly the difficulties are not insurmountable.

> Oh, and the one being built by KDE is Limba:

Thanks, I'll take a look at that.

Jerome:
> If you're not intimately
> familiar with linux, your problem is "Hey, should I distribute debs?
> rpms? tarballs? can I not distribute binaries? do I need to let the
> distro handle my stuff? what's that pacman they're talking about?" --
> adding another item into that particular mix is simply not useful.

Right. That's why I wanted to do an incremental improvement to tarballs,
the lowest common denominator that people retreat to when they're
overwhelmed by choices.

Specifically, you can use Batis to create a tarball and give that to
users without ever telling them about Batis - each tarball has an
included install script which the application developer hasn't had to
write or debug. I hope that developers do support Batis as an
installation mechanism as well, but it's useful even if they only use it
to create tarballs for users to install manually.

> So deb, rpm and tar.*z are really all the same format, with differing
> metadata on top. This is the big item to outsiders, and it's the
> easiest item to converge on.

It might be easy in principle, but I've not seen any indication that
distros are going to converge even at a relatively simple layer.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: [ANNOUNCE] xdg-app - desktop app sandboxing system

[Thomas Kluyver]

Hi Alex,

On Wed, Jun 24, 2015, at 01:15 AM, Alexander Larsson wrote:
 More details on how xdg-app works can be found here:
  https://wiki.gnome.org/Projects/SandboxedApps

Thanks, this looks interesting. A couple of questions:

How specific is a 'runtime'? If I've written an application based on
Python and Qt, for instance, do I need to define a Python+Qt runtime
based on the versions I need? Or would I use the freedesktop runtime and
specify in some other way that the application requires Python and Qt?
Or use the freedesktop runtime and bundle anything missing from it into
my application?

The wiki page mentioned distribution of apps, and I see links to
'OSTree', but I'm not quite clear what it means. What would it look like
for an application developer to package and distribute an application
like this, and what is going on when the user installs it?

On that last bit, specific examples of what I'm not sure about:
- Is it still conveyed inside an rpm/deb/whatever package, or will user
systems use OSTree to fetch it?
- Would an application developer host their own packages, or is it still
a centralised model like distro packaging? If it's centralised but
cross-distribution, who would run the repository?
- When the user installs an application, would it be like current app
installation on smartphones? FooApp needs these permissions, OK to
install it? Or could they deny individual capabilties? Or are the
capabilities checked by a centralised gatekeeper before the app is
available? Or some other model?

Best wishes,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: [ANNOUNCE] xdg-app - desktop app sandboxing system

[Thomas Kluyver]

Hi Jasper,

On Wed, Jun 24, 2015, at 10:23 AM, Jasper St. Pierre wrote:
 Both of these are really cool and convenient for system updates.
 xdg-app is simply using OSTree for its first bit, the repo bit.
 xdg-app has its own deploy stage.

So it sounds like an application publisher would use OSTree to host
releases, and the user uses a custom xdg-app mechanism to fetch and
install it. This would be independent of current distro package formats.
Is that right?

  - Would an application developer host their own packages, or is it still
  a centralised model like distro packaging? If it's centralised but
  cross-distribution, who would run the repository?
 
 You could run it either way. The vision here is definitely that the
 app developers publish their own official builds. But Fedora might
 want a central repo for all the packages in its distro.
 
 So, I don't know, it remains to be seen. We're simply building the
 tools here. Distro politics come after. :)

Right, but how you design the tools depends on how you expect them to be
used. I'm happy to hear that the vision is for app developers to publish
their own builds: I don't think centralised gate-keeping scales well
enough, unless you have the kind of resources Google or Apple have to
run it.

 When the app is deployed, its manifest of permissions is checked to
 determine what should be mounted in the sandbox. This manifest can be
 edited by a user at any time. Note, however, that if the app isn't
 coded for these failure cases (it was simply using a standard Linux
 API), it might crash outright.

I'm still a bit unclear on what the trust model is - would the user be
clearly shown the permissions manifest in an understandable format
before they use the application, so they could see if it was trying to
do anything sneaky? Or is the idea that you trust the app author, and
permissions are a way to limit the impact on the system if there's a
security bug in that app?

Again, it's the vision I'm interested in - I understand that it's early
days for the project and this kind of user-visible stuff might be some
way off. But it's good to know what it's driving towards.

Thanks,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: [ANNOUNCE] xdg-app - desktop app sandboxing system

[Thomas Kluyver]

Thanks Alex,

On Wed, Jun 24, 2015, at 12:20 PM, Alexander Larsson wrote:
 A runtime is very specific. It defines an exact ABI and is then
 supposed to continue to support exactly that ABI. If anything that you
 need is not shipped in the runtime you chose to use, you need to bundle
 those with the app. In general you should not define your own runtime,
 doing that is analogous to creating (and supporting) your own distro.

Just to check, though, a user can have more than one runtime available
on their system, right? I hope the distro doesn't decide on a single
runtime that all apps must use.

 ostree is used under the hood. But rpm/deb/whatever can be used to
 construct the app on the developer side.

But there's one package which users of all distros can install, correct?
i.e. The app developer doesn't need to make an rpm package *and* a deb
package and so on.

Best wishes,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Fallbacks for $XDG_RUNTIME_DIR

[Thomas Kluyver]

I looked into this before, and came to the conclusion that there is no
fallback directory that meets the guarantees $XDG_RUNTIME_DIR provides. If
you want your application to run on older systems that don't provide
$XDG_RUNTIME_DIR, you'll need to think about what properties are important
for your use case, and figure out the best way of making a fallback.
Carefully creating a user-only-readable temp directory might be one
possible strategy.

It would be valuable to collect information on what versions of different
distros provide features such as $XDG_RUNTIME_DIR, so that application
authors can estimate when it's safe to use them without fallbacks.
Something like http://caniuse.com/ for free desktop programming. If
anyone's looking for something to work on, this could be a really neat
website and crowdsourcing effort.

Thomas

On 3 June 2015 at 07:53, Vladimir Kudrya vladimir-...@yandex.ru wrote:

 Hi!
 I wanted to know, what are the valid fallbacks for $XDG_RUNTIME_DIR in
 case it is not defined, or if there are no systemd components present in
 the system to manage /run/user/$UID.
 Basedir spec only references mandatory premissions for such dir, but lacks
 examples for fallbacks.
 Thank you!
 ___
 xdg mailing list
 xdg@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/xdg

___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: [PATCH notification] spec: Add badge-number hint

[Thomas Kluyver]

On 16 February 2015 at 10:18, Bastien Nocera had...@hadess.net wrote:

 About the? It's also very low for a number of people. I can also be
 there to notify about the number of new podcasts episodes to read, the
 number of unread articles in my offline reader app, the number of unread
 messages in my chat application,


In all of these cases (email, podcasts, RSS reader, chat), I have used
applications which internally show some kind of unread/unseen count, and in
all four categories, the number quickly gets higher than I have any
intention of doing anything about other than clicking 'Mark all read'. I
have a suspicion that this is partly what 'killed' RSS (in popular use) -
feed readers were designed as if people would read every item, and then it
felt like a chore to keep up with it.

I'm not saying there are no possible use cases for a numeric badge, but my
experience is that most of the obvious use cases for it are not great UI
design.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Free desktop application distribution and installation

[Thomas Kluyver]

On 16 December 2014 at 12:52, Alexander Larsson al...@redhat.com wrote:

 Well, there are two parts. One is the actual runtime that makes the
 whole thing tick. This part is desktop independent.

 The second part is to have an actual base runtime with dependencies that
 you can use to write an application. Anyone could create one, and the
 system obviously handles that, but I'm also creating a gnome specific
 one both so that gnome applications can use it and to have *something*
 to test things on.


That sounds pretty reasonable. It's also not far from my idea of using very
few system dependencies to ensure the necessary runtime (e.g. Python 3 + Qt
5) is available, and bundling the majority of the libraries the application
wants.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Free desktop application distribution and installation

[Thomas Kluyver]

On 16 December 2014 at 13:06, Matthias Klumpp matth...@tenstral.net wrote:

 so you would force the app
 author to write a huge metadata file


As I see it, many app authors are already figuring out the necessary
metadata for different distros, whether they scatter it around in packaging
files for different systems, or write it in human readable form in their
docs (...on Ubuntu, apt-get install blah...). So I'm thinking of a way to
store that information in a standardised, machine readable format so
dependencies will install programmatically. There would also be a natural
language fallback, so if the user's distro is not recognised, they will see
a message that they should ensure X  Y are installed. I imagine most
applications would start with automatic dependency installation for only a
couple of popular distros, and as they became more widely known, users of
minor distros would contribute the metadata to deal with dependencies
automatically.

I think there's a philosophical difference in our approaches. You are
trying to rethink application installation from the ground up. I'm very
glad that someone is doing that, but I'm personally thinking about how to
incrementally improve one of the common ways to distribute applications at
present. This is not quite what I suggested in my first email, but my
thinking has evolved during this discussion. This shift is partly because
I've seen that projects like Listaller and 0install have already tried
something much closer to my initial proposal, and do not seem to have got
much traction (as in, I haven't seen applications recommending installation
using such tools). I suspect that, whatever the technical merits of new
installer systems, getting adoption is very hard because of the catch 22 -
application authors have little incentive to use it until there are many
users, and users have little incentive to use it until there are many
applications installable with it.

Thanks,
Thomas

--
Further thinking:
From my brief, informal survey of application websites, they seem to fall
into three main categories:

1. The good open source citizens - a list of instructions for different
distros, often with a weary message that distro packages tend to be out of
date, and not uncommonly mixed in with instructions on compiling it
yourself. 'Conversion rate' is a foreign term. E.g. 0AD, Battle for
Wesnoth, Amarok. Sometimes they even skip the specific instructions and
just tell you to install from your distro (e.g. Meld, Gnumeric).
2. The cross platform application - a download button points to a tarball.
The user is expected to deal with extracting it, finding the extracted
files, and working out which one to click on (peanuts for an experienced
user, but this sort of friction can be offputting for newcomers). E.g.
Firefox, Zotero, Pycharm, Eclipse.
3. Big enough to do it ourselves - Builds packages for different distros
and hosts them themselves. Probably the best user experience (if your
distro is supported), but a lot more work for developers. It usually still
requires the user to select 32-/64-bit and deb/rpm (two decisions which may
not be apparent to non-expert users). E.g. Google Earth  Chrome, Skype,
Libreoffice.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Free desktop application distribution and installation

[Thomas Kluyver]

Hi Matthias,

On 8 December 2014 at 19:01, Matthias Klumpp matth...@tenstral.net wrote:

 his means without installation those tarballs are of no value to the
 user, OR they contain a lot of bundled dependencies, which defeats
 your point of pulling stuff from the distribution repositories.


My intention is that without the installer tool, the experience is the same
as using tarballs currently is: some dependencies are bundled, and the user
is instructed to install manually. E.g. system requirements for Pycharm
list Oracle JRE 1.6+ or OpenJDK 1.7+; Python 2.4 or higher, Jython, PyPy
or IronPython. I'm imagining here that applications will prefer to bundle
the majority of the libraries they're using to avoid APIs changing
underneath them, and only have a couple of big dependencies like language
runtimes or GUI toolkits.

But it could go one better: the tarball could ship with a minimal version
of the installer tool included, so the user unpacks it and runs ./install,
and it reads the metadata and uses the package manager to install the local
dependencies. There may not seem much benefit to the user in actually
getting the full installer, then, but it still offers some convenience
(handles downloading and unpacking for you) and some security (when you're
prompted for root access to install dependencies, you only need to trust
the installer, not the package you're installing).

 Oho, you would be suprised! It is actually *very* hard and a complex
 task to perform for an upstream project author. It also limits a
 software to a set of distributions.

Can you expand on why this is so complex? I'm thinking of something like
this:

depends[apt]=python3-pyqt5
depends[rpm]=python3-qt5

Is this something that's complex primarily for compiled languages because
of ABI changes? I'm used to dynamic languages, so I don't have a good feel
for ABI incompatibility, though I know what it means. Is the complexity to
do with working out what distro you're actually in? Or something else?

Thanks,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Free desktop application distribution and installation

[Thomas Kluyver]

This may be a pipe dream, but XDG is the best place I know to propose
something like this:

We need a new mechanism for distributing end-user applications on free
desktop platforms.

Traditionally, distro packaging is considered the right way to distribute
applications. However, I believe that distro packaging is designed to
distribute libraries, frameworks and such tools for developers and
sysadmins, not end user applications. Specifically:

* Distro packages are almost always out of date. Even with 'quick' six
month release cycles, the gap between the developer making a release and
users getting it is measured in weeks or months, when we (application
developers) want it to be hours or days.
* More broadly, distros put a layer between developers and users. That has
some benefits, but with end user applications we generally want to engage
more directly with the user, to present the image we choose and get
feedback directly.
* You need to provide different instructions for each distro - like this
download page for 0AD: play0ad.com/download/linux/
* If you want to package your application yourself, you realistically need
to deal with at least .deb and .rpm package formats, and if you care enough
about smaller distributions, there are still more formats. LSB attempted to
declare RPM the standard, but that hasn't really worked.
* On most distros, packages can only be installed as root, so to get even
some trivial game working, you have to hand it the keys to the kingdom.

As a result, on many application webpages, the download button gives you a
.tar.gz file - e.g. Firefox, Eclipse, Pycharm and Zotero. That avoids all
of the issues listed above, but it can't add things to $PATH, install
.desktop files, set up automatic updates, and so on, unless the
application's own code completes its installation when it's first run. And
if users are as lazy as me, they end up with applications 'installed' in
their Downloads folder, which doesn't seem quite right.

Still other applications try to rely on language specific packaging tools.
My background is in Python, and I've seen applications recommend you
install them with pip. Python packaging tools are pretty bad even for the
things they're supposed to do, and distributing applications is not one of
those things.

So, I would like a mechanism whereby:

1. Developers can publish applications without going through distro
maintainers. This could either be self-hosted installer files, or a
centralised location where you're free to claim a name (like PyPI, CPAN,
etc.)
2. When the user installs an application, it can set up command line tools
on $PATH and .desktop files to launch the application from the GUI.
3. Applications can be installed into ~/.local without giving them root
privileges
3.a For bonus points: capabilities based security, because root is not the
only thing we care about: http://xkcd.com/1200/
4. The installer should be able to specify dependencies on system packages
for any relevant packaging systems, because the developer shouldn't be
forced to bundle dependencies any more than they should be forced to
unbundle them.
5. A user with an application installed should be notified of updates,
without every application having to implement its own update checker and
downloader.
6. Ideally, all of this should be an addition to a tarball, so sites can
offer a single .app.tar.gz file, and users without the installer mechanism
can extract the files and launch the application manually.
7. This should, of course, be distro and desktop independent. We definitely
can't afford to fragment it by GNOME vs. KDE, or Debian vs. Red Hat.
Applications should have *one* button to download for Linux.

I am working on an end-user application, and I will try to build something
like this and test it by distributing that (glossing over 3a and probably
skipping 5 for the first iteration). Feedback, offers of help, and telling
me about similar things that already exist are all welcome.

Thanks,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Free desktop application distribution and installation

[Thomas Kluyver]

Thanks Matthias  Mattias for your comments,

I will certainly look into Limba some more - I don't want to proliferate
too many solutions if other people are working on this. From reading your
blog post, my initial concern is that having a duplicate dependency system
is too complex. My idea is that these application packages are only
consumers of the system dependency management, and that only for
sufficiently stable packages (like PyQt4). If the developer wants to bundle
things, they just include the relevant files in their package, without
telling the package system about them at all.

On 8 December 2014 at 15:38, Matthias Klumpp matth...@tenstral.net wrote:
 3. Applications can be installed into ~/.local without giving them root
 privileges

 This actually has some security implications, e.g. a malicious
 software can taint the other applications and use them to hide itself.
 It also leads to some kind of annarchy on one system, where different
 users are running different software versions (and combinations of
 them).


Sure, it's a long way from perfect security against malicious applications.
But it's a very easy step to take, and giving an application everything
apart from root permissions is still better than giving it everything
including root, so it's better than installing .deb/.rpm packages. 3a was
my goal to improve security, but that's orders of magnitude more complex.


  6. Ideally, all of this should be an addition to a tarball, so sites can
  offer a single .app.tar.gz file, and users without the installer
 mechanism
  can extract the files and launch the application manually.

 Why should they want to do that? This would not only have all problems
 described in 3., but also have other technical difficulties. E.g. you
 have version 1.0 of application X which creates some configuration in
 your home directory. Then you decide to test version 2.0 that way,
 which migrates your configuration to a higher version. Then you decide
 to switch back to 1.0, or simply launch 1.0 because you forgot about
 the local copy. Version 1.0 can't read 2.0 configuration or in the
 worst case might even corrupt it, and then you have new trouble.


I'm not quite sure about the link between that point and
upgrading/downgrading config.

This is my attempt to address the obvious catch 22 here: why would users
install the package installer tool if apps don't use it, and why would apps
use that packaging format if users can't install it? My solution is that
the packaging format is usable even without having the installer tool. All
the applications that currently offer Linux downloads as a tarball could
offer .app.tar.gz tarballs. If the user doesn't have the installer, they
just keep using it like a regular tarball, but if they do, it opens in the
installer, and shortcuts and dependencies are automatically installed for
the user.

This may sound trivial, but I think it's actually very important. Users
don't go looking for how to install applications, they look for
*applications*, and assume the applications will tell them the best way to
install that. If one or two applications offer 0install or Limba packages
as an alternative, it's not worth the user's time to go and research that
system, get it set up and then use it to install the application. You need
a critical mass of applications to make the system a de-facto standard so
users and distros will pay attention to it. Extending the
lowest-common-denominator standard of tarballs is one way to get there.

If you'll excuse the cynicism, there may also be benefits to constraining
the imagination of people building packaging systems. As an application
developer, I have something cool working on my computer, and now I want to
make it easy for other people to use it. When I go and read about making a
0install package, it says I should read the page about important concepts
first. That page is full of sentences like: When you launch a program
(like Edit) 0install looks up the feed files of the interface and chooses
an implementation of the interface and the interfaces it depends on
according to the policy settings (e.g. preferring stable or testing
implementations). And my heart sinks. That sounds like a bunch of new
stuff I need to learn about. What I want to see is more like: make a
tarball, however you want, with a couple of extra files in this and that
fixed location, in the format described here...

Mattias:

I'm not quite clear about what exactly your proposal is aiming at. I think
you've identified differences in package naming among distros as a central
concern, and the system of UUIDs is designed to overcome that. I don't
think that's a big problem; as an application developer, maintaining a list
of rpm dependencies and a list of deb dependencies is not especially hard.
Also, there's disagreement over what consitutes a package - for instance,
Riverbank releases PyQt as one big package, but Debian splits it into
several smaller packages. Who decides the UUIDs? 

Re: Free desktop application distribution and installation

[Thomas Kluyver]

On 8 December 2014 at 18:09, Mattias Andrée maand...@member.fsf.org wrote:

 The goal was to make it as simple as possible, but
 perhaps there is a simpler way than UUID:s.


My idea is that the new system leaves all the dependency management to
distros: an end user application can depend on distro packages, but can't
be depended on itself, so it wouldn't have an ID to specify as a
dependency. If a unique ID is needed, which it certainly may be, I'd go for
something more like Apple's UTIs (e.g. com.microsoft.Excel), which have at
least some meaning without a lookup table.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Binary name in the desktop file

[Thomas Kluyver]

On 26 December 2013 20:33, Liam R E Quin l...@holoweb.net wrote:

 On Thu, 2013-12-26 at 10:56 +, Jerome Leclanche wrote:
  I'd really like to be able to get the binary name from desktop files

 What if there's no binary, e.g. a shell script or a python-based program
 with a UI?


I think this is a key issue: do you actually mean the binary which will be
executed as machine code by the system, or do you mean the filename of
something which represents the application - which could be a binary, a
Python script, a Java jar, a Wine executable, etc?

Jerome, you've also said that part of the issue is that applications cannot
use a different command line syntax for launching with and without input
args such as filenames. Do we have any examples of applications that need
this, or would like to need this? I guess if files were specified for
something as e.g. --file %f, it would be necessary.

Thanks,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Thomas Kluyver]

On 24 December 2013 15:06, Kevin Krammer kram...@kde.org wrote:

  BTW, I happen to know one breakage caused by Linux not having open(1)
 like
  OS X. https://github.com/swaroopch/byte_of_python/issues/8

 Looks like the implementors either had not thought about cross platform
 integration or had no information about things outside the platform they
 are
 working on.


I think it would be beneficial for 'open' to work the way that people
writing scripts on OS X expect, i.e. an alias to xdg-open, because it's not
obvious that it is a platform specific thing.

Of course, you'd still need to consider cross platform compatibility for
Windows, but people are used to assuming that similar shell commands work
across posix-y platforms, while Windows is a very different ball game.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Thomas Kluyver]

On 24 December 2013 16:37, Kevin Krammer kram...@kde.org wrote:

 Well, a quick check would have revealed that it is.
 Cross platform development always requires testing on the targetted
 platforms,
 one can not simply assume things.


But I don't go and check that simple commands like cp or grep will work on
a Mac. It's easy to see how someone could have assumed that 'open' is a
similarly common command and would work on Linux systems. Of course you can
blame developers who make incorrect assumptions, but why not aim to make
the obvious assumptions correct?
.
 Even if a tool or command with the same name exists it might have
different
 capabilities, arguments or options.

That is a valid concern - OSX's open has several options that xdg-open does
not (currently). But I think the benefit of having a similar obvious way to
load files and URLs outweighs that. Developers are also familiar with
common commands like cc and make being provided by different
implementations that may support different options.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Thomas Kluyver]

On 21 December 2013 08:37, Ma Xiaojun damage3...@gmail.com wrote:

 The good news is now that, console-tools, the package provides open(1)
 in Debian, is being removed recently, if I understand correctly:
 http://packages.qa.debian.org/c/console-tools.html


I think it's still provided in the kbd package:
http://packages.debian.org/sid/amd64/kbd/filelist

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Mime types - uppercase appearing in mime type names

[Thomas Kluyver]

On 18 March 2013 07:47, Thomas Kluyver tho...@kluyver.me.uk wrote:


 I've also realised I copied the wrong URL for the bug. The correct one is:
 https://bugs.freedesktop.org/show_bug.cgi?id=62473


Any more thoughts about this (the case of MEDIA/SUBTYPE.xml filename)? I
had a go at a simple patch for the spec and update-mime-database. I'm
aiming for a 1.0 release of PyXDG, so I'd like to know that this is getting
resolved.

Thank-you,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Freedesktop Application Icon / magic database (Debian)

[Thomas Kluyver]

On 2 May 2013 21:03, Felix Natter fnat...@gmx.net wrote:

 The only problem with this (and probably the reason why the previous
 packager used the full path to freeplane.svg) is that konqueror displays
 a (small) bitmap instead of the svg which is pixelated.


I think the idea is that it's up to the file manager to pick the best icon.
pngs seem to be preferred - I guess they're less computationally intensive
to render.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Freedesktop Application Icon / magic database (Debian)

[Thomas Kluyver]

On 1 May 2013 12:41, Felix Natter fnat...@gmx.net wrote:

 icon name=/usr/share/icons/hicolor/scalable/apps/freeplane.svg
 /


The spec isn't entirely clear on what the name attribute should be, but in
the one example I've got on my system, it's a simple filename, not a full
path:

icon name=qgis-mime-icon.png/


 I also tried icon name=freeplane.svg/, icon name=freeplane/ and
 icon name=freeplane.png/ (by changing
 /usr/share/mime/packages/freeplane.xml and running update-mime-database
 /usr/share/mime) but see no change.


It's possible that the file manager keeps its own cache of Mime types, so
you might need to restart the file manager as well.


 'file' does not detect the correct mime type, but I don't think this
 is related to my problem [1] (since it works with the right-click menu):


file works with a separate database of magic numbers that predates
shared-mime-info. To check with the xdg database, you can run:

xdg-mime query filetype myfile.mm

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Freedesktop Application Icon / magic database (Debian)

[Thomas Kluyver]

On 1 May 2013 18:22, Felix Natter fnat...@gmx.net wrote:

 and put freeplane.png here:
 /usr/share/icons/hicolor/32x32/mimetypes/freeplane.png
 (I also tried to put the svg in hicolor/scalable/mimetypes/)

 = probably a (local?) problem with my nautilus? It seems to work in
 konqueror (and on another computer with the same config it even works
 with nautlius :-/)


This might be obvious, but did you have the icons displayed at 32x32 when
you tried? It might only resize larger images to smaller views. The default
view on my system seems to be 48x48.

The icon theme spec suggests that 'icon name' doesn't include the path or
the extension, though I see it also says minimally you should install a
48x48 icon...
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html


  = does it make sense to create a bug report against nautilus
 (I looked at the prefs but couldn't find anything :-/)?


I'd say not yet - I don't think we're confident that there really is a bug,
rather than just a config issue.


 That is really useful. Is there also a way to debug the icon locations?


Not that I know of, sorry.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: udev (from xdg Digest, Vol 109, Issue 18)

[Thomas Kluyver]

I think the issue is that the search box on the freedesktop.org home page
is part of the Moin wiki, so it only searches documents that are part of
that. Things like the udev reference manual (
http://www.freedesktop.org/software/systemd/libudev/ ) are generated
separately, but hosted on the same domain.

One easy answer would be to use a Google custom search engine, which can be
limited to pages from a particular site. Some people might take issue with
using a hosted, proprietary solution, though.

Thomas


On 25 April 2013 20:08, Alice Wonder alicewon...@shastaherps.org wrote:

 On Thu, 2013-04-25 at 12:00 -0700, xdg-requ...@lists.freedesktop.org
 
  Message: 1
  Date: Wed, 24 Apr 2013 23:48:13 -0700
  From: Alice Wonder alicewon...@shastaherps.org
  To: xdg@lists.freedesktop.org
  Subject: udev
  Message-ID: 1366872493.21492.9.camel@localhost
  Content-Type: text/plain; charset=UTF-8
 
  First : how come when I type udev (without the quotes) in to Search
  box I get no results? I know you host the API docs, and that udev is now
  part of systemd which you also host.

 A simple solution that a lot of search engines (e.g. sphider) implement
 is to tag certain documents with keywords that then come up in a search.

 Documents that deal wit udev could then have that keyword added,
 allowing them to come up in results when people visit the site and do a
 search for a very common technology such as udev.


 ___
 xdg mailing list
 xdg@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/xdg

___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: udev (from xdg Digest, Vol 109, Issue 18)

[Thomas Kluyver]

On 25 April 2013 20:45, Alice Wonder alicewon...@shastaherps.org wrote:

 e.g. a page called Udev that maybe has a very brief description and then
 hyperlinks to the actual documentation. That would also work.


That would fix this specific case, but what if you want to search for
something like a specific function from udev? I think there's an
expectation that a search box offers full text search of the whole site,
not just of names that have been prepared for it by making wiki pages.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Masking in the MIME magic spec

[Thomas Kluyver]

Thanks, David, that all makes sense of me. I'll ensure that the next
version of PyXDG applies the mask to both values, until we can be confident
that it will see the updated version of the magic database.

Thomas


On 19 April 2013 17:42, David Faure fa...@kde.org wrote:

 On Tuesday 19 March 2013 13:57:04 Thomas Kluyver wrote:
  On 19 March 2013 13:28, David Faure fa...@kde.org wrote:
   The other would be to write code that detects the cases where the
 database
   has
   values such that  (value  mask) != value, and fixing the database to
   specify
   (value  mask) as value from now on. This would allow implementations
 to
   avoid
   having to mask the value at runtime, which would lead to a minor
 speedup
   (and
   to the spec being correct after all).
   Such code would be easy to write, as part of any of the existing
   implementations, I would think.
 
  Yes, I think that sounds reasonable, although of course implementations
  will need to support the existing data for some time, even if newer
  versions of shared-mime-info fix that.

 I don't see that point. I'm talking about fixing the shared-mime-info data
 to
 have more useful expected values, this won't break existing
 implementations at
 all.

 What I meant by Such code and the existing implementations was to add a
 check in one implementation and use that to detect the weird expected
 values.
 But you've already done that apparently, by manual inspection.

 You're right though, removing the masking of the value in the
 implementations
 cannot be done for quite some time, even if we adjust the data today.
 Still, at some point this will be useful :)

  The downside is that
  update-mime-database is written in C, and as I found yesterday, I'm lousy
  at fixing C code. (Aside: this is an occasionally used script where
  performance isn't that important - would it make sense to write it in
  Python rather than C?)

 Not my code, I can't comment on that. But IMHO let's not start a language
 flamewar. It's there and it works.

  I've just inspected the values I have. There aren't many rules using
 masks
  at all. Of those that are, 5 need the mask applied, in all cases because
  they use a placeholder character where the mask has a null byte.
 
  - application/x-core, application/x-sharedlib and
  application/vnd.adobe.photoshop use spaces
  - image/bmp uses lowercase 'x'
  - application/vnd.corel-draw uses an uppercase 'X'

 Ah, so this leads to more readable magic than using '\000' in the value
 field.
 But indeed, update-mime-database could take care of sanitizing the value in
 the generated output.

 OK, done for int values too, which caught one more case:
   mime-type type=image/x-sigma-x3f
 match value=0x00FF00FF type=little32 offset=4
 mask=0xFF00FF00/
 I wonder if it's intended, i.e. the FF in the value field mean nothing...
 OK, http://www.photofo.com/downloads/x3f-raw-format.pdf says this is
 correct.
 The goal is to catch a version number like 0x00010003, for 1.3.

 And done for strings too (I'm not C/glib programmer either, I'm rather a
 C++/Qt guy, so this should be reviewed by glib people) ;)

 Attached is the diff (after hex-dumping) of the generated magic files.

 --
 David Faure, fa...@kde.org, http://www.davidfaure.fr
 Working on KDE, in particular KDE Frameworks 5

___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Direct-opening a temporary file using the user's preferred application

[Thomas Kluyver]

On 17 April 2013 15:24, Jan Kundrát j...@flaska.net wrote:

 This is not meant to say that your proposal is wrong -- it might actually
 be the best option which is available *right now*. It's just that I would
 like to have a solution which somehow elliminates all of the problems I
 described. If only the D-Bus activation included an option for throw
 away that file after reading it, prompt user for another name when
 modified,... -- would something like that be feasible?


When I directly open a document from the web, using Firefox, it opens in a
read only view (in, say, Libreoffice).
I've just tested, and it looks like it simply saves it, and then removes
all write permissions from the file before
 opening it, so Libreoffice offers 'Save as', but disables 'Save', and I
can't easily overwrite the file. Is that the sort of thing you're after? It
seems much simpler than bringing D-Bus into it.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re:

[Thomas Kluyver]

On 21 March 2013 15:13, Thiago Macieira thi...@kde.org wrote:

  The specification has no access control for users or groups. If you want
 settings to apply to specific users or specific groups, make them see
 those files
 and make other users not see those files.


You may also want to have a look at the menu spec:
http://standards.freedesktop.org/menu-spec/menu-spec-latest.html

For example, to show a particular menu to a specific user, you could create
a ~/.config/menus/application.menu file under their home directory.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Masking in the MIME magic spec

[Thomas Kluyver]

On 19 March 2013 13:28, David Faure fa...@kde.org wrote:

 The other would be to write code that detects the cases where the database
 has
 values such that  (value  mask) != value, and fixing the database to
 specify
 (value  mask) as value from now on. This would allow implementations to
 avoid
 having to mask the value at runtime, which would lead to a minor speedup
 (and
 to the spec being correct after all).
 Such code would be easy to write, as part of any of the existing
 implementations, I would think.


Yes, I think that sounds reasonable, although of course implementations
will need to support the existing data for some time, even if newer
versions of shared-mime-info fix that. The downside is that
update-mime-database is written in C, and as I found yesterday, I'm lousy
at fixing C code. (Aside: this is an occasionally used script where
performance isn't that important - would it make sense to write it in
Python rather than C?)

I've just inspected the values I have. There aren't many rules using masks
at all. Of those that are, 5 need the mask applied, in all cases because
they use a placeholder character where the mask has a null byte.

- application/x-core, application/x-sharedlib and
application/vnd.adobe.photoshop use spaces
- image/bmp uses lowercase 'x'
- application/vnd.corel-draw uses an uppercase 'X'

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Mime types - uppercase appearing in mime type names

[Thomas Kluyver]

I've filed a bug about this:
https://bugs.freedesktop.org/show_bug.cgi?id=9562

It's against xdgmime, as there doesn't seem to be a component for the
shared-mime-info spec. It would need both a (small) spec change and a code
change.

Thomas


On 15 March 2013 23:22, Jerome Leclanche adys...@gmail.com wrote:

 Agreed. If the files are not lowercase, we could have conflicts (which we
 actually do as you mentioned).


 J. Leclanche


 On Fri, Mar 15, 2013 at 10:11 PM, Thomas Kluyver tho...@kluyver.me.ukwrote:

 Almost all Mime types are named in lower case, e.g. image/png. However,
 there are a handful of MS office file formats that the 
 freedesktop.orgdatabase uses the word 'macroEnabled', e.g.

 application/vnd.ms-excel.sheet.macroEnabled.12

 The same type is also defined by LibreOffice, but in lowercase, i.e.
 macroenabled.

 I also see uppercase in audio/AMR, audio/AMR-WB and text/x-iMelody.

 RFC 2045 [1] says The type, subtype, and parameter names are not case
 sensitive. I can flatten the case easily enough, but looking up the
 MEDIA/SUBTYPE.xml files on a case-sensitive filesystem gets tricky - I
 would have to keep a reference to the original spelling, just for those few
 cases.

 To simplify this, I think the shared mime-info spec should say that the
 media/subtype.xml files are always named in lowercase. Since the names are
 supposed to be case insensitive, it shouldn't create conflicts.

 update-mime-database should also merge mimetypes regardless of case - at
 present, I see separate media/subtype.xml files for the 'macroEnabled' and
 'macroenabled' mimetypes.

 Thanks,
 Thomas

 [1] http://tools.ietf.org/html/rfc2045

 ___
 xdg mailing list
 xdg@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/xdg



___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Mime types - uppercase appearing in mime type names

[Thomas Kluyver]

On 18 March 2013 14:32, Bastien Nocera had...@hadess.net wrote:

 shared-mime-info - specification (or whatever) component


Rats, sorry. I was looking under the 'Specifications' product.

I've also realised I copied the wrong URL for the bug. The correct one is:
https://bugs.freedesktop.org/show_bug.cgi?id=62473

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Mime types - uppercase appearing in mime type names

[Thomas Kluyver]

Almost all Mime types are named in lower case, e.g. image/png. However,
there are a handful of MS office file formats that the
freedesktop.orgdatabase uses the word 'macroEnabled', e.g.

application/vnd.ms-excel.sheet.macroEnabled.12

The same type is also defined by LibreOffice, but in lowercase, i.e.
macroenabled.

I also see uppercase in audio/AMR, audio/AMR-WB and text/x-iMelody.

RFC 2045 [1] says The type, subtype, and parameter names are not case
sensitive. I can flatten the case easily enough, but looking up the
MEDIA/SUBTYPE.xml files on a case-sensitive filesystem gets tricky - I
would have to keep a reference to the original spelling, just for those few
cases.

To simplify this, I think the shared mime-info spec should say that the
media/subtype.xml files are always named in lowercase. Since the names are
supposed to be case insensitive, it shouldn't create conflicts.

update-mime-database should also merge mimetypes regardless of case - at
present, I see separate media/subtype.xml files for the 'macroEnabled' and
'macroenabled' mimetypes.

Thanks,
Thomas

[1] http://tools.ietf.org/html/rfc2045
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Masking in the MIME magic spec

[Thomas Kluyver]

The spec [1] says that the mask is applied to the value from the file
before comparing it with the value from the magic database.

However, looking for examples, I find image/vnd.adobe.photoshop [2], where
bytes 5-6 of the mask are \x00\x00, while bytes 5-6 of the value are
\x20\x20 (two spaces). By my reading, the test is therefore [value  0x
== 0x2020], which can never be true.

It looks like the mask should be applied to both the value from the file
and the value in the magic database, so where the mask is \x00, the magic
value is ignored. This appears to be what xdgmime does [3]. Is this
correct, and is it worth updating the spec to clarify it?

Thanks,
Thomas

[1]
http://standards.freedesktop.org/shared-mime-info-spec/latest/ar01s02.html#id2597284
[2]
http://cgit.freedesktop.org/xdg/shared-mime-info/tree/freedesktop.org.xml.in#n4523
[3] http://cgit.freedesktop.org/xdg/xdgmime/tree/src/xdgmimemagic.c#n536
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Fwd: Conflicting mime types

[Thomas Kluyver]

I've just had a bug reported against PyXDG that a Mimetype test is
returning image/x-apple-ios-png instead of image/png.

Looking at the XML mime type definitions [0], this new mime type ('Apple
broken PNGs') has the same glob as regular pngs: *.png. They can be
distinguished by magic sniffing, but the test in question is specifically
for when only a filename is available.

Obviously, a filename like foo.png should be presumed to be image/png over
image/x-apple-ios-png. But how should this be done? Should we prefer
mimetypes without the x- prefix? Could there be a collision between two
mimetypes neither of which have an x-? Is there some other heuristic we can
use?

[0]
http://cgit.freedesktop.org/xdg/shared-mime-info/commit/freedesktop.org.xml.in?id=afbdfb40a3ff8c255e5d3dab8840cc478a007d45

Thanks,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Conflicting mime types

[Thomas Kluyver]

On 5 March 2013 11:58, Jerome Leclanche adys...@gmail.com wrote:

 Are they valid PNGs? If so, it sounds like the mime type should just be a
 child of image/png and drop the glob here.


It's not clear, and I don't have one to examine. I would guess that they're
not valid:

- The commit message where the mimetype was added described them as 'Apple
broken PNGs'
- An Apple QA page says that 'Preview' (the OS X image  PDF viewer) can't
open iOS-optimized PNGs. (Just Works/sarcasm)
http://developer.apple.com/library/ios/#qa/qa1681/_index.html

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Conflicting mime types

[Thomas Kluyver]

On 5 March 2013 12:41, Jerome Leclanche adys...@gmail.com wrote:

  - PNG is a massively popular file format, who the hell thought this was a
 good idea?


Seconded ;-)

Bastien:
 Your implementation returns results differently from the one we use in
 shared-mime-info itself.

Looking at the implementation in PyXDG, it's quite a long way from the
recommended checking order in the spec. I'll have to sort that out properly
when I've got time, but for now it should be improved by making the first
suffix from the globs file win, not the last one (they're sorted by
decreasing weight).

Jerome:
 I think resulting behaviour should be the same as what you would do when
getting two conflicting, same-priority magics. The spec doesn't seem to
advocate a behaviour in this case[1]. In general, if there are conflicts,
they should be solved using the priority attribute at the package level.

In the file structure, the priority attribute is a property of the magic
matching rule, not of the mimetype. The description in the spec, on the
other hand, seems to be relevant to the Mimetype overall: Low numbers
should be used for more generic types (such as 'gzip compressed data') and
higher values for specific subtypes (such as a word processor format that
happens to use gzip to compress the file).

So does it make sense to use this even when we're not using the magic
matching rules?

Thanks,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: about match value -- file /usr/share/mime/packages/freedesktop.org.xml

[Thomas Kluyver]

On 18 January 2013 23:51, westlake westlake2...@videotron.ca wrote:

 So if I had these problematic filetypes (.msi/.msu) in ~ , I get no
 long-long long delay..

  ^ I tested it.. thumbnails off. A long list of files.. I then add just
 one problematic .msi file and it nearly stalls the listing completely (2+
 minute delay) -- just because of ONE file.


This certainly does sound like a problem. But ultimately, it still sounds
like a problem with the code somewhere. Even in 5 different file managers -
I suspect you may be hitting a corner case that hasn't really been tested
before.

I suggest you pick one of the GUI file managers - the one you use most or
understand best - and describe your problem on its mailing list or bug
tracker. If it's a problem in the code, they can work it out, and you can
take the discussion to the other file managers. If they decide that there's
some problem with the freedesktop stuff, we should get a clearer idea of
precisely what the issue is, and how we can fix it.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: about match value -- file /usr/share/mime/packages/freedesktop.org.xml

[Thomas Kluyver]

On 17 January 2013 20:37, westlake westlake2...@videotron.ca wrote:

   It is because of match values that there's a 2+ minute delay when
 listing filetypes(Nautilus/Dolphin, but not cli tools like mc and lynx) on
 an ssl+webdav mountpoint


I'm guessing that the delay occurs because the file manager is attempting
to open each file to check its contents for mimetype matches?

I'm inclined to say that that's an issue for the file managers, not the
MIME database. The database provides information about MIME types, but it's
up to the application how to use that. Specifically, they could:

- Detect that file operations are slow over ssl+webdav, and decide not to
examine the contents to find MIME types.
- Display the list first, and progressively update icons etc. as they
gather MIME type information.

I hope that helps,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: hi

[Thomas Kluyver]

On 15 January 2013 18:56, westlake westlake2...@videotron.ca wrote:

 Hi guys, I'm new to this list.. I would like to post an issue about a very
 serious problem I'm having it concerns

 It's about file /usr/share/mime/packages/**freedesktop.org.xml,


It could be - why don't you describe the problem in more detail. If it's
the wrong place, I'm sure someone will direct you to the right list.

You might also want to refer to the Freedesktop Mime info specification:
http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Fwd: $XDG_RUNTIME_DIR

[Thomas Kluyver]

On 5 December 2012 22:14, David Faure fa...@kde.org wrote:

 OK, so /run/user/ is a better default, when available, than /tmp, I'll
 adjust
 my code. Thanks for pointing this out, it looks like I didn't take this
 into
 account.


/run/user was created for this use, though, so systems that don't have
$XDG_RUNTIME_DIR set probably won't have /run/user. My Ubuntu 12.04
installation doesn't have either, while 12.10 does have both. And you can't
create a directory in /run, because it's not user-writable.

I went too far in one direction (fallback without warning), you're going too
 far into the other one (no fallback), I think we should both do what the
 spec
 says: fallback, with a warning :-)


I'm still not convinced that I am going too far. The runtime directory is
supposed to have a very precisely specified set of properties that
application authors can depend on. Silently (a stderr warning is all but
silent for GUI developers) falling back to a substitute that *probably*offers
*most* of the same features sounds like a recipe for hard to find bugs and
security holes. I think there's a real argument for forcing application
developers to think about the problem themselves.

Also, while it's unclear how this will be used, I'm inclined to be
conservative. If consensus develops on a suitable fallback, I can add a
wrapper function to use it. But if I provide a fallback and later decide it
was a mistake, removing it would break a lot of code.

Best wishes,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Fwd: $XDG_RUNTIME_DIR

[Thomas Kluyver]

On 5 December 2012 22:57, David Faure fa...@kde.org wrote:

 Using /tmp for user-specific session sockets is what we've been doing for
 decades, I don't think we should break apps just because the user's OS
 doesn't
 have yet the fancy new /run/user directory.


PyXDG doesn't currently have any reference to $XDG_RUNTIME_DIR, so in my
case, this is purely a new feature, and can't break existing code.
Applications that are using /tmp for similar purposes must already have
other mechanisms to do that.

I still think the basic way to get the runtime directory should raise an
error if the environment variable isn't set - after all, PyXDG is an
implementation of the spec. I might offer a wrapper function with a
strict=True/False parameter, which would fall back on /tmp/app-username.


 I have to admit, that an application aborting due to no XDG_RUNTIME_DIR is
 exactly what made ubuntu implement it...
 https://bugs.launchpad.net/ubuntu/+source/weston/+bug/1029223 pushed
 https://bugs.launchpad.net/ubuntu/+source/pam-xdg-support/+bug/894391
 to be implemented, it would seem.

 Strange that this behavior of weston didn't make debian do the same...


Well, Ubuntu is planning to make Wayland the default graphics thingy, so I
guess something that prevents Weston starting is much more pressing than it
is for Debian.

Thanks,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Fwd: $XDG_RUNTIME_DIR

[Thomas Kluyver]

On 5 December 2012 15:21, David Faure fa...@kde.org wrote:

 Not very convenient, to expect apps to implement themselves a fallback.

 In Qt, I implemented this:

 if XDG_RUNTIME_DIR isn't set, mkdir /tmp/runtime-$USER,
 then ensure that it's owned by the user (otherwise bail out),
 then chmod to 0700 (and if that fails, bail out).

 At least this makes your framework easier to use, because it returns
 something
 that works out of the box, in normal circumstances, without requiring the
 user
 or the distro to prepare the directory and set an env var...


Thanks David, that's useful perspective.

I think the reason /run/user is used is that the XDG base directories spec
requires stronger guarantees about file and directory lifetime than are
provided by /tmp:

*The lifetime of the directory MUST be bound to the user being logged in.
It MUST be created when the user first logs in and if the user fully logs
out the directory MUST be removed. If the user logs in more than once he
should get pointed to the same directory, and it is mandatory that the
directory continues to exist from his first login to his last logout on the
system, and not removed in between. Files in the directory MUST not survive
reboot or a full logout/login cycle.*

...

*If $XDG_RUNTIME_DIR is not set applications should fall back to a
replacement directory with similar capabilities and print a warning message.
*

So the question is, how similar do the capabilities need to be for a
fallback directory? And what kind of warning is needed? I can fire a
warning using Python's warnings mechanism from within the library, but in a
typical GUI application that will be completely invisible.

Providing a built-in fallback certainly makes life easier for application
developers, but it could also lead them to overlook security issues,
because the fallback doesn't have the same guarantees as $XDG_RUNTIME_DIR
should. I don't think it's possible to offer the same guarantees without
the OS managing the directory, in which case it will set the environment
variable.

Best wishes,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: $XDG_RUNTIME_DIR

[Thomas Kluyver]

On 4 December 2012 00:41, Jerome Leclanche adys...@gmail.com wrote:

 My tests are here:
 https://github.com/Adys/python-xdg/blob/master/tests/mime.py

 I strongly recommend you test for foo.c, foo.C, aliases, non-existant mime
 types, and mimetype parenting (text/x-python - text/plain)


Thanks Jerome,

I've just done all of those except for non-existent mime types. For now,
PyXDG will just let you construct a Mime type, whether or not it exists.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: volatile config data and XDG Base Directory spec

[Thomas Kluyver]

On 4 December 2012 15:35, Thomas Koch tho...@koch.ro wrote:

 Some applications store volatile config data or convenience data like:

 - last window position
 - recently opened file
 - last time application was run
 - ... you name it

 Most annoyingly these applications create config files on first run even
 if I
 won't ever run those apps again! So my home folder accumulates many
 worthless
 config files.


You could kind of call this data a cache - the user could easily move the
window to their preferred position, find a file they've recently used
again, and so on. The backup test - how much do you care if you lose it -
also suggests it could go under cache.

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Fwd: $XDG_RUNTIME_DIR

[Thomas Kluyver]

I'm thinking of adding support for $XDG_RUNTIME_DIR to PyXDG. However, I
want to check how to handle the case where it isn't set. From the spec:

*If $XDG_RUNTIME_DIR is not set applications should fall back to a
replacement directory with similar capabilities and print a warning
message. Applications should use this directory for communication and
synchronization purposes and should not place larger files in it, since it
might reside in runtime memory and cannot necessarily be swapped out to
disk.

*I've read a few discussions around Ubuntu's implementation of this, and
the consensus appears to be that there is no standard directory that will
reliably have the right properties. So, from 12.10, Ubuntu will ensure that
XDG_RUNTIME_DIR is set by default.

Therefore, my thinking is to provide no fallback, so if the environment
variable is not set, the Python variable will have a useless value too. Or,
if implemented as a function, it would raise an exception. Applications
that need to handle this case would then have to handle it themselves. Does
that sound reasonable?

Thanks,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: $XDG_RUNTIME_DIR

[Thomas Kluyver]

On 3 December 2012 21:08, Jerome Leclanche adys...@gmail.com wrote:

 However I'd be more inclined to figure out if the *spec* not providing a
 fallback is a good idea. What's wrong with assuming .local/run or something?


I think there are some security issues, although I'm not quite clear about
the details. The spec also says that the runtime directory needs to support
all Unix file-like features - named pipes, hard links, and so on. If the
user's home directory is on NFS, for example, that may not hold. My
understanding is that Ubuntu now creates an entire separate mount point (at
/run/user) to ensure the conditions are met.

Thanks,
Thomas

P.S. Jerome, I haven't forgotten your suggestion that your python-xdg
implementation should replace PyXDG. But I'm increasingly convinced that
it's important to keep the API as stable as possible. It's already used in
a lot of places, and I don't think many projects are interested in dealing
with API changes. Even the refactoring I've done has accidentally broken a
couple of things. So I've been focussing on adding tests (
http://cgit.freedesktop.org/xdg/pyxdg/tree/test ) and docs (
http://pyxdg.readthedocs.org/en/latest/index.html ). You're more than
welcome to help with that - perhaps we should merge some of the bits of
python-xdg that PyXDG doesn't yet have.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: $XDG_RUNTIME_DIR

[Thomas Kluyver]

On 3 December 2012 22:31, Jerome Leclanche adys...@gmail.com wrote:

 No worries Thomas. I'll keep python-xdg as a separate project, it's not
 bad to have an alternative. I mostly enjoy the mimetype api, for which I
 have pretty extensive tests. Feel free to look around.


Great. I haven't looked in great detail at how mime-types are implemented
in PyXDG, although I have written a few basic tests for it. If you see any
problems there (http://cgit.freedesktop.org/xdg/pyxdg/tree/xdg/Mime.py ),
let me know. I've also put a copy of the repository on Github (
https://github.com/takluyver/pyxdg ), so pull requests are welcome.

Thanks,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Fwd: Default assignee for PyXDG bugs

[Thomas Kluyver]

Hi,

I hope this is the right place to ask: can someone set me (
tho...@kluyver.me.uk) as the default assignee for bugs in the 'PyXDG'
component?

https://bugs.freedesktop.org/describecomponents.cgi?product=PyXDG

Thanks,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Could someone please help fix icewm-xdg-menu (details included).

[Thomas Kluyver]

On 4 November 2012 23:00, Sergio sergiocmailbox-freedesk...@yahoo.com.brwrote:

 icewm-xdg-menu is a python script that generates an IceWM menu file from
 freedesktop.org menu specs.
 I use Fedora 17 and recently pyxdg was updated from 0.19 to 0.23 (
 http://koji.fedoraproject.org/koji/buildinfo?buildID=362599 ) and this
 broke icewm-xdg-menu.

 The script is this: http://paste.org/56606
 The error it has with pyxdg 0.23 is this: http://paste.org/56149


Thanks again. Now I'm at my computer, here's the freedesktop bug for the
same issue:
https://bugs.freedesktop.org/show_bug.cgi?id=56426

I've just committed a test and a fix for it. I hope to make a new release
of PyXDG soon.

Best wishes,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Changes in Categories in the XDG Desktop Menu Specification

[Thomas Kluyver]

On 24 October 2012 14:04, Stanislav Brabec sbra...@suse.cz wrote:
 I am pleased to announce changes in Categories in the Desktop Menu
 Specification[1] that incorporated changes and proposals collected in
 last years in XDG list or Bugzilla.

 Please update your utilities and distribution menus to accept these new
 Categories.

I've updated PyXDG:
https://github.com/takluyver/pyxdg/commit/d7f23a55ce3bb07463f6de0289901e39b1f0265c

Are more updates likely in the near future? If not, I'll aim for a new
release soon with those changes in.

Thanks,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Changes in Categories in the XDG Desktop Menu Specification

[Thomas Kluyver]

On 24 October 2012 16:07, Vincent Untz vu...@gnome.org wrote:
 I'm not aware of any changes that might go in soon; however, someone
 might want to take a look at the bugs in bugzilla for the spec and see
 if there are some of them that we can fix (product is Specifications).

Here's the list filed against the desktop entry spec:
https://bugs.freedesktop.org/buglist.cgi?product=Specificationscomponent=desktop-entryresolution=---list_id=150898

Including the charmingly titled many aspects of human life have no
main category (https://bugs.freedesktop.org/show_bug.cgi?id=39786)

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Keyrings, redux

[Thomas Kluyver]

On 21 August 2012 03:43, Jerome Leclanche adys...@gmail.com wrote:
 Googling xdg keyring brings this up:
 http://old.nabble.com/Unifying-KWallet-Gnome-Keyring-td19098909.html

 Has there ever been any effort towards this? This is something we're
 eventually going to hit in Razor, and I'd like to work on this if needs be.
 If there hasn't, what would be a good place to start? I don't exactly want
 to alienate gnome and kde in the process.

I think this is what the 'secret storage' DBUS service is designed for:

http://freedesktop.org/wiki/Specifications/secret-storage-spec

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

PyXDG 0.20 release

[Thomas Kluyver]

I'm pleased to announce the release of PyXDG 0.20, available from:

http://people.freedesktop.org/~takluyver/pyxdg-0.20.tar.gz

The main purpose of this release is to add support for Python 3. Note
that it requires Python 2.6 or later. Various bugs have been fixed
along the way, including patches from Debian and Gentoo. A list of the
changes is here:

http://freedesktop.org/wiki/Software/pyxdg

I've CCed Paul Horn, who owns the package on PyPI. Paul, can you
upload the new version, or add me (user takowl) to the package owners
so I can upload it?

Thanks to everyone who's tested the package and helped me resurrect
the codebase. With this update done, we can aim for a more thorough
overhaul - ensuring that it implements the current version of
standards, making proper tests and simplifying the code.

Best wishes,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

PyXDG licensing

[Thomas Kluyver]

(Resending from the email address I used for this list - apologies if
you receive this twice)

To: xdg xdg@lists.freedesktop.org, docto...@gmail.com, Heinrich
Maximilian Wendel h_wen...@cojobo.net

Hi all,

The source code for PyXDG as a whole is under LGPLv2 (as per the
COPYING file and the license field in setup.py). However, xdg/Menu.py
has a GPL header.

I guess this was a simple oversight from someone whose editor used a
template for new files, but obviously I can't change it without
checking. Can anyone confirm that this was an oversight? Or if it was
deliberate, please can I relicense the file as LGPL to fit in with the
rest of PyXDG? I'd much rather not rehash the great license debate,
but I don't think that strong copyleft is the best choice for code
implementing a specification like this.

CCed Matt Owens, who's listed first in the copyright notice on that file.

Best wishes,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: PyXDG licensing

[Thomas Kluyver]

On 20 June 2012 14:11, Martin Owens docto...@gmail.com wrote:
 Yes, you have my permission. On the proviso that you read my comment
 below ;-)

Thanks, Martin. I have read it ;-)

 Actually, with this codebase, it makes no difference at all. The
 difference between LGPL and GPL for python is zero. The oversight is as
 a result of my surprise that a inapplicable license like the LGPL would
 be used for a python codebase.

Is this based on the fact that Python code can't be statically linked?
I think there's some uncertainty about this - my understanding of the
GPL is that if you distribute a package containing and importing GPLed
Python code, all of the resulting code gets GPLed, under GPL v 2
clause 2b.

Best wishes,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: PyXDG licensing

[Thomas Kluyver]

On 20 June 2012 20:34, Martin Owens docto...@gmail.com wrote:
 We're quickly going into lawyer territory.

We are rather - let's agree to disagree, and leave it to people who're
paid to think about these things. ;-)

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Fwd: PyXDG

[Thomas Kluyver]

On 18 June 2012 08:39, Vincent Untz vu...@gnome.org wrote:
 Given that it seemed nobody else was stepping up for maintainership of
 pyxdg, I think you can just trust yourself, merge the branch, do a
 release and wait for bug reports from early users ;-)

Right, I've merged in the Python 3 work, applied some patches Debian
had created, and fixed up a few other things (it was making a mess of
validating icon themes).

Allow me to present PyXDG 0.20 release candidate 1:
http://people.freedesktop.org/~takluyver/pyxdg-0.20c1.tar.gz

Please download it and test anything you think of in Python 2 or 3
(only Python = 2.6 is supported). If we haven't found any serious
problems in a week or so, I'll make a full release.

Thanks,
Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg