Review Request 125725: Make KCrash optional for kservice

Martin Gräßlin mgraesslin at kde.org
Tue Oct 20 16:00:42 UTC 2015



> On Oct. 20, 2015, 3:52 p.m., Aleix Pol Gonzalez wrote:
> > src/kbuildsycoca/kbuildsycoca_main.cpp, line 122
> > <https://git.reviewboard.kde.org/r/125725/diff/1/?file=411919#file411919line122>
> >
> >     Maybe it would make sense to handle it using signal() directly here, rather than just ifdef'ing KCrash?
> 
> Christoph Cullmann wrote:
>     Perhaps, but then I would have to reimplement more or less what setEmergencySaveFunction does, or? I am not sure if that makes sense, if you want crash recovery, you can have KCrash.
> 
> Christoph Cullmann wrote:
>     On the other side: Ok, that was anyway not that useful, given kglobalaccel + kinit use KCrash, too.
>     Perhaps I should better take a look at KCrash to make it less verbose, e.g. not warn about missing drkonqui which won't be there on mac or win in the normal case.
> 
> Aleix Pol Gonzalez wrote:
>     Sure.
>     
>     Or maybe some of the code can become part of KCoreAddons?
> 
> David Faure wrote:
>     I've been thinking for quite some time that a very basic "run this function on crash" and "restart on crash" functionality would be good to have in QtCore. Could be KCoreAddons too indeed, otherwise.
>     No bug reporting and all that, just the basics for daemons and command-line tools.
>     
>     The trick however is how would KCrash work on top of that (would it be "use one or the other, they are fully independent and exclusive", or would it extend this mechanism - well, by setting that crash-handler function, maybe).
> 
> Martin Gräßlin wrote:
>     > given kglobalaccel + kinit use KCrash, too.
>     
>     isn't kglobalaccel only in the runtime part? If yes we can certainly make the complete runtime optional (which would turn it to tier1).
> 
> Christoph Cullmann wrote:
>     Yes, that is true, its only the "daemon".
>     Btw., I see that there are backends for mac + windows for that daemon, but I am not that sure it is that useful, as you have no dbus around to talk with it, in the normal case.

> but I am not that sure it is that useful, as you have no dbus around to talk with it, in the normal case.

I think they don't compile anyway.


- Martin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125725/#review87135
-----------------------------------------------------------


On Oct. 20, 2015, 4 p.m., Christoph Cullmann wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125725/
> -----------------------------------------------------------
> 
> (Updated Oct. 20, 2015, 4 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kservice
> 
> 
> Description
> -------
> 
> kservice depends on KCrash only for kbuildsycoca.
> make this optional and link only against it, if around. Move check to kbuildsyscoca file.
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt 4c0f269 
>   src/kbuildsycoca/CMakeLists.txt 19bdc84 
>   src/kbuildsycoca/kbuildsycoca_main.cpp 03619cc 
> 
> Diff: https://git.reviewboard.kde.org/r/125725/diff/
> 
> 
> Testing
> -------
> 
> Seems to compile fine without it.
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151020/23448b4d/attachment-0001.html>


More information about the Kde-frameworks-devel mailing list