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

[Stefan Blachmann]

Good suggestion! Will do that!

On 5/8/21, David Faure  wrote:
> On mercredi 5 mai 2021 19:16:34 CEST Stefan Blachmann wrote:
>> I have looked at the xdg-open script.
>>
>> I'd like best if I could just set an environment variable XDG_OPEN to
>> another program.
>> So xdg-open just passes through to my script.
>
> This makes sense. In theory all implementations called by xdg-open implement
>
> the same spec, but not the "desktop-specific fallbacks". So it makes
> sense to redirect to your own implementation in other desktop environments.
>
>> So I kindly ask, could there be added such an environment variable
>> XDG_OPEN specifying an alternative handler, to allow non-mainstream
>> DE/WMs handle the open dialog themselves?
>
> Make a merge request for https://gitlab.freedesktop.org/xdg/xdg-utils/
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>
>
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

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

[Stefan Blachmann]

Some thoughts.

There are several "usage criteria" that could be used for ordering.
In a situation when one just wants to quickly view something then the
criteria are different ones when one wants to edit. Some people prefer
simplicity. Others prefer feature-completeness. And so on.
I doubt that  these different "usage criteria" (maybe an alternative
term for "intents"?) can be combined in one valid-for-all number.

There have been identified some usage criteria parameters:
- view ... edit  (some viewers allow simple editing too, so this is
also sort of a scale)
- degree of format support/feature completeness
- user interface (console-ish ... KDE-ish ... Gnome-ish)
- and probably more (TBD: find them)

Compared to a more-or-less arbitrary single [in]valid-for-all number,
such kind of parameters are easily definable and reasonably accurately
measurable.

If the spec allows a number of these most important characterizations,
these can be used in conjunction with the users' settings to determine
an appropriate application suitability list.

In my inner eye I now see a Gnome-ish simple configuration with a few
sliders where the user can set these preferences. So this could be
very easily configurable, too.


What I *definitely* like is the possibility of deprioritizing
particularly uncommonly used mime types/applications combos, like
text/plain+LibreOffice, or text/pdf and GIMP.


If the specification would allow association of apps to their "native"
DE, e.g. apps that belong to a particular DE, and DE-independent apps,
that would be *very* nice, too.

Because, the apps in the OpenWith list could then be sorted depending
on the users' DE preferences.
For example, DE-independent-apps > DE1 apps > DE2 apps  > DE3 apps.
This surely would make a much more orderly impression than the current
random chaos.

The possibility to show in the menu the application-associated DE
(e.g. Okular [KDE], Evince [Gnome], ...) might also be nifty.

On 5/8/21, David Faure  wrote:
> On samedi 8 mai 2021 14:53:39 CEST Jehan Pagès wrote:
>> On Sat, May 8, 2021 at 11:18 AM David Faure  wrote:
>> > But as soon as two applications are installed, which both claim level 2,
>> > or both claim level 1 (with no level 2 available), this proposal would
>> > just
>> > move the problem, because we again don't know which one to prefer.
>>
>> Of course. But why is it a problem? Computers don't read in people's minds
>> (and I sure hope they never will! ). So yes, if you installed 2 software
>> which support .odt as native format (a good example because there are
>> actually several software with ODT as native format), I sure don't want my
>> computer to assume a *better* for me. This is the limit of what my
>> computer
>> is able to do for me.
>
> It's not "the computer" which would assume, it's people with an actual
> biological brain would would have done that for you, to avoid bad surprises.
> That's exactly the topic of this conversation: humans making choices rather
> than "the computer" randomly selecting one of the installed apps.
>
>> Basically such numbers make no sense because we cannot exactly map a
>> support level to such degree of accuracy. It will just be random numbers
>> in
>> the end.
>
> Numbers which are used to define a priority order. What matters is the
> order,
> not the absolute numbers per se.
>
>> Also such number system really implies quantifying the format support,
>> this
>> is not what my initial proposal is about. It is about the "intent". For
>> instance, PSD is definitely the kind of format which is intended to be
>> edited in a software as GIMP. E.g. maybe some image viewer software are
>> able to display PSD, but the chances that someone with a PSD file wants to
>> open it in a viewer rather than an image editor is low. So if you have
>> Photoshop itself, it's ideal (native format). If you don't, GIMP or alike
>> may be your best bet. But this is the "intent". We are not talking about
>> level of support (which is a very complicated topic we should not go
>> into).
>> And these should not be mixed, which IMO your point system would end up
>> looking like.
>
> You're adding meaning where there isn't. I never talked about quantifying
> format support. We are both talking about defining a preference order that
> is
> most likely to make sense for the user. Your assumption however is that 3
> levels are enough for this.
>
>> Basically for a desktop, yes numbers can represent preferences, not
>> necessary level of support. But for the proposal I had, numbers
>> representing preferences don't make sense. I mean, as software developers,
>> then I would just put our software as main preferences because that's
>> obviously how we use it ourselves. So using your description above ("if
>> it's not your native mimetype, then the number should be below 20", and
>> "if
>> not a mimetype where it makes sense for your app to be default […], then
>> it
>> should be below 10"), I would put native formats as 20, all "same intent"

Re: New `MimeType` fields in .desktop

[Stefan Blachmann]

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

This is why my opinion is that the correct and simplest way to deal
with that mess is not introducing more complicated configuration
bureaucracy, instead just respecting (e.g. memorizing) your preference
for each file type/format you showed by using OpenWith.

(That problem annoyed me much, and the desire of having some "Recently
used/opened" mechanisms was one of the reasons why I wrote my own
solution "Meow", a complete replacement for xdg-menu for FVWM.)

Again my question:
What is the correct way to make xdg-open pass through to my script?

Because, as far as I can see, without a defined mechanism to do this,
my only option would be to delete/replace the xdg-open file.
Which is no good solution because it causes conflicts with package managers etc.
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Stefan Blachmann]

