Re: Plasma and KWin Integration
On Thursday 12 February 2009 17:44:14 Jamboarder wrote: From: Sebastian Kügler se...@kde.org ... For more conservative setups, we can use the Aya theme, which should be improved. The general idea of re-using the theme's colors is feasible I think, though probably not for the default Oxygen (Air) theme. The Aya theme does need some touch-ups though. Let me know what you'd like to see improved in Aya and I'll work on it. I hadn't had a look at Aya in a while (I think only at what has been shipped with OpenSuse). I'm now running it for a bit and I think it looks much better already. - I'm not totally sold one the right border, for some applets, it looks good, for others, it looks unrefined. It's also shown on the applet handle, making it look out of balance (between handle left/right) Why is this border there at all? - The black text doesn't give enough contrast on the folderview at the top - same goes for IconWidgets, inside the toolbox for example, also the text on the taskbar buttons looks unrefined - The menu that pops up for grouped tasks is missing the highlights, there's no hover feedback for the tasks right now Otherwise, Aya has come quite far, congrats to that! -- 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
Review Request: simple animation of tabbar icons everytime kickoff is launched by pressing the KDE start button
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/63/ --- Review request for Plasma and Aaron Seigo. Summary --- A little animation that mimics the behaviour of my sony erricsson handy whenever I get to the main menu. The Icons in kickoff's tabbar are all placed at the center of the tabbar before moving towards their intended location when the menu is displayed. It's a hack as of now and doesn't even work when the panel is placed on the right or left screen edge. But that's pretty easy to fix if you guys like that behaviour. I am not sure, maybe the thing is superfluous but hey, I like small useless animations. Diffs - KDE/kdebase/workspace/plasma/applets/kickoff/ui/CMakeLists.txt 925663 KDE/kdebase/workspace/plasma/applets/kickoff/ui/main.cpp 925663 KDE/kdebase/workspace/plasma/applets/kickoff/ui/ui/tabbar.h 925663 KDE/kdebase/workspace/plasma/applets/kickoff/ui/ui/tabbar.cpp 925663 Diff: http://reviewboard.kde.org/r/63/diff Testing --- the animation doesn't work (yet) if the panel is placed on the right or left screen edge. But adding support for that is pretty straightforward. Thanks, Mohammad Mehdi ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: simple animation of tabbar icons everytime kickoff is launched by pressing the KDE start button
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/63/ --- (Updated 2009-02-14 00:58:27.871308) Review request for Plasma and Aaron Seigo. Summary --- A little animation that mimics the behaviour of my sony erricsson handy whenever I get to the main menu. The Icons in kickoff's tabbar are all placed at the center of the tabbar before moving towards their intended location when the menu is displayed. It's a hack as of now and doesn't even work when the panel is placed on the right or left screen edge. But that's pretty easy to fix if you guys like that behaviour. I am not sure, maybe the thing is superfluous but hey, I like small useless animations. Diffs (updated) - trunk/KDE/kdebase/workspace/plasma/applets/kickoff/ui/tabbar.h 925803 trunk/KDE/kdebase/workspace/plasma/applets/kickoff/ui/tabbar.cpp 925803 Diff: http://reviewboard.kde.org/r/63/diff Testing --- the animation doesn't work (yet) if the panel is placed on the right or left screen edge. But adding support for that is pretty straightforward. Thanks, Mohammad Mehdi ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fun with Akonadi Dataengine
On Sunday 15 February 2009, David Baron wrote: 1. The ContactCollection-# loads all the contacts but they are not necessarily accessible at this point. I might have to try hm; this sounds rather inefficient for large address books. perhaps it's a good idea to collect use cases for this part of the engine and build specifically for those rather than build something too general purpose; the engine doesn't need to be able to support building an entire address book application around it (that's not the point of engines), so defining what a widget should like to do with it is probably a good start point. -- 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
Aya updates (was Re: Plasma and KWin Integration)
From: Sebastian Kügler se...@kde.org On Thursday 12 February 2009 17:44:14 Jamboarder wrote: Let me know what you'd like to see improved in Aya and I'll work on it. I hadn't had a look at Aya in a while (I think only at what has been shipped with OpenSuse). I'm now running it for a bit and I think it looks much better already. great! - I'm not totally sold one the right border, for some applets, it looks good, for others, it looks unrefined. It's also shown on the applet handle, making it look out of balance (between handle left/right) Why is this border there at all? Purely an aesthetic decision in the KDE 4.1 debut of the theme. The new applet handles for 4.2 introduced this imbalance when the standard background was used for the handle. I had a local patch for the applet handle to use it's own background svg but I could decide if it was worth introducing yet another theme element... but it does tie the theme author's hands a bit when trying to do asymmetric backgrounds. Still, I'm thinking about how to tweak this border for a future Aya release. - The black text doesn't give enough contrast on the folderview at the top - same goes for IconWidgets, inside the toolbox for example, also the text on the taskbar buttons looks unrefined Not sure if will help but there was a post 4.2 update of the theme available in trunk and via GHNS that improved the focused task element. That said, the text colors are part of the global color scheme and the text rendering handled by the respective applets. Aya doesn't control either of these. Perhaps the rendering of black text on lighter backgrounds could be improved a touch in the plasma libs/applets. There is also an inconsistency between how the text shadows are handled in the folderview (center-blurred) and in the task bar (offset-blurred) when the text color is dark. Aya is one of the few test cases for black text on lighter backgrounds - at least when the kde global color scheme is set to the Oxygen. Try Aya with Obsidian Coast color scheme to see if the text problems remain. - The menu that pops up for grouped tasks is missing the highlights, there's no hover feedback for the tasks right now I've noticed this happening for other themes as well (even Oxygen). I don't think I've missed an element in the Aya theme, but I might be wrong. I think the highlight uses the tasks.svg hover element, right? On a rare occasion I'll see the highlights show up correctly. Not sure what's causing it though. Otherwise, Aya has come quite far, congrats to that! Thanks so much for the feedback. I'll see what I can do to address the issues you've raised. My mild OCD will compel Aya tweakage for the foreseable future. :-) Andrew (Jamboarder) Lake ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New systemtray: beginnings and how to do
On Sunday 15 February 2009, Marco Martin wrote: this basic thing works fairly well by now, what is totally missing of course is the big part, the comunication infrastructure with the app (don't how to do this is going to be the big trick in all of this. the d-bus interaction is actually pretty simple, but preserving backwards compat will be interesting to accomplish. we have KSystemTrayIcon which IsA QSystemTrayIcon. so even if we implement the D-Bus protocol in KSystemTrayIcon, we'll always have a QSystemTrayIcon, and therefore a regular system tray icon, as well. what we really want is an API that takes the various possible information (icon, name, tooltip, etc, etc) and internally decides whether or not to use the D-Bus route or to use a KSystemTrayIcon internally and provide the other fun bits (e.g. the tooltip) manually. so this seems to indicate that we probably want a new class that will eventually end up in libkdeui. it should have a name that doesn't include SystemTray in it, and it should be source compatible as much as possible with KSystemTrayIcon so that it can be used as a drop-in replacement or as close to a drop-in as possible. KNotificationIcon? meh. so what would need to go in workspace would be the daemon and the protocol that's cool with me. for now, let's put the kded plugin in with the systemtray widget. when it gets accepted as an official KDE bit, we can move it somwhere else, though i think it should remain in workspace and only get started when a KDE desktop session is being started. -- 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 Automator
On Sunday 15 February 2009, Dario Freddi wrote: You set a preference in automator that switches your activity to Home when you get connected to your own wifi. So automator catches the signal, switches activity, and notifies you. this sounds a lot like plasma activity - plasma context - nepomuk - profit. the add on seems to be changing plasma activity, which causes the rest of the cascade, based on external stimulus. other than network, what external stimulus might this be? how would this work with manually switching activities? why wouldn't this live inside the plasma desktop shell itself? Applications could expose their DBus signals through XML files, that will let automator catch a variety of events. So every developer can hook its application into automator with a very minimum effort, define hook [..] into automater. is this to react to context changed events, or to trigger them? supposed that its application is already exposed in DBus. all kde apps are visible on the bus. -- 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: bisecting the 1-pixel bug
On Monday 16 February 2009, Alexis Ménard wrote: Hi, This is fixed, i will have the review tomorrow and i will push it for 4.5.0 final. big hug and be sure i offer you a beer next time :D Cheers, Marco Martin But to be sure it works you have to clean the cache in your .kde4/cache-*/kpc/plasma* Otherwise it won't redraw all svgs without the 1 px bug. On Sat, Feb 14, 2009 at 5:33 PM, Alexis Ménard men...@kde.org wrote: Ok thanks for taking time...we are still on it...Monday i will take a look on it and provide that to our graphics team. 2009/2/14 Marco Martin notm...@gmail.com Hi all, before i forget the details, i've done some tests about the 1 pixel bug in framesvg and what i found is this: it happens only when the svgrenderer paints on a qpixmap, if asked to paint on all of it, sometimes the last pixel gets not painted, the minimum amount of code to reliably cause this is the file attached, note the 1 pixel red line that appears sometimes. i've done a git bisect on the qt/all snapshot branch and probably doesn't tell that much (it does just reflet snapshots and not actual commits right?) but what i've found, if i didn't did terrible mistakes is that: (if it's not a really trivial thing to fix i'm going to post this on the qt task tracker) 355c90dad265a6c3b20f7bffeeabdc420ace78ee is first bad commit commit 355c90dad265a6c3b20f7bffeeabdc420ace78ee Author: Snapshots snapsh...@trolltech.com Date: Wed Dec 3 02:00:16 2008 +0100 Update to Qt 4.5 snapshot 20081203 :100644 100644 f053d8e7342aa99764f9f4674296d9ca9a4db372 8a9943da9b00c055f7d8dd5ebaffe0698c9502b4 M .tag :04 04 24d96e05510c648058db5df5b5ef2bbad15f82c9 7961db773e9b5b60ec300edbddcc87998d1c068b M doc :04 04 60df8b9737bcb54961c379640241c725963dee04 7d3f9d1080034f16a11fc1a7caf0d581a59ed4a9 M qmake :04 04 f89dd3fb8c536d65c8a0f091807c0a61030b4f59 ded3aa6cdf7bec61efad821e255565a07c39452b M src :04 04 6edf3b7029b91891f30295e21e49f9a6c1380159 20fa707790f7a3d935642e39ac7561832d9692c7 M tools ___ 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: battery monitor plasmoid changes
On Thursday 12 February 2009, Sebastian Kügler wrote: To accomplish this I added another layer to the svgz icon as well as a configuration option to allow the user to choose the old style display (4 separate blocks) or my continuous mode display. I personally think it doesn't need its own config option, instead I'd go for just making it default. Thing is that it's an artwork issue, which is Nuno's domain. i personally find discreet easier to read, though the art could be done differently. the trick is to have some visible demarcations, like the lines on a measuring cup. fading out the individual slices is a really nice touch imho. the big issue imho with a continuous mode is that we will still want some discreet-style behaviour, such as e.g. being able to change the colour as it gets close to empty. that said, it should be possible to do *either* with an appropriate svg. currently, there are only 5 states allowed for in the svg, and that could probably be improved. but i see no reason why the current svg couldn't even be used to do a continuous meter. i suppose the real issue is the granularity of the steps rather than continuous-versus-discreet, however. after all, continuous just means the discreet step is numberOfPixels/100 ;) how to achieve that graphically with elegance is the question. btw, in a discreet model increasing the # of steps can be done with backwards compat / without adding to the work of artists who don't care by using the element nearest to the %. so if it went by 5% steps (which should be plenty?) one could check for, e.g., 85% and if that doesn't exist look for 80% when the battery is 83% charged. anyways, i haven't seen the patch so i have no idea what the patch actually does. Basically, additionally to your issue (which I think is a valid point, especially interesting for larger / higher dpi representations of the applet Nuno asked me if I could do some stepping, so we don't get the SVG rendered at for example 27 pixels which *will* produce bad results. Instead the applet should, based on its size be rendered at 16, 22, 32 and 48 pixels. Starting with that size, it could probably just scale up. so it will float in the middle of a 30 px layout, with 4 px above and below? that's going to look highly questionable. perhaps you mean that the meter inside the battery will only get rendered to those sizes? that could make sense. I tried to adhere to the kde coding style guidelines and what the program already had. The patch looks technically good. which patch is this? and yes, a config option would be ridiculous for this. -- 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, ARGB and 4.5
On Friday 13 February 2009, Marco Martin wrote: Hi all, right now plasma enables argb visuals with that magin X11 code pasted in many places... since 4.5 now can handle it by setting Qt::WA_TranslucentBackground on the top level window we want transparent we can make it in a prettier way that would be nice. -- 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: Fun with Akonadi Dataengine
On Monday 16 February 2009 19:08:03 Aaron J. Seigo wrote: On Sunday 15 February 2009, David Baron wrote: 1. The ContactCollection-# loads all the contacts but they are not necessarily accessible at this point. I might have to try hm; this sounds rather inefficient for large address books. perhaps it's a good idea to collect use cases for this part of the engine and build specifically for those rather than build something too general purpose; the engine doesn't need to be able to support building an entire address book application around it (that's not the point of engines), so defining what a widget should like to do with it is probably a good start point. It's a point. But I am dialing the phone. Here is how I do it now: 1. In init(), I start a QTimer with 1 second interval. 2. At 1st timeout, I do the a query(ContactCollections) then if I find a suitable key, connectSource, i.e to ContentCollection-6. 3. After that, I connectAllSources at 1 second intervals until dataUpdated gets called. At this point, I stop the QTimer and am now receiving the contacts. Using these, I assemble my phone book into a QListWIdget. This works nicely in the background without delaying the panel/desktop and the GUI stays live. Using a QThread was my 1st try but the dataengine did not like that. The QTimer looks like a thread but is done differently so this plays. The alternative of writing a dataengine tailored to this type of task such as was done in a birthday plasmoid could be considered, not using Akonadi. Unless these background daemons are tactfully niced, I think folks may uninstall them. Nepomuk and all the Akonadi children take a large bite of CPU, especially after login. They may quiet down a lot later on (after everything is sync'ed?). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
suspend text and icon consistency
In 4.2 the suspend icons and text are inconsistent between battery
applet and kickoff.
http://www.kubuntu.org/~jriddell/tmp/logout1.png
http://www.kubuntu.org/~jriddell/tmp/logout2.png
I propose changing kickoff to use Sleep and Hibernate with the
subtext set to Suspend to Memory and Suspend to Disk
respectively. Also use system-suspend icon for Sleep to be consistent.
--- kdebase-workspace-4.2.0/plasma/applets/kickoff/core/leavemodel.cpp
2008-12-10 16:13:23.0 +
+++ kdebase-workspace-4.2.0/plasma/applets/kickoff/core/leavemodel.cpp
2009-02-16 19:27:44.0 +
@@ -74,13 +74,13 @@
item-setIcon(KIcon(system-suspend));
item-setData(i18n(Pause without logging out),
Kickoff::SubTitleRole);
} else if (basename == suspenddisk) {
-item-setText(i18n(Suspend to Disk));
+item-setText(i18n(Hibernate));
item-setIcon(KIcon(system-suspend-hibernate));
-item-setData(i18n(Pause without logging out),
Kickoff::SubTitleRole);
+item-setData(i18n(Suspend to Disk),
Kickoff::SubTitleRole);
} else if (basename == suspendram) {
-item-setText(i18n(Suspend to RAM));
-item-setIcon(KIcon(system-suspend-hibernate));
-item-setData(i18n(Pause without logging out),
Kickoff::SubTitleRole);
+item-setText(i18n(Sleep));
+item-setIcon(KIcon(system-suspend));
+item-setData(i18n(Suspend to Memory), Kickoff::SubTitleRole);
} else {
item-setText(basename);
item-setData(url, Kickoff::SubTitleRole);
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Tokamak III in Switzerland
Good morning all you Plasma hackers As I read in your blogs the Tokamak II meeting in Portugal was a real success (I'm especially excited about Nuno's AIR theme). And as you probably still know I proposed a location for the next Plasma meeting. At the KDE 4.2 release event in Zurich/Switzerland I had a quick talk with Aaron about my proposal and we left with the agreement that I'll sent another email to the list (which is hearby done ;-). There is still a doodle [1] vote for a date (end of August or beginning of September 2009) with already some people added. When there is still interest I'd like to fix the date in the coming days and weeks (say till the end of march) that I can begin to plan, organize and search for sponsoring. Furthermore the sooner we fix the meeting date and location the sooner you can begin to book the flights and apply for financial help at KDE e.V. So let's go concrete: - Is there still interest (see my mails last year about the details of my offering)? - Add your preferences for a date to the doodle [1]? - Let me begin to organize so that you'll come to a comfortable and inspiring hacking place. Greets out of the train Mario [1] http://www.doodle.com/participation.html?pollId=8444b4t2t7t74bp9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Tokamak III in Switzerland
So let's go concrete: - Is there still interest (see my mails last year about the details of my offering)? of course :) - Add your preferences for a date to the doodle [1]? - Let me begin to organize so that you'll come to a comfortable and inspiring hacking place. I don't have my exact schedule, but school generally starts the first week of september. the earlier tokamak happens, the less chance there is of teachers killing me. ;) although right now to be honest I'm finding it hard to care. apparently I didn't miss much during tokamak II. but who knows, in september I might end up with teachers who actually teach ;) the other thing is, we found out last year that flights in august are horribly expensive. so... I'd think the first week of september would be the best time. -- This message brought to you by eevil bananas and the number 3. www.chani3.com 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, ARGB and 4.5
On Monday 16 February 2009, Aaron J. Seigo wrote: On Friday 13 February 2009, Marco Martin wrote: Hi all, right now plasma enables argb visuals with that magin X11 code pasted in many places... since 4.5 now can handle it by setting Qt::WA_TranslucentBackground on the top level window we want transparent we can make it in a prettier way that would be nice. done, seems to work quite good, except for two things: the tooltips seems to insist that they don't want to be transparent the systemtray has garbage again with the raster graphicssystem (so i didn't dream it up) i'm not sure if that's the case also with the old method btw i really hope those two aren't insolvable issues, otherwise it would be necessary to return back.. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: suspend text and icon consistency
On Monday 16 February 2009 21:19:47 Jonathan Riddell wrote:
In 4.2 the suspend icons and text are inconsistent between battery
applet and kickoff.
http://www.kubuntu.org/~jriddell/tmp/logout1.png
http://www.kubuntu.org/~jriddell/tmp/logout2.png
I propose changing kickoff to use Sleep and Hibernate with the
subtext set to Suspend to Memory and Suspend to Disk
respectively. Also use system-suspend icon for Sleep to be consistent.
The icon fix is fine, the label fix as well. (Both IMO, which is hardly
surprising since I wrote the option you picked ;-)).
--- kdebase-workspace-4.2.0/plasma/applets/kickoff/core/leavemodel.cpp
2008-12-10 16:13:23.0 +
+++ kdebase-workspace-4.2.0/plasma/applets/kickoff/core/leavemodel.cpp
2009-02-16 19:27:44.0 +
@@ -74,13 +74,13 @@
item-setIcon(KIcon(system-suspend));
item-setData(i18n(Pause without logging out),
Kickoff::SubTitleRole);
} else if (basename == suspenddisk) {
-item-setText(i18n(Suspend to Disk));
+item-setText(i18n(Hibernate));
item-setIcon(KIcon(system-suspend-hibernate));
-item-setData(i18n(Pause without logging out),
Kickoff::SubTitleRole);
+item-setData(i18n(Suspend to Disk),
Kickoff::SubTitleRole);
} else if (basename == suspendram) {
-item-setText(i18n(Suspend to RAM));
-item-setIcon(KIcon(system-suspend-hibernate));
-item-setData(i18n(Pause without logging out),
Kickoff::SubTitleRole);
+item-setText(i18n(Sleep));
+item-setIcon(KIcon(system-suspend));
+item-setData(i18n(Suspend to Memory), Kickoff::SubTitleRole);
} else {
item-setText(basename);
item-setData(url, Kickoff::SubTitleRole);
--
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
Re: Fun with Akonadi Dataengine
On Monday 16 February 2009 19:42:03 David Baron wrote: On Monday 16 February 2009 19:08:03 Aaron J. Seigo wrote: On Sunday 15 February 2009, David Baron wrote: 1. The ContactCollection-# loads all the contacts but they are not necessarily accessible at this point. I might have to try hm; this sounds rather inefficient for large address books. perhaps it's a good idea to collect use cases for this part of the engine and build specifically for those rather than build something too general purpose; the engine doesn't need to be able to support building an entire address book application around it (that's not the point of engines), so defining what a widget should like to do with it is probably a good start point. It's a point. But I am dialing the phone. Here is how I do it now: 1. In init(), I start a QTimer with 1 second interval. If you need to use a timer here, I think something's wrong. You should be able to just connect to dataUpdated() for that collection and If it's necessary to use a timer, there's something wrong with the interface. It should be completely event-based, no? 2. At 1st timeout, I do the a query(ContactCollections) then if I find a suitable key, connectSource, i.e to ContentCollection-6. You can just do that in or from init(). Why use a timer here? 3. After that, I connectAllSources at 1 second intervals until dataUpdated gets called. At this point, I stop the QTimer and am now receiving the contacts. Using these, I assemble my phone book into a QListWIdget. You should query ContactCollections and then in dataUpdated(), you check if the source is Why in one-second intervals? Is it blocking for you otherwise? If you're unsure how to do it, you can look at lionmail.cpp. There, it should be async and pretty similar to what you want. Well, what exactly is it that you actually want? :D This works nicely in the background without delaying the panel/desktop and the GUI stays live. Using a QThread was my 1st try but the dataengine did not like that. The QTimer looks like a thread but is done differently so this plays. The alternative of writing a dataengine tailored to this type of task such as was done in a birthday plasmoid could be considered, not using Akonadi. Unless these background daemons are tactfully niced, I think folks may uninstall them. Nepomuk and all the Akonadi children take a large bite of CPU, especially after login. They may quiet down a lot later on (after everything is sync'ed?). Yeah, that is indeed a problem of all data-intensive services. It is also why it's all the more important to have display of data fully async, and not depending on complete initialization of all data on startup. -- 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
Re: New systemtray: beginnings and how to do
On Monday 16 February 2009, Aaron J. Seigo wrote: On Sunday 15 February 2009, Marco Martin wrote: this basic thing works fairly well by now, what is totally missing of course is the big part, the comunication infrastructure with the app (don't how to do this is going to be the big trick in all of this. the d-bus interaction is actually pretty simple, but preserving backwards compat will be interesting to accomplish. yes, and fall back at the proper cases, that is the most worrying part, yeah we have KSystemTrayIcon which IsA QSystemTrayIcon. so even if we implement the D-Bus protocol in KSystemTrayIcon, we'll always have a QSystemTrayIcon, and therefore a regular system tray icon, as well. ok, so we don't need a subclass of ksystemtrayicon, but something with roughly the same api, i'm going a bit blindly there because i still never looked at both KSystemTrayIcon and QSystemTrayIcon what we really want is an API that takes the various possible information (icon, name, tooltip, etc, etc) and internally decides whether or not to use the D-Bus route or to use a KSystemTrayIcon internally and provide the other fun bits (e.g. the tooltip) manually. so this seems to indicate that we probably want a new class that will eventually end up in libkdeui. it should have a name that doesn't include SystemTray in it, and it should be source compatible as much as possible with KSystemTrayIcon so that it can be used as a drop-in replacement or as close to a drop-in as possible. KNotificationIcon? meh. hmm, as a name wouldn't confuse a bit with dbus notification and galago things? so what would need to go in workspace would be the daemon and the protocol that's cool with me. for now, let's put the kded plugin in with the systemtray widget. when it gets accepted as an official KDE bit, we can move it somwhere else, though i think it should remain in workspace and only get started when a KDE desktop session is being started. ok, so tomorrow i'll move the daemon in workspace together the applet and include the systemtray plugin, so to recap as names we have: (that can't come up with ones i like for none of them) SystemTrayDaemon: the kded daemon DBusSystemTrayTask/DBusSystemTrayProtocol in the system tray applet (DBusNotificationTask was already there, so...) KNotificationIcon the client library we could come up with a cool name for the specification so we can stick with that everywhere, two random ideas TrayBus (the fancy rather meaningless one) NotificationIcon (the really (too much?) generic one) any nicer ideas? Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fun with Akonadi Dataengine
On Tuesday 17 February 2009 00:44:13 Sebastian Kügler wrote: On Monday 16 February 2009 19:42:03 David Baron wrote: On Monday 16 February 2009 19:08:03 Aaron J. Seigo wrote: On Sunday 15 February 2009, David Baron wrote: 1. The ContactCollection-# loads all the contacts but they are not necessarily accessible at this point. I might have to try hm; this sounds rather inefficient for large address books. perhaps it's a good idea to collect use cases for this part of the engine and build specifically for those rather than build something too general purpose; the engine doesn't need to be able to support building an entire address book application around it (that's not the point of engines), so defining what a widget should like to do with it is probably a good start point. It's a point. But I am dialing the phone. Here is how I do it now: 1. In init(), I start a QTimer with 1 second interval. If you need to use a timer here, I think something's wrong. You should be able to just connect to dataUpdated() for that collection and If it's necessary to use a timer, there's something wrong with the interface. It should be completely event-based, no? The problem I found is (maybe because ContactCollection-# loads other sources rather than its own data-hash) is that until all the individual contact sources have been loaded into the engine (shown on console messages if I am running in the plasmoidviewer), connectAllSources does nothing. It needs be repeated when sources are in fact available. I am not saying it SHOULD be this way but that it how I find it to be. 2. At 1st timeout, I do the a query(ContactCollections) then if I find a suitable key, connectSource, i.e to ContentCollection-6. You can just do that in or from init(). Why use a timer here? The panel on which the applet is nested delays coming up when I do it directly in init(). 3. After that, I connectAllSources at 1 second intervals until dataUpdated gets called. At this point, I stop the QTimer and am now receiving the contacts. Using these, I assemble my phone book into a QListWIdget. You should query ContactCollections and then in dataUpdated(), you check if the source is I query to get the ContactCollection-# key and then connect to that which initiates the load of all the Contac-# sources after a delay. Why in one-second intervals? Is it blocking for you otherwise? I could have used another interval. The point is that I am NOT blocking so everything plays naturally. If you're unsure how to do it, you can look at lionmail.cpp. There, it should be async and pretty similar to what you want. URL? Well, what exactly is it that you actually want? :D To build a phone number directory from the contacts. One contact may give me several entries. All easy by checking the keys. This works nicely in the background without delaying the panel/desktop and the GUI stays live. Using a QThread was my 1st try but the dataengine did not like that. The QTimer looks like a thread but is done differently so this plays. The alternative of writing a dataengine tailored to this type of task such as was done in a birthday plasmoid could be considered, not using Akonadi. Unless these background daemons are tactfully niced, I think folks may uninstall them. Nepomuk and all the Akonadi children take a large bite of CPU, especially after login. They may quiet down a lot later on (after everything is sync'ed?). Yeah, that is indeed a problem of all data-intensive services. It is also why it's all the more important to have display of data fully async, and not depending on complete initialization of all data on startup. The QTimer let me do exactly this (while a simple background thread did not). If there be a more correct way, easy enough to try it out :-) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
