Summary: | Crash after changing some of FancyTask settings. | ||
---|---|---|---|
Product: | [Unmaintained] plasma4 | Reporter: | Jerry Ablan <jerryablan> |
Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED DOWNSTREAM | ||
Severity: | crash | CC: | aseigo, asraniel, emdeck, linkstat |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Jerry Ablan
2010-05-02 02:46:36 UTC
bug in fancytasks, which is a third party widget. (In reply to comment #1) > bug in fancytasks, which is a third party widget. Or in taskmanager library (time to drop this dependency). I've added next workaround for checking if task object is valid, should help, I'll post update soon. "Or in taskmanager library (time to drop this dependency)" yes, it is time to do something with that dependency, and not because of bugs in it (which isn't the case here, btw) but because it is in kdebase-workspace and has no binary compatibility guarantees. without BC guarantees, using it from a component with a separate release is gambling for problems. there are three possible routes that i see: * stop using libtaskmanger from kdebase/workspace * provide a copy of libtaskmanger (with the installed library binary named something different :) with your widget, avoiding BC issues * go over the public libtaskmanager API once more to ensure we can reasonably start doing BC releases (e.g. make sure every public class has a dptr, that there aren't any protected or private members that shouldn't be there, move the "internal" methods that are publicly exposed in classes like Task to a private class) and then we can start doing BC releases from 4.5 on. the third choice is the best long term strategy as it allows us to share code and efforts. the second choice is the easiest. you can find me, and the rest of the gang, in #plasma on irc or on plasma-devel@kde.org if you'd like to pursue, or even just explore pursuing, the third option. Yeah, but I've already wrote on mailing list why libtaskmanager I (and not only me) don't want use it anymore and use own flexible engine. But anyway third option is best, but I want to first experiment with architecture described on mailing list. *** Bug 239947 has been marked as a duplicate of this bug. *** |