Problems with NoDisplay and menu editors

[Travis Watkins-2]

Currently NoDisplay has three uses:

 * install things that shouldn't be shown in the menus but should
handle MIME types
 * install things that shouldn't be shown in the menus by default but
users can enable in a menu editor
 * to hide things when a user wants to hide them in a menu editor

Only the first use is really correct but the other two exist because
there is currently no better way.
Let's look at the other choices.

<Exclude> seems to be a perfect fit and is certainly easy enough to
use in a menu editor.
However, for an application to use this it has to not only install a
file into the
applications-merged directory it has to know what menu it is going to end up in.
This is rather impossible when a quick edit to /etc/xdg/menus/applications.menu
can change that.

Hidden is a good candidate as it is easy to use in an application and
easy for a menu
editor to add to a .desktop file. However, this two has problems as it
disables MIME
type handling. If a user hides Firefox from their menu and the editor
uses Hidden
Firefox will no longer be opened when you open an HTML file. Along the
same lines
if an application wants to install a .desktop that is hidden by
default but a user can
enable later it won't be able to do MIME type handling until the user
enables it.


Right now it looks pretty hopeless as every solution is broken somehow
but I do see
a couple of possible fixes. The first one would be to make Hidden
items still work
for MIME type handling. This breaks the Hidden=Deleted idea in the
spec but makes
Hidden perfect for this use case. The other solution would be to
invent a new key
in the desktop entry spec that would be used for this purpose.

Any thoughts on this? Personally I'd rather go with the change to the meaning of
Hidden as it makes the most sense to me (Hidden means it is hidden in the menu)
and would still be compatible with the current menu implementations
since they don't
show Hidden items anyway.

--
Travis Watkins
http://www.realistanew.com
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Monday 04 May 2009, Travis Watkins wrote:
> Personally I'd rather go with the change to the meaning of
> Hidden as it makes the most sense to me (Hidden means it is hidden in the menu)
> and would still be compatible with the current menu implementations
> since they don't show Hidden items anyway.

This would break compatibility with all installed .desktop files which say Hidden=true,
with the intention of saying "this file is deleted". We cannot change this meaning,
for penalty of introducing 1000 bugs. This is a big veto from me for changing the
meaning of a 10-year-old .desktop file key, even though it was misnamed.

I don't actually understand the problem you're describing. In all three cases
we want "mime handling but no appearance in the menus", and NoDisplay=true
does exactly that. So what's the problem you're trying to fix? Too much crap
showing up in the menu editors as "no display"?

--
David Faure, faure@..., sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Travis Watkins-2]

On Mon, May 11, 2009 at 5:50 AM, David Faure <faure@...> wrote:

> On Monday 04 May 2009, Travis Watkins wrote:
>> Personally I'd rather go with the change to the meaning of
>> Hidden as it makes the most sense to me (Hidden means it is hidden in the menu)
>> and would still be compatible with the current menu implementations
>> since they don't show Hidden items anyway.
>
> This would break compatibility with all installed .desktop files which say Hidden=true,
> with the intention of saying "this file is deleted". We cannot change this meaning,
> for penalty of introducing 1000 bugs. This is a big veto from me for changing the
> meaning of a 10-year-old .desktop file key, even though it was misnamed.
>
> I don't actually understand the problem you're describing. In all three cases
> we want "mime handling but no appearance in the menus", and NoDisplay=true
> does exactly that. So what's the problem you're trying to fix? Too much crap
> showing up in the menu editors as "no display"?
>

Exactly, I'm trying to figure out how to let users hide/unhide things
without making them see the 3 copies of Banshee and 2 copies of
Brasero and whatever other junk shows up.

The only other thing I can think to do is patch all of these
applications so they don't put any Categories in their NoDisplay files
so they end up in the Other menu and don't bother users so much.


--
Travis Watkins
http://www.realistanew.com
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Monday 11 May 2009, Travis Watkins wrote:

