From: Damjan Jovanovic Subject: Re: [PATCH v2 0/2] Improved file association desktop integration Message-Id: Date: Tue, 30 Jun 2020 05:18:52 +0200 In-Reply-To: <98681471-564c-107f-7cca-4f54e3f6f9c4@gmail.com> References: <20200624071127.109241-1-alexhenrie24@gmail.com> <98681471-564c-107f-7cca-4f54e3f6f9c4@gmail.com> On Mon, Jun 29, 2020 at 10:41 PM Zebediah Figura wrote: > > > On 6/29/20 3:27 PM, Nikolay Sivov wrote: > > > > > > On Mon, Jun 29, 2020 at 11:22 PM Alex Henrie > > wrote: > > > > On Mon, Jun 29, 2020 at 2:05 PM Nikolay Sivov > > wrote: > > > > > > > > > > > > On Mon, Jun 29, 2020 at 10:54 PM Alex Henrie > > > wrote: > > >> > > >> On Mon, Jun 29, 2020 at 1:49 PM Nikolay Sivov > > > wrote: > > >> > > > >> > > > >> > > > >> > On Mon, Jun 29, 2020 at 10:45 PM Alex Henrie > > > wrote: > > >> >> > > >> >> On Thu, Jun 25, 2020 at 3:29 AM Francois Gouget > > > wrote: > > >> >> > > > >> >> > On Wed, 24 Jun 2020, Alex Henrie wrote: > > >> >> > > > >> >> > > The big change here is rewriting the patches to avoid the > term > > >> >> > > "blacklist", which I have replaced with "naughty list". > > >> >> > > > >> >> > In this context it's not clear what naughty means. What in a > > file > > >> >> > extension is "badly behaved, disobedient or mildly rude or > > indecent"? > > >> >> > > >> >> Several built-in Wine programs are badly behaved in the sense > that > > >> >> they associate themselves with file types that native desktop > > programs > > >> >> are better suited to open. > > >> > > > >> > > > >> > Would it be a problem to remove such integration completely? I > > can't think of a good scenario when it would be useful. > > >> > > >> The associations have to be in Wine for programs that call > `start.exe > > >> ` to open a file. > > > > > > > > > This has to be a prefix configuration, not affecting > > opening/strating things through DE. E.g. 'wine start test.txt' > > supposedly expected to open notepad, > > > that doesn't have to be configured for DE associations. Maybe > > you're talking about something else, I meant this part: > > > > > > >> Several built-in Wine programs are badly behaved in the sense > that > > > >> they associate themselves with file types that native desktop > > programs > > > >> are better suited to open. > > > > > > Builtin programs or installed programs only need shell extensions > > stuff in registry to open via 'wine start', > > > they don't have to touch system configuration. > > > > > > Is that a different issue? > > > > If I understand you correctly now, you're proposing to get rid of > > desktop integration for associations altogether. I imagine that would > > be very undesirable for people who use MS Office on Linux through > > Wine. I'd also like to be able to install Steam games in the Windows > > client by browsing https://store.steampowered.com/ in the native > > browser and then clicking steamapp:// links that open in Wine. > > > > > > That becomes unusable once you have more than one prefix (I believe > > desktop integration does not specify WINEPREFIX for launch commands). > > In fact it does; see write_freedesktop_association_entry() in > winemenubuilder.c. > > > Do they get updated if you move prefix with Office somewhere, or if you > > remove it? > > winemenubuilder automatically updates associations on prefix update, or > when manually run with the -a argument. > > Of course associations never get removed, which is a problem, but it's > hard to solve. It's not obvious to me that it's worth throwing out the > whole of winemenubuilder just because of that, though. > > That's not true. Associations do get removed. It was intended to behave the way users expect. How do you remove an association from a native *nix application? You use a tool that ultimately deletes the fd.o file eg. ~/.local/share/applications/wine-extension-png.desktop. On the next winemenubuilder run, it will see the PNG associated was previously generated (from the registry) but the fd.o file is absent, and assume the user doesn't want it, and avoid regenerating the fd.o file. If you uninstall the Windows application, the uninstaller deletes the association from the registry, and winemenubuilder then deletes it from fd.o. Either way, the fd.o association gets deleted. That's how I remember designing and implementing it ~10 years ago. If it doesn't currently behave this way, it's a bug. (Of course, applications that ship with Wine, like iexplore and notepad, never get deleted...) Damjan


On Mon, Jun 29, 2020 at 10:41 PM Zebediah Figura <z.figura12@gmail.com> wrote:


