Re: [Kourse 3] Fixing krazy2 issues
Am 16. Januar 2009 00:21 schrieb Aaron J. Seigo ase...@kde.org: On Thursday 15 January 2009, Philipp Klaffert wrote: I've now swapped all the Strings with constants and so, just 3 objects an no more krazy complaining for at least these issues. great; ready to 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 Qt Software ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Thank you for commiting the patch!! -- Philipp Klaffert ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: FrameSvg corruption [a bit urgent]
On Friday 16 January 2009, Ivan Čukić wrote: because if it is found, then we don't want to re-look it up in the svg. no? But the problem is that it is not loaded from the cache properly, but exists in the file, and hasElement() returns false, because it thinks that the cache holds the element, and if it has it at all, it is corrupted. The /found/ variable refers to the fact that it is found in the cache, and not in the file. So, the hasElement() returns false although that element exist. As the documentation states for hasElement() @return true if the element is defined in the Svg, otherwise false Which doesn't describe its behavior. With the proposed change, it would. 1. Check cache, if we have valid cached element, then the element exists 2. If we don't have it in the cache, then we check the Svg directly problem is, asking for random non existent elements (thing that happens a lot because it's supposed to be very fast) won't get any speedups by the cache I hope I made it a bit more clear what is the problem. Cheers ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Applet Direction
On Thursday 15 January 2009, Aaron J. Seigo wrote: On Thursday 15 January 2009, Jud Craft wrote: I do really like the platform-independence and compilation-free packages! I had neglected those; that's awesome, so the picture is much less depressing than my post says. Plasma themes themselves are also independent, correct? (Assumption based on hearing efforts to port Plasma to Windows). correct. What would be fantastic if there was one integrated area in the Control Center for Plasma management. we were discussing this just last week, actually. there are a few things that probably belong in there: * theme choice * installed component management * per-virtual desktop views ... For example, Plasma theming and the main containment wouldn't be side-notes in the Desktop Background dialog. Right-clicking well, there actually isn't such a thing as the main containment per se; just the currently active one for a given view. i'm a little hesitant on providing access to configuration of that out of process because it means loading plugins from the same library in two different processes, making sure they are both using the same configuration file settings and then coordinating between them. what about giving a dbus interface for all of this, like background settings and use this for setting stuff from another process? (for background settings would also be needed a list of activities and have a dialog per-activity, dunno if it could be overkill as an ui) in part, this is a weakness of kconfig. in part, this is just about having settings where they are contextually appropriate. the shift in thinking required is that Activities are Contextual. for the other things, yes, a centralized place for those makes sense. Appearance on the desktop could bring up a hypothetical Plasma/Environment/whatever control dialog, which would have the different areas of a plasma desktop (Background, Theme, Containments, Activities, Plasmoids) grouped in a common area, defaulting to Background (since you did right-click on the Desktop background, after all). the plan for 4.3 is to combine the Activity's own config with the Appearance settings, and to move the Theme settings elsewhere. so.. we're on teh same general wave length i think. Another thing, besides reorganization of the plasma config options, would be unification of the KDE theme settings. KDE 3's theme management was also more of a side-note. this is a long term goal. i want to be fully confident that we have the individual pieces figure out first, though. Compare GNOME, where theme management is the de facto way to change the desktop appearance -- you have no choice but to work through a theme metaphor, and THEN change individual aspects (style, colors, etc). yes. different, both in what is good about it and what isn't good about it. certainly begs the question if we can do something better than either previous system =) A Plasma metatheme (that combines Wallpaper and colors with a plasma theme) that even possibly configures a Qt style theme would be even better -- it makes little sense to have two or three different places that must be traveled to in the Control Center to theme your desktop, and as long as each component is isolated from the other, it is difficult to provide a sense of cohesiveness -- a single place you can go to either choose a new theme, get new themes (a single place to get new themes -- not having to go different places for color schemes, Plasma themes, and wallpapers) or alter a component of the current theme. agreed. The Plasmoids panel then would have a similar feel: rather than a mere listbox of Add New Plasmoids, it would be a central area to download new plasmoids and add/remove them. But then I don't actually know of any analog of this in any other OS, so maybe that's overkill. google gadget, the iPhone, Windows 7 ... it's not that exotic =) Such a design could be much more usable than having to browse kde-look, but I don't mean to put down Get-Hot-New-Stuff: I just think that it needs to be a little more than just a web-downloaded list box of plasmoids. this is simply a presentation issue. it's not a limitation of GHNS or kde- look. that dialog could be completely redesigned. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: FrameSvg corruption [a bit urgent]
Question:
This is the current framesvg.cpp, the beginning of the updateSizes()
void FrameSvgPrivate::updateSizes()
{
FrameData *frame = frames[prefix];
Q_ASSERT(frame);
QSize s = q-size();
q-resize();
frame-cachedBackground = QPixmap();
frame-cachedMask = QRegion();
We first store the size into s, and then do a q-resize(). Why?
When those two lines switch places, so that s is the newest size, everything
is ok. (I'll keep testing whether it is just accident)
--
Sanity is the trademark of a weak mind.
-- Mark Harrold
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: FrameSvg corruption [a bit urgent]
On Friday 16 January 2009, Ivan Čukić wrote: When those two lines switch places, so that s is the newest size, everything is ok. (I'll keep testing whether it is just accident) This seems to have fixed the problem. No breakage in Lancelot anymore, and as far as I can tell, no breakage outside neither. (have restarted plasma ok, it's 3am here and maybe i'm missing it, but i think what would happen in that case is: * the svg will get resized to its natural size * it'll still get painted down to a smaller rect * that will scale the cached _pixmap_ rather than the svg avoiding scaled pixmaps are why we're using svgs. ;) i'm sure it looks ok superficially, but if you look closely i'll bt you see artifacts, depending on the sizes of the elements in the svg and the size of the elements being painted. Lancelot doesn't since I wouldn't want to initialize [for example] the disabled state of the buttons, and load the elements into cache, when I never use the disabled state (at least, not at the present moment). shouldn't need to. -- 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 Software 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: [Kourse 3] Fixing krazy2 issues
On Friday 16 January 2009, Philipp Klaffert wrote: Thank you for commiting the patch!! thanks for putting the effort into writing 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 Software 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: FrameSvg corruption [a bit urgent]
On Friday 16 January 2009, Ivan Čukić wrote:
Question:
This is the current framesvg.cpp, the beginning of the updateSizes()
void FrameSvgPrivate::updateSizes()
{
FrameData *frame = frames[prefix];
Q_ASSERT(frame);
QSize s = q-size();
q-resize();
frame-cachedBackground = QPixmap();
frame-cachedMask = QRegion();
We first store the size into s, and then do a q-resize(). Why?
When those two lines switch places, so that s is the newest size,
everything is ok. (I'll keep testing whether it is just accident)
to me the problem is still there
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: FrameSvg corruption [a bit urgent]
That is kill lancelot, delete cache, start lancelot? -- I am a spokesman for a better way of living Love is the word and it can be heard If you are young the message can be sung -- Deep Purple ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: FrameSvg corruption [a bit urgent]
The borders do have hint-stretch. i'm sure it looks ok superficially, but if you look closely i'll bt you see artifacts, depending on the sizes of the elements in the svg and the size of the elements being painted. Maybe I'm sleepy too, but I don't :) I've stretched a FloderView to my whole screen and set the Air theme since it has a nice gradient background... and it still is a valid background. I would guess (if we were scaling pixmaps) that an overly large gradient wouldn't look so good. Lancelot doesn't since I wouldn't want to initialize [for example] the disabled state of the buttons, and load the elements into cache, when I never use the disabled state (at least, not at the present moment). shouldn't need to. I agree. -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun -- The Pink Floyd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: FrameSvg corruption [a bit urgent]
On Friday 16 January 2009, Ivan Čukić wrote: That is kill lancelot, delete cache, start lancelot? yep :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: FrameSvg corruption [a bit urgent]
http://websvn.kde.org/?view=revrevision=905645 When I revert to 905644 (only svg.cpp and framesvg.cpp), it works ok... Marco, what about you? -- There is a better way of life and it's not so hard to find If you live and let the people in your world speak its mind -- Deep Purple ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: FrameSvg corruption [a bit urgent]
On Friday 16 January 2009, Ivan Čukić wrote: http://websvn.kde.org/?view=revrevision=905645 When I revert to 905644 (only svg.cpp and framesvg.cpp), it works ok... Marco, what about you? nope (yeah, deleted and restarted all had to be :/) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: FrameSvg corruption [a bit urgent]
nope (yeah, deleted and restarted all had to be :/) Bummer... I have absolutely no more ideas what is the problem here... Is it possible that the cache has problems when two different processes access the same cache or something like that? I'm asking because I've just cleared it, and started only Plasma with one Lancelot Part on it - thus making it the same process - it was drawn correctly, and then I started the menu... and it remained screwed. -- You know, there are many people in the country today who, through no fault of their own, are sane. Some of them were born sane. Some of them became sane later in their lives... -- Monty Python's Flying Circus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: FrameSvg corruption [a bit urgent]
On Friday 16 January 2009, Ivan Čukić wrote: nope (yeah, deleted and restarted all had to be :/) Bummer... I have absolutely no more ideas what is the problem here... Is it possible that the cache has problems when two different processes access the same cache or something like that? I'm asking because I've just cleared it, and started only Plasma with one Lancelot Part on it - thus making it the same process - it was drawn correctly, and then I started the menu... and it remained screwed. since it's reading and writing on the same config file could be some inconsistent behaviour... anyways was trying to debug what happened but i can't quite grasp the code in lancelot, i tried to comment all paintFrame calls (just 2 actually) and all the widgets still paints.. how does the thing work? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: FrameSvg corruption [a bit urgent]
since it's reading and writing on the same config file could be some inconsistent behaviour... anyways was trying to debug what happened but i can't quite grasp the code in lancelot, i tried to comment all paintFrame calls (just 2 actually) and all the widgets still paints.. how does the thing work? libs/lancelot/widgets/Widget.cpp Widget::paintBackground(QPainter * painter, const QString element) is the function that takes care of background painting - when you remove the paintFrame, Lancelot should become dark. Are you sure that you are running the newly compiled version? -- Sanity is the trademark of a weak mind. -- Mark Harrold ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Tokamak Meeting II
Hi Artur, hi all, Hey, I'm arriving at the same day/time! Maybe we are in the same flight from Lisbon to Porto ? (TP1952) indeed, same flight! we can meet at the boarding area around 7h30 am, we'll be arriving at 7:00 at Lisbon from Toulouse. - Nuno: I can talk 5 minutes if you schedule us 3 after 10h30 - 11h. Planned 5 minutes talk: Picture Frame applet: present and future - My objectives for the week-end: * picture frame applet perspectives (PoTD engine, metadata and Nepomuk integration, flipping animation, sharing config with Desktop settings, ...) * what containment for educational purposes? (started by Aaron blog) the Desktop itself and the plasmoids. * KDE community plasma integration (uploading of data from users which I am waiting for ages in particular!) Anne-Marie ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: FrameSvg corruption [a bit urgent]
On Friday 16 January 2009, Ivan Čukić wrote: nope (yeah, deleted and restarted all had to be :/) Bummer... I have absolutely no more ideas what is the problem here... Is it possible that the cache has problems when two different processes access the same cache or something like that? I'm asking because I've just cleared it, and started only Plasma with one Lancelot Part on it - thus making it the same process - it was drawn correctly, and then I started the menu... and it remained screwed. started the menu .. in plasmoidviewer or in the same plasma instance as lancelot part? if the latter, then there's only one process accessing that cache. -- 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 Software 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: FrameSvg corruption [a bit urgent]
started the menu .. in plasmoidviewer or in the same plasma instance as The [Lancelot] menu is a separate process (application), but uses the same cache as plasma. So the point was: - Lancelot Part which is being run under the Plasma's process behaved ok - Lancelot menu, which is a completely separate process from Plasma did not. The only thing that has anything to do with the plasma process, as far as the menu is concerned, is the applet that shows buttons that open the menu - the applet communicates with Lancelot (the menu/the application) via D-Bus. -- Sanity is the trademark of a weak mind. -- Mark Harrold ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Tokamak Meeting II
I am here, i don't know yest when i arrive but the 5th for sure. I have a talk that i want to give about some stuff coming from Qt Software. As soon as i have the date i will let you know. On Fri, Jan 16, 2009 at 3:03 PM, Anne-Marie Mahfouf annemarie.mahf...@free.fr wrote: Hi Artur, hi all, Hey, I'm arriving at the same day/time! Maybe we are in the same flight from Lisbon to Porto ? (TP1952) indeed, same flight! we can meet at the boarding area around 7h30 am, we'll be arriving at 7:00 at Lisbon from Toulouse. - Nuno: I can talk 5 minutes if you schedule us 3 after 10h30 - 11h. Planned 5 minutes talk: Picture Frame applet: present and future - My objectives for the week-end: * picture frame applet perspectives (PoTD engine, metadata and Nepomuk integration, flipping animation, sharing config with Desktop settings, ...) * what containment for educational purposes? (started by Aaron blog) the Desktop itself and the plasmoids. * KDE community plasma integration (uploading of data from users which I am waiting for ages in particular!) 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: FrameSvg corruption [a bit urgent]
On Friday 16 January 2009, Ivan Čukić wrote: nope (yeah, deleted and restarted all had to be :/) Bummer... I have absolutely no more ideas what is the problem here... Is it possible that the cache has problems when two different processes access the same cache or something like that? I'm asking because I've just cleared it, and started only Plasma with one Lancelot Part on it - thus making it the same process - it was drawn correctly, and then I started the menu... and it remained screwed. yes, killing the lancelot process and reverting that change makes the problem go away ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: FrameSvg corruption [a bit urgent]
On Friday 16 January 2009, Marco Martin wrote: On Friday 16 January 2009, Ivan Čukić wrote: nope (yeah, deleted and restarted all had to be :/) Bummer... I have absolutely no more ideas what is the problem here... Is it possible that the cache has problems when two different processes access the same cache or something like that? I'm asking because I've just cleared it, and started only Plasma with one Lancelot Part on it - thus making it the same process - it was drawn correctly, and then I started the menu... and it remained screwed. yes, killing the lancelot process and reverting that change makes the problem go away seems that printing size() as debug in updateSizes() both before and after resize() seems that sometimes resize() resizes to QSize(-1,-1) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: FrameSvg corruption [a bit urgent]
On Friday 16 January 2009, Marco Martin wrote:
On Friday 16 January 2009, Marco Martin wrote:
On Friday 16 January 2009, Ivan Čukić wrote:
nope
(yeah, deleted and restarted all had to be :/)
Bummer... I have absolutely no more ideas what is the problem here...
Is it possible that the cache has problems when two different processes
access the same cache or something like that? I'm asking because I've
just cleared it, and started only Plasma with one Lancelot Part on it -
thus making it the same process - it was drawn correctly, and then I
started the menu... and it remained screwed.
yes, killing the lancelot process and reverting that change makes the
problem go away
seems that printing size() as debug in updateSizes()
both before and after resize() seems that sometimes resize() resizes to
QSize(-1,-1)
oh, if a renderer is still not created resize() actually does resize to
QSize(), so do we need to always have one i this case?
i wonder how the performance impact would be, i.e. how many resize() there are
around that could actually not need to know the size...
Index: svg.cpp
===
--- svg.cpp (revision 910984)
+++ svg.cpp (working copy)
@@ -476,10 +476,11 @@
void Svg::resize()
{
QSizeF newSize;
-if (d-renderer) {
-newSize = d-renderer-defaultSize();
-}
+d-createRenderer();
+newSize = d-renderer-defaultSize();
+
+
if (qFuzzyCompare(newSize.width(), d-size.width())
qFuzzyCompare(newSize.height(), d-size.height())) {
return;
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Applet Direction
On Friday 16 January 2009, Aaron J. Seigo wrote: On Friday 16 January 2009, Marco Martin wrote: what about giving a dbus interface for all of this, like background settings and use this for setting stuff from another process? (for background settings would also be needed a list of activities and have a dialog per-activity, dunno if it could be overkill as an ui) two issues with this: 747 cockpits versus a drawer full of pens and paper. both have a lot of parts, but i'd only trust most people with one of them. ;) yeah, totally agree, was just throwing ideas around, but in general i would like to mantain the plasma configuration as ui-less as possible :D so there is kinda only the plasma theme selection that could make sense in something outside like systemsettings ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PATCH] fixing krazy2 issues in kdeplasma-addons
On Friday 16 January 2009, Philipp Klaffert wrote: Since I had some time I patched some of the minor krazy2 issues in kdeplasma-addons. Mostly the QLatin1String and double-quote issues. I attached the patch to this mail so feel free to look over it and if its Ok, please commit it since I am not able to do so... i'm really not so much a fan of the QLatin1String changes. in these particular cases, they don't result in any useful performance improvements and they aren't technically incorrect, but they do impact readability. the rest of the changes look ok, however. =) -- 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 Software 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: Plasma Applet Direction
On Friday 16 January 2009, Marco Martin wrote: so there is kinda only the plasma theme selection that could make sense in something outside like systemsettings hmm... let's brainstorm on this ... things that are global plasma settings: * Plasma theme * install/remove widgets * per-virtual-desktop views anything else? -- 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 Software 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: FrameSvg corruption [a bit urgent]
On Friday 16 January 2009, Marco Martin wrote: On Friday 16 January 2009, Marco Martin wrote: On Friday 16 January 2009, Marco Martin wrote: On Friday 16 January 2009, Ivan Čukić wrote: nope (yeah, deleted and restarted all had to be :/) Bummer... I have absolutely no more ideas what is the problem here... Is it possible that the cache has problems when two different processes access the same cache or something like that? I'm asking because I've just cleared it, and started only Plasma with one Lancelot Part on it - thus making it the same process - it was drawn correctly, and then I started the menu... and it remained screwed. yes, killing the lancelot process and reverting that change makes the problem go away seems that printing size() as debug in updateSizes() both before and after resize() seems that sometimes resize() resizes to QSize(-1,-1) oh, if a renderer is still not created resize() actually does resize to QSize(), so do we need to always have one i this case? i wonder how the performance impact would be, i.e. how many resize() there are around that could actually not need to know the size... this would result in a lot of svg rendering. the value ought to be cached and only used if not cached. -- 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 Software 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: FrameSvg corruption [a bit urgent]
that's an interesting and unorthodox approach. in any case, the things that do work just fine across processes are the pixmapcache. The reasons were: - lancelot can be used without plasma - lancelot doesn't crash plasma (the most important one :) ) - lancelot can be called by third party applets (for awn and what not) the thing that probably doesn't work so great is the config file that stores the prefixes, though in practice that shouldn't be a problem. we'll Just to mention, if you have missed it, notmart confirmed that all worked well before the change you have mentioned before (websvn.kde.org/?view=revrevision=905645) -- Money can't buy happiness, but neither can poverty. -- Leo Rosten ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PATCH] fixing krazy2 issues in kdeplasma-addons
Am 16. Januar 2009 16:54 schrieb Aaron J. Seigo ase...@kde.org:
On Friday 16 January 2009, Philipp Klaffert wrote:
Since I had some time I patched some of the minor krazy2 issues in
kdeplasma-addons. Mostly the QLatin1String and double-quote issues.
I attached the patch to this mail so feel free to look over it and if its
Ok, please commit it since I am not able to do so...
i'm really not so much a fan of the QLatin1String changes. in these
particular
cases, they don't result in any useful performance improvements and they
aren't technically incorrect, but they do impact readability. the rest of
the
changes look ok, however. =)
--
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 Software
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
After reading your mail and considering that you are absolutely right about
that I think I let krazy be crazy about these and focus on other issues.
---
Philipp Klaffert
Index: applets/luna/phases.cpp
===
--- applets/luna/phases.cpp (Revision 911885)
+++ applets/luna/phases.cpp (Arbeitskopie)
@@ -232,7 +232,7 @@
O = torad(O);
/* all those planetary arguments, too! */
- for (i=1; i=14; i++)
+ for (i=1; i=14; ++i)
A[i] = torad(A[i]);
/* ok, we have all the parameters, let's apply them to the JDE.
Index: libs/conversion/volume.cpp
===
--- libs/conversion/volume.cpp (Revision 911885)
+++ libs/conversion/volume.cpp (Arbeitskopie)
@@ -146,7 +146,7 @@
QString result = unit;
result.replace(/-3, \xb3);
result.replace(^3, \xb3);
-result.replace(3, \xb3);
+result.replace('3', \xb3);
return result;
}
Index: libs/conversion/area.cpp
===
--- libs/conversion/area.cpp (Revision 911885)
+++ libs/conversion/area.cpp (Arbeitskopie)
@@ -104,7 +104,7 @@
QString result = unit;
result.replace(/-2, \xb2);
result.replace(^2, \xb2);
-result.replace(2, \xb2);
+result.replace('2', \xb2);
return result;
}
Index: libs/conversion/value.cpp
===
--- libs/conversion/value.cpp (Revision 911885)
+++ libs/conversion/value.cpp (Arbeitskopie)
@@ -60,7 +60,7 @@
QString Value::toString() const
{
-return d-number.toString() + + d-unit;
+return d-number.toString() + ' ' + d-unit;
}
QVariant Value::number() const
Index: libs/conversion/unit.cpp
===
--- libs/conversion/unit.cpp (Revision 911885)
+++ libs/conversion/unit.cpp (Arbeitskopie)
@@ -31,4 +31,5 @@
}
-#include unit.moc
\ No newline at end of file
+#include unit.moc
+
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Also save extender item config when not detached, and save collapsed state.
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.vidsolbach.de/r/328/ --- Review request for Plasma. Summary --- Previously we've decided to, by default not make attached items in an extender permanent. This has the problem of the position not being saved on items that are not detached though. For applets like network manager, it would however be nice if the position of the different extender items is being saved. That way the user can order the items the way they like it. Since in for example libplasmaclock we check if the calendar already exists anyways (we don't want to duplicate the calendar just because it is detached), I don't think it's a very big problem if we change this behavior to always make extenderitems persistent (unless they have an autoExpireTimeout set). The only problem this gives is that jobs and notifications don't make sense to stay around after a reboot, cause they don't get an autoExpireTimout set while being displayed (they are just deleted when the notification is destroyed by knotification). This means if you reboot while a notification is being displayed, the notification will be shown after the reboot, which doesn't make sense. This will require a change to the systemtray to destroy all attached extender items in it's destructor which is fairly trivial. And I think most applets would want the plasma clock kind of behavior (always having a kind of fixed set of items being displayed), which would require them to check for duplicates anyway through extender()-item(name). This patch changes the behavior to 'always persistent', and also saves all items' collapsed state. (and adds a big fat warning in the default implementation of initExtenderItem about not implementing initExtenderItem while using extenders) The question is, do we want this change in behavior? I personally think it's worth it. Second question is, do we want this backported to 4.2. Again, I think yes, but can we do this considering the freeze? Diffs - /trunk/KDE/kdelibs/plasma/plasma/applet.cpp /trunk/KDE/kdelibs/plasma/plasma/extender.cpp /trunk/KDE/kdelibs/plasma/plasma/extenderitem.cpp /trunk/KDE/kdelibs/plasma/plasma/private/extenderitem_p.h Diff: http://reviewboard.vidsolbach.de/r/328/diff Testing --- Thanks, Rob ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: FrameSvg corruption [a bit urgent]
On Friday 16 January 2009, Ivan Čukić wrote: the thing that probably doesn't work so great is the config file that stores the prefixes, though in practice that shouldn't be a problem. we'll Just to mention, if you have missed it, notmart confirmed that all worked well before the change you have mentioned before (websvn.kde.org/?view=revrevision=905645) no, i didn't miss it. in case anyone else missed it, that commit fixes a pretty obvious visual bug when switching between themes at runtime. i explained the border issue in a previous email. in fact, i specifically mentioned that if the borders are scalable the mechanism we use there (and previously) *will not work*. i just opened the button svg and lo and behold, the borders are no fixed sized pixmaps but proper SVG items. ta-da. so we need a hint that says my borders are scalable and in those cases not do the resize thing before figuring border size. -- 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 Software 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: Tokamak Meeting II
On Thursday 15 January 2009 17:47:30 Nuno Pinheiro wrote: so if you coud send me a title to the presentation and expected time it will take you it will be great. I would like to present some of the Nepomuk / Crystal stuff, Crystal is explained in 5 minutes, I can give more information about Nepomuk making it a bit longer -- but I think it'd be useful for others to know so they can consider using Nepomuk in their applets as well. -- 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
Icons only mode for tasks plasmoid
Hello Plasma-devs,
first of all: please cc me in answers as I am not subscribed to this list.
I just did some hacking on the tasks plasmoid and added an option to only show
the icons and hide the text. So a kind of Windows 7 task bar. The advantage is
that much less space is required, you can have bigger icons and most important
it suites vertical panels much better. Currently tasks plasmoid kind of sucks
when having a big vertical panel.
Please have a look at the attached patch and give comments on it ;-)
Regards
Martin Gräßlin
commit fc6184bef3a4491eaf2f303d4f6a94e416335758
Author: Martin Gräßlin ubu...@martin-graesslin.com
Date: Fri Jan 16 17:21:22 2009 +0100
Icons only mode for tasks plasmoid
diff --git a/applets/tasks/abstracttaskitem.cpp b/applets/tasks/abstracttaskitem.cpp
index e9e50ac..8739c32 100644
--- a/applets/tasks/abstracttaskitem.cpp
+++ b/applets/tasks/abstracttaskitem.cpp
@@ -98,8 +98,15 @@ QSize AbstractTaskItem::basicPreferredSize() const
topMargin = qMax(1, topMargin/2);
bottomMargin = qMax(1, bottomMargin/2);
}
-return QSize(mSize.width()*12 + m_applet-itemLeftMargin() + m_applet-itemRightMargin() + KIconLoader::SizeSmall,
+if (m_applet-iconsOnly()) {
+iconsize = KIconLoader::SizeMedium;
+int size = qMin((int)m_applet-itemLeftMargin() + (int)m_applet-itemRightMargin() + iconsize,
+qMax(mSize.height(), iconsize) + topMargin + bottomMargin);
+return QSize(size, size);
+} else {
+return QSize(mSize.width()*12 + m_applet-itemLeftMargin() + m_applet-itemRightMargin() + KIconLoader::SizeSmall,
qMax(mSize.height(), iconsize) + topMargin + bottomMargin);
+}
}
AbstractTaskItem::~AbstractTaskItem()
@@ -453,17 +460,18 @@ void AbstractTaskItem::drawTask(QPainter *painter, const QStyleOptionGraphicsIte
}
painter-setPen(QPen(textColor(), 1.0));
+if (!m_applet-iconsOnly()) {
+QRect rect = textRect(bounds).toRect();
+if (rect.height() 20) {
+rect.adjust(2, 2, -2, -2); // Create a text margin
+}
+QTextLayout layout;
+layout.setFont(KGlobalSettings::taskbarFont());
+layout.setTextOption(textOption());
-QRect rect = textRect(bounds).toRect();
-if (rect.height() 20) {
-rect.adjust(2, 2, -2, -2); // Create a text margin
+layoutText(layout, m_text, rect.size());
+drawTextLayout(painter, layout, rect);
}
-QTextLayout layout;
-layout.setFont(KGlobalSettings::taskbarFont());
-layout.setTextOption(textOption());
-
-layoutText(layout, m_text, rect.size());
-drawTextLayout(painter, layout, rect);
TaskGroupItem *groupItem = qobject_castTaskGroupItem *(this);
if (groupItem) {
@@ -720,7 +728,9 @@ QRectF AbstractTaskItem::iconRect(const QRectF b) const
QRectF bounds(b);
const int right = bounds.right();
//leave enough space for the text. useful in vertical panel
-bounds.setWidth(qMax(bounds.width() / 3, qMin(minimumSize().height(), bounds.width(;
+if (!m_applet-iconsOnly()) {
+bounds.setWidth(qMax(bounds.width() / 3, qMin(minimumSize().height(), bounds.width(;
+}
//restore right position if the layout is RTL
if (QApplication::layoutDirection() == Qt::RightToLeft) {
@@ -728,8 +738,12 @@ QRectF AbstractTaskItem::iconRect(const QRectF b) const
}
QSize iconSize = m_icon.actualSize(bounds.size().toSize());
+Qt::Alignment align = Qt::AlignLeft;
+if (m_applet-iconsOnly()) {
+align = Qt::AlignCenter;
+}
-return QStyle::alignedRect(QApplication::layoutDirection(), Qt::AlignLeft | Qt::AlignVCenter,
+return QStyle::alignedRect(QApplication::layoutDirection(), align | Qt::AlignVCenter,
iconSize, bounds.toRect());
}
diff --git a/applets/tasks/tasks.cpp b/applets/tasks/tasks.cpp
index e7068af..558128b 100644
--- a/applets/tasks/tasks.cpp
+++ b/applets/tasks/tasks.cpp
@@ -123,6 +123,7 @@ void Tasks::init()
m_groupManager-setShowOnlyMinimized( cg.readEntry(showOnlyMinimized, false));
m_groupManager-setOnlyGroupWhenFull(cg.readEntry(groupWhenFull, true));
m_showTooltip = cg.readEntry(showTooltip, true);
+m_iconsOnly = cg.readEntry(iconsOnly, false);
m_groupManager-setGroupingStrategy( static_castTaskManager::GroupManager::TaskGroupingStrategy(cg.readEntry(groupingStrategy, static_castint(TaskManager::GroupManager::ProgramGrouping;
@@ -252,6 +253,7 @@ void Tasks::createConfigurationInterface(KConfigDialog *parent)
parent-addPage(widget, i18n(General), icon());
m_ui.showTooltip-setChecked(m_showTooltip);
+m_ui.iconsOnly-setChecked(m_iconsOnly);
m_ui.showOnlyCurrentDesktop-setChecked(m_groupManager-showOnlyCurrentDesktop());
m_ui.showOnlyCurrentScreen-setChecked(m_groupManager-showOnlyCurrentScreen());
Re: Icons only mode for tasks plasmoid
On Friday 16 January 2009, Martin Gräßlin wrote: Please have a look at the attached patch and give comments on it ;-) before this goes in (and the patch looks ok at first read) i think we may want to step back and ask ourselves: Do we really want a task bar that behaves exactly like the current task bar, except that it has no text? - or - Do we want a task bar that actually has the semantics of a dock? if the latter, we ought to create a sperate widget. this new widget and the tasks widget can certainly share a lot of code and classes, but i don't think that shoving more and more options in and complicating the code more and more makes the most sense if what we really want is a dock when it's all said and done. btw, in the code, instead of doing the checkedState comparison, you can just do isChecked(). so much shorter =) checkedState only really matters for tristate controls. -- 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 Software 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: Icons only mode for tasks plasmoid
On Friday 16 January 2009 19:15:55 you wrote: On Friday 16 January 2009, Martin Gräßlin wrote: Please have a look at the attached patch and give comments on it ;-) before this goes in (and the patch looks ok at first read) i think we may want to step back and ask ourselves: Do we really want a task bar that behaves exactly like the current task bar, except that it has no text? - or - Do we want a task bar that actually has the semantics of a dock? if the latter, we ought to create a sperate widget. this new widget and the tasks widget can certainly share a lot of code and classes, but i don't think that shoving more and more options in and complicating the code more and more makes the most sense if what we really want is a dock when it's all said and done. Personally I would like to have a dock and of course I thought of a dock when starting to work on this part ;-) But first of all for me only icons would be enough for saving space ;-) I don't know how much work it would be to get a dock starting from the tasks widget. Most of the functionality of the tasks widget will be needed in a dock, too. Of course the quicklaunch functionality has to be added and saving the positions, etc. btw, in the code, instead of doing the checkedState comparison, you can just do isChecked(). so much shorter =) checkedState only really matters for tristate controls. I just wanted to keep the code consistent to the existing checks ;-) 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: FrameSvg corruption [a bit urgent]
On Friday 16 January 2009, Aaron J. Seigo wrote: On Friday 16 January 2009, Ivan Čukić wrote: the thing that probably doesn't work so great is the config file that stores the prefixes, though in practice that shouldn't be a problem. we'll Just to mention, if you have missed it, notmart confirmed that all worked well before the change you have mentioned before (websvn.kde.org/?view=revrevision=905645) no, i didn't miss it. in case anyone else missed it, that commit fixes a pretty obvious visual bug when switching between themes at runtime. problem was that svg.size() returned -1,-1 if no operation was done before to initialize the size variable cached in svgprivate should be fixed now i explained the border issue in a previous email. in fact, i specifically mentioned that if the borders are scalable the mechanism we use there (and previously) *will not work*. i just opened the button svg and lo and behold, the borders are no fixed sized pixmaps but proper SVG items. ta-da. so we need a hint that says my borders are scalable and in those cases not do the resize thing before figuring border size. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PATCH] fix for 8 krazy2 issues
Aaron J. Seigo a écrit : doing so now ... btw, if you wish to continue to contribute (same for the other kourseware contributors), please consider getting an svn account .. personally, i hope you do both want to continue and do apply for an account =) Thanks Aaron! I just applied for one @ http://techbase.kde.org/Contribute/Get_a_SVN_Account Bruno ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Icons only mode for tasks plasmoid
On Friday 16 January 2009, Aaron J. Seigo wrote: On Friday 16 January 2009, Martin Gräßlin wrote: Please have a look at the attached patch and give comments on it ;-) before this goes in (and the patch looks ok at first read) i think we may want to step back and ask ourselves: Do we really want a task bar that behaves exactly like the current task bar, except that it has no text? - or - Do we want a task bar that actually has the semantics of a dock? if the latter, we ought to create a sperate widget. this new widget and the tasks widget can certainly share a lot of code and classes, but i don't think that shoving more and more options in and complicating the code more and more makes the most sense if what we really want is a dock when it's all said and done. just a little administrative curiosity: so if we want to do so, where should be put? in workspace like plasmaclock or simply make more applet in the same taskbar applet folder like kickoff? btw, in the code, instead of doing the checkedState comparison, you can just do isChecked(). so much shorter =) checkedState only really matters for tristate controls. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Icons only mode for tasks plasmoid
From: Aaron J. Seigo ase...@kde.org Do we really want a task bar that behaves exactly like the current task bar, except that it has no text? I remember starting to hack on this a few months ago and one thing that came up for me: - If the user selects Icon Only then there would perhaps need to be an UI interlock for tooltips (i.e. select Icon Only - Tooltips always visible). That would provide the user access to the text they would otherwise get, though it requires additional mouse hover action. There's at least precedent for extra hover action in other task UI's. I won't argue though, whether those are good or bad precedents. :-) - or - Do we want a task bar that actually has the semantics of a dock? if the latter, we ought to create a sperate widget. For full dock semantics, yeah it would make better sense to create a seperate widget. Dock semantics, at least for OS X and Windows 7, include conflation of launcher and running applications in addition to icon-only task recognition (among other things I'm sure). Perhaps there are portions of Dock semantics that are valuable on their own or as part of the existing tasks widget. In this case perhaps icon-only task recognition, properly implemented, could be useful as well. Hope this helps, Andrew (Jamboarder) Lake ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Icons only mode for tasks plasmoid
On Friday 16 January 2009, Marco Martin wrote: so if we want to do so, where should be put? in workspace like plasmaclock or simply make more applet in the same taskbar applet folder like kickoff? good questions. i prefer each in its own folder under applets. due to its location, the simple menu is a bit hard to find if you aren't familiar with the source code tree already. of course, whether it belongs in kdebase or kdeaddons is another good question, and would come down to how critical we feel a dock would be to the default experience. -- 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 Software 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: Plasma Applet Direction
From: Aaron J. Seigo ase...@kde.org hmm... let's brainstorm on this ... things that are global plasma settings: * Plasma theme * install/remove widgets * per-virtual-desktop views anything else? These are a little speculative but: - panel-follows-activity? - Activity - Icon threshold for semantic zoom? hmm... after reading Marco's response about keeping settings dialogs to a minimum, what if these settings show up in a renamed/slightly-repurposed Zoomed Out mode? Contextually, you're zoomed out so you're no longer activity specific anyway. And settings changes there could perhaps be interpreted, at least visually, to be more global. Then, perhaps we could even move Add Activity out of the activity-specific actions into these settings (kinda odd seeing Add Activity on every activity when they all do the same thing that has nothing to do with that activity). Anyway just ideas... Hope they're helpful, Andrew ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: FrameSvg corruption [a bit urgent]
no, i didn't miss it. in case anyone else missed it, that commit fixes a pretty obvious visual bug when switching between themes at runtime. It wasn't my intention to suggest you to revert, but just to point to the time when it broke. The FrameSvg code is not something I'm familiar, but am trying to help you as much as I can to solve this in time for 4.2 tagging. -- The bleeding hearts and artists, Make their stand. -- Pink Floyd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Styled input fields
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.vidsolbach.de/r/329/ --- Review request for Plasma. Summary --- This makes input fields use plasma text color (maybe would not have a distinction between windowtext and text here to keep things simple?) and a framesvg for painting (currently sunken frame, probably will need new graphics with also a nice focus effect) since input fields are a thing that would be identic for every similar thing it's done in the plasma style, modified to create only framesvgs that actually needs the combobox is still missing, but that's the idea :) Diffs - /trunk/KDE/kdelibs/plasma/private/style.cpp /trunk/KDE/kdelibs/plasma/private/style_p.h /trunk/KDE/kdelibs/plasma/widgets/lineedit.h /trunk/KDE/kdelibs/plasma/widgets/lineedit.cpp /trunk/KDE/kdelibs/plasma/widgets/spinbox.h /trunk/KDE/kdelibs/plasma/widgets/spinbox.cpp Diff: http://reviewboard.vidsolbach.de/r/329/diff Testing --- Screenshots --- http://reviewboard.vidsolbach.de/r/329/s/99/ Thanks, Marco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Making paths case insensitive in krunner
Hi, My name is Diaa sami and I'm relatively new to KDE development, recently I've been working on making path completion in KDE case insensitive[1], which should be more productive, I've already made Konqueror, Dolphin and the file dialogs provide case-insensitive path completion, these changes are already in KDE 4.2 I was thinking that when launching files and folders in krunner using the Locations plugin, paths shouldn't be case-sensitive, or at least it can be an option. upon examining the code I found that it's krunner that needs modification because it is where the type of the command is determined(and found to be a file or a folder). I've already wrote the code to recognize and correct paths with incorrect case, but I did it in a separate application for easier testing and debugging. so what do you think? Regards, Diaa Sami [1] http://lists.kde.org/?t=12207289331r=1w=2 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Icons only mode for tasks plasmoid
On Fri, 16 Jan 2009 19:36:31 +0100, Martin Gräßlin k...@martin-graesslin.com wrote: On Friday 16 January 2009 19:15:55 you wrote: On Friday 16 January 2009, Martin Gräßlin wrote: Please have a look at the attached patch and give comments on it ;-) before this goes in (and the patch looks ok at first read) i think we may want to step back and ask ourselves: Do we really want a task bar that behaves exactly like the current task bar, except that it has no text? - or - Do we want a task bar that actually has the semantics of a dock? if the latter, we ought to create a sperate widget. this new widget and the tasks widget can certainly share a lot of code and classes, but i don't think that shoving more and more options in and complicating the code more and more makes the most sense if what we really want is a dock when it's all said and done. Personally I would like to have a dock and of course I thought of a dock when starting to work on this part ;-) But first of all for me only icons would be enough for saving space ;-) I don't know how much work it would be to get a dock starting from the tasks widget. Most of the functionality of the tasks widget will be needed in a dock, too. Of course the quicklaunch functionality has to be added and saving the positions, etc. btw, in the code, instead of doing the checkedState comparison, you can just do isChecked(). so much shorter =) checkedState only really matters for tristate controls. I just wanted to keep the code consistent to the existing checks ;-) Since everyone is now talking about a dock i just wanted to say that i don't like the dock at all(at least the OSX one..) I can't see any advantage apart from the fancy look and the quick access to some apps (which could be overcome with a simple quickstart applet placed next to the taskbar). Other than that i think it just takes away space from the taskbar which could be used to identify tasks. But if you have some fancier ideas than apple, please let me know ;-) To get back to topic, i quite like your patch and from my pov we could integrate it (although i couldn't live with only icons) and will probably never use it =). What i don't understand is how you're able to distinguish between multiple windows of the same app. Since we want to have soon a popup showing real TaskGroupItems it would also not work with grouped windows. This has to be considered maybe... Regards -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: PATCH: Configuration Dialog for Turning off Notifications in the Panel
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.vidsolbach.de/r/331/ --- Review request for Plasma. Summary --- This patch allows one to turn on and off jobs and notifications in the panel via the systemtray configuration dialog. This is in response to Aaron Seigo's blog entry: http://aseigo.blogspot.com/2009/01/todays-tip-turning-off-fancy-schmancy.html Withing manager.cpp, functions to unregister the notification and job protocols was created, as well as a function to unset a protocol (disconnect it). These were based on the already present functions to register and setup protocols. Within applet.cpp, a new page was added to the configuration dialog called Notifications. This page includes the two check boxes that allow one to turn on and turn off notifications. A possible area where that may need to be fixed is the strings for the check boxes. Presently they are Show Jobs and Show Notifications. Thank you for your time and review. Diffs - /trunk/KDE/kdebase/workspace/plasma/applets/systemtray/core/manager.h /trunk/KDE/kdebase/workspace/plasma/applets/systemtray/core/manager.cpp /trunk/KDE/kdebase/workspace/plasma/applets/systemtray/ui/applet.cpp Diff: http://reviewboard.vidsolbach.de/r/331/diff Testing --- Testing of suppression of job progress. Testing of suppression of notifications. Testing of allowing job progress. Testing of allowing notifications. Thanks, distortedlogic ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
signal clicked()
I want my plasma to react on left click on it. What signal/object should I connect to my slot? I tried MyApplet::clicked() , but there is no such signal... ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