> On Mon, May 11, 2009 at 5:50 AM, David Faure <faure@...> wrote:
> > On Monday 04 May 2009, Travis Watkins wrote:
> >> Personally I'd rather go with the change to the meaning of
> >> Hidden as it makes the most sense to me (Hidden means it is hidden in the menu)
> >> and would still be compatible with the current menu implementations
> >> since they don't show Hidden items anyway.
> >
> > This would break compatibility with all installed .desktop files which say Hidden=true,
> > with the intention of saying "this file is deleted". We cannot change this meaning,
> > for penalty of introducing 1000 bugs. This is a big veto from me for changing the
> > meaning of a 10-year-old .desktop file key, even though it was misnamed.
> >
> > I don't actually understand the problem you're describing. In all three cases
> > we want "mime handling but no appearance in the menus", and NoDisplay=true
> > does exactly that. So what's the problem you're trying to fix? Too much crap
> > showing up in the menu editors as "no display"?
> >
>
> Exactly, I'm trying to figure out how to let users hide/unhide things
> without making them see the 3 copies of Banshee and 2 copies of
> Brasero and whatever other junk shows up.
>
> The only other thing I can think to do is patch all of these
> applications so they don't put any Categories in their NoDisplay files
> so they end up in the Other menu and don't bother users so much.

Sounds like we need NoDisplay-as-set-by-user and NoDisplay-as-decided-by-programmer?
Which would amount basically to checking if the local file (in the user's home dir) has NoDisplay
(then allow to show it again, it was hidden by the user) or if NoDisplay comes from a
global file (e.g. /usr) then it is probably a "system" desktop file which wouldn't make sense
in a menu in any case. Does this seem like a good solution?

The alternative would be to actually use a different key; in fact preventing people from
unhiding some desktop files could simply be done with NoDisplay[$i]=true (where [$i] means
immutable, i.e. cannot be overridden in a local config file). We "just" have to patch all
NoDisplay desktop files we provide to actually say that.

--
David Faure, faure@..., sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Brian J. Tarricone]

On 2009/05/11 06:00, Travis Watkins wrote:

> On Mon, May 11, 2009 at 5:50 AM, David Faure<faure@...>  wrote:
>> On Monday 04 May 2009, Travis Watkins wrote:
>>> Personally I'd rather go with the change to the meaning of
>>> Hidden as it makes the most sense to me (Hidden means it is hidden in the menu)
>>> and would still be compatible with the current menu implementations
>>> since they don't show Hidden items anyway.
>> This would break compatibility with all installed .desktop files which say Hidden=true,
>> with the intention of saying "this file is deleted". We cannot change this meaning,
>> for penalty of introducing 1000 bugs. This is a big veto from me for changing the
>> meaning of a 10-year-old .desktop file key, even though it was misnamed.
>>
>> I don't actually understand the problem you're describing. In all three cases
>> we want "mime handling but no appearance in the menus", and NoDisplay=true
>> does exactly that. So what's the problem you're trying to fix? Too much crap
>> showing up in the menu editors as "no display"?
>
> Exactly, I'm trying to figure out how to let users hide/unhide things
> without making them see the 3 copies of Banshee and 2 copies of
> Brasero and whatever other junk shows up.

Why can't we bring back the 'Desktop Actions' portion of the desktop
entry spec (or was that in the menu spec?)?  This easily solves the
issue of an app installing >1 .desktop file, and seems to work rather
well in practice (Thunar still implements it even though it was removed
from the spec a while ago).  You'd rarely (never?) display the other
actions in a menu anyway, so they can be safely ignored.

        -brian
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Sunday 12 July 2009, Brian J. Tarricone wrote:

> On 2009/05/11 06:00, Travis Watkins wrote:
> > On Mon, May 11, 2009 at 5:50 AM, David Faure<faure@...>  wrote:
> >> On Monday 04 May 2009, Travis Watkins wrote:
> >>> Personally I'd rather go with the change to the meaning of
> >>> Hidden as it makes the most sense to me (Hidden means it is hidden in the menu)
> >>> and would still be compatible with the current menu implementations
> >>> since they don't show Hidden items anyway.
> >> This would break compatibility with all installed .desktop files which say Hidden=true,
> >> with the intention of saying "this file is deleted". We cannot change this meaning,
> >> for penalty of introducing 1000 bugs. This is a big veto from me for changing the
> >> meaning of a 10-year-old .desktop file key, even though it was misnamed.
> >>
> >> I don't actually understand the problem you're describing. In all three cases
> >> we want "mime handling but no appearance in the menus", and NoDisplay=true
> >> does exactly that. So what's the problem you're trying to fix? Too much crap
> >> showing up in the menu editors as "no display"?
> >
> > Exactly, I'm trying to figure out how to let users hide/unhide things
> > without making them see the 3 copies of Banshee and 2 copies of
> > Brasero and whatever other junk shows up.
>
> Why can't we bring back the 'Desktop Actions' portion of the desktop
> entry spec (or was that in the menu spec?)?  This easily solves the
> issue of an app installing >1 .desktop file, and seems to work rather
> well in practice (Thunar still implements it even though it was removed
> from the spec a while ago).  

