Fwd: [KDE/Mac] DrKonqi placement

[Marko Käning]

I think Ian's post from KDE-MAC might be of interest for all KF5 devs and I guess
it should rather be discussed on KDE-DEVEL...


Begin forwarded message:

> From: Ian Wadham <iandw.au at gmail.com>
> Subject: Re: [KDE/Mac] DrKonqi placement
> Date: 23 Oct 2014 01:38:50 GMT+2
> To: KDE Software on Mac OS X <kde-mac at kde.org>
> Cc: David Faure <faure at kde.org>, Aleix Pol <aleixpol at kde.org>
> Reply-To: KDE Software on Mac OS X <kde-mac at kde.org>
> 
> Hi Marko,
> 
> Nice to see you again… :-)
> 
> On 23/10/2014, at 7:30 AM, Marko Käning wrote:
>> I felt urged to forward this to kde-mac...
>> 
>> But, I guess you are aware of this discussion thread on k-f-d, aren’t you?
> 
> No, I don't follow kde-frameworks-devel, but it's good that one of us does…
> This topic is of interest on the OSX platform and probably Windows too.  It
> should really be discussed on kde-devel or at least kde-core-devel.
> 
>> On 22 Oct 2014, at 09:13 , David Faure <faure at kde.org> wrote:
>>> On Monday 20 October 2014 10:54:51 Milian Wolff wrote:
>>>> On Wednesday 02 April 2014 18:48:24 Aleix Pol wrote:
>>>>> Hi,
>>>>> I know I'm changing what I say about drkonqi every now and then, but every
>>>>> step I take, I realize that the project is bigger and bigger. What I
>>>>> wanted
>>>>> to do originally was to move it to KCrash, KCrash without drkonqi is much
>>>>> less useful.
>>>> 
>>>> <snip>
>>>> 
>>>>> - with bugzilla integration (additionally to the previous ones):
>>>>> KF5::WebKit
>>>> 
>>>> Could this maybe be replaced by using QtWebKit directly?
>>> 
>>> Then it wouldn't use KWallet, KIO, KCookieJar...
> 
> BTW, KCookieJar is no longer relevant to Dr Konqi.  Bugzilla on bugs.kde.org
> stopped issuing or accepting cookies in July.  That is what all the hoo-ha and
> last-minute panic was about regarding https://git.reviewboard.kde.org/r/120431/
> "Fix and future-proof Dr Konqi security methods on Bugzilla"… :-)
> (@David: I am the guy who submitted that patch).
> 
> KIO comes in as a tail-end I/O method after Dr Konqi sends a remote procedure
> call to Bugzilla via the KXmlRpc::Client class.  KXmlRpc::Client could presumably
> use another I/O method --- carrier pigeons maybe… :-)  Or perhaps, Dr K could use
> another Bugzilla command-protocol, such as REST (but I do not know much about that).
> 
>>> Would be annoying to have to enter your password again there, when the KIO 
>>> infrastructure would normally take care of it….
> 
> KWallet is all you need to get your login ID and password entered in Dr Konqi's
> login dialog box.  It even works on Apple OS X now… ;-)
> 
> In future versions of Bugzilla, the login ID and password will be required on
> every RPC that updates the database.  AFAICT, from scanning the Dr Konqi
> code, there will usually be one such call per crash, with the alternatives being
> to submit a new bug report or add an attachment to an existing report.
> 
> If that is so, the login dialog should be relocated so as to occur immediately
> before the database update (if there is one).  That way, we could avoid having
> to log in unnecessarily, if the outcome is that the crash has insufficient or
> redundant information and Dr Konqi decides not to report it.
> 
> Dr K should still say, early in the piece, that a bugs.kde.org account/login could
> be needed, so that the end-user is prepared for that before he goes through all
> the dialog boxes.
> 
>>> Maybe we need to separate the basic crash dialog from the bug reporting 
>>> functionality….
> 
> It is already separated quite a lot.  The real problem IMHO is that the succession
> of dialog boxes and the interaction between them and the underlying database
> (bugs.kde.org) has been coded in such a complex way.  Perhaps that is because
> the underlying "wizard" paradigm is sequential, whereas the dialog is branching
> and has (at least) three outcomes: report a bug, add to an existing bug or report
> nothing (insufficient information).  Also, each branch can depend on complex
> evaluation of crash information, possible duplicates, etc.
> 
> All the best, Ian W.
> 
>>> David Faure, faure at kde.org, http://www.davidfaure.fr
>>> Working on KDE Frameworks 5
> 
> _______________________________________________
> kde-mac at kde.org
> List Information: https://mail.kde.org/mailman/listinfo/kde-mac
> KDE/Mac Information: http://community.kde.org/Mac