[Portland] Summarize current plan?

[Jeremy White]

>  You can and you or anybody else are free to work on that, it's just that this 
> is not the point of DAPI. Installing a menu entry is fairly simple, you just 
> read the spec and basically just put a .desktop file somewhere as the spec 
> says. It's supposed to work with any desktop and you in fact don't even need 
> a desktop running at the install time.

Go read the thread I posted.  It's not as easy as you think; the
spec is imprecise when you're doing root installs.

And some people think that you need to invoke update-desktop-database
after you're done (although I haven't seen that empirically, and
that tool seems to only be appropriate when running as the root user),
and that's sure not discussed in the spec anywhere.

And the XDG spec isn't supported on Mandriva (unless the user disables
'normal' menus and fudges it somehow).  And KDE/Ubuntu has some sort
of fun bug that I haven't pinned down yet; the XDG user menus aren't
picked up until some set of conditions are satisfied
(having any menu in the ~/.kde menu structure seems to be one way to
satisfy the condition).

And this is the *very best* case for Linux; the menu spec is, imho, the
nicest, cleanest, and best desktop integration spec we have; it's even
becoming widely adopted.

> 
>  The API is about things that cannot be done so easily, either because they're 
> not standardized or because they'd be too complicated this way.

GAH!!!!!!!!!!

You just don't get it.  There are a whole range of things that
you WM developers *think* are easy and obvious,
because they work for you, but they don't work in the real world.

An ISV wants to ship 1 binary that has a few simple characteristics:
  * If I give my binary to 100 random users, I want it to work the same
    for all 100
  * That's complicated, because 'same' doesn't necessarily mean
    'always open the bundled copy of Opera', it means 'open the
    browser the user wanted opened'.
  * If it doesn't work for some of the 100, I want it to be
    clear that the failure is because *their* distro fails
    to support the appropriate standard, and I need a clear
    and morally compelling way to convey that to the user.

>From personal experience,  I'll tell you that we've never gotten
menu creation to work on 100% of desktops (although I do think we're
well north of 90%).  Note that that success has come after literally
months of developer time spent building a very complex
structure of code to adapt to and respond to the actual desktop
environment.  I am not exaggerating - we have spent literally man months
(and not 1 or 2, but 'many') just making @#$@#$#@ menus appear
where uses think they should.

And *don't* tell me that is not important.  *My* users think
my software is broken if the menu doesn't show up!

Now, admittedly, our menu needs are complex (we have to create
a whole chain of menus, and do so dyanically), and I also admit that
most of our pain is from non XDG compliant WMs (yay for the menu-spec!).

But *this* is what the Linux desktop looks like to an ISV.

And when we bitch about it, we're told "Oh, that's a solved problem,
it's trivial."  It's not solved; it's 97% solved, and no one will
close the @#$@#$$ gap to actually make it useful!

Let's take an example; opening a URL.

*You* might think it's easy to open a URL because you always
run in KDE and you set your preferences up properly.  But there is
not a clear equivalent of the menu-spec for this.

Most ISVs I've seen have an algorithm that goes something like this:
    for x in firefox mozilla konqueror opera (and so on) ; do
        if [ -x `which $x` ] ; then
            $x the-url-i-wanna-run
            break
        fi
    done

And we just live with the fact that we really didn't want our URL
to override some tab in the current browser, but that we wanted it
in a brand new window, but there is no reliable way to make sure
that happens everywhere.

*STOP*

Right now, you're all furiously thinking of the bazillion
ways in which this is wrong and how there is a better way
to do this.  I am aware that there are better ways
(and we use some of them); I'm even aware that good work is
being done to raise the bar on this.

But it is a clear example of my main beef:

  IT IS NOT DOCUMENTED ANYWHERE USEFUL

Further, even those places where it is documented usefully,
it is not in a place that is morally useful to me as an ISV.

The menu-spec is lovely.  I can say "We support the XDG menu spec.  If
you do not have an XDG compliant WM, talk to your vendor - it's *their*
problem, not mine."

I have no such luck with browsers.  If a user says to me that their
.mailcap file clearly specifies that we should use lynx, what
moral authority do I have to say that the user is wrong?  .mailcap
is a completely legitimate standard...  and now I'm spending man months
just trying to open a @#$@#$ url.

And, like I've said; the browser step is actually getting better
quickly; there are things like mime handling that are much thornier.

Finally, to give you some perspective of how this feels to me:
in December, I took away that someone was going to document the
standards in trivial things like opening URLs, and then we were
going to write some simple scripts.  Like, for example,
  xdg-open-url [--new-window] url

Wow!  How nice would that be!  One line of code!  My web browser
integration needs are done in 15 minutes!

Instead, everyone seems to be off solving some other 'hard' problem,
leaving me with weeks and weeks of hair wrangling to figure out the
'best' way to open a @$@#$@#$ URL.

Urk.  I've ranted on quite a bit, haven't I?

Sorry about that; the years spent fighting vfolders and
other menu inanities have left deep and bitter scars.

Cheers,

Jeremy