KDE does, too. (it was in the desktop entry spec). And indeed I didn't
know it had been removed (!). Ouch. If two implementations still have it
and want it, why was it removed?
Hmm. Well. We use it, but not for app desktop files it seems; rather
for actions on devices, and for servicemenus (rmb / actions / foo in
file managers, but using kde-specific .desktop files).


But anyway I don't see a relation with the current thread.
Desktop Actions was about specific named actions, not about the
issue of hidden-from-the-menu associations between an app
and a mimetype. Which is NoDisplay=true, but indeed a menu editor
would probably not want to show these as potentially showable,
so I suggested NoDisplay[$i]=true (immutable setting).
Didn't get an answer on that though ;)

--
David Faure, faure@..., sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Brian J. Tarricone]

On 08/05/2009 03:25 PM, David Faure wrote:

> On Sunday 12 July 2009, Brian J. Tarricone wrote:
>> On 2009/05/11 06:00, Travis Watkins wrote:
>>> On Mon, May 11, 2009 at 5:50 AM, David Faure<faure@...>   wrote:
>>>> On Monday 04 May 2009, Travis Watkins wrote:
>>>>> Personally I'd rather go with the change to the meaning of
>>>>> Hidden as it makes the most sense to me (Hidden means it is hidden in the menu)
>>>>> and would still be compatible with the current menu implementations
>>>>> since they don't show Hidden items anyway.
>>>> This would break compatibility with all installed .desktop files which say Hidden=true,
>>>> with the intention of saying "this file is deleted". We cannot change this meaning,
>>>> for penalty of introducing 1000 bugs. This is a big veto from me for changing the
>>>> meaning of a 10-year-old .desktop file key, even though it was misnamed.
>>>>
>>>> I don't actually understand the problem you're describing. In all three cases
>>>> we want "mime handling but no appearance in the menus", and NoDisplay=true
>>>> does exactly that. So what's the problem you're trying to fix? Too much crap
>>>> showing up in the menu editors as "no display"?
>>> Exactly, I'm trying to figure out how to let users hide/unhide things
>>> without making them see the 3 copies of Banshee and 2 copies of
>>> Brasero and whatever other junk shows up.
>> Why can't we bring back the 'Desktop Actions' portion of the desktop
>> entry spec (or was that in the menu spec?)?  This easily solves the
>> issue of an app installing>1 .desktop file, and seems to work rather
>> well in practice (Thunar still implements it even though it was removed
>> from the spec a while ago).
>
> KDE does, too. (it was in the desktop entry spec). And indeed I didn't
> know it had been removed (!). Ouch. If two implementations still have it
> and want it, why was it removed?
> Hmm. Well. We use it, but not for app desktop files it seems; rather
> for actions on devices, and for servicemenus (rmb / actions / foo in
> file managers, but using kde-specific .desktop files).
>
>
> But anyway I don't see a relation with the current thread.
> Desktop Actions was about specific named actions, not about the
> issue of hidden-from-the-menu associations between an app
> and a mimetype. Which is NoDisplay=true, but indeed a menu editor
> would probably not want to show these as potentially showable,
> so I suggested NoDisplay[$i]=true (immutable setting).
> Didn't get an answer on that though ;)

It's possible that I've forgotten what the original issue was, but from
talking to Travis on IRC months ago, I seem to remember that the problem
was that some apps install multiple desktop files, marking all but one
as invisible, and the invisible ones do things like set up mime
associations with a particular variant of Exec=.  Travis' problem (IIRC)
was that these extra files show up in the menu editor as hidden, when in
reality we don't want to see them at all (in the menu editor).

Bringing back Desktop Actions (I think!) would remove the need for apps
to ship multiple desktop files, instead just shipping one with the
various other stuff in it.  If the original DA spec gets us most of the
way there, but not all the way, we could both bring it back and add
whatever magic is necessary to make it work.

Of course, as I said, I could be mis-remembering what the issue was, and
I don't have time right now to re-read the thread.

        -brian
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg