Martin says coredump might be a bad idea as it can cause quite a system slow down and freezes the application while working.

• drkonqi apparently closes the X connection before doing its thing thus "hiding" the crashed app. perhaps we should do the same in kcrash.
  • by extension applications which haven't explicitly disabled or bypassed drkonqi are hidden once coredump starts, so for most of our apps this shouldn't be a problem
• the performance impact most likely has more to do with coredump backtracing than with actually dumping the core. IFF there was a setting for auto-trace we could disable that, alas, there is not.

neon-desktop should be updated correctly. Instead of forcefully ripping out apport and friends I am currently musing on implementing something like the kubuntu hook tech https://cgit.kde.org/kubuntu-notification-helper.git/tree/src/daemon/hookevent except without standard UI definitions maybe as they make l10n more complicated. OTOH we could make kubuntu-notification-helper more generic if we used that. It's also somewhat more constricting in UI design.
Discussing whether notifications are the way to go with Jens and general visuals of this.

For now new installations will come without any crash collection by default, existing installations will retain it until the notification stuff is figured out.

So, I talked with Jens about this and we concluded that putting a note on a blog would be good enough. On that note Jens thinks we should have a blog.

Showing a Y/N notification (notification only) to apply the change would be possible but given the effort this would take to engineer and translate I am saying that it's not worth the effort for now. If this becomes a repeating pattern it might be good to revisit this decision and implement a simple system.

For something like Kubuntu's hoook system a "notification center" of sorts would be handy. Which is basically what the kubuntu thing is in a way, except more generic and less terrible looking. This is out of scope and not necessary for now. But plays into a larger refactor of systray/systemsettings I have been told.

Random design thoughts on a notification system:

• notifications should shoot after ~5 minutes on every boot
• or right after installation
• notifications should be Y/N
• short sentences
• once acted upon notifications should put a stamp in /var/ (possibly via a polkit'd dbus service) to disable the notification
• probably needs supporting kded service (alternatively one could check with startkde-systemd stuff on kde's git if one could wire a systemd service such that it starts for every xsession? systemd definitely can do conditional starts based on file presence)

Social mediaed a suggestion to remove apport to conserve memory. Since we do not install apport-kde apport recording crashes at best has a performance impact but otherwise not impair UX. And when an application crashes a bit of subsequent sluggishness probably is the least concern.

closing this as indeed apport and whoopsie don't install on new installs and drkonqi still works