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...@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-...@kde.org> > Cc: David Faure <fa...@kde.org>, Aleix Pol <aleix...@kde.org> > Reply-To: KDE Software on Mac OS X <kde-...@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 <fa...@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, fa...@kde.org, http://www.davidfaure.fr >>> Working on KDE Frameworks 5 > > _______________________________________________ > kde-...@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