> On March 24, 2014, 3:41 p.m., Alex Merry wrote: > > The correct solution is to get drkonqi merged into kcrash (see > > http://community.kde.org/Frameworks/Epics/New_Runtime_Organization). > > Aleix Pol Gonzalez wrote: > Agreed. If somebody has the time, it would be interesting to figure out > what can be uncommented (see commit f8b59b6c in kde-runtime). There's many > things commented out and I'm unsure what to do with it. > > Dan Vrátil wrote: > I agree, however until it is done, this patch would make lifes of > distribution packagers a bit easier :-) > > Kevin Ottens wrote: > Aleix, weren't you indeed planning to move drkonqi in? Any ETA? > > Aleix Pol Gonzalez wrote: > I wanted to figure it out first. At the moment Dr Konqi depends on some > commented out kdepimlibs bits I'm unsure what to do with, so I decided to > lower it's priority. I can do it before next week if it's considered > important. > > Dan Vrátil wrote: > Initial port of KXMLRPCClient to frameworks is already done. It's very > tiny (2 classes), so it could be properly frameworkized on the PIM sprint > this weekend. It depends on KIO ATM for doing HTTP POST requests, but maybe > it could be replaced by a Qt solution, so that it could go to Tier 1. > > Aleix Pol Gonzalez wrote: > I think we're a bit late for that. We can do it but the addition of > frameworks is frozen AFAIK. > > But yes, kdepimlibs should be sorted out ASAP and this sprint can be a > good moment for doing so. > > Alex Merry wrote: > As a temporary solution, the two classes could be just dropped into > KCrash, but without exporting them.
I've been looking into it, I made it compile completely by using KF5XmlRpcClient (the port of kdepimlibs is in a much better state than I expected, thanks!!). I'm unsure we want to provide the bugzilla integration together with drkonqi, so I've been thinking that we probably want to split it out into a plugin. In any case, this is quite unrelated to the subject, given that either in kcrash or in kde-runtime, this will have to be installed in libexec. - Aleix ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review53985 ----------------------------------------------------------- On March 24, 2014, 12:01 p.m., Dan Vrátil wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/117016/ > ----------------------------------------------------------- > > (Updated March 24, 2014, 12:01 p.m.) > > > Review request for KDE Frameworks. > > > Repository: kcrash > > > Description > ------- > > Since KCrash is a framework that relies on DrKonqi binary being provided by a > 3rd party software (kde-runtime), it should not make assumptions regarding > location of the utility. > > This patch makes KCrash to look for drkonqi binary first in $PATH, then > falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch > it's possible for distributions to ship KDE Frameworks in normal prefix > (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. > > > Diffs > ----- > > src/kcrash.cpp 87163cc > > Diff: https://git.reviewboard.kde.org/r/117016/diff/ > > > Testing > ------- > > - Installed KCrash into /usr prefix > - Installed drkonqi from kde-runtime master to /opt/kde5 prefix > - started broken application > - no "could not find drkonqi" warning anymore > - crashed application, got drkonqi window > > > Thanks, > > Dan Vrátil > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