I have looked at the xdg-open script.

I'd like best if I could just set an environment variable XDG_OPEN to
another program.
So xdg-open just passes through to my script.

I ask because, instead of using xdg-open, I would like to use my
personal app chooser for my Meow menu+filebrowser for FVWM.
Meow keeps LRU lists for the preferred apps for every and each
mime/file type.
So the default app is the last-used for any particular file type, and
the most-recently used apps for that file type are always at top in
the OpenWith list.
This solution imho best adapts to the users' personal preferences.

Because, who doesn't hate the bad UX when, for example xdg-open thinks
GIMP is the right app to view a PDF file :)

So I kindly ask, could there be added such an environment variable
XDG_OPEN specifying an alternative handler, to allow non-mainstream
DE/WMs handle the open dialog themselves?


On 5/4/21, Stefan Blachmann  wrote:
> When I search the web, I find little information about this topic, so
> I am not sure whether I understand you all correctly.
> If anybody can give me a pointer where I can read about xdg-open
> (documentation, specifications, etc), I'd be grateful.
>
> Here my thoughts:
> Shouldn't the DE, respective the file manager keep a LRU sorted list
> of applications for each mime/file type, so that it sort of
> "memorizes" and respect the users' favorite apps?
> So the list of the applications shown on "Open With" should reflect
> what the particular user *actually* prefers to use, and present this
> topmost.
>
> Some, like KDE, do not do this. So the user often has to go through
> the app choosing menus each and every time (s)he wants to open a
> particular file type.
>
> This is very annoying.
> But imho it's an implementation deficiency of the DE and not of the
> specification.
>
> Just to use the initial example of XCF files: if you want to just view
> the file, using GIMP is overkill over using a simple viewer app.
> So, the imho initial proposal would add a *lot* of complexity, only to
> be overridden by the individual users' choice anyway.
>
> However, for this to work, the particular DE/application chooser must
> not be deficient, instead it must store the users' choices in its LRU
> list for later invocations.
>
> Imho xdg-open should just ask the interface script of the current DE
> or application chooser for the preference-sorted app list for the
> particular file/mime type, and use that list.
> The DE/application chooser should remember the individual users'
> choices, to respect these in subsequent invocations.
>
> Again, I believe the problem is not the standard, but the laziness of
> the DE/application choosers not to store/memorize the previous user
> choices.
>
> So I am not sure what to think about a real solution to that
> long-standing issue.
>
> Wouldn't it be a better solution to add a specification in XDG that
> defines how to store individual users' application preference LRU
> lists for each mime/file type, which thus can keep the individual
> users' preferences, even when switching to another DE/application
> chooser?
>
>
> On 5/4/21, Thomas Kluyver  wrote:
>> On Mon, 3 May 2021, at 20:36, Eli Schwartz wrote:
>>> Once all levels have been checked, if no entry could be found, the
>>> implementations MUST query the user to pick one of the .desktop files
>>> associated with the mimetype, taking into account added and removed
>>> associations as per the next section. Optionally, the implementation may
>>> and probably should then default to saving this to "user overrides
>>> (recommended location for user configuration GUIs)".
>>
>> I don't think there's really any point writing MUST. The spec can
>> recommend
>> things, but no-one can force desktops to follow it if they don't think
>> that
>> behaviour provides the best experience. There's certainly a case for
>> prompting the user to decide, but the place to make that case first is to
>> the desktops which could actually implement it (assuming most users don't
>> reach the generic fallback in xdg-open).
>>
>>> In the xdg-open program, update open_generic() to comply with the new
>>> version of the mime apps spec, by e.g. spawning a zenity selection
>>> dialog. If zenity is not installed, a CLI dialog could be printed...
>>
>> I suspect that adding pop-up dialogs to something that didn't previously
>> use
>> them is going to cause some issues. It also means that you would need
>> another level of detection & fallback (zenity/kdialog, terminal prompts)
>> inside what's already a fallback. And you probably still want an ultimate
>> fallback where n

