Re: Plasma::Svg::paint
On Wednesday 04 May 2011, Alex Merry wrote: I have a question about the way Plasma::Svg::paint is supposed to work when an elementId is given, but a size is not. did you do setContanisMultipleElements(true)? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: questions about KWin shadows
On Monday 02 May 2011, Martin Gräßlin wrote: Windows wich have decorations are the only ones which should not get the shadows. Docks should work. In any case I recommend reading [1]. Feel free to show me the diff. Cheers Martin [1]: https://projects.kde.org/projects/kde/kdebase/kde- workspace/repository/revisions/master/entry/kstyles/oxygen/oxygenshadowhelp er.cpp from a quick look it seems that what is missing in the panel is the actual insertion of the shadow pixmaps -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Got into GSoC!
On Tuesday 26 April 2011, Viranch Mehta wrote: Hi, As all of you might have known by now, my proposal (QML port of Plasmoids) just got accepted into GSoC. I want to thank all the community members of Plasma and KDE for giving me the opportunity :) Hope to make the plasma and KDE a better piece of software! we should meet on irc either later this week or next week for a kickstart discussion -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QtQuick 2.0?
FYI QtQuick 2 will not be compatible with QtQuick 1.x. Something to keep in mind, that there may be a migration step. context: http://thread.gmane.org/gmane.comp.lib.qt.qml/2499 Alan Alpert wrote: On Wed, 4 May 2011 03:39:22 ext Jason H wrote: I thought with modularization, that what is in qt 4.8 should matter less and less. For instance, there is a QML2 plugin that will work with QML1 http://labs.qt.nokia.com/2011/05/03/qml-shadereffectitem-on- qgraphicsview/ If everything except the core is a plug in, then what is in 4.8 should be less relevant. That plugin is a QML1 plugin designed to emulate a QML2 element. As far as I'm aware, it is a completely different element (C++-wise). But it does aim for QML source compatibility, like the QML2 elements designed to act like the QML1 elements we all know and love. Modularization doesn't do anything to solve this problem, alas, as QtQuick 1 and QtQuick 2 will still be incompatible. Plugins may contain just QML1 or QML2 items, and while they can contain both it is likely that you'd have to implement each one semi-separately in C++. So this is not the most graceful version bump. On the plus side, it's still a ways away (still a 'research' stage project and so not tied to any release). I don't know when 4.8 is being released, so I can't say it won't end up in 4.8, but right now it's not in any release. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QtQuick 2.0?
FYI QtQuick 2 will not be compatible with QtQuick 1.x. Something to keep in mind, that there may be a migration step. context: http://thread.gmane.org/gmane.comp.lib.qt.qml/2499 Alan Alpert wrote: On Wed, 4 May 2011 03:39:22 ext Jason H wrote: I thought with modularization, that what is in qt 4.8 should matter less and less. For instance, there is a QML2 plugin that will work with QML1 http://labs.qt.nokia.com/2011/05/03/qml-shadereffectitem-on- qgraphicsview/ If everything except the core is a plug in, then what is in 4.8 should be less relevant. That plugin is a QML1 plugin designed to emulate a QML2 element. As far as I'm aware, it is a completely different element (C++-wise). But it does aim for QML source compatibility, like the QML2 elements designed to act like the QML1 elements we all know and love. Modularization doesn't do anything to solve this problem, alas, as QtQuick 1 and QtQuick 2 will still be incompatible. Plugins may contain just QML1 or QML2 items, and while they can contain both it is likely that you'd have to implement each one semi-separately in C++. So this is not the most graceful version bump. On the plus side, it's still a ways away (still a 'research' stage project and so not tied to any release). I don't know when 4.8 is being released, so I can't say it won't end up in 4.8, but right now it's not in any release. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QtQuick 2.0?
there won't be binary compatibility with c++ items that subclass qdeclarativeitem or qgraphicswidget due the difference on how the paint operation happens. however they will be pretty easy to reimplement maintaining qml source compatibility. in Plasma we plan to ship both, once qml2 is out (to have a gratious fallback to software rendering, among other things) On Wednesday 04 May 2011, Stephen Kelly wrote: FYI QtQuick 2 will not be compatible with QtQuick 1.x. Something to keep in mind, that there may be a migration step. context: http://thread.gmane.org/gmane.comp.lib.qt.qml/2499 Alan Alpert wrote: On Wed, 4 May 2011 03:39:22 ext Jason H wrote: I thought with modularization, that what is in qt 4.8 should matter less and less. For instance, there is a QML2 plugin that will work with QML1 http://labs.qt.nokia.com/2011/05/03/qml-shadereffectitem-on- qgraphicsview/ If everything except the core is a plug in, then what is in 4.8 should be less relevant. That plugin is a QML1 plugin designed to emulate a QML2 element. As far as I'm aware, it is a completely different element (C++-wise). But it does aim for QML source compatibility, like the QML2 elements designed to act like the QML1 elements we all know and love. Modularization doesn't do anything to solve this problem, alas, as QtQuick 1 and QtQuick 2 will still be incompatible. Plugins may contain just QML1 or QML2 items, and while they can contain both it is likely that you'd have to implement each one semi-separately in C++. So this is not the most graceful version bump. On the plus side, it's still a ways away (still a 'research' stage project and so not tied to any release). I don't know when 4.8 is being released, so I can't say it won't end up in 4.8, but right now it's not in any release. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: questions about KWin shadows
thanks for the answers .. On Monday, May 2, 2011 17:34:17 Martin Gräßlin wrote: * is there a way to get the default sizes for the offsets? e.g. if passing in -1 or some such? there is no default offset size. It is completly controlled by the client why should the client be forced to control the size of the shadow? the panel, for instance, has no particular requirement for or reason to have a spcifically sized shadow. using whatever the default is would increase consistency between different clients, no? -- 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: Fix build of libkdeclarative with ENABLE_FINAL.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101278/#review3101 --- Ship it! looks fine, though i'd prefer not using underscores (something we avoid in the coding style :) experimental/libkdeclarative/bindings/icon.cpp http://git.reviewboard.kde.org/r/101278/#comment2632 iconCtor experimental/libkdeclarative/bindings/url.cpp http://git.reviewboard.kde.org/r/101278/#comment2631 urlCtor - Aaron J. On May 2, 2011, 10:21 p.m., Nicolas Alvarez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101278/ --- (Updated May 2, 2011, 10:21 p.m.) Review request for Plasma. Summary --- kdelibs compilation is broken with KDE4_ENABLE_FINAL turned ON. One of the problems is in libkdeclarative, where there's two file-static functions with the same name (ctor) and different code. These functions are used as function pointers when creating the QScript function objects. Fixed by renaming the two functions to icon_ctor and url_ctor. Diffs - experimental/libkdeclarative/bindings/icon.cpp 24885fa9d55b01388c681ec1766b659474fc40d7 experimental/libkdeclarative/bindings/url.cpp 21c7aa2227ea4ee10a15239905553bab40687fc5 Diff: http://git.reviewboard.kde.org/r/101278/diff Testing --- Compilation of kdelibs with and without final. Didn't try installing or running. Thanks, Nicolas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: questions about KWin shadows
On Wednesday 04 May 2011, Aaron J. Seigo wrote: thanks for the answers .. On Monday, May 2, 2011 17:34:17 Martin Gräßlin wrote: * is there a way to get the default sizes for the offsets? e.g. if passing in -1 or some such? there is no default offset size. It is completly controlled by the client why should the client be forced to control the size of the shadow? the panel, for instance, has no particular requirement for or reason to have a spcifically sized shadow. using whatever the default is would increase consistency between different clients, no? problem: the radius of the rounded window is controlled by the plasma theme, so is pretty easy creating a shadow that doesn't match -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Implements Plasma::TabBar::setTabHighlighted
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101264/#review3102
---
Ship it!
looks fine; a few minor tweaks but nothing that stands in the way of committing
this. cheers :)
plasma/private/nativetabbar.cpp
http://git.reviewboard.kde.org/r/101264/#comment2633
it's a private class; private membesr are unecessary. :)
plasma/private/nativetabbar.cpp
http://git.reviewboard.kde.org/r/101264/#comment2634
watch the whitespace = count()) {
- Aaron J.
On May 2, 2011, 10:25 a.m., Matthias Fuchs wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101264/
---
(Updated May 2, 2011, 10:25 a.m.)
Review request for Plasma, Aaron J. Seigo and Marco Martin.
Summary
---
Adds a setTabHighlighted and a isTabHighligted method to Plasma::TabBar.
When a tab is highlighted its icon will be drawn with 50% opacity and the
text will use Theme::HighlightColor.
So far I am not overly happy with the result.
Marco suggested to blur the area behind the icon, though I am not sure how to
do that. Another option I thought off is to either draw the button highlight
effect at the area of highlighted tabs or around its icon.
What do you think of that?
Diffs
-
plasma/private/nativetabbar.cpp 916deed
plasma/private/nativetabbar_p.h 665d99f
plasma/widgets/tabbar.h eb7a2aa
plasma/widgets/tabbar.cpp 16da3b9
Diff: http://git.reviewboard.kde.org/r/101264/diff
Testing
---
Screenshots
---
could be nicer :/
http://git.reviewboard.kde.org/r/101264/s/152/
http://git.reviewboard.kde.org/r/101264/s/153/
Thanks,
Matthias
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: SoK idea: Improve krunner result displaying and navigation.
Hi again. So, based on this list, I made a 12 week plan for the project based on the 12 week scheme used in GSoC: Week 1/2: Tweak Nepomuk runner Week 2/3: Tweak File search runner Week 3: Tweak Google runner Weeks 4 to 5 (or 6?): Put result querying in a different thread Week 6: Polish what has been done so far Week 7: Get user feedback better (Tell when searching and when nothing was found, some helping message at start) Week 8: Separate results in groups, allow user to define the priority of each runner (or allow developer to define the priority each one of their runner's commands can set it) Week 9: Make results fit on only one krunner screen, shrink less relevant results, hide lesser relevant results on main krunner screen Week 10: Expanding/unexpanding search groups Week 11: Extra actions for each item of the results, depending on its type Week 12: Polish and get everything ready to go What do you think? Em 1 de maio de 2011 04:06, Luiz Romário Santana Rios luizroma...@gmail.com escreveu: Ah, this is not a definitive list. We can add/remove stuff from it. Em 1 de maio de 2011 04:04, Luiz Romário Santana Rios luizroma...@gmail.com escreveu: Take a look at this and see if it's OK: Improve krunner result displaying brainstorm: + Tweak runners result rating * Nepomuk runner ~ Remove over and over repeated results * File search runner Priority criteria ~ Exact match: for photos, priorize Photos over Photos - september, for example ~ Priorize folders over files ~ Folders that contain several folders or files that match the query, probably showing them as subresults * Google runner ~ Show a list of actual results from the search (Is this possible?) + Change krunner result displaying * Group each runner results into its own category * Allow user to change the categories' priorities (For example: first, commands, then, files, then, nepomuk, etc). * Show as many results as it fits in krunner, shrinking the less relevant ones. (configurable) * If there are results from more than a runner, give the user an option to expand one category and show only its results. ~ Show further results in the associated application * Show extra actions for each item * Give the option of using a compact layout * Mockup: https://picasaweb.google.com/luizromario/Mockups#5601639496208873426 + Fine-tune krunner * Popup some helping text if user waits too long * Tell the user when krunner is searching and when it found nothing * Put query in a different thread so krunner doesn't freeze while the user is typing something (if it still isn't). And I think the KSysGuard part it uses needs some care too. Anyway, sorry for taking so long, I got stuck sometimes when doing this. 2011/4/30 Aaron J. Seigo ase...@kde.org On Friday, April 29, 2011 23:57:57 Luiz Romário Santana Rios wrote: 2011/4/29 Aaron J. Seigo ase...@kde.org On Friday, April 29, 2011 00:21:11 Luiz Romário Santana Rios wrote: 2011/4/28 Aaron J. Seigo ase...@kde.org On Thursday, April 28, 2011 09:15:08 Luiz Romário Santana Rios wrote: Currently, when we type something in, krunner displays the results as it finds it, without giving a feedback of whether it is searching or just didn't find anything. that would be a nice addition. It also does not separate the results into its different categories that's because they are organized by relevance. if they are sorted into categories, and if there are 4 categories that match and 5 items in each category then the best match from the 4th category will be the 16th item in the list(!) even though it is more likely to be what the user wants than most of the items above it. i have yet to see a solution for this problem, but am open to such a solution being offered. Well, I thought about showing only the most relevant results for each category and priorizing the category with the most relevant results. If a which is almost always going to be the nepomuk search ;) user want to see more results for that category, they would just need to expand it. I'll do some mockups for that and will post here. sounds good; mockups always help. Here's one: http://lh5.googleusercontent.com/_V8ZPvFyTxNc/Tbty2kU7CII/ARs/v_Ut1J 8P4DQ/01%20-%20Expand%20and%20Shrink%20less%20relevant%20results.png It's bad, I know, I suck at making mockups, but it gives part of the idea of what I mean. wire frame mockups like that one are just fine. they let one concentrate on the structure rather than get distracted by shiny things ;) Notice that I show two different ways of expanding the results in it. I think the button is better, but it takes too much space, so I'm and what would be the workflow to expand / collapse / run? an
Re: Review Request: Implements Plasma::TabBar::setTabHighlighted
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101264/#review3103 --- This review has been submitted with commit 0d9efa0f939ece18849e82cd2b58cf4ce441b0c2 by Matthias Fuchs. - Commit On May 2, 2011, 10:25 a.m., Matthias Fuchs wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101264/ --- (Updated May 2, 2011, 10:25 a.m.) Review request for Plasma, Aaron J. Seigo and Marco Martin. Summary --- Adds a setTabHighlighted and a isTabHighligted method to Plasma::TabBar. When a tab is highlighted its icon will be drawn with 50% opacity and the text will use Theme::HighlightColor. So far I am not overly happy with the result. Marco suggested to blur the area behind the icon, though I am not sure how to do that. Another option I thought off is to either draw the button highlight effect at the area of highlighted tabs or around its icon. What do you think of that? Diffs - plasma/private/nativetabbar.cpp 916deed plasma/private/nativetabbar_p.h 665d99f plasma/widgets/tabbar.h eb7a2aa plasma/widgets/tabbar.cpp 16da3b9 Diff: http://git.reviewboard.kde.org/r/101264/diff Testing --- Screenshots --- could be nicer :/ http://git.reviewboard.kde.org/r/101264/s/152/ http://git.reviewboard.kde.org/r/101264/s/153/ Thanks, Matthias ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: questions about KWin shadows
On Wednesday, May 4, 2011 10:19:34 Marco Martin wrote: On Monday 02 May 2011, Martin Gräßlin wrote: Windows wich have decorations are the only ones which should not get the shadows. Docks should work. In any case I recommend reading [1]. Feel free to show me the diff. Cheers Martin [1]: https://projects.kde.org/projects/kde/kdebase/kde- workspace/repository/revisions/master/entry/kstyles/oxygen/oxygenshadowh elp er.cpp from a quick look it seems that what is missing in the panel is the actual insertion of the shadow pixmaps aha; i was under the impression that the shadows were to be provided by the compositor, not the client. fair enough ... -- 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: Check for new comic strips
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101252/#review3104 --- This review has been submitted with commit f80d5c09f4c9e414b39aabf7eedf5b0f56867f6d by Matthias Fuchs. - Commit On April 30, 2011, 10:33 a.m., Matthias Fuchs wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101252/ --- (Updated April 30, 2011, 10:33 a.m.) Review request for Plasma and Aaron J. Seigo. Summary --- Checks if there a new comic strips for the chosen comics. The user can define a time intervall in minutes for that. If a new comic strip is found, then the tab is highlighted by prepending a * to the tab text. First I planned to change the tab text color but this is not possible, unless the NativeTabBar code would change. But I think the way it is now works reasonable well. Diffs - applets/comic/CMakeLists.txt b85cb33 applets/comic/checknewstrips.h PRE-CREATION applets/comic/checknewstrips.cpp PRE-CREATION applets/comic/comic.h ca55959 applets/comic/comic.cpp 814cca8 applets/comic/comicSettings.ui f7fdeed applets/comic/comicarchivejob.cpp 33d1da4 applets/comic/configwidget.h 767dc3d applets/comic/configwidget.cpp 0dfd9ab applets/comic/imagewidget.cpp 15e1ddb dataengines/comic/comicprovider.cpp 73f1791 Diff: http://git.reviewboard.kde.org/r/101252/diff Testing --- Screenshots --- http://git.reviewboard.kde.org/r/101252/s/142/ http://git.reviewboard.kde.org/r/101252/s/143/ Thanks, Matthias ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: questions about KWin shadows
On Wednesday 04 May 2011 13:32:55 Aaron J. Seigo wrote: On Wednesday, May 4, 2011 10:19:34 Marco Martin wrote: On Monday 02 May 2011, Martin Gräßlin wrote: Windows wich have decorations are the only ones which should not get the shadows. Docks should work. In any case I recommend reading [1]. Feel free to show me the diff. Cheers Martin [1]: https://projects.kde.org/projects/kde/kdebase/kde- workspace/repository/revisions/master/entry/kstyles/oxygen/oxygenshadowh elp er.cpp from a quick look it seems that what is missing in the panel is the actual insertion of the shadow pixmaps aha; i was under the impression that the shadows were to be provided by the compositor, not the client. fair enough ... that is in fact the main idea of the new shadow system as the compositor cannot know about the light model used by the client, whether to apply drop shadows etc. etc. And of course the compositor doesn't know the clients shape like Marco already said. Martin 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: questions about KWin shadows
On Wednesday, May 4, 2011 17:19:37 Martin Gräßlin wrote: that is in fact the main idea of the new shadow system as the compositor cannot know about the light model used by the client, whether to apply drop shadows etc. etc. And of course the compositor doesn't know the clients shape like Marco already said. well, in any case, it's working now in master for panels. those are now rendered using the kwin effect. i'll work on the other bits and pieces in libplasma later. it seems to work nicely with the panel autohide slide in/out effect as well, and content behind the shadow is not blurred. clicks go through ... all in a nice improvement. you may wish to check it out for yourselves to ensure there are no performance regressions. there is just one copy of the pixmaps kept for all the panels; there will end up being another set for popups and yet another for tooltips, i believe. -- 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: questions about KWin shadows
On Wednesday 04 May 2011, Aaron J. Seigo wrote: On Wednesday, May 4, 2011 17:19:37 Martin Gräßlin wrote: that is in fact the main idea of the new shadow system as the compositor cannot know about the light model used by the client, whether to apply drop shadows etc. etc. And of course the compositor doesn't know the clients shape like Marco already said. well, in any case, it's working now in master for panels. those are now rendered using the kwin effect. i'll work on the other bits and pieces in libplasma later. it seems to work nicely with the panel autohide slide in/out effect as well, and content behind the shadow is not blurred. clicks go through ... all in a nice improvement. you may wish to check it out for yourselves to ensure there are no performance regressions. there is just one copy of the pixmaps kept for all the panels; there will end up being another set for popups and yet another for tooltips, i believe. yup, they should stay inside the dialogs/tooltips svgs. while it could probably save something using a single set, themes can have pretty different svgs for those 3 things, altough in the case of air a single set would probably work -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: questions about KWin shadows
On Wednesday 04 May 2011 19:58:14 Aaron J. Seigo wrote: On Wednesday, May 4, 2011 17:19:37 Martin Gräßlin wrote: that is in fact the main idea of the new shadow system as the compositor cannot know about the light model used by the client, whether to apply drop shadows etc. etc. And of course the compositor doesn't know the clients shape like Marco already said. well, in any case, it's working now in master for panels. awesome, it just took as eight releases to get it working :-D those are now rendered using the kwin effect. In fact it's not an effect, but an integrated part of the compositor which allows all the magic like not being blurred, clicks going through and not affecting anything else :-) i'll work on the other bits and pieces in libplasma later. cool it seems to work nicely with the panel autohide slide in/out effect as well, and content behind the shadow is not blurred. clicks go through ... all in a nice improvement. you may wish to check it out for yourselves to ensure there are no performance regressions. just compiled, looks really good and I will keep an eye on performance. It also seems to be no issue that the shadow is above the windows and not below. there is just one copy of the pixmaps kept for all the panels; there will end up being another set for popups and yet another for tooltips, i believe. Currently KWin is still keeping an additional copy of the pixmaps for each window, but that is something I want to optimize. Martin 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: Idea for Season of KDE
On Wednesday 04 May 2011 12:35:27 Samikshan Bairagya wrote: Hi, I am interested in participating in the season of KDE with a project idea which is related to the Digital-Clock Plasma Applet. While the Digital-Clock applet does show events (mainly holidays) it can be put to better use if we add more features to it. This is the idea: On clicking on any date from the calendar that pops up from the clock, we should be able to view more information related to that date(past or future). Various date specific informations like chat-logs, browsing history, emails received/sent, birthdays, to-dos/appointments also notes if we do wish to write them down. I suppose this would be great. Regarding implementation I think integration with Kontact, Nepomuk. Well I about the chat logs I am not sure if integration should be done with telepathy or not. So, it would be great if anyone interested could mentor me throughout this. :) Cheers, Hi Samikshan, A nice idea, but unfortunately one that is already being worked on. At the moment we have both Holidays and Akonadi support in the Plasma Calendar widget, which will give us full PIM data integration once the kdepim migration is complete. We also already have a GSoC project this year for Zeitgeist integration into Plasma which will give us the other data, albeit not yet in the calendar. If you do want to try adding it to the calendar then pop back after GSoC and use the new dataengine to do so. Have a look at the Cheers! John. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Idea for Season of KDE
On Wednesday 04 May 2011 20:03:27 John Layt wrote: On Wednesday 04 May 2011 12:35:27 Samikshan Bairagya wrote: Hi, I am interested in participating in the season of KDE with a project idea which is related to the Digital-Clock Plasma Applet. While the Digital-Clock applet does show events (mainly holidays) it can be put to better use if we add more features to it. This is the idea: On clicking on any date from the calendar that pops up from the clock, we should be able to view more information related to that date(past or future). Various date specific informations like chat-logs, browsing history, emails received/sent, birthdays, to-dos/appointments also notes if we do wish to write them down. I suppose this would be great. Regarding implementation I think integration with Kontact, Nepomuk. Well I about the chat logs I am not sure if integration should be done with telepathy or not. So, it would be great if anyone interested could mentor me throughout this. :) Cheers, Hi Samikshan, A nice idea, but unfortunately one that is already being worked on. At the moment we have both Holidays and Akonadi support in the Plasma Calendar widget, which will give us full PIM data integration once the kdepim migration is complete. We also already have a GSoC project this year for Zeitgeist integration into Plasma which will give us the other data, albeit not yet in the calendar. If you do want to try adding it to the calendar then pop back after GSoC and use the new dataengine to do so. Have a look at the Cheers! John. Sorry, missed the bit on the end :-) I was going to suggest if you want to work on a SoK project for the Plasma Calendar that you could look into two-way Akonadi integration, e.g. being able to add new appointments via the calendar. I'm not sure if that is enough work of a SoK project or not, but if you do some research and come up with a draft proposal we can make a decision then. Cheers! John. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Preconfigurable plasmoids
On April 28, 2011, 9:19 p.m., Aaron J. Seigo wrote: an interesting idea, but the configuration values should not appear in the metadata.desktop file. it not only bloats up the # of keys we have, it doesn't scale to plasmoids with more/different configuration. i think this would make more sense as a .desktop + a KConfigGroup (could even be in the same file?) that holds the complete default configuration that is then copied over after the applet is created. I am making a DBusLauncher base plasmoid to see how far this can get. It faces one issue so far: How to make some entries in the [Configuration] group translatable? (provided by the configuration desktop file). Some data should be translated (as user facing strings) and some other must not be translated (as resources identifiers). - David --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101251/#review2950 --- On May 4, 2011, 12:52 a.m., David Palacio wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101251/ --- (Updated May 4, 2011, 12:52 a.m.) Review request for Plasma. Summary --- There is some code duplication in that some plasmoids share very much of program logic but actually differ in just a setting. E.g. the recently made ShowActivityManager plasmoid, which just is a DBus call launcher. The Icon plasmoid is an example of this made right. I'd like to have more generic plasmoids. Even better, I'd like to have an easy way to configure them. Let's see the code. config.patch shows a way to load a config metadata file and fill a designated plasmoid with the configuration data (metadata.desktop). We search for a X-Plasma-ConfigApplet property that defines the plasmoid to configure and load. Additional properties define the plasmoid settings. This allows us, for example, to easily provide access to any webservice without code duplication. Diffs - plasma/data/servicetypes/plasma-applet.desktop 8fabddb plasma/pluginloader.cpp 43a5b7c plasma/tests/CMakeLists.txt 1d04aa5 plasma/tests/plasmoidconfigtest.h PRE-CREATION plasma/tests/plasmoidconfigtest.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/101251/diff Testing --- Loading of plasmoids works. Testcase: Install these widgets: http://kde-look.org/content/show.php/Label?content=99881 http://kde-look.org/content/show.php?content=141270 Add configlabel to desktop. Thanks, David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
