Re: [Nepomuk] Activity services merge
*** This is a cross-list-thread *** Hi all, I'm in the process of recreating the activity-related services and I'd like to merge the kded activities daemon and nepomuk activities service. Essentially, the current state is this: - kded activities daemon handles the data needed by workspaces (plasma, kwin) which can exist even without nepomuk, while when nepomuk is online, it acts like cache - nepomuk service which links resources (documents, apps...) to activities. Both will experience significant changes, mostly feature-wise. The reasons for the proposed merger into one service: - easier maintainability - less code duplication (both services need to know the list of activities, names etc.) - less d-bus communication (kded daemon needs to pass most things to the nepomuk service) Reasons why it was separated in the first place - kwin people didn't want to depend on nepomuk A: The merged service would continue to work w/o nepomuk running so, apart from the fact that the service will have to be linked against libnepomuk, nothing will change - kded module was kept as simple as possible to avoid crashing kded A: See below - nepomuk tracking of opened/closed/etc. documents should not depend on existence of activities A: This can be kept as well, it is only that both activities and tracking will live in one executable, which would be the case even w/o the merge - plasma people didn't complain about anything except of missing features in kded daemon whilch will be addressed anyway :) So, from my POV, the only remaining problem is crashing the kded if everything is put inside it. For this, there are two possible solutions: 1) Make an out-of-process kded module 2) Make an independent d-bus service which will start as soon as anybody tries to access some of its method (my favourite feature of d-bus) Thoughts? Complaints? If not, the merger will happen. Any ideas regarding the name of the service would be more than welcome. IIRC, Trueg had something against ActivityManager. For me, the alternative could be UsageTracker... but using Tracker in the name wouldn't be a good idea. I am totally fine with a merger. My only problem is the kded stability. So as long as that is addressed I fully agree that one service makes more sense. Cheers, Sebastian ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Make kolourpicker color grab working from autohiding panels
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5465/#review7884 --- Ship it! looks good, though the patch looks like it hasn't been tidied up for commit yet. the code itself looks good, though, so just tidy it up and commit. nicely done! /trunk/KDE/kdeplasma-addons/applets/kolourpicker/kolourpicker.h http://svn.reviewboard.kde.org/r/5465/#comment8134 delete the line before committing :) /trunk/KDE/kdeplasma-addons/applets/kolourpicker/kolourpicker.cpp http://svn.reviewboard.kde.org/r/5465/#comment8135 watch the whitespace :) /trunk/KDE/kdeplasma-addons/applets/kolourpicker/kolourpicker.cpp http://svn.reviewboard.kde.org/r/5465/#comment8136 delete before commit - Aaron On 2010-09-28 10:01:19, Björn Ruberg wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5465/ --- (Updated 2010-09-28 10:01:19) Review request for Plasma. Summary --- Patch fixes the bug that the mouse grab of the color-picker goes away when the panel hides. The idea of initiating the grab not on the panel but on a self created widget is from ksnapshot. I want someone to look at it because I want to commit it KDE 4.5 branch as a bugfix. This addresses bug 252350. https://bugs.kde.org/show_bug.cgi?id=252350 Diffs - /trunk/KDE/kdeplasma-addons/applets/kolourpicker/kolourpicker.h 1180054 /trunk/KDE/kdeplasma-addons/applets/kolourpicker/kolourpicker.cpp 1180054 Diff: http://svn.reviewboard.kde.org/r/5465/diff Testing --- Had kolourpicker in an autohiding panel - and it suddenly works. Tested with an applet on the desktop too. Works. Thanks, Björn ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: render SVGs with system colors
On Monday 27 September 2010 23:09:16 Aaron J. Seigo wrote: have you done any timings to test how long the DOM parsing takes on svgs we have in the theme? Average loading time with current trunk: 11ms Average loading time with my patch applied: 27ms But i added a simple 'contains(current-color-scheme)' on the QByteArray. So the expencive double-parsing is only used if the svg really needs it. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: render SVGs with system colors
On Tuesday 28 September 2010 08:49:28 Julian Bäume wrote: I’ve seen something similar in libkdegames (look for KGameSvgDocument, somewhat different approach, but one could do similar things) and I really want to have something like that myself. It allows much more manipulation. A very nice thing for games but to much for plasma. I don't think that we need more then replacing styles here. On the other side, this should be enaugh for most games too. Coloring the player would be possible if we extend Plasma::Svg so one can set the used stylesheet. What I’ve been thinking about is a way to highlight certain elements in the SVG DOM, preferably using the system palette. ATM I’m using Qt’s highlight mechanism, which draws a frame around the selected item. This looks somewhat ugly ;) So please go ahead, I‘m eager to see, what you come up with. This should be possible with KGameSvgDocument, as I understand it. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: render SVGs with system colors
On Wednesday, September 29, 2010, Manuel Mommertz wrote: On Monday 27 September 2010 23:09:16 Aaron J. Seigo wrote: have you done any timings to test how long the DOM parsing takes on svgs we have in the theme? Average loading time with current trunk: 11ms Average loading time with my patch applied: 27ms do you know where this 16ms is being spent? is it in the parsing? the construction of the stylesheet string? .. ? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: render SVGs with system colors
On Wednesday 29 September 2010 22:43:32 Aaron J. Seigo wrote: On Wednesday, September 29, 2010, Manuel Mommertz wrote: On Monday 27 September 2010 23:09:16 Aaron J. Seigo wrote: have you done any timings to test how long the DOM parsing takes on svgs we have in the theme? Average loading time with current trunk: 11ms Average loading time with my patch applied: 27ms do you know where this 16ms is being spent? is it in the parsing? the construction of the stylesheet string? .. ? It is the parsing with QDomDocument. Stylesheet creation is now in Plasma::Theme::stylesheet(SVG) where it belongs and this is cached, so only created once. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
