Re: Desktop Slideshow Settings
On Sunday, December 5, 2010, Steven Sroka wrote:
> add at the very beginning of BackgroundDialog::saveConfig(),if(
> !hasChanged() ) { return;}orif( hasChanged() ) { //the existing code that
> is run when a setting is changed.}
yes, that would work. it would still mean the wallpaper would reload if the
layout type was changed (e.g. default dekstop -> folderview) or when the mouse
actions are changed.
so while what you suggest would be an improvement (and i'd probably accept
such a patch), it would be even nicer to track wallpaper changes independantly
as well.
--
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: Desktop Slideshow Settings
Excuse the messing message before from me, I should top post like this since
Windows Live doesn't put arrows before each line of previous emails when
replying to them. Even though its not recommended to top post ;)
From: steven.sr...@live.ca
To: plasma-devel@kde.org
Subject: RE: Desktop Slideshow Settings
Date: Mon, 6 Dec 2010 00:42:01 -0500
On Sunday, December 5, 2010, Steven Sroka wrote:
> I'm assuming the settingsChanged() signal is emitted twice, once by 'Apply'
> and once by 'OK'. Is there anyway to stop the signal from emitting from
> the 'OK' button if the settings aren't changed (because the 'Apply' button
> has already emitted the signal and done all the necessary work)?
yes. and now that i understand what you are trying to accomplish ... :)
the problem is in BackgroundDialog::saveConfig in
kdebase/workspace/libs/plasmagenericshell/backgrounddialog.cpp
it is called when apply or ok is clicked and it unconditionally resets the
wallpaper. it probably needs to track when the wallpaper settings actually
change. right now it does this:
connect(wallpaperWidget, SIGNAL(modified(bool)), this,
SLOT(settingsModified(bool)));
settingsModified is a generic "something's changed" handler; a new slot could
be added that calls settingsModified, but which also tracks that value for the
wallpaper itself and if no changes have been made to the wallpaper config,
just not reset it.
---I
see, now I know what to look for.I noticed that BackgroundDialog keeps track
if there are changes made through BackgroundDialog::hasChanged()Would it be
possible to add at the very beginning of BackgroundDialog::saveConfig(),if(
!hasChanged() ) { return;}orif( hasChanged() ) { //the existing code that is
run when a setting is changed.}
___
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: Desktop Slideshow Settings
On Sunday, December 5, 2010, Steven Sroka wrote:
> I'm assuming the settingsChanged() signal is emitted twice, once by 'Apply'
> and once by 'OK'. Is there anyway to stop the signal from emitting from
> the 'OK' button if the settings aren't changed (because the 'Apply' button
> has already emitted the signal and done all the necessary work)?
yes. and now that i understand what you are trying to accomplish ... :)
the problem is in BackgroundDialog::saveConfig in
kdebase/workspace/libs/plasmagenericshell/backgrounddialog.cpp
it is called when apply or ok is clicked and it unconditionally resets the
wallpaper. it probably needs to track when the wallpaper settings actually
change. right now it does this:
connect(wallpaperWidget, SIGNAL(modified(bool)), this,
SLOT(settingsModified(bool)));
settingsModified is a generic "something's changed" handler; a new slot could
be added that calls settingsModified, but which also tracks that value for the
wallpaper itself and if no changes have been made to the wallpaper config,
just not reset it.
---I
see, now I know what to look for.I noticed that BackgroundDialog keeps track
if there are changes made through BackgroundDialog::hasChanged()Would it be
possible to add at the very beginning of BackgroundDialog::saveConfig(),if(
!hasChanged() ) { return;}orif( hasChanged() ) { //the existing code that is
run when a setting is changed.}___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Desktop Slideshow Settings
On Sunday, December 5, 2010, Steven Sroka wrote: > I'm assuming the settingsChanged() signal is emitted twice, once by 'Apply' > and once by 'OK'. Is there anyway to stop the signal from emitting from > the 'OK' button if the settings aren't changed (because the 'Apply' button > has already emitted the signal and done all the necessary work)? and one other thing that's probably needed: the slideshow should probably not reset itself if the directory lists haven't changed from it already has been set to. so this is probably two small fixes, one in libplasmagenericshell and one in the image wallpaper init() -- 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 new share dataengine
On Sunday, December 5, 2010, Thomas Olsen wrote: > Is it possible to offer GHNS from a javascript engine or an engine at all? yes; though DataEngines themselves offer no UI. it is usually exposed from a plasmoid's UI (configuration, usually) > I need to have a look at the new share engine; where is it situated in the > repository now? kdebase/workspace/plasma/generic/dataengines/share/ -- 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: Desktop Slideshow Settings
On Sunday, December 5, 2010, Steven Sroka wrote: > I'm assuming the settingsChanged() signal is emitted twice, once by 'Apply' > and once by 'OK'. Is there anyway to stop the signal from emitting from > the 'OK' button if the settings aren't changed (because the 'Apply' button > has already emitted the signal and done all the necessary work)? yes. and now that i understand what you are trying to accomplish ... :) the problem is in BackgroundDialog::saveConfig in kdebase/workspace/libs/plasmagenericshell/backgrounddialog.cpp it is called when apply or ok is clicked and it unconditionally resets the wallpaper. it probably needs to track when the wallpaper settings actually change. right now it does this: connect(wallpaperWidget, SIGNAL(modified(bool)), this, SLOT(settingsModified(bool))); settingsModified is a generic "something's changed" handler; a new slot could be added that calls settingsModified, but which also tracks that value for the wallpaper itself and if no changes have been made to the wallpaper config, just not reset it. -- 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: Desktop Slideshow Settings
Sorry for the late reply, I just switched to KDE 4.6 Beta 1 and it took some time to get stable and fast enough to set up the development dependancies. I'm try to prevent the slideshow wallpaper from changing everytime a user clicks 'OK' after clicking 'Apply'. I'm assuming the settingsChanged() signal is emitted twice, once by 'Apply' and once by 'OK'. Is there anyway to stop the signal from emitting from the 'OK' button if the settings aren't changed (because the 'Apply' button has already emitted the signal and done all the necessary work)? From: ase...@kde.org To: plasma-devel@kde.org Subject: Re: Desktop Slideshow Settings Date: Mon, 29 Nov 2010 16:07:03 -0800 On Monday, November 29, 2010, Steven Sroka wrote: > Pic of window and buttons attached. I think it is created in image.cpp aha. the ok/apply/cancel buttons. (this is one time when a picture was only worth 5 words. ;) those are handled automatically by KConfigDialog. when the settingsChanged signal is emitted, Apply becomes enabled. the state is reset after Apply is clicked. (this is actually covered in the Plasma::Wallpaper apidox, but sometimes that's more like a buried treasure than a useful learning tool.) Cancel and Ok are always there. assuming you are wanting to do something with Apply, what you are looking for is probably the Image::modified() slot in image.cpp. take a look at the things that connect to it / call it. or are you trying to do someting else with the buttons in that area? -- 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: Review Request: Plasma crash if lockout conf file is malformed.
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6060/#review9146 --- Ship it! makes sense to me (it's not doing anymore what te config says, but the cofig is saying actually to make a broken applet) - Marco On 2010-12-05 22:36:32, Nicolas Lécureuil wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/6060/ > --- > > (Updated 2010-12-05 22:36:32) > > > Review request for Plasma. > > > Summary > --- > > if on the plasma conf file we have for the lockout plasmoid : > > showHibernateButton=false > showLockButton=false > showLogoutButton=false > showSleepButton=false > showSwitchUserButton=false > > Plasma will crash. > > This patch check this and provide a default setting if this happens. > > > Diffs > - > > trunk/KDE/kdebase/workspace/plasma/generic/applets/lock_logout/lockout.cpp > 1203948 > > Diff: http://svn.reviewboard.kde.org/r/6060/diff > > > Testing > --- > > > Thanks, > > Nicolas > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Plasma crash if lockout conf file is malformed.
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6060/ --- Review request for Plasma. Summary --- if on the plasma conf file we have for the lockout plasmoid : showHibernateButton=false showLockButton=false showLogoutButton=false showSleepButton=false showSwitchUserButton=false Plasma will crash. This patch check this and provide a default setting if this happens. Diffs - trunk/KDE/kdebase/workspace/plasma/generic/applets/lock_logout/lockout.cpp 1203948 Diff: http://svn.reviewboard.kde.org/r/6060/diff Testing --- Thanks, Nicolas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Lockout widget: Explain to the user that he must select a button to show
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6041/ --- (Updated 2010-12-05 21:41:56.363884) Review request for Plasma. Changes --- I updated the patch this way : - I changed the string. - I fixed the UI so when it is opened , the widget is disabled if only one checkbox is checked. Summary --- When the user ask to show no buttons in the lockout widget, nothing tell the user that this is not possible, and when he saves the configuration nothing changed in the widget. With this patch, if the user unselect all the checkboxes, he is warned. This addresses bug 256879. https://bugs.kde.org/show_bug.cgi?id=256879 Diffs (updated) - trunk/KDE/kdebase/workspace/plasma/generic/applets/lock_logout/lockout.h 1203948 trunk/KDE/kdebase/workspace/plasma/generic/applets/lock_logout/lockout.cpp 1203948 Diff: http://svn.reviewboard.kde.org/r/6041/diff Testing --- Thanks, Nicolas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The new share dataengine
On Sunday, December 5, 2010, Thomas Olsen wrote: > As I was fiddling around with an URL shortener plasmoid similar to the > pastebin plasmoid I was thinking if it would be an idea to also provide > URL Shortener services in the same engine or id would be better to have a > separate one? imho: it probably makes more sense to keep them separate as they are different kinds of tasks, even if related. the structure could be similar/the same, however. i'd even think that a URL shortener dataengine could easily be written in javascript (giving it addons for free in the process as well) -- 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: Separate caching for unthemed SVGs requesting colorization
> On 2010-12-05 14:50:33, Manuel Mommertz wrote: > > It is now even worse then before. Unthemed graphics still use the colors > > from plasma theme but don't get informed if the theme changes. this means, > > the colors that are used when first rendering the graphics stay even if I > > switch the theme. > > The plasma elements itself don't get rerendered on theme change. Only > > graphics that have to be rerendered for another reason (resizing a widget, > > ...) get the svg's from the new activated theme. > > Marco Martin wrote: > well, they shouldn't be informed on theme changes in this case... > > Manuel Mommertz wrote: > right, but on colorscheme changes. with doesn't happen. > > Aaron Seigo wrote: > "Unthemed graphics still use the colors from plasma theme but don't get > informed if the theme changes." > > unthemed graphics never use colors from the plasma theme. they either use > no colors, or they use the system colors. in which case are unthemed graphics > using the color scheme from the plasma theme? > > "the colors that are used when first rendering the graphics stay even if > I switch the theme." > > of course. the theme is not relevant. you get to pick between "themed" > and "unthemed". > > "The plasma elements itself don't get rerendered on theme change." > > which plasma elements? > > "Only graphics that have to be rerendered for another reason (resizing a > widget, ...) get the svg's from the new activated theme." > > are you saying that NO svg's (themed or unthemed) are being updated? > because that works here. > > "right, but on colorscheme changes. with doesn't happen." > > do you mean the KDE color scheme change? e.g. when you change the > colorscheme in the Colors control panel? > > i'm quite confused now by what you mean. can you give me a clear, simple > use case with detailed steps of reproduction so that i may identify and > reproduce the problem and subsequently fix it? thanks. > > Manuel Mommertz wrote: > http://img502.imageshack.us/img502/2729/plasmadesktopxk7517.png > > Steps I did before taking this screenshot: > > Logged in while Oxygen was the selected theme. > Switched theme to Air. > > Noticed: After switching all graphics stay unchanged. The folderview > changed after some 10-20 seconds. The handle (seen next to folderview) > changed to air after I unhovered folderview and hovered it again. Panel stays > unchanged. The Entry in the taskbar gets the hover-graphic from air while > falling back to oxygen when mouse leaves the entry. > Windeco still uses oxywin colors. > > What I did to ensure this is not some strange local thing: > Logged out > Removed cache files from themes (oxygen and air, each two files. No other > files were there from plasma) > Removed kde-install-path > Reinstalled > Logged in again > Nothing changed > > What I am going to do now: > rebuild kdelibs and kdebase and test again none of this had anything to do with these changes, however. these were all little bugs that had crept into the codebase around repainting when the theme changes. i've fixed the ones i've seen so far already. but again, nothing to do with these changes. they would have been broken before this commit, too. what is broken (so i can reproduce, test and fix) with unthemed svgs? - Aaron --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6008/#review9136 --- On 2010-11-28 23:52:16, Aaron Seigo wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/6008/ > --- > > (Updated 2010-11-28 23:52:16) > > > 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 c
Re: Review Request: Separate caching for unthemed SVGs requesting colorization
> On 2010-12-05 14:50:33, Manuel Mommertz wrote: > > It is now even worse then before. Unthemed graphics still use the colors > > from plasma theme but don't get informed if the theme changes. this means, > > the colors that are used when first rendering the graphics stay even if I > > switch the theme. > > The plasma elements itself don't get rerendered on theme change. Only > > graphics that have to be rerendered for another reason (resizing a widget, > > ...) get the svg's from the new activated theme. > > Marco Martin wrote: > well, they shouldn't be informed on theme changes in this case... > > Manuel Mommertz wrote: > right, but on colorscheme changes. with doesn't happen. > > Aaron Seigo wrote: > "Unthemed graphics still use the colors from plasma theme but don't get > informed if the theme changes." > > unthemed graphics never use colors from the plasma theme. they either use > no colors, or they use the system colors. in which case are unthemed graphics > using the color scheme from the plasma theme? > > "the colors that are used when first rendering the graphics stay even if > I switch the theme." > > of course. the theme is not relevant. you get to pick between "themed" > and "unthemed". > > "The plasma elements itself don't get rerendered on theme change." > > which plasma elements? > > "Only graphics that have to be rerendered for another reason (resizing a > widget, ...) get the svg's from the new activated theme." > > are you saying that NO svg's (themed or unthemed) are being updated? > because that works here. > > "right, but on colorscheme changes. with doesn't happen." > > do you mean the KDE color scheme change? e.g. when you change the > colorscheme in the Colors control panel? > > i'm quite confused now by what you mean. can you give me a clear, simple > use case with detailed steps of reproduction so that i may identify and > reproduce the problem and subsequently fix it? thanks. http://img502.imageshack.us/img502/2729/plasmadesktopxk7517.png Steps I did before taking this screenshot: Logged in while Oxygen was the selected theme. Switched theme to Air. Noticed: After switching all graphics stay unchanged. The folderview changed after some 10-20 seconds. The handle (seen next to folderview) changed to air after I unhovered folderview and hovered it again. Panel stays unchanged. The Entry in the taskbar gets the hover-graphic from air while falling back to oxygen when mouse leaves the entry. Windeco still uses oxywin colors. What I did to ensure this is not some strange local thing: Logged out Removed cache files from themes (oxygen and air, each two files. No other files were there from plasma) Removed kde-install-path Reinstalled Logged in again Nothing changed What I am going to do now: rebuild kdelibs and kdebase and test again - Manuel --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6008/#review9136 --- On 2010-11-28 23:52:16, Aaron Seigo wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/6008/ > --- > > (Updated 2010-11-28 23:52:16) > > > 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 cach
Re: Review Request: Separate caching for unthemed SVGs requesting colorization
> On 2010-12-05 14:50:33, Manuel Mommertz wrote: > > It is now even worse then before. Unthemed graphics still use the colors > > from plasma theme but don't get informed if the theme changes. this means, > > the colors that are used when first rendering the graphics stay even if I > > switch the theme. > > The plasma elements itself don't get rerendered on theme change. Only > > graphics that have to be rerendered for another reason (resizing a widget, > > ...) get the svg's from the new activated theme. > > Marco Martin wrote: > well, they shouldn't be informed on theme changes in this case... > > Manuel Mommertz wrote: > right, but on colorscheme changes. with doesn't happen. "Unthemed graphics still use the colors from plasma theme but don't get informed if the theme changes." unthemed graphics never use colors from the plasma theme. they either use no colors, or they use the system colors. in which case are unthemed graphics using the color scheme from the plasma theme? "the colors that are used when first rendering the graphics stay even if I switch the theme." of course. the theme is not relevant. you get to pick between "themed" and "unthemed". "The plasma elements itself don't get rerendered on theme change." which plasma elements? "Only graphics that have to be rerendered for another reason (resizing a widget, ...) get the svg's from the new activated theme." are you saying that NO svg's (themed or unthemed) are being updated? because that works here. "right, but on colorscheme changes. with doesn't happen." do you mean the KDE color scheme change? e.g. when you change the colorscheme in the Colors control panel? i'm quite confused now by what you mean. can you give me a clear, simple use case with detailed steps of reproduction so that i may identify and reproduce the problem and subsequently fix it? thanks. - Aaron --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6008/#review9136 --- On 2010-11-28 23:52:16, Aaron Seigo wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/6008/ > --- > > (Updated 2010-11-28 23:52:16) > > > 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 > --- >
Re: Review Request: Separate caching for unthemed SVGs requesting colorization
> On 2010-12-05 14:50:33, Manuel Mommertz wrote: > > It is now even worse then before. Unthemed graphics still use the colors > > from plasma theme but don't get informed if the theme changes. this means, > > the colors that are used when first rendering the graphics stay even if I > > switch the theme. > > The plasma elements itself don't get rerendered on theme change. Only > > graphics that have to be rerendered for another reason (resizing a widget, > > ...) get the svg's from the new activated theme. > > Marco Martin wrote: > well, they shouldn't be informed on theme changes in this case... right, but on colorscheme changes. with doesn't happen. - Manuel --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6008/#review9136 --- On 2010-11-28 23:52:16, Aaron Seigo wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/6008/ > --- > > (Updated 2010-11-28 23:52:16) > > > 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: Separate caching for unthemed SVGs requesting colorization
> On 2010-12-05 14:50:33, Manuel Mommertz wrote: > > It is now even worse then before. Unthemed graphics still use the colors > > from plasma theme but don't get informed if the theme changes. this means, > > the colors that are used when first rendering the graphics stay even if I > > switch the theme. > > The plasma elements itself don't get rerendered on theme change. Only > > graphics that have to be rerendered for another reason (resizing a widget, > > ...) get the svg's from the new activated theme. well, they shouldn't be informed on theme changes in this case... - Marco --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6008/#review9136 --- On 2010-11-28 23:52:16, Aaron Seigo wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/6008/ > --- > > (Updated 2010-11-28 23:52:16) > > > 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: Separate caching for unthemed SVGs requesting colorization
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6008/#review9136 --- It is now even worse then before. Unthemed graphics still use the colors from plasma theme but don't get informed if the theme changes. this means, the colors that are used when first rendering the graphics stay even if I switch the theme. The plasma elements itself don't get rerendered on theme change. Only graphics that have to be rerendered for another reason (resizing a widget, ...) get the svg's from the new activated theme. - Manuel On 2010-11-28 23:52:16, Aaron Seigo wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/6008/ > --- > > (Updated 2010-11-28 23:52:16) > > > 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
