Re: [kde-promo] start of elevator pitch for plasma on devices
In the elevator pitch I miss some mention to the existing support behind the Plasma platform. Something along the lines of "In addition to the community work, Plasma development is supported by $BIG_COMPANY_NAME", where $BIG_COMPANY_NAME currently could use the names of Nokia, Intel, AMD... for MeeGo, or some others that support KDE in general. On 19 November 2010 11:05, Aaron J. Seigo wrote: > On Friday, November 19, 2010, Marco Martin wrote: > > another thing i would like to add, maybe as a separate page is a set > > of counterpoints on the most common objections i heard, like > > why not using just qml a big case of platform vs primitive ui toolset > > why what various kde ieces offers is not all hoverhead (i've heard > > many people screaming about duplication of stuff that we offer. is not > > as much as it seems i think) > > as you hear these, please add these questions and objections to the bottom > of > the page under the misc notes section. i'll try to work through them as i > can, > unless someone beats me to it of course. > > i'll still work on the opening arguments for a bit, but then we definitely > do > need to have answers for the common / innevitable follow up questions that > occur. > > > will look at it, however help of somebody not too tied on the > > implementation details would be helpful :D > > yep; which is why we have the promo people on the thread. already getting > some > good feedback from them :) > > -- > 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 > > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Using Plasma::Svg outside of Plasma
I looked a bit deeper in the code and there are some more things that need a bit of work in my eyes: Currently Plasma::Theme::styleSheet takes its colors always from defaultTheme instead of the Theme it is called from. This is very easy to fix. If a Plasma::Svg is not themed it stores its pixmaps in the cache of defaultTheme. For this, it would be a better solution to have a generic systemTheme or something like that, as there is no need to rerender this, if the default theme changes. Beside this, there is really no logical relation between an unthemed svg and the default plasma theme. To conclude: I still think that a generic Plasma::Theme would be the best way to solve this issues. But I am open to other solutions. I am going to create a working patch for this until next sunday but as i can only work on weekends and there might be other private stuff, this might take longer. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Using Plasma::Svg outside of Plasma
On Saturday, November 27, 2010, Manuel Mommertz wrote: > Way better then my idea. But we still need the stylesheet from > Plasma::Theme but with colors from the system. Any idea how to archive > this? yes; will require some changes to ThemePrivate::processStyleSheet and SvgPrivate::createRenderer. -- 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: Using Plasma::Svg outside of Plasma
On Sunday, November 28, 2010, Manuel Mommertz wrote: > I looked a bit deeper in the code and there are some more things that need > a bit of work in my eyes: > > Currently Plasma::Theme::styleSheet takes its colors always from > defaultTheme instead of the Theme it is called from. This is very easy to > fix. yes, i noticed that as well. looking at some of the new code in Svg and Theme, it's probably time to do some more profiling of Svg as well as make sure the caching is working properly (e.g. no renderers created on a second run of the app) > If a Plasma::Svg is not themed it stores its pixmaps in the cache of > defaultTheme. For this, it would be a better solution to have a generic > systemTheme or something like that, as there is no need to rerender this, > if the default theme changes. Beside this, there is really no logical > relation between an unthemed svg and the default plasma theme. this isn't fatal, and if the occurance of theme changes is nominal then the overhead of another cache file is probably not worth it. if the themes were going to be changing several times each session and there were significant numbers of unthemed SVGs, then it might be worth thinking about. and since it is an entirely internal detail, the policy for this can change if we find it is an actual issue. > To conclude: I still think that a generic Plasma::Theme would be the best > way to solve this issues. i disagree; such a theme would just be a way to work around non-themed SVGs. which is an oxymoron. it also means applications would need to remember to set the theme correctly for a given svg and we can do that a lot simpler for them. -- 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: KRunner Crash BuG:207592
On Saturday, November 27, 2010, Matthias Fuchs wrote: > What do you think? KBookmarkManager should be usable without showing GUI bits; so something like your #2 -- 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: Review Request: Fixes QuickSand scrolling animation
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5988/#review9015 --- Ship it! looks like it also cleans up some dubious memory management with the time line creation. - Aaron On 2010-11-27 21:04:37, Matthias Fuchs wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/5988/ > --- > > (Updated 2010-11-27 21:04:37) > > > Review request for Plasma. > > > Summary > --- > > If an animation is already running finish it before starting a new one. > BUG:209485 > > > Diffs > - > > /trunk/KDE/kdebase/workspace/krunner/interfaces/quicksand/qs_matchview.h > 1201458 > /trunk/KDE/kdebase/workspace/krunner/interfaces/quicksand/qs_matchview.cpp > 1201458 > > Diff: http://svn.reviewboard.kde.org/r/5988/diff > > > Testing > --- > > > Thanks, > > Matthias > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Using Plasma::Svg outside of Plasma
On Sunday 28 November 2010 12:08:12 Aaron J. Seigo wrote: > looking at some of the new code in Svg and Theme, it's probably time to do > some more profiling of Svg as well as make sure the caching is working > properly (e.g. no renderers created on a second run of the app) agreed. should be on the agenda for 4.7 > > If a Plasma::Svg is not themed it stores its pixmaps in the cache of > > defaultTheme. For this, it would be a better solution to have a generic > > systemTheme or something like that, as there is no need to rerender this, > > if the default theme changes. Beside this, there is really no logical > > relation between an unthemed svg and the default plasma theme. > > this isn't fatal if the default theme doesn't use system colors but the unthemed svg does, this indeed is fatal as the pixmaps for this svg stay in the cache on changes in the colorscheme. > > To conclude: I still think that a generic Plasma::Theme would be the best > > way to solve this issues. > > i disagree; such a theme would just be a way to work around non-themed > SVGs. which is an oxymoron. it also means applications would need to > remember to set the theme correctly for a given svg and we can do that a > lot simpler for them. applications don't need to know this. we can decide in Plasma::Svg. If we have a unthemed one, just use the generic theme. But there is a question that should be solved first: For 4.7 we have time to investigate in this. But what should we do for 4.6? If we want to support unthemed svgs that use system colors, we need a solution that doesn't involve to much investigation (and changes). With this in mind i would say we shouldn't officialy support this for 4.6 and work on a good solution for 4.7. But on the personal side, I know from a guy that has worked hard to create a theme for aurorae that uses system colors. I really doesn't want to say him that he has to wait over 6 month to release it. :-/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
The KWin Coding Style Situation
Hi, CC-int Plasma as I would like to get some opinion on it. From various discussion on IRC and looking through review requests, it seems that we have a general problem with our coding style. * The coding style is only used in KWin * Developers seem to have problems with it, nobody really knows how the style should look like (I think I mostly get it, but only mostly) * The coding style is not consistent Personally I see this as a unneeded barrier to get into KWin development. Because of that I think we have to do something about it. For me the actual coding style does not matter as long as it's consistent - but that is not the case. So I would propose the following: 1. Follow the rules from Plasma concerning coding style (and all other development matters - reviews, git, mergin...) 2. Switch to new coding style together with git migration (December, 20th) 3. Reformat complete code base except clients with new coding style and submit this to a new branch. Merge it with master after let's say two weeks Thoughts on that? What I dislike about step 3 is that this would make bisecting in future more difficult. But I see it as the only sane way to get a consistent coding style. Cheers Martin 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: The KWin Coding Style Situation
Just noting that plasma coding style is the same as kdelibs [1] -- Cheerio, Ivan [1] http://techbase.kde.org/Policies/Kdelibs_Coding_Style -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Notes widget: Working bold/italic/underline/strike out even when the note text is empty
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6005/ --- Review request for Plasma and Stephen Kelly. Summary --- Text format of the note can't be changed while the note is empty, so I add a space and I change the text format. This work around is rather stupid but I don't have any nicer idea. Anyway this might be a bug in KRichTextEdit so I add to this review request also steveire. Diffs - trunk/KDE/kdeplasma-addons/applets/notes/notes.h 1201054 trunk/KDE/kdeplasma-addons/applets/notes/notes.cpp 1201054 Diff: http://svn.reviewboard.kde.org/r/6005/diff Testing --- Thanks, Davide ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The KWin Coding Style Situation
On Sunday 28 November 2010 21:18:55 Chani wrote:
> a new branch? two weeks? why?
> isn't there a program for reformatting code, that could just sweep over all
> of it and be one commit? even if it's not perfect, something that could at
> least fix the brace indentation...
let's say I don't trust it and don't want to possibly degenerate the code
quality by getting the braces wrong. So waiting for trunk/master open up again
and testing two weeks for obvious regressions sounds like an idea to me.
>
> and, svn has the ability to ignore ws changes (which a lot of these changes
> will be). I don't know about git though.
Whitespaces shouldn't be a problem, more the moving of the braces. Those will
most likely end up in the diff.
if( foo )
doSomething();
will become
if (foo) {
doSomething();
}
I doubt that this can be handled by tools.
>
> I say, get the style conversion over with quick. maybe just do it now
> instead of waiting for git :)
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: The KWin Coding Style Situation
On Sunday 28 November 2010 20:20:33 Martin Gräßlin wrote: > From various discussion on IRC and looking through review requests, it > seems that we have a general problem with our coding style. For kdelibs, we have a policy that only _new_ code needs to follow the style guidelines. Existing code is not reformatted. I would prefer switching to kdelibs style in kwin, but only for new code (i.e. new files or new functions). While this inevitably leads to inconsistency, it has repository technical advantages (history, blame, bisect, licensing etc.) which we see as a requirement for kdelibs code. Small fixes _usually_ are done in the style of the surrounding code to keep at least some consistency. Currently "external" contributions are mostly new effects, and don't usually touch kwin core code. Any new file you are currently working on (ES support etc.) should be new kdelibs style, because that is where future contributions and fixes will land. Other than that, I agree that the current style is annoying and you should not force contributors to use it. Christoph Feck (kdepepo) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Turns the slide effect off if KRunner is set to floating.
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6006/ --- Review request for kwin and Plasma. Summary --- Turns the slide effect off if floating is used. This is related to BUG:218678 but does not completely fix it. Steps to reproduce: 1. set krunner to top screen, hide/show it 2. set krunner to floating 3. hide it 4. show it Step 3 and 4 use the slide-animation that should only be used if it is at the top. This patch fixes this behavior to some degree. Now only step three will use the slide animation and from that point on the correct one will be used. I am not sure how I can also fix step 3, help welcome! :) Diffs - /trunk/KDE/kdebase/workspace/krunner/krunnerdialog.cpp 1201754 Diff: http://svn.reviewboard.kde.org/r/6006/diff Testing --- Thanks, Matthias ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Turns the slide effect off if KRunner is set to floating.
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6006/#review9024 --- Step 3 probably needs changes in slidingpopups effect. When the window is added it is added to an internal hash. The effect does not remove the window from the hash when the property is changed. So here we could add an explicit remove by setting the property to e.g. 0 and check that. If you want to have a look on it: trunk/KDE/kdebase/workspace/kwin/effects/slidingpopups/slidingpopups.cpp method propertyNotify. You can find examples for how to explicitly disable in taskbarthumbnails or highlightwindow effects. - Martin On 2010-11-28 20:44:27, Matthias Fuchs wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/6006/ > --- > > (Updated 2010-11-28 20:44:27) > > > Review request for kwin and Plasma. > > > Summary > --- > > Turns the slide effect off if floating is used. This is related to BUG:218678 > but does not completely fix it. > > Steps to reproduce: > 1. set krunner to top screen, hide/show it > 2. set krunner to floating > 3. hide it > 4. show it > > Step 3 and 4 use the slide-animation that should only be used if it is at the > top. > This patch fixes this behavior to some degree. > > Now only step three will use the slide animation and from that point on the > correct one will be used. > I am not sure how I can also fix step 3, help welcome! :) > > > Diffs > - > > /trunk/KDE/kdebase/workspace/krunner/krunnerdialog.cpp 1201754 > > Diff: http://svn.reviewboard.kde.org/r/6006/diff > > > Testing > --- > > > Thanks, > > Matthias > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Using Plasma::Svg outside of Plasma
On Sunday, November 28, 2010, Manuel Mommertz wrote: > > > If a Plasma::Svg is not themed it stores its pixmaps in the cache of > > > defaultTheme. For this, it would be a better solution to have a generic > > > systemTheme or something like that, as there is no need to rerender > > > this, if the default theme changes. Beside this, there is really no > > > logical relation between an unthemed svg and the default plasma theme. > > > > this isn't fatal > > if the default theme doesn't use system colors but the unthemed svg does, > this indeed is fatal as the pixmaps for this svg stay in the cache on > changes in the colorscheme. well, we do clear the renderer, and this is already done for system theme color following svgs. problem is that, as you note, the on-disk cache is not cleared (Svg relies on Theme dropping the cache on such change) and short of doing bookkeeping of all id's cached in a given unthemed-but-colored svg there is no easy way out. (and then there are edge cases where things change while the cache is not maintained, e.g. the app is closed or the svg object destroyed.) that's very unfortunate, really :( > But on the personal side, I know from a guy that has worked hard to create > a theme for aurorae that uses system colors. I really doesn't want to say > him that he has to wait over 6 month to release it. :-/ i'm pretty well finished implementing it already. -- 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: Using Plasma::Svg outside of Plasma
On Sunday, November 28, 2010, Aaron J. Seigo wrote: > that's very unfortunate, really :( to fully explain the unfortunateness and why "just set the theme to something else internally" is quite so straightforward, Svg also needs to maintain the ability to set the Theme for the object via Svg::setTheme, while maintaining that "other theme" for caching and coloring when the Svg itself is not themed. denying setTheme calls when it is not themed means requiring setting the imagePath first, which just seems brittle (calls the rely on the order of other calls in non-obvious ways) it would probably also be defensible to say, "if you use setTheme on an Svg that doesn't use a theme Svg file, you're program is buggy. but that, too, seems fragile. separating the caching out of Theme and into a caching object occurred to me, but then it's not just the caching that is needed but also the colors and then we have most of Theme all over again. meh.. -- 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: Using Plasma::Svg outside of Plasma
On Sunday 28 November 2010 22:23:54 Aaron J. Seigo wrote: > i'm pretty well finished implementing it already you are just awesome! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The KWin Coding Style Situation
On Sunday, November 28, 2010, Christoph Feck wrote: > On Sunday 28 November 2010 20:20:33 Martin Gräßlin wrote: > > From various discussion on IRC and looking through review requests, it > > seems that we have a general problem with our coding style. > > For kdelibs, we have a policy that only _new_ code needs to follow the > style guidelines. Existing code is not reformatted. I would prefer > switching to kdelibs style in kwin, but only for new code (i.e. new files > or new functions). kwin and kdelibs differ in some ways that are significant to this: * kwin has just undergone a maintainership change and has "a" maintainer; kdelibs is maintained in pieces by a relatively large number of people and there is long term continuity of that maintainership * kdelibs is developed in pieces (e.g. this class or that group of classes) rather than as a holistic whole, which kwin is; this means that kdelibs hacking is less affected by global consistency than kwin is. so yes, a reformat will create an "opaque membrane" in the history of the repository, but wether that is actually a problem or not comes down to the development practices around kwin. e.g. how important is it to git bisect N months in the past? ballance this (and how often the history is really used in this manner in kwin) with the benefits of code clarity in terms of keeping bar for contribution low and quality high. -- 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: The KWin Coding Style Situation
Hummm... but /I/ _really_ *like* the style as it is now!!! ... As for the transition, i guess it mostly depends on automated fixing reliability (i ran that once in kdevelop years ago and _never_ tried it again, but i guess the tools have meanwhile improved ;-) Otherwise (ie if automated conversion still implicitly means that you'll have to step after gcc to fix a thousand bugs) i'd say that this isn't a beauty contest, we just want to get things usable, so it's not required to update code that's never been or will be touched in years and whenever you actually do some there, you just "fix" the surrounding function "by the way". Bisecting (if used at all) is probably not a (longterm) issue, as it's typically done between recent versions anyway (so only a small period where "recent" shifts across the merge would potentially harm at all) Cheers & thanksalot =D Thomas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The KWin Coding Style Situation
On Sunday, November 28, 2010, Martin Gräßlin wrote: > 1. Follow the rules from Plasma concerning coding style (and all other > development matters - reviews, git, mergin...) i forgot to make this explicit in my earlier email, but it's worth saying imo: to me this means that when we make decisions regarding development process, that both plasma and kwin people are involved in the discussion and that we arrive at consensus together. imho, it can't work as "plasma people[1] decide, kwin gets to follow along". to me this is really about working together as a more coordinated "meta project". see this happening more and more in practice (such as the google code-in studen the other day on irc who ended up working on kwin effect things to get the desired effect in plasma dashboard), so it's really not anything really all that new. i am very happy and excited to see us finding ways to mesh our gears better, though. :) [1] there's overlap between plasma and kwin contributors as it is, so that distinction is even a bit artificial :) -- 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
Review Request: The KSystemActivityDialog uses MB as default unit.
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6007/ --- Review request for Plasma, Aaron Seigo and John Tapsell. Summary --- The KSystemActivityDialog uses MB as default unit. BUG:222022 Diffs - /trunk/KDE/kdebase/workspace/krunner/ksystemactivitydialog.cpp 1201754 Diff: http://svn.reviewboard.kde.org/r/6007/diff Testing --- Thanks, Matthias ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: The KSystemActivityDialog uses MB as default unit.
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6007/ --- (Updated 2010-11-28 23:31:11.663968) Review request for Plasma, Aaron Seigo and John Tapsell. Summary --- The KSystemActivityDialog uses MB as default unit. BUG:222022 This addresses bug 222022. https://bugs.kde.org/show_bug.cgi?id=222022 Diffs - /trunk/KDE/kdebase/workspace/krunner/ksystemactivitydialog.cpp 1201754 Diff: http://svn.reviewboard.kde.org/r/6007/diff Testing --- Thanks, Matthias ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: The KSystemActivityDialog uses MB as default unit.
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6007/#review9029 --- Sorry, but this is too much of a hack, and I don't really agree with the idea of the change anyway. If you do a quick poll somewhere and show that other people agree it should be MB by default, then I'll change it. But I don't want to change it just based on 1 person. - John On 2010-11-28 23:31:11, Matthias Fuchs wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/6007/ > --- > > (Updated 2010-11-28 23:31:11) > > > Review request for Plasma, Aaron Seigo and John Tapsell. > > > Summary > --- > > The KSystemActivityDialog uses MB as default unit. > BUG:222022 > > > This addresses bug 222022. > https://bugs.kde.org/show_bug.cgi?id=222022 > > > Diffs > - > > /trunk/KDE/kdebase/workspace/krunner/ksystemactivitydialog.cpp 1201754 > > Diff: http://svn.reviewboard.kde.org/r/6007/diff > > > Testing > --- > > > Thanks, > > Matthias > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: The KSystemActivityDialog uses MB as default unit.
---
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6007/#review9030
---
i think the real problem is in KSysGuardProcessList::loadSettings(const
KConfigGroup &cg) where it uses hard coded defaults such as this line:
setUnits((ProcessModel::Units) cg.readEntry("units",
(int)ProcessModel::UnitsKB));
it should be possible to do:
m_processList.setUnits(ProcessModel::UnitsMB);
m_processList.loadSettings(config);
and have the current settings used as the defaults. the hardcoded defaults can
be set up in the ctor of KSysGuardProcessList. so the setUnits line above would
become:
setUnits((ProcessModel::Units) cg.readEntry("units", (int)d->m_model.units()));
thoughts?
- Aaron
On 2010-11-28 23:31:11, Matthias Fuchs wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6007/
> ---
>
> (Updated 2010-11-28 23:31:11)
>
>
> Review request for Plasma, Aaron Seigo and John Tapsell.
>
>
> Summary
> ---
>
> The KSystemActivityDialog uses MB as default unit.
> BUG:222022
>
>
> This addresses bug 222022.
> https://bugs.kde.org/show_bug.cgi?id=222022
>
>
> Diffs
> -
>
> /trunk/KDE/kdebase/workspace/krunner/ksystemactivitydialog.cpp 1201754
>
> Diff: http://svn.reviewboard.kde.org/r/6007/diff
>
>
> Testing
> ---
>
>
> Thanks,
>
> Matthias
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: The KSystemActivityDialog uses MB as default unit.
> On 2010-11-28 23:39:49, Aaron Seigo wrote:
> > i think the real problem is in KSysGuardProcessList::loadSettings(const
> > KConfigGroup &cg) where it uses hard coded defaults such as this line:
> >
> > setUnits((ProcessModel::Units) cg.readEntry("units",
> > (int)ProcessModel::UnitsKB));
> >
> > it should be possible to do:
> >
> > m_processList.setUnits(ProcessModel::UnitsMB);
> > m_processList.loadSettings(config);
> >
> > and have the current settings used as the defaults. the hardcoded defaults
> > can be set up in the ctor of KSysGuardProcessList. so the setUnits line
> > above would become:
> >
> > setUnits((ProcessModel::Units) cg.readEntry("units",
> > (int)d->m_model.units()));
> >
> > thoughts?
Yep, makes a lot of sense.
- John
---
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6007/#review9030
---
On 2010-11-28 23:31:11, Matthias Fuchs wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6007/
> ---
>
> (Updated 2010-11-28 23:31:11)
>
>
> Review request for Plasma, Aaron Seigo and John Tapsell.
>
>
> Summary
> ---
>
> The KSystemActivityDialog uses MB as default unit.
> BUG:222022
>
>
> This addresses bug 222022.
> https://bugs.kde.org/show_bug.cgi?id=222022
>
>
> Diffs
> -
>
> /trunk/KDE/kdebase/workspace/krunner/ksystemactivitydialog.cpp 1201754
>
> Diff: http://svn.reviewboard.kde.org/r/6007/diff
>
>
> Testing
> ---
>
>
> Thanks,
>
> Matthias
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Separate caching for unthemed SVGs requesting colorization
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6008/ --- Review request for Plasma. Summary --- see: http://www.mail-archive.com/plasma-devel@kde.org/msg13494.html this introduces a Theme object used by Svg to cache the rendering of svg's asking to be colorized, but which are not part of the theme. this requires an independent cache and set of color files, therefore a second Theme object. SvgPrivate::actualTheme() is thus overridden by SvgPrivate::cacheAndColorsTheme() whenever caching or colors are used. there are two remaining defects of varying severity, though neither is very high imho: a) if the system color palette changes when the application is not running (or an svg using such a theme is not running) the cache will not be dropped. this is an existing issue, however, not something introduce by this patchset b) the new system color theme is shared for performance reasons, but once created it is never deleted. it ought to be reference counted so it can be cleaned up after in use, but this is currently not done. several other fixes crept into this patchset (sorry :/) including: * not dropping the cache just because we change themes; this made sense when just plasma-desktop used this or when the apps using Plasma::Theme all used the same theme. this is no longer the case, really, and having applications changing themes randomly kicking the cache out from underneath other apps that may still be using it is undesirable. this does mean that cache files will accumulate. not sure that's a big issue as they don't tend to be large and are in an area marked as "cache" (so ripe for clean-without-care) * consolidate the signal/slot connections in SvgPrivate::checkColorHints, and now the check is consistent on all paths (previously, it wasn't!) * missing (and possible cause of cache key ambiguity) separator in CACHE_ID_WITH_SIZE * cleanups such as getting rid of superfluous use of Plasma:: namespacing in code that is now in libplasma, such as the stylesheeting. (it was from a plasmoid sebas wrote originally, iirc, explaining the historical reason for the explicit namespacing) in any case, consider this a draft at this stage. i'm interested in geting feedback, improvements and testing. Diffs - /trunk/KDE/kdelibs/plasma/private/svg_p.h 1199366 /trunk/KDE/kdelibs/plasma/svg.cpp 1201684 /trunk/KDE/kdelibs/plasma/theme.cpp 1201685 Diff: http://svn.reviewboard.kde.org/r/6008/diff Testing --- just running normal plasma-desktop and what i use. needs testing with svg's that will actually rely on this feature. Thanks, Aaron ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: The KSystemActivityDialog uses MB as default unit.
> On 2010-11-28 23:32:29, John Tapsell wrote: > > Sorry, but this is too much of a hack, and I don't really agree with the > > idea of the change anyway. > > > > If you do a quick poll somewhere and show that other people agree it should > > be MB by default, then I'll change it. But I don't want to change it just > > based on 1 person. Actually ksysguard also uses MB by default here. Personally I like MB more, simply because it is easier to see what a program uses as the numbers are smaller. Maybe ideally would be to have it the same as in Dolphin. I.e. 437.5 M, 1.3 K, 214 B all at the same time. - Matthias --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6007/#review9029 --- On 2010-11-28 23:31:11, Matthias Fuchs wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/6007/ > --- > > (Updated 2010-11-28 23:31:11) > > > Review request for Plasma, Aaron Seigo and John Tapsell. > > > Summary > --- > > The KSystemActivityDialog uses MB as default unit. > BUG:222022 > > > This addresses bug 222022. > https://bugs.kde.org/show_bug.cgi?id=222022 > > > Diffs > - > > /trunk/KDE/kdebase/workspace/krunner/ksystemactivitydialog.cpp 1201754 > > Diff: http://svn.reviewboard.kde.org/r/6007/diff > > > Testing > --- > > > Thanks, > > Matthias > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