On 6/29/20 3:27 PM, Nikolay Sivov wrote:
>
>
> On Mon, Jun 29, 2020 at 11:22 PM Alex Henrie <alexhenrie24@gmail.com
> <mailto:alexhenrie24@gmail.com>> wrote:
>
>     On Mon, Jun 29, 2020 at 2:05 PM Nikolay Sivov <bunglehead@gmail.com
>     <mailto:bunglehead@gmail.com>> wrote:
>     >
>     >
>     >
>     > On Mon, Jun 29, 2020 at 10:54 PM Alex Henrie
>     <alexhenrie24@gmail.com <mailto:alexhenrie24@gmail.com>> wrote:
>     >>
>     >> On Mon, Jun 29, 2020 at 1:49 PM Nikolay Sivov
>     <bunglehead@gmail.com <mailto:bunglehead@gmail.com>> wrote:
>     >> >
>     >> >
>     >> >
>     >> > On Mon, Jun 29, 2020 at 10:45 PM Alex Henrie
>     <alexhenrie24@gmail.com <mailto:alexhenrie24@gmail.com>> wrote:
>     >> >>
>     >> >> On Thu, Jun 25, 2020 at 3:29 AM Francois Gouget
>     <fgouget@free.fr <mailto:fgouget@free.fr>> wrote:
>     >> >> >
>     >> >> > On Wed, 24 Jun 2020, Alex Henrie wrote:
>     >> >> >
>     >> >> > > The big change here is rewriting the patches to avoid the term
>     >> >> > > "blacklist", which I have replaced with "naughty list".
>     >> >> >
>     >> >> > In this context it's not clear what naughty means. What in a
>     file
>     >> >> > extension is "badly behaved, disobedient or mildly rude or
>     indecent"?
>     >> >>
>     >> >> Several built-in Wine programs are badly behaved in the sense that
>     >> >> they associate themselves with file types that native desktop
>     programs
>     >> >> are better suited to open.
>     >> >
>     >> >
>     >> > Would it be a problem to remove such integration completely? I
>     can't think of a good scenario when it would be useful.
>     >>
>     >> The associations have to be in Wine for programs that call `start.exe
>     >> <file>` to open a file.
>     >
>     >
>     > This has to be a prefix configuration, not affecting
>     opening/strating things through DE. E.g. 'wine start test.txt'
>     supposedly expected to open notepad,
>     > that doesn't have to be configured for DE associations. Maybe
>     you're talking about something else, I meant this part:
>     >
>     > >> Several built-in Wine programs are badly behaved in the sense that
>     > >> they associate themselves with file types that native desktop
>     programs
>     > >> are better suited to open.
>     >
>     > Builtin programs or installed programs only need shell extensions
>     stuff in registry to open via 'wine start',
>     > they don't have to touch system configuration.
>     >
>     > Is that a different issue?
>
>     If I understand you correctly now, you're proposing to get rid of
>     desktop integration for associations altogether. I imagine that would
>     be very undesirable for people who use MS Office on Linux through
>     Wine. I'd also like to be able to install Steam games in the Windows
>     client by browsing https://store.steampowered.com/ in the native
>     browser and then clicking steamapp:// links that open in Wine.
>
>
> That becomes unusable once you have more than one prefix (I believe
> desktop integration does not specify WINEPREFIX for launch commands).

In fact it does; see write_freedesktop_association_entry() in
winemenubuilder.c.

> Do they get updated if you move prefix with Office somewhere, or if you
> remove it?

winemenubuilder automatically updates associations on prefix update, or
when manually run with the -a argument.

Of course associations never get removed, which is a problem, but it's
hard to solve. It's not obvious to me that it's worth throwing out the
whole of winemenubuilder just because of that, though.


That's not true. Associations do get removed.

It was intended to behave the way users expect.

How do you remove an association from a native *nix application? You use a tool that ultimately deletes the fd.o file eg. ~/.local/share/applications/wine-extension-png.desktop. On the next winemenubuilder run, it will see the PNG associated was previously generated (from the registry) but the fd.o file is absent, and assume the user doesn't want it, and avoid regenerating the fd.o file.

If you uninstall the Windows application, the uninstaller deletes the association from the registry, and winemenubuilder then deletes it from fd.o.

Either way, the fd.o association gets deleted. That's how I remember designing and implementing it ~10 years ago. If it doesn't currently behave this way, it's a bug.

(Of course, applications that ship with Wine, like iexplore and notepad, never get deleted...)

Damjan