Re: Reworking the kwin tabbox
Am Donnerstag 16 Juli 2009 21:49:24 schrieb Thomas Lübking: now my 2¢ on the whole suggestion: imho there two different approaches to switch windows. - one is on the fly - which is good if you've got 2 up to 4 open windows, therefore the current concept is pretty much ok. - the other one is to find out of your window mess - basically the exposé approach the problem we face is top provide sth. like this (where window switching is a single task job) for an uncomposited environment - (regarding the fulltime job switch) - whatever we do: not using the entire available screen is waste. (otherwise it would just be another taskbar :-( - the task is not bound to mouse or keyboard usage (i.e. you want to use both input devs) - as it's a fulltime job, there can (and should) be an explicit leave statement (clicking a window, pressing enter, etc.) - therefore there's no problem with a searchline either =D the key backdraw is that we cannot rely on compositing i.e. a miniversion of the window. all we have are title and icon and the icon is probably ambigious (right now i've got 5 kmail windows opened...) and the text (maybe ambigious as well) is a rather slow visualization :-( to improve this we could include the window geometries (or rather aspects) to draw some boxes and strip stuff like the app name from the displayed window titles (as they're implicated by the icons anyway) advertthe bespin deco has such feature implemented ;-)/advert Sidenote: --- imho a WM may take advantages from other running process but not rely with some core functionality on them (even if we assumed the plasma/KDE only! variant (what's pretty un-unix). what if krunner crashes, and a user who never uses it otherwise magically looses some functionality of his/her WM? s/he might search a whole day for the option to reactivate it :-( thanks Thomas, your comment helped. So basically I agree that we cannot change the alt+tab behaviour, which has to be quick and has to be with alt key pressed. So what we need is that fulltime job. And basically everything I proposed so far is for that fulltime job. And I think that could be done with a special KRunner interface (in that case it would be ok to use the external KRunner as it is not such an important core functionality like alt+tab). And I agree that current size of the KRunner interface is a waste of space when going for such a switcher. So Plasma devs is it possible to get it bigger when we activate KRunner from KWin? I don't think it has to use the full width, but full height or a reasonable height to fit all windows in the selection would be nice. 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: Reworking the kwin tabbox
On Friday 17 July 2009 10:32:32 Martin Gräßlin wrote: Am Donnerstag 16 Juli 2009 21:49:24 schrieb Thomas Lübking: now my 2¢ on the whole suggestion: imho there two different approaches to switch windows. - one is on the fly - which is good if you've got 2 up to 4 open windows, therefore the current concept is pretty much ok. - the other one is to find out of your window mess - basically the exposé approach the problem we face is top provide sth. like this (where window switching is a single task job) for an uncomposited environment - (regarding the fulltime job switch) - whatever we do: not using the entire available screen is waste. (otherwise it would just be another taskbar :-( - the task is not bound to mouse or keyboard usage (i.e. you want to use both input devs) - as it's a fulltime job, there can (and should) be an explicit leave statement (clicking a window, pressing enter, etc.) - therefore there's no problem with a searchline either =D the key backdraw is that we cannot rely on compositing i.e. a miniversion of the window. all we have are title and icon and the icon is probably ambigious (right now i've got 5 kmail windows opened...) and the text (maybe ambigious as well) is a rather slow visualization :-( to improve this we could include the window geometries (or rather aspects) to draw some boxes and strip stuff like the app name from the displayed window titles (as they're implicated by the icons anyway) advertthe bespin deco has such feature implemented ;-)/advert Sidenote: --- imho a WM may take advantages from other running process but not rely with some core functionality on them (even if we assumed the plasma/KDE only! variant (what's pretty un-unix). what if krunner crashes, and a user who never uses it otherwise magically looses some functionality of his/her WM? s/he might search a whole day for the option to reactivate it :-( thanks Thomas, your comment helped. So basically I agree that we cannot change the alt+tab behaviour, which has to be quick and has to be with alt key pressed. So what we need is that fulltime job. And basically everything I proposed so far is for that fulltime job. And I think that could be done with a special KRunner interface (in that case it would be ok to use the external KRunner as it is not such an important core functionality like alt+tab). And I agree that current size of the KRunner interface is a waste of space when going for such a switcher. So Plasma devs is it possible to get it bigger when we activate KRunner from KWin? I don't think it has to use the full width, but full height or a reasonable height to fit all windows in the selection would be nice. Yes we can(tm) However the (aestethical) problem I see with that is that with the filtering action of the queries, we would quiclky have far less results than all results so that the results view would be mostly empty as soon as the user looks for something. Since you can (and want) to filter your results I wouldn't see a problem in showing only a fraction of them to start with.. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma-devel Digest, Vol 13, Issue 41
On Thu, Jul 16, 2009 at 10:58 PM, Diego Casella ([Po]lentino)polentino...@gmail.com wrote: -- Messaggio inoltrato -- From: Yuen Hoe Lim yuenho...@gmail.com To: plasma-de...@kde.org Date: Fri, 17 Jul 2009 01:13:23 +0800 Subject: Re: Re: Plasmate status With a directory tree listing the project files, of course =) isn't that already there? or did someone remove it? I've never seen that dock widget =( It's there, though I doubt it's actually doing anything now since we're not saving anything yet afaik. Plus its there when you start out, but it gets replaced with the editor kpart when you select anything. Uh ok, the one with Configuration Definition, Images, Executable Scripts, Translations !!! I was referring to a traditional directory tree list, with a root directory, its subfolders and files, not a list of elements grouped by its usage =) That is actually the structure of a Plasma Package (Plasma::PackageStructure) with their respective MIME types (thats how plasmate knows which kpart to load for the editor). Sorry for the mistake ! -- Jason moofang Lim Yuen Hoe http://yuenhoe.co.cc/ ___ 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 -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add next and previous buttons to Frame applet
On Tuesday 14 July 2009 19:36:08 Arthur Mello wrote: As mentioned on Frame TODO this patch adds buttons to navigate through slide show. Buttons appear when mouse is over applet and only when applet is doing a slideshow. Example code at TODO put the buttons above the pictue, I placed them on left and right borders, but I can change this if necessary. The approach looks sensible, so +1 for committing this patch. However, I have rather substantial changes to the frame applet on my disk. I'm resolving some issues that I wouldn't like to see committed this weekend and am planning to commit the whole thing this weekend. It would be good if I didn't have to rebase all my patches -- I had to do it by hand once already. So please wait with committing it until my work is in. (Your patch looks much easier to rebase on top of mine.) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 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: window management ideas
On Wednesday 15 July 2009 07:41:32 Aaron J. Seigo wrote: On Friday 10 July 2009, Chani wrote: what I wanted is window tagging. do windows live long enough for tagging to work? would there be an always there tag? how easy is it to tag a window? (this is an interaction design concept) how does tagging interact with activities? (i suppose that's answered in the windowgroups / pager / ZUI thread?) what's the average user advantage in this? how much work is saved or how much efficiency gained versus how much time spent messing around with tagging? this feels like a very geek feature that i can't see many people using. i could be wrong but tagging really tends to work when: * the data set is large * the data set is long lived (so value accrues over time) * the data set is shared by many people (so there's value reaped from other's work or by being able to tie several people's work together in unique ways) because of that, tagging works _fabulously_ for things like photo sharing websites and online news aggregation. how well does it work for a small, often/usually temporary, non-shared data set? I see tagging also as a way to specify the virtual desktop / window group an application window is in. Moving a window to some virtual desktop called Work would tag the window with it. Based on those tags, we can open stuff by project / activity. So you open all windows tagged foobar to open the foobar project. Saving goes similarly. The thing is that we need to differentiate between unique applications (think of your email client) and document windows (think of a kwrite window with an open text file). unique applications would have persistant tags attached to the application, document windows would have those tags set on the file they're displaying. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 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: Reworking the kwin tabbox
Diego Moya wrote: 2009/7/16 Martin Gr��lin k...@martin-graesslin.com: My idea is that with alt+tab it should work as ever known. But that it is not required to keep alt pressed (keeping it pressed shouldn't harm). There's a way to achieve that goal without breaking the normal alt+tab quasimode behavior. Hold alt + tab as many times as required + release tab = change window (same behavior) Hold alt + tab + press cursor key + release tab = make tabbox persistent. From now on, pressing tab or cursor arrows navigates the window list normally, and Enter is required to close the tabbox and open the selected window. You can add as many extra keys as desired after the initia alt+tab, to free the quasimode and trap the window for providing additional functions. For example, hold alt + tab + s + release tab, could activate a search function among the name (or content!) of the open windows. Or: hold alt + tab + k + release tab, could be used as the trigger key for the krunner-like extra functions. Personally, I prefer the solution Maciej and I discussed w.r.t. NWI, which is using a different key combination to activate the switcher in release-mod-isn't-confirm mode. (And that way 'alt(v) tab(v) tab(^) arrows(v,^) alt(^)' can still be used w/o adding another key to confirm.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- ,= ,-_-. =.Function ((_/)o o(\_)) Flexibility `-'(. .)`-' Freedom \_/ The Power of GNU ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Tokamak 3 - The organization begins
But yesterday in the news there was an article about that the Schengen area is thinking about omitting the VISA duty for Serbia, Montenegro and Yes, unfortunately it is not going to happen on the time for T3. So, I'll definitely need it as soon as possible (have no idea how long the VISA process is - it *was* one week the last time I came to CH, but it can be much longer) Cheers p.s. CH is now a part of Schengen? (as in the VISA is the same?) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix text centering in task manager task items
On Thursday 16 July 2009, Alec Moskvin wrote: On 2009-07-16 07:54:09, Marco Martin wrote: yeah, the text ends up definitely not centered :( http://imagebin.ca/view/hGiPl3.html What's interesting is that it's actually pretty well-centered, but it looks way off if the text has no descenders. i find it often looks most natural to the eye to align text to the baseline, even if it isn't strictly centered anymore. QFontMetrics can tell you what the descent is to calculate the baseline. maybe that will help. -- 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: zui, windows, desktops
On Thursday 16 July 2009, Marco Martin wrote: On Thursday 16 July 2009, Aaron J. Seigo wrote: * the window group overview could include an Activities overview as well. the visual will help explain this but for now imagine a strip at the top of the screen showing the existing Activities: a name above and a shrunken version of the Activity below; switching would be moving which activity is in the center, e.g. by scrolling through them or clicking on one. so there would be a horizontal stripe of activity choices sitting atop a set of horizontal window groupings, keeping things visually distinct so they don't become overly confusing? i've read this point several times and still don't have a clear idea, yes a photo would be appreciated :) will do :) we found a place to move into the other day, so i'll be back to working more regularly again next week, and i'll catch up with this point (and others) then. * arrange the desktop containments on the corona in a horizontal strip, one row per screen hmm, it wouldn't be possible to switch a containment between screen so? not being able to access an old activity just bcause at the moment i don't have a screen around doesn't seem too convenient? i think we should be able to make it possible to do so, though i don't know if it would be completely seamless in that one would probably have to select a other Acitivities button or some such thing. right now it's already pretty confusing, however, since all screens and all desktops are scattered in the same layout making it confusing to people why they can't select or remove a certain activity. or when a screen is disconnectedeverything is closed, saved and can be loaded from everywhere? this is certainly a possibility, as in Chani's proposal. as long as people don't expect those activities to remain live (which seems like quite a corner case imo) then we should be fine with just not loading activities for which their associated screen does not exist. * we must publish the activity stuff live in nepomuk so that applications can adjust their content and play along too question i'm wondering since a bit: does nepomuk has some support of the Context concept or is it something still to come? yes and no. there's a start of an ontology for this, and otherwise it's completely ready for it. all that's needed is to commit to the Context ontology, which was something i started working on with the nepomuk team, but got distracted as they went off into more and more theoretical stuff. i need to see if they have come up with anything in the meantime. -- 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
KDE/kdelibs/experimental/knotificationitem
SVN commit 997964 by asouza:
Only disconnect the signal if everything was ok. Before we were disconnecting
and connecting again if something went wrong.
CCMAIL: plasma-devel@kde.org
M +1 -3 knotificationitem.cpp
--- trunk/KDE/kdelibs/experimental/knotificationitem/knotificationitem.cpp
#997963:997964
@@ -630,14 +630,12 @@
if (notificationItemWatcher-isValid()
notificationItemWatcher-ProtocolVersion() == s_protocolVersion) {
-QObject::disconnect(notificationItemWatcher,
SIGNAL(NotificationHostRegistered()), q, SLOT(registerToDaemon()));
if (notificationItemWatcher-IsNotificationHostRegistered()) {
kDebug() service is notificationItemDbus-service();
notificationItemWatcher-RegisterService(notificationItemDbus-service());
setLegacySystemTrayEnabled(false);
-} else {
-QObject::connect(notificationItemWatcher,
SIGNAL(NotificationHostRegistered()), q, SLOT(registerToDaemon()));
+QObject::disconnect(notificationItemWatcher,
SIGNAL(NotificationHostRegistered()), q, SLOT(registerToDaemon()));
}
} else {
kDebug()System tray daemon not reachable or no registered system
trays;
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Reworking the kwin tabbox
2009/7/16 Martin Gräßlin k...@martin-graesslin.com: My idea is that with alt+tab it should work as ever known. But that it is not required to keep alt pressed (keeping it pressed shouldn't harm). There's a way to achieve that goal without breaking the normal alt+tab quasimode behavior. Hold alt + tab as many times as required + release tab = change window (same behavior) Hold alt + tab + press cursor key + release tab = make tabbox persistent. From now on, pressing tab or cursor arrows navigates the window list normally, and Enter is required to close the tabbox and open the selected window. You can add as many extra keys as desired after the initia alt+tab, to free the quasimode and trap the window for providing additional functions. For example, hold alt + tab + s + release tab, could activate a search function among the name (or content!) of the open windows. Or: hold alt + tab + k + release tab, could be used as the trigger key for the krunner-like extra functions. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: ginormous performance issue
On Friday 17 July 2009, Marco Martin wrote: and still, in the case of an applet with many subwidgets, independent timers can do really a big signal storm, so i still kinda like more the pointer approach :p yes, having a single timer for this is a nice win the pointer thing is as bit of a hack (and yes, a pointer is always an int, so that's fine in that previous patch). the pointer bit would need to be stripped before actually putting it into the cache; i wonder if having a set syntax for it would make more sense, e.g. id:path_details_separated_by_underscores allowing the id to be stripped off. then the don't cache this yet collection could be a map of ids to entries. really, this is just a way around adding API. i wonder if it wouldn't make more sense to just add a new addToCache method in Theme that takes an additional id argument for this purpose. avoids all the string parsing and reliance on well formed entries and makes it clear what's going on internally. i'll think more on this over the weekend (back to work on monday for me! wee! :)) but the more i look at the various patches the more i think that a new method is the cleanest approach. thoughts? -- 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 3 - The organization begins
Am Freitag, 17. Juli 2009 schrieb Ivan Čukić: Good morning Ivan But yesterday in the news there was an article about that the Schengen area is thinking about omitting the VISA duty for Serbia, Montenegro and Yes, unfortunately it is not going to happen on the time for T3. So, I'll definitely need it as soon as possible (have no idea how long the VISA process is - it *was* one week the last time I came to CH, but it can be much longer) Ok. Would it be ok if I write some invitation. I'm just a person and no company ... but hey, wait, I've got some company. Or do you need an invitation by KDE e.V.? Would a letter as pdf be enough? Cheers p.s. CH is now a part of Schengen? (as in the VISA is the same?) Afaik we finally are part of Schengen. griits Mario ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: ginormous performance issue
I like the new method and deprecate the old one if it's not anymore needed. On Friday, July 17, 2009, Aaron J. Seigo ase...@kde.org wrote: On Friday 17 July 2009, Marco Martin wrote: and still, in the case of an applet with many subwidgets, independent timers can do really a big signal storm, so i still kinda like more the pointer approach :p yes, having a single timer for this is a nice win the pointer thing is as bit of a hack (and yes, a pointer is always an int, so that's fine in that previous patch). the pointer bit would need to be stripped before actually putting it into the cache; i wonder if having a set syntax for it would make more sense, e.g. id:path_details_separated_by_underscores allowing the id to be stripped off. then the don't cache this yet collection could be a map of ids to entries. really, this is just a way around adding API. i wonder if it wouldn't make more sense to just add a new addToCache method in Theme that takes an additional id argument for this purpose. avoids all the string parsing and reliance on well formed entries and makes it clear what's going on internally. i'll think more on this over the weekend (back to work on monday for me! wee! :)) but the more i look at the various patches the more i think that a new method is the cleanest approach. thoughts? -- 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
Re: ginormous performance issue
On Friday 17 July 2009, Aaron J. Seigo wrote: On Friday 17 July 2009, Marco Martin wrote: and still, in the case of an applet with many subwidgets, independent timers can do really a big signal storm, so i still kinda like more the pointer approach :p yes, having a single timer for this is a nice win the pointer thing is as bit of a hack (and yes, a pointer is always an int, so that's fine in that previous patch). the pointer bit would need to be stripped before actually putting it into the cache; i wonder if having a set syntax for it would make more sense, e.g. id:path_details_separated_by_underscores allowing the id to be stripped off. then the don't cache this yet collection could be a map of ids to entries. really, this is just a way around adding API. i wonder if it wouldn't make more sense to just add a new addToCache method in Theme that takes an additional id argument for this purpose. avoids all the string parsing and reliance on well formed entries and makes it clear what's going on internally. i'll think more on this over the weekend (back to work on monday for me! wee! :)) but the more i look at the various patches the more i think that a new method is the cleanest approach. thoughts? +1 from me for the new method so the version without id will insert immediately into the cache, the version with id will be delayed, that will need to be well documented thinking about it besides the pointer as id we need also in case of Svg the element id (if any) and in FrameSvg the prefix(if any) it's fine just to concatenate the two things in a single string i think tomorrow i will give a try (buaaah, /me want giiit:p) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add next and previous buttons to Frame applet
On Friday 17 July 2009 18:25:06 Arthur Renato Mello wrote: On Fri, Jul 17, 2009 at 9:10 AM, Sebastian Küglerse...@kde.org wrote: However, I have rather substantial changes to the frame applet on my disk. I'm resolving some issues that I wouldn't like to see committed this weekend and am planning to commit the whole thing this weekend. It would be good if I didn't have to rebase all my patches -- I had to do it by hand once already. So please wait with committing it until my work is in. (Your patch looks much easier to rebase on top of mine.) ok. I was working on play/pause too. After you commit I rediff, with pause button, and update the review request. Phew, thanks :) I wish we had a git setup already to make this kind of stuff much easier... -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Fixing Bball getting stuck at the corner
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1054/ --- Review request for Plasma, Aaron Seigo and Sebastian Kügler. Summary --- The Bball gets stuck at the right-bottom/left-bottom. Now with this patch it doesn't stuck. I had added a feature that when dropped from right/left top will make the ball bounce. Diffs - /trunk/KDE/kdeplasma-addons/applets/bball/bball.h 998542 /trunk/KDE/kdeplasma-addons/applets/bball/bball.cpp 998542 Diff: http://reviewboard.kde.org/r/1054/diff Testing --- Tested in my laptop and works fine here. Thanks, Sujith ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fixing Bball getting stuck at the corner
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1054/ --- (Updated 2009-07-17 23:37:46.001490) Review request for Plasma, Aaron Seigo, Artur de Souza (MoRpHeUz), and Sebastian Kügler. Summary --- The Bball gets stuck at the right-bottom/left-bottom. Now with this patch it doesn't stuck. I had added a feature that when dropped from right/left top will make the ball bounce. Diffs - /trunk/KDE/kdeplasma-addons/applets/bball/bball.h 998542 /trunk/KDE/kdeplasma-addons/applets/bball/bball.cpp 998542 Diff: http://reviewboard.kde.org/r/1054/diff Testing --- Tested in my laptop and works fine here. Thanks, Sujith ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: ginormous performance issue
On Friday 17 July 2009, Alexis Ménard wrote: I like the new method and deprecate the old one if it's not anymore needed. the old method is just fine for yes, cache this now and is indeed simpler to use (no need to ensure a unique id, e.g.), the new method would be for the i MAY want to cache this, but it MAY change in the near future or disappear altogether use case. it's probably a fairly even split between the two uses, looking over our current code. so i don't think we'd need to deprecate any. we could merge the two when we break BC next if the id comes last in the signature, 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