Re: New `MimeType` fields in .desktop

[Stefan Blachmann]

When I search the web, I find little information about this topic, so
I am not sure whether I understand you all correctly.
If anybody can give me a pointer where I can read about xdg-open
(documentation, specifications, etc), I'd be grateful.

Here my thoughts:
Shouldn't the DE, respective the file manager keep a LRU sorted list
of applications for each mime/file type, so that it sort of
"memorizes" and respect the users' favorite apps?
So the list of the applications shown on "Open With" should reflect
what the particular user *actually* prefers to use, and present this
topmost.

Some, like KDE, do not do this. So the user often has to go through
the app choosing menus each and every time (s)he wants to open a
particular file type.

This is very annoying.
But imho it's an implementation deficiency of the DE and not of the
specification.

Just to use the initial example of XCF files: if you want to just view
the file, using GIMP is overkill over using a simple viewer app.
So, the imho initial proposal would add a *lot* of complexity, only to
be overridden by the individual users' choice anyway.

However, for this to work, the particular DE/application chooser must
not be deficient, instead it must store the users' choices in its LRU
list for later invocations.

Imho xdg-open should just ask the interface script of the current DE
or application chooser for the preference-sorted app list for the
particular file/mime type, and use that list.
The DE/application chooser should remember the individual users'
choices, to respect these in subsequent invocations.

Again, I believe the problem is not the standard, but the laziness of
the DE/application choosers not to store/memorize the previous user
choices.

So I am not sure what to think about a real solution to that
long-standing issue.

Wouldn't it be a better solution to add a specification in XDG that
defines how to store individual users' application preference LRU
lists for each mime/file type, which thus can keep the individual
users' preferences, even when switching to another DE/application
chooser?


On 5/4/21, Thomas Kluyver  wrote:
> On Mon, 3 May 2021, at 20:36, Eli Schwartz wrote:
>> Once all levels have been checked, if no entry could be found, the
>> implementations MUST query the user to pick one of the .desktop files
>> associated with the mimetype, taking into account added and removed
>> associations as per the next section. Optionally, the implementation may
>> and probably should then default to saving this to "user overrides
>> (recommended location for user configuration GUIs)".
>
> I don't think there's really any point writing MUST. The spec can recommend
> things, but no-one can force desktops to follow it if they don't think that
> behaviour provides the best experience. There's certainly a case for
> prompting the user to decide, but the place to make that case first is to
> the desktops which could actually implement it (assuming most users don't
> reach the generic fallback in xdg-open).
>
>> In the xdg-open program, update open_generic() to comply with the new
>> version of the mime apps spec, by e.g. spawning a zenity selection
>> dialog. If zenity is not installed, a CLI dialog could be printed...
>
> I suspect that adding pop-up dialogs to something that didn't previously use
> them is going to cause some issues. It also means that you would need
> another level of detection & fallback (zenity/kdialog, terminal prompts)
> inside what's already a fallback. And you probably still want an ultimate
> fallback where none of the GUI dialog tools are available and it's not
> running in a tty.
>
>> This change may very well obsolete much of the micro industry that has
>> grown up around xdg-open, where the sole purpose of a program is to
>> provide an alternative xdg-open that does not respect the xdg mimeapps
>> spec, but uses custom rules (generally a mix of regex and desktop entry
>> hints) and prompts the user on ambiguity, because their authors are
>> positive that xdg-open is the literal devil and will never open the
>> right thing ever.
>
> I may be wrong, but I'd guess that the mystery of xdg-open is more because
> it's a wrapper around a bunch of different desktop-specific tools with their
> own peculiarities. xdg-open could be effectively a different tool on my
> machine and yours, even if we have the same xdg-utils package from the same
> distro. Maybe it would have been better to implement xdg-open as a
> standalone tool rather than a wrapper around desktop tools, but I imagine
> that ship has long since sailed.
>
> (And of course, there's nothing particularly wrong with people using other
> launcher tools if they want to - though I agree it's worth thinking about
> whether that points to problems with the default mechanisms.)
>
> Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

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

