Re: exporting/importing config keys? plus: Mandelbrot news
2010/3/15 Aaron J. Seigo ase...@kde.org: On March 13, 2010, Benoit Jacob wrote: contextualActions().append(m_exportImageAction); contextualActions().append(m_exportConfigAction); contextualActions().append(m_importConfigAction); the append() is being called on a copy of the collection. as soon as you change the return value from contextualActions(), the internal data structure detatches from the original, shared one and copies the values over. so this obviously has no effect. Yes, saw that, that's fixed now :) You have a shiny improved Mandelbrot wallpaper in trunk now. Just for the record and so I don't look like a complete C++ newbie, the reason why I made that wrong assumption is I'm developing a C++ library (Eigen) where we have methods returning proxy objects such that operating on their return values affects the original object. I just... need to get back to earth more often and realize that only a small minority of C++ APIs work like that :) Benoit what you are looking for is setContextualActions. -- 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: exporting/importing config keys? plus: Mandelbrot news
Thanks to Ossi on IRC, this is now fixed.
Benoit
2010/3/13 Benoit Jacob jacob.benoi...@gmail.com:
ok, finally a hopefully not too stupid question.
Here's my code:
void Mandelbrot::exportConfig()
{
KUrl url = KFileDialog::getSaveUrl(
KUrl(),
*.txt|Text files,
0,
i18n(Save File),
KFileDialog::ConfirmOverwrite
);
KConfig config(url.fileName());
KConfigGroup configgroup(config, Mandelbrot);
save(configgroup);
configgroup.config()-sync();
}
Problem: it doesn't actually write the file. Why?
(The file dialog runs well, but the file isn't actually getting
created, and if i create it beforehand, it doesn't get written).
I had tried following this:
http://techbase.kde.org/index.php?title=Development/Tutorials/KConfig#Writing_Entries
Benoit
2010/3/13 Benoit Jacob jacob.benoi...@gmail.com:
2010/3/13 Benoit Jacob jacob.benoi...@gmail.com:
2010/3/13 Benoit Jacob jacob.benoi...@gmail.com:
2010/3/13 Benoit Jacob jacob.benoi...@gmail.com:
2010/3/13 Marco Martin notm...@gmail.com:
On Saturday 13 March 2010, Benoit Jacob wrote:
Hi,
I've just made a bunch of Mandelbrot improvements in trunk, plus 1
bugfix backported to 4.4, see below.
great :)
I would like to honor this feature request:
http://forum.kde.org/brainstorm.php#idea55395_page1
Basically I want to create a right-click desktop menu entry that
allows to export/import Mandelbrot's configuration to/from a file.
Does KDE's config system allow that right away? Or should I code my
own file I/O?
create a new kconfig on a new file, a kconfiggroup on it, then write all
your
config entries copied from the main kconfiggroup
Also, any example code for adding a right-click menu to a plasma
wallpaper?
QListQAction* Wallpaper::contextualActions()
I tried that but can't get it to work: it compiles, but the actions
don't show up in the right click menu.
Here's what I did. In my Mandelbrot (inheriting Wallpaper) class I
have new members,
QAction m_exportImageAction;
QAction m_exportConfigAction;
QAction m_importConfigAction;
Then they are initialized in the initialization list of my Mandelbrot
constructor:
Mandelbrot::Mandelbrot(QObject *parent, const QVariantList args)
: Plasma::Wallpaper(parent, args), m_image(0), m_tiling(this),
m_exportImageAction(i18n(Export image...), 0),
m_exportConfigAction(i18n(Export parameters...), 0),
m_importConfigAction(i18n(Import parameters...), 0),
I also tried passing 'this' instead of '0' for the 'parent' argument
here, no difference...
Then, in the body of that constructor, I do:
contextualActions().append(m_exportImageAction);
contextualActions().append(m_exportConfigAction);
contextualActions().append(m_importConfigAction);
connect(m_exportImageAction, SIGNAL(triggered()), this,
SLOT(exportImage()));
connect(m_exportConfigAction, SIGNAL(triggered()), this,
SLOT(exportConfig()));
connect(m_importConfigAction, SIGNAL(triggered()), this,
SLOT(importConfig()));
What am I doing wrong?
Found it --- contextualActions(), despite _not_ being const-qualified,
is returning a list _by value_. Since I didn't see a const-qualifier,
my brain just assumed it would return a reference.
Oops.
It _is_ const qualified :)
Sorry, I'm really tired !!
Benoit
Looks like I have to use setContextualActions.
Benoit
Thanks
Benoit
(wouldn't make more sense putting it into the config dialog anyways?)
Cheers,
Marco Martin
___
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
exporting/importing config keys? plus: Mandelbrot news
Hi, I've just made a bunch of Mandelbrot improvements in trunk, plus 1 bugfix backported to 4.4, see below. I would like to honor this feature request: http://forum.kde.org/brainstorm.php#idea55395_page1 Basically I want to create a right-click desktop menu entry that allows to export/import Mandelbrot's configuration to/from a file. Does KDE's config system allow that right away? Or should I code my own file I/O? Also, any example code for adding a right-click menu to a plasma wallpaper? Thanks Benoit PS. The aforementioned Mandelbrot changelog: * fix the mandelbrot ate my right-click desktop menu bug --- backported to 4.4 * big optimization: interior tiles are now detected early * scalability: different threads now work on completely separate tiles * fix the visual artifacts on startup bug * significant code simplification and cleanup * several smaller fixes ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: exporting/importing config keys? plus: Mandelbrot news
2010/3/13 Marco Martin notm...@gmail.com: On Saturday 13 March 2010, Benoit Jacob wrote: Hi, I've just made a bunch of Mandelbrot improvements in trunk, plus 1 bugfix backported to 4.4, see below. great :) I would like to honor this feature request: http://forum.kde.org/brainstorm.php#idea55395_page1 Basically I want to create a right-click desktop menu entry that allows to export/import Mandelbrot's configuration to/from a file. Does KDE's config system allow that right away? Or should I code my own file I/O? create a new kconfig on a new file, a kconfiggroup on it, then write all your config entries copied from the main kconfiggroup Ah, I see. How do I create a new kconfig on a new file ? It's not obvious to me from http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKConfigGroup.html Also, any example code for adding a right-click menu to a plasma wallpaper? QListQAction* Wallpaper::contextualActions() Thanks! (wouldn't make more sense putting it into the config dialog anyways?) The config i'm saving there is not just the config from the config dialog, it's also (and most importantly) the viewpoint as determined by the user by mouse interaction on the desktop. Whence the idea of a right click action... Cheers Benoit Cheers, Marco Martin ___ 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: exporting/importing config keys? plus: Mandelbrot news
2010/3/13 Marco Martin notm...@gmail.com: On Saturday 13 March 2010, Benoit Jacob wrote: Hi, I've just made a bunch of Mandelbrot improvements in trunk, plus 1 bugfix backported to 4.4, see below. great :) I would like to honor this feature request: http://forum.kde.org/brainstorm.php#idea55395_page1 Basically I want to create a right-click desktop menu entry that allows to export/import Mandelbrot's configuration to/from a file. Does KDE's config system allow that right away? Or should I code my own file I/O? create a new kconfig on a new file, a kconfiggroup on it, then write all your config entries copied from the main kconfiggroup Also, any example code for adding a right-click menu to a plasma wallpaper? QListQAction* Wallpaper::contextualActions() I tried that but can't get it to work: it compiles, but the actions don't show up in the right click menu. Here's what I did. In my Mandelbrot (inheriting Wallpaper) class I have new members, QAction m_exportImageAction; QAction m_exportConfigAction; QAction m_importConfigAction; Then they are initialized in the initialization list of my Mandelbrot constructor: Mandelbrot::Mandelbrot(QObject *parent, const QVariantList args) : Plasma::Wallpaper(parent, args), m_image(0), m_tiling(this), m_exportImageAction(i18n(Export image...), 0), m_exportConfigAction(i18n(Export parameters...), 0), m_importConfigAction(i18n(Import parameters...), 0), Then, in the body of that constructor, I do: contextualActions().append(m_exportImageAction); contextualActions().append(m_exportConfigAction); contextualActions().append(m_importConfigAction); connect(m_exportImageAction, SIGNAL(triggered()), this, SLOT(exportImage())); connect(m_exportConfigAction, SIGNAL(triggered()), this, SLOT(exportConfig())); connect(m_importConfigAction, SIGNAL(triggered()), this, SLOT(importConfig())); What am I doing wrong? Thanks Benoit (wouldn't make more sense putting it into the config dialog anyways?) Cheers, Marco Martin ___ 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: exporting/importing config keys? plus: Mandelbrot news
2010/3/13 Benoit Jacob jacob.benoi...@gmail.com: 2010/3/13 Marco Martin notm...@gmail.com: On Saturday 13 March 2010, Benoit Jacob wrote: Hi, I've just made a bunch of Mandelbrot improvements in trunk, plus 1 bugfix backported to 4.4, see below. great :) I would like to honor this feature request: http://forum.kde.org/brainstorm.php#idea55395_page1 Basically I want to create a right-click desktop menu entry that allows to export/import Mandelbrot's configuration to/from a file. Does KDE's config system allow that right away? Or should I code my own file I/O? create a new kconfig on a new file, a kconfiggroup on it, then write all your config entries copied from the main kconfiggroup Also, any example code for adding a right-click menu to a plasma wallpaper? QListQAction* Wallpaper::contextualActions() I tried that but can't get it to work: it compiles, but the actions don't show up in the right click menu. Here's what I did. In my Mandelbrot (inheriting Wallpaper) class I have new members, QAction m_exportImageAction; QAction m_exportConfigAction; QAction m_importConfigAction; Then they are initialized in the initialization list of my Mandelbrot constructor: Mandelbrot::Mandelbrot(QObject *parent, const QVariantList args) : Plasma::Wallpaper(parent, args), m_image(0), m_tiling(this), m_exportImageAction(i18n(Export image...), 0), m_exportConfigAction(i18n(Export parameters...), 0), m_importConfigAction(i18n(Import parameters...), 0), I also tried passing 'this' instead of '0' for the 'parent' argument here, no difference... Then, in the body of that constructor, I do: contextualActions().append(m_exportImageAction); contextualActions().append(m_exportConfigAction); contextualActions().append(m_importConfigAction); connect(m_exportImageAction, SIGNAL(triggered()), this, SLOT(exportImage())); connect(m_exportConfigAction, SIGNAL(triggered()), this, SLOT(exportConfig())); connect(m_importConfigAction, SIGNAL(triggered()), this, SLOT(importConfig())); What am I doing wrong? Thanks Benoit (wouldn't make more sense putting it into the config dialog anyways?) Cheers, Marco Martin ___ 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: exporting/importing config keys? plus: Mandelbrot news
2010/3/13 Benoit Jacob jacob.benoi...@gmail.com: 2010/3/13 Benoit Jacob jacob.benoi...@gmail.com: 2010/3/13 Marco Martin notm...@gmail.com: On Saturday 13 March 2010, Benoit Jacob wrote: Hi, I've just made a bunch of Mandelbrot improvements in trunk, plus 1 bugfix backported to 4.4, see below. great :) I would like to honor this feature request: http://forum.kde.org/brainstorm.php#idea55395_page1 Basically I want to create a right-click desktop menu entry that allows to export/import Mandelbrot's configuration to/from a file. Does KDE's config system allow that right away? Or should I code my own file I/O? create a new kconfig on a new file, a kconfiggroup on it, then write all your config entries copied from the main kconfiggroup Also, any example code for adding a right-click menu to a plasma wallpaper? QListQAction* Wallpaper::contextualActions() I tried that but can't get it to work: it compiles, but the actions don't show up in the right click menu. Here's what I did. In my Mandelbrot (inheriting Wallpaper) class I have new members, QAction m_exportImageAction; QAction m_exportConfigAction; QAction m_importConfigAction; Then they are initialized in the initialization list of my Mandelbrot constructor: Mandelbrot::Mandelbrot(QObject *parent, const QVariantList args) : Plasma::Wallpaper(parent, args), m_image(0), m_tiling(this), m_exportImageAction(i18n(Export image...), 0), m_exportConfigAction(i18n(Export parameters...), 0), m_importConfigAction(i18n(Import parameters...), 0), I also tried passing 'this' instead of '0' for the 'parent' argument here, no difference... Then, in the body of that constructor, I do: contextualActions().append(m_exportImageAction); contextualActions().append(m_exportConfigAction); contextualActions().append(m_importConfigAction); connect(m_exportImageAction, SIGNAL(triggered()), this, SLOT(exportImage())); connect(m_exportConfigAction, SIGNAL(triggered()), this, SLOT(exportConfig())); connect(m_importConfigAction, SIGNAL(triggered()), this, SLOT(importConfig())); What am I doing wrong? Found it --- contextualActions(), despite _not_ being const-qualified, is returning a list _by value_. Since I didn't see a const-qualifier, my brain just assumed it would return a reference. Looks like I have to use setContextualActions. Benoit Thanks Benoit (wouldn't make more sense putting it into the config dialog anyways?) Cheers, Marco Martin ___ 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: exporting/importing config keys? plus: Mandelbrot news
2010/3/13 Benoit Jacob jacob.benoi...@gmail.com: 2010/3/13 Benoit Jacob jacob.benoi...@gmail.com: 2010/3/13 Benoit Jacob jacob.benoi...@gmail.com: 2010/3/13 Marco Martin notm...@gmail.com: On Saturday 13 March 2010, Benoit Jacob wrote: Hi, I've just made a bunch of Mandelbrot improvements in trunk, plus 1 bugfix backported to 4.4, see below. great :) I would like to honor this feature request: http://forum.kde.org/brainstorm.php#idea55395_page1 Basically I want to create a right-click desktop menu entry that allows to export/import Mandelbrot's configuration to/from a file. Does KDE's config system allow that right away? Or should I code my own file I/O? create a new kconfig on a new file, a kconfiggroup on it, then write all your config entries copied from the main kconfiggroup Also, any example code for adding a right-click menu to a plasma wallpaper? QListQAction* Wallpaper::contextualActions() I tried that but can't get it to work: it compiles, but the actions don't show up in the right click menu. Here's what I did. In my Mandelbrot (inheriting Wallpaper) class I have new members, QAction m_exportImageAction; QAction m_exportConfigAction; QAction m_importConfigAction; Then they are initialized in the initialization list of my Mandelbrot constructor: Mandelbrot::Mandelbrot(QObject *parent, const QVariantList args) : Plasma::Wallpaper(parent, args), m_image(0), m_tiling(this), m_exportImageAction(i18n(Export image...), 0), m_exportConfigAction(i18n(Export parameters...), 0), m_importConfigAction(i18n(Import parameters...), 0), I also tried passing 'this' instead of '0' for the 'parent' argument here, no difference... Then, in the body of that constructor, I do: contextualActions().append(m_exportImageAction); contextualActions().append(m_exportConfigAction); contextualActions().append(m_importConfigAction); connect(m_exportImageAction, SIGNAL(triggered()), this, SLOT(exportImage())); connect(m_exportConfigAction, SIGNAL(triggered()), this, SLOT(exportConfig())); connect(m_importConfigAction, SIGNAL(triggered()), this, SLOT(importConfig())); What am I doing wrong? Found it --- contextualActions(), despite _not_ being const-qualified, is returning a list _by value_. Since I didn't see a const-qualifier, my brain just assumed it would return a reference. Oops. It _is_ const qualified :) Sorry, I'm really tired !! Benoit Looks like I have to use setContextualActions. Benoit Thanks Benoit (wouldn't make more sense putting it into the config dialog anyways?) Cheers, Marco Martin ___ 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
wheel events no longer passed to the wallpaper?
Hi, I just tried 4.4 beta2 and noted that mouse wheel events are no longer passed to the wallpaper. Is this intentional or a bug? Notice that this breaks the Mandelbrot wallpaper, as it makes the zooming functionality much harder to discover (have to use MMB DD). Happy holidays! Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wheel events no longer passed to the wallpaper?
2009/12/29 Chani chan...@gmail.com: On December 29, 2009 14:39:05 Benoit Jacob wrote: Hi, I just tried 4.4 beta2 and noted that mouse wheel events are no longer passed to the wallpaper. Is this intentional or a bug? Notice that this breaks the Mandelbrot wallpaper, as it makes the zooming functionality much harder to discover (have to use MMB DD). in the wheel event, containmentactions plugins get higher priority than the wallpaper. that's the opposite of mouse press/release events... I'll switch it so the wallpaper gets top priority. Thanks! unfortunately this will prevent users of your wallpaper from using the scroll wheel on desktop switches virtual-desktop feature. Yes, I agree that this is a problem. But this was already the case in KDE 4.3, so at least the users are used to that. I think that for users who chose to use Mandelbrot, when they use the mouse wheel on the wallpaper, they are more likely to want a zoom than a desktop switch... Benoit folderview's got the same problem - I think whatever widget it uses to display icons eats scroll events even when it doesn't need scrollbars. -- This message brought to you by eevil bananas and the number 3. www.chani3.com ___ 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: kdereview review day
You're welcome and thanks for reporting the bug! Benoit 2009/4/30 Anne-Marie Mahfouf annemarie.mahf...@free.fr: Hi Benoit, My system froze (I think there's something fishy in Desktop effects as X froze after I disable compositing). I checked Mandelbrot again with debugfull and it's OK now! Thanks for the fix and for trusting me when I said I had it all black! Best regards, Anne-Marie ___ 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: how to use the cache-to-disk feature in Wallpaper
this is now committed, as a testcase... Example of console output: plasma-desktop(7077) Mandelbrot::updateCache: remove mandelbrot-157422800 Corresponding to this code: // remove old image from cache kDebug() remove m_cacheKey; insertIntoCache(m_cacheKey, QImage()); Yet the file still exists: bja...@kiwi:~/.kde/cache-kiwi/plasma-wallpapers ls home mandelbrot-157422800.png mandelbrot-72259600.png usr Cheers, Benoit 2009/4/13 Benoit Jacob jacob.benoi...@gmail.com: I have a problem, I wonder if I'm hitting a bug. It seems as if insertIntoCache(key, QImage()) does not do anything when it is called from ~Mandelbrot(). The expected behavior was to remove the image corresponding to 'key' from the cache. I have really checked that the key is correct and that isUsingDiskCache() returns true. Looking at the source code in wallpaper.cpp, I can't see anything else to check... When I used to call insertIntoCache(key, QImage()) from a slot connected to a QTimer, it did work. So there seems to be something specific to calling it from the destructor. Cheers, Benoit 2009/4/12 Benoit Jacob jacob.benoi...@gmail.com: 2009/4/12 Aaron J. Seigo ase...@kde.org: if you have 3 containments with the same image as the wallpaper, it shouldn't create three cache files on disk. so there is no real mapping from cache file to containment; there is a mapping of sorts between wallpaper plugins and the cache file they are using ... ah, right, i hadn't thought of this. For the rest, I agree, and I don't see any good solution... The main reason for stale cached images will probably be if plasma crashes (which is bound to happen as any binary plugin may crash plasma). Maybe then one could say that, when plasma starts for the first time after a crash, it prunes its cache (like removing the oldest files until the cache size is under a certain limit, as you suggested). Cheers, Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: how to use the cache-to-disk feature in Wallpaper
By the way the committed code does this from save(), not from the destructor, so this wasn't where to look for an explanation. Cheers, Benoit 2009/4/13 Benoit Jacob jacob.benoi...@gmail.com: this is now committed, as a testcase... Example of console output: plasma-desktop(7077) Mandelbrot::updateCache: remove mandelbrot-157422800 Corresponding to this code: // remove old image from cache kDebug() remove m_cacheKey; insertIntoCache(m_cacheKey, QImage()); Yet the file still exists: bja...@kiwi:~/.kde/cache-kiwi/plasma-wallpapers ls home mandelbrot-157422800.png mandelbrot-72259600.png usr Cheers, Benoit 2009/4/13 Benoit Jacob jacob.benoi...@gmail.com: I have a problem, I wonder if I'm hitting a bug. It seems as if insertIntoCache(key, QImage()) does not do anything when it is called from ~Mandelbrot(). The expected behavior was to remove the image corresponding to 'key' from the cache. I have really checked that the key is correct and that isUsingDiskCache() returns true. Looking at the source code in wallpaper.cpp, I can't see anything else to check... When I used to call insertIntoCache(key, QImage()) from a slot connected to a QTimer, it did work. So there seems to be something specific to calling it from the destructor. Cheers, Benoit 2009/4/12 Benoit Jacob jacob.benoi...@gmail.com: 2009/4/12 Aaron J. Seigo ase...@kde.org: if you have 3 containments with the same image as the wallpaper, it shouldn't create three cache files on disk. so there is no real mapping from cache file to containment; there is a mapping of sorts between wallpaper plugins and the cache file they are using ... ah, right, i hadn't thought of this. For the rest, I agree, and I don't see any good solution... The main reason for stale cached images will probably be if plasma crashes (which is bound to happen as any binary plugin may crash plasma). Maybe then one could say that, when plasma starts for the first time after a crash, it prunes its cache (like removing the oldest files until the cache size is under a certain limit, as you suggested). Cheers, Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: how to use the cache-to-disk feature in Wallpaper
oops, sent too fast. sorry for the spam. It remains that my way of triggering save() was kquitapp plasma. So in every case, my problem arises when Mandelbrot is about to be destroyed. 2009/4/13 Benoit Jacob jacob.benoi...@gmail.com: By the way the committed code does this from save(), not from the destructor, so this wasn't where to look for an explanation. Cheers, Benoit 2009/4/13 Benoit Jacob jacob.benoi...@gmail.com: this is now committed, as a testcase... Example of console output: plasma-desktop(7077) Mandelbrot::updateCache: remove mandelbrot-157422800 Corresponding to this code: // remove old image from cache kDebug() remove m_cacheKey; insertIntoCache(m_cacheKey, QImage()); Yet the file still exists: bja...@kiwi:~/.kde/cache-kiwi/plasma-wallpapers ls home mandelbrot-157422800.png mandelbrot-72259600.png usr Cheers, Benoit 2009/4/13 Benoit Jacob jacob.benoi...@gmail.com: I have a problem, I wonder if I'm hitting a bug. It seems as if insertIntoCache(key, QImage()) does not do anything when it is called from ~Mandelbrot(). The expected behavior was to remove the image corresponding to 'key' from the cache. I have really checked that the key is correct and that isUsingDiskCache() returns true. Looking at the source code in wallpaper.cpp, I can't see anything else to check... When I used to call insertIntoCache(key, QImage()) from a slot connected to a QTimer, it did work. So there seems to be something specific to calling it from the destructor. Cheers, Benoit 2009/4/12 Benoit Jacob jacob.benoi...@gmail.com: 2009/4/12 Aaron J. Seigo ase...@kde.org: if you have 3 containments with the same image as the wallpaper, it shouldn't create three cache files on disk. so there is no real mapping from cache file to containment; there is a mapping of sorts between wallpaper plugins and the cache file they are using ... ah, right, i hadn't thought of this. For the rest, I agree, and I don't see any good solution... The main reason for stale cached images will probably be if plasma crashes (which is bound to happen as any binary plugin may crash plasma). Maybe then one could say that, when plasma starts for the first time after a crash, it prunes its cache (like removing the oldest files until the cache size is under a certain limit, as you suggested). Cheers, Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: how to use the cache-to-disk feature in Wallpaper
2009/4/13 Aaron J. Seigo ase...@kde.org: On Monday 13 April 2009, Benoit Jacob wrote: // remove old image from cache kDebug() remove m_cacheKey; insertIntoCache(m_cacheKey, QImage()); fixed in svn; what was happening was that a kio job was being created while the app was being destroyed ... so it would never hit the event loop (no longer exists) and therefore never auto-start the job. this was causing console output like: A KUiServerJobTracker instance contains 1 stalled jobs so now i just exec the job. p.s. plasmawallpaperviewer now calls save() on app exit. Cool, thanks ! Btw, plasmawallpaperviewer has been very useful for valgrinding my wallpaper. I could never valgrind plasma-desktop as it's far too heavy. Cheers, Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
KDEReview for Mandelbrot Wallpaper Plugin
Hi, The Mandelbrot wallpaper plugin is now in KDEReview, at this address: /trunk/kdereview/plasma/wallpapers/mandelbrot/ * Basic facts: * 844 lines of code (according to sloccount) Stripped executable size: 68 kB. Nontrivial dependencies: Eigen = 2.0 (in kdesupport). Should be completely portable. * Description: * Allows to navigate through the Mandelbrot set, http://en.wikipedia.org/wiki/Mandelbrot_set To enable: go to the Desktop Settings dialog, then in Wallpaper, in the Type combo-box, choose Mandelbrot. Use the Lock view checkbox to let it behave like a plain wallpaper. Features: * non-blocking rendering (in separate threads) * uses as many threads as you have CPU cores (Qt's idealThreadCount) * uses SSE2 or AltiVec if available (through the Eigen library) with graceful fallback if none available * on x86, both paths (with and without SSE2) are compiled and a runtime test using the Solid library determines if SSE2 is available * immediate previews based on previous image * tile-based rendering starting from the tile you're most interested in * supersampling up to 16x * caching of rendered image using Plasma::Wallpaper's functionality * color gradients based on HSV color mixing Cheers, Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: how to use the cache-to-disk feature in Wallpaper
2009/4/10 Aaron J. Seigo ase...@kde.org: papers (maybe i should add that bookkeeping into Wallpaper itself? H.. yes, probably... let me get back to you on that one, he says, again.) ok: caching is now implemented in Mandelbrot (r952792). Here's again a somewhat lengthy email but you can skip to (***). I think i now have a clearer idea of what part of the bookkeeping needs to be done in Plasma::Wallpaper and what can be done in Mandelbrot. The bookkeeping that Mandelbrot itself does is whenever you insert a new image into the cache, remove the previous image. With this simple bookkeeping, stale cached images are inevitable when: 1) plasma crashes after caching the image and before saving the viewpoint. 2) the user is bored of mandelbrot and chooses another wallpaper instead: then the cached images stay. There is also a 3rd circumstance but for that one i've got an ugly workaround: 3) When we open Desktop Settings, the mini monitor may show a different viewpoint than the previous time (if the user moved the view in between). So the previous cached image stays. The ugly workaround for 3) was to only cache images that have 10 pixels... Anyway, here's a proposal: (***) Plasma::Wallpaper should remember for each cached image it's context: that is (i guess), which containment it belongs to. That could be either stored in the filename, or by storing in different sub-directories. Periodically, Plasma should then erase all but the most recent image for each containment, or at least offer an API to let the wallpaper do so (erase all my images except for this list of keys that should be kept). That also suggests that plasma should remember also which wallpaper plugin an image belongs to -- currently i put mandelbrot in the key but Plasma could do it for me. Cheers, Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: how to use the cache-to-disk feature in Wallpaper
2009/4/12 Aaron J. Seigo ase...@kde.org: if you have 3 containments with the same image as the wallpaper, it shouldn't create three cache files on disk. so there is no real mapping from cache file to containment; there is a mapping of sorts between wallpaper plugins and the cache file they are using ... ah, right, i hadn't thought of this. For the rest, I agree, and I don't see any good solution... The main reason for stale cached images will probably be if plasma crashes (which is bound to happen as any binary plugin may crash plasma). Maybe then one could say that, when plasma starts for the first time after a crash, it prunes its cache (like removing the oldest files until the cache size is under a certain limit, as you suggested). Cheers, Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: how to use the cache-to-disk feature in Wallpaper
I have a problem, I wonder if I'm hitting a bug. It seems as if insertIntoCache(key, QImage()) does not do anything when it is called from ~Mandelbrot(). The expected behavior was to remove the image corresponding to 'key' from the cache. I have really checked that the key is correct and that isUsingDiskCache() returns true. Looking at the source code in wallpaper.cpp, I can't see anything else to check... When I used to call insertIntoCache(key, QImage()) from a slot connected to a QTimer, it did work. So there seems to be something specific to calling it from the destructor. Cheers, Benoit 2009/4/12 Benoit Jacob jacob.benoi...@gmail.com: 2009/4/12 Aaron J. Seigo ase...@kde.org: if you have 3 containments with the same image as the wallpaper, it shouldn't create three cache files on disk. so there is no real mapping from cache file to containment; there is a mapping of sorts between wallpaper plugins and the cache file they are using ... ah, right, i hadn't thought of this. For the rest, I agree, and I don't see any good solution... The main reason for stale cached images will probably be if plasma crashes (which is bound to happen as any binary plugin may crash plasma). Maybe then one could say that, when plasma starts for the first time after a crash, it prunes its cache (like removing the oldest files until the cache size is under a certain limit, as you suggested). Cheers, Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Mandelbrot progress, need Qt GUI help!
2009/4/10 Aaron J. Seigo ase...@kde.org: it's because you didn't put a layout in the widget itself. to do so in designer: * click on the background * select a layout from the toolbar this is equivalent to: QWidget *topLevelWidget = new QWidget(this); QGridLayout *layout = new QGridLayout(topLevelWidget); // or whatever kind of layout you want layout-addWidget(..); i've modified and committed your .ui file so that it fits the PIG (plasma interface guidelines).. enjoy :) Thanks a lot! I allowed myself to remove the horiz spacer to the right of the KComboBox, letting it be horizontally expanded. Indeed (also to answer Andrew's question) my motivation was that the last items in this combo box could fail to fit in the given space, when i18n'ed. One question -- you made the ColorButtons be both horizontally and vertically expandable, is that wanted? looking at other wallpapers, this isn't how they do (though i have packages from a few days ago). Cheers, Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Usability questions for Mandelbrot
2009/4/10 Aaron J. Seigo ase...@kde.org:
On Thursday 09 April 2009, Benoit Jacob wrote:
2009/4/9 Aaron J. Seigo ase...@kde.org:
QCursor::setCursor?
ah, thanks!
i wonder if the hoverOut events are accurate enough for that though..
hm..
i can't seem to find any hoverEvents in the Wallpaper class. Anyway if
it's nontrivial then better just leave the default mouse pointer!
try it; it _should_ just work. if it doesn't, let me know. ;)
OK, here's where I'm stuck:
1) There doesn't seem to be a QCursor::setCursor(). There is a
setCursor method in QWidget and in QApplication; how can i leverage
either?
2) There are no hoverEnterEvent and hoverLeaveEvent methods in
Wallpaper. So I tried reimplementing QObject::event() but it doesn't
seem to ever get called: the following gives nothing, not even the
mouse events that are well handled:
bool Mandelbrot::event(QEvent *e)
{
kDebug() event e-type();
return Plasma::Wallpaper::event(e);
}
Cheers,
Benoit
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
how to use the cache-to-disk feature in Wallpaper
Hi, I think Mandelbrot is a good candidate for cache-to-disk, however, how do i enable this feature? I did setUsingDiskCache(true); in the constructor, and I emit renderCompleted once my image has finished rendering, but that doesn't make any difference. Thanks, Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Usability questions for Mandelbrot
2009/4/10 Aaron J. Seigo ase...@kde.org: On Friday 10 April 2009, Benoit Jacob wrote: 2) There are no hoverEnterEvent and hoverLeaveEvent methods in Wallpaper. So I tried reimplementing QObject::event() but it doesn't seem to ever get called: the following gives nothing, not even the mouse events that are well handled: yes, i think you can only do it on mouse press/release atm. wallpaper don't support hover effects, which may have been a real oversight when we were designing them. unfortunately adding new virtuals isn't possible, though if hover really becomes an issue would could introduce a new WallaperV2 sort of class that does this... OK. Well, to make it clear, i think that the present use case is NOT important enough to justfy doing that, as it's no big deal (and possibly even better) to stick with the default mouse pointer here. Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Mandelbrot progress, need Qt GUI help!
2009/4/10 Aaron J. Seigo ase...@kde.org: On Friday 10 April 2009, Benoit Jacob wrote: I allowed myself to remove the horiz spacer to the right of the KComboBox, letting it be horizontally expanded. Indeed (also to answer Andrew's question) my motivation was that the last items in this combo box could fail to fit in the given space, when i18n'ed. you actually don't need to do this. the spacer will give way to the combobox as the combobox's contents grow (e.g. due to a longer i18n'd string) aaah, ok that makes sense now. Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: how to use the cache-to-disk feature in Wallpaper
2009/4/10 Aaron J. Seigo ase...@kde.org: On Friday 10 April 2009, Benoit Jacob wrote: I did setUsingDiskCache(true); in the constructor, and I emit when you are ready to cache the image, you can now call: insertIntoCache(const QString key, const QImage image); and if you want to see if it exists and retrieve it call: bool findInCache(const QString key, QImage image, unsigned int lastModified = 0) with the same key. so in your case, you may want to include things like the the view point and zoom level in the key. Thanks! I see. also, i'd suggest: * deleting the old image so the user doesn't end up with a bajillion cached papers (maybe i should add that bookkeeping into Wallpaper itself? H.. yes, probably... let me get back to you on that one, he says, again.) Maybe I don't understand, but I think that the Wallpaper class doesn't seem to have enough information to do the bookkeeping. Here's an example: the user has 2 different Mandelbrot's in 2 desktops. The expected behavior is to keep the most recent cached image for each Mandelbrot. I don't see how to make that automatically handled in Wallpaper? So unless you can figure a way to make that work magically, I'd suggest either void removeFromCache(const QString key); or changing insertIntoCache as follows: void insertIntoCache(const QString key, const QImage image, const QString oldkey); where the cache entry corresponding to oldkey is automatically removed from cache (one may then pass an empty string -- perhaps that'd be the default value -- if one doesn't want to remove anything). Cheers, Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Mandelbrot progress, need Qt GUI help!
Hi, one more GUI question please! When I resize the Desktop Settings dialog horizontally, I'd expect the Mandelbrot controls to resize automatically to use the extra space. That's what happens with the Pattern wallpaper's controls. But I can't seem to obtain this behavior. I tried to mimic Pattern everywhere I could see, like setting the sizes to MinimumExpanding, but still no luck... any ideas? Thanks, Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Usability questions for Mandelbrot
2009/4/9 Sebastian Kügler se...@kde.org: Make the mouse pointer a hand only when the left button is pressed, this way you get visual feedback without the distraction of the always hand. OK, the next question is: how do you change the mouse cursor from a Plasma wallpaper? Normally i'd call setCursor() but there doesn't seem to be any such method around in this context ? Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Mandelbrot, continued (and plasma bug reports)
Hi, First of all, many thanks to Aaron and Andrew for your help. SVN now has an updated version taking it into account. Finally, I found that what I really need is to be able to distinguish between the main instance of the wallpaper, that is the one that is actually used as desktop background, and the other instance of the wallpaper, that is the one that is displayed in the tiny screen in the Desktop Settings dialog. I didn't find anything like a bool isMainInstance() method so I hacked one that just returns true if the number of pixels is 20. Very hackish, but works for me. Could you please tell me how to do that cleanly, or add such a method in the Wallpaper class? The reason why I need it, is that the 2 instances modify different settings: the main instance controls the viewpoint while the other instance controls other parameters. So in the save() method I need to know which instance it is. While I'm here, here are a few possible bug reports. 1) the isInitialized() method seems to always return true. 2) In Desktop Settings dialog, the Apply button is disabled even after i have modified Mandelbrot settings 3) In Desktop Settings dialog, the mandelbrot preview is misplaced slightly to the top-left, so there are black bands on the bottom and right. Cheers, Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Usability questions for Mandelbrot
Hi, I have a couple usability questions. The Mandelbrot wallpaper has 2 modes: locked and unlocked. In locked mode, it behaves like an ordinary wallpaper. In unlocked mode, the view can be moved by mouse dd and mouse wheel. Question 1. In locked mode, should mouse wheel do nothing? Or should it have the default effect which is, cycle through virtual desktops? Argument in favor of doing nothing: prevents unwanted desktop cycling if the user forgot that he had locked Mandelbrot. Argument in favor of cycling through desktops: user might like this feature, and that is also the behavior with ordinary wallpapers. Question 2. In unlocked mode, should the mouse pointer become a little hand (or something like that) to indicate that the view can be dragged? Or should we keep the default pointer? Argument in favor of default pointer: it might be annoying to see that little hand most of the time, since we're talking about a large prominent element of the desktop. Argument in favor of special pointer (like a hand): gives a clue that dragging is possible (though it doesn't give a clue that zooming is also possible). Cheers, Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Usability questions for Mandelbrot
2009/4/8 Aaron J. Seigo ase...@kde.org: On Wednesday 08 April 2009, Benoit Jacob wrote: In locked mode, should mouse wheel do nothing? Or should it have the default effect which is, cycle through virtual desktops? if the mouse event is not used by the wallpaper, you should not call accepted() on the event. this lets it pass through and the widget/containment using the wallpaper can then do whatever it wants with it. OK, that's the current behavior. In unlocked mode, should the mouse pointer become a little hand (or something like that) to indicate that the view can be dragged? Or should we keep the default pointer? sounds like we have a documentation problem, and that we should have a way to tell the user what they can do with a particular wallpaper. this probably makes the most sense in the configuration? perhaps this could go into the .desktop file as part of the Comment= and it could be harvested from there and shown in the UI. OK, I leave the default pointer and i agree it's a documentation issue. I'd welcome any way to include a bit of documentation in the UI. I guess that theoretically that's what KHelpCenter is for, but as a KDE user I've developed a reflex of closing the KHelpCenter window as soon as it appears (because it's long to start and its docs are often outdated). Cheers, Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Mandelbrot, continued (and plasma bug reports)
2009/4/8 Aaron J. Seigo ase...@kde.org: On Wednesday 08 April 2009, Benoit Jacob wrote: (**) Ideally, the main Mandelbrot instance should save its config before the Desktop Settings embedded instance reads the config. Is that possible? this is now done in svn .. the wallpaper doesn't need to care about it. Wonderful ! Thanks, Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Usability questions for Mandelbrot
2009/4/9 Sebastian Kügler se...@kde.org: Make the mouse pointer a hand only when the left button is pressed, this way you get visual feedback without the distraction of the always hand. good idea! Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Mandelbrot ready for review, config bugs
Hi, Mandelbrot (playground/base/plasma/wallpapers/mandelbrot) is ready for review! However before moving it to kdereview let's discuss the following bug as I don't know if it is in my code or in libplasma. The bug is that the config isn't saved when it should, so is often lost: 1) when changing the mandelbrot settings in Desktop Settings, the setting in question is well updated, but the rest of the config is lost (i.e. the viewpoint is reinitialised) 2) when doing kquitapp plasma_desktop the config is also lost. I have implemented Mandelbrot::save(). Looking at the Pattern wallpaper, it looks like that's all I have to do? at least, Pattern seems to only implement save() and doesn't seem to ever call save() manually. Cheers, Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Mandelbrot progress, need Qt GUI help!
2009/4/8 Andrew Stromme astro...@chatonka.com: It would be nice to have more descriptive names than Color 1, Color 2 etc.. for the color selection. Maybe something like Inside Color, Outline Color, Fringe Color or Main Color, Secondary Color, etc... would be more self-explanatory? Good idea. I have just a question which I'm afraid will reveal how much of an ignorant I am when it comes to GUI. I am afraid that these i18n'ed strings might become too long in certain languages to fit in the given horizontal space in the dialog. Or would it be automatically resized then? Do i need to do anything specific in Designer to let that happen? I assume Fineness means Level of Detail or Graphics Quality? Would one of those be more descriptive to the user? OK. It means technically the number of iterations. So i guess that level of detail is ok. Lastly, and in the same vein, Lock could be something like Allow Panning/Zooming with mouse (of course then it would probably be checked by default) or Lock Current View. I like lock current view. Also, what would be cool is if enabling/disabling the lock didn't reset the view as well, That's of course the goal, and what you're discussing here is the bug that i mention in the other thread (solved in my local copy). Of course these are all just suggestions, and relatively minor :). Thanks, it's always useful to have input from a native english speaker! Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Mandelbrot progress, need Qt GUI help!
Hi, The mandelbrot wallpaper plugin is almost ready (in playground/base/plasma/wallpapers/mandelbrot). However I am a complete GUI n00b and I need some very basic help so I hope that someone here can help me. Initially, the configuration GUI had only one KColorButton. Now I want 3 KColorButtons. So I edited the config.ui file with Designer and updated my source code, and it compiles and even runs, but... now, when I go in desktop settings, the mandelbrot settings are empty! no KColorButton shows up. Probably I made a classical mistake? I committed this in the hope that someone can help. Also, I made various attempts with spacers and layouts but no luck, so the current version has neither. Cheers, Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: playground plasmoid redux
2008/10/3, Aaron J. Seigo [EMAIL PROTECTED]: hrm; not to my knowledge but i could be wrong. what's the crash you get? Attached is the backtrace. It occurs only on plasma startup i.e. if you select Mandelbrot it works fine for the duration of your session but on next login it crashes. I assume it's my own Mandelbrot's fault but I can't see why it crashes, except if waiting for a waiting thread is illegal. I don't want to make you lose time btw :) Cheers, Benoit plasma.kcrash Description: Binary data ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: playground plasmoid redux
Another possibility: is it illegal to wait for a QThread that was just constructed but not yet started? I.e. thread = new MyThreadClass(); wait(thread); OK, i don't distract this thread (no pun intended) more with offtopic questions. Cheers, Benoit 2008/10/3, Benoit Jacob [EMAIL PROTECTED]: 2008/10/3, Aaron J. Seigo [EMAIL PROTECTED]: hrm; not to my knowledge but i could be wrong. what's the crash you get? Attached is the backtrace. It occurs only on plasma startup i.e. if you select Mandelbrot it works fine for the duration of your session but on next login it crashes. I assume it's my own Mandelbrot's fault but I can't see why it crashes, except if waiting for a waiting thread is illegal. I don't want to make you lose time btw :) Cheers, Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: playground plasmoid redux
Yes sure that's what I mean :) OK, I forget about this documentation bit, thank you. Cheers, Benoit 2008/10/3, Jason Stubbs [EMAIL PROTECTED]: wait(thread)? wait()'s parameter is an integer timeout... If you mean thread-wait(), the documentation says it returns true if the thread has not been started yet. ie, it doesn't wait at all. -- Jason Stubbs ___ 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 : Re : New Mandelbrot wallpaper in playground, triggers some bugs
I definitely plan to do so for 4.2 but there are a couple more things that I want to sort out before. Cheers, Benoit 2008/9/8, Aaron J. Seigo [EMAIL PROTECTED]: On Monday 08 September 2008, Benoit Jacob wrote: letting you know that the embargo on screenshots is lifted :) ;) even more exciting will be when you suggest it's ready for kdereview so we can move it into kdeplasma-addons =) i found a nice formula for the gradient, pretty happy about it :) cool... -- 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 Trolltech ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New Mandelbrot wallpaper in playground, triggers some bugs
just one more note: i'm going to implement the smooth gradient algo, so please nobody blog about this wallpaper until i've done it, currently it doesn't look too good. 2008/9/6 Benoit Jacob [EMAIL PROTECTED]: ok should be fixed in 857678. Cheers, Benoit PS. Now using intel graphics (yes i got one of these sony sz2 with dual intel/nvidia), no rendering glitches. 2008/9/6 Benoit Jacob [EMAIL PROTECTED]: aaah got it :) when changing a setting, init() was called, reallocating the QImage that was being painted in paralled by the renderer threads... solution was to add a renderThreads[0]-wait() in Mandelbrot::init()... indeed the 0-th thread is the master-thread, it controls the others if any. Cheers, Benoit 2008/9/6 Benoit Jacob [EMAIL PROTECTED]: Indeed, i can reproduce that. How do I get a backtrace? The kcrash dialog just disappears when i ask for the backtrace, and when i run plasma in gdb, after the crash it just says no stack. 2008/9/6 Aaron J. Seigo [EMAIL PROTECTED]: On Friday 05 September 2008, Benoit Jacob wrote: I updated to 177.70. With desktop effects enabled, the glitches are as bad as before. With desktop effects disabled, the situation has improved but there remain some glitches. not related, but i just discovered that changing the settings while the fractal is still rendering on the desktop results in a crash in a thread in the renderer.. -- 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 Trolltech ___ 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: New Mandelbrot wallpaper in playground, triggers some bugs
Thanks for looking into it, but now when i change the color and apply or ok the change is not applied, the old color is still used. I did svn up in trunk/kdebase/workspace, anything else I should do ? Benoit 2008/9/5 Aaron J. Seigo [EMAIL PROTECTED]: On Friday 05 September 2008, Benoit Jacob wrote: Another thing that also looks like a bug: if you go to desktop effects and change the color, apply, then the viewpoint gets reset. I checked, the view parameters (m_center and m_zoom) are already reset when the setColor() slot is called. i think i just fixed this problem =) -- 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 Trolltech ___ 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: New Mandelbrot wallpaper in playground, triggers some bugs
I just tried the vesa driver instead of nvidia: it works fine. So this is a nvidia driver issue, sorry for the noise. I haven't yet tried the newer drivers, I was planning to wait until they are released. Cheers, Benoit 2008/9/5 Sebastian Kügler [EMAIL PROTECTED]: On Friday 05 September 2008 16:32:02 Benoit Jacob wrote: Here are the steps to reproduce: -set mandelbrot as your wallpaper -minimize all windows, close plasma toolboxes (e.g. the panel toolbox) -navigate through the wallpaper (e.g. mouse wheel) I still have the glitches with latest trunk; also, if i enable desktop effects I get glitches also in the dashboard (while without desktop effects the dashboard view is oK). This is with proprietary nvidia driver 169.12. Can you check if it's fixed with their newest beta drivers? I've had some garbage on screen before, those drivers improve it ... -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ 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: New Mandelbrot wallpaper in playground, triggers some bugs
Indeed, i can reproduce that. How do I get a backtrace? The kcrash dialog just disappears when i ask for the backtrace, and when i run plasma in gdb, after the crash it just says no stack. 2008/9/6 Aaron J. Seigo [EMAIL PROTECTED]: On Friday 05 September 2008, Benoit Jacob wrote: I updated to 177.70. With desktop effects enabled, the glitches are as bad as before. With desktop effects disabled, the situation has improved but there remain some glitches. not related, but i just discovered that changing the settings while the fractal is still rendering on the desktop results in a crash in a thread in the renderer.. -- 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 Trolltech ___ 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: New Mandelbrot wallpaper in playground, triggers some bugs
aaah got it :) when changing a setting, init() was called, reallocating the QImage that was being painted in paralled by the renderer threads... solution was to add a renderThreads[0]-wait() in Mandelbrot::init()... indeed the 0-th thread is the master-thread, it controls the others if any. Cheers, Benoit 2008/9/6 Benoit Jacob [EMAIL PROTECTED]: Indeed, i can reproduce that. How do I get a backtrace? The kcrash dialog just disappears when i ask for the backtrace, and when i run plasma in gdb, after the crash it just says no stack. 2008/9/6 Aaron J. Seigo [EMAIL PROTECTED]: On Friday 05 September 2008, Benoit Jacob wrote: I updated to 177.70. With desktop effects enabled, the glitches are as bad as before. With desktop effects disabled, the situation has improved but there remain some glitches. not related, but i just discovered that changing the settings while the fractal is still rendering on the desktop results in a crash in a thread in the renderer.. -- 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 Trolltech ___ 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
[PATCH] pass mouse wheel events to the wallpaper
Hi, The attached patch makes Containment forward mouse wheel events first to the wallpaper, if the event screenPos() indicates that the mouse cursor was on the wallpaper. I adapted this code from what you were already doing with mouseMoveEvent(). If the wallpaper doesn't accept the wheel event, it gets propagated as before. Please, review this short patch and tell me if I may commit. Cheers, Benoit diff Description: Binary data ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PATCH] pass mouse wheel events to the wallpaper
OK, committed in 857101.
Benoit
2008/9/4 Aaron J. Seigo [EMAIL PROTECTED]:
On Thursday 04 September 2008, Benoit Jacob wrote:
Hi,
The attached patch makes Containment forward mouse wheel events first
to the wallpaper, if the event screenPos() indicates that the mouse
cursor was on the wallpaper. I adapted this code from what you were
already doing with mouseMoveEvent().
cool ... two points:
you need to re-accept the the event if the wallpaper ignores it; so this:
if(event-isAccepted()) return;
should be:
if (event-isAccepted()) {
return;
}
event-accept();
}
the second point is that the whitespace usage around the if statement is
incorrectin your patch (and fixed in the example above)
otherwise .. beauty =) please commit.
--
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 Trolltech
___
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
New Mandelbrot wallpaper in playground, triggers some bugs
Hi, I just committed an initial version of my Mandelbrot wallpaper plugin (only 360 LOC) there: /trunk/playground/base/plasma/wallpapers/ commit message: http://websvn.kde.org/trunk/playground/base/plasma/wallpapers/?view=logpathrev=857241 You'll need a recent checkout of /trunk/kdesupport/eigen2. For now, a SSE2 CPU is required, but that requirement will quickly go away. I'd like to point out that it seems to trigger a few plasma bugs -- although of course it might just be me misusing libplasma. 1) In the Ctrl+F12 dashboard view it renders fine without glitches. But outside of dashboard, on the actual desktop, there are huge repaint glitches (many damaged areas). Perhaps I should add that I have desktop effects disabled. But 2) In the desktop settings dialog, the little preview isn't getting mouse events. Cheers, Benoit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New Mandelbrot wallpaper in playground, triggers some bugs
2008/9/5 Aaron J. Seigo [EMAIL PROTECTED]: woo hoo! the best part of this is that you manage to find all the annoying little bugs that hadn't been rooted out yet. thanks for that alone! You're welcome... thanks for making this framework in the first place :) 2) In the desktop settings dialog, the little preview isn't getting mouse events. to be expected: we don't pass them on (it's not being drawn in a containment, but in a regular QWidget) ... do we really need (or want?) mouse interaction there? If it's only a few lines of code, and if it does not cause any kind of trouble, then I'd say yes: it's a nice toy, and allows the user to evaluate the plugin before switching his desktop to it. Benoit P.S. I checked the size of the .so when compiled without debug info, to get an idea of memory usage: 44K. Then essentially the only data is the image itself, so, this live-wallpaper essentially doesn't consume more memory than a plain wallpaper. Unless you added subtlety to not always keep whole wallpaper images in memory, I haven't checked :) In fact i could still reduce memory usage by x4 by storing a 1-channel image (since the gradient is monochrome) but then i don't know if Qt makes that easy to draw. -- 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 Trolltech ___ 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
Plasma wallpaper painting inconsistency
Hi,
I noticed an inconsistency in the way plasma wallpapers are painted, between
when it is painted as background of the screen and when it is painted in the
little preview in the Desktop Settings dialog.
Here is my paint() function. Mandelbrot is a subclass of Wallpaper.
void Mandelbrot::paint(QPainter *painter, const QRectF exposedRect)
{
if(!m_tile.final()) {
QRect destination = m_tile.destination();
kDebug() recompute destination;
mandelbrot_render_with_vectorizationfloat(m_tile_image, m_color,
m_tile, 1, 0);
QPainter(m_image).drawImage(destination, *m_tile_image);
painter-drawImage(destination, *m_image, destination);
m_tile.next();
emit update(m_tile.destination());
}
kDebug() repaint exposedRect;
painter-drawImage(exposedRect, *m_image, exposedRect);
}
Here is the console output when the wallpaper is painted as the background
of the screen:
.
plasma(11356) Mandelbrot::paint: recompute QRect(640,700 160x100)
plasma(11356) Mandelbrot::paint: repaint QRectF(0,0 1280x800)
plasma(11356) Mandelbrot::paint: recompute QRect(480,700 160x100)
plasma(11356) Mandelbrot::paint: repaint QRectF(0,0 1280x800)
plasma(11356) Mandelbrot::paint: recompute QRect(320,700 160x100)
plasma(11356) Mandelbrot::paint: repaint QRectF(0,0 1280x800)
plasma(11356) Mandelbrot::paint: recompute QRect(160,700 160x100)
plasma(11356) Mandelbrot::paint: repaint QRectF(0,0 1280x800)
.
See, the paint() function is always called with exposedRect equal to the
whole screed, regardless of the parameter passed to update().
Now here is the console output when I open the Desktop Settings dialog and
it shows the little preview:
..
plasma(11356) Mandelbrot::paint: recompute QRect(102,90 20x12)
plasma(11356) Mandelbrot::paint: repaint QRectF(102,90 20x12)
plasma(11356) Mandelbrot::paint: recompute QRect(82,90 20x12)
plasma(11356) Mandelbrot::paint: repaint QRectF(82,90 20x12)
plasma(11356) Mandelbrot::paint: recompute QRect(61,90 20x12)
plasma(11356) Mandelbrot::paint: repaint QRectF(61,90 20x12)
plasma(11356) Mandelbrot::paint: recompute QRect(41,90 20x12)
plasma(11356) Mandelbrot::paint: repaint QRectF(41,90 20x12)
plasma(11356) Mandelbrot::paint: recompute QRect(20,90 20x12)
plasma(11356) Mandelbrot::paint: repaint QRectF(20,90 20x12)
.
See, this time the paint() function is called with exactly the rectangle
that was passed to update().
So:
1) is this inconsistency (difference between preview and actual wallpaper
rendering) justified or a bug?
2) currently the preview has visual artifacts while the actual wallpaper
rendering is OK. But the actual wallpaper rendering, repainting the whole
screen background everytime a tile is updated, is slow. Isn't there a way to
repaint only the updated tile, without having visual artifacts?
Cheers,
Benoit
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma wallpaper painting inconsistency
Yes, seems fixed. More specifically the debug output now is: . plasma(8143) Mandelbrot::paint: recompute QRect(640,0 160x100) plasma(8143) Mandelbrot::paint: repaint QRectF(637,0 166x103) plasma(8143) Mandelbrot::paint: recompute QRect(800,0 160x100) plasma(8143) Mandelbrot::paint: repaint QRectF(797,0 166x103) plasma(8143) Mandelbrot::paint: recompute QRect(960,0 160x100) plasma(8143) Mandelbrot::paint: repaint QRectF(957,0 166x103) plasma(8143) Mandelbrot::paint: recompute QRect(1120,0 160x100) plasma(8143) Mandelbrot::paint: repaint QRectF(1117,0 163x103) plasma(8143) Mandelbrot::paint: recompute QRect(1120,100 160x100) plasma(8143) Mandelbrot::paint: repaint QRectF(1117,97 163x106) plasma(8143) Mandelbrot::paint: recompute QRect(1120,200 160x100) plasma(8143) Mandelbrot::paint: repaint QRectF(1117,197 163x106) plasma(8143) Mandelbrot::paint: recompute QRect(1120,300 160x100) plasma(8143) Mandelbrot::paint: repaint QRectF(1117,297 163x106) . So the actually repainted rect is only slightly larger than what is being asked for. A margin of 3 or 6 pixels seems to still be added. Normal behavior? There still are repainting glitches, but it'll be time to discuss these when i'll have committed. Cheers, Benoit 2008/9/3 Aaron J. Seigo [EMAIL PROTECTED] On Tuesday 02 September 2008, Aaron J. Seigo wrote: On Tuesday 02 September 2008, Benoit Jacob wrote: See, the paint() function is always called with exposedRect equal to the whole screed, regardless of the parameter passed to update(). this is a bug in Applet::paint; not sure when it was introduced, but it's a pretty big fubar. =/ i'm working on fixing it right now... can you svn up and let me know if it's better now? =) -- 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 Trolltech ___ 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
