Re: Proposal for an intent-apps spec

[Bastien Nocera]

On Mon, 2021-05-03 at 12:13 +0200, David Faure wrote:
> On lundi 3 mai 2021 12:04:30 CEST Bastien Nocera wrote:
> > On Mon, 2021-05-03 at 11:44 +0200, David Faure wrote:
> > > Hello everyone,
> > > 
> > > I just created
> > > https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/45
> > > 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.
> > 
> > This still doesn't fix the problem of knowing _how_ to launch
> > applications in those terminals when the options are different, and
> > expect different values, which was the problem in the first place.
> 
> This is handled by the DBus interface.
> 
> It's not
> * lookup desktop file from intent
> * execute the Exec line of that desktop file, which will be like xterm
> -e..
> 
> It's
> * lookup desktop file from intent
> * start that process
> * make a DBus call to it

How do you plan on implementing that in, say, xterm, or rxvt?

Note that specs are usually only accepted when implementations already
exist for a vendor-ed version of it, or a WIP version of it.

> > Please also make a formatted version of the spec available, it's
> > easier
> > to read than docbook diffs ;)
> 
> I'm having trouble doing that. There's no discount-mkd2html
> executable on 
> binary, I found a mkd2html

This is the software:
https://github.com/Orc/discount

But this is only used for the index page, not for the specs themselves.

>  and added a symlink with that name, but I'm not 
> sure that's right. Now ./update.py (with Local=True and a line in
> specs.idx 
> pointing to HEAD)

You need to make it point to your branch. But you could also generate a
single page just for your document.

>  runs to the end but doesn't generate any HTML for the 
> spec...
> 


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

Re: Proposal for an intent-apps spec

[Bastien Nocera]

On Mon, 2021-05-03 at 11:44 +0200, David Faure wrote:
> Hello everyone,
> 
> I just created
> https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/45
> 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.

This still doesn't fix the problem of knowing _how_ to launch
applications in those terminals when the options are different, and
expect different values, which was the problem in the first place.

Listing the .desktop files which correspond to terminal emulators
wasn't really the hard part of the problem...

Please also make a formatted version of the spec available, it's easier
to read than docbook diffs ;)

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


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

Re: New `MimeType` fields in .desktop

[Bastien Nocera]

On Thu, 2021-02-18 at 02:36 +0100, Jehan Pagès wrote:

> How do we know this? Who will know this if not even you who maintain
> these files know this?

What files do I maintain? I don't maintain shared-mime-info anymore, I
maintain a single xdg spec, not the mime or desktop ones, and I don't
maintain the implementation in Qt or GLib.

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

Re: New `MimeType` fields in .desktop

[Bastien Nocera]

On Wed, 2021-02-17 at 23:02 +, Thomas Kluyver wrote:
> 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. :-/

They're identical because no one's changed the version in shared-mime-
info:
https://src.fedoraproject.org/rpms/shared-mime-info/history/mimeapps.list?identifier=rawhide

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

Re: New `MimeType` fields in .desktop

[Bastien Nocera]

On Wed, 2021-02-17 at 22:07 +0100, Jehan Pagès wrote:
> 
> There is also something which I am not fond of with the order
> depending on a shared database: we must agree on an order which might
> not be fair. Say 2 applications are on the exact same action fields,
> i.e. they both work on the same file formats (for instance JPEG, PNG
> for image viewers). If the defaults depend on this shared database,
> then the same one will consistently be the default image viewer
> shadowing (if installed) all the others. Be it based on character
> order (then you'd want to just name your app "aaa") or just whatever
> the database maintainer prefer for oneself, it's not right.

It's not a database, it's a default configuration for various desktops.
As mentioned in my previous email, it's also likely to be easily
changed in the "default applications" panel in GNOME, and equivalent
somewhere else.

> On the other hand, when no order is specified centrally, but each
> software is able to tell its intent "I'm made to display JPEG, PNG…"
> without specifying priority relatively to other software, at least we
> can go with fairer algorithm (something not based on an arbitrary
> choice making a strict order). Be it "last installed" or "keeping
> stability to whatever was here first" (then it will likely be
> dependent on your desktop choice during install, and distrib
> maintainers, at least not the same on all distributions).

The order for mime-types with no defaults has nothing to do with a
"shared database", it's implementation specific, as it's not codified
in the mime specs. GLib probably behaves differently than Qt does,
which means that the file managers using either of those are likely to
behave differently.

If you want to solve this problem, you'll probably need to figure out
whether their behaviour is intentional, and then change the specs to
clarify the intended behaviour.


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

Re: New `MimeType` fields in .desktop

[Bastien Nocera]

On Wed, 2021-02-17 at 19:26 +, Thomas Kluyver wrote:
> 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.

Not quite. There used to be only one file matching all the desktops for
the longest time, and nobody ever complained because nobody seems to
have run into the problem of launching GNOME apps on KDE because the
GNOME apps were never installed.

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

Other files in the same directory will show you how it's made.

GNOME also ships with a "default applications" settings panel which
make sure that, for example, the image viewer selected is the one that
opens all the image types it supports by default.

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

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

[Bastien Nocera]

On Sun, 2020-10-18 at 15:08 +0200, Guido Günther wrote:
> Hi Bastien,
> On Thu, Oct 15, 2020 at 02:40:50PM +0200, Bastien Nocera wrote:
> > On Fri, 2020-10-09 at 17:55 +0200, Guido Günther wrote:
> > > Hi,
> > > On Fri, Oct 09, 2020 at 05:08:10PM +0200, piegames wrote:
> > > > So the main motivation for this is to *hide elements* from the
> > > > menu? As
> > > > in, if I unplug the keyboard I cannot find some apps in the
> > > > launcher
> > > > any more? That sounds arbitrary and frustrating IMO. But I
> > > > don't
> > > > really
> > > > understand the point of this feature. What will it bring to the
> > > > users?
> > > 
> > > Not necessarily hiding permanently but rather sorting or showing
> > > with
> > > proper priority (e.g. on search).
> > > 
> > > E.g There's no point in having kicad, gimp, libreoffice,
> > > inkscape,
> > > freecad, gnumeric, ... in a prominent place on a phone when no
> > > large
> > > screen is attached. It's busywork for the user to have them sort
> > > that
> > > out
> > > by arranging apps manually when the shell can sort applications
> > > properly
> > > into a 'fits the current device mode' and 'all apps' tabs.
> > 
> > I don't see how this would be implemented. Right now, it's unclear
> > what
> > makes a phone, which peripherals need to be plugged in and enabled
> > to
> > make it not a phone anymore. Is a tablet with a keyboard a laptop?
> > Is a
> > large phone with a keyboard a laptop? Is a small tablet with a
> > mouse a
> > laptop?
> 
> If we go by device types (rather than specifying screen resolution
> and
> required/supported input hardware) we'd need clear definitions for
> all
> device types (as mentioned in
> https://lists.freedesktop.org/archives/xdg/2020-October/014404.html)
> 
> > I think that if the user installs KiCad, LibreOffice, or VSCode on
> > a
> > phone, they'll likely put it somewhere in the launchers where it
> > doesn't get in the way of their normal usage.
> 
> Given the amount of application that is not something i would like to
> do
> manually for all applications. I could imagine doing something like:
> `Adpaptive=phone;desktop;` as a *hint* to the shell/lanuncher/desktop
> environment so it can build different tabs/drawers per device type
> and
> order them accordingly based on detected hardware while what is in
> the
> appstream metadata is the detailed set of requirements.

I still think that those hints are too imprecise, which might mean that
shells can't implement it as you would expect.

Put it another way:
- KiCad, or inkscape can definitely be used on a tiny phone screen, but
require precise control. Do you expect app organisation to change based
on the availability of a mouse, pen or trackball?
- Which physical and pixel dimensions do you expect to be the boundary
between device types? How do you expect developers to be able to tell
whether their apps work on a particular type of device?

(Note that I didn't touch upon the fact that appstream and/or Flathub
have some requirements for screenshots and some other metadata that
make it unsuitable for mostly vertical phone/tablet apps)

I still think that adding specifics of hardware into the way the
applications advertise themselves is too narrow, too restrictive, and
too difficult to get wrong on the shell side of things.

I think that it might be better to augment the .desktop file with more
specific metadata, eg.
- whether an app needs precise pointer control (that would account for
touchscreen usage, as well as filtering/sorting for a11y purposes),
- whether an app is usable on a physically tiny or very large screen
and which types (from watch to ultra wide desktop monitors),
- whether an app is usable on a screen with tiny resolution (eg. usable
on a CRT, or a low-resolution phone)

I think that's more forward compatible than tagging apps today, with a
spec that refers to ever changing hardware.

Even those are complicated to pin down exactly.

I think that, to go back to the original post in the discussion, it
would be good for you to list a bunch of different apps of different
styles, and explain why you think each one would filtered, and would
appear on different devices.

Cheers

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

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

[Bastien Nocera]

On Fri, 2020-10-09 at 17:55 +0200, Guido Günther wrote:
> Hi,
> On Fri, Oct 09, 2020 at 05:08:10PM +0200, piegames wrote:
> > So the main motivation for this is to *hide elements* from the
> > menu? As
> > in, if I unplug the keyboard I cannot find some apps in the
> > launcher
> > any more? That sounds arbitrary and frustrating IMO. But I don't
> > really
> > understand the point of this feature. What will it bring to the
> > users?
> 
> Not necessarily hiding permanently but rather sorting or showing with
> proper priority (e.g. on search).
> 
> E.g There's no point in having kicad, gimp, libreoffice, inkscape,
> freecad, gnumeric, ... in a prominent place on a phone when no large
> screen is attached. It's busywork for the user to have them sort that
> out
> by arranging apps manually when the shell can sort applications
> properly
> into a 'fits the current device mode' and 'all apps' tabs.

I don't see how this would be implemented. Right now, it's unclear what
makes a phone, which peripherals need to be plugged in and enabled to
make it not a phone anymore. Is a tablet with a keyboard a laptop? Is a
large phone with a keyboard a laptop? Is a small tablet with a mouse a
laptop?

I think that if the user installs KiCad, LibreOffice, or VSCode on a
phone, they'll likely put it somewhere in the launchers where it
doesn't get in the way of their normal usage.

There's already a "control" section in appstream:
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-requires-recommends-control

Maybe that's the data you're looking for?

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

Re: Freedesktop "Recent File Storage Specification" broken by concept - what's the correct way to fix it?

[Bastien Nocera]

On Thu, 2020-09-03 at 15:30 +0100, Emmanuele Bassi wrote:
> Great! I guess I'll need to have access to the repository, then. :-)

I've updated the READMEs in the repository:
https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/34

The easiest way to contribute a spec is to create a merge request for
it. You'll need to update "specs.idx" in the web-export directory and
run "update.py" on your local machine to test out the generation of the
website.

Let me know if you run into any problems.

Cheers

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

Re: Freedesktop "Recent File Storage Specification" broken by concept - what's the correct way to fix it?

[Bastien Nocera]

On Thu, 2020-09-03 at 15:11 +0100, Emmanuele Bassi wrote:
> it was just never promoted as the actual specification, and left as a
> "draft" because of the general state of disrepair of the fd.o
> infrastructure.

I fixed the specifications website last year to be fully automated and
generated out of the CI, so no excuses ;)

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

Leaving some maintainership positions

[Bastien Nocera]

Hey,

>From today, I won't be maintaining shared-mime-info or the xdg-specs
modules anymore. I've also relinquished my mailing-list admin position
for this list.

For shared-mime-info specifically, 16 years is probably long enough to
maintain anything.

Cheers

PS: I don't intend to remove myself as a developer from the gitlab
modules for now.

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

Re: Redistribution of file URI specification

[Bastien Nocera]

On Tue, 2020-06-30 at 20:01 +, Christian Dürr wrote:
> Hello,
> 
> I'd like to redistribute the Freedesktop file-uri specification as
> part of the
> terminal working directory notification proposal
> (
> https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/7
> ),
> to prevent link rot from potentially invalidating the reference to
> the official
> resource.
> 
> Is it permitted to copy the full text of the specification and
> redistribute it
> independently? Linking to the original would probably be a good idea
> anyways, so
> if that's necessary that's not a problem.
> 
> And if this is permitted, are there any exact licensing terms that
> need to be
> followed (like providing the license together with the
> specification)?

You'll need to find the original authors so they can attach a license
to it, and you might want to migrate it to the xdg-specs repository as
well.

I don't think that including that wholesale into your specification
would be needed afterwards, but you could certainly use archive.org
URLs if you want to ensure long-term availability.

Cheers

___
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

[Bastien Nocera]

