[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Fwd: [KDE/Mac] DrKonqi placement
From:       <mk-lists () email ! de>
Date:       2014-10-23 23:45:09
Message-ID: 37AF3999-D94F-4CE4-90B8-9A3F644E757E () email ! de
[Download RAW message or body]

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@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@kde.org>
> Cc: David Faure <faure@kde.org>, Aleix Pol <aleixpol@kde.org>
> Reply-To: KDE Software on Mac OS X <kde-mac@kde.org>
> =

> Hi Marko,
> =

> Nice to see you again=85 :-)
> =

> On 23/10/2014, at 7:30 AM, Marko K=E4ning 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=92t =
you?
> =

> No, I don't follow kde-frameworks-devel, but it's good that one of us doe=
s=85
> 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@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-h=
a and
> last-minute panic was about regarding https://git.reviewboard.kde.org/r/1=
20431/
> "Fix and future-proof Dr Konqi security methods on Bugzilla"=85 :-)
> (@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 proce=
dure
> call to Bugzilla via the KXmlRpc::Client class.  KXmlRpc::Client could pr=
esumably
> use another I/O method --- carrier pigeons maybe=85 :-)  Or perhaps, Dr K=
 could use
> another Bugzilla command-protocol, such as REST (but I do not know much a=
bout that).
> =

>>> Would be annoying to have to enter your password again there, when the =
KIO =

>>> infrastructure would normally take care of it=85.
> =

> KWallet is all you need to get your login ID and password entered in Dr K=
onqi's
> login dialog box.  It even works on Apple OS X now=85 ;-)
> =

> In future versions of Bugzilla, the login ID and password will be require=
d 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 alternative=
s 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 immedi=
ately
> before the database update (if there is one).  That way, we could avoid h=
aving
> to log in unnecessarily, if the outcome is that the crash has insufficien=
t 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/lo=
gin could
> be needed, so that the end-user is prepared for that before he goes throu=
gh all
> the dialog boxes.
> =

>>> Maybe we need to separate the basic crash dialog from the bug reporting =

>>> functionality=85.
> =

> It is already separated quite a lot.  The real problem IMHO is that the s=
uccession
> of dialog boxes and the interaction between them and the underlying datab=
ase
> (bugs.kde.org) has been coded in such a complex way.  Perhaps that is bec=
ause
> the underlying "wizard" paradigm is sequential, whereas the dialog is bra=
nching
> and has (at least) three outcomes: report a bug, add to an existing bug o=
r report
> nothing (insufficient information).  Also, each branch can depend on comp=
lex
> evaluation of crash information, possible duplicates, etc.
> =

> All the best, Ian W.
> =

>>> David Faure, faure@kde.org, http://www.davidfaure.fr
>>> Working on KDE Frameworks 5
> =

> _______________________________________________
> kde-mac@kde.org
> List Information: https://mail.kde.org/mailman/listinfo/kde-mac
> KDE/Mac Information: http://community.kde.org/Mac

_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
[prev in list] [next in list] [prev in thread] [next in thread]