[Stefan Blachmann]

Hi!

All DMs and OSes (Windows, MacOS) provide a menu for recently used files.
The freedesktop "Recent File Storage Specification" was probably
intended as an unified means to provide freedesktop software users
with access to recently used files via a start menu.
The specification is here:
https://specifications.freedesktop.org/recent-file-spec/recent-file-spec-0.2.html

However, the concept is broken from the beginning.
The factual inclusion of the browsing history renders it useless.

Actual recent documents get shoved out of the list by broswing trash in no time.
The lists' small size (~70 entries) in actual distributions aggravates
the problem a lot.
So the well-intended concept in practice degenerates into a redundant
browser history, which nobody needs.

For this reason neither KDE nor Gnome appear to make use of that
broken-by-concept Freedesktop "Recent File Storage Specification" to
generate their "Recent" menus.
Instead they use their proprietary solutions.

So the concept should be corrected to be actually practical.
Definitely clear is that the browsers' history data belongs into
another file, say, ~/.RecentlyVisitedURLs.


Why am I posting this?
I am working on a start menu script for FVWM.
I need to find a temporary solution to fix the problem, until the
specification got corrected and browser makers updated their software
accordingly.

Do you think that a cron script that regularly filters
"~/.recently-used" would be appropriate?
Its task would be to separate the data in "~/.recently-used" into two files:

-the actually user-generated or locally-stored documents that have
been accessed or worked on by non-browser software. This "List of
Files Recently Used by Me" then could keep the files that were moved
out of the "~/.recently-used" file by web history trash and provide
the user with an actually usable recently-used-files list.
-the web page history which the start menu then can combine with a
convenient "Open With Browser..." option.

Do you know less-awkward solutions to the problem?

I'd be really grateful about a discussion how to fix the specification.

Thank you,
Stefan
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Seeking clarification of Desktop Entry Specification

[Stefan Blachmann]

Regarding (2):
I have found both kinds of whitespace in desktop entry files. So, as a
practical matter, both SPACEs and TABs need to be filtered out when
reading these files.

On 4/24/20, Stephan Bergmann  wrote:
> I have three questions regarding
> :
>
> (1)  #basic-format says "A file is interpreted as a series of lines that
> are separated by linefeed characters."  #value-types says "The escape
> sequences \s, \n, \t, \r, and \\ are supported for values of type string
> and localestring, meaning ASCII space, newline, tab, carriage return,
> and backslash, respectively."  Even though the former is about the
> structure of the file itself while the latter is about the encoded
> payload, it is confusing that one talks about "linefeed" while the other
> talks about "newline" and "carriage return".  Should "newline" read
> "linefeed" (meaning U+000A LINE FEED) instead?
>
> (2)  #entries says "Space before and after the equals sign should be
> ignored".  Does that mean just U+0020 SPACE, or also other kinds of
> white space, like U+0009 CHARACTER TABULATION?
>
> (3)  It is unclear exactly when the escape sequences mentioned in (1)
> need to be used in string/localestring values:
>
> *  "\\" apparently needs to be used at least whenever the following
> character is one of "s", "n", "t", "r", or "\".  But what about
> sequences like "\a", does it render the file ill-formed, or is it an
> accepted shortcut for the fully escaped "\\a"?
>
> *  "\n" apparently needs to always be used (at least with the "newline"
> vs. "linefeed" clarification from (1)).
>
> *  "\s" (and maybe also "\t" and "\r"?) apparently needs to be used at
> the very start of a string/localestring value (see (2)).  But does it
> also need to be used e.g. at the very end of such a value?  (From common
> practice, it appears that it at least doesn't need to be used for a
> space somewhere in the middle of such a value.)
>
> *  What about "\t" and "\r"?
>
> (These questions occurred to me when doing
> 
>
> "Properly escape desktop file string values".)
>
> ___
> 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: Debian: Application not shown in section

[Stefan Blachmann]

I can confirm that, have seen such, too.
Particularly with Midnight Commander not being shown.

My wild guess is that there is some (undocumented?) setting "Show only
graphical applications" or the like in Gnome or its derivatives.
Seems some bug just looking at the mere presence of a Terminal=...
line, and not what it says.