On Wed, 2020-02-26 at 15:24 +0100, Benjamin Berg wrote:
> Hi,
> 
> On Wed, 2020-02-26 at 15:14 +0100, Bastien Nocera wrote:
> > Flatpak'ed applications also use a different cache directory, like:
> > $ export | grep CACHE
> > declare -x XDG_CACHE_HOME="/home/hadess/.var/app//cache"
> > 
> > I'd say that it might better left well alone, and have something
> > like
> > Baobab better signal what each directory is/which application it
> > belongs to, to clean it up.
> 
> This specification change would only affect the $XDG_CACHE_HOME as
> set
> at login time by pam_systemd (i.e. ~/.cache).
> 
> So in principle, Flatpak'ed applications are not affected at all.
> However, the logical extension of this proposal would be that
> appropriate configurations are shipped inside each Flatpak. Then we
> also have a cleanup mechanism there that does not depend on the
> application to be run regularly.
> 
> I had not thought about that yet. I could imagine Flatpak collecting
> the information and doing the simple re-write and dropping it into
> ~/.config/tmpfiles.d or $XDG_RUNTIME_DIR/tmpfiles.d at login time.
> And
> Flatpak itself could again ship a default to clean .var/app/*/cache
> by 
> default.

In this case, an opt-in would be less surprising than an opt-out.

___
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

[Bastien Nocera]

On Wed, 2020-02-26 at 14:30 +0100, Benjamin Berg wrote:
> On Wed, 2020-02-26 at 14:22 +0100, Bastien Nocera wrote:
> > On Wed, 2020-02-26 at 13:45 +0100, Benjamin Berg wrote:
> > > Now, systemd-tempfiles can already clean up everything except for
> > > the
> > > trash. And considering that $XDG_CACHE_HOME is non-essential by
> > > definition, I think it might be sane to use systemd-tempfiles not
> > > only
> > > to clean the thumbnails but the entirety of $XDG_CACHE_HOME in
> > > the
> > > future.
> > 
> > It's not "non-essential", it's a cache, which can be regenerated,
> > but
> > it might be utterly costly to do so. Eg. there are 10 gigs of
> > "cached"
> > evolution mails in my ~/.cache, 5 gigs of jhbuild builddirs.
> > 
> > Nuking it is a last ditch scenario. You'd avoid backing it up on
> > space
> > constrained storage, but you'd want to avoid having to regenerate
> > that
> > cache in most cases.
> 
> 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.
> 
> This matches the behaviour of /tmp and /var/tmp on systemd managed
> systems. In the simplest case, all evolution needs to do is ship a
> one
> line file with:
> 
> x %C/evolution
> 
> This file can even be installed to the users $XDG_CONFIG_DIR for
> applications that might not be able to do it globally.

That sounds like a recipe for disaster, if you have an older version of
evolution and a newer version of the host OS.

Flatpak'ed applications also use a different cache directory, like:
$ export | grep CACHE
declare -x XDG_CACHE_HOME="/home/hadess/.var/app//cache"

I'd say that it might better left well alone, and have something like
Baobab better signal what each directory is/which application it
belongs to, to clean it up.

> > 
> > > Is it reasonable to standardise on the systemd tmpfiles.d format?
> > > Is it OK to clean $XDG_CACHE_HOME after a fixed time period by
> > > default?
> > 
> > I'm guessing that's a no.
> > 
> > As for thumbnails, you'd probably get away with checking whether
> > atime
> > is actually set on that mount and cleaning up the ones that haven't
> > been used.
> 
> Benjamin

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

New specifications.freedesktop.org website

[Bastien Nocera]

Hey,

https://specifications.freedesktop.org/ is now completely generated
through the CI in this repository:
https://gitlab.freedesktop.org/xdg/xdg-specs/

The Python code in the web-export directory is the one that does all
the fancy work, and you can glean information on the setup you'd need
in the .gitlab-ci.yml file at the top of the source tree.

If you find any problems, please CC: me on new issues filed at:
https://gitlab.freedesktop.org/xdg/xdg-specs/issues

Thanks to Daniel Stone for his help setting up the hosting for this.

Cheers

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

desktop-entry-spec: add PrefersDiscreteGPU entry

[Bastien Nocera]

Hey,

I've updated Jan's patch to add a PrefersDiscreteGPU key to the
desktop-entry-spec:
https://gitlab.freedesktop.org/xdg/xdg-specs/merge_requests/13

It's a standardisation of KDE's X-KDE-RunOnDiscreteGpu.

Comments on the MR would be appreciated.

As for the implementation, I'm currently wondering how to implement it
in a way that requires minimal changes, and without bringing in some
ugly code into core libraries like GLib or Qt. See:
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1804#note_631724

Cheers

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

Re: How about derivative MIME-types from "inode/directory", is it already doable?

[Bastien Nocera]

On Wed, 2019-10-23 at 20:25 +0500, Nikita Zlobin wrote:
> 

> So, my idea, is that dirs just like files (plain text) could have
> derivated types. I faced unexpected cases several times, when dir,
> clicked in fm (thunar or pcmanfm, not sure), opened instead in some
> other alternative apps (from Open With... list), such as file
> properties, baobab disk usage analyzer, and even git gui browser
> (qgit).

It's already possible, but might need a lot of patience to fix all the
assumptions that a directory is always of type inode/directory
everywhere in the stack.

Cheers

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

Moved sound-theme-spec

[Bastien Nocera]

Hey,

The sound-theme spec has been moved to the fd.o gitlab, as the updated
link here says:
https://www.freedesktop.org/wiki/Specifications/sound-theme-spec/

Thanks!

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

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

[Bastien Nocera]

On Wed, 2019-06-26 at 12:23 +0200, Egmont Koblinger wrote:
> On Wed, Jun 26, 2019 at 12:11 PM Bastien Nocera 
> wrote:
> 
> > What apps?
> 
> I've shown a link that lists a couple of useful cases. E.g. "signs
> that are considered rude in some cultures" (note that e.g. GNOME's
> foot is such an icon), icons that are preferred to be mirrored in RTL
> locales (maybe the terminal's ">_" icon one day, when generic overall
> RTL support becomes available there), icons that contain text (e.g.
> "Aa" for a font ediotr).

Nobody's used that capability in 20 years.

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

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

[Bastien Nocera]

On Wed, 2019-06-26 at 12:08 +0200, Egmont Koblinger wrote:
> What I'm the most firmly against is removing it from the spec and
> then
> looking for another workaround to resurrect the _functionality_ for
> those few apps that require it.

What apps?

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

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

[Bastien Nocera]

On Wed, 2019-06-26 at 10:10 +0200, Egmont Koblinger wrote:
> If someone does an exhaustive search, e.g. examines all the .desktop
> files of Debian and Fedora packages, plus tons of 3rd party ones
> (skype, vmware, steam games, etc.), and concludes that localized Icon
> is so extremely rare and unimportant in those cases that is okay to
> remove its translatability with no intent of providing a workaround,
> I
> don't mind.

Those are the uses in Debian:
https://codesearch.debian.net/search?q=Icon%5C%5B%5B%5B%3Aalpha%3A%5D%5D%2B%5C%5D%3D

Most of those are translations that don't need to exist:
https://sources.debian.org/src/knewstuff/5.54.0-2/data/kmoretools-desktopfiles/org.gnome.clocks.desktop/?hl=263#L225
https://sources.debian.org/src/calamares/3.2.4-4/calamares.desktop/?hl=177#L177

Actual bugs where a translator translated the icon name (in fact, most
of razorqt's entries are broken):
https://sources.debian.org/src/razorqt/0.5.2-4/razorqt-config/src/translations/razor-config_gl.desktop/?hl=19#L19
https://sources.debian.org/src/razorqt/0.5.2-4/razorqt-config/src/translations/razor-config_ru.desktop/?hl=19#L19
https://sources.debian.org/src/qt5ct/0.37-1/src/qt5ct/desktop-translations/qt5ct_cs.desktop.in/?hl=37#L37

Spec that will need updating:
https://codesearch.debian.net/search?q=Icon%5C%5B%5B%5B%3Aalpha%3A%5D%5D%2B%5C%5D%3D+package%3A%5CQkde4libs%5CE

So it's fair to say that nobody uses it correctly, and then barely
anyone uses it. At this point, I think the onus would be on you to show
that it's useful, if you wanted to keep it despite the problems it
causes translators.

Let's remove it.

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

Re: DBus signal to disable reminders/notifications

[Bastien Nocera]

On Tue, 2018-12-18 at 22:21 +0100, David Faure wrote:
> Hello,
> 
> Is there some spec that would allow to implement a desktop-wide
> signal in 
> order to disable things like calendar reminders, chat notifications,
> new email 
> notifications etc. during a presentation?
> 
> Calligra Stage, LibreOffice Impress and other presentation software
> could emit 
> a dbus signal when starting/stopping a presentation, and
> calendar/email 
> software would listen to that and disable/enable
> reminders/notifications.
> 
> I give professional trainings and give talks at conferences, and it's
> annoying 
> or even embarrassing when (recurring) calendar reminders pop up.
> Imagine if one said "It's time to take one of those anti-baldness
> pills" :-)

There's already an inhibition API for the screensaver which could be
extended:
https://specifications.freedesktop.org/idle-inhibit-spec/latest/

GNOME/GTK has an implementation for other inhibition reasons, which are
implemented in GTK (client-side) and gnome-session (server-side):
https://developer.gnome.org/gtk3/stable/GtkApplication.html#gtk-application-inhibit
https://developer.gnome.org/gtk3/stable/GtkApplication.html#GtkApplicationInhibitFlags

Full disclosure, I'm listed as one of the authors of US Patent
US8881065B2 which is relevant. It's held by Red Hat and is free for any
Open Source/Free Software to use[1].

Cheers

[1]: https://www.redhat.com/en/about/patent-promise

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

Re: A path to xdg-utils2 in python

[Bastien Nocera]

On Fri, 2019-03-01 at 19:11 +1030, Simon Lees wrote:
> 
> On 28/02/2019 20:36, Bastien Nocera wrote:
> > Hey,
> > 
> > While I share your hate for the xdg-utils codebase, a couple of
> > comments below.
> > 
> > > Stage 1: Implement regression tests for the existing xdg-utils in
> > > openSUSE's openqa instance, openqa.opensuse.org there is already
> > > general
> > > testing for most desktops here but i'm planning to extend these
> > > tests
> > > with more xdg-utils specific tests.
> > 
> > The freedesktop.org GitLab has a CI, you should add and run the
> > tests
> > upstream, against the current implementation, if you want to be
> > sure to
> > minimise the behavioural differences.
> > 
> 
> I still plan to use the current CI tests but I see them being rather 
> limited compared to the system level testing I can do in openqa which is 
> far more useful. For example across 4-5 different desktops I can call 
> xdg-terminal and check that the same terminal is launched, or can check 
> that the right authenticator is used for xdg-su and that authentication 
> succeeds or fails as it should. It can also do things like

Like what?

You can run OpenQA in the upstream CI as well.

> > > Stage 2: SUSE has a hackweek (https://hackweek.suse.com) once a
> > > year
> > > where SUSE employees get a week to work on whatever they feel
> > > like.
> > > The
> > > dates for this years have not been announced yet but my plan is
> > > to
> > > spend
> > > most of that week doing the bulk of the rewrite.
> > 
> > You're probably underestimating the amount of work required.
> 
> Well whenever the week comes I will already have a plan and
> everything 
> layed out and i'll know what I can pull in from existing python 
> libraries. So I should be able to just sit down and write. Many of
> the 
> tools are pretty simple although they have alot of boilerplate code
> and 
> the complicated stuff which is the desktop and mime handling will 
> hopefully mostly be coming from another already written library.
> 
> I'm not aiming to get everything done in that week but i'd like to
> get 
> it to a point where the framework is there so I or other people can
> grab 
> and do a small chunk thats still missing.
> > > Stage 3: Spend 2 hrs a week implementing the remaining code.
> > > 
> > > Stage 4: Submit a "beta" version into openSUSE Tumbleweed, given
> > > there
> > > will already be regression tests in openqa by the point its
> > > accepted
> > > I
> > > should be pretty confident that most of the major issues should
> > > have
> > > been found and fixed.
> > > 
> > > Design:
> > > 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.
> > 
> > For what it's worth, there's also an implementation for the
> > .desktop
> > and mime handling available in GLib, some of which are available
> > through "gio mime" or "gio open". Those APIs are also usable from
> > Python through gobject-introspection.
> > 
> > The current xdg-utils are unusable inside a sandbox, which is why
> > xdg-
> > open and xdg-email were replaced by portal clients:
> > https://github.com/flatpak/flatpak-xdg-utils/tree/master/src
> > 
> > This might be something to keep in mind.
> > 
> > The other thing to keep in mind is all the tools in this list that
> > aren't xdg-email or xdg-open still need to be reimplemented, or at
> > least assessed.
> > 
> > You can use Debian's codesearch to find some of the uses:
> > https://codesearch.debian.net/search?q=xdg-desktop-icon=1
> > 
> > My own assessment would be:
> > $ rpm -ql xdg-utils | grep bin
> > # There are better installation methods than this, remove
> > /usr/bin/xdg-desktop-icon
> > /usr/bin/xdg-desktop-menu
> > /usr/bin/xdg-icon-resource
> > # Replace
> > /usr/bin/xdg-email
> > /usr/bin/xdg-open
> > /usr/bin/xdg-mime
> > # Only works with X11, nuke
> > /usr/bin/xdg-screensaver
> > # Does the same thing as xdg-mime for x-scheme-handler,
> > # remove, or replace with xdg-mime code
> > /usr/bin/xdg-settings
> > 
> > Whether with my Fedora, Flatpak, or GNOME hat on, my course of
> > action
> > would be to extend the above mentioned "flatpak" versions (xdg-
> > email
> > and xdg-op

Re: A path to xdg-utils2 in python

[Bastien Nocera]

Hey,

On Thu, 2019-02-28 at 10:38 +1030, Simon Lees wrote:
> Hi,
> 
> For those who don't know me, I am currently the xdg-utils maintainer
> for 
> SUSE / openSUSE.
> 
> Given that SUSE is in a year where where SUSE doesn't have any major 
> releases scheduled I have a bit of extra time, I am also sick of
> fixing 
> errors with desktop file / mime handling in posix shell. People on
> this 
> list have in the past discussed the idea of rewriting xdg-utils in 
> python oneday if someone has the time, I asked my manager nicely and
> I 
> now have the time. As such i've developed the very rough plan below
> that 
> i'll work on carrying out if there's a general consensus here that
> its a 
> sensible way forward. I have been allocated a couple of hours a week
> to 
> work on this.

While I share your hate for the xdg-utils codebase, a couple of
comments below.

> Stage 1: Implement regression tests for the existing xdg-utils in 
> openSUSE's openqa instance, openqa.opensuse.org there is already
> general 
> testing for most desktops here but i'm planning to extend these
> tests 
> with more xdg-utils specific tests.

The freedesktop.org GitLab has a CI, you should add and run the tests
upstream, against the current implementation, if you want to be sure to
minimise the behavioural differences.

dbusmock is a very useful tool to use if you want to implement the
server-side of some of the tools for testing.

> Stage 2: SUSE has a hackweek (https://hackweek.suse.com) once a year 
> where SUSE employees get a week to work on whatever they feel like.
> The 
> dates for this years have not been announced yet but my plan is to
> spend 
> most of that week doing the bulk of the rewrite.

You're probably underestimating the amount of work required.

> Stage 3: Spend 2 hrs a week implementing the remaining code.
> 
> Stage 4: Submit a "beta" version into openSUSE Tumbleweed, given
> there 
> will already be regression tests in openqa by the point its accepted
> I 
> should be pretty confident that most of the major issues should have 
> been found and fixed.
> 
> Design:
> 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.

For what it's worth, there's also an implementation for the .desktop
and mime handling available in GLib, some of which are available
through "gio mime" or "gio open". Those APIs are also usable from
Python through gobject-introspection.

The current xdg-utils are unusable inside a sandbox, which is why xdg-
open and xdg-email were replaced by portal clients:
https://github.com/flatpak/flatpak-xdg-utils/tree/master/src

This might be something to keep in mind.

The other thing to keep in mind is all the tools in this list that
aren't xdg-email or xdg-open still need to be reimplemented, or at
least assessed.

You can use Debian's codesearch to find some of the uses:
https://codesearch.debian.net/search?q=xdg-desktop-icon=1

My own assessment would be:
$ rpm -ql xdg-utils | grep bin
# There are better installation methods than this, remove
/usr/bin/xdg-desktop-icon
/usr/bin/xdg-desktop-menu
/usr/bin/xdg-icon-resource
# Replace
/usr/bin/xdg-email
/usr/bin/xdg-open
/usr/bin/xdg-mime
# Only works with X11, nuke
/usr/bin/xdg-screensaver
# Does the same thing as xdg-mime for x-scheme-handler,
# remove, or replace with xdg-mime code
/usr/bin/xdg-settings

Whether with my Fedora, Flatpak, or GNOME hat on, my course of action
would be to extend the above mentioned "flatpak" versions (xdg-email
and xdg-open) to work outside the sandbox, and add an xdg-mime
implementation. And have that replace the upstream xdg-utils.

Cheers

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

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

[Bastien Nocera]

On Sun, 2018-09-09 at 21:08 -0400, Jeremy Bicha wrote:
> Originally, the desktop-entry-spec set the Icon field as "string". It
> was changed in 2006 to "localestring" which means it is translatable.
> 
> Recently in GNOME, many projects have switched from intltool to
> gettext. gettext treats the Icon field as a translatable string
> without a way for projects to disable that. In GNOME, we include a
> comment to warn translators not to translate the Icon field but
> translators sometimes don't see the comment. That causes breakage
> because no one is providing translated icons here.
> 
> Could we please change the Icon field back to "string"?

There are a number of such strings marked as translatable that
translators don't take enough care to translate. For example, the
RTL/LTR "translations", or calendar default settings in GTK+.

This problem would be better fixed with tools that would allow checking
for the validity of translations.

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

Re: AW: Seeking Bug analysis assistance for systemd

[Bastien Nocera]

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

This isn't the mailing-list for systemd. The mailing-list information
for systemd is here:
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

But even that list cannot cannot substitute itself for the support
you're supposed to be getting from your vendor. I would advise you to
contact your vendor's support first.

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

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

[Bastien Nocera]

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

This isn't how copyright works, sorry.

If you think those 2 sentences are trivial, replace them. You now have
copyright on those. If you think that some contribution is trivial
(say, a typo fix), you need to show that it is trivial and therefore
that there's no copyright claim for that change.

Even assuming good faith, relicensing people's work when you've failed
to contact them isn't how relicensing works. It might be how you
protect yourself in court though...

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

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

[Bastien Nocera]

On Fri, 2018-04-13 at 11:11 +0200, Daniel Stone wrote:
> 

> > It would be great if anyone could help me get into contact with the
> > original
> > author of https://www.freedesktop.org/wiki/Specifications/file-mana
> > ger-interface
> > . Besides, I believe setting up a default license for
> > freedesktop.org contents
> > should be of higher priority given freedesktop.org's fame and
> > importance in
> > FLOSS world.
> 
> I've CCed the two people who I believe wrote the content originally,
> who can answer for the spec. They could assign a licence to it and
> perhaps move it to the specifications repo as well.

I've never touched this, sorry.
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: DBus interface for meeting creation

[Bastien Nocera]

On Tue, 2018-03-13 at 13:11 +, David Woodhouse wrote:
> As part of a conference protocol plugin for Pidgin (like the one for
> Lync), we have the ability to create meetings.
> 
> We need to spawn a "new meeting" editor in the client of the user's
> choice, pre-populated with meeting dial-in information, conference-
> specific attendees, etc.
> 
> I've implemented a plugin for Evolution which supports this:
> 
> dbus-send --print-reply --dest=im.pidgin.event_editor \
>/im/pidgin/event_editor im.pidgin.event_editor.CreateEvent \
>string:"Organizer " \
>string:"Meeting summary" \
>string:"Meeting location" \
>string:"Meeting description" \
>array:string:attend...@example.org,attend...@example.org
> 
> Right now I'm shipping that Evolution plugin as part of my own code
> base, but I think it makes most sense to standardise the DBus API and
> split it out. Then it can be implemented in other calendar
> applications, and used from other places (like the Lync plugin for
> Pidgin, at least).
> 
> Does it make sense for this to be a fd.o specification?

What about passing this as a URI? There might even be an existing, and
probably underused, RFC for it.
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Adding an Accessibility Category to the Desktop Menu Specification?

[Bastien Nocera]

On Mon, 2016-05-23 at 10:58 +0200, Samuel Thibault wrote:
> Hello,
> 
> We need a place for people to find accessibility helpers such as
> screen
> readers, magnifiers, etc. Hiding them into "Settings", "System", or
> "Utility" does not seem appropriate to me, it makes them not easily
> accessible (sic).

In GNOME, the "universal access" settings are listed in the search
results, along with keywords like screen readers, etc.

We also prefer to have any accessibility utilities integrated directly
in the Settings panel, instead of launching separate applications. This
is the reason why we removed the orca launcher in GNOME now.

> The desktops which care about accessibility have a dedicated
> "Accessibility" menu, so it seems reasonable to me that the Desktop
> Menu
> Specification follows this trend.

GNOME doesn't even have sub menus.
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Extending xdg-user-dirs

[Bastien Nocera]

On Thu, 2016-03-10 at 13:55 -0800, Cosimo Cecchi wrote:
> Hey Bastien,
> 
> On Wed, Mar 9, 2016 at 2:06 AM, Bastien Nocera <had...@hadess.net>
> wrote:
> > I commented on the xdg-user-dirs patches. It's mostly fine, but
> > still
> > has the same problem as the first set of patches, which is going to
> > be
> > about organising conflicts between applications.
> Thanks for the comments; I am a bit unclear how you would like to see
> the current patchset change to address that.
> Could you give me an example? I thought I implemented the suggestion
> from your initial mail.
> 
> > A couple of things that I'd like before merging all this:
> > - verify that transifex or another system is in place to update and
> > be
> > reactive to new translations
> I see translation commits in master, so I was assuming this worked
> already.

I have no idea how Alex dealt with it.

> Is there anything in my patchset you think would result in a change
> in that regard?

No, the patchset is fine. I'm just concerned about translations not
getting updated in a timely manner, or the same problem for patches for
adding new sub-user-dirs.

> > - a test suite, verifying that files get moved properly, get
> > renamed,
> > etc. as expected.
> Definitely; this is something I wanted too and I will work on it
> next.

Right, it's a bit difficult to see whether there are bugs in your
patchset without a test suite, as the changes are quite invasive.

> > Other than that, I'm happy with the changes, even if the man pages
> > are
> > still on the short side to me.
> OK, I will try to expand that too.
> 
> Either way, since the patchset is pretty large as it is, I'd love to
> be able to merge the refactors/GLib port without the new user
> directories feature in the meantime. 

Right. As mentioned, I'd really like to see at least a basic test suite
before doing that, as the GLib port is the part of the patchset that's
most likely to have bugs in it.

> Another thing that would greatly benefit the code is porting it to
> GIO. I initially didn't do that to reduce the churn and introduce a
> dependency on GObject, but in retrospect I don't see why not -
> practically speaking everyone shipping GLib already also ships
> GObject/GIO.
> 
> What do you think?

I personally wouldn't mind, but bear in mind that you'll likely want to
disable the gvfs extension point to avoid possible races/hangs waiting
for the gvfs service on session startup.

Again, easier to review and ack with a test suite.

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

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

[Bastien Nocera]

On Sat, 2015-11-21 at 23:34 +0100, Michal Suchanek wrote:
> On 20 November 2015 at 22:01, Jasper St. Pierre  t> 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".
> 
> One thing is to trust the sandboxing and another is to trust the
> application to work in a sandbox reasonably well.
> 
> If I install abiword in a sandbox I cannot edit my word files,
> obviously. I have to give it access to my word files to be of any
> use.
> Which in present day is only accomplished by installing it on my
> desktop machine directly.
> 
> This can be solved to some extent by modification to the GTK library
> so that calling the function that normally pops up file open dialog
> actually calls into the sandboxing framework to import a file into
> the
> sandbox. And depending on the policy the file would be trashed after
> the application terminates, or copied as new version, or updated
> in-place.

This is getting fixed by using "Portals" in xdg-app, and is the reason
why native file choosers are getting implemented in GTK+:
https://blogs.gnome.org/alexl/2015/11/05/native-file-choosers-in-gtk/

> This won't work with libreoffice or firefox, unfortunately. They use
> their own file open dialog and not the stock one.

Both are getting ported to GTK3, so they could use the above work
without much changes.

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

Re: Spec to define the default terminal?

[Bastien Nocera]

On Wed, 2015-10-21 at 19:30 +0200, Per Olofsson wrote:
> On 2015-10-20 15:10, Bastien Nocera wrote:
> > > Apparently GNOME removed the UI for choosing terminal so you have
> > > to
> > > use 
> > > the gsettings command to change it.
> > 
> > No, it doesn't have anything to change it because nobody who might
> > care
> > has made the changes:
> > https://bugzilla.gnome.org/show_bug.cgi?id=627943
> 
> I believe GNOME 2 had a UI for choosing the terminal emulator. But I
> guess the settings UI was completely rewritten in GNOME 3. Sorry.
> 
> > > I was sceptical at first but now I think it might be a good idea,
> > > although strictly speaking it is an abuse of MIME types. It is
> > > similar 
> > > to how URIs are handled, with x-scheme-handler/.
> > 
> > Not really. See the bug above.
> 
> I can't find any argument in the bug report for why having a MIME
> type
> for terminals would be more wrong than x-scheme-handler. Only you
> stating so :-)

Both mime-type and scheme are metadata to the URL. I'd be fine having a
"x-scheme-handler/terminal" mime-type added if they could all handle
those URLs. They can't though.

> But you're right, it is more of a stretch. At least x-scheme-handler
> is
> about applications opening stuff.
> 
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Spec to define the default terminal?

[Bastien Nocera]

On Tue, 2015-10-20 at 14:57 +0200, Per Olofsson wrote:
> 

> > - not sure what desktop environments are doing in their code base,
> > maybe
> > hardcoding their own terminals
> 
> Many use gsettings or config files.
> 
> Apparently GNOME removed the UI for choosing terminal so you have to
> use 
> the gsettings command to change it.

No, it doesn't have anything to change it because nobody who might care
has made the changes:
https://bugzilla.gnome.org/show_bug.cgi?id=627943


> > 3). invent a mimetype for terminal applications so available
> > terminals
> > can be iterated via .desktop files and a default can be requested
> > in the
> > mimeapps.list file, e.g.:
> > 
> >  [Desktop Entry]
> >  name=terminator
> >  GenericName=X Terminal Emulator
> >  Exec=terminator -x %F
> >  MimeType=x-terminal-emulator
> 
> I was sceptical at first but now I think it might be a good idea, 
> although strictly speaking it is an abuse of MIME types. It is
> similar 
> to how URIs are handled, with x-scheme-handler/.

Not really. See the bug above.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: freedesktop.org get off the air

[Bastien Nocera]

On Fri, 2015-10-02 at 23:25 +0200, noi...@a6.25u.com wrote:
> On 10/02/15 21:59, Reuben Thomas wrote:
> > Hi,
> > 
> > as a user who became irritated with some aspects of some
> > freedesktop.org
> > code, I got involved and was able to fix some of those irritations.
> > 
> > Non-specific criticism is irrational: it won't help you, and it
> > will only
> > annoy or demoralize contributors.
> 
> My criticism is regarding the treatment of Unix philosophies (1) at 
> freedesktop and Lennart Poettering.
> 
> I would love to punch a second asshole into that mans face..

You've been barred.

Go away.

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

Re: Debugging xdg-open

[Bastien Nocera]

Hey,

On Sat, 2015-04-25 at 12:09 +0200, Felix Natter wrote:
 hello,
 
 I am the author of a freeplane debian package, and the problem is 
 that
 for a user, it runs successfully from a terminal, but not from a file
 manager (rightclick-run_as I think).
 
 Now I would like to debug this (possibly using xdg-open):
 
 - $ file bugreports.mm 
   bugreports.mm: Freeplane document
 
 - $ xdg-open bugreports.mm 
 Opening bugreports.mm with LibreOffice Writer  (text/x-troff-mm)
 (even though Freeplane is listed first in right-click dialog in
  nautilus)

It's likely that whatever xdg-open uses to check the mime-type doesn't 
check the magic of the file, and falls back to using the suffix.

 -- Is there another way to debug this? Will Terminal=true in a
 desktop file work? Do I need to run a command after I modify
 /usr/share/applications/freeplane.desktop?

sh -x xdg-open bugreports.mm
will show you what actual command it's using to detect the mime-type, 
which is desktop dependent.

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

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

[Bastien Nocera]

On Mon, 2015-02-16 at 10:26 -0800, Jasper St. Pierre wrote:
 
 
 On Mon, Feb 16, 2015 at 10:18 AM, Bastien Nocera had...@hadess.net
 wrote:
 On Mon, 2015-02-16 at 10:03 -0800, Jasper St. Pierre wrote:
  Jon had multiple reasons:
 
 
  1. The main use for a counter like is Unread Emails, a
 number that's
  particularly high for Jon that he didn't think it would be
 too useful.
  Notifications should be about the
 
 About the?
 
 
 Sorry. Notifications should be about the now.
snip
 Then why is it part of the notification? If I have broadcast a new
 notification with a new badge-number hint, does that replace the old
 one? What if I remove the notification with that hint? What do we
 display then?

You're confusing the protocol with the UI. If I underspec'ed the
changes, I'm more than happy to talk about that, rather than having to
justify why it's needed.

 Note that we replaced the FDO Notifications spec with a semi-private
 API when we introduced GNotification. Ryan was planning to standardize
 that API, so you should talk to him about it.

Until that's done, I consider it an implementation detail.

Cheers


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

Re: [PATCH] desktop entry spec: Add UsesNotifications key

[Bastien Nocera]

On Wed, 2015-02-04 at 06:39 -0500, Ryan Lortie wrote:
 hi,
 
 On Wed, Feb 4, 2015, at 06:21, Bastien Nocera wrote:
  Huh? Are we talking about the same spec[1] that already exists and you
  implemented, and that we're discussing on xdg@lists.freedesktop.org?
  [1]:
  https://people.gnome.org/~mccann/docs/notification-spec/notification-spec-latest.html
 
 Yes and no.  The linked spec is not the one that I that I had any
 involvement in at all.
 
 The one that we created recently is not (yet) a freedesktop spec.  It
 uses org.gtk.Notifications.
 
 org.freedesktop.Notifications is
 https://developer.gnome.org/notification-spec/ (for which the canonical
 version is apparently in Jon's homedir -- the one you link above).  I've
 never had any involvement at all with this spec.

The canonical version is in libnotify's git tree:
https://git.gnome.org/browse/libnotify/tree/docs/notification-spec.xml

 GNotification will use one or the other, depending on what is
 implemented by the system.

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

[PATCH notification] spec: Add badge-number hint

[Bastien Nocera]

As discussed during the Wayland meeting at FOSDEM 2015.
---
 docs/notification-spec.xml | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/docs/notification-spec.xml b/docs/notification-spec.xml
index fa1da0b..3bc0292 100644
--- a/docs/notification-spec.xml
+++ b/docs/notification-spec.xml
@@ -3,8 +3,8 @@
 article id=index
  articleinfo
   titleDesktop Notifications Specification/title
-  releaseinfoVersion 1.2/releaseinfo
-  date28 October 2010/date
+  releaseinfoVersion 1.3/releaseinfo
+  date16 February 2015/date
   authorgroup
author
 firstnameMike/firstname
@@ -674,6 +674,19 @@
   entrygt;= 1.2/entry
  /row
  row
+  entryliteralbadge-number/literal/entry
+  entryINT32/entry
+  entry
+When set, a server can use it to show the number attached to
+the notification on top of the application icon referenced by the
+desktop-entry hint.
+Note that servers can choose not to show the number, either because
+they do not implement the capability, or in response to user
+configuration to suppress its display.
+  /entry
+  entrygt;= 1.3/entry
+ /row
+ row
   entryliteralcategory/literal/entry
   entrySTRING/entry
   entry


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

Re: [PATCH] desktop entry spec: Add UsesNotifications key

[Bastien Nocera]

On Wed, 2015-02-04 at 05:39 -0500, Ryan Lortie wrote:
 hi Bastien,
 
 On Wed, Feb 4, 2015, at 05:23, Bastien Nocera wrote:
  +Whether the program makes use of desktop notifications. This
  is used to pre-populate
  +notification configuration interfaces.
 
 I don't agree with this patch.
 
 If you want to do this, please invent an interface name and use
 Implements=.  It was invented precisely for this sort of thing.  That
 way you can even use g_desktop_app_info_get_implementations() to list
 off all the apps in question.

Sure, org.freedesktop.Notifications then?

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

Re: New default dirs: Books and Audiobooks

[Bastien Nocera]

Hey Torben,

On Thu, 2014-08-28 at 07:08 +, Torben Andresen wrote:
 Hi,
 
 more and more user have eBooks and Audiobooks on their Computers.  
 There are also software for these files like Calibre or Gnome-Books  
 and so on. So maybe it would be a good idea to implement two new  
 default dirs: Books and Audiobooks. Why Audiobooks? I think that most  
 people don't want their music and audiobooks mixed. Is it possible to  
 implement these both dirs als default dirs?

I think that Cosimo's suggestion from a couple of months ago solves that
problem, without the need to add more top-level items.

See:
http://thread.gmane.org/gmane.comp.freedesktop.xdg/13791/

Cheers

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

Re: handling optional MimeTypes in a Desktop Entry

[Bastien Nocera]

On Fri, 2014-05-02 at 12:16 -0500, Ted Gould wrote:
 On Wed, 2014-04-30 at 11:38 +0200, Bastien Nocera wrote: 
  On Wed, 2014-04-30 at 05:23 -0400, Ryan Lortie wrote:
   On Thu, Apr 24, 2014, at 13:50, François Cami wrote:
I've read the Desktop Entry Specification at
http://standards.freedesktop.org/desktop-entry-spec/latest/index.html
and haven't found an answer to my problem, so here goes:
   
   I'm not sure any of these options will really work.
   
   In the simple case of applications with plugins one of these options
   might be acceptable, but consider the case that we have something like
   Totem using GStreamer.  When I install a GStreamer plugin, how should it
   know about Totem existing in order to update its list?
   
   The only thing I can think of is that we have some mime type to mean
   all of the types of things supported by GStreamer (where GStreamer
   could also be the name of an individual application, in the case of
   direct plugins).  It might make sense to also say all of the _audio_
   file types supported by GStreamer as well.
   
   I'm not really sure what this would look like, and I'm also not sure if
   I would be in favour of the final result.  This is a tough problem and
   I'm not sure that any solution is palatable.
  
  For the GStreamer case, I should add that:
  - GStreamer doesn't really support mime-types. At best, you would know
  that you have a plugin to handle the container type (AVI, MPEG-4, MKV).
  - Using GStreamer's automatic codec installers requires _all_ the
  possibly supported types to be listed in the desktop file.
 
 We're not using desktop files for this on Ubuntu, but content hub
 registrations. What we decided for the GStreamer case is to have a key
 that was I use GStreamer so then the hub could be smart enough to
 look at GStreamer and turn those into types that can be supported.
 Allows for support of proprietary protocols on devices that have
 licenses (and plugins) that support them.

Again, that's a static case. That doesn't allow for searching for
3rd-party plugins that could implement playing such codecs. This is
probably fine if you don't have support for adding new plugins, or if
the list of plugins is finite.

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

Re: handling optional MimeTypes in a Desktop Entry

[Bastien Nocera]

On Wed, 2014-04-30 at 05:23 -0400, Ryan Lortie wrote:
 hi,
 
 On Thu, Apr 24, 2014, at 13:50, François Cami wrote:
  I've read the Desktop Entry Specification at
  http://standards.freedesktop.org/desktop-entry-spec/latest/index.html
  and haven't found an answer to my problem, so here goes:
 
 I'm not sure any of these options will really work.
 
 In the simple case of applications with plugins one of these options
 might be acceptable, but consider the case that we have something like
 Totem using GStreamer.  When I install a GStreamer plugin, how should it
 know about Totem existing in order to update its list?
 
 The only thing I can think of is that we have some mime type to mean
 all of the types of things supported by GStreamer (where GStreamer
 could also be the name of an individual application, in the case of
 direct plugins).  It might make sense to also say all of the _audio_
 file types supported by GStreamer as well.
 
 I'm not really sure what this would look like, and I'm also not sure if
 I would be in favour of the final result.  This is a tough problem and
 I'm not sure that any solution is palatable.

For the GStreamer case, I should add that:
- GStreamer doesn't really support mime-types. At best, you would know
that you have a plugin to handle the container type (AVI, MPEG-4, MKV).
- Using GStreamer's automatic codec installers requires _all_ the
possibly supported types to be listed in the desktop file.

Cheers

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

Re: mime apps specification

[Bastien Nocera]

On Sat, 2014-04-05 at 15:04 -0400, Jasper St. Pierre wrote:
 No idea how DPNH got there. Cat on a keyboard or something.
 
 
 RealPlayer was an app known for making terrible forceful
 customizations to the user's system on Windows. If you deleted the
 Start Menu, Desktop, or Quick Launch shortcut and ran RealPlayer, it
 would notice and re-add all the shortcuts. If it wasn't the default
 MIME handler, it would silently reregister itself for all media types
 it supported.
 
 
 Having an official way to do this is a way to tell ISVs that they
 *should* do this,

We also have official ways to delete every user owned files...

  that it's recommended practice if you have an app that handles a MIME
 type. Apps that want to force their way into the user's customizations
 are RealPlayer, and we should let them feel shameful hacking
 up /usr/share/applications/mimeapps.list on install, and bare the
 responsibility if it breaks, not give them an API for it.

This is silly. In the long run, those files won't be accessible to
applications. Right now, applications can already set themselves as the
default application for each user when they're run, it was simply
implemented in desktop/toolkit-specific ways.


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

Re: cursor spec

[Bastien Nocera]

On Sun, 2014-04-06 at 19:35 +0200, Philipp A. wrote:
 hi people,
 
 
 how about adding zoom-in and zoom-out to the cursor spec? (I’d guess
 “nice-to-have” section)
 
 http://www.freedesktop.org/wiki/Specifications/cursor-spec/

Are there implementations already using this?

We'd be happy having this added in GNOME.

Cheers

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

Re: Extending xdg-user-dirs

[Bastien Nocera]

Hey,

On Mon, 2014-03-03 at 16:42 -0800, Cosimo Cecchi wrote:
 Hi all,
snip

This diff to the spec isn't very clear:
https://github.com/cosimoc/xdg-user-dirs/commit/29c89e42ec784fd00075b44cdfa459de7aecb1a9

It's really not very clear that the extension files are in a
sub-directory.

snip

 Use cases:
 * An application (e.g. a sound recorder) wants to save a file
 in a subdirectory of $XDG_MUSIC_DIR. Another sound recorder
 wants to save files in the same subdirectory, and doesn't want
 to worry about the translations for each language to be in
 sync.

How can sound recorder #2 rely on #1 being present, and having installed
the directory file with the right name? Should common directories be
shipped in xdg-users-dir?

 
 * A photo booth application wants to save pictures to a webcam
 snaps subdirectory of $XDG_PICTURES_DIR. An user properties
 settings panel in the desktop environment allows to pick an
 avatar picture through a file chooser, which should default to
 the webcam snaps place.
 
 
 There's a bunch of similar cases, which you can find in this
 bug [1] where this message originates from.

The original bug is about backgrounds and discussing it with David Faure
and Ryan, we wondered what would happen if the KDE wallpaper panel was
to make it create a ~/Pictures/Wallpapers and the GNOME one made it
create a ~/Pictures/Backgrounds?

How do we avoid the directories being filled up with gunk from running
different desktop environments, or, if we use the same file shipped by
xdg-users-dir, do we decide whether it should be called Backgrounds or
Wallpapers?

We think that, to avoid inter-application dependency, and cluttering
those top-level dirs with more slightly different versions of the same
directory, we should ship the most common directories in xdg-users-dir
directly.

I hope this is clear enough so we can carry the discussion forward a
little.

Cheers


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

Re: Draft of proposed new XDG Desktop Application Autostart Spec

[Bastien Nocera]

On Mon, 2014-03-17 at 21:04 -0400, Mark Edgington wrote:
 Hello everyone,
 
 In an effort to rectify some of the issues which the current Desktop
 Application Autostart Specification has, I've drafted an updated
 version of this spec that includes some new keys which I think should
 make the spec a bit cleaner and easier to implement in a way where
 different sessions / desktop-environments are able to be decoupled
 from each other.  I welcome any comments and criticism!  Also, feel
 free to fork the spec and make any modifications you would see as a
 way of improving it.
 
 One of the big issues, of course, is how you go about changing a spec
 that is already at least in large part being supported by different
 desktop-environments.  If you take a look, I haven't changed the spec
 very much, but rather have deprecated certain keys, and introduced new
 keys to replace their functionality.  If a desktop-environment is able
 to understand the new keys, then it should use them, whereas if it
 can't, it can still rely on the old deprecated keys.
 
 The (dynamically updated) latest version of the proposed spec is located at:
 
 
 https://bitbucket.org/edgimar/xdg_autostart_spec/src/tip/xdg_autostart_spec.md

Do you have a diff so we can see what's actually change?

Cheers

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

Re: expanding the inhibit spec

[Bastien Nocera]

On Wed, 2014-01-22 at 10:10 +0100, Michal Suchanek wrote:
 On 21 January 2014 08:09, Bastien Nocera had...@hadess.net wrote:
  On Sat, 2014-01-18 at 12:23 +0100, Michal Suchanek wrote:
  Hello,
 
  there is some problem with the archives so I can't read the whole
  thread about this.
 
  From the existing API I can see three things that are inhibited
 
  - screen blank/lock
  - system sleep (STR/hibernation)
  - system shutdown
  - logoff/user switch
 
  1, 2, 4, 3?
 
 These re just random things that you can do.

That's 4 things in your list of 3.

  Out of these sleep and
 shutdown are clearly related because they happen in hardware. Screen
 lock and user switch may or may not. Same for logoff/user switch and
 the others.
 
 For example you might want to save your work on user switch if you
 have a screen/session lock that prevents the other users accessing
 your session later but if your system does not have locking you might
 want the system not bother you with that to make the switching faster.
 
 
  Also, we don't inhibit screen blank/screen lock. We inhibit idle.
 
  Since the application simulates the user is active
 
  No it doesn't. This isn't the 90's.
 
 Well, it does not use actual input events. However, the end result is
 that the idle service which watches for user input to determine
 non-idleness receives another kind of event from the application that
 indicates that the user is not considered idle. As pointed out
 inhibiting idleness indefinitely is not the way to go.

Why is inhibiting idleness not the way to go? I can't see anywhere in
this mail that it's not the way to go. It's how we've implemented things
right now, and it work pretty well...

  Please reply to the thread in the future instead of writing a new
  e-mail.
 
 Sorry, the downloadable archives are in unintelligible format and the
 archive web interface does not support reply.

The downloadable archives are in mbox format, which your mail
application should be able to import.

 There is no practical way to reply to an email that did not arrive in my 
 inbox.

This is your e-mail:
http://thread.gmane.org/gmane.comp.freedesktop.xdg/13800/focus=13807

You can answer it there or using the NNTP interface.

Cheers

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

Re: defaults.list or mimeapps.list?

[Bastien Nocera]

On Sun, 2014-01-19 at 19:03 +, Jerome Leclanche wrote:
 I'm finding a lot of conflicting information. Which to use? I'm using
 mimeapps.list currently, I was certain defaults.list was the
 deprecated one but I need an official word on this.

mimeapps.list adds mime-types to a particular application.
defaults.list changes the default handler for a mime-type.

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

Re: expanding the inhibit spec

[Bastien Nocera]

On Sat, 2014-01-18 at 12:23 +0100, Michal Suchanek wrote:
 Hello,
 
 there is some problem with the archives so I can't read the whole
 thread about this.
 
 From the existing API I can see three things that are inhibited
 
 - screen blank/lock
 - system sleep (STR/hibernation)
 - system shutdown
 - logoff/user switch

1, 2, 4, 3?

Also, we don't inhibit screen blank/screen lock. We inhibit idle.

 Since the application simulates the user is active 

No it doesn't. This isn't the 90's.

Please reply to the thread in the future instead of writing a new
e-mail.

Cheers

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

Re: Modifying an existing desktop file's MimeTypes

[Bastien Nocera]

On Sat, 2014-01-11 at 13:36 +0100, Albert Astals Cid wrote:
 El Dissabte, 11 de gener de 2014, a les 02:28:18, Jerome Leclanche va 
 escriure:
  Consider the following use case:
  
  gimp supports image/png. gimp-webp-plugin makes gimp support image/webp.
  
  How would gimp-webp-plugin declare that it makes another app support
  additional mime types? I don't think it's possible currently.
  Suggestions?
 
 In Okular we just install another .desktop with the same main keys (Name, 
 exec, type, etc) except it has a different mimetype and NoDisplay=true
 
 That works fine under KDE but I've been told not so good under 
 gnome/glib/gtk/whatever does the .desktop parsing.
 
 IMHO it's quite a clean an easy way to do it, but I do not have much in depth 
 knowledge of how this works/is supposed to work.

It works fine under GNOME, but it will break some other functionality
like Default applications because there's no way to back link to the
original desktop file (the one without NoDisplay=true).

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

Re: expanding the inhibit spec

[Bastien Nocera]

On Thu, 2014-01-09 at 13:08 -0500, Ryan Lortie wrote:
snip
 It's a whole other issue, though, when we start to talk about
 independent app vendors who don't want to use Gtk.  People who want to
 make something in SDL and have it just work.  What do we tell them?  I
 guess we could start by asking them what is your intended platform?

SDL is a bad example. The only inhibitor it uses is idle inhibition, and
I already cooked up a patch for it to use the (existing) fd.o spec for
that:
https://bugzilla.libsdl.org/show_bug.cgi?id=2169

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

Re: expanding the inhibit spec

[Bastien Nocera]

On Thu, 2014-01-09 at 13:50 +0100, Lennart Poettering wrote:
 On Wed, 08.01.14 09:48, Ryan Lortie (de...@desrt.ca) wrote:
 
  
  hi,
  
  On Wed, Jan 8, 2014, at 6:28, Simon McVittie wrote:
   Having implemented delay logout until we've tried to disconnect IM
   connections in telepathy-mission-control, in terms of the logind API
   (which only has Inhibit and PrepareToSleep), I'm not sure that a
   separate Delay API is really needed.
  
  As I mentioned before, I'm concerned that not everyone will be using
  logind.
  
  That said, delay-before-suspend is sort of a separate thing from
  Inhibit, and I'm not sure I want to support it at all in the API I
  propose, so my concerns about able to do all kinds of inhibit from one
  place don't necessarily apply here.
  
  This would still land us in a place that means that those who want to do
  tasks before suspend could only do it on logind systems.  I don't really
  consider that to be a substantial problem (particularly because
  non-logind systems may not even have this ability to begin with), but I
  guess it would be nice to have a more generic mechanism for that as
  well... one day...
 
 So, let's turn this around: which operations precisely do you want to
 cover here, and in which modes?
 
 You only want blocking locks, and you want to cover
 suspending/hibernation, and the screenlock, and ...?

The listed inhibit flags in GtkApplication are here:
https://developer.gnome.org/gtk3/stable/GtkApplication.html#GtkApplicationInhibitFlags

Cheers

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

Re: expanding the inhibit spec

[Bastien Nocera]

On Tue, 2014-01-07 at 17:38 -0500, Ryan Lortie wrote:
 hi,
 
 On Tue, Jan 7, 2014, at 16:00, Ted Gould wrote:
  It seems to me that what is odd about that API is that it conflates two
  different types of inhibition, one is application lifecycle and the
  other system lifecycle.  I don't think it makes sense at a system level
  to merge those two together because they're handled very differently in
  different parts of the stack.
 
 There is nothing here that is directed toward the 'app lifecycle' that
 you're talking about.  This is just an API for inhibiting system-level
 stuff (like 'logout', 'suspend', 'lock screen', etc).

They inhibit *automatic* logout and suspend. Lock screen is never
inhibited (the user can always lock the screen), idle is inhibited which
stops the screensaver coming on. Please use the correct vocabulary when
discussing this, otherwise we'll end up with one big mess of a
discussion.

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

Re: New handling for URI scheme handlers

[Bastien Nocera]

On Sat, 2013-12-21 at 11:01 +0100, David Faure wrote:
 On Monday 02 December 2013 16:05:56 Bastien Nocera wrote:
  But David's original request was for this to work the same way across
  desktops. 
 
 Not really, actually.
 
 We use a different approach. That's fine.
 
 My request is that they don't step on each other's toes :)
 
 Installing a desktop file with x-scheme-handler/http breaks the KDE solution,
 so I was hoping to get an agreement on not installing such desktop files.
 
 But I'm starting to see that this won't happen, so I guess I'll stick to if 
 KIO supports a scheme and an app exists for the mimetype x-scheme-
 handler/scheme, then give priority to KIO. If anyone complains that this 
 isn't xdg-spec-compliant, I want it to be said already that this is because 
 the spec doesn't make room for our solution...

That sounds fine by me. Given that I don't agree that it's a good idea
to implement it that way, I'd rather it be hidden inside one
implementation instead of mandated in the spec :)

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

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

[Bastien Nocera]

On Mon, 2014-01-06 at 10:09 +0100, David Faure wrote:
 On Sunday 05 January 2014 21:42:47 Ryan Lortie wrote:
  On Sun, Jan 5, 2014, at 20:25, Jerome Leclanche wrote:
   Problem #1
   Apps cannot enumerate other apps of a specific type. A couple of
  
  It is my intent (ha...) to raise for a while that I want to introduce
  a new key to desktop files called Implements.  There is already some
  discussion about that here:
  https://bugzilla.gnome.org/show_bug.cgi?id=712391
  
  
  In terms of the desktop entry spec, such an addition would be extremely
  simple: we have a new 'string list' key called Implements with no
  particular meaning except that each entry in the list is expected to be
  in D-Bus interface name style.
  
  This would solve your enumerate apps of a specific type assuming that
  you have someone willing to specify, concretely, what it means to be a
  given type of application.
 
 Not really, it's useful but orthogonal.
 
 To let users choose their preferred webbrowser, terminal emulator, WM, and 
 mail app, all we need is an interface name like WebBrowser, 
 TerminalEmulator, WindowManager, Mail, InstantMessenger, without any relation 
 to DBus.

D-Bus-style name.

This allows namespacing and versioning.

org.freedesktop.TerminalEmulator1
or org.gnome.TerminalEmulator2
vs. simply TerminalEmulator

And it's more about services (allow me to pick a photo, or select a
contact) than about full-fledged applications. A terminal emulator can
hardly be thought as providing a service to other applications, a photo
picker provided by the native photo application would.

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

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

[Bastien Nocera]

On Mon, 2014-01-06 at 14:35 +0100, David Faure wrote:
 On Monday 06 January 2014 14:28:01 Bastien Nocera wrote:
  And it's more about services (allow me to pick a photo, or select a
  contact) than about full-fledged applications. A terminal emulator can
  hardly be thought as providing a service to other applications, a photo
  picker provided by the native photo application would.
 
 My point is that both needs (i.e. use cases) exist.
 
 I know that intents and the use of dbus interfaces is about what you 
 describe.
 
 I'm simply pointing out that the other use case (merely starting apps, at 
 most 
 with a url on the command line) exists too, and that I'd like to see a 
 standard solution for it.

The URL would/should have a mime-type associated to it, so you can just
lookup by mime-type.

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

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

[Bastien Nocera]

On Mon, 2014-01-06 at 14:48 +0100, David Faure wrote:
 On Monday 06 January 2014 14:44:27 Bastien Nocera wrote:
  On Mon, 2014-01-06 at 14:35 +0100, David Faure wrote:
   On Monday 06 January 2014 14:28:01 Bastien Nocera wrote:
And it's more about services (allow me to pick a photo, or select a
contact) than about full-fledged applications. A terminal emulator can
hardly be thought as providing a service to other applications, a photo
picker provided by the native photo application would.
   
   My point is that both needs (i.e. use cases) exist.
   
   I know that intents and the use of dbus interfaces is about what you
   describe.
   
   I'm simply pointing out that the other use case (merely starting apps, at
   most with a url on the command line) exists too, and that I'd like to see
   a standard solution for it.
  
  The URL would/should have a mime-type associated to it, so you can just
  lookup by mime-type.
 
 at most means sometimes none.
 
 There's no URL and no mimetype involved when listing or starting
 - window managers
 - terminal emulators

Those would be covered by the Implements changes documented by Ryan:
https://bugs.freedesktop.org/show_bug.cgi?id=73317

 - instant messaging apps

xmpp, and irc schemes at least, so those are covered by
x-scheme-handler/*

 - email clients

mailto scheme

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

Re: New handling for URI scheme handlers

[Bastien Nocera]

On Mon, 2013-12-02 at 09:40 +, Jerome Leclanche wrote:
 On Mon, Dec 2, 2013 at 7:57 AM, Bastien Nocera had...@hadess.net wrote:
  On Mon, 2013-12-02 at 07:49 +, Jerome Leclanche wrote:
  On Mon, Dec 2, 2013 at 7:13 AM, Bastien Nocera had...@hadess.net wrote:
   On Mon, 2013-12-02 at 00:59 +0100, David Faure wrote:
   (very old mail, but this is bugging me again :)
  
   Context: I believe that associating a webbrowser with 
   x-scheme-handler/http is
   wrong.
  
   On Wednesday 06 October 2010 00:38:40 Bastien Nocera wrote:
David Faure wrote:
  When you click a http URL that
 points to an .odt document, you want to launch openoffice, not a
 web-browser.
   
If you're already in a web browser, yes, but in this case, the lookup
shouldn't be including a scheme handler lookup, just an application 
that
handles that particular mime-type.
  
   But what if you're not in a webbrowser in the first place?
   E.g. in a desktop email application, you click on an HTTP link to a .odt
   document. Should that really start firefox, just so that it can then 
   launch
   openoffice?
   (same with any other content application that can handle HTTP urls on 
   its own;
   same with other schemes that apps might support, like FTP).
  
   Note that at this point we have no clue about the mimetype. We can 
   start a
   download and find it out, but the first question is: should we do that, 
   or
   just blindly trust the app that says it wants all URLs with this scheme 
   (http,
   in my example).
  
   Since we don't want this to happen in KDE, I had to write code such as 
   if KIO
   supports a scheme and an app exists for the mimetype x-scheme-
   handler/scheme, then give priority to KIO. (for the special case of 
   http,
   there is actually a user setting for send all http urls to this 
   particular
   app, but that's not the default setting).
   I don't like it very much though, it feels like a hack :)
   But I guess it makes sense, since in KDE we prefer to open HTTP urls by
   mimetype, while IIUC in Gnome you prefer to open them with a single 
   scheme-
   associated application (i.e. webbrowser).
  
   So, it's all fine, I'm just curious about what happens in your case 
   when the
   user isn't in a webbrowser in the first place (and to pick the worst 
   case - if
   it's not running yet, which means a long delay coming from the startup 
   of two
   large applications one after the other).
  
   I wish it worked like that as well, but you've just broken one-time URLs
   and tried to open a login page in LibreOffice if you don't share cookie
   jars between all the clients.
 
  With a middleman client this is a solved issue; it would be identified
  as a page to take care of in the browser.
 
  Let me know when you have that middle man client implemented :)
 
  I wonder how you'll handover to the dozen of different web browsers,
  read their cookie jars, or get applications with links to use your
  middle man client instead of whatever HTTP library they want to use.
 
  It's a nice idea, but it's just not feasible without a clean slate. I
  think that GNOME's current approach is more pragmatic, especially with
  HTTP's baggage.
 
 
 I think you're confused about the complexity of the task.
 
 All the client does is, for http:
  - Parse the url given to it
  - Identify whether it's potentially a file through its name (get a
 filename if there's one)

This might fail if you need to log in, because the file type on the end
of the call is HTML when the URI tells you otherwise.

  - If it is, run a match against the xdg patterns on it
  - If there's any match that is not an app that is associated with
 x-scheme-handler/http(s), do HTTP HEAD on the url

The HTTP HEAD just ate your one-time URL. 

  - If the HEAD was successful and returns a mime type in the mime type
 db and the mime type is associated with an app, *download* the file
  - Hand off downloaded file to the associated app
  * If any step fails, hand off to web browser
 
 This could be a simple script, or it could be a more involved download
 manager that would integrate with the desktop (a neat system-wide
 download bar such and such).

It seems that I didn't explain myself well enough. You cannot access the
URLs given to you from outside the client that will ultimately handle it
because you might be using up a one-time URL. You also cannot rely on
filenames because that's not how HTTP mime-types are conveyed.

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

Re: New handling for URI scheme handlers

[Bastien Nocera]

On Mon, 2013-12-02 at 15:53 +0100, Kevin Krammer wrote:
 On Monday, 2013-12-02, 15:34:34, Bastien Nocera wrote:
  On Mon, 2013-12-02 at 15:16 +0100, Kevin Krammer wrote:
   On Monday, 2013-12-02, 09:40:12, Nicolas Mailhot wrote:
Le Lun 2 décembre 2013 00:59, David Faure a écrit :
 (same with any other content application that can handle HTTP urls on
 its
 own;
 same with other schemes that apps might support, like FTP).

Having managed a very large proxy configuration for some years (150k+
users, high-availability) I can tell you that pretty much any
application
that pretends talking http lies, and only full browsers implement
(mostly)
the complete http spec (including error handling)
   
   David obviously looks at this from a KDE perspective, where the same HTTP
   implemention is used by all applications, including the browser.
   IIRC it can even transfer a session from one application to another, e.g.
   avoiding the one-time-URL problem.
  
  If I use Opera, Firefox or Chrome in KDE, I'm not sure it magically uses
  the same HTTP implementation.
 
 Sure, but David also mentioned that we enable users to tell our URL handling 
 code to delegate HTTP always to a certain program/browser and was, in my 
 interpretation, discussing the implications on the standard setup.
 
 So, within this assumed context, I was pointing out to Nicolas that the HTTP 
 implemention in question was browser capable.

It's certainly possible to implement this feature the way mentioned when
you know that the default HTTP handler will be able to transfer/share
session information with the browser.

But David's original request was for this to work the same way across
desktops. We don't have any such support in GNOME, and I don't see it as
something that's worth the effort either. I guess that brings David's
question to a close.

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

Re: New handling for URI scheme handlers

[Bastien Nocera]

On Mon, 2013-12-02 at 00:59 +0100, David Faure wrote:
 (very old mail, but this is bugging me again :)
 
 Context: I believe that associating a webbrowser with x-scheme-handler/http 
 is 
 wrong.
 
 On Wednesday 06 October 2010 00:38:40 Bastien Nocera wrote:
  David Faure wrote:
When you click a http URL that 
   points to an .odt document, you want to launch openoffice, not a
   web-browser.
 
  If you're already in a web browser, yes, but in this case, the lookup
  shouldn't be including a scheme handler lookup, just an application that
  handles that particular mime-type.
 
 But what if you're not in a webbrowser in the first place?
 E.g. in a desktop email application, you click on an HTTP link to a .odt 
 document. Should that really start firefox, just so that it can then launch 
 openoffice?
 (same with any other content application that can handle HTTP urls on its 
 own; 
 same with other schemes that apps might support, like FTP).
 
 Note that at this point we have no clue about the mimetype. We can start a 
 download and find it out, but the first question is: should we do that, or 
 just blindly trust the app that says it wants all URLs with this scheme 
 (http, 
 in my example).
 
 Since we don't want this to happen in KDE, I had to write code such as if 
 KIO 
 supports a scheme and an app exists for the mimetype x-scheme-
 handler/scheme, then give priority to KIO. (for the special case of http, 
 there is actually a user setting for send all http urls to this particular 
 app, but that's not the default setting).
 I don't like it very much though, it feels like a hack :)
 But I guess it makes sense, since in KDE we prefer to open HTTP urls by 
 mimetype, while IIUC in Gnome you prefer to open them with a single scheme-
 associated application (i.e. webbrowser).
 
 So, it's all fine, I'm just curious about what happens in your case when the 
 user isn't in a webbrowser in the first place (and to pick the worst case - 
 if 
 it's not running yet, which means a long delay coming from the startup of two 
 large applications one after the other).

I wish it worked like that as well, but you've just broken one-time URLs
and tried to open a login page in LibreOffice if you don't share cookie
jars between all the clients.

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

Re: New handling for URI scheme handlers

[Bastien Nocera]

On Mon, 2013-12-02 at 07:49 +, Jerome Leclanche wrote:
 On Mon, Dec 2, 2013 at 7:13 AM, Bastien Nocera had...@hadess.net wrote:
  On Mon, 2013-12-02 at 00:59 +0100, David Faure wrote:
  (very old mail, but this is bugging me again :)
 
  Context: I believe that associating a webbrowser with 
  x-scheme-handler/http is
  wrong.
 
  On Wednesday 06 October 2010 00:38:40 Bastien Nocera wrote:
   David Faure wrote:
 When you click a http URL that
points to an .odt document, you want to launch openoffice, not a
web-browser.
  
   If you're already in a web browser, yes, but in this case, the lookup
   shouldn't be including a scheme handler lookup, just an application that
   handles that particular mime-type.
 
  But what if you're not in a webbrowser in the first place?
  E.g. in a desktop email application, you click on an HTTP link to a .odt
  document. Should that really start firefox, just so that it can then launch
  openoffice?
  (same with any other content application that can handle HTTP urls on its 
  own;
  same with other schemes that apps might support, like FTP).
 
  Note that at this point we have no clue about the mimetype. We can start a
  download and find it out, but the first question is: should we do that, or
  just blindly trust the app that says it wants all URLs with this scheme 
  (http,
  in my example).
 
  Since we don't want this to happen in KDE, I had to write code such as if 
  KIO
  supports a scheme and an app exists for the mimetype x-scheme-
  handler/scheme, then give priority to KIO. (for the special case of 
  http,
  there is actually a user setting for send all http urls to this particular
  app, but that's not the default setting).
  I don't like it very much though, it feels like a hack :)
  But I guess it makes sense, since in KDE we prefer to open HTTP urls by
  mimetype, while IIUC in Gnome you prefer to open them with a single scheme-
  associated application (i.e. webbrowser).
 
  So, it's all fine, I'm just curious about what happens in your case when 
  the
  user isn't in a webbrowser in the first place (and to pick the worst case 
  - if
  it's not running yet, which means a long delay coming from the startup of 
  two
  large applications one after the other).
 
  I wish it worked like that as well, but you've just broken one-time URLs
  and tried to open a login page in LibreOffice if you don't share cookie
  jars between all the clients.
 
 With a middleman client this is a solved issue; it would be identified
 as a page to take care of in the browser.

Let me know when you have that middle man client implemented :)

I wonder how you'll handover to the dozen of different web browsers,
read their cookie jars, or get applications with links to use your
middle man client instead of whatever HTTP library they want to use.

It's a nice idea, but it's just not feasible without a clean slate. I
think that GNOME's current approach is more pragmatic, especially with
HTTP's baggage.

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

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

[Bastien Nocera]

Hey,

Em Wed, 2013-02-13 às 15:18 +, Simon McVittie escreveu:
 On 21/12/12 15:16, Bastien Nocera wrote:
  So this is what I ended up with:
  http://people.freedesktop.org/~hadess/idle-inhibition-spec/
 
  Idle inhibition is achieved by ... calling an Inhibit function ... on
  a well-known D-Bus name.
 
 s/function/method/ - D-Bus doesn't have functions.

Fixed.

 It seems pretty strange that the API documentation chapter is so vague
 - you have to read the API reference to know what's actually going on.
 Rename to API overview maybe, and/or add more hyperlinks?

Renamed.

  API notes
 
 Design notes or Rationale?

Renamed.

  org.freedesktop.ScreenSaver — The Idle Inhibition Service manages the
  inhibition requests.
 
 There's nothing here to say that the process with the o.f.S well-known
 name must implement the o.f.S interface. There's also nothing here to
 say which object-path in that process must have that interface.

Sigh. That'd be because I didn't read the HTML output at all, other than
looking that it did generate, and the input does contain that
information:
$ git grep 'node ' 
org.freedesktop.ScreenSaver.xml:node name=/org/freedesktop/ScreenSaver

  By
 inspecting the GNOME implementation, it appears to be
 /org/freedesktop/ScreenSaver.
 
 I suggest re-wording to:
 
 The Idle Inhibition service manages inhibition requests.
 Implementations of this well-known bus name must have an object
 /org/freedesktop/ScreenSaver which implements the
 _org.freedesktop.ScreenSaver_ interface.
 
 where _..._ is a hyperlink.

I've put this in the API overview, otherwise this gets pulled in to the
TOC as the label for the link.

 Oswald wrote:
  the spec is ridiculously over-structured for its contents.
 
 I think it would seem less ridiculous if it was (only) published as a
 single HTML page with the same content, which I think is just a matter
 of using different XSLT? The single page / multi-page split can happen
 if it grows more methods later.

I haven't figured out how to do that, and after spending 10 minutes
trying to make it output what I wanted, I think it's quite enough work
for the handful of people that will ever be reading this.

Note that I found out (when VLC wasn't actually inhibiting playback)
that KDE doesn't implement the API on the /org/freedesktop/ScreenSaver
but on /ScreenSaver. I've made a mention of that in the spec as well.

Cheers

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

Re: Trash spec: directory size cache

[Bastien Nocera]

Em Mon, 2013-04-15 às 10:07 +0200, Alexander Larsson escreveu:
 On sön, 2013-04-14 at 23:48 +0200, David Faure wrote:
  To implement a maximum size for the trash directory, one needs to check the 
  size every time a new item is being trashed. With the current spec, the 
  only 
  solution is to do a recursive traversal, which is pretty expensive.
  To make this efficient, we need a cache.
  My initial idea of a global total size cache doesn't work well with older 
  implementations which don't update that value, so it gets out of date 
  quickly.
  
  Instead, Ryan Lortie and I came up with the following idea, which we would 
  like to standardize into the trash spec:
  
  For files, we get the file from stat. For dirs, we use a cache:
  in every trash directory, a metadata file is created, with one entry per 
  directory (that was trashed by the user).
  That entry contains the total size in bytes of the directory, and the 
  modification time of the trashinfo file [*].
  
  The metadata file uses desktop file syntax, where the key is the directory 
  name, and the value is a pair: size, and mtime.
  
  However the desktop file standard restricts the available characters for 
  keys, 
  so instead of just writing out the directory name, we write the sha1 of the 
  directory name (a bit like the thumbnail spec uses sha1s too).
  
  In summary, it would look like this:
  
  [Directories]
  # One entry per sub-directory of the files directory
  # key = sha1 of the directory name
  #  value = size in bytes, timestamp of the trashinfo file, in UTC
  cb58e5c11a6802db43fd82ca8d3c7393353c0eab=25383,2009-07-11T20:18:30
  f1d2d2f924e986ac86fdf7b36c94bcdf32beec15=2315,2012-04-12T10:05:20
 
 In general this sounds good to me. I have two minor objections:
 
 1: Using sha1 seems wrong to me. There is no need to get an even
 distribution of the keys (like for thumbnail subdirectories), and a sha1
 is slow to calculate. Also, if you ever look at the file manually its
 says very little. I would much prefer simple character escape model, say
 you allow A-Za-z0-9 and everyting else you escape as - + the hex
 digits (like -2d for -). This is valid desktop file keys, are cheap
 to calculate and makes most files readable by humans.

Or base-64 encode the directory name. Even if that fails the readable
by humans test, at least it'll avoid slightly differently buggy escape
sequences).

 2: Don't store the mtime in a format that needs parsing. Time and date
 parsing is a very complicated area that is easy to get wrong. And the
 source is always a stat which is in epoch format, why not just save it
 in the same format to avoid any day/month order issues, timezone
 weirdnesses or whatnot.

ISO 8601 time format requires very little work to parse, and uses
GMT/UTC. It also passes the human-readable test ;)


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

Re: Trash spec: directory size cache

[Bastien Nocera]

Em Mon, 2013-04-15 às 14:36 +0200, Alexander Larsson escreveu:
 On mån, 2013-04-15 at 14:25 +0200, Ryan Lortie wrote:
  hi,
  
  On 2013-04-15 13:43, Alexander Larsson wrote:
   On mån, 2013-04-15 at 10:19 +0200, Ryan Lortie wrote:
   No strong objections to turning it into unix-timestamp-in-UTC though.
  
   N! The timestamp timezone of a mtime is undefined, and may be
   different from the actual timezone of the computer doing the stat()
   call, for instance for NFS mounts. There is no reason whatsoever to do
   anything to the value returned from stat, as all we do with it is
   compare it to a later stat value. Any kind of timezone conversion on it
   will not help and may hurt.
  
  The kernel time is in UTC...
 
 The kernel will report whatever time_t value was sent over the network
 via the NFS protocol. Whether this is UTC or not depends on the server
 setup and OS. But sure, if what you mean by unix-timemstamp-in-UTC is
 whatever value the kernel gave you in stat() then that is fine. Just
 don't ever try to do anything on that value that depends on the timezone
 of the NFS client.
 
 This is exactly where using a string for time makes things tricky. You
 need to parse the string, and its easy to accidentally pick some API
 that assumes that the string is in local timezone rather than UTC, and
 thus get things wrong. If the file just lists a time_t integer value it
 is less likely that things go wrong when you compare it with the
 stat().st_mtime value.

How is it any better defined than ISO8601 with the timezone information?

From g_time_val_to_iso8601():

ISO 8601 allows a large number of date/time formats, with or without
punctuation and optional elements. The format returned by this function
is a complete date and time, with optional punctuation included, the UTC
time zone represented as Z, and the tv_usec part included if and only
if it is nonzero, i.e. either -MM-DDTHH:MM:SSZ or
-MM-DDTHH:MM:SS.fZ.



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

Re: Mime types - uppercase appearing in mime type names

[Bastien Nocera]

On Mon, 2013-03-18 at 14:22 +, Thomas Kluyver wrote:
 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.

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

  It would need both a (small) spec change and a code change.

You'll need to attach patches for both if you want to see any movement
on this (both to xdgmime and shared-mime-info's update-mime-database, as
well as an additional testcase for shared-mime-info's test suite).

Cheers


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

Re: Fwd: Conflicting mime types

[Bastien Nocera]

On Tue, 2013-03-05 at 11:29 +, Thomas Kluyver wrote:
 I've just had a bug reported against PyXDG that a Mimetype test is
 returning image/x-apple-ios-png instead of image/png.

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

 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?

By lowering the priority of the *png associated with
image/x-apple-ios-png, which I've now done in master.

  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?

Cheers


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

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

[Bastien Nocera]

On Fri, 2012-12-21 at 16:16 +0100, Bastien Nocera wrote:
 Resend, as the original mail was never moderated through (the attached
 patch was too big).

And the draft is now live at:
http://specifications.freedesktop.org/idle-inhibit-spec/0.1/

Thanks Vincent!

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

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

[Bastien Nocera]

Resend, as the original mail was never moderated through (the attached
patch was too big).

So this is what I ended up with:
http://people.freedesktop.org/~hadess/idle-inhibition-spec/

Patch for xdg-specs available at:
http://people.freedesktop.org/~hadess/0001-Add-idle-inhibit-D-Bus-service-spec.patch

Patches welcome.

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

Re: Rework of the org.freedesktop.ScreenSaver API?

[Bastien Nocera]

On Thu, 2012-11-29 at 11:16 +0100, Aaron J. Seigo wrote:
 On Wednesday, November 28, 2012 19:10:28 Bastien Nocera wrote:
  I missed the discussions about the old screensaver API that KDE and
  GNOME developers discussed but only KDE implemented:
  https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/mas
  ter/entry/ksmserver/screenlocker/dbus/org.freedesktop.ScreenSaver.xml and I
  hope we can work something out now.
 
 cool ...
 
  I've implemented a proxy for this in GNOME[2], which I'll backport to
  3.6 when it's had a bit of testing. Only the Inhibit/UnInhibit and the
  Throttle/UnThrottle pairs are implemented (and the latter is a no-op).
 
 Would it be possible to have only inhibit/uninhibit, or is throttle actually 
 useful / used?

GNOME has not use for throttle, we don't have screensaver animations. I
thought it might be used in KDE apps, so I implemented no-ops for it.

No objections getting it removed for me.

  Here's a list of things I think we'd need to clean up in a new API:
  - Only define application API, not system-level API (what's the use
  knowing that the screensaver is actually on, or the session idle time?)
  - What's SimulateUserActivity for? It looks like a way to avoid using
  the API, or maybe a way for apps to not link to D-Bus. I think that we
  should remove this if we agree and implement this API.
 
 It resets the idle time of the system, which various components use to alter 
 the behaviour of the UI; e.g. if a notification appears while the user is 
 idle, 
 it waits until there is user activity before starting the countdown to 
 automatically hide it (giving them a chance to see it once their attention is 
 back on the system). That said, I'm not sure it makes much sense to expose 
 this to applications directly.
 
 The reason it is in the DBus API seems to be as a way to expose this 
 functionality without requiring applications to have support in libraries 
 they 
 link to. e.g. in KDE's libs we have KIdleTime which implements all this 
 functionality (and as a result, no KDE apps use this part of the DBus spec). 

I think idle time can be better monitored directly from X. You have
KIdleTime, we have GnomeIdleMonitor in gnome-desktop.

This should only really be used for system level integration (the
notification daemon, the shell, whatever ends up presenting the
notification), so I don't see a point having it in a D-Bus spec.

And if it's really needed for apps, we can always re-add it later.

 It may also have been put there as a way to easily port existing applications 
 that were doing such things manually in their code, giving them a 1:1 
 mapping of functionality rather than requiring they change their code to an 
 inhibition pattern. If that was the case, I don't agree with it :)
 
 I'd support the position of: if you want to simulate user activity, then 
 find 
 an implementation that does so. rather than expose this in the DBus API.
 
 Potential impact of the change: This would only potentially impact 3rd party 
 applications, user scripts, etc. It's a bit of a stretch imho to justify use 
 of this API from scripts and the like .. it's really only rather specific 
 (and 
 usually somewhat special) applications that need to simulate user activity.
 
 Ditto all the above for the idle time API.
 
 So imho the DBUs API could indeed be stripped down a bit into a basic-needs 
 application API and leave things like idle time to actual libraries.
 
 For KDE's existing support of this API, we'd have to keep the API as-is in 
 any 
 case to preserve application compatibility .. but we could mark things as 
 deprecated and remove them in the coming Frameworks 5.0 based releases

We can bump the version/change the name of the API entry point. Then you
could support both versions of the spec.

  - Inhibition should be done at the session level, with the session
  controlling the screensaver (or the screensaver asking the session,
  whichever). Could we rename the interface to not include screensaver
  in the name?
 
 This creates work for those of us who have already implemented it. Other than 
 the cosmetics of it, what are the benefits of altering the name?
 
 While the name is perhaps not perfect, it would mean that all applications 
 that currently use this API (probably mostly KDE applications at this point) 
 would Just Work(tm) without needing any adjustments or alterations. Otherwise 
 we will need to not only change the application code, but also do some 
 dancing 
 to ensure those apps work on current/previous releases of KDE's workspaces 
 (e.g. - see if the interface is registered on some new name, if that fails, 
 try the old name).
 
 So unless there's a really good reason for changing the name, I'd suggest we 
 leave it, even if it isn't perfect (that being the enemy of good ;)

The good reason is that KDE's been using that name with this particular
API, with the expectation from application developers that such and such
function

Re: Rework of the org.freedesktop.ScreenSaver API?

[Bastien Nocera]

On Thu, 2012-11-29 at 12:20 +0100, Aaron J. Seigo wrote:
snip
 For a widely implemented spec with API that is actually used, this would make 
 sense. This is not the case here, however.
 
   So unless there's a really good reason for changing the name, I'd suggest
   we leave it, even if it isn't perfect (that being the enemy of good ;)
  The good reason is that KDE's been using that name with this particular
  API, with the expectation from application developers that such and such
  function are working and will remain working.
  
  Removing functions from the D-Bus API as you've implemented without
  renaming it is akin to removing functions in a shared library without
  bumping the soname.
 
 As I wrote earlier, we can make this kind of change with the upcoming 5.0 
 release, so it isn't a problem for us. It is made much easier by the fact 
 that 
 there is precisely zero usage of these calls in KDE applications according to 
 lxr.kde.org so would only be kept during the 4.x release series for API 
 discipline rather than any actual real world benefit. So this is not a good 
 reason to change the name.
 
 The problem of having a KDE 4.x application work with a 5.x based env, or 
 vice 
 versa, is a strong reason to keep the name as that does have actual real 
 world 
 benefit.
 
 .. which is why I asked if the motivation for changing the name is cosmetics. 
 :) If the reason for a name change is a nicer name can be thought of then 
 that just increases the cost for KDE. As a kindness to those who implement 
 such specs in a timely manner, it is nice not to heap additional work that 
 does not provide real world benefit when new implementions appear.

So, you can change the API because nothing uses it, but you can't change
its name because something *might* use it? I don't quite understand the
logic.

- As for the Inhibition APIs, gnome-session can inhibit more than just
the screensaver (log out, user switching, suspend, and auto-mounting):
http://git.gnome.org/browse/gnome-session/tree/gnome-session/org.gnome.S
essi onManager.xml#n148
   
   We already have /org/freedesktop/PowerManagement/Inhibit
  
  We, as in, KDE? I don't see this being available anywhere on my system.
 
 Perhaps; seems to be yet another API that got discussed (though I'm not 
 personally aware of when/where/between whom) and rarely implemented. :/

Where is it spec'ed?

for things like
   
   suspension inhibition. It could make sense to try and unify all these
   suspension concepts into one DBus API .. though that could also just as
   easily be done in library API, preventing churn in the already
   implemented DBus services underneath.
  
  I don't think that application developers should have to look in two
  separate places for inhibition APIs. Having the API split like that
  based on implementation details is just bad.
 
 There are a couple ways to look at it:
 
 * anything with the word inhibit in it, or which inhibits some system 
 functionality, belongs together in one API
 
 * inhibition of system functionality belongs with the controller of that 
 functionality

Which brings back the question, why should application developers care?

 I lean towards the latter. We (KDE) don't have one overall inhibitor 
 service, but we do have a power management component, a screen locker 
 component, etc. With a unified inhibition API, we'd end up having to create a 
 synthetic service that calls out to these other services that implement the 
 actual functionality.

If this is the way we're gonna go, the implementation in GNOME is going
to stay in the proxy category. It's not usable to replace or even
supplement existing functionality.

 Having an inhibit catch-all service could easily lead to a random-collection-
 of-stuff API. It would also mean that each time a new can-be-inhibited system 
 service appears, we'd have to also manage a change to the catch-all API 
 rather 
 than keep it localized to the service in question. (Ditto, but in reverse, 
 for 
 system services that stop being offered, or aren't offered on specific form 
 factors.)

This is an implementation detail, users of the API shouldn't have to
care about where it's implemented or about the architecture of KDE. I
doubt that Windows or OSX split their APIs like that.

 What would be useful is to have a defined standard for inhibition API so that 
 each service that does support inhibition can be used in a consistent manner.
 
  And I don't see what log out, user switching or auto-mount inhibition
  would have to do in PowerManagement.
 
 They don't; I was discussing things like suspension which do :)

Yes... Which means that, if those additional ones were implemented, we
would have 3 additional separate APIs for it. I don't see this as being
useful.


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

Re: Rework of the org.freedesktop.ScreenSaver API?

[Bastien Nocera]

On Thu, 2012-11-29 at 13:56 +0100, Aaron J. Seigo wrote:
 On Thursday, November 29, 2012 12:50:34 you wrote:
  On Thu, 2012-11-29 at 12:20 +0100, Aaron J. Seigo wrote:
  So, you can change the API because nothing uses it, but you can't change
  its name because something *might* use it?
 
 No :)
 
 The API can be changed in 5.0 as we can break compatibility there; since 
 nothing actually uses the API that would be removed the real world 
 development 
 cost will be 0.
 
 Changing the name of the service incurs development cost as we will need to 
 support the case of mixed application and service versions. The only way to 
 prevent that is to keep both names in perpetuity, and I don't see any point 
 to 
 that unless there is something seriously flawed with the existing name.

In the implementation it's:
if (path == old_service_name)
  do_old_stuff
else if (path == new_service_name)
  do_new_stuff

Where most of the code between do_old_stuff and do_new_stuff would be
shared anyway.

  for things like
 
 suspension inhibition. It could make sense to try and unify all these
 suspension concepts into one DBus API .. though that could also just
 as
 easily be done in library API, preventing churn in the already
 implemented DBus services underneath.

I don't think that application developers should have to look in two
separate places for inhibition APIs. Having the API split like that
based on implementation details is just bad.
   
   There are a couple ways to look at it:
   
   * anything with the word inhibit in it, or which inhibits some system
   functionality, belongs together in one API
   
   * inhibition of system functionality belongs with the controller of that
   functionality
  
  Which brings back the question, why should application developers care?
 
 It's more why should the implementors care.

No, I'm making an API for application developers. System developers and
implementors make do with whatever they have available.

  If application devs don't care 
 (though if they are going to use DBus APIs directly, they will), then it's 
 what is most convenient and maintainable for those of us writing the 
 implementations.
 
 Having one catch-all inhibit service is more work and harder to maintain, 
 which is why I care as one of the people involved in implementing these 
 services for KDE :)

It took me an afternoon to write this proxy. Don't you think you're
exaggerating the amount of work here? Certainly, it would go well with
the other pieces of abstraction you've already got in your stack.

   I lean towards the latter. We (KDE) don't have one overall inhibitor
   service, but we do have a power management component, a screen locker
   component, etc. With a unified inhibition API, we'd end up having to
   create a synthetic service that calls out to these other services that
   implement the actual functionality.
  
  If this is the way we're gonna go, the implementation in GNOME is going
  to stay in the proxy category. It's not usable to replace or even
  supplement existing functionality.
 
 Yes, which is why I don't like the catch-all approach and prefer a per-
 service-inhibition API, e.g. one for power management, one for screen 
 locking, 
 etc.

The current API is severely limited, and non-extensible.

   Having an inhibit catch-all service could easily lead to a
   random-collection- of-stuff API. It would also mean that each time a new
   can-be-inhibited system service appears, we'd have to also manage a
   change to the catch-all API rather than keep it localized to the service
   in question. (Ditto, but in reverse, for system services that stop being
   offered, or aren't offered on specific form factors.)
  
  This is an implementation detail, users of the API shouldn't have to
  care about where it's implemented or about the architecture of KDE. I
 
 It has nothing to do with users of the API, but rather the specification 
 itself 
 which we who are implementing it will have to maintain.

If you write API for the implementors, it's no wonder the API ends up
being as muddled as this, with no clear separation between app-level API
and system-level API.

   What would be useful is to have a defined standard for inhibition API so
   that each service that does support inhibition can be used in a
   consistent manner. 
And I don't see what log out, user switching or auto-mount inhibition
would have to do in PowerManagement.
   
   They don't; I was discussing things like suspension which do :)
  
  Yes... Which means that, if those additional ones were implemented, we
  would have 3 additional separate APIs for it. I don't see this as being
  useful.
 
 Log out and user switching are probably connected.

Or maybe not, if I offer user switching in the screensaver, do I talk to
the screensaver? The display manager handling the switching? The desktop
daemon that'll make sure the current session is locked?

 Auto-mount inhibition 

Rework of the org.freedesktop.ScreenSaver API?

[Bastien Nocera]

Heya,

I've started looking at the screensaver inhibition problem for GNOME
3.6, as we've remove the hacks[1] that people were sometimes using to
inhibit the screensaver coming on.

I missed the discussions about the old screensaver API that KDE and
GNOME developers discussed but only KDE implemented:
https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/master/entry/ksmserver/screenlocker/dbus/org.freedesktop.ScreenSaver.xml
and I hope we can work something out now.

I've implemented a proxy for this in GNOME[2], which I'll backport to
3.6 when it's had a bit of testing. Only the Inhibit/UnInhibit and the
Throttle/UnThrottle pairs are implemented (and the latter is a no-op).

The API is bit a iffy, and shows how things are implemented underneath.

Here's a list of things I think we'd need to clean up in a new API:
- Only define application API, not system-level API (what's the use
knowing that the screensaver is actually on, or the session idle time?)
- What's SimulateUserActivity for? It looks like a way to avoid using
the API, or maybe a way for apps to not link to D-Bus. I think that we
should remove this if we agree and implement this API.
- Inhibition should be done at the session level, with the session
controlling the screensaver (or the screensaver asking the session,
whichever). Could we rename the interface to not include screensaver
in the name?
- As for the Inhibition APIs, gnome-session can inhibit more than just
the screensaver (log out, user switching, suspend, and auto-mounting):
http://git.gnome.org/browse/gnome-session/tree/gnome-session/org.gnome.SessionManager.xml#n148

FWIW, I'm fine with only having idle inhibition spec'ed on fd.o if we're
only going to be targetting applications with this API.

In the meanwhile, does somebody want to publish the original spec as it
was written? It would be something useful for application developers to
use right now, even if only that 4 aforementioned calls are listed.

Cheers

[1]: gnome-screensaver-command --poke, or whatever it was called.
[2]: https://bugzilla.gnome.org/show_bug.cgi?id=689225

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

Re: URL and application handling/registration standard

[Bastien Nocera]

On Sun, 2012-10-21 at 22:58 +0200, David Faure wrote:
 On Friday 19 October 2012 17:09:50 David Faure wrote:
   Better solution yet, imho: Screw being too clever.
  
- Have apps list protocols they support. Eg
  
   Protocols=x-scheme-handler/http;x-scheme-handler/https;
  
  Never ever do this, for the reasons above. HTTP is too complex to send all 
  http urls to a single app.
 
 Ouch, and I just found out that /usr/share/applications/firefox.desktop says
 
 MimeType=text/html;text/xml;application/xhtml+xml;application/vnd.mozilla.xul+xml;text/mml;application/x-
 xpinstall;x-scheme-handler/http;x-scheme-handler/https;x-scheme-handler/ftp;
 
 on OpenSUSE 12.1 at least.
 (MozillaFirefox-15.0.1-2.40.1.x86_64)
 
 Didn't we say no application should ever associate itself with x-scheme-
 handler/http?

That's not what we said. We said that no non-browser applications should
do that.

 This is supposed to have priority over anything else, right? (i.e. over the 
 standard mechanism of launching an app based on the file contents).
 That's fine for special protocols (magnet://, telnet:// etc.) but not for 
 HTTP... 

Why not? Sniffing HTTP URLs is completely broken. It breaks one-time
URLs.

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

Re: URL and application handling/registration standard

[Bastien Nocera]

On Mon, 2012-10-22 at 10:30 +0200, David Faure wrote:
 On Monday 22 October 2012 09:45:31 Bastien Nocera wrote:
  On Sun, 2012-10-21 at 22:58 +0200, David Faure wrote:
   On Friday 19 October 2012 17:09:50 David Faure wrote:
 Better solution yet, imho: Screw being too clever.
 
  - Have apps list protocols they support. Eg
 
 Protocols=x-scheme-handler/http;x-scheme-handler/https;

Never ever do this, for the reasons above. HTTP is too complex to send
all
http urls to a single app.
   
   Ouch, and I just found out that /usr/share/applications/firefox.desktop
   says
   
   MimeType=text/html;text/xml;application/xhtml+xml;application/vnd.mozilla.
   xul+xml;text/mml;application/x-
   xpinstall;x-scheme-handler/http;x-scheme-handler/https;x-scheme-handler/f
   tp;
   
   on OpenSUSE 12.1 at least.
   (MozillaFirefox-15.0.1-2.40.1.x86_64)
   
   Didn't we say no application should ever associate itself with x-scheme-
   handler/http?
  
  That's not what we said. We said that no non-browser applications should
  do that.
 
 I don't like it, but it doesn't matter anymore, I have fixed my patch from 
 yesterday so that x-scheme-handler doesn't have priority over KIO protocol 
 handlers, if both exist.

I think that's the wrong way to do it, but your call.

   This is supposed to have priority over anything else, right? (i.e. over
   the
   standard mechanism of launching an app based on the file contents).
   That's fine for special protocols (magnet://, telnet:// etc.) but not for
   HTTP...
  
  Why not? Sniffing HTTP URLs is completely broken. It breaks one-time
  URLs.
 
 Not if you can then give the connexion out to the app which will hande it.
 But yeah this requires that the first and second app use the same VFS.
 
 However sending all HTTP URLs to the browser is broken too - e.g. if it's a 
 .odt you end up launching a browser just to then launch the office 
 application.
 So double-download there too (of the headers at least).

You'll launch the browser, and either it will download the file and pass
it on to your office application, or (better from my point of view), the
preview is handled by within the browser (as it is in a lot of browsers
for PDFs or other types of office documents) and it offers you to
download it.


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

Re: URL and application handling/registration standard

[Bastien Nocera]

On Wed, 2012-10-03 at 22:04 +0400, Сергей Давыдов wrote:
 Feel free to read the archives of this mailing-list to know
 why adding a
 list of protocols isn't a good idea, and actually harms
 interoperability.
 
 I've found
 http://lists.freedesktop.org/archives/xdg/2008-June/009720.html thread
 where the discussion just stalled while everybody seemed to agree on
 adding a list of protocols. 
 It was also briefly brought up in 2010:
 http://lists.freedesktop.org/archives/xdg/2010-October/011661.html and
 continued in
 http://lists.freedesktop.org/archives/xdg/2010-November/011679.html +
 follow-ups. Opinions on that thread seem to be mixed.
 
 The important info I got from there is that on GNOME, XFCE, LXDE etc.
 all apps support any GIO-supported URLs, and that in GNOME's
 experience making the viewer apps download the data doesn't work.

This is the mail that I agree with:
http://thread.gmane.org/gmane.comp.freedesktop.xdg/12310/focus=12370
which pretty says we're not going to be using that in GIO even if it
exists because it's broken in many different ways.

 Is this a bug report?
 
 No. I assume I have something misconfigured, unless proven
 otherwise :)

OK.


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

Re: URL and application handling/registration standard

[Bastien Nocera]

On Sun, 2012-09-30 at 00:38 +0100, Jerome Leclanche wrote:
 There are a lot of issues with coming up with a good system for this.
 
 
 Say you get a uri to an image: http://example.com/image.png. You want
 that uri to open in an image viewer that supports http.
 
 
  - What happens if the uri isn't an image? It should instead be opened
 in a browser. But xdg-open cannot know how to open and sniff arbitrary
 protocols, so it either has to open in an http reader *first* that
 then forwards it to an image viewer, or the image viewer has to
 understand a lot more about the protocol than might be implemented.
 Confusion can arise if the image format is not supported by the image
 viewer, too (but still registered); it would forward back and forth
 between browser and image viewer.
  - The reverse has to be supported:
 http://example.com/image/?id=12345. This cannot be guessed by name, it
 has to be sniffed. Most likely scenario is it'll get opened in a web
 browser always.
 
 
 This is just for http; some protocols are much more obscure about all
 this. And you have to remember not to go overboard when integrating
 it, for users will likely want to disable this behaviour (and always
 open such and such protocol in a specific program, 

Feel free to read the archives of this mailing-list to know why adding a
list of protocols isn't a good idea, and actually harms
interoperability.


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

Re: URL and application handling/registration standard

[Bastien Nocera]

On Tue, 2012-10-02 at 17:44 +0400, Сергей Давыдов wrote:
 Behavior will largely depend on the actual program xdg-open
 delegates to.
 E.g. on KDE the KIO subsystem knows how to determine the MIME
 type of a
 resource and will look up the application associated with it.
 
 I would guess that this is also true for GNOME and their IO
 framework.
 
 It is true for GVFS; gvfs-info can detect mimetype of remote files and
 gvfs-mime is supposed to print the application associated with it, but
 the latter didn't work on my system.

Is this a bug report?


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

Re: shared-mime-info-spec: Typo »treemagic element*s*«

[Bastien Nocera]

On Mon, 2012-10-01 at 10:05 +0200, Paul Menzel wrote:
 Dear freedesktop.org folks,
 
 
 there is a typo in the second sentence in the following paragraph [1].
 
 Matching of content types works with treemagic elements, which
 are analogous to the magic elements used for MIME type matching.
 Instead of looking for byte sequences in files, treemagic
 element allow to look for files with certain names, permissions
 or mime types in a directory hierarchy.
 
 The typo is »treemagic element*s*«.
 
 Unfortunately it is not mentioned in the document, how comments/patches
 for the document should be submitted.

The spec is in shared-mime-info's git tree, so file a bug in the
freedesktop bugzilla with a patch, and we'll look at it.

Cheers

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

Re: shared mime info: URI scheme handlers for non browsers

[Bastien Nocera]

On Tue, 2011-10-18 at 13:50 +0200, Rémi Denis-Courmont wrote:
 On Tue, 18 Oct 2011 13:16:48 +0200, Pavol Babinčák
 pavol.babin...@gmail.com wrote:
  On Tue, Oct 18, 2011 at 11:12, David Faure fa...@kde.org wrote:
  Instead, the .desktop file should mention %u in the Exec line, so that
  the
  launchers know that this application supports HTTP urls.
  %s doesn't itself mean it can handle HTTP URLs, does it? Reading
  Desktop Entry Specification (I think) means it accepts argument in URL
  format. This URL can be file or any other specified in
  x-scheme-handler/* (according to Shared MIME-info Database spec). Or
  am I missing something?
 
 Yes. That is a known ambiguity with %U. You don't know which URI schemes
 actually work. I guess, that's why KDE came up with X-KDE-Protocols.

That's good, because it's not the goal of x-scheme-handler/* to defined
which protocols your application handles, just that it wants to handle
all URLs of this protocol.

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

Re: shared mime info: URI scheme handlers for non browsers

[Bastien Nocera]

On Tue, 2011-10-18 at 13:46 +0200, Rémi Denis-Courmont wrote:
 Hello,
 
 On Mon, 17 Oct 2011 23:06:24 +0200, Patryk Zawadzki pat...@pld-linux.org
 wrote:
  a) Let's have a video player that uses HTTP to download a movie and
  its subsequent play. This player should not register
  x-scheme-handler/http, right?
  b) Another video player that uses HTTP as a transport protocol for
  video streaming. This player may register x-scheme-handler/http?
  
  Claiming to handle x-scheme-handler/http is basically saying I can
  handle anything that you throw my way as long as it's HTTP.
 
 There is no applications that can handle ANYTHING over a byte stream
 protocol (file, http, ftp...). It's purely historical
 first-come-first-serve that the web browsers are the typical handler for
 HTTP.
 
 After all, a file manager or a download manager could deal with anything
 just as well as a browser - if it passes HTML pages to the browser,
 documents to the office suite, video to the media player, etc. Certainly,
 it would ruin the browsing seamless experience... just like not giving the
 media player HTTP video URLs ruins the streaming experience.

I'm not sure whether you're trying to be playful, hard to work with, or
just bashing the possibly bad wording that's in the spec. I'd rather
something constructive. If the goals of the x-scheme-handler/ mime-types
isn't clear, then I'd rather have proposals for better wording.

  That includes regular web pages so I guess the answer is that no
  media-specific application should ever register for a generic
  protocol.
 
 So how do you deal with progressive HTTP streaming? How do you deal with
 DASH, Apple Live Streaming, MMSH and you-name-it streaming over HTTP
 protocols?

You detect progressive HTTP streaming through mime-type, not URI scheme.
You handle HLS through the web browser as well, and detect it using a
mime-type, not a URI scheme.

 As far as I am concerned as a maintainer of VLC media player, this
 proposal is broken by design.

It's not a proposal, it's already in the spec. And it's not broken by
design, it's limited in design.

  We are going to stick with the KDE
 X-KDE-Protocols approach, since It Actually Makes Sense(tm) and it seems to
 work.

It doesn't replace X-KDE-Protocols.

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

Re: shared mime info: URI scheme handlers for non browsers

[Bastien Nocera]

On Mon, 2011-10-31 at 17:56 +0200, Rémi Denis-Courmont wrote:
 Le lundi 31 octobre 2011 17:45:37 Bastien Nocera, vous avez écrit :
That includes regular web pages so I guess the answer is that no
media-specific application should ever register for a generic
protocol.
   
   So how do you deal with progressive HTTP streaming? How do you deal with
   DASH, Apple Live Streaming, MMSH and you-name-it streaming over HTTP
   protocols?
  
  You detect progressive HTTP streaming through mime-type, not URI scheme.
  You handle HLS through the web browser as well, and detect it using a
  mime-type, not a URI scheme.
 
 Sure. Say you have detected that the content is for the audio player, from 
 Content-Type, or from the file extension.
 
 Now, how do you know whether the audio player supports the URI scheme or not? 
 Without something like KDE has, you will need to assume that it supports 
 every 
 URI schemes from the presence of %U, and none (other than file) otherwise.
 
 Obviously, this will fail in some cases. So some implementations might 
 instead 
 decide to download the whole file. Unfortunately, this breaks progressive 
 download. Alternatively, they could pipe it (or to provide a virtual file 
 system around it). But in some cases, even that fails as the application 
 needs 
 to do something special with the URI, as would indeed be the case for HLS, 
 DASH or MMSH.

There are many more problems with that than just knowing whether the
application supports the protocol (or a subset of the protocol). What
about passing cookie that the website might use for authentication?

In any case, it's not what x-scheme-handler is trying to solve.
 
   As far as I am concerned as a maintainer of VLC media player, this
   proposal is broken by design.
  
  It's not a proposal, it's already in the spec. And it's not broken by
  design, it's limited in design.
  
We are going to stick with the KDE
   
   X-KDE-Protocols approach, since It Actually Makes Sense(tm) and it seems
   to work.
  
  It doesn't replace X-KDE-Protocols.
 
 I think we have to agree on that.

And I hope you'll still be adding x-scheme-handler/mms and the likes
to VLC, because that's what a lot of web browsers will be using to
determine which applications support which of those very specialised
protocols.

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

Re: shared mime info: URI scheme handlers for non browsers

[Bastien Nocera]

On Mon, 2011-10-31 at 18:16 +0200, Rémi Denis-Courmont wrote:
 Le lundi 31 octobre 2011 18:05:41 Bastien Nocera, vous avez écrit :
  There are many more problems with that than just knowing whether the
  application supports the protocol (or a subset of the protocol). What
  about passing cookie that the website might use for authentication?
  
  In any case, it's not what x-scheme-handler is trying to solve.
 
 I got that. I'm concerned that every file manager will lack this (except 
 KDE), 
 just because one (?) desktop refuses to standardize it though.

Because it's broken, mostly. David already explained the reasons why it
was broken, and nothing changed since then:
http://article.gmane.org/gmane.linux.xdg.devel/12370/

  And I hope you'll still be adding x-scheme-handler/mms and the likes
  to VLC, because that's what a lot of web browsers will be using to
  determine which applications support which of those very specialised
  protocols.
 
 VLC 1.2 has both X-KDE-* with the full list and handlers with only RTSP, RTMP 
 and MMS.

Cool.

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

Re: [PATCH] xdgmime: Add autotools-based build system.

[Bastien Nocera]

On Tue, 2011-03-01 at 09:49 +0100, Thierry Reding wrote:
 Just some more info about the idea behind this. Apparently, there is no
 standard library for accessing the database provided by shared-mime-info. So
 with xdgmime seeming like the reference implementation, it would be nice to
 have an actual release tarball that people can use.
 
 I am willing to help out with this, though I don't have a freedesktop.org
 account and cannot commit (or upload release tarballs) myself.

xdgmime is meant to be copy/pasted, or reimplemented. It doesn't make
sense for it to be a library, so it doesn't make sense for it to have
releases.

Cheers

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

Re: shared mime info: URI scheme handlers for non browsers

[Bastien Nocera]

On Mon, 2011-10-17 at 23:06 +0200, Patryk Zawadzki wrote:
 On Mon, Oct 17, 2011 at 8:23 PM, Scrool scroo...@gmail.com wrote:
  I'd like to ask you for clarification of URI scheme handlers section
  in Shared MIME-info Database spec. Quote from last paragraph:
 
  Note that this virtual mime-type is not for listing URI schemes that
  an application can load files from. For example, a movie player would
  not list x-scheme-handler/http in its supported mime-types, but it
  would list x-scheme-handler/rtsp if it supported playing back from
  RTSP locations.
 
  a) Let's have a video player that uses HTTP to download a movie and
  its subsequent play. This player should not register
  x-scheme-handler/http, right?
  b) Another video player that uses HTTP as a transport protocol for
  video streaming. This player may register x-scheme-handler/http?
 
 Claiming to handle x-scheme-handler/http is basically saying I can
 handle anything that you throw my way as long as it's HTTP. That
 includes regular web pages so I guess the answer is that no
 media-specific application should ever register for a generic
 protocol.

Exactly. Other examples include media-only streaming schemes. The
media player would probably claim to handle x-scheme-handler/rtsp
because it handles all types of RTSP URLs.

Cheers

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

Re: Questions regarding the shared mime spec

[Bastien Nocera]

On Mon, 2011-09-26 at 10:07 +0200, Alexander Larsson wrote:
 On Sun, 2011-09-25 at 09:08 +0200, David Faure wrote:
snip
  I just committed it, but I'm attaching the patch so that Alexander or 
  Bastien 
  can review it, this is my first commit to xdgmime [which seems to still be 
  in 
  CVS? I thought everything had moved to git?]

I'm just a person who wanted to get some video and audio types in
shared-mime-info, I've tried to avoid reading the xdgmime code :)

 Weird. I have an old clone here pointing at:
 ssh://al...@git.freedesktop.org/git/mime/xdgmime.git
 But that doesn't seem to exist anymore??

It's been moved under /git/xdg/xdgmime.git by somebody who didn't tell
me that it moved either... See http://cgit.freedesktop.org/xdg/xdgmime/

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

Re: Showing a file in the file manager

[Bastien Nocera]

On Thu, 2011-09-22 at 15:09 +0200, Kevin Krammer wrote:
 On Thursday, 2011-09-22, Jannis Pohlmann wrote:
 
  IMHO that's a bad idea. Bypassing DE-specific checks and forwarding
  straight to the FileManager1 service means that, on a multi-user system
  with multiple file managers installed, people may easily end up
  launching file managers other than the one they expect to see.
  
  The same problem occurs if applications start using the FileManager1
  service for opening folders directly (and other features that we might
  add to the interface in the future). Let's say a GNOME application does
  that and both, Nautilus and Thunar are installed. Which one is going to
  pop up? Is there any solution to this?
 
 As long as none of the file managers installs a D-Bus service file for the 
 given interface there shouldn't be any problem.
 The call will either go to an already running file manager, which we can then 
 savely assume to be the correct one, or fail.

Which is absolutely useless for GNOME 3.x as nautilus (our file manager)
doesn't run by default.

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

Re: XDG_CURRENT_DESKTOP

[Bastien Nocera]

On Thu, 2011-07-14 at 11:36 -0400, Michael Terry wrote:
 Hello!  I've seen the idea of a XDG_CURRENT_DESKTOP environment variable 
 tossed around a few times on this mailing list, but I don't see it in 
 any spec.
 
 Historically, most desktop file parsing libraries were tightly tied to a 
 desktop and were able to assume which XDG desktop they were in (e.g. 
 libgmenu assumes 'GNOME').
 
 However in Unity, it uses most of the same libraries but still wants the 
 ability to respect OnlyShowIn=Unity.  So there's a need for those 
 libraries to detect which desktop is running.  The easiest/quickest way 
 is to use an environment variable like XDG_CURRENT_DESKTOP.
 
 I have some ideas on how such a variable might work:

What's the use for this when you could add a set_desktop_name()
function in the front-end that uses that library?
Is it of any use apart from libgnome-menus?

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

Re: XDG_CURRENT_DESKTOP

[Bastien Nocera]

On Thu, 2011-07-14 at 11:46 -0400, Michael Terry wrote:
 On 07/14/2011 11:42 AM, Bastien Nocera wrote:
  What's the use for this when you could add a set_desktop_name() 
  function in the front-end that uses that library? Is it of any use 
  apart from libgnome-menus? 
 
 Well, say there's an app FooBar that uses libgnome-menus.  How does 
 FooBar know which desktop it's in?

Application FooBar being?

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

Re: Relative paths in .desktop files

[Bastien Nocera]

On Thu, 2011-06-23 at 15:30 +0200, David Faure wrote:
 On Thursday 23 June 2011, you wrote:
  If you just want to give the script an icon, you can embed
  the icon in the script, and write a thumbnailer for it.
  IMHO, having run_me.sh in the folder is enough.
  Having run_me.sh, run_me.desktop, and run_me.png in the folder
  won't increase usability.
  
  There are several ways to embed an icon in a script file. Just apend
  it to the end of file, or encode it with base64 or some others. Then
  having a thumbnailer decode such thing won't be too difficult. By
  adding a comment line containing specific strings in the script,
  during mime-type sniffing, it's easy to recognize this kind of file
  with mime-type magic rules.
 
 You know, not everyone is a developer. I am, but most people just want the 
 *simplest* way to create an icon shortcut which launches something.
 
 Think of the usability for the creator of the shortcut too, not only the 
 usability for the end user (who just clicks on something anyway).
 
 Writing a thumbnailer, or encoding an icon with base64, is nowhere as simple 
 as writing out with a text editor (or a standard properties dialog)
 Exec=./foo.sh
 Icon=some-standard-icon
 
 KISS :-)
 
 If some desktops want to also offer something at a higher-level that's fine, 
 but 
 not everything should need a GUI, in the Unix world. There's a strong use 
 case 
 for being able to do things from a command-line, in text mode, as well.

I'm fine with relative paths. As long as you can't reference files in
parent directories, only ever children nodes, then it's fine by me.

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

Re: [RFC] XDG basedir spec should mandate absolute paths

[Bastien Nocera]

On Thu, 2011-04-07 at 03:53 +0200, Lennart Poettering wrote:
 Heya,
 
 currently the xdg basedir spec doesn't make clear that all env vars need
 to be set to absolute paths.
 
 Anybody opposed if I add a small sentence whith clears that up?
 
 Background:
 
 https://bugzilla.gnome.org/show_bug.cgi?id=646950

I'd like to add that whether or not Totem would crash with a relative
path is beyond the point. I believe that the spec should require an
absolute path, and GLib should print out a warning, and use the default
path if the envvar is invalid.

Cheers

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

Re: Adding Unity to OnlyShowIn allowed values

[Bastien Nocera]

On Wed, 2011-03-02 at 10:25 -0600, Ted Gould wrote:
 On Sat, 2011-02-19 at 10:26 +0100, Vincent Untz wrote:
  Le vendredi 18 février 2011, à 22:26 -0600, Ted Gould a écrit :
   On Thu, 2011-02-17 at 08:52 -0600, Ted Gould wrote:
We would like to add Unity to the list of values allowed for
OnlyShowIn in the menu spec.  While Unity is mostly GNOME based there
are cases where we'd like some desktop files and menus that GNOME does
not so the distinction is relevant.  Patch attached (it's huge!)
   
   Haven't seen any objection on this, I'm guessing it's not because people
   are scared of my good looks.  Sound good to everyone?
  
  We usually wait a week or so to make sure everyone has time to object
  :-)
 
 I haven't seen any objection, just questions to this.  Final call?

Your original explanation:
 The use that pushed me to write the patch/email was with the Desktop
 Actions that we're putting in desktop file for static actions on the
 Launcher.  Unfortunately, it's still an X- thing but I intend to
 update
 it to the current version of the Desktop Actions spec soon (because of
 release timing we needed something too quickly).  In the actions that
 we've added and sent upstream we've been adding an OnlyShowIn=Unity
 to
 ensure they won't effect other projects.  I have suggested a couple of
 times that GNOME Shell should use the same actions, but I don't
 believe
 they currently are.
 
 I think longer term, we'd like to do things like have multiple desktop
 files for applications that provide major features.  Things like
 Evolution providing mail and calendar.  GNOME Shell's matching doesn't
 allow for two desktop files for an executable, but we can do that with
 BAMF.  So we could make the second desktop file Unity only.

It seems to me that you should be using OnlyShowIn=GNOME, and either
you, or the first person to experience it, would file a bug against
gnome-shell about this problem.

I don't think that adding another value here is needed.

Cheers

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

Re: .desktop file: supported URL schemes key

[Bastien Nocera]

On Mon, 2010-10-11 at 13:08 +0200, David Faure wrote:
 The recent discussion raises again something that has been a need for a very 
 long time.
 
 Some programs support URLs (Exec=foo %u) but not all URLs.
 For instance VLC supports http, ftp, and smb.
 We need to know that we can pass it such URLs, and not others.
 
 I would like to propose a key UrlSchemes in the desktop entry standard,
 as a ;-separated list of supported URL schemes. For instance, for vlc:
 UrlSchemes=http;ftp;smb;

This problem pretty much doesn't exists in GNOME, as:
- either a local FUSE URI will be passed to the program (eg. opening
smb://myserver/myshare/foobar.txt will actually pass the URI version of
~/.gvfs/myshare on my server/foobar.txt)
- or the supported schemes are listed using the x-schema-handler/ stuff

This means that you would only have problems when launching GNOME apps
under KDE, but not when running in GNOME, XFCE, LXDE (which use gvfs).

Again, that's probably only a problem if KDE didn't get FUSE support for
KIO since the last time I looked at it.


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

Re: extending mime-type def with generic-icon

[Bastien Nocera]

On Sun, 2010-10-17 at 21:24 -0400, Matthew Monaco wrote:
 This is my first foray into mime-types. I am trying to add a new .xml file to
 /usr/share/mime/packages:
 
 =
 ?xml version=1.0 encoding=UTF-8?
 mime-info xmlns='http://www.freedesktop.org/standards/shared-mime-info'
 
  mime-type type=text/x-matlab
  commentMATLAB script/function/comment
  sub-class-of type=text/plain/
  magic priority=10
  match value=% type=string offset=0/
  /magic
  magic priority=50
  match value=function type=string offset=0/
  /magic
  glob pattern=*.m weight=60/
  alias type=text/x-octave/
  generic-icon name=matlab-m/
  /mime-type
 
  mime-type type=image/x-matlab-fig
  commentMATLAB figure/comment
  magic priority=50
  match value=MATLAB type=string offset=0/
  /magic
  glob pattern=*.fig weight=60/
  generic-icon name=matlab-fig/
  /mime-type
 
  mime-type type=application/x-matlab-data
  commentMATLAB data file/comment
  magic priority=50
  match value=MATLAB type=string offset=0/
  /magic
  glob pattern=*.mat weight=60/
  generic-icon name=matlab-mat/
  /mime-type
 
 /mime-info
 =
 
 1) Is it legal to define text/x-matlab here since it's already in 
 freedesktop.org.xml? If so, am I adding to the definition, or completely 
 overriding it? Which def would take priority?

It should take over it (but that's not the problem here).

 2) I'm having trouble with the generic-icon feature. My icon for the .mat 
 file 
 works fine, but the icons for .m and .fig files are not working. The icons 
 are 
 in /usr/share/icons/hicolor/{16x16...256x256}/mimetypes/*.png.

The generic-icon feature is not there to theme your mime-types. From:
http://specifications.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-0.20.html


   * generic-icon elements specify the icon to use as a generic
 icon for this particular mime-type, given by
 the name attribute. This is used if there is no specific icon
 (see icon for how these are found). These are used for
 categories of similar types (like spreadsheets or archives)
 that can use a common icon. The Icon Naming Specification
 lists a set of such icon names. If this element is not
 specified then the mimetype is used to generate the generic
 icon by using the top-level media type (e.g. video in
 video/ogg) and appending -x-generic (i.e.
 video-x-generic in the previous example). Only
 one generic-icon element is allowed.

Your items will already be assigned the text-x-generic icon. Follow
the icon theme specification to assign icons to your mime-types.

Cheers

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

Re: New handling for URI scheme handlers

[Bastien Nocera]

On Mon, 2010-10-11 at 23:59 +0200, David Faure wrote:
 On Friday 08 October 2010, Bastien Nocera wrote:
  On Tue, 2010-10-05 at 16:32 +0100, Bastien Nocera wrote:
   Heya,
   
   This morning I implemented in GNOME use of the x-scheme-handler/*
   mime-type for applications to register their interest in handling
   particular URI schemes.
   
   I posted about it in:
   http://www.hadess.net/2010/10/new-control-center-and-you.html
   And have a blocker bug for GNOME applications in:
   https://bugzilla.gnome.org/show_bug.cgi?id=631433
   
   The attached patch is changes to the shared-mime-info spec to mention
   the use of x-scheme-handler/* mime-types.
   
   Any comments?
  
  I committed the changes to the spec to shared-mime-info, with the
  addition of a clarification paragraph to mention that the mime-type
  should not be used to advertise supported URI schemes.
 
 I just committed support for x-scheme-handler/* to KDE, it will be in KDE SC 
 4.6.

Thanks, much appreciated.

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

Re: New handling for URI scheme handlers

[Bastien Nocera]

On Tue, 2010-10-05 at 16:32 +0100, Bastien Nocera wrote:
 Heya,
 
 This morning I implemented in GNOME use of the x-scheme-handler/*
 mime-type for applications to register their interest in handling
 particular URI schemes.
 
 I posted about it in:
 http://www.hadess.net/2010/10/new-control-center-and-you.html
 And have a blocker bug for GNOME applications in:
 https://bugzilla.gnome.org/show_bug.cgi?id=631433
 
 The attached patch is changes to the shared-mime-info spec to mention
 the use of x-scheme-handler/* mime-types.
 
 Any comments?

I committed the changes to the spec to shared-mime-info, with the
addition of a clarification paragraph to mention that the mime-type
should not be used to advertise supported URI schemes.

Cheers

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

New handling for URI scheme handlers

[Bastien Nocera]

Heya,

This morning I implemented in GNOME use of the x-scheme-handler/*
mime-type for applications to register their interest in handling
particular URI schemes.

I posted about it in:
http://www.hadess.net/2010/10/new-control-center-and-you.html
And have a blocker bug for GNOME applications in:
https://bugzilla.gnome.org/show_bug.cgi?id=631433

The attached patch is changes to the shared-mime-info spec to mention
the use of x-scheme-handler/* mime-types.

Any comments?

Cheers
From 7ec2f22dab71e8c40a4154fe5a92819ed80fbaa7 Mon Sep 17 00:00:00 2001
From: Bastien Nocera had...@hadess.net
Date: Tue, 5 Oct 2010 16:29:11 +0100
Subject: [PATCH] Add mentions of x-scheme-handler/ in spec

---
 shared-mime-info-spec.xml |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/shared-mime-info-spec.xml b/shared-mime-info-spec.xml
index 0254421..9f31e44 100644
--- a/shared-mime-info-spec.xml
+++ b/shared-mime-info-spec.xml
@@ -983,6 +983,19 @@ hierarchy.
 		/para
 	/sect2
 	sect2
+		titleURI scheme handlers/title
+		para
+URI scheme handling (such as a movie player handling mms:// URIs, or a Podcast program 
+handling feed:// URIs) are handled through applications handling the x-scheme-handler/foo
+mime-type, where foo is the URI scheme in question.
+		/para
+		para
+This scheme allows URI scheme handling to enjoy the same benefits as mime-type handlers,
+such as the ability to change the default handler, the cross-desktop support, and
+easier application launching.
+		/para
+	/sect2
+	sect2
 		titleSecurity implications/title
 		para
 The system described in this document is intended to allow different programs
-- 
1.7.2.3

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

Re: New handling for URI scheme handlers

[Bastien Nocera]

On Tue, 2010-10-05 at 17:36 +0200, Damjan Jovanovic wrote:
 On Tue, Oct 5, 2010 at 5:32 PM, Bastien Nocera had...@hadess.net wrote:
  Heya,
 
  This morning I implemented in GNOME use of the x-scheme-handler/*
  mime-type for applications to register their interest in handling
  particular URI schemes.
 
  I posted about it in:
  http://www.hadess.net/2010/10/new-control-center-and-you.html
  And have a blocker bug for GNOME applications in:
  https://bugzilla.gnome.org/show_bug.cgi?id=631433
 
  The attached patch is changes to the shared-mime-info spec to mention
  the use of x-scheme-handler/* mime-types.
 
  Any comments?
 
  Cheers
 
  ___
  xdg mailing list
  xdg@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/xdg
 
 
 
 I love it. Does it work in KDE?

Not sure what you mean exactly. But if your app registered
x-scheme-handler/foo and you tried to launch it using a GIO-based
application, it would be considered at the same level as a GNOME
application.

I don't know which process KDE itself uses to register URI scheme
handlers, but I'm guessing it's either something similar, or another key
in .desktop file. Am I correct?

Cheers

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

Re: New handling for URI scheme handlers

[Bastien Nocera]

On Tue, 2010-10-05 at 18:01 +0200, Thiago Macieira wrote:
 Em Terça-feira 05 Outubro 2010, às 17:36:52, Damjan Jovanovic escreveu:
  On Tue, Oct 5, 2010 at 5:32 PM, Bastien Nocera had...@hadess.net wrote:
   Heya,
   
   This morning I implemented in GNOME use of the x-scheme-handler/*
   mime-type for applications to register their interest in handling
   particular URI schemes.
   
   I posted about it in:
   http://www.hadess.net/2010/10/new-control-center-and-you.html
   And have a blocker bug for GNOME applications in:
   https://bugzilla.gnome.org/show_bug.cgi?id=631433
   
   The attached patch is changes to the shared-mime-info spec to mention
   the use of x-scheme-handler/* mime-types.
   
   Any comments?
 
  I love it. Does it work in KDE?
 
 No.
 
 KDE requires that you install a .protocol file (which is just a .desktop file 
 with a different extension) in /usr/share/kde4/services.

I should add that using a mime-type means that you get to have an
mmap'ed binary cache, which is probably the only gain above the KDE
implementation.

And you could keep both implementations as well...

Cheers

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

Re: New handling for URI scheme handlers

[Bastien Nocera]

On Tue, 2010-10-05 at 18:27 +0200, David Faure wrote:
 On Tuesday 05 October 2010, Bastien Nocera wrote:
  Heya,
  
  This morning I implemented in GNOME use of the x-scheme-handler/*
  mime-type for applications to register their interest in handling
  particular URI schemes.
  
  I posted about it in:
  http://www.hadess.net/2010/10/new-control-center-and-you.html
  And have a blocker bug for GNOME applications in:
  https://bugzilla.gnome.org/show_bug.cgi?id=631433
  
  The attached patch is changes to the shared-mime-info spec to mention
  the use of x-scheme-handler/* mime-types.
 
 I'm in favour of the addition if it's only used in these special cases you 
 mention, where we want to send *all* urls with a given scheme to an 
 application, so this indeed *replaces* any mimetype-based lookup.
 
 This is orthogonal to the use cases like we have a HTTP URL pointing to an 
 image, we need an application which supports image/png -and- which supports 
 HTTP - this is another unresolved issue (in KDE we started using X-KDE-
 Protocols for that, but let's talk about that in another thread, to not mix 
 up 
 the issues). In that case both criterias must be met, so 
 x-scheme-handler/http 
 would not work if it's just another mimetype, this is why I'm clearly 
 separating the two issues.

Right, completely agreed here, though that particular problem isn't so
visible on GNOME, given that we can access files through FUSE when gvfs
supports the protocol/scheme.

 But to come back to your use case, all urls with a given scheme, no mimetype 
 at all, then OK. I just hope nobody installs a desktop file with x-scheme-
 handler/http ever...

Apart from web browsers, nothing should. And the cleverness for that
particular codepath is still there.

The main use though would be when applications handle *all* the files on
the URI scheme, such as:
- MMS, RTSP, RTP URIs - movie player
- FEED, ZCAST, ITPC - podcast manager
- MAILTO - mail client
etc.

Cheers

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