Re: Review request: Container plasma applet
On 9/23/09, alan moore m...@alandmoore.com wrote: Anyway, with your last sentence you was saying that I could have done a similar thing working directly on containments? yes, and that's really probably the way to go about it. use cases would probably help define what direction to actually take. I was actually a bit excited when I saw this applet myself, as I had looked into developing something along the same lines (but gave up because I didn't have the requisite coding knowledge). Basically, my use case is simple: using the KDE panel as a sidebar. The reason being that screens are getting wider and smaller for many users (think notebooks, netbooks, UMPCs), vertical space becomes more valuable, so it makes sense to put stuff like the panel (that mostly just sits there offering some controls) off to the side rather than the traditional top/bottom arrangement. When I tried this with my panel as-is, the results were problematic. Many plasmoids (such as the battery monitor) insist on being square, and in a 200 to 300 px wide sidebar they take up a huge amount of space. Some just kind of fall apart. The tray became a huge squarish thing that took up 1/4 of the height. this means those plasmoids have to be fixed. in particular the battery applet should have a constrainedsquare aspect ratio andstill draw the svg as square when the applet is rectangular My thinking for the solution was to create a sub-containment that would allow plasmoids to be arranged in horizontal rows on a vertical sidebar. best bapproach would be write a panel containment that allows more complex layouts, like vertval layout of horizontals or more simply a grid layout I don't know if the plasmoid in question can do that, or if the panel can be modified to do that, but it seems a reasonable way to approach the problem. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Ayatana notifications for Plasma
Hi, I would like to present to you some work I have been doing for Canonical regarding notifications in Plasma. Before going further, let me state that my goal with this mail is not to get this work incorporated upstream, as I understand the Plasma project have a different position than Canonical on the subject of notifications. I decided to write this mail because I believe it is more correct to let you know about it in a more personal way rather than you discovering it in a blog post or a Kubuntu review. This work provides an implementation of Ayatana notifications for Plasma (Ayatana is the name of a Canonical project to improve user experience on Ubuntu and derivatives). Ayatana notifications have the following characteristics: - Notifications are queued instead of stacked. This helps reduce the spamming feeling. - Notifications are passive: they do not feature actions or close buttons. This is probably the most controversial bit. - Since notifications are passive, they are click-through: when you move the mouse over them, they fade away to become almost transparent and let you click through them to reach any underlying window. - Since they do not need any interactivity interface, they are drawn using Plasma tooltip SVG. Here are (slightly outdated) screenshots of what they look like: http://people.canonical.com/~agateau/plasma-ayatana-notifications/powerdevil.png http://people.canonical.com/~agateau/plasma-ayatana-notifications/kopete.png An important point: While the patch is integrated in Kubuntu, the default behavior is to use KDE notifications. The user can switch to Ayatana notifications through an option of the system tray configuration dialog (there are even preview buttons to help the user decide). http://people.canonical.com/~agateau/plasma-ayatana-notifications/configuration.png I attached a patch for you to test if you feel so inclined. I updated it this morning to latest trunk. It is a single large patch because I believe it is easier to try it this way, but if you are interested in the incremental steps, you can find a patchset tarball here: http://people.canonical.com/~agateau/plasma-ayatana-notifications/ As I said I do not expect this to be merged but I would be very happy if some of you just gave it a try for a few hours and maybe find some interesting ideas in it. The queuing and click-through features in particular could be interesting. I was quite skeptic about the idea of passive notifications first, but have since changed my mind after using them for a while. I believe this new approach needs to be tried for one to make an informed opinion on it. The feedback I got from Kubuntu Karmic users is varied: some like it a lot, other don't. Please let me know your opinion on this. Regards, Aurélien kdebase-ayatana-notifications.diff.bz2 Description: Binary data ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
Hi, I for one was one of the early skeptics, being a supporter of keeping Kubuntu as much a pure KDE dist as possible. Part of our goal was to allow Canonical to trial their new notifications under KDE, while defaulting to pure KDE notifications, thus permitting the user the choice to test out this experiment by opting in. I believe this was a good decision, in that it allowed the Kubuntu team to maintain its goals, yet at the same time, allowed some experimentation with new ideas. After having opted into the trial, I have found that these new notifications are quite appealing, and coupled with the Notification Indicator Applet that Aurélien has written, I find that I am having a much better user experience. I do believe that while KDE may not desire to merge the patches for this, it is definitely worth a look to see what ideas may be taken from this experiment, and possibly something to consider as ideas for integration into KDE 4.4 or 4.5. The click-through on notifications are simply beautiful, and allow the user to continue to type behind the pop-up and thereby not interrupt work flow. Anyway, just to give a users perspective.. Regards, Rod. Hi, I would like to present to you some work I have been doing for Canonical regarding notifications in Plasma. Before going further, let me state that my goal with this mail is not to get this work incorporated upstream, as I understand the Plasma project have a different position than Canonical on the subject of notifications. I decided to write this mail because I believe it is more correct to let you know about it in a more personal way rather than you discovering it in a blog post or a Kubuntu review. This work provides an implementation of Ayatana notifications for Plasma (Ayatana is the name of a Canonical project to improve user experience on Ubuntu and derivatives). Ayatana notifications have the following characteristics: - Notifications are queued instead of stacked. This helps reduce the spamming feeling. - Notifications are passive: they do not feature actions or close buttons. This is probably the most controversial bit. - Since notifications are passive, they are click-through: when you move the mouse over them, they fade away to become almost transparent and let you click through them to reach any underlying window. - Since they do not need any interactivity interface, they are drawn using Plasma tooltip SVG. Here are (slightly outdated) screenshots of what they look like: http://people.canonical.com/~agateau/plasma-ayatana-notifications/powerdevi l.png http://people.canonical.com/~agateau/plasma-ayatana-notifications/kopete.p ng An important point: While the patch is integrated in Kubuntu, the default behavior is to use KDE notifications. The user can switch to Ayatana notifications through an option of the system tray configuration dialog (there are even preview buttons to help the user decide). http://people.canonical.com/~agateau/plasma-ayatana-notifications/configura tion.png I attached a patch for you to test if you feel so inclined. I updated it this morning to latest trunk. It is a single large patch because I believe it is easier to try it this way, but if you are interested in the incremental steps, you can find a patchset tarball here: http://people.canonical.com/~agateau/plasma-ayatana-notifications/ As I said I do not expect this to be merged but I would be very happy if some of you just gave it a try for a few hours and maybe find some interesting ideas in it. The queuing and click-through features in particular could be interesting. I was quite skeptic about the idea of passive notifications first, but have since changed my mind after using them for a while. I believe this new approach needs to be tried for one to make an informed opinion on it. The feedback I got from Kubuntu Karmic users is varied: some like it a lot, other don't. Please let me know your opinion on this. Regards, Aurélien signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
Am Mittwoch 23 September 2009 16:48:00 schrieb Aurélien Gâteau: Hi, I would like to present to you some work I have been doing for Canonical regarding notifications in Plasma. That just saved you from a rant about it on planetkde from my side ;-) I wanted to blog about some things I don't like. Most important I don't like that Canonical is reinventing the wheel. KDE has a great notification system which could be improved but developing a second system is IMHO completely wrong and doesn't look like a good Upstream/Downstream relationship. An important point: While the patch is integrated in Kubuntu, the default behavior is to use KDE notifications. The user can switch to Ayatana notifications through an option of the system tray configuration dialog (there are even preview buttons to help the user decide). http://people.canonical.com/~agateau/plasma-ayatana-notifications/configura tion.png Sorry have you ever considered how that looks to the user? Which user does know about Ayatana? That is a technical term which should not be presented in a UI. Why should a user switch to something else than the KDE notifications? The dialog is completely missing any information on what the notifications provide, what's the difference between the two and in the end it will come down to the one provides different possible positions while the other doesn't (btw the last time I tested Karmic the edges monitor didn't get disabled when switching to KDE notifications). If you wanted to give an easy way to test this system while not destroying user experience you should have made this a hidden config file option. Some personal notes: adding strings to the user interface is realy bad if the distribution is Kubuntu. From my experience of four years using Kubuntu there has never been any release where the custom additions made by Kubuntu were translated and given the history and the fact that there is no community left which will translate the strings I doubt they will be translated. There is IMHO nothing worse to the user experience than broken translations. That's of course in no way your fault, I just wanted to make you aware of the problem ;-) And I am realy afraid that there will be the time when Kubuntu switches from KDE notifications to those Ayatana notifications. I realy hope that will never happen. There might be good things about it and it would be great to bring them into the normal KDE notifications but all together I don't want the system. I have spoken to many Ubuntu users and nobody has said a good word about notifiy-osd, the most common saying was broken by design. Just so when Kubuntu switches to Ayatana, I will switch to a different distribution. I don't want a distribution which doesn't use the upstream implementation in a very centric part of the desktop environment. signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
Martin Gräßlin wrote: An important point: While the patch is integrated in Kubuntu, the default behavior is to use KDE notifications. The user can switch to Ayatana notifications through an option of the system tray configuration dialog (there are even preview buttons to help the user decide). http://people.canonical.com/~agateau/plasma-ayatana-notifications/configura tion.png Sorry have you ever considered how that looks to the user? Which user does know about Ayatana? That is a technical term which should not be presented in a UI. I was thinking just like you. My initial patch was labeled Lighter notifications, but Celeste and ScottK (of Kubuntu fame) suggested to put the Ayatana word here to start building a brand on it. Why should a user switch to something else than the KDE notifications? The dialog is completely missing any information on what the notifications provide, what's the difference between the two and in the end it will come down to the one provides different possible positions while the other doesn't It seems you missed the Preview buttons in the dialog. (btw the last time I tested Karmic the edges monitor didn't get disabled when switching to KDE notifications). Good point. Will fix. If you wanted to give an easy way to test this system while not destroying user experience you should have made this a hidden config file option. I would not call this an easy way to test And I am realy afraid that there will be the time when Kubuntu switches from KDE notifications to those Ayatana notifications. I realy hope that will never happen. My knowledge of the Kubuntu community makes me quite confident this won't happen. There might be good things about it and it would be great to bring them into the normal KDE notifications but all together I don't want the system. That's all I want you to find. Experiment with it and extract anything which makes sense from it. I have spoken to many Ubuntu users and nobody has said a good word about notifiy-osd, the most common saying was broken by design. As I said, the changes received varied feedback. I met Ubuntu users who really loved notify-osd, and others who don't. Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
Disclaimer: this mail is not meant to sound offensive and/or personal. On Wednesday 23 September 2009 16:48:00 Aurélien Gâteau wrote: Hi, I would like to present to you some work I have been doing for Canonical regarding notifications in Plasma. Before going further, let me state that my goal with this mail is not to get this work incorporated upstream, as I understand the Plasma project have a different position than Canonical on the subject of notifications. I decided to write this mail because I believe it is more correct to let you know about it in a more personal way rather than you discovering it in a blog post or a Kubuntu review. I'd like a bit more clarity. The patch you posted about powerdevil was presented as your initiative regardless of Ayatana. However, with Ayatana notifications user interaction is not possible, hence your previous patch was either an unfortunate wrong timing coincidence or strictly related. I don't want to go off-topic or whatever, since about your PowerDevil patch I am quite confused as I really can't decide between a notification and a dialog, but I'd just like to have some clarifications on purpose and goals. That said. This work provides an implementation of Ayatana notifications for Plasma (Ayatana is the name of a Canonical project to improve user experience on Ubuntu and derivatives). Ayatana notifications have the following characteristics: - Notifications are queued instead of stacked. This helps reduce the spamming feeling. - Notifications are passive: they do not feature actions or close buttons. This is probably the most controversial bit. What about IM? Without what you presented in your post about Indicators, the desktop workspace would be broken. Hence this makes me really believe you're taking the wrong route here. You are basically pushing 2 different kind of notifications (with 2 API and 2 underlying systems) the developer has to choose (and learn) to display informations. And the situation of PowerDevil is the one that demonstrates the weakness of this design. Putting aside the scope of the notification, the side effects and whatever, my question is: would it be possible, with the current Ayatana spec featuring indicators to achieve something like powerdevil notification without a dialog? I bet the answer is no. Indicators would be too much, and with this spec you are defining (IMHO) the following points: 1 - Everything that requires user interaction can be delayed until X - wrong. Unless you decide that in situations where the user has to provide fast feedback you want to use dialogs 2 - Everything short-noticed should be passive - wrong. It's instant messaging for a reason :) Indicators might fit for mails, but if I'm using an instant messenger I want to see the message on the fly, be able to view it if I want (by clicking the notification), or simply let it fade out. So it looks like this design is lacking a middle-way of doing things. Aside from that, having 2 (!) servers handling notifications is what I call bloat. Especially now that we're targeting small devices where powersaving and resource consumption DO matter. - Since notifications are passive, they are click-through: when you move the mouse over them, they fade away to become almost transparent and let you click through them to reach any underlying window. Nice indeed, but is that what the user expects? What if the user wants simply to close it without waiting for the timeout? - Since they do not need any interactivity interface, they are drawn using Plasma tooltip SVG. Here are (slightly outdated) screenshots of what they look like: http://people.canonical.com/~agateau/plasma-ayatana-notifications/powerdevi l.png http://people.canonical.com/~agateau/plasma-ayatana-notifications/kopete.p ng An important point: While the patch is integrated in Kubuntu, the default behavior is to use KDE notifications. The user can switch to Ayatana notifications through an option of the system tray configuration dialog (there are even preview buttons to help the user decide). http://people.canonical.com/~agateau/plasma-ayatana-notifications/configura tion.png I attached a patch for you to test if you feel so inclined. I updated it this morning to latest trunk. It is a single large patch because I believe it is easier to try it this way, but if you are interested in the incremental steps, you can find a patchset tarball here: http://people.canonical.com/~agateau/plasma-ayatana-notifications/ As I said I do not expect this to be merged but I would be very happy if some of you just gave it a try for a few hours and maybe find some interesting ideas in it. The queuing and click-through features in particular could be interesting. I was quite skeptic about the idea of passive notifications first, but have since changed my mind after using them for a while. I believe this new approach needs to be tried
Re: Ayatana notifications for Plasma
Am Mittwoch 23 September 2009 18:21:32 schrieb Aurélien Gâteau: Martin Gräßlin wrote: An important point: While the patch is integrated in Kubuntu, the default behavior is to use KDE notifications. The user can switch to Ayatana notifications through an option of the system tray configuration dialog (there are even preview buttons to help the user decide). http://people.canonical.com/~agateau/plasma-ayatana-notifications/config ura tion.png Sorry have you ever considered how that looks to the user? Which user does know about Ayatana? That is a technical term which should not be presented in a UI. I was thinking just like you. My initial patch was labeled Lighter notifications, but Celeste and ScottK (of Kubuntu fame) suggested to put the Ayatana word here to start building a brand on it. Why should a user switch to something else than the KDE notifications? The dialog is completely missing any information on what the notifications provide, what's the difference between the two and in the end it will come down to the one provides different possible positions while the other doesn't It seems you missed the Preview buttons in the dialog. No I didn't and tried it. But still it just shows that it is a different style. It doesn't show anything about the different functionalities. It's just a small preview it's not usage, like a Kopete notfication or a Suspend notification. (btw the last time I tested Karmic the edges monitor didn't get disabled when switching to KDE notifications). Good point. Will fix. If you wanted to give an easy way to test this system while not destroying user experience you should have made this a hidden config file option. I would not call this an easy way to test An easy way to experiment for advanced users while not breaking setups for beginners. And I am realy afraid that there will be the time when Kubuntu switches from KDE notifications to those Ayatana notifications. I realy hope that will never happen. My knowledge of the Kubuntu community makes me quite confident this won't happen. Well maybe the French community is better. But for Germany there is no such thing as a translator for Kubuntu any more. Rosetta did a good job on that :-( Obvious strings like Select System Language in the Language KCM is still untranslated for years. But that's OT. There might be good things about it and it would be great to bring them into the normal KDE notifications but all together I don't want the system. That's all I want you to find. Experiment with it and extract anything which makes sense from it. I have spoken to many Ubuntu users and nobody has said a good word about notifiy-osd, the most common saying was broken by design. As I said, the changes received varied feedback. I met Ubuntu users who really loved notify-osd, and others who don't. Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
Martin Gräßlin wrote: Why should a user switch to something else than the KDE notifications? The dialog is completely missing any information on what the notifications provide, what's the difference between the two and in the end it will come down to the one provides different possible positions while the other doesn't It seems you missed the Preview buttons in the dialog. No I didn't and tried it. But still it just shows that it is a different style. It doesn't show anything about the different functionalities. It's just a small preview it's not usage, like a Kopete notfication or a Suspend notification. The KDE notification has an action, the Ayatana one does not. The Ayatana one also has text explaining how to play with it. And I am realy afraid that there will be the time when Kubuntu switches from KDE notifications to those Ayatana notifications. I realy hope that will never happen. My knowledge of the Kubuntu community makes me quite confident this won't happen. Well maybe the French community is better. But for Germany there is no such thing as a translator for Kubuntu any more. Rosetta did a good job on that :-( Was not talking about translations here. Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
Am Mittwoch 23 September 2009 18:50:41 schrieb Aurélien Gâteau: Martin Gräßlin wrote: Why should a user switch to something else than the KDE notifications? The dialog is completely missing any information on what the notifications provide, what's the difference between the two and in the end it will come down to the one provides different possible positions while the other doesn't It seems you missed the Preview buttons in the dialog. No I didn't and tried it. But still it just shows that it is a different style. It doesn't show anything about the different functionalities. It's just a small preview it's not usage, like a Kopete notfication or a Suspend notification. The KDE notification has an action, the Ayatana one does not. The Ayatana one also has text explaining how to play with it. Exactly and I don't think this is obvious to the user. Yes the KDE preview does show the action while the Notify OSD doesn't. But can you expect that the user will notice that there won't be actions? That's what I meant with showing a Kopete notification. You will only notice the missing action when you want to click on it to jump to your Kopete instance. And that's something you can't show in a preview as it is out of context, out of the workflow. And I am realy afraid that there will be the time when Kubuntu switches from KDE notifications to those Ayatana notifications. I realy hope that will never happen. My knowledge of the Kubuntu community makes me quite confident this won't happen. Well maybe the French community is better. But for Germany there is no such thing as a translator for Kubuntu any more. Rosetta did a good job on that :-( Was not talking about translations here. Ups sorry, mixed it up :-( Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
On September 23, 2009, Dario Freddi wrote: presented as your initiative regardless of Ayatana. However, with Ayatana notifications user interaction is not possible, hence your previous patch was either an unfortunate wrong timing coincidence or strictly related. of course it is strictly related. that this wasn't made obvious in the posting to kde-core-devel is a little odd but also completely what i've come to expect. i didn't really feel like going into on kde-core-devel because i don't think there's anything to gain at this point, but it's no surprise that the people who felt it necessary to come up with such a patch are the people who have removed actions from notifications. 2 + 2 = 4. the desktop workspace would be broken. Hence this makes me really believe you're taking the wrong route here. You are basically pushing 2 different before this gets carried forward into a big thread on this list, it has been made very clear that Canonical is intent on following through on these ideas as they are. it is an insular project without outside participation, which is something they are perfectly free to engage in and i fully support their right to do so. now, whether anyone else outside of Canonical thinks it is better or worse seems to really not matter. any discussion on it is therefore a waste of time. and i'd prefer not to waste our time on this list. btw, i'd recommend to anyone using the Ayatana notifications patch not do so on a laptop running on battery power if you care about getting the most out of a battery charge. -- 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: Ayatana notifications for Plasma
Dario Freddi wrote: I'd like a bit more clarity. The patch you posted about powerdevil was presented as your initiative regardless of Ayatana. However, with Ayatana notifications user interaction is not possible, hence your previous patch was either an unfortunate wrong timing coincidence or strictly related. I don't want to go off-topic or whatever, since about your PowerDevil patch I am quite confused as I really can't decide between a notification and a dialog, but I'd just like to have some clarifications on purpose and goals. I wrote the Powerdevil patch because the notification annoyed me a few times ago personally, but also because it was a problem for Ayatana notifications. Note that with Ayatana notifications, I mean either notify-osd or the Plasma patch I posted. I should have mentioned it in my first message, and I addressed this (probably not enough) in one of the answers I made to Aaron, where I mentioned the Powerdevil notification was a bigger problem for Kubuntu users running notify-osd. I have been preparing the email about Ayatana notifications for a few days and wanted to keep them separate, but when I read Sebas mentioning Ayatana notifications, I decided to rush it out because as I said, I thought it would be more correct if I presented this work to the Plasma devs myself. I am sorry for this bad timing. I really did not try to have the Powerdevil patch upstreamed before presenting the Ayatana patch. - Notifications are passive: they do not feature actions or close buttons. This is probably the most controversial bit. What about IM? Without what you presented in your post about Indicators, the desktop workspace would be broken. Hence this makes me really believe you're taking the wrong route here. You are basically pushing 2 different kind of notifications (with 2 API and 2 underlying systems) the developer has to choose (and learn) to display informations. Yes, the indicators are meant to complement the passive notifications. And the situation of PowerDevil is the one that demonstrates the weakness of this design. Putting aside the scope of the notification, the side effects and whatever, my question is: would it be possible, with the current Ayatana spec featuring indicators to achieve something like powerdevil notification without a dialog? I bet the answer is no. Indicators would be too much, and with this spec you are defining (IMHO) the following points: 1 - Everything that requires user interaction can be delayed until X - wrong. Unless you decide that in situations where the user has to provide fast feedback you want to use dialogs 2 - Everything short-noticed should be passive - wrong. It's instant messaging for a reason :) Indicators might fit for mails, but if I'm using an instant messenger I want to see the message on the fly, be able to view it if I want (by clicking the notification), or simply let it fade out. This was my exact feelings before giving the passive notifications a try. What I realized is that active notifications introduce a urge to act: you must act by clicking the button before the notification goes away. If you are using passive notifications plus a system like the indicators, you do not have this urge to act: you can read the IM text of the notification and take your time to act because the indicator will provide you a permanent access to the incoming chat message. So it looks like this design is lacking a middle-way of doing things. Aside from that, having 2 (!) servers handling notifications is what I call bloat. Especially now that we're targeting small devices where powersaving and resource consumption DO matter. They are just applets listening to DBus communications. I would not call this bloat (what I would call bloat is not having indicators and implemented in term of systray, but that's another story). On a really small device, neither KDE nor Ayatana notifications will fit the needs anyway. - Since notifications are passive, they are click-through: when you move the mouse over them, they fade away to become almost transparent and let you click through them to reach any underlying window. Nice indeed, but is that what the user expects? What if the user wants simply to close it without waiting for the timeout? The need to close is usually motivated by the need to reach what is under the notification. Using it for a while I did not felt the need to close them. Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
On Wed, Sep 23, 2009 at 1:08 PM, Aaron J. Seigo ase...@kde.org wrote: On September 23, 2009, Dario Freddi wrote: presented as your initiative regardless of Ayatana. However, with Ayatana notifications user interaction is not possible, hence your previous patch was either an unfortunate wrong timing coincidence or strictly related. of course it is strictly related. that this wasn't made obvious in the posting to kde-core-devel is a little odd but also completely what i've come to expect. i didn't really feel like going into on kde-core-devel because i don't think there's anything to gain at this point, but it's no surprise that the people who felt it necessary to come up with such a patch are the people who have removed actions from notifications. 2 + 2 = 4. the desktop workspace would be broken. Hence this makes me really believe you're taking the wrong route here. You are basically pushing 2 different before this gets carried forward into a big thread on this list, it has been made very clear that Canonical is intent on following through on these ideas as they are. it is an insular project without outside participation, which is something they are perfectly free to engage in and i fully support their right to do so. The Ayatana notifcations are installed by default but not configured by default in Kubuntu Karmic for *testing* purposes (this wasn't clear in Aurelian's email). We (Kubuntu) didn't want to provide it by default and adding a configuration option was a compromise we made with the Canonical Design team who wanted to see how the system works for KDE users used to actions in notifications (not really the best evaluation method, but whatever). If it ends up that the Ayatana notifcations fail in a major way, then the configuration option and functionality will (in theory) be removed from defaults (but users will still be able to install as an addon it if they want). Canonical did a really bad job involving upstreams in the design process and are now trying to make up for it by keeping upstreams aware of what is going on. It may be too little too late, but if we (KDE) can at least humor them, then they will be more willing to listen how they can make their software work better with KDE (even if it doesn't follow what KDE wants to do) instead of just forcing Kubuntu to ship whatever they produce. -- Celeste Lyn Paul KDE Usability Project KDE e.V. Board of Directors www.kde.org ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
Aaron J. Seigo wrote: On September 23, 2009, Dario Freddi wrote: presented as your initiative regardless of Ayatana. However, with Ayatana notifications user interaction is not possible, hence your previous patch was either an unfortunate wrong timing coincidence or strictly related. of course it is strictly related. that this wasn't made obvious in the posting to kde-core-devel is a little odd but also completely what i've come to expect. i didn't really feel like going into on kde-core-devel because i don't think there's anything to gain at this point, but it's no surprise that the people who felt it necessary to come up with such a patch are the people who have removed actions from notifications. 2 + 2 = 4. I just explained myself about this in my answer to Dario. As I said it was poor timing and I recon I should have been handled this in a different way. the desktop workspace would be broken. Hence this makes me really believe you're taking the wrong route here. You are basically pushing 2 different before this gets carried forward into a big thread on this list, it has been made very clear that Canonical is intent on following through on these ideas as they are. it is an insular project without outside participation, which is something they are perfectly free to engage in and i fully support their right to do so. I try to reach out with this mail. If we were not looking for outside participation, you would not find me regularly trying to upstream changes. And things can change too. For example the more I think about indicators, the more I believe you are right in that they should be implemented in terms of an evolution of the system tray. Getting other members of my team to think the same is another story... btw, i'd recommend to anyone using the Ayatana notifications patch not do so on a laptop running on battery power if you care about getting the most out of a battery charge. I guess you mean I made a stupid mistake in my code. Can you explain what it is? Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
On Wednesday 23 September 2009, Aurélien Gâteau wrote: Hi, I would like to present to you some work I have been doing for Canonical regarding notifications in Plasma. Before going further, let me state that my goal with this mail is not to get this work incorporated upstream, as I understand the Plasma project have a different position than Canonical on the subject of notifications. I decided to write this mail because I believe it is more correct to let you know about it in a more personal way rather than you discovering it in a blog post or a Kubuntu review. This work provides an implementation of Ayatana notifications for Plasma (Ayatana is the name of a Canonical project to improve user experience on Ubuntu and derivatives). Ayatana notifications have the following characteristics: every other consideration aside, i feel that it would have been -far- easier to mantain if the systray patch just consisted in notifications disabling and provide a totally separate daemon for that kind of notifications - Notifications are queued instead of stacked. This helps reduce the spamming feeling. - Notifications are passive: they do not feature actions or close buttons. This is probably the most controversial bit. - Since notifications are passive, they are click-through: when you move the mouse over them, they fade away to become almost transparent and let you click through them to reach any underlying window. - Since they do not need any interactivity interface, they are drawn using Plasma tooltip SVG. Here are (slightly outdated) screenshots of what they look like: http://people.canonical.com/~agateau/plasma-ayatana-notifications/powerdevi l.png http://people.canonical.com/~agateau/plasma-ayatana-notifications/kopete.pn g An important point: While the patch is integrated in Kubuntu, the default behavior is to use KDE notifications. The user can switch to Ayatana notifications through an option of the system tray configuration dialog (there are even preview buttons to help the user decide). http://people.canonical.com/~agateau/plasma-ayatana-notifications/configura tion.png I attached a patch for you to test if you feel so inclined. I updated it this morning to latest trunk. It is a single large patch because I believe it is easier to try it this way, but if you are interested in the incremental steps, you can find a patchset tarball here: http://people.canonical.com/~agateau/plasma-ayatana-notifications/ As I said I do not expect this to be merged but I would be very happy if some of you just gave it a try for a few hours and maybe find some interesting ideas in it. The queuing and click-through features in particular could be interesting. I was quite skeptic about the idea of passive notifications first, but have since changed my mind after using them for a while. I believe this new approach needs to be tried for one to make an informed opinion on it. The feedback I got from Kubuntu Karmic users is varied: some like it a lot, other don't. Please let me know your opinion on this. Regards, Aurélien -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Nepomuk+Plasma review
Hi all, Here is the preview of the nepomuk activities for plasma started at T3. This is not in any sense a final version, that is, it will need a lot more testing (with nepomuk both enabled and disabled). Currently, I'm hunting a few bugs left related to activity storing. The good thing is that, at least for me, it doesn't break any current functionality of plasma (no more displaying the UUIDs as names of the activity on the desktop and in the menus). The point of this mail is to post the changes for a very early API review. Some things needed to be deprecated in Context, a new singleton class (GlobalContext) for managing all the activities so that Context doesn't have a lot static methods with weird names since the current methods can't be changed. The other reason for creating GlobalContext instead of adding static methods to Context is that I needed it to have signals... The nepomuk service is currently located here: http://websvn.kde.org/trunk/playground/base/nepomuk-kde/libactivities/ It is also ready for a review and possible moving to kdereview and kdebase/workspace (only the server part for the time being) Cheerio base_workspace_plasma__nepomukcontext.diff.bz2 Description: application/bzip libs_plasma__nepomukcontext.diff.bz2 Description: application/bzip ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Nepomuk+Plasma review
On September 23, 2009 11:04:38 Ivan Čukić wrote: Hi all, Here is the preview of the nepomuk activities for plasma started at T3. any chance you could put it up on reviewboard? :) -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
On September 23, 2009, Aurélien Gâteau wrote: Aaron J. Seigo wrote: before this gets carried forward into a big thread on this list, it has been made very clear that Canonical is intent on following through on these ideas as they are. it is an insular project without outside participation, which is something they are perfectly free to engage in and i fully support their right to do so. I try to reach out with this mail. If we were not looking for outside participation, you would not find me regularly trying to upstream changes. sending patches and saying hey, this is what we're doing when there is no intention of modification of the design or harmonizing it with the work of those you are sending the patches to is only notification of your work (excuse the pun ;). that is more than some do, and i appreciate that. it is not, however, an invitation to the outside to participate on working on the design your patches espouse. (where your refers to Ayatana, not you personally :) that is a completely fair and reasonable thing for Ayatana to do, but it does make Ayatana insular and closed to true outside participation. by contrast, the design of Plasma itself has been formed and influenced by a large number of people, almost all of whom have self-selected and have entered into the core of the project simply through their efforts rather than my express permission. on the matter of notifications, we have a fundamental difference in design and expectations and simply showing each other our code isn't going to change that. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
On September 23, 2009, Marco Martin wrote: every other consideration aside, i feel that it would have been -far- easier to mantain if the systray patch just consisted in notifications disabling and provide a totally separate daemon for that kind of notifications unless i'm misremembering things, this is also what i suggested to the people working on this when the Ayatana notifications design was first announced. -- 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
Review Request: Plasma + Nepomuk - plasma patch - attempt 1
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1700/ --- Review request for Plasma. Summary --- Nepomuk-based storage of plasma activities (see http://reviewboard.kde.org/r/1699/) Diffs - /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/containment.cpp 1027129 /trunk/KDE/kdebase/workspace/plasma/netbook/shell/plasmaapp.cpp 1027129 Diff: http://reviewboard.kde.org/r/1700/diff Testing --- Needs more testing Thanks, Ivan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Plasma + Nepomuk - libplasma patch - attempt 1
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/ --- Review request for Plasma. Summary --- Nepomuk-based storage of plasma activities Diffs - /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1027137 /trunk/KDE/kdelibs/plasma/applet.cpp 1027137 /trunk/KDE/kdelibs/plasma/containment.h 1027137 /trunk/KDE/kdelibs/plasma/containment.cpp 1027137 /trunk/KDE/kdelibs/plasma/context.h 1027137 /trunk/KDE/kdelibs/plasma/context.cpp 1027137 /trunk/KDE/kdelibs/plasma/private/activitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/activitieshandler.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/context_p.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/desktoptoolbox.cpp 1027137 /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/nepomukactivitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/nepomukactivitieshandler.cpp PRE-CREATION Diff: http://reviewboard.kde.org/r/1699/diff Testing --- Needs more testing Thanks, Ivan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Nepomuk+Plasma review
any chance you could put it up on reviewboard? :) Ok, although it is not yet meant for merging. http://reviewboard.kde.org/r/1699/ http://reviewboard.kde.org/r/1700/ Cheerio ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
Aaron J. Seigo a écrit : On September 23, 2009, Marco Martin wrote: every other consideration aside, i feel that it would have been -far- easier to mantain if the systray patch just consisted in notifications disabling and provide a totally separate daemon for that kind of notifications unless i'm misremembering things, this is also what i suggested to the people working on this when the Ayatana notifications design was first announced. My first implementation was doing exactly this. But I was told (by a Plasma dev) it was not a good idea. Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Plasma + Nepomuk - libplasma patch - attempt 1
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/#review2433 --- i'm going to concentrate on the GlobalContext class mostly here. as it stands, GlobalContext seems like an activity manager; where activity is defined as a named object stored in nepomuk. is that correct? if so, then it's not really a global Context object. perhaps an ActivityManager? or a ContextManager? it doesn't include location information either, which Plasma::Context should at some point here. GlobalContext public API may only need to be: a signal noting when the active global context changes; a way to list available activities (mostly because the method in Plasma::Context isn't static) ... /trunk/KDE/kdelibs/plasma/containment.cpp http://reviewboard.kde.org/r/1699/#comment1737 kDebug? :) /trunk/KDE/kdelibs/plasma/context.h http://reviewboard.kde.org/r/1699/#comment1738 ensureActivityExists? or maybe ensureActivity and createActivity could be merged? maybe something like: activityId(const QString name, const QString expectedId = QString());? or perhaps these can remain as they are but be private API? it should only really be needed by Context when setting the current activity in that Context? /trunk/KDE/kdelibs/plasma/context.h http://reviewboard.kde.org/r/1699/#comment1753 or perhaps: forActivity(id)-setActiveContext(true);? /trunk/KDE/kdelibs/plasma/context.h http://reviewboard.kde.org/r/1699/#comment1739 is this equivalent to currentContext()-name()? /trunk/KDE/kdelibs/plasma/context.h http://reviewboard.kde.org/r/1699/#comment1740 i'd personally expect these as static methods in Plasma::Context, e.g.: Plasma::Context::contextForActivity(QString) Plasma::Context::activeContext() /trunk/KDE/kdelibs/plasma/context.h http://reviewboard.kde.org/r/1699/#comment1749 is this equivalent to: forActivity(id)-name(); ? /trunk/KDE/kdelibs/plasma/context.h http://reviewboard.kde.org/r/1699/#comment1747 maybe this could emit a Context object instead of a QString id? /trunk/KDE/kdelibs/plasma/context.h http://reviewboard.kde.org/r/1699/#comment1741 wouldn't this create an activity and associate it with this Context? /trunk/KDE/kdelibs/plasma/context.h http://reviewboard.kde.org/r/1699/#comment1742 setCurrentActivityId()? and then there could be a corresponding activityId(). - Aaron On 2009-09-23 20:19:36, Ivan Cukic wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/ --- (Updated 2009-09-23 20:19:36) Review request for Plasma. Summary --- Nepomuk-based storage of plasma activities Diffs - /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1027137 /trunk/KDE/kdelibs/plasma/applet.cpp 1027137 /trunk/KDE/kdelibs/plasma/containment.h 1027137 /trunk/KDE/kdelibs/plasma/containment.cpp 1027137 /trunk/KDE/kdelibs/plasma/context.h 1027137 /trunk/KDE/kdelibs/plasma/context.cpp 1027137 /trunk/KDE/kdelibs/plasma/private/activitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/activitieshandler.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/context_p.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/desktoptoolbox.cpp 1027137 /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/nepomukactivitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/nepomukactivitieshandler.cpp PRE-CREATION Diff: http://reviewboard.kde.org/r/1699/diff Testing --- Needs more testing Thanks, Ivan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Plasma + Nepomuk - libplasma patch - attempt 1
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/#review2435 --- I don't think I really grok what global is. the current desktop? the current screen? with multiple screens and/or different activities on different virtual desktops, we can have more than one plasma activity visible at once... how does that relate to nepomuk activities? /trunk/KDE/kdelibs/plasma/containment.h http://reviewboard.kde.org/r/1699/#comment1744 s/activity/activityId to be extra clear. I don't like how activity sometimes means the name and sometimes the ID. /trunk/KDE/kdelibs/plasma/containment.h http://reviewboard.kde.org/r/1699/#comment1745 does this return the id or the name? and why's there no function to set just the name? /trunk/KDE/kdelibs/plasma/context.h http://reviewboard.kde.org/r/1699/#comment1756 add a comment saying this class is @since 4.4 /trunk/KDE/kdelibs/plasma/context.h http://reviewboard.kde.org/r/1699/#comment1751 the function name could be better. maybe just activity. and what does it do if an activity with that id and a different name exists? /trunk/KDE/kdelibs/plasma/context.h http://reviewboard.kde.org/r/1699/#comment1754 don't start function names with for. either activityContext or contextForActivity /trunk/KDE/kdelibs/plasma/context.cpp http://reviewboard.kde.org/r/1699/#comment1757 oi! we use kDebug around here :) /trunk/KDE/kdelibs/plasma/context.cpp http://reviewboard.kde.org/r/1699/#comment1758 so if nepomuk crashes and restarts itself, I have to restart plasma? plasma should watch for nepomuk appearing and disappearing. /trunk/KDE/kdelibs/plasma/context.cpp http://reviewboard.kde.org/r/1699/#comment1759 you set realID to one thing, then another. skip this unnecessary assignment. /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.cpp http://reviewboard.kde.org/r/1699/#comment1760 use kDebug - Chani On 2009-09-23 20:19:36, Ivan Cukic wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/ --- (Updated 2009-09-23 20:19:36) Review request for Plasma. Summary --- Nepomuk-based storage of plasma activities Diffs - /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1027137 /trunk/KDE/kdelibs/plasma/applet.cpp 1027137 /trunk/KDE/kdelibs/plasma/containment.h 1027137 /trunk/KDE/kdelibs/plasma/containment.cpp 1027137 /trunk/KDE/kdelibs/plasma/context.h 1027137 /trunk/KDE/kdelibs/plasma/context.cpp 1027137 /trunk/KDE/kdelibs/plasma/private/activitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/activitieshandler.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/context_p.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/desktoptoolbox.cpp 1027137 /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/nepomukactivitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/nepomukactivitieshandler.cpp PRE-CREATION Diff: http://reviewboard.kde.org/r/1699/diff Testing --- Needs more testing Thanks, Ivan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Plasma + Nepomuk - libplasma patch - attempt 1
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/#review2439 --- it's late here... just two quick things came to my mind :) /trunk/KDE/kdelibs/plasma/containment.cpp http://reviewboard.kde.org/r/1699/#comment1761 is the name given now by the desktop settings dialog going to be an identifier rather than a name? seems qute a behavioural change for this function /trunk/KDE/kdelibs/plasma/private/activitieshandler.h http://reviewboard.kde.org/r/1699/#comment1763 maybe should be done with a bool activityExists() function+createactivity? but this shortcut could be handy anyways, hmm... a check function would make sense anyways tough - Marco On 2009-09-23 20:19:36, Ivan Cukic wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/ --- (Updated 2009-09-23 20:19:36) Review request for Plasma. Summary --- Nepomuk-based storage of plasma activities Diffs - /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1027137 /trunk/KDE/kdelibs/plasma/applet.cpp 1027137 /trunk/KDE/kdelibs/plasma/containment.h 1027137 /trunk/KDE/kdelibs/plasma/containment.cpp 1027137 /trunk/KDE/kdelibs/plasma/context.h 1027137 /trunk/KDE/kdelibs/plasma/context.cpp 1027137 /trunk/KDE/kdelibs/plasma/private/activitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/activitieshandler.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/context_p.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/desktoptoolbox.cpp 1027137 /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/nepomukactivitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/nepomukactivitieshandler.cpp PRE-CREATION Diff: http://reviewboard.kde.org/r/1699/diff Testing --- Needs more testing Thanks, Ivan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Plasma + Nepomuk - libplasma patch - attempt 1
On 2009-09-23 21:28:50, Aaron Seigo wrote: i'm going to concentrate on the GlobalContext class mostly here. as it stands, GlobalContext seems like an activity manager; where activity is defined as a named object stored in nepomuk. is that correct? if so, then it's not really a global Context object. perhaps an ActivityManager? or a ContextManager? it doesn't include location information either, which Plasma::Context should at some point here. GlobalContext public API may only need to be: a signal noting when the active global context changes; a way to list available activities (mostly because the method in Plasma::Context isn't static) ... I'd go for ContextManager if we are going to add location etc. to it. On 2009-09-23 21:28:50, Aaron Seigo wrote: /trunk/KDE/kdelibs/plasma/containment.cpp, line 1846 http://reviewboard.kde.org/r/1699/diff/1/?file=11890#file11890line1846 kDebug? :) I stopped using kdebug for some time now for some superstitious reasons :) On 2009-09-23 21:28:50, Aaron Seigo wrote: /trunk/KDE/kdelibs/plasma/context.h, line 67 http://reviewboard.kde.org/r/1699/diff/1/?file=11891#file11891line67 ensureActivityExists? or maybe ensureActivity and createActivity could be merged? maybe something like: activityId(const QString name, const QString expectedId = QString());? or perhaps these can remain as they are but be private API? it should only really be needed by Context when setting the current activity in that Context? It would be ok to rename to ensureActivityExists activityId is a bit to vague - it doesn't say what it does at all (it looks like a getter for a field while it can create a new activity) The idea was for an application/applet/whatever to be able to create a new activity - then, plasma (and other apps) would react to that, by creating a new plasma-activity. On 2009-09-23 21:28:50, Aaron Seigo wrote: /trunk/KDE/kdelibs/plasma/context.h, line 83 http://reviewboard.kde.org/r/1699/diff/1/?file=11891#file11891line83 is this equivalent to currentContext()-name()? hm... Context doesn't have a name. Containment has, and it can be different - if the activity name is empty, the Containment name is some generic string (Desktop/Panel...) On 2009-09-23 21:28:50, Aaron Seigo wrote: /trunk/KDE/kdelibs/plasma/context.h, line 78 http://reviewboard.kde.org/r/1699/diff/1/?file=11891#file11891line78 or perhaps: forActivity(id)-setActiveContext(true);? This looks appealing. The problem is that the setActiveContext would have to trigger the context/activity changed signal in the manager. On 2009-09-23 21:28:50, Aaron Seigo wrote: /trunk/KDE/kdelibs/plasma/context.h, lines 93-99 http://reviewboard.kde.org/r/1699/diff/1/?file=11891#file11891line93 i'd personally expect these as static methods in Plasma::Context, e.g.: Plasma::Context::contextForActivity(QString) Plasma::Context::activeContext() Ok On 2009-09-23 21:28:50, Aaron Seigo wrote: /trunk/KDE/kdelibs/plasma/context.h, line 105 http://reviewboard.kde.org/r/1699/diff/1/?file=11891#file11891line105 is this equivalent to: forActivity(id)-name(); ? Again, the context doesn't have a name On 2009-09-23 21:28:50, Aaron Seigo wrote: /trunk/KDE/kdelibs/plasma/context.h, line 137 http://reviewboard.kde.org/r/1699/diff/1/?file=11891#file11891line137 wouldn't this create an activity and associate it with this Context? It could, although the name doesn't suggest it. On 2009-09-23 21:28:50, Aaron Seigo wrote: /trunk/KDE/kdelibs/plasma/context.h, line 151 http://reviewboard.kde.org/r/1699/diff/1/?file=11891#file11891line151 setCurrentActivityId()? and then there could be a corresponding activityId(). the setCurrentActivity is an old function - so we can't really change the name. We could deprecate it as well, and introduce the one with the ID but (IMO) that would be too much... I've mostly made decisions with a thought that I should change the api as little as possible. - Ivan --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/#review2433 --- On 2009-09-23 20:19:36, Ivan Cukic wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/ --- (Updated 2009-09-23 20:19:36) Review request for Plasma. Summary --- Nepomuk-based storage of plasma activities Diffs - /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1027137 /trunk/KDE/kdelibs/plasma/applet.cpp 1027137 /trunk/KDE/kdelibs/plasma/containment.h 1027137
Re: Review Request: Plasma + Nepomuk - libplasma patch - attempt 1
On 2009-09-23 22:01:11, Marco Martin wrote: /trunk/KDE/kdelibs/plasma/containment.cpp, line 1839 http://reviewboard.kde.org/r/1699/diff/1/?file=11890#file11890line1839 is the name given now by the desktop settings dialog going to be an identifier rather than a name? seems qute a behavioural change for this function Yes, there is a behavioural change - mostly because the activity names are not unique (empty by default) which is the reason everything is done by IDs. I agree that changing the behaviour is a bad thing, but almost nobody used these classes (there wasn't that much to be used - they were mostly empty) On 2009-09-23 22:01:11, Marco Martin wrote: /trunk/KDE/kdelibs/plasma/private/activitieshandler.h, line 76 http://reviewboard.kde.org/r/1699/diff/1/?file=11893#file11893line76 maybe should be done with a bool activityExists() function+createactivity? but this shortcut could be handy anyways, hmm... a check function would make sense anyways tough ok about the check function. - Ivan --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/#review2439 --- On 2009-09-23 20:19:36, Ivan Cukic wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/ --- (Updated 2009-09-23 20:19:36) Review request for Plasma. Summary --- Nepomuk-based storage of plasma activities Diffs - /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1027137 /trunk/KDE/kdelibs/plasma/applet.cpp 1027137 /trunk/KDE/kdelibs/plasma/containment.h 1027137 /trunk/KDE/kdelibs/plasma/containment.cpp 1027137 /trunk/KDE/kdelibs/plasma/context.h 1027137 /trunk/KDE/kdelibs/plasma/context.cpp 1027137 /trunk/KDE/kdelibs/plasma/private/activitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/activitieshandler.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/context_p.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/desktoptoolbox.cpp 1027137 /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/nepomukactivitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/nepomukactivitieshandler.cpp PRE-CREATION Diff: http://reviewboard.kde.org/r/1699/diff Testing --- Needs more testing Thanks, Ivan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: devicenotifier with qgw
On Sunday 20 September 2009 18:09:20 Aaron J. Seigo wrote: On September 20, 2009, Aaron J. Seigo wrote: On September 19, 2009, Jacopo De Simoi wrote: 1) we need to activate the items on hover, but with the itemBackground animation delay, hoverEvent is not good anymore to track that. I can see two solutons: - itemBackground should send some signal when its animation finishes, something like targetReached(qgi *) where the pointer would be null if the target was not an item. - itemBackground should make publicly available the animation time, so that we can animate accordingly fadein/fadeout in each item. i can see uses for both, really. the problem with providing an animation time is that it will never be perfectly timed; what would be better is for another thing that occurred to me just now while responding to David Placio's email: perhaps you could create a generic listing widget for inclusion in lib plasma and then use ItemBackground internally to make this magic work without having to export more API for it? not sure if that would work out perfectly, but if having such a list widget in libplasma would make this easier, let's consider doing that. Just to make sure I got what you meant: are you thinking of some widget which you would add qgi to as if it were a layout (for instance) and would allow for scrolling and stuff like that? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: devicenotifier with qgw
On Sunday 20 September 2009 17:30:36 Aaron J. Seigo wrote: On September 19, 2009, Jacopo De Simoi wrote: 1) we need to activate the items on hover, but with the itemBackground animation delay, hoverEvent is not good anymore to track that. I can see two solutons: - itemBackground should send some signal when its animation finishes, something like targetReached(qgi *) where the pointer would be null if the target was not an item. - itemBackground should make publicly available the animation time, so that we can animate accordingly fadein/fadeout in each item. i can see uses for both, really. the problem with providing an animation time is that it will never be perfectly timed; what would be better is for the item background to emit a signal whenever it gets an animation update due to its internal animation. then another animation can synchronize with it. perhaps emit something between 0 and 1, with 1 == target has been reached? Actually I like this idea, it can be also very easily implemented, I'll play around with it... ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: devicenotifier with qgw
On September 23, 2009, Jacopo De Simoi wrote: Just to make sure I got what you meant: are you thinking of some widget which you would add qgi to as if it were a layout (for instance) and would allow for scrolling and stuff like that? yes, along with some QAbstractItemModel hooks. -- 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: Plasma + Nepomuk - libplasma patch - attempt 1
On 2009-09-23 21:28:50, Aaron Seigo wrote: /trunk/KDE/kdelibs/plasma/context.h, line 105 http://reviewboard.kde.org/r/1699/diff/1/?file=11891#file11891line105 is this equivalent to: forActivity(id)-name(); ? wrote: Again, the context doesn't have a name what exactly is the difference between the context and the activity? - Chani --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/#review2433 --- On 2009-09-23 20:19:36, Ivan Cukic wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/ --- (Updated 2009-09-23 20:19:36) Review request for Plasma. Summary --- Nepomuk-based storage of plasma activities Diffs - /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1027137 /trunk/KDE/kdelibs/plasma/applet.cpp 1027137 /trunk/KDE/kdelibs/plasma/containment.h 1027137 /trunk/KDE/kdelibs/plasma/containment.cpp 1027137 /trunk/KDE/kdelibs/plasma/context.h 1027137 /trunk/KDE/kdelibs/plasma/context.cpp 1027137 /trunk/KDE/kdelibs/plasma/private/activitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/activitieshandler.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/context_p.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/desktoptoolbox.cpp 1027137 /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/nepomukactivitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/nepomukactivitieshandler.cpp PRE-CREATION Diff: http://reviewboard.kde.org/r/1699/diff Testing --- Needs more testing Thanks, Ivan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Plasma + Nepomuk - libplasma patch - attempt 1
On 2009-09-23 22:01:11, Marco Martin wrote: /trunk/KDE/kdelibs/plasma/containment.cpp, line 1839 http://reviewboard.kde.org/r/1699/diff/1/?file=11890#file11890line1839 is the name given now by the desktop settings dialog going to be an identifier rather than a name? seems qute a behavioural change for this function wrote: Yes, there is a behavioural change - mostly because the activity names are not unique (empty by default) which is the reason everything is done by IDs. I agree that changing the behaviour is a bad thing, but almost nobody used these classes (there wasn't that much to be used - they were mostly empty) there's one downside to this - if I run out of space for applets on my plasma plasma-activity I can't just create a second one and give it the same name and have it share context. but I assume UIDs solve a lot more problems than this one little limitation they introduce. - Chani --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/#review2439 --- On 2009-09-23 20:19:36, Ivan Cukic wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/ --- (Updated 2009-09-23 20:19:36) Review request for Plasma. Summary --- Nepomuk-based storage of plasma activities Diffs - /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1027137 /trunk/KDE/kdelibs/plasma/applet.cpp 1027137 /trunk/KDE/kdelibs/plasma/containment.h 1027137 /trunk/KDE/kdelibs/plasma/containment.cpp 1027137 /trunk/KDE/kdelibs/plasma/context.h 1027137 /trunk/KDE/kdelibs/plasma/context.cpp 1027137 /trunk/KDE/kdelibs/plasma/private/activitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/activitieshandler.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/context_p.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/desktoptoolbox.cpp 1027137 /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/nepomukactivitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/nepomukactivitieshandler.cpp PRE-CREATION Diff: http://reviewboard.kde.org/r/1699/diff Testing --- Needs more testing Thanks, Ivan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
On September 23, 2009, Aurélien Gâteau wrote: Aaron J. Seigo a écrit : On September 23, 2009, Marco Martin wrote: every other consideration aside, i feel that it would have been -far- easier to mantain if the systray patch just consisted in notifications disabling and provide a totally separate daemon for that kind of notifications unless i'm misremembering things, this is also what i suggested to the people working on this when the Ayatana notifications design was first announced. My first implementation was doing exactly this. But I was told (by a Plasma dev) it was not a good idea. what i'm pretty sure i said (could be wrong, was a # of months ago) was that the option in the system tray could be defaulted very easily to off and the new style of notifications could run separate from it. it could make sense to share the notifications DataEngine, depending on how that part was written, but modifications to the systray widget should not have been necessary. i pointed out (i think to Bo?) that the systray was designed to easily get out of the way of notifications and that one could watch for the notifications host dbus service becoming available. -- 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: Plasma + Nepomuk - libplasma patch - attempt 1
On 2009-09-23 21:28:50, Aaron Seigo wrote: /trunk/KDE/kdelibs/plasma/context.h, line 78 http://reviewboard.kde.org/r/1699/diff/1/?file=11891#file11891line78 or perhaps: forActivity(id)-setActiveContext(true);? wrote: This looks appealing. The problem is that the setActiveContext would have to trigger the context/activity changed signal in the manager. that can be done behind the scenes quite easily. i'm thinking more about the public API here rather than the implementation; we often make some parts of the internal implementation a little uglier so that the public API is more consistent and pretty. On 2009-09-23 21:28:50, Aaron Seigo wrote: /trunk/KDE/kdelibs/plasma/context.h, line 67 http://reviewboard.kde.org/r/1699/diff/1/?file=11891#file11891line67 ensureActivityExists? or maybe ensureActivity and createActivity could be merged? maybe something like: activityId(const QString name, const QString expectedId = QString());? or perhaps these can remain as they are but be private API? it should only really be needed by Context when setting the current activity in that Context? wrote: It would be ok to rename to ensureActivityExists activityId is a bit to vague - it doesn't say what it does at all (it looks like a getter for a field while it can create a new activity) The idea was for an application/applet/whatever to be able to create a new activity - then, plasma (and other apps) would react to that, by creating a new plasma-activity. well, the method fetches the id for a given activity name. in that sense, it seems like a getter. that it may need to create the activity in the nepomuk store is almost a detail? as for creating a new activity, it really seems more natural, at least to me, to create Context objects and manage those. the only complication is that activities have IDs and they have names. *thinks* you know, it seems to me that applications should ALWAYS be refering to activities by ID. i can't think of a single use case where application code should rely on the activity's name. that's something for the user, isn't it? in plasma-desktop, we need to keep a mapping of Containment ID to Activity ID (or, Context::id()), but that's all. On 2009-09-23 21:28:50, Aaron Seigo wrote: /trunk/KDE/kdelibs/plasma/context.h, line 83 http://reviewboard.kde.org/r/1699/diff/1/?file=11891#file11891line83 is this equivalent to currentContext()-name()? wrote: hm... Context doesn't have a name. Containment has, and it can be different - if the activity name is empty, the Containment name is some generic string (Desktop/Panel...) the name of a Context should be the name associated with the Activity, if any, correct? i don't think we should think too much bout Containment is doing (other than we want to map Containment - Context) On 2009-09-23 21:28:50, Aaron Seigo wrote: /trunk/KDE/kdelibs/plasma/context.h, line 105 http://reviewboard.kde.org/r/1699/diff/1/?file=11891#file11891line105 is this equivalent to: forActivity(id)-name(); ? wrote: Again, the context doesn't have a name wrote: what exactly is the difference between the context and the activity? context is a combination of the activity and the physical location of the machine/user. it may eventually contain other items (presence?) On 2009-09-23 21:28:50, Aaron Seigo wrote: /trunk/KDE/kdelibs/plasma/context.h, line 151 http://reviewboard.kde.org/r/1699/diff/1/?file=11891#file11891line151 setCurrentActivityId()? and then there could be a corresponding activityId(). wrote: the setCurrentActivity is an old function - so we can't really change the name. We could deprecate it as well, and introduce the one with the ID but (IMO) that would be too much... I've mostly made decisions with a thought that I should change the api as little as possible. fair enough. :) - Aaron --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/#review2433 --- On 2009-09-23 20:19:36, Ivan Cukic wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/ --- (Updated 2009-09-23 20:19:36) Review request for Plasma. Summary --- Nepomuk-based storage of plasma activities Diffs - /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1027137 /trunk/KDE/kdelibs/plasma/applet.cpp 1027137 /trunk/KDE/kdelibs/plasma/containment.h 1027137 /trunk/KDE/kdelibs/plasma/containment.cpp 1027137 /trunk/KDE/kdelibs/plasma/context.h 1027137
Re: Review Request: Plasma + Nepomuk - libplasma patch - attempt 1
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/#review2446 --- /trunk/KDE/kdelibs/plasma/context.h http://reviewboard.kde.org/r/1699/#comment1787 perhaps this should be a QHashQString, QString for id - name of the activities? or maybe even a QHashQUuid, QString? - Aaron On 2009-09-23 20:19:36, Ivan Cukic wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/ --- (Updated 2009-09-23 20:19:36) Review request for Plasma. Summary --- Nepomuk-based storage of plasma activities Diffs - /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1027137 /trunk/KDE/kdelibs/plasma/applet.cpp 1027137 /trunk/KDE/kdelibs/plasma/containment.h 1027137 /trunk/KDE/kdelibs/plasma/containment.cpp 1027137 /trunk/KDE/kdelibs/plasma/context.h 1027137 /trunk/KDE/kdelibs/plasma/context.cpp 1027137 /trunk/KDE/kdelibs/plasma/private/activitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/activitieshandler.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/context_p.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/desktoptoolbox.cpp 1027137 /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/nepomukactivitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/nepomukactivitieshandler.cpp PRE-CREATION Diff: http://reviewboard.kde.org/r/1699/diff Testing --- Needs more testing Thanks, Ivan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Plasma + Nepomuk - libplasma patch - attempt 1
On 2009-09-23 21:28:50, Aaron Seigo wrote: /trunk/KDE/kdelibs/plasma/context.h, line 105 http://reviewboard.kde.org/r/1699/diff/1/?file=11891#file11891line105 is this equivalent to: forActivity(id)-name(); ? wrote: Again, the context doesn't have a name wrote: what exactly is the difference between the context and the activity? wrote: context is a combination of the activity and the physical location of the machine/user. it may eventually contain other items (presence?) and yet each activity has its own context? something doesn't feel right here. so... we have global contexty things like physical location... then we have a bunch of nepomuk actvitites which have a UID and a name and some more context associated with them (what context?), and map to plasma activity containments... and somewhere in the middle of all this we have an old Context class we've got to work with because of BC requirements. adding to my confusion is the fact that we seem to be using the same words for different things again. *shrug* maybe I should just wait until it's done... it just feels like something's not right. - Chani --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/#review2433 --- On 2009-09-23 20:19:36, Ivan Cukic wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/ --- (Updated 2009-09-23 20:19:36) Review request for Plasma. Summary --- Nepomuk-based storage of plasma activities Diffs - /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1027137 /trunk/KDE/kdelibs/plasma/applet.cpp 1027137 /trunk/KDE/kdelibs/plasma/containment.h 1027137 /trunk/KDE/kdelibs/plasma/containment.cpp 1027137 /trunk/KDE/kdelibs/plasma/context.h 1027137 /trunk/KDE/kdelibs/plasma/context.cpp 1027137 /trunk/KDE/kdelibs/plasma/private/activitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/activitieshandler.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/context_p.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/desktoptoolbox.cpp 1027137 /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/nepomukactivitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/nepomukactivitieshandler.cpp PRE-CREATION Diff: http://reviewboard.kde.org/r/1699/diff Testing --- Needs more testing Thanks, Ivan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: added support for collors and size on fifteenpuzzle.
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1706/ --- Review request for Plasma. Summary --- colors are now configurable, and number of pieces too. everything is saved and restored. shuffle now also shows a bit of movement while shuffling. Diffs - trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/CMakeLists.txt 1026834 trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/images/blanksquare.svgz UNKNOWN trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/images/greensquare.svgz UNKNOWN trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/fifteen.h 1026834 trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/fifteen.cpp 1026834 trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/fifteenPuzzle.cpp 1026834 trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/fifteenPuzzleConfig.h 1026834 trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/fifteenPuzzleConfig.cpp 1026834 trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/fifteenPuzzleConfig.ui 1026834 trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/piece.h 1026834 trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/piece.cpp 1026834 Diff: http://reviewboard.kde.org/r/1706/diff Testing --- everything looks ok. Thanks, Tomaz ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Plasma + Nepomuk - libplasma patch - attempt 1
On 2009-09-23 21:28:50, Aaron Seigo wrote: /trunk/KDE/kdelibs/plasma/context.h, line 105 http://reviewboard.kde.org/r/1699/diff/1/?file=11891#file11891line105 is this equivalent to: forActivity(id)-name(); ? wrote: Again, the context doesn't have a name wrote: what exactly is the difference between the context and the activity? wrote: context is a combination of the activity and the physical location of the machine/user. it may eventually contain other items (presence?) wrote: and yet each activity has its own context? something doesn't feel right here. so... we have global contexty things like physical location... then we have a bunch of nepomuk actvitites which have a UID and a name and some more context associated with them (what context?), and map to plasma activity containments... and somewhere in the middle of all this we have an old Context class we've got to work with because of BC requirements. adding to my confusion is the fact that we seem to be using the same words for different things again. *shrug* maybe I should just wait until it's done... it just feels like something's not right. the relationship is this: Each Plasma::Containment may have a Plasma::Context associated with it Each Plasma::Context object aggregates an Activity, the current geolocation information, etc. The Activity is recorded in Nepomuk so that other applications can use them as well. The Activity has a name (for the user) and an ID (for info retrieval purposes). At any given time zero or one Activity is the current activity. plasma-desktop will need to map what it is showing in its Views using this informtion; e.g. when Activity Y is marked as the current activity in Nepomuk, it may want to switch to showing the Containment(s) where Containment::context()-activityId() == GlobalContext::currentActivity()-activityId(). (or whatever the API ends up being). or plasma-desktop may decide to set the current Activity in nepomuk to whatever Containment the user just selected to focus on in the overview mode. meanwhile, Kopete / Konqueror / Kontact / etc / etc may also choose to watch for the Activity in Nepomuk and alter what they are doing in response. They may also decide to create new Activities of their own, which plasma-desktop may elect to follow or ignore. HTH. - Aaron --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/#review2433 --- On 2009-09-23 20:19:36, Ivan Cukic wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1699/ --- (Updated 2009-09-23 20:19:36) Review request for Plasma. Summary --- Nepomuk-based storage of plasma activities Diffs - /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1027137 /trunk/KDE/kdelibs/plasma/applet.cpp 1027137 /trunk/KDE/kdelibs/plasma/containment.h 1027137 /trunk/KDE/kdelibs/plasma/containment.cpp 1027137 /trunk/KDE/kdelibs/plasma/context.h 1027137 /trunk/KDE/kdelibs/plasma/context.cpp 1027137 /trunk/KDE/kdelibs/plasma/private/activitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/activitieshandler.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/context_p.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/desktoptoolbox.cpp 1027137 /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/fallbackactivitieshandler.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/private/nepomukactivitieshandler.h PRE-CREATION /trunk/KDE/kdelibs/plasma/private/nepomukactivitieshandler.cpp PRE-CREATION Diff: http://reviewboard.kde.org/r/1699/diff Testing --- Needs more testing Thanks, Ivan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: added support for collors and size on fifteenpuzzle.
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1706/#review2451
---
part of the patch did not apply cleanly to trunk. can you check that? other
than that, a few small issues but nothing outstanding. looking forward to this
being in svn for 4.4 :)
trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/CMakeLists.txt
http://reviewboard.kde.org/r/1706/#comment1792
not needed :)
trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/fifteen.h
http://reviewboard.kde.org/r/1706/#comment1793
QColor color() const; should be enough?
trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/fifteenPuzzle.cpp
http://reviewboard.kde.org/r/1706/#comment1794
usually we just do: cg.readEntry(Size, 4);
trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/piece.cpp
http://reviewboard.kde.org/r/1706/#comment1796
m_fifteen-size() must be guaranteed to never return 0. worth checking that
over or else changing these to qMax(4, m_fifteen-size()); for safety's sake.
trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/piece.cpp
http://reviewboard.kde.org/r/1706/#comment1795
void Piece::shuffling()
{
(curly brace on its own line)
- Aaron
On 2009-09-24 00:56:28, Tomaz Canabrava wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1706/
---
(Updated 2009-09-24 00:56:28)
Review request for Plasma.
Summary
---
colors are now configurable,
and number of pieces too.
everything is saved and restored.
shuffle now also shows a bit of movement while shuffling.
Diffs
-
trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/CMakeLists.txt 1026834
trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/images/blanksquare.svgz
UNKNOWN
trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/images/greensquare.svgz
UNKNOWN
trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/fifteen.h 1026834
trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/fifteen.cpp 1026834
trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/fifteenPuzzle.cpp
1026834
trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/fifteenPuzzleConfig.h
1026834
trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/fifteenPuzzleConfig.cpp
1026834
trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/fifteenPuzzleConfig.ui
1026834
trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/piece.h 1026834
trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/piece.cpp 1026834
Diff: http://reviewboard.kde.org/r/1706/diff
Testing
---
everything looks ok.
Thanks,
Tomaz
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Use window() as KNotificationItem::associatedWidget() to avoid native widgets
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1707/ --- Review request for kdelibs and Plasma. Summary --- Use the window() of the passed parent() as the associated widget to avoid creating a native widget for the child due to all the winId() calls. Alien widgets are much faster. Diffs - /trunk/KDE/kdelibs/kdeui/notifications/knotificationitem.cpp 1027406 Diff: http://reviewboard.kde.org/r/1707/diff Testing --- Thanks, Christoph ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review request: Container plasma applet
Aaron J. Seigo wrote: On September 22, 2009, alan moore wrote: My thinking for the solution was to create a sub-containment that would and improving the panel and/or the widgets wasn't a possibility? :) Possible, but for me not very probable; I'm just a simple python hacker. Though I did think about submitting a detailed wishlist item with mockups, etc. In the end it seemed like proof-of-concept code seemed like a better path, but even that was beyond me. I'm sure the best solution is to work the capabilities into the panel. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
