So with the availability of KDE applications in the Windows store we
don't need drkonqi.
We get perfect reports, if the users privacy settings allow it, for each
submitted app separately.
Every maintainer can request access to the store, for submissions and
reports.
So I guess we should focus on bringing more apps to the store, rather
than porting drkonqi.
Cheers,
Hannah
On 17.09.20 16:54, Harald Sitter wrote:
On Thu, Sep 17, 2020 at 4:17 PM Hannah von Reth <vonr...@kde.org> wrote:
Hi,
looks like some quoted text is missing.
I have no idea bout the state of drkonqi on windows,
ages ago a gsoc student did *things* but I don't think anybody was ever
able to use it.
I can remember a more recent communication that people where trying
again to get it to work.
Ah sorry.
The original:
drkonqi is part of plasma, yet it gets built on windows. shall we stop
doing that? windows keeps not having expected plasma requirements
because the rest of plasma is not on windows
https://build.kde.org/job/Plasma/job/drkonqi/job/kf5-qt5%20WindowsMSVCQt5.14/
this already happened a couple weeks ago and was then temporarily
reverted but now it fails again. uselessly I might add. why we even
want to have drkonqi on windows at all is equally questionable as the
platform already has a far superior crash reporting system.
I guess the question is mostly.... do we think that pursuing drkonqi
on windows is useful at all?
The way I see it we'd either want to use the windows error reporting
system (to send reports off to microsoft and then get them from there)
or we'd need a fair amount of extra code in drkonqi to tie into
local-only WER (I'm assuming that's a thing based on the WER API).
Since we distribute the binaries we only need a mini dump and the
exact build version to then grab our debug symbols for that build and
do server-side tracing, so the actual live-tracing feature of drkonqi
is fairly uninteresting IMHO.
HS
