Re: Ayatana notifications for Plasma
Sebastian Kügler wrote: >> Regarding implementing it as a separate applet: I don't think it would >> have been a good idea because you would have to either add a dumb icon >> to your panel so that you could run this system, or add an invisible >> applet (not handy for the user to manipulate). > > That's what you have the config option for. (it's the same in terms of > manipulation > right now). I don't understand what you mean. >> Keep in mind that the >> binary is started on demand, so it does not take any memory if you are >> not using it (assuming it would automatically stop itself after a while). > > Same goes for applets, dataengines... Can an applet unload itself from memory? What I meant with "stop itself after a while", was the notify-osd executable calling exit(). I believe your desktop would be a bit too clean if an applet called exit() :). >> The alternative of using a kded module could have been a good idea, but >> it would have required the creation of a kcm to configure the system. >> Such kcm would have had to tweak Plasma system tray settings behind its >> back, which could have been a problem to get on the fly changes. It >> would have at least needed to patch the applet to tell it to stop >> listening on dbus. > > You could just as well manipulate the kded module's config from the systray's > config > dialog. True, but in both cases it would have needed a patch. Offtopic: it's too bad Plasma does not have a DBus call to reload its config. Could be handy when going from one distro release to another (/me thinks about the switch between knetworkmanager the executable and knetworkmanager the plasmoid). I'll try to implement this if I find time. Aurelien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
Sebastian Kügler wrote: > On Monday 28 September 2009 17:01:34 Roderick B. Greening wrote: >> I wonder if it would be worthwhile for Sebastian and Aurelien to get >> together and chat offline. I see some opportunity for clarification in a >> one-on-one via irc, etc. > > Not sure, it sounds like you see personal issues between me and Aurelien. I > don't. > (And I hope Aurelien doesn't either.) I certainly don't have any personal issue with you or any other Plasma dev. > Not that I like the current situation with > patches that won't be accepted because of different design direction, but to > me > there's a fundamental difference between Aurelien as a KDE hacker and > Aurelien as an > Ayatana ambassador. Heh, sometimes I feel like I am suffering from multiple personality disorder :) >> I believe we had some great discussions at UDS and Sebastian was awesome >> at helping provide guidance to Aurelien at the time. However, it's >> possible that over the last 6 months we may have gotten a little off track >> and we have some opportunity to move this forward in a way desirable to >> all parties. Or at least, if we cannot make major changes for this >> release, we can try to minimize any confusion through direction from >> Sebastion, and look towards doing this differently via USD Lucid and 10.04 >> release in 6 months time... > > At UDS, we've discussed doing things in a way that KDE can benefit from work > being > done by Canonical. I would have hoped that this way, we get things like > queueing, > prioritizing of notifications and improved layout / display into Plasma > upstream (and > there's surely room for that). That hasn't happened yet, and I hope it still > will. I could probably have spent time trying to get some of the concepts you mentioned integrated to Plasma. I confess I didn't try because I was afraid all of this would be perceived as a sneaky way to move KDE notifications toward Ayatana notifications. Instead I opted for presenting our work as "Here is what we did. We believe there are good things in it for KDE. We know you do not agree with some of the core concepts. We would just like you to give it a try and see if you find some ideas interesting for Plasma" Aurelien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Remote widgets, the next steps
Hi everyone, I've studied the code of the Remote Widgets implementation and I'd like to discuss some internals. Most of the following (if not all) could be already known, anyway. If I understood the implementation correctly, the parameters for operation calls to a remote Plasma::Service are serialized as a byte array, which is then deserialized on the other side. This works just fine between a Plasma instance and another Plasma instance, but won't work with other technologies (because the message isn't properly structured, so for example a SOAP service would just see a stream of bytes inside the SOAP body instead of an XML tree of parameters). Moreover, if I wanted to use a Jolie script to implement a complex Plasma::Service that, i.e., implements a peer to peer multiparty game/chat/something I couldn't do it for the same reasons. What needs to be done is to create the message by reflecting the parameters structure, so one child node for each parameter. Another problem I've seen is that the remote widgets framework makes use of special operations like startOperationCall, and others for checking access control. There is nothing wrong with this, but then for performing "normal" operation calls you are passing the operation name in the message data, not in the message headers. This breaks interoperability with everything because you've got two levels of operations, the special one and the normal one, whereas services have just one. A quick solution for this would be to make these operation names standard and reserved for Plasma::Service, or (better) to hide them behind a specific resource name (e.g. "PlasmaControl"). Last, the current implementation is just using tcp sockets and sodep, but I think that's obviously known. :-) Cheers, Fabrizio. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Full Konqueror History Runner
Hi Jon, On Tuesday 29 September 2009 00:15:34 Jon de Andres wrote: > The browserhistory runner in kdeplasma-addons only searchs in the typed > history in konqueror, stored in KDEDIR/share/conf/konq_history. Konqueror > uses its own lib to use the "full" history with title and extra info. This > runner do use the KonqHistoryProvider to search in this history, stored in > KDEDIR/share/apps/konqueror/konq_history. I've talked with dfaure about that about a year ago, he seemed positive towards making this history part of the lib public API. You need to talk to him though to get it done. > Probably this runner is used with the rekonq browser but we think that it > could be useful for KDE users so it searches in the title and url as we > can see in other browsers, firefox, chromium, etc... > > In kdebase/apps/lib/konq lives the lib used by konqueror and this runner, > in this folder there are some headers, konq_history*.h that are needed to > be installed. So the CMakeLists.txt should be fixed. Also, the runner should completely replace the browserhistory runner, both in our sources but also its pluginnames. There shouldn't be two runners, and users who have configured the "old" one, should get the new one automatically. In the code, you have this TODO to connect signals to update. That's actually a pretty important thing (the history changes much more often than you restart KRunner). So with this added, and David having made the necessary changes to libkonq, it can go in. You can test your runner by only enabling that one, and then see if you still get crashes. Maybe konqhistory isn't thread-safe? The code looks good to me, otherwise. Welcome to Plasma development, btw :) -- 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: Ayatana notifications for Plasma
On Tuesday 29 September 2009 10:34:19 Aurélien Gâteau wrote: > Sebastian Kügler wrote: > >> Regarding implementing it as a separate applet: I don't think it would > >> have been a good idea because you would have to either add a dumb icon > >> to your panel so that you could run this system, or add an invisible > >> applet (not handy for the user to manipulate). > > > > > > That's what you have the config option for. (it's the same in terms of > > manipulation right now). > > I don't understand what you mean. You could add the invisible applet programmatically if the config option in the systray is set, and remove it in the same way. > >> Keep in mind that the > >> binary is started on demand, so it does not take any memory if you are > >> not using it (assuming it would automatically stop itself after a > >> while). > > > > > > Same goes for applets, dataengines... > > Can an applet unload itself from memory? What I meant with "stop itself > after a while", was the notify-osd executable calling exit(). I believe > your desktop would be a bit too clean if an applet called exit() :). Hehe, "fluxbox mode". ;-) AFAIK, applets are unloaded from memory when you remove them from the containment. (Though the same version is reloaded, so I guess there's some kind of caching.) -- 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: Ayatana notifications for Plasma
Hey Aurélien, On Tuesday 29 September 2009 10:52:55 Aurélien Gâteau wrote: > Sebastian Kügler wrote: > > On Monday 28 September 2009 17:01:34 Roderick B. Greening wrote: > >> I wonder if it would be worthwhile for Sebastian and Aurelien to get > >> together and chat offline. I see some opportunity for clarification in > >> a one-on-one via irc, etc. > > > > Not sure, it sounds like you see personal issues between me and Aurelien. > > I don't. (And I hope Aurelien doesn't either.) > > I certainly don't have any personal issue with you or any other Plasma dev. Good to have this confirmed. Hugs :) > > Not that I like the current situation with > > patches that won't be accepted because of different design direction, but > > to me there's a fundamental difference between Aurelien as a KDE hacker > > and Aurelien as an Ayatana ambassador. > > Heh, sometimes I feel like I am suffering from multiple personality > disorder :) I can very well understand that. :/ > >> I believe we had some great discussions at UDS and Sebastian was awesome > >> at helping provide guidance to Aurelien at the time. However, it's > >> possible that over the last 6 months we may have gotten a little off > >> track and we have some opportunity to move this forward in a way > >> desirable to all parties. Or at least, if we cannot make major changes > >> for this release, we can try to minimize any confusion through direction > >> from Sebastion, and look towards doing this differently via USD Lucid > >> and 10.04 release in 6 months time... > > > > At UDS, we've discussed doing things in a way that KDE can benefit from > > work being done by Canonical. I would have hoped that this way, we get > > things like queueing, prioritizing of notifications and improved layout / > > display into Plasma upstream (and there's surely room for that). That > > hasn't happened yet, and I hope it still will. > > I could probably have spent time trying to get some of the concepts you > mentioned integrated to Plasma. I confess I didn't try because I was > afraid all of this would be perceived as a sneaky way to move KDE > notifications toward Ayatana notifications. I think that would actually be a good way forward. Most of the ideas the Ayatana team has WRT notifications are no-brainers IMO. (Streamlined display / layout of the notifications, the stuff that determines how long to show one (current Plasma still doesn't get this right, I often miss the second half of my quassel notifications, queueing (we have very bad bugs when an app goes nuts and stacks 20 notifications on top of each other). All things that would greatly benefit Plasma without diverting from its design concepts. > Instead I opted for presenting our work as "Here is what we did. We > believe there are good things in it for KDE. We know you do not agree > with some of the core concepts. We would just like you to give it a try > and see if you find some ideas interesting for Plasma" -- 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: Remote widgets, the next steps
On Tuesday 29 September 2009 10:53:41 Fabrizio Montesi wrote: > Hi everyone, > > I've studied the code of the Remote Widgets implementation and I'd like to > discuss some internals. Most of the following (if not all) could be already > known, anyway. Cool, I could use some more peer review :) > If I understood the implementation correctly, the parameters for operation > calls to a remote Plasma::Service are serialized as a byte array, which is > then deserialized on the other side. This works just fine between a Plasma > instance and another Plasma instance, but won't work with other > technologies (because the message isn't properly structured, so for > example a SOAP service would just see a stream of bytes inside the SOAP > body instead of an XML tree of parameters). Moreover, if I wanted to use a > Jolie script to implement a complex Plasma::Service that, i.e., implements > a peer to peer multiparty game/chat/something I couldn't do it for the > same reasons. What needs to be done is to create the message by reflecting > the parameters structure, so one child node for each parameter. I never really considered the case of implementing a native Plasma::Services in jolie script since that could get a bit complicated anyway, considering the access control/message signing, plus additional overhead like the fact that we should send over valid kconfigxml describing the parameters. Also, publishing a Plasma::Service using a different technology (like as a SOAP service) would be tricky since the access/control and message singing would make this SOAP service quite complicated to use I mostly considered the case of accessing something like a SOAP service from plasma as something seperate, where we could leverage jolie, but need to use a different approach. In that case we would want some wsdl to jolie converter for example, since it would be a pain if a developer that just wants to use a web service needs to do that by hand. And a wsdl to configxml convertor, since Plasma::Service need to provide valid configxml. And a seperate Service implementation that doesn't do any access control stuff and just calls operations on the service, but this would be a relatively small and trivial class to make. I could at some point add a function to access manager to access any non native plasma service through a Plasma::Service. If/when (?) there are converters to help us with the wsdl, it should be very easy ... both to implement, and to use. The problem of streaming the parameters is not entirely solvable. The parameters passed to any Plasma::Service are a QVariantMap. I could obviously put every element of the map as seperate child node, but they're still QVariants, and those will need to be serialized/deserialized. I could use the 3 native sodep types: string integer and double directly, but this doesn't solve the issue for all the types out there, just for some of the most common ones. So in short: accessing native plasma:services from something other then plasma is tricky because of the access control, accessing something not native plasma::service from plasma would be easy to add support for, depending on the state of wsdl -> joliescript and wsdl/joliescript -> configxml converters. > Another problem I've seen is that the remote widgets framework makes use of > special operations like startOperationCall, and others for checking access > control. There is nothing wrong with this, but then for performing "normal" > operation calls you are passing the operation name in the message data, not > in the message headers. This breaks interoperability with everything > because you've got two levels of operations, the special one and the > normal one, whereas services have just one. A quick solution for this > would be to make these operation names standard and reserved for > Plasma::Service, or (better) to hide them behind a specific resource name > (e.g. "PlasmaControl"). Yeah, I suppose I could put the actual operations in the operation name instead of the startOperationCall parameters. > Last, the current implementation is just using tcp sockets and sodep, but I > think that's obviously known. :-) hehe, yeah it is :p > Cheers, > Fabrizio. > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: taskmanager library: Manual Sorting Fix
> On 2009-09-04 20:16:52, Aaron Seigo wrote: > > this results in a "leak" in that every window ever created will have an > > item that stays forever, no? shouldn't it only keep track of winIds that > > still exist, and do so in the manual grouping strategy? > > Christian Mollekopf wrote: > Yes this would result in a "leak" (as long the groupmanager instance > exists). > I just noticed that also manual grouping is broken since it also relies > on the pointers to remain. > > I will work on a new patch where manual grouping and sorting keep track > of the windows/groups by winIds. > > Aaron Seigo wrote: > any progress on this? yes, but since i'm rather busy atm. it takes some more time. I'll try to finish it until next week. Cheers - Christian --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1526/#review2247 --- On 2009-09-28 20:26:09, Christian Mollekopf wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/1526/ > --- > > (Updated 2009-09-28 20:26:09) > > > Review request for Plasma, Aaron Seigo and Marco Martin. > > > Summary > --- > > this fixes the manual sorting strategy, which is broken atm if the desktop is > changed. > > Since the manual sorting strategy relies on AbstractGroupableItem pointer not > to change, we cannot remove it from the bookkeeping in case it returns (after > a desktop change for instance). > I don't know if this is acceptable because this results in the item never > being removed from the itemList until the groupmanager instance is deleted > (lifetime of the applet which created the instance). > > Another option would be to identify tasks and groups by WId, which is a bit > more complicated, but if you think it would be better/cleaner, i could supply > a patch. > > > This addresses bug 200255. > https://bugs.kde.org/show_bug.cgi?id=200255 > > > Diffs > - > > /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1018615 > > Diff: http://reviewboard.kde.org/r/1526/diff > > > Testing > --- > > Tried it, works. > > > Thanks, > > Christian > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Remote widgets, the next steps
On Tue, Sep 29, 2009 at 4:30 PM, Rob Scheepmaker < r.scheepma...@student.utwente.nl> wrote: > I never really considered the case of implementing a native > Plasma::Services > in jolie script since that could get a bit complicated anyway, considering > the > access control/message signing, plus additional overhead like the fact that > we > should send over valid kconfigxml describing the parameters. Message signing and access control shouldn't be too hard to code: I'd like to write some sort of standard Jolie library for handling Plasma services and to distribute it with Jolie. Could you provide the workflow specs? (describing them here is fine) We had some work on generating kconfigxml automatically from Jolie interface files, see http://jolie.svn.sourceforge.net/viewvc/jolie/trunk/tools/jolie2plasma/ Only problems are w.r.t. certain data types (which I see you already know by your explanation in the following). Also, publishing > a Plasma::Service using a different technology (like as a SOAP service) > would > be tricky since the access/control and message singing would make this SOAP > service quite complicated to use > Well, a lot of SOAP services in the industry there have very complicated specifications on how to access them. I don't think anybody would kick us for some security parameters that need to be added to messages. :-) > I mostly considered the case of accessing something like a SOAP service > from > plasma as something seperate, where we could leverage jolie, but need to > use a > different approach. In that case we would want some wsdl to jolie converter > for example, since it would be a pain if a developer that just wants to use > a > web service needs to do that by hand. And a wsdl to configxml convertor, > since > Plasma::Service need to provide valid configxml. And a seperate Service > implementation that doesn't do any access control stuff and just calls > operations on the service, but this would be a relatively small and trivial > class to make. I could at some point add a function to access manager to > access any non native plasma service through a Plasma::Service. If/when (?) > there are converters to help us with the wsdl, it should be very easy ... > both > to implement, and to use. > This is true, but if we provide a way to use the loadEmbeddedJolieService in MetaService so to load custom Jolie scripts and see them as a Plasma::Service I can at least access SOAP services by making a Jolie script. In a lot of cases making a Jolie script for accessing a SOAP service is easy, and there are hard cases in which I would like to use a Jolie script even if I had all the automatic converters because there could be a necessity for some additional orchestration (security protocols, handshaking etc...) which Plasma doesn't support. For the future tools, we would just need a WSDL2Jolie converter, since we already have Jolie2Plasma (which converts a Jolie interface to a kconfigxml service descriptor). > The problem of streaming the parameters is not entirely solvable. The > parameters passed to any Plasma::Service are a QVariantMap. I could > obviously > put every element of the map as seperate child node, but they're still > QVariants, and those will need to be serialized/deserialized. > I could use the 3 native sodep types: string integer and double directly, > but > this doesn't solve the issue for all the types out there, just for some of > the > most common ones. > I suggest we go this way: - if a parameter can be cast to a sodep data type, convert it; - otherwise, serialize it. Nevertheless, maintain the separate child node structure. This way we already have a mostly working implementation (I imagine most parameters in Plasma are integers, strings, doubles and booleans?) and I can start adding sodep data types appropriately as we see necessary. > > > Another problem I've seen is that the remote widgets framework makes use > of > > special operations like startOperationCall, and others for checking > access > > control. There is nothing wrong with this, but then for performing > "normal" > > operation calls you are passing the operation name in the message data, > not > > in the message headers. This breaks interoperability with everything > > because you've got two levels of operations, the special one and the > > normal one, whereas services have just one. A quick solution for this > > would be to make these operation names standard and reserved for > > Plasma::Service, or (better) to hide them behind a specific resource > name > > (e.g. "PlasmaControl"). > > Yeah, I suppose I could put the actual operations in the operation name > instead of the startOperationCall parameters. > That would already be a great step forward, yes. What I'd like to get working first is to, at least, be able to implement local (yes, local) services in Jolie. By doing so I would already gain a lot of power, for example a plasmoid could load this Jolie service using loadEmbeddedJolieS
Re: Ayatana notifications for Plasma
On September 29, 2009, Aurélien Gâteau wrote: > >> Keep in mind that the > >> binary is started on demand, so it does not take any memory if you are > >> not using it (assuming it would automatically stop itself after a > >> while). > > > > Same goes for applets, dataengines... > > Can an applet unload itself from memory? What I meant with "stop itself > after a while", was the notify-osd executable calling exit(). I believe > your desktop would be a bit too clean if an applet called exit() :). the overhead of a running applet should be negligable unless it's doing something rather wrong. so while you can certainly have an applet remove itself you'd also need a way to re-create it, position it properly, make sure any user adjustments previously made to it remain, etc. then there'd be the overhead of any re- layouts this triggers in the containment, etc. for the memory savings that would result, this probably isn't worth it. > >> The alternative of using a kded module could have been a good idea, but > >> it would have required the creation of a kcm to configure the system. > >> Such kcm would have had to tweak Plasma system tray settings behind its > >> back, which could have been a problem to get on the fly changes. It > >> would have at least needed to patch the applet to tell it to stop > >> listening on dbus. > > > > You could just as well manipulate the kded module's config from the > > systray's config dialog. > > True, but in both cases it would have needed a patch. > Offtopic: it's too bad Plasma does not have a DBus call to reload its > config. you really don't want to do that; this implies something other than plasma- desktop has touched the config file(s) but plasma-desktop may have written over it since then. due to limitations in kconfig this whole "change the config file on disk behind the app's back" is a non-starter. > Could be handy when going from one distro release to another > (/me thinks about the switch between knetworkmanager the executable and > knetworkmanager the plasmoid). I'll try to implement this if I find time. this is why i wrote the QScript based system for controlling plasma-desktop. it supports update scripts. there's a file in workspace/plasma/design/ about it and i've blogged about it as well. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Ported KTimeTracker to KNotification
> > >> On 2009-09-29 05:32:23, Thorsten Staerk wrote: >> > I committed the change, see >> http://websvn.kde.org/?view=revision&revision=1029142. Where can I set >> this to completed? > > there is somewhere a button here that lets you set this to submitted. > Do you mean the "ship it" tag? I did set that. > > - Beat > > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/1653/#review2495 > --- > > > On 2009-09-19 20:16:41, Davide Bettio wrote: >> >> --- >> This is an automatically generated e-mail. To reply, visit: >> http://reviewboard.kde.org/r/1653/ >> --- >> >> (Updated 2009-09-19 20:16:41) >> >> >> Review request for KDE PIM and Plasma. >> >> >> Summary >> --- >> >> KTimeTracker has been ported to KNotificationItem but I still have few >> issues that I've corrected with #if 0. >> It's not really clear to me how the notification works when KTimeTracker >> is a KPart. >> Anyway please don't use XPM pixmaps, use icons. >> >> >> Diffs >> - >> >> /trunk/KDE/kdepim/ktimetracker/ktimetrackerpart.cpp 1024122 >> /trunk/KDE/kdepim/ktimetracker/tray.h 1024122 >> /trunk/KDE/kdepim/ktimetracker/tray.cpp 1024122 >> >> Diff: http://reviewboard.kde.org/r/1653/diff >> >> >> Testing >> --- >> >> >> Thanks, >> >> Davide >> >> > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Ported KTimeTracker to KNotification
On September 29, 2009, thors...@staerk.de wrote: > >> On 2009-09-29 05:32:23, Thorsten Staerk wrote: > >> > I committed the change, see > >> > >> http://websvn.kde.org/?view=revision&revision=1029142. Where can I set > >> this to completed? > > > > there is somewhere a button here that lets you set this to submitted. > > Do you mean the "ship it" tag? I did set that. no, there's a Close entry in the "toolbar" that also contains "View Diff", "Review", etc. web app usability, what's that? ;) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Kde-pim] Review Request: Ported KTimeTracker to KNotification
On Tuesday 29 September 2009, thors...@staerk.de wrote: > >> On 2009-09-29 05:32:23, Thorsten Staerk wrote: > >> > I committed the change, see > >> > >> http://websvn.kde.org/?view=revision&revision=1029142. Where can I > >> set this to completed? > > > > there is somewhere a button here that lets you set this to > > submitted. > > Do you mean the "ship it" tag? I did set that. No. AFAIK only the original submitter of the review request can close it. Regards, Ingo > > --- > > This is an automatically generated e-mail. To reply, visit: > > http://reviewboard.kde.org/r/1653/#review2495 > > --- > > > > On 2009-09-19 20:16:41, Davide Bettio wrote: > >> --- > >> This is an automatically generated e-mail. To reply, visit: > >> http://reviewboard.kde.org/r/1653/ > >> --- > >> > >> (Updated 2009-09-19 20:16:41) > >> > >> > >> Review request for KDE PIM and Plasma. > >> > >> > >> Summary > >> --- > >> > >> KTimeTracker has been ported to KNotificationItem but I still have > >> few issues that I've corrected with #if 0. > >> It's not really clear to me how the notification works when > >> KTimeTracker is a KPart. > >> Anyway please don't use XPM pixmaps, use icons. > >> > >> > >> Diffs > >> - > >> > >> /trunk/KDE/kdepim/ktimetracker/ktimetrackerpart.cpp 1024122 > >> /trunk/KDE/kdepim/ktimetracker/tray.h 1024122 > >> /trunk/KDE/kdepim/ktimetracker/tray.cpp 1024122 > >> > >> Diff: http://reviewboard.kde.org/r/1653/diff > >> > >> > >> Testing > >> --- > >> > >> > >> Thanks, > >> > >> Davide > > ___ > KDE PIM mailing list kde-...@kde.org > https://mail.kde.org/mailman/listinfo/kde-pim > KDE PIM home page at http://pim.kde.org/ 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: [Kde-pim] Review Request: Ported KTimeTracker to KNotification
On September 29, 2009, Ingo Klöcker wrote: > On Tuesday 29 September 2009, thors...@staerk.de wrote: > > >> On 2009-09-29 05:32:23, Thorsten Staerk wrote: > > >> > I committed the change, see > > >> > > >> http://websvn.kde.org/?view=revision&revision=1029142. Where can I > > >> set this to completed? > > > > > > there is somewhere a button here that lets you set this to > > > submitted. > > > > Do you mean the "ship it" tag? I did set that. > > No. AFAIK only the original submitter of the review request can close > it. or a project admin. i am such an admin, and you can get others given this privilege by making a request to the sys admins. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Forecast-only weather ion
Hello everyone, I am currently developing a Weather Ion for the German wetter.com weather data provider to improve the station coverage for Germany, Austria and Switzerland. Unfortunately, wetter.com only provides forecast data through its free web service API, so the Ion actually has no access to current observation data to provide to the Weather Plasmoid. AFAICS this results in some ugly rendering glitches in the Plasmoid such as a large question mark document being displayed instead of the current weather condition. Is building a Ion that does not supply observation data, but only forecast data, supported? Is there a way to convince the Weather Plasmoid to skip displaying the observation data (instead of displaying "N/A" indicators and icons)? Thanks, Thilo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: taskmanager library: Manual Sorting Fix
> On 2009-09-04 20:16:52, Aaron Seigo wrote: > > this results in a "leak" in that every window ever created will have an > > item that stays forever, no? shouldn't it only keep track of winIds that > > still exist, and do so in the manual grouping strategy? > > Christian Mollekopf wrote: > Yes this would result in a "leak" (as long the groupmanager instance > exists). > I just noticed that also manual grouping is broken since it also relies > on the pointers to remain. > > I will work on a new patch where manual grouping and sorting keep track > of the windows/groups by winIds. > > Aaron Seigo wrote: > any progress on this? > > Christian Mollekopf wrote: > yes, but since i'm rather busy atm. it takes some more time. > I'll try to finish it until next week. > > Cheers Out of curiosity, will this change affect how new applications are displayed/handled in the taskbar? Ideally they'd just appear (and stay unless moved) to the right of any extant tasks. If not, can I ask a big favour ... ? ;) - jedd --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1526/#review2247 --- On 2009-09-28 20:26:09, Christian Mollekopf wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/1526/ > --- > > (Updated 2009-09-28 20:26:09) > > > Review request for Plasma, Aaron Seigo and Marco Martin. > > > Summary > --- > > this fixes the manual sorting strategy, which is broken atm if the desktop is > changed. > > Since the manual sorting strategy relies on AbstractGroupableItem pointer not > to change, we cannot remove it from the bookkeeping in case it returns (after > a desktop change for instance). > I don't know if this is acceptable because this results in the item never > being removed from the itemList until the groupmanager instance is deleted > (lifetime of the applet which created the instance). > > Another option would be to identify tasks and groups by WId, which is a bit > more complicated, but if you think it would be better/cleaner, i could supply > a patch. > > > This addresses bug 200255. > https://bugs.kde.org/show_bug.cgi?id=200255 > > > Diffs > - > > /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1018615 > > Diff: http://reviewboard.kde.org/r/1526/diff > > > Testing > --- > > Tried it, works. > > > Thanks, > > Christian > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
