[Portland] Defining the problem

[Lubos Lunak]

 Hello,

 maybe it's just me but I think the discussion is getting a bit astray. We 
shouldn't be discussing step C when we haven't got yet past step B. IMHO we 
shouldn't be comparing in-process vs out-of-process solutions for a problem 
before we really know the problem, otherwise we may end up with a solution 
for a problem we don't intend to solve or even worse just end up as a 
philosophical discussion forum. For example, I as a developer find the code 
for integrating KDE and GNOME component frameworks very interesting, but I 
guess most ISVs couldn't care less that Nautilus now can't embed KPDFPart and 
have more basic problems like "how to handle mailto: links" or "what are the 
proxy settings".

 We've already gotten past step A, saying "there's a problem, we're going to 
fix it". But "there's no standard desktop API on Linux" is maybe good as a 
headline, however that's about it. I think now the next step should be 
defining the problem more precisely so that we can work on solving it.

 So far the only thing we have I know of is 
http://www.freedesktop.org/wiki/PortlandIntegrationTasks , which I still 
don't find good enough. It's too vague, whoever posted it there himself 
didn't know what some of the things were "(what is this?)" and some of the 
things don't belong there, either because they're already solved 
("Install/remove/update a menu item") or just because we may decide to ignore 
some of them for whatever reason.

 So I suggest we proceed like this:

A: Say that there's a problem and we intend to fix it. Check :).

B: Create a new page in the wiki that'll list what is needed, move some things 
from the pending tasks page there, ISVs who are here add more what they'd 
like to see solved (e.g. some of the things Billy Biggs posted look like real 
problems but they're not listed yet). The items should be at least somewhat 
technical descriptions of the problem, no need to go into deep details now, 
e.g. "Access the current proxy settings" is fine, but I find e.g. "Print a 
document" just too vague.

C: Filter out what definitely doesn't belong there, either because it's 
already sufficiently solved or because it simply doesn't belong in desktop 
API ("Launching/managing the modem" - huh? ).

D: Sort/group according to priority and feasibility and decide what we want to 
solve now and what we'll leave for later. I think Waldo or somebody has 
already posted here a desired deadline but I can't find it right now.

E: Discuss how to actually solve it (i.e. the thing some people are already 
trying to do now). If after step D we end up with something that generally 
just boils down to one of "get/set setting X" or "launch Y" (which actually 
covers a large part of what's currently listed) and decide to handle the rest 
later, the solution may very well be e.g. XSETTINGS + a couple of simple 
scripts for the time being.

 Comments? If people agree, then, at whatever step you're now, please proceed 
to step B :).

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/