[Portland] Summarize current plan?

[Jeremy White]

First, let me apologize; I snapped, and there was a lot
more froth and spittle in that last email than was needed.

>  Short summary: The menu spec doesn't work on Mandriva, Kubuntu has a bug, 
> some desktops doesn't support the spec and the spec is imprecise in some 
> details, so in practice it doesn't work in 100% cases.
> 

Yes - the menu-spec is good; I want more
areas of the Linux desktop to work as well as the menu-spec does.

My key point is that even in areas that people think are good
and/or solved, we have a 'last mile' gap.

>  Now, what exactly would you like to happen here? 

That's a fair point; my email was long on venting and
short on constructive comments.

My worry was that you will have persuaded others that no
work is needed, and I think that is very far from the truth.

I think work on documentation, on aggregating existing solutions,
and on 'blessing' simple solutions is critical and needs to be done.


> 
>  As for the last item, the spec needing some clarifications/fixes/whatever, if 
> you really could have spent man months on it, why didn't you instead try to 
> spend noticeably less time on fixing the spec and doing what'd be necessary? 
> It's not like you're not allowed to.

Um...I'm not sure what you're suggesting.  You seem to be saying
"don't bother trying to improve the specs, just do whatever you have to
to make it work."  That is what we've done; we've adapted to all of
the sick and wierd ways that Linux distros like to arrange their menus.
(For the record, KDE has been a shining beacon of sanity in an
otherwise horrid mess; KDE menus have usually been quite nice, unless
the distro vendor screws them up).

I'm here as a volunteer.  I'm trying to share the pain an actual, real
life ISV has had in trying to ship a product for the Linux Desktop,
and I'm trying to help improve that experience so other ISVs won't
become as bitter and as prone to froth and spittle as I am <grin>.

I'm trying to contribute code and documentation changes where
I can.  I even edited the Wiki (and I hate Wikis).
I'm not sure what else you would have me do (okay, I could have
caught the creation of this mailing list and not stupidly have
missed 3 months of discussion :-/).

>  Good news for you, OpenUrl is the first call in dapi/doc/API.txt . And your 
> last sentence describes the motivation - there's no spec and it depends on 
> the running desktop, so there can be no simple shared implementation. You'll 
> just call OpenUrl and the active backend daemon will take care of it.

Aha!  Now we come to an interesting point of debate.  See, I think that
the existing methods to open a URL are 'good enough'; I would just like
to standardize around the existing methods.  I find Kevin's
implementation to be the ideal.

But I'm not sure of that; I can imagine that more sophisticated
meanings of 'Open a URL' will require an alternate implementation.
So I agree that competing approaches is a good idea.  And I think it's
vital that even the simple solutions be framed in the awareness of
the larger problems, so that they can eventually scale to solve
the hard problems.

>  Nobody's stopping you. Or anybody else. Maybe it's rather you who doesn't get 
> it? Things will happen only after somebody makes them happen. Just because 
> I've chosen one way to solve the problem and started working on that doesn't 
> mean it's the Only True Way(TM).
> 
> 
>>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.
> 
> 
>  Hmm, you've studied the archives of this list, haven't you? Maybe you should 
> read again the first mail in February that restarted the discussion after 
> month's silence. If I were interested in solving 'hard' problems I would have 
> joined those discussions instead of sending that mail. Yes, I could have done 
> some scripts first, but given their simplicity I kind of thought there would 
> be enough people to create those, and moreover I'd like to create something 
> that should be powerful and extensible enough even when people decide to move 
> further down on http://www.freedesktop.org/wiki/PortlandIntegrationTasks .

My rant was out of line in that I did not mean to dismiss or derail
your work on dapi; I genuinely believe that there are hard problems
that will require a solution like dapi.  Further, I am very grateful
to you for actually contributing.

I'm just obsessed with seeing that the simple problems not be neglected,
and that we help ISVs make it over that last mile.

Cheers,

Jeremy