Re: today's meeting notes
Oh, fsck, meeting was yesterday and not today... sorry... On 13 September 2010 00:13, Aaron J. Seigo ase...@kde.org wrote: hi all.. thanks to everyone who attended, here are notes from today's meeting on irc: http://community.kde.org/Plasma/20100912 -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: export the lib behind the widget explorer
On Sunday 12 September 2010, Giulio Camuffo wrote: I've hacked a bit with it and i saw that there are actually only two classes needed to make an interface like the widget explorer: AbstractIcon and AbstractIconList. Can we make those two public? Giulio i think you should stick with a ScrollWidget with an horizontal lyout of iconwidgets in it (or even copying pieces of the widget explorer) it's a bit of duplicate code but better than exporting something that could be soon-to-be-thrown-away Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: today's meeting notes
On Monday 13 September 2010, Aaron J. Seigo wrote: hi all.. thanks to everyone who attended, here are notes from today's meeting on irc: http://community.kde.org/Plasma/20100912 ok, thanks a lot, and sorry aain to not be able to be there. I have some points to make/questions to ask on the points highlighted there: * Plasma Mobile: - agree on the big work needed on the system tray, hope Yuen can still work on it, i will help tough - agree on extragear as location - activity switching must be bade way prettier code wise. at the moment there is too much hardcoded stuff for my pleasing, will take a look - with konact mobile... yes, i feel potentilly there is a quite big amount of duplication, honestly didn't had the energy to ctually check tough :) * QtComponents/ QML bindings - we need a timeframe for QtComponents, but i guess it will pass a quite long time before it makes it in a qt release - i think that for this reason bindings for the plasma widgets are still needed, at worst the plasma widgets could get replaced by qml counterparts with the exact set of properties - i would still like them to make it for 4.6, big issues remaining are the use of a private qt class for dataengines (this really makes me cry) and i18n (did kontact mobile solved that?) support for QIcons/KIcons would be nice as well * Activities - i still have to understand if i really want activities on plasma netbook/mobile or if containments are enough for the job * Classroom - still didn't get involved too much in tat one, one thing i can think of it is improved remote widgets (and maybe a way to have remote dataengines on local applets, maybe mixed with local dataengines) could be helpful there, for instance the calendar dataengine example in the wiki page. Could be post 4.6 material at this point tough Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: today's meeting notes
A Segunda, 13 de Setembro de 2010 09:45:38 Marco Martin você escreveu: On Monday 13 September 2010, Aaron J. Seigo wrote: hi all.. thanks to everyone who attended, here are notes from today's meeting on irc: http://community.kde.org/Plasma/20100912 ok, thanks a lot, and sorry aain to not be able to be there. I make Marco words mine. I have some points to make/questions to ask on the points highlighted there: * Plasma Mobile: - agree on the big work needed on the system tray, hope Yuen can still work on it, i will help tough - agree on extragear as location - activity switching must be bade way prettier code wise. at the moment there is too much hardcoded stuff for my pleasing, will take a look - with konact mobile... yes, i feel potentilly there is a quite big amount of duplication, honestly didn't had the energy to ctually check tough :) Ben working with Artur in some things in kontact-mobile (main reson i was not able to do much kde work latly was kontact mobile), good news are that I think I have now a good basis for a tooklit style, (butons, input areas, toglebuton etc) that fits the dpi of mobiles, its a bit office serius like but it works. * QtComponents/ QML bindings - we need a timeframe for QtComponents, but i guess it will pass a quite long time before it makes it in a qt release - i think that for this reason bindings for the plasma widgets are still needed, at worst the plasma widgets could get replaced by qml counterparts with the exact set of properties - i would still like them to make it for 4.6, big issues remaining are the use of a private qt class for dataengines (this really makes me cry) and i18n (did kontact mobile solved that?) support for QIcons/KIcons would be nice as well * Activities - i still have to understand if i really want activities on plasma netbook/mobile or if containments are enough for the job * Classroom - still didn't get involved too much in tat one, one thing i can think of it is improved remote widgets (and maybe a way to have remote dataengines on local applets, maybe mixed with local dataengines) could be helpful there, for instance the calendar dataengine example in the wiki page. Could be post 4.6 material at this point tough failing big time here must find some free time, to atleast port my presentation at tokamac here. had some conversations with a study group of this area here, they seam interested in doing reviews. other random notes#, will make some adjustments to air style in the taskbar hope to do a new splashscreen and kdm style Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Nuno Pinheiro | nuno.pinhe...@kdab.com | UI Designer Klarälvdalens Datakonsult AB, a KDAB Group company KDAB - Qt Experts - Platform-independent software solutions ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: today's meeting notes
Quoting Marco Martin notm...@gmail.com: * QtComponents/ QML bindings - we need a timeframe for QtComponents, but i guess it will pass a quite long time before it makes it in a qt release - i think that for this reason bindings for the plasma widgets are still needed, at worst the plasma widgets could get replaced by qml counterparts with the exact set of properties We need to talk about this during the mobile sprint :) The conclusions that are coming out from qt-components are showing that it's not worth it the bindings of the *widgets* (the other stuff I'm sure it's worth it - also to enable 'QML plasmoids'). Writing a QML version of our widgets would be easier and faster, and we would just need a bridge between them and our theming stuff. Anyway, we can talk more about this on IRC and at the sprint :) - i would still like them to make it for 4.6, big issues remaining are the use of a private qt class for dataengines (this really makes me cry) and i18n (did kontact mobile solved that?) support for QIcons/KIcons would be nice as well Yep, Kontact Mobile solved this issues providing a bridge between the i18n() functions and also for the KIcon loading. It would be nice to reuse code. Otherwise it would be simple to do the same thing. Cheers! Artur --- ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: today's meeting notes
On Monday 13 September 2010, Artur de Souza wrote: Quoting Marco Martin notm...@gmail.com: * QtComponents/ QML bindings - we need a timeframe for QtComponents, but i guess it will pass a quite long time before it makes it in a qt release - i think that for this reason bindings for the plasma widgets are still needed, at worst the plasma widgets could get replaced by qml counterparts with the exact set of properties We need to talk about this during the mobile sprint :) The conclusions that are coming out from qt-components are showing that it's not worth it the bindings of the *widgets* (the other stuff I'm sure it's worth it - also to enable 'QML plasmoids'). Writing a QML version of our widgets would be easier and faster, and we would just need a bridge well, not really faster, since the binding of the widgets is exactly the only part that right now is finished and working perfectly. the problem as usual, is the layouting, bad interaction between the qgw based ones and qdi based ones, but at least is possible to obtain decent results using only, or almost only qgw based ones (i still fear the lack of a real layout system and size hints is going to bite really hard, especially on non- mobile) between them and our theming stuff. Anyway, we can talk more about this on IRC and at the sprint :) would probably just be needed a qdi subclass that can draw svg and framesvg, to be used in place of the rather ugly BorderImage. Theme colors are already binded - i would still like them to make it for 4.6, big issues remaining are the use of a private qt class for dataengines (this really makes me cry) and i18n (did kontact mobile solved that?) support for QIcons/KIcons would be nice as well Yep, Kontact Mobile solved this issues providing a bridge between the i18n() functions and also for the KIcon loading. It would be nice to reuse code. Otherwise it would be simple to do the same thing. yes, i would like to see kdelibs related bindings in kdelibs itself some day Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: today's meeting notes
Quoting Marco Martin notm...@gmail.com: well, not really faster, since the binding of the widgets is exactly the only part that right now is finished and working perfectly. the problem as usual, is the layouting, bad interaction between the qgw based ones and qdi based ones, but at least is possible to obtain decent results using only, or almost only qgw based ones (i still fear the lack of a real layout system and size hints is going to bite really hard, especially on non- mobile) Yes, layouting and a lot of other things that are not working well with qgw. Alexis did a really amazing job on this when he was working with QML but this is no longer maintained and keeping the hope that it's going to work is just false hope unfortunately :(. The problem with creating qdi based ones is that we can suffer of the proxy-proxy problem. The KDE-pim guys tried this and it just made things worse. To properly do this you almost have to duplicate what qgraphicsproxywidget does. So, it's really easier to just change the way we do widgets. It has been some months now that we tried different approaches and going a step back will allow us to go two further later, would probably just be needed a qdi subclass that can draw svg and framesvg, to be used in place of the rather ugly BorderImage. Theme colors are already binded This may be needed, but I thought that svg was supported on qml already... Cheers, --- ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Launchersupport for the tasks-applet
So my question is: Is anyone here interested in implementing it or maybe already doing so? i haven't started doing so, and i don't know of anyone who has. so, do you plan to do so? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: today's meeting notes
On Monday 13 September 2010, Aaron J. Seigo wrote: hi all.. thanks to everyone who attended, here are notes from today's meeting on irc: http://community.kde.org/Plasma/20100912 another thing i did forgot to add before: i'll have to finish the dataengine caching gsoc (also there, i hope brian will reappear some day, bah) if there is enough of akonadi in kdesupport, i'll finish that backend and put it in libplasma, otherwise it could become a plugin in workspace and the kdelibs mplementation could use sqlite perhaps (kconfig is really too cow for this) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: today's meeting notes
On Monday 13 September 2010, Artur de Souza wrote: Quoting Marco Martin notm...@gmail.com: well, not really faster, since the binding of the widgets is exactly the only part that right now is finished and working perfectly. the problem as usual, is the layouting, bad interaction between the qgw based ones and qdi based ones, but at least is possible to obtain decent results using only, or almost only qgw based ones (i still fear the lack of a real layout system and size hints is going to bite really hard, especially on non- mobile) Yes, layouting and a lot of other things that are not working well with qgw. Alexis did a really amazing job on this when he was working with QML but this is no longer maintained and keeping the hope that it's going to work is just false hope unfortunately :(. yes, the binding for layouts is in plasma sources directly. now i'm not sure if it's less painful using qgws with the qml anchors (yes, it does work, the root element has to have an hardcoded size tough) or relying on the layout bindings fork, but, even if our widget are going to be redone in the future (yes i know what will happen to qgraphicsview) redoing it right now means: - it's not going to be done for 4.6 (or even 4.7 or 4.8) - while could be almost perfect(tm) for the mobile case it's not going to be good enough for the desktop, because they are going to behave slightly different from the other widgets, even if they are mimicking the other ones. for instance text areas won't have context menus (i don't think it's possible at all in qml?) pushbuttons won't have the exact same behaviour and capabilites, to reimplement the pushbutton/toggebutton/toolbutton/button with menu is going to be a big amount of work. now, maybe when qtcomponents will be ready it could be decided to just use those widgets, again if they will be good enough for the desktop. Or alternatively we can also decide that we really need to wait for them ad delay the complete bindings at this point, but wouldn't seem a particularly wise move for me, also because would basically mean plasma mobile not happening. until then, a solution already is in there, judging from a couple of pretty complex uis i did with it, works quite good, so i don't much see the point of all of this discussion, because the real problem is one and completely unrelated: the use of the private class for dataengine bindings. The problem with creating qdi based ones is that we can suffer of the proxy-proxy problem. The KDE-pim guys tried this and it just made things worse. To properly do this you almost have to duplicate what qgraphicsproxywidget does. So, it's really easier to just change the way we do widgets. It has been some months now that we tried different approaches and going a step back will allow us to go two further later, would probably just be needed a qdi subclass that can draw svg and framesvg, to be used in place of the rather ugly BorderImage. Theme colors are already binded This may be needed, but I thought that svg was supported on qml already... some considerations about technical minutiae of svg/framesvg vs image/borderimage: yep, it does, Image and BorderImage can have a svg as source tough there again i'm not sure either the right approach is done or is done the one good for us. as far i see from the sources a caching seems involved (qdeclarativepixmapcache), but looks like only memory and no svg renderer sharing, i could be wrong. it is not possible to access to sub elements, so no rendering of a single eleent or checking for the hint elements (thats all out of scope for the svg rendering of qml i think, so i don't think it would even make sense trying of making qml svg support more sofisticate) it is also not possible to have a borderimage that gets elements of an svg with a certain prefix, it only gets the whole image, all of this it would make impossible to use current themes, in brief break compatibility of wat there is already in. Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: today's meeting notes
Hi Marco, On Monday 13 September 2010 16:10:54 Marco Martin wrote: now, maybe when qtcomponents will be ready it could be decided to just use those widgets, again if they will be good enough for the desktop. That's what I'm trying to say: qt-components will probably never be ready as the conclusion of the project is that it's not worth it providing a widget set in QML. It's up to platform makers (this is where we enter with plasma *library*) to provide the widgets. Of course, qt-components may offer an implementation reference but it doesn't make sense to offer widgets as they differ from platform to platform and trying to do that is just a ton of hacks on top of other hacks (I say this from experience as we already tried to do so). So don't expect a widget set that we can just use as we have today with QWidgets. Application developers can expect that, but platform developers don't. That's why if we may want to provide this in the future: so applications using libplasma (kdeui maybe) may use directly the KDE widgets without pain. Summary: qt-components is not going to solve the problem for platform developers. They will need to write their widgets. Qt-components just show how to do in with less pain. Another path is to just do the bindings, but they will not work 100%...if we don't create false hopes that everything is going to work it's fine :) (example, without 4.7.1 the qgw exported to QML just don't work on Flickable items - nobody is maintaining this so regressions can also be expected). Or alternatively we can also decide that we really need to wait for them ad delay the complete bindings at this point, but wouldn't seem a particularly wise move for me, also because would basically mean plasma mobile not happening. I'm not saying that we choose one or another. My point is: we can do something (bindings) for the short term, but for long term we should start thinking about doing it as it's expected. Also to avoid headaches for us :) From my point of view it's not orthogonal: either bindings or proper components. From my point of view we can use the bindings for short term (4.6) and should start thinking about components for the long term. until then, a solution already is in there, judging from a couple of pretty complex uis i did with it, works quite good, so i don't much see the point of all of this discussion, because the real problem is one and completely unrelated: the use of the private class for dataengine bindings. The point of the discussion is just that you got a sentence out of context and is thinking that I'm arguing that is either one or another. My options are not exclusive - just the opposite: I think we should go for both. For the use of private classes on dataengine bindings: also don't expect for 4.7 the export of classes...it may happen on 4.8 but no idea when it's going out :P So we need to think together about a way of getting rid of it. Which private classes are being used? as far i see from the sources a caching seems involved (qdeclarativepixmapcache), but looks like only memory and no svg renderer sharing, i could be wrong. I would need to check too. Don't remember about this it is also not possible to have a borderimage that gets elements of an svg with a certain prefix, it only gets the whole image, all of this it would make impossible to use current themes, in brief break compatibility of wat there is already in. Ok. This justifies the creation of a declarative item that has proper support for our svgs. Cheers, -- --- Artur Duque de Souza - MoRpHeUz --- http://claimid.com/morpheuz Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net --- 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: today's meeting notes
On Monday 13 September 2010, Artur Duque de Souza wrote: Hi Marco, On Monday 13 September 2010 16:10:54 Marco Martin wrote: now, maybe when qtcomponents will be ready it could be decided to just use those widgets, again if they will be good enough for the desktop. That's what I'm trying to say: qt-components will probably never be ready as the conclusion of the project is that it's not worth it providing a [...] Summary: qt-components is not going to solve the problem for platform developers. They will need to write their widgets. Qt-components just show how to do in with less pain. ah, that's interesting. i understood that they were supoposed to have a part with the logic and a separate qml file for the styling that would have been platform specific? i should check what code there is in at the moment ;) Another path is to just do the bindings, but they will not work 100%...if we don't create false hopes that everything is going to work it's fine :) (example, without 4.7.1 the qgw exported to QML just don't work on Flickable items - nobody is maintaining this so regressions can also be expected). yeah, it will be a bit painful at start but the only short term way. in that particular case events get stolen, so they need a mousearea on top of it or to be in a plasma flickable widget, all of that needs to be documented. Or alternatively we can also decide that we really need to wait for them ad delay the complete bindings at this point, but wouldn't seem a particularly wise move for me, also because would basically mean plasma mobile not happening. I'm not saying that we choose one or another. My point is: we can do something (bindings) for the short term, but for long term we should start thinking about doing it as it's expected. Also to avoid headaches for us :) From my point of view it's not orthogonal: either bindings or proper yeah, that is what i was trying to say :) if we want to have something quickly what we have now needs to be used. i agree in the long term things should be done in a proper way. (for an hypotethic kde5 we could have just those, even) components. From my point of view we can use the bindings for short term (4.6) and should start thinking about components for the long term. until then, a solution already is in there, judging from a couple of pretty complex uis i did with it, works quite good, so i don't much see the point of all of this discussion, because the real problem is one and completely unrelated: the use of the private class for dataengine bindings. The point of the discussion is just that you got a sentence out of context and is thinking that I'm arguing that is either one or another. My options are not exclusive - just the opposite: I think we should go for both. yes, exactly, i misunderstood that part :) to me a distinct short and long term plans should be in place For the use of private classes on dataengine bindings: also don't expect for 4.7 the export of classes...it may happen on 4.8 but no idea when it's going out :P So we need to think together about a way of getting rid of it. Which private classes are being used? it's qdeclarativeopenmetaobject (that drags in also qdeclarativerefcount and the private of qobject) i think options are basically 2: - try to write something simple that doesn't use qdeclarativeopenmetaobject that could be even a bit overkill for it, will try today - keep an internal copy of all the thing if it's likely to be exported in future versions as far i see from the sources a caching seems involved (qdeclarativepixmapcache), but looks like only memory and no svg renderer sharing, i could be wrong. I would need to check too. Don't remember about this it is also not possible to have a borderimage that gets elements of an svg with a certain prefix, it only gets the whole image, all of this it would make impossible to use current themes, in brief break compatibility of wat there is already in. Ok. This justifies the creation of a declarative item that has proper support for our svgs. i'll try that shortly as well. i think those should be exported a Svg and FrameSvg since exporting directly thise classes doesn't make sense (they just offer a qpainter, so couldn't be used at all) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: today's meeting notes
Hi, Sorry I didn't attend, went house-hacking and had a birthday party last weekend, didn't do much computer-stuff as a result. Let me add my plans anyway. On Monday, September 13, 2010 00:13:23 Aaron J. Seigo wrote: thanks to everyone who attended, here are notes from today's meeting on irc: http://community.kde.org/Plasma/20100912 Network Management: - stable release within 1 or two months, further on from there (Lamarque is doing quite some work on mobile broadband stuff, really cool) Email Notifier (Lion Mail's first release): - nearly feature complete, will move to kdereview before 4.6 freeze Battery: - Could use an informational widget, just like NM's interface details. Maybe even a nice task for a JJ, in any case probably a lot of fun to do, I might just do it some night. :) Webslice: - Configuration needs usability love, other fixes (have to check w/ webkit from Qt 4.7) Desktop Search / Crystal: - possibly ship I've also one mostly finished desktop search applet there, it needs porting to Nepomuk's new query API though. Right now it uses KIO nepomuksearch, works quite OK in fact, and we can start doing fancy stuff with the display of search results (it already shows excerpts from full text search, btw). More of a fun project for me, though, but it happens to become stable and useful, maybe a nice addition to kdeplasma-addons. The above is also roughly my order of priority, so given limited time, items lower in the list might not get a lot of TLC (or none). Cheers, -- 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: Review Request: Add suspend-signal to powerdevil and make plasma time dataengine detecting clock skrews
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5320/#review7578 --- To be honest, I don't like this patch. The correct solution is to get a SIGNAL resumed(), which is caught by the dataengines and which then just updates. The polling and retrying in timeengine.cpp is really ugly, IMO. (No offense ;)) I want this fixed in Solid to get a reliable signal that we're resumed now. Your patch doesn't take hibernation into account, btw, which has the exact same problem. Also starting two second polling for two minutes when the user hits suspend looks like draining the battery unnecessarily (CPU wakeups), which is exactly not what you want on machines where suspend/resume is critical. Thanks a lot for looking into this (admittedly very annoying) problem, but I think that this is just a workaround for something that is important enough to be fixed in the right way. /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/time/timeengine.h http://svn.reviewboard.kde.org/r/5320/#comment7732 remove whitespace /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/time/timeengine.h http://svn.reviewboard.kde.org/r/5320/#comment7733 rm whitespace /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/time/timeengine.h http://svn.reviewboard.kde.org/r/5320/#comment7734 rm whitespace /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/time/timeengine.cpp http://svn.reviewboard.kde.org/r/5320/#comment7735 ws /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/time/timeengine.cpp http://svn.reviewboard.kde.org/r/5320/#comment7736 ws /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/time/timeengine.cpp http://svn.reviewboard.kde.org/r/5320/#comment7738 it's clock skew /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/time/timeengine.cpp http://svn.reviewboard.kde.org/r/5320/#comment7737 ws /trunk/KDE/kdebase/workspace/powerdevil/daemon/PowerDevilDaemon.cpp http://svn.reviewboard.kde.org/r/5320/#comment7731 This is problematic. You cannot assume that we resumed already, since the job in 808 is async. Suspension can still happen at this point. /trunk/KDE/kdebase/workspace/powerdevil/daemon/PowerDevilDaemon.cpp http://svn.reviewboard.kde.org/r/5320/#comment7730 remove whitespace - Sebastian On 2010-09-13 11:20:38, Björn Ruberg wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5320/ --- (Updated 2010-09-13 11:20:38) Review request for Plasma and Solid. Summary --- NOTE: This a little bit ugly as I have to workaround the missing going to suspend-signal in the linux userland This patch adds a signal to powerdevil that is emitted when a suspend/hibernate/standby is requested there. The signal is caught by the time engine what starts to look for an unexpected change in system time for two minutes by polling. If a clock skrew is detected, all sources are updated immediatly. This fixes the bug that the plasma clocks are showing old time after suspending your machine up until 59 seconds (whenever the normal update is scheduled). This is not exactly a patch for bug 181380. But the clock skrew detection code can be used quite similar for detecting normal time changes. I'll look into that as soon this is accepted. Please tell me whether I can commit this to 4.5 trunk as it is a bugfix for a nasty glitch. This addresses bug 181380. https://bugs.kde.org/show_bug.cgi?id=181380 Diffs - /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/time/timeengine.h 1166313 /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/time/timeengine.cpp 1166313 /trunk/KDE/kdebase/workspace/powerdevil/daemon/PowerDevilDaemon.h 1166313 /trunk/KDE/kdebase/workspace/powerdevil/daemon/PowerDevilDaemon.cpp 1166313 /trunk/KDE/kdebase/workspace/powerdevil/daemon/org.kde.PowerDevil.xml 1166313 Diff: http://svn.reviewboard.kde.org/r/5320/diff Testing --- Suspended machine, waited three minutes, woke up again - and noticed that all clocks on screen showed the correct time almost immediatly :) Thanks, Björn ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add suspend-signal to powerdevil and make plasma time dataengine detecting clock skrews
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5320/#review7579 --- First of all, thanks for looking into this and most of all for submitting a patch. Unfortunately, just like Sebastian said, I'm afraid I'm not willing to let this patch in. However, in the upcoming solid sprint I plan to address this. Luckily, UPower has a signal which does exactly what you tried to achieve here. I will get in touch with you as soon as I will implement the needed part in PowerDevil/Solid so you can code another patch against the new method. How does this sound to you? - Dario On 2010-09-13 11:20:38, Björn Ruberg wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5320/ --- (Updated 2010-09-13 11:20:38) Review request for Plasma and Solid. Summary --- NOTE: This a little bit ugly as I have to workaround the missing going to suspend-signal in the linux userland This patch adds a signal to powerdevil that is emitted when a suspend/hibernate/standby is requested there. The signal is caught by the time engine what starts to look for an unexpected change in system time for two minutes by polling. If a clock skrew is detected, all sources are updated immediatly. This fixes the bug that the plasma clocks are showing old time after suspending your machine up until 59 seconds (whenever the normal update is scheduled). This is not exactly a patch for bug 181380. But the clock skrew detection code can be used quite similar for detecting normal time changes. I'll look into that as soon this is accepted. Please tell me whether I can commit this to 4.5 trunk as it is a bugfix for a nasty glitch. This addresses bug 181380. https://bugs.kde.org/show_bug.cgi?id=181380 Diffs - /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/time/timeengine.h 1166313 /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/time/timeengine.cpp 1166313 /trunk/KDE/kdebase/workspace/powerdevil/daemon/PowerDevilDaemon.h 1166313 /trunk/KDE/kdebase/workspace/powerdevil/daemon/PowerDevilDaemon.cpp 1166313 /trunk/KDE/kdebase/workspace/powerdevil/daemon/org.kde.PowerDevil.xml 1166313 Diff: http://svn.reviewboard.kde.org/r/5320/diff Testing --- Suspended machine, waited three minutes, woke up again - and noticed that all clocks on screen showed the correct time almost immediatly :) Thanks, Björn ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add suspend-signal to powerdevil and make plasma time dataengine detecting clock skrews
On 2010-09-13 16:16:21, Sebastian Kügler wrote: To be honest, I don't like this patch. The correct solution is to get a SIGNAL resumed(), which is caught by the dataengines and which then just updates. The polling and retrying in timeengine.cpp is really ugly, IMO. (No offense ;)) I want this fixed in Solid to get a reliable signal that we're resumed now. Your patch doesn't take hibernation into account, btw, which has the exact same problem. Also starting two second polling for two minutes when the user hits suspend looks like draining the battery unnecessarily (CPU wakeups), which is exactly not what you want on machines where suspend/resume is critical. Thanks a lot for looking into this (admittedly very annoying) problem, but I think that this is just a workaround for something that is important enough to be fixed in the right way. I want to have this fixed in solid too, but in the meantime this is all what can be done. All you said is true. But if you look in powertop you have at least 40 wakeups per second (if you don't do anything and have much luck). Under nurmal workload in can climb up into the thousands. This patch adds a single wakeup all two seconds for a short period of time only if the user requested a sleeping mode. After waking up there is much cpu activity anyway, there is not much time for deep sleeps anyway. I cannot imagine that this patch really reduces battery time in any noticeable amount. This patch does respect hibernate. On 2010-09-13 16:16:21, Sebastian Kügler wrote: /trunk/KDE/kdebase/workspace/powerdevil/daemon/PowerDevilDaemon.cpp, line 814 http://svn.reviewboard.kde.org/r/5320/diff/2/?file=35751#file35751line814 This is problematic. You cannot assume that we resumed already, since the job in 808 is async. Suspension can still happen at this point. Don't understand. I don't assume that. - Björn --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5320/#review7578 --- On 2010-09-13 11:20:38, Björn Ruberg wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5320/ --- (Updated 2010-09-13 11:20:38) Review request for Plasma and Solid. Summary --- NOTE: This a little bit ugly as I have to workaround the missing going to suspend-signal in the linux userland This patch adds a signal to powerdevil that is emitted when a suspend/hibernate/standby is requested there. The signal is caught by the time engine what starts to look for an unexpected change in system time for two minutes by polling. If a clock skrew is detected, all sources are updated immediatly. This fixes the bug that the plasma clocks are showing old time after suspending your machine up until 59 seconds (whenever the normal update is scheduled). This is not exactly a patch for bug 181380. But the clock skrew detection code can be used quite similar for detecting normal time changes. I'll look into that as soon this is accepted. Please tell me whether I can commit this to 4.5 trunk as it is a bugfix for a nasty glitch. This addresses bug 181380. https://bugs.kde.org/show_bug.cgi?id=181380 Diffs - /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/time/timeengine.h 1166313 /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/time/timeengine.cpp 1166313 /trunk/KDE/kdebase/workspace/powerdevil/daemon/PowerDevilDaemon.h 1166313 /trunk/KDE/kdebase/workspace/powerdevil/daemon/PowerDevilDaemon.cpp 1166313 /trunk/KDE/kdebase/workspace/powerdevil/daemon/org.kde.PowerDevil.xml 1166313 Diff: http://svn.reviewboard.kde.org/r/5320/diff Testing --- Suspended machine, waited three minutes, woke up again - and noticed that all clocks on screen showed the correct time almost immediatly :) Thanks, Björn ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add suspend-signal to powerdevil and make plasma time dataengine detecting clock skrews
On 2010-09-13 16:44:03, Dario Freddi wrote: First of all, thanks for looking into this and most of all for submitting a patch. Unfortunately, just like Sebastian said, I'm afraid I'm not willing to let this patch in. However, in the upcoming solid sprint I plan to address this. Luckily, UPower has a signal which does exactly what you tried to achieve here. I will get in touch with you as soon as I will implement the needed part in PowerDevil/Solid so you can code another patch against the new method. How does this sound to you? That's sounds good. But this patch does not mean that the problem can never be fixed correctly. Maybe this can be seen as a fix for the 4.5 branch while you add the correct functionality for 4.6? - Björn --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5320/#review7579 --- On 2010-09-13 11:20:38, Björn Ruberg wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5320/ --- (Updated 2010-09-13 11:20:38) Review request for Plasma and Solid. Summary --- NOTE: This a little bit ugly as I have to workaround the missing going to suspend-signal in the linux userland This patch adds a signal to powerdevil that is emitted when a suspend/hibernate/standby is requested there. The signal is caught by the time engine what starts to look for an unexpected change in system time for two minutes by polling. If a clock skrew is detected, all sources are updated immediatly. This fixes the bug that the plasma clocks are showing old time after suspending your machine up until 59 seconds (whenever the normal update is scheduled). This is not exactly a patch for bug 181380. But the clock skrew detection code can be used quite similar for detecting normal time changes. I'll look into that as soon this is accepted. Please tell me whether I can commit this to 4.5 trunk as it is a bugfix for a nasty glitch. This addresses bug 181380. https://bugs.kde.org/show_bug.cgi?id=181380 Diffs - /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/time/timeengine.h 1166313 /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/time/timeengine.cpp 1166313 /trunk/KDE/kdebase/workspace/powerdevil/daemon/PowerDevilDaemon.h 1166313 /trunk/KDE/kdebase/workspace/powerdevil/daemon/PowerDevilDaemon.cpp 1166313 /trunk/KDE/kdebase/workspace/powerdevil/daemon/org.kde.PowerDevil.xml 1166313 Diff: http://svn.reviewboard.kde.org/r/5320/diff Testing --- Suspended machine, waited three minutes, woke up again - and noticed that all clocks on screen showed the correct time almost immediatly :) Thanks, Björn ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add an unit test for Plasma::ConfigLoader
On 2010-09-12 21:47:38, Martin Blumenstingl wrote: /trunk/KDE/kdelibs/plasma/tests/configloadertest.cpp, line 172 http://svn.reviewboard.kde.org/r/5329/diff/1/?file=35739#file35739line172 I am not sure why, but actual is always empty. I can't figure out the reason, because building the list is OK in ConfigLoader. I can access the list when I use it in a javascript plasmoid - so there may be something wrong with the code in my test. after a discussion with Aaron: using QListqint32 is wrong here. ItemIntList is a QListint - that's why casting fails. - Martin --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5329/#review7566 --- On 2010-09-12 21:45:48, Martin Blumenstingl wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5329/ --- (Updated 2010-09-12 21:45:48) Review request for Plasma. Summary --- Currently I'm changing some of the code in Plasma::ConfigLoader. I want to make sure that I don't break that much ;) Thus I wrote a unit test for the config loader. Currently all it does it testing if the config loader can parse the default-values correctly. One test for each (data-)type which ConfigLoader can handle. Unfortunately ConfigLoaderTest::intListDefaultValue does not work yet (everything else works) Diffs - /trunk/KDE/kdelibs/plasma/tests/configloadertest.xml PRE-CREATION /trunk/KDE/kdelibs/plasma/tests/CMakeLists.txt 1174512 /trunk/KDE/kdelibs/plasma/tests/configloadertest.h PRE-CREATION /trunk/KDE/kdelibs/plasma/tests/configloadertest.cpp PRE-CREATION Diff: http://svn.reviewboard.kde.org/r/5329/diff Testing --- I ran the tests on my box. 20/21 were successful. The only one failing is: ConfigLoaderTest::intListDefaultValue (and I need some help there) Thanks, Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add suspend-signal to powerdevil and make plasma time dataengine detecting clock skrews
On Monday, September 13, 2010 18:52:03 Björn Ruberg wrote: On 2010-09-13 16:44:03, Dario Freddi wrote: First of all, thanks for looking into this and most of all for submitting a patch. Unfortunately, just like Sebastian said, I'm afraid I'm not willing to let this patch in. However, in the upcoming solid sprint I plan to address this. Luckily, UPower has a signal which does exactly what you tried to achieve here. I will get in touch with you as soon as I will implement the needed part in PowerDevil/Solid so you can code another patch against the new method. How does this sound to you? That's sounds good. But this patch does not mean that the problem can never be fixed correctly. Maybe this can be seen as a fix for the 4.5 branch while you add the correct functionality for 4.6? I'd rather not have it in high-level Plasma components since it's essentially working around a limitation in HAL. There are a couple of problems with putting it in powerdevil as is: - the DBus method you expose is only valid for the HAL backend, if someone uses the (future) upower backend, you'd still use this workaround. Also, app developers might start to rely on this behaviour. - DBus interfaces are to be regarded as public API, therefore we cannot just change them - the workaround is in the wrong layer of the stack, the app (timeengine in this case) shouldn't work around limitations which we need to fix below in the stack (i.e. in Solid) Maybe we can put this workaround into the hal backend itself, and have it emit resumed() when it detects this clock skew. The upower backend would then emit the same signal, but triggered in the correct way. The applications get the hotness in a transparant manner and can adapt (i.e. our timeengine fires updates). This doesn't solve the problem that we're adding public API (the DBus method in powerdevil), but doing it in this future-proof (yey, right!) way would make it more acceptable IMO. You'll need to get it past Kevin, though. :) On 2010-09-13 11:20:38, Björn Ruberg wrote: http://svn.reviewboard.kde.org/r/5320/ NOTE: This a little bit ugly as I have to workaround the missing going to suspend-signal in the linux userland This patch adds a signal to powerdevil that is emitted when a suspend/hibernate/standby is requested there. The signal is caught by the time engine what starts to look for an unexpected change in system time for two minutes by polling. If a clock skrew is detected, all sources are updated immediatly. This fixes the bug that the plasma clocks are showing old time after suspending your machine up until 59 seconds (whenever the normal update is scheduled). This is not exactly a patch for bug 181380. But the clock skrew detection code can be used quite similar for detecting normal time changes. I'll look into that as soon this is accepted. Please tell me whether I can commit this to 4.5 trunk as it is a bugfix for a nasty glitch. This addresses bug 181380. https://bugs.kde.org/show_bug.cgi?id=181380 Cheers, -- 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: Review Request: Add an unit test for Plasma::ConfigLoader
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5329/ --- (Updated 2010-09-13 17:51:03.041714) Review request for Plasma. Changes --- fixed the failing test :) Summary (updated) --- Currently I'm changing some of the code in Plasma::ConfigLoader. I want to make sure that I don't break that much ;) Thus I wrote a unit test for the config loader. Currently all it does it testing if the config loader can parse the default-values correctly. One test for each (data-)type which ConfigLoader can handle. Diffs (updated) - /trunk/KDE/kdelibs/plasma/tests/configloadertest.xml PRE-CREATION /trunk/KDE/kdelibs/plasma/tests/CMakeLists.txt 1174512 /trunk/KDE/kdelibs/plasma/tests/configloadertest.h PRE-CREATION /trunk/KDE/kdelibs/plasma/tests/configloadertest.cpp PRE-CREATION Diff: http://svn.reviewboard.kde.org/r/5329/diff Testing (updated) --- I ran the tests on my box. All of them were successful. Thanks, Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add an unit test for Plasma::ConfigLoader
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5329/#review7582 --- Ship it! looks great; and it shows a problem in ConfigLoader - it should be using int, not qint32 for the integer list. nice! :) - Aaron On 2010-09-13 17:51:03, Martin Blumenstingl wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5329/ --- (Updated 2010-09-13 17:51:03) Review request for Plasma. Summary --- Currently I'm changing some of the code in Plasma::ConfigLoader. I want to make sure that I don't break that much ;) Thus I wrote a unit test for the config loader. Currently all it does it testing if the config loader can parse the default-values correctly. One test for each (data-)type which ConfigLoader can handle. Diffs - /trunk/KDE/kdelibs/plasma/tests/configloadertest.xml PRE-CREATION /trunk/KDE/kdelibs/plasma/tests/CMakeLists.txt 1174512 /trunk/KDE/kdelibs/plasma/tests/configloadertest.h PRE-CREATION /trunk/KDE/kdelibs/plasma/tests/configloadertest.cpp PRE-CREATION Diff: http://svn.reviewboard.kde.org/r/5329/diff Testing --- I ran the tests on my box. All of them were successful. Thanks, Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: today's meeting notes
* Activities - i still have to understand if i really want activities on plasma netbook/mobile or if containments are enough for the job iirc at akademy we agreed it was better... although there was some talk about getting the session stuff stable first? hrm. should've written things down. maybe we can chat about this next week? /me should really be packing, not reading mail :) oops ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: today's meeting notes
On Monday 13 September 2010, Chani wrote: * Activities - i still have to understand if i really want activities on plasma netbook/mobile or if containments are enough for the job iirc at akademy we agreed it was better... although there was some talk about getting the session stuff stable first? hrm. should've written things down. maybe we can chat about this next week? /me should really be packing, not reading mail :) oops yeah, as soon you have time and a stable connection, happy to do that :) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add suspend-signal to powerdevil and make plasma time dataengine detecting clock skrews
On 2010-09-13 16:44:03, Dario Freddi wrote: First of all, thanks for looking into this and most of all for submitting a patch. Unfortunately, just like Sebastian said, I'm afraid I'm not willing to let this patch in. However, in the upcoming solid sprint I plan to address this. Luckily, UPower has a signal which does exactly what you tried to achieve here. I will get in touch with you as soon as I will implement the needed part in PowerDevil/Solid so you can code another patch against the new method. How does this sound to you? Björn Ruberg wrote: That's sounds good. But this patch does not mean that the problem can never be fixed correctly. Maybe this can be seen as a fix for the 4.5 branch while you add the correct functionality for 4.6? Mail from Sebastian Kügler: I'd rather not have it in high-level Plasma components since it's essentially working around a limitation in HAL. There are a couple of problems with putting it in powerdevil as is: - the DBus method you expose is only valid for the HAL backend, if someone uses the (future) upower backend, you'd still use this workaround. Also, app developers might start to rely on this behaviour. - DBus interfaces are to be regarded as public API, therefore we cannot just change them - the workaround is in the wrong layer of the stack, the app (timeengine in this case) shouldn't work around limitations which we need to fix below in the stack (i.e. in Solid) Maybe we can put this workaround into the hal backend itself, and have it emit resumed() when it detects this clock skew. The upower backend would then emit the same signal, but triggered in the correct way. The applications get the hotness in a transparant manner and can adapt (i.e. our timeengine fires updates). This doesn't solve the problem that we're adding public API (the DBus method in powerdevil), but doing it in this future-proof (yey, right!) way would make it more acceptable IMO. You'll need to get it past Kevin, though. :) I would be fine reworking the patch in that manner IF it will be accepted then. May be I get some stubs provided so that I know where I have to go into powerdevil/solid. But concerning your dbus-concerns: I'm inventing a signal standbyRequested(). I can rename it awaitingStandby() or whatever. Important thing is, I don't see a reason why such a signal should not be in the public API. I can imagine different usages for it, i.e. applications gracefully closing network connections before standby. The whole polling stuff is there to work around the missing resumed signal. Surely that can be moved in the lower layer. The main benefit of this that there will actually be an resumed()-signal that other applications can catch. But as there will come a correct signal for this with the 4.6 release (I hope so :)), the patch might even stay as it is for the 4.5 line. - Björn --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5320/#review7579 --- On 2010-09-13 11:20:38, Björn Ruberg wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5320/ --- (Updated 2010-09-13 11:20:38) Review request for Plasma and Solid. Summary --- NOTE: This a little bit ugly as I have to workaround the missing going to suspend-signal in the linux userland This patch adds a signal to powerdevil that is emitted when a suspend/hibernate/standby is requested there. The signal is caught by the time engine what starts to look for an unexpected change in system time for two minutes by polling. If a clock skrew is detected, all sources are updated immediatly. This fixes the bug that the plasma clocks are showing old time after suspending your machine up until 59 seconds (whenever the normal update is scheduled). This is not exactly a patch for bug 181380. But the clock skrew detection code can be used quite similar for detecting normal time changes. I'll look into that as soon this is accepted. Please tell me whether I can commit this to 4.5 trunk as it is a bugfix for a nasty glitch. This addresses bug 181380. https://bugs.kde.org/show_bug.cgi?id=181380 Diffs - /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/time/timeengine.h 1166313 /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/time/timeengine.cpp 1166313 /trunk/KDE/kdebase/workspace/powerdevil/daemon/PowerDevilDaemon.h 1166313 /trunk/KDE/kdebase/workspace/powerdevil/daemon/PowerDevilDaemon.cpp 1166313 /trunk/KDE/kdebase/workspace/powerdevil/daemon/org.kde.PowerDevil.xml 1166313 Diff: http://svn.reviewboard.kde.org/r/5320/diff Testing
Re: Launchersupport for the tasks-applet
On Monday, September 13, 2010, Anton Kreuzkamp wrote: So my question is: Is anyone here interested in implementing it or maybe already doing so? i haven't started doing so, and i don't know of anyone who has. so, do you plan to do so? not currently. it's not because i don't want to but because: a) i already have more projects than time atm b) i wouldn't use the feature myself (so i can't even abuse the scratch my own itch motivation) -- 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: today's meeting notes
On Monday, September 13, 2010, Marco Martin wrote: On Monday 13 September 2010, Aaron J. Seigo wrote: * Activities - i still have to understand if i really want activities on plasma netbook/mobile or if containments are enough for the job personally, i think that for plasma-netbook itself, containments are fine. at least, i don't see a benefit to adding the complexity of activities, nor do i see a clean mapping between which newpspaper containment i'm viewing and which activity i'm engaged in. activities on the desktop are a reaction to those devices being used as general purpose tools. * Classroom - still didn't get involved too much in tat one, one thing i can think of it's ok, you have enough on your plate already :) -- 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: today's meeting notes
On Monday, September 13, 2010, Marco Martin wrote: - with konact mobile... yes, i feel potentilly there is a quite big amount of duplication, honestly didn't had the energy to ctually check tough :) oh, and i've actually started talking with Kevin about this ... we'll see where it goes. :) -- 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
plasma classroom
Hello everybody, yesterday took place a Plasma irc meeting. I was busy, so I want to say some words now, about Plasma Classroom: I think it's time to set up a folder on svn for this project. It could be created cloning the folder of plasma-desktop, so everyone could start writing code and discuss it with reviewboard. Another idea i had is to create a webpage from which teachers of all the world can submit suggestions for this project. Luca Tringali ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: configChanged coverage for 4.6
On Sunday, September 12, 2010 18:38:04 Rohan Garg wrote: Sorry that im waayy behind the schedule on this one, since this is my first patch to plasma, it might take another 10 days to perfect it, ive already fixed most of the issues with my patch on reviewboard for folderview, just need to fix the iconSizes issue. Extremely sorry for the delay. Don't worry, feature freeze is still months away (and this would even qualify as a bugfix). -- 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: Review Request: Add suspend-signal to powerdevil and make plasma time dataengine detecting clock skrews
On Monday, September 13, 2010 21:12:37 Björn Ruberg wrote: I would be fine reworking the patch in that manner IF it will be accepted then. May be I get some stubs provided so that I know where I have to go into powerdevil/solid. That's up to Dario and Kevin, I don't object in principle, if done well. But really, not my call. (And still, it's not that I really like QTimer::singleShot() hackery working around HAL limitations.) But concerning your dbus-concerns: I'm inventing a signal standbyRequested(). I can rename it awaitingStandby() or whatever. Important thing is, I don't see a reason why such a signal should not be in the public API. I can imagine different usages for it, i.e. applications gracefully closing network connections before standby. You don't have the time for that, as standby might be kicking in halfway, remember, there's no guarantee when a QSIGNAL will be delivered, it's essentially async. The actual suspend can happen before, or after, or in between, since the kernel can interrupt user space at any given point. (In fact your patch assume that this happens within 2 minutes, but again, this is also not a given -- the code path between when you call the signal and the actual resume of control in userspace might take more than those two minutes. Fortunately, in reality it doesn't happen very often, but it's well possible (imagine a machine needing to free enough swap space in order to resume, or some driver taking a long time to tear down some device). What you are talking about here something like suspend blockers. And hey, http://lwn.net/Articles/390369/ ... that's where we have to rely on the kernel and middleware (HAL, upower) again, since it has to be a system-wide mechanism to be effective. These things provide a mechanism to say don't suspend I'm doing this and that (sounds orthogonal, I know, but your awaitingStandby() is in fact a someone called suspend, some time ago, it's not awaiting since it's not blocking, and it should not be either. The gist is that what you want is not a signal, but a lock on the suspending function, and that is quite a bit more work. A signal such as the one you're proposing is close to useless IMO, and not even the subject of this whole thread -- that is updating the clock when the machine has resumed. Before adding something to public API, we need clear usecases, if we added functions because we can imagine someone doing it this way (even if broken), we'd end up with a pretty horrible pile of crap. Let's just wing this part for now =) The whole polling stuff is there to work around the missing resumed signal. Surely that can be moved in the lower layer. The main benefit of this that there will actually be an resumed()-signal that other applications can catch. But as there will come a correct signal for this with the 4.6 release (I hope so :)), the patch might even stay as it is for the 4.5 line. Yes, in the HAL backend, unless someone implements this in HAL. The idea is to fake the resume() signal for the HAL backend, so that it'll work for all applications, and that the API for that stuff doesn't change when switching backends. -- 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: today's meeting notes
On Monday 13 September 2010, Marco Martin wrote: For the use of private classes on dataengine bindings: also don't expect for 4.7 the export of classes...it may happen on 4.8 but no idea when it's going out :P So we need to think together about a way of getting rid of it. Which private classes are being used? it's qdeclarativeopenmetaobject (that drags in also qdeclarativerefcount and the private of qobject) i think options are basically 2: - try to write something simple that doesn't use qdeclarativeopenmetaobject that could be even a bit overkill for it, will try today - keep an internal copy of all the thing if it's likely to be exported in future versions QDeclarativePropertyMap gets to the rescue. a private-less version seems working now Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: configChanged coverage for 4.6
On Tue, Sep 14, 2010 at 12:55 AM, Aaron J. Seigo ase...@kde.org wrote: feedback time: was this a useful / helpful way to go about getting such improvements done? for those who got involved: was it enjoyable for you, and would you do it again? It was definitely a nice way to get into hacking on plasma, and I'll try to contribute more now - although I won't necessarily have much time once university starts again in a few weeks. if so, i have a few more similarly entry level, detail oriented items that we could set as a new focus item. I think maintaining the tasks page is a great way to track junior jobs, and having more entry level things there sounds like a good idea. Thanks, Anthony. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
