RFC: new OnlyShowIn/NotShowIn values: MATE and RAZOR

[PCMan]

On Sun, Jan 15, 2012 at 8:43 PM, Emmanuele Bassi <ebassi at gmail.com> wrote:

> hi;
>
> On 15 January 2012 12:10, PCMan <pcman.tw at gmail.com> wrote:
> > Slightly off topic, is there any consensus on how to detect current
> desktop
> > environment?
> > Previously a proposed environment variable XDG_CURRENT_DESKTOP was
> mentioned
> > on the ML, but there was no conclusion.
> > Can we start a discussion on this issue again?
> > It's very important for desktop-independent applications, such as web
> > browsers.
>
> applications should be detecting capabilities, not doing string
> comparisons on desktop environment names.
>
> Then what's the purpose of OnlyShowIn/NotShowIn?
Besides, how to detect capabilities?
Examing for specific dbus interface or using systemd?
I don't think this is a good idea suitable for "all" applications.

> a desktop environment UX can change without its name changing; or new
> desktop environments, with similar UX can appear.
>
> Feel free to do additional capability testing in your desktop environment.
You can still do the additonal checks you like regardless of the DE name
given.
Sometimes we really just need that "name string". Otherwise, things like
"uname" won't exist, either.
Sometimes you just need the name for some programs and there is no easy way
to figure it out.

> checking the name of the desktop environment is going to be hopelessly
> out of date, or actively wrong.
>
Please explain what's wrong with it. It's quite useful for desktop
independent programs.
Not everyone writes source code for Gnome or KDE only.
There are programs which need to be usable across desktop environment.
If I want to know which program I can use to open file of a mime-type, I
query mime database.
Then I get a list of desktop entry files. If I don't know the name of DE,
how can I know which ones can be shown?

> plus, are you seriously going to add a bunch of
> whitelisting/blacklisting of behaviours inside application code, and
> basing it on strings? because that *will* break. it's like
> whitelisting or blacklisting a GL driver based on the output of the
> glxinfo Renderer string: let's not repeat the mistakes of the past
> (*cough* Flash *cough*).
>
Isn't this what has been done in menu spec, a listing of known desktop
environments for OnlyShowIn/NotShowIn in the spec?
Everytime a new DE is created, we add it to the list. Is this ideal?
> If you're not able to detect current DE, how can you apply
> OnlyShowIn/NotShowIn correctly?

> showing entries is the desktop environment role, not the application's
> role - and a desktop environment should know its own name.
>
Then why a project like xdg-utils exist? It should be killed.
In the "free world", not every applications is designed to work with Gnome
or KDE only.
Not every program is bound to a specific desktop environment, either.
While I understand your ambition for finding the best solution possible,
it's not necessarilty the best for other small and simple projects.
Please leave room for others. We just need a simple solution to solve
simple cases.
If name comparison is not enough for your DE, you can still add more
complicated rules to yours.
Adding a common way to export DE name won't hurt anything. It only helps
people who really need it much.

Thanks

ciao,
>  Emmanuele.
>
> --
> W: http://www.emmanuelebassi.name
> B: http://blogs.gnome.org/ebassi/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20120117/428d6f83/attachment.htm>