On 4/1/18, Felix Natter  wrote:
> Dear xdg members,
>
> a Debian (stretch) user reported an issue where an application (freeplane)
> is not
> shown in the office section. So far I cannot reproduce this (GNOME3),
> but the user reported [1] that it is "fixed" by this change:
>
> --- /usr/share/applications/freeplane.desktop 2016-12-10 12:08:55.0
> -0500
> +++ freeplane.desktop 2018-03-20 14:16:27.182938569 -0400
> @@ -2,7 +2,7 @@
>  Version=1.0
>  Name=Freeplane
>  Exec=/usr/bin/freeplane %F
> -Terminal=false
> +#Terminal=false
>  Icon=freeplane
>  Type=Application
>  MimeType=application/x-freeplane;
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893635
>
> Here is the complete /usr/share/applications/freeplane.desktop:
> [Desktop Entry]
> Version=1.0
> Name=Freeplane
> Exec=/usr/bin/freeplane %F
> Terminal=false
> Icon=freeplane
> Type=Application
> MimeType=application/x-freeplane;
> Categories=Office;
> GenericName=Freeplane
> Comment=A free tool to structure and organise your information with mind
> mapping
> Keywords=Mindmaps; Knowledge management; Organize information;
> Brainstorming; ...;
>
> Do you have any idea what might cause this?
>
> Many Thanks and Best Regards,
> --
> Felix Natter
>
> ___
> 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: Adding an Accessibility Category to the Desktop Menu Specification?

[Stefan Blachmann]

I have to correct myself, sorry.

> Thus, Gnome and KDE advocates should be aware that this is an
> issue that does affect only people that do _not_ use DEs.
This is wrong.
As Samuel explained very well:

> Thinking again about it, this makes unattended launches more difficult.
> Such launches can be useful when a sighted user is working, and a
> non-sighted co-worker comes to work over something. Starting the screen
> reader from a launcher just for the time when he is there, and not
> permanently through configuration, makes complete sense.

Let me explain this problem using another disability as example. As I am deaf,
I have to use screen flashing utilities as a replacement for the beeper.
(See here for example:
http://serverfault.com/questions/19743/is-there-a-visual-bell-in-linux-that-works-in-x
)
Thus if I have to do things on another ones' computer account which
require me to
notice beeps I would be forced to change settings, and change them back to
original settings after finishing. In other words, I would be forced
to change the
system configuration _twice_.
If I could just go the menu path Utility->Accessibility->Visual_Bell
to run the utility,
then there won't be any need to tamper with the system configuration.

Thus a category "Accessibility" makes perfect sense imho.


On 5/24/16, Stefan Blachmann <sblachm...@gmail.com> wrote:
> If I understand Sam correctly, his suggestion is about adding an
> additional category Utilities→Accessibility. (see
> https://standards.freedesktop.org/menu-spec/latest/apas02.html )
>
> First, Gnome and KDE are not xdg menu specification compliant.
> Second, these DEs have a settings menu. Window managers like FVWM do
> not have such.
> Thus, Gnome and KDE advocates should be aware that this is an issue
> that does affect only people that do _not_ use DEs.
>
> Thus imho it makes perfect sense and is actually overdue to add such a
> subcategory “Accessibility” to the xdg menu spec.
>
>
> On 5/24/16, Samuel Thibault <samuel.thiba...@ens-lyon.org> wrote:
>> Bastien Nocera, on Mon 23 May 2016 11:54:44 +0200, wrote:
>>> 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.
>>
>> Thinking again about it, this makes unattended launches more difficult.
>> Such launches can be useful when a sighted user is working, and a
>> non-sighted co-worker comes to work over something. Starting the screen
>> reader from a launcher just for the time when he is there, and not
>> permanently through configuration, makes complete sense.
>>
>> Samuel
>> ___
>> 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: Adding an Accessibility Category to the Desktop Menu Specification?

[Stefan Blachmann]

If I understand Sam correctly, his suggestion is about adding an
additional category Utilities→Accessibility. (see
https://standards.freedesktop.org/menu-spec/latest/apas02.html )

First, Gnome and KDE are not xdg menu specification compliant.
Second, these DEs have a settings menu. Window managers like FVWM do
not have such.
Thus, Gnome and KDE advocates should be aware that this is an issue
that does affect only people that do _not_ use DEs.

Thus imho it makes perfect sense and is actually overdue to add such a
subcategory “Accessibility” to the xdg menu spec.


On 5/24/16, Samuel Thibault  wrote:
> Bastien Nocera, on Mon 23 May 2016 11:54:44 +0200, wrote:
>> 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.
>
> Thinking again about it, this makes unattended launches more difficult.
> Such launches can be useful when a sighted user is working, and a
> non-sighted co-worker comes to work over something. Starting the screen
> reader from a launcher just for the time when he is there, and not
> permanently through configuration, makes complete sense.
>
> Samuel
> ___
> 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