[KDE Bugtracking System] REMINDER: current Plasma regressions
Please find below a list of the current regressions reported for Plasma This search was scheduled by myr...@kde.org. Plasma regressions -- Bug 283626: https://bugs.kde.org/show_bug.cgi?id=283626 Priority: NOR Severity: crash Platform: openSUSE RPMs Assignee: plasma-b...@kde.org Status: NEEDSINFO Resolution: WORKSFORME Summary: plasma-desktop crashes when Adding Widget while ActivityManager is visible [@ ActivityManager::setLocation] Bug 290828: https://bugs.kde.org/show_bug.cgi?id=290828 Priority: NOR Severity: normal Platform: Archlinux Packages Assignee: plasma-b...@kde.org Status: NEW Summary: Widget selections scrolling broken Bug 296117: https://bugs.kde.org/show_bug.cgi?id=296117 Priority: NOR Severity: minor Platform: Other Assignee: plasma-b...@kde.org Status: REOPENED Summary: New Add Widgets dialog does not respect fractional font sizes Bug 297842: https://bugs.kde.org/show_bug.cgi?id=297842 Priority: NOR Severity: normal Platform: Other Assignee: plasma-b...@kde.org Status: NEW Summary: Navigating the list with the keyboard when a search filter is entered Bug 300885: https://bugs.kde.org/show_bug.cgi?id=300885 Priority: NOR Severity: critical Platform: Ubuntu Packages Assignee: plasma-b...@kde.org Status: NEW Summary: Weather widget does not work anymore with bbcuk or wetter.com provider Bug 301382: https://bugs.kde.org/show_bug.cgi?id=301382 Priority: NOR Severity: normal Platform: Gentoo Packages Assignee: plasma-b...@kde.org Status: NEW Summary: Panel overlaps widget explorer Bug 301424: https://bugs.kde.org/show_bug.cgi?id=301424 Priority: NOR Severity: normal Platform: openSUSE RPMs Assignee: plasma-b...@kde.org Status: NEW Summary: Cannot open battery monitor applet if set to hidden in systray Bug 301459: https://bugs.kde.org/show_bug.cgi?id=301459 Priority: NOR Severity: normal Platform: openSUSE RPMs Assignee: plasma-b...@kde.org Status: UNCONFIRMED Summary: Categories button should reflect the category being filtered on Bug 301460: https://bugs.kde.org/show_bug.cgi?id=301460 Priority: NOR Severity: normal Platform: Other Assignee: plasma-b...@kde.org Status: NEW Summary: Switching activities became really slow Bug 301522: https://bugs.kde.org/show_bug.cgi?id=301522 Priority: NOR Severity: normal Platform: Gentoo Packages Assignee: plasma-b...@kde.org Status: NEW Summary: Clickable area in Activity Bar widget does not resize Bug 301533: https://bugs.kde.org/show_bug.cgi?id=301533 Priority: NOR Severity: normal Platform: Other Assignee: plasma-b...@kde.org Status: NEW Summary: Option Show Multiple Batteries does nothing Bug 301656: https://bugs.kde.org/show_bug.cgi?id=301656 Priority: NOR Severity: normal Platform: Other Assignee: plasma-b...@kde.org Status: NEW Summary: Installed widgets are not marked as such anymore Bug 301765: https://bugs.kde.org/show_bug.cgi?id=301765 Priority: NOR Severity: normal Platform: Other Assignee: plasma-b...@kde.org Status: NEW Summary: Generic activity icon covers custom icon when configuring it Bug 302100: https://bugs.kde.org/show_bug.cgi?id=302100 Priority: NOR Severity: normal Platform: Other Assignee: plasma-b...@kde.org Status: UNCONFIRMED Summary: Icon always shown in systray ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Team meeting today
Hello Plasma team, I've heard that this group is experiencing some difficulties, and the Community Working Group has been asked to intervene. We usually are asked to come into crises, while we would really prefer to work with groups to improve community. We've been developing a tool to help with that, and offer it to you to use (or not) as you please. Please ignore what doesn't apply. Notice that we don't focus on the issues under discussion, but rather how the team is functioning, with the goal of improving the conversation, and thus the creativity available. I came across a quote tonight: No problem can be solved from the same level of consciousness that created it. - Albert Einstein The ideal KDE Team The ideal KDE team has fun and is productive. The members trust one another enough to express honest feelings and thoughts about their project, as well as personal issues when appropriate. The team members support and encourage one another, and bring fresh information, resources and entertainment to the group. The ideal KDE team is not only growing, but is always recruiting. Each team member is so happy with the group that new members are drawn-in naturally. Each team member blogs and writes in other places about the work, and about the team. Team members encourage one another to communicate publicly, and also to comment the code. At release time, team members pitch in to help, and celebrate their accomplishments. Team members look for diversity when they recruit, both culturally and in team roles. In times of major disagreements, the ideal team thoroughly airs both facts and feelings honestly, and members do not attack one another. Everyone feels free to express themselves, everyone is heard, everyone feels valued, and every member supports the decisions reached, even if their own ideas were not accepted, because their concerns were taken into account. The ideal team has not only an active group of coders, but also people who do bug triaging, documentation, community, promo, forums, list, and IRC. The developers each do some of this work as appropriate, and also just talk with users. Enthusiastic users become testers, and then perhaps enter the team more formally to help out. As time goes on, a healthy team loses contributors too. However, they leave with fond memories, remain friends, and are often called upon for advice, feedback, or just to swap stories. Team members learn new roles, and train their own replacements all the time. Growing out of a role into a new one is more fun that burnout! Team Health Check [ ] Rate your team 1 - 5, where 1 is needs lots of work, and 5 is working excellently. Is our team growing? How many members have we gained and lost in the last year? [ ] Rate your team: Rate the diversity of the team. Consider gender, age, team roles, time zones, language, etc. [ ] Rate your team: Why are team members leaving? Do social bonds with departed members continue? [ ] Rate your team: Do we encourage one another to learn new roles, and change those roles as time goes on? In other words, how do we stave off burnout? [ ] Rate your team: What sort of recruitment of new team members are we doing? Is this recruitment increasing our diversity? Are we recruiting for diverse roles in the community as well (documentation, usability, testing, community, as well as coding)? [ ] Rate your team: How often do team members meet up in the various fora, in meetings, and for sprints? How many of the team participate? [ ] Rate your team: Do we have any sort of metrics set up that we can use to rate our progress? [ ] Rate your team: How well is our code documented? (Undocumented code is a major roadblock to new contributors.) Is is a team value to Always Document? [ ] Rate your team: How clear and up-to-date is our team documentation in KDE space, such as our website, Techbase, Userbase and Community wikis? [ ] Rate your team: How often do our team members blog about their work? Are their blogs all on Planet KDE? [ ] Rate your team : Does our team contribute articles to The Dot? [ ] Rate your team: What sort of training and guidance do we provide for our IRC ops, listowner, and forum administrators? [ ] Rate your team: How many of our team members consider themselves to be leaders in the team? Do the non-coding members feel equal to the coders? Do all members of the team feel valued by the team? [ ] Rate your team: How good is our bug triage, commenting, and bug closing? Individual Health Check -- within the team, and KDE Is my voice heard? Are my ideas respected? Are my emotional needs met? (within the boundaries of KDE and teams, this means appreciation for contributions and a sense of camaraderie) I would appreciate feedback about this Health Check tool; criticisms too. All the best, Valorie, member of KDE Community Working Group ___ Plasma-devel mailing list Plasma-devel@kde.org
Re: Review Request: Plasm qml-components: also highlight the dualstate button on keyboard-focus
On June 14, 2012, 6:18 p.m., Aaron J. Seigo wrote:
plasma/declarativeimports/plasmacomponents/qml/private/DualStateButton.qml,
lines 77-78
http://git.reviewboard.kde.org/r/105232/diff/1/?file=67422#file67422line77
loos like this will work but i dislike how shadowLoader.state is being
set all over the place in a rather procedural manner. much nicer imho would
be sth like:
Loader {
id: shadowLoader
anchors.fill: surfaceLoader
state: (duableButton.enabled dualButton.focus) ? hover :
shadow
}
and then do the right thing in Keys.onSpacePressed,
Keys.onReturnPressed, etc.
this would also get rid of the entered() function and maybe even clean
up the MouseArea below as well.
to me this would just feel more QML
Marco: what do you think?
yeah, i agree.
to me apart this small issue the change in behaviour is correct, so correct it
and can be pushed
- Marco
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105232/#review14727
---
On June 12, 2012, 10:25 p.m., Johannes Tröscher wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105232/
---
(Updated June 12, 2012, 10:25 p.m.)
Review request for Plasma.
Description
---
this will enable the highlight on a dualstatebutton (like a checkbox) also if
the button has keyboardfocus.
Diffs
-
plasma/declarativeimports/plasmacomponents/qml/private/DualStateButton.qml
1579e88
Diff: http://git.reviewboard.kde.org/r/105232/diff/
Testing
---
tested, works
Thanks,
Johannes Tröscher
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: moving forward
On Tuesday, June 19, 2012 19:07:10 Martin Gräßlin wrote: On Tuesday 19 June 2012 12:56:50 Aaron J. Seigo wrote: On Monday, June 18, 2012 18:44:25 Giorgos Tsiapaliwkas wrote: I don't see any objections regarding the meeting. So when it will happen :)? thanks for poking me on this, i got distracted this morning by other things. meeting will happen tomorrow, Wednesday at 17:00 UTC ... that was when the most people could make it see you then. I assume in #plasma, right? ah, yes.. sorry, forgetting all the details. very distracted this week. in #plasma indeed .. -- Aaron J. Seigo 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
Raj change
Hey, Triggered by the comments on my blog, I'd like to change Raj's monthly available money from 300€ to 60€, which seems way more in line with reality. Unless someone objects, I'll make that change. http://vizzzion.org/blog/2012/06/plasma-personas-carla-and-raj/ Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Team meeting today
Hi all, hi Valorie, Thanks a lot for this, and thanks a lot for an external person stepping in. I think I might be one of the targets on why this IRC meeting is conducted (I think I might show you that I am not entirely sure of what is going on here, I only feel it might be about me.) A few days ago, in the #plasma IRC channel, we debugged a systray problem and after testing I reverting 1 Aaron's commit (I CCed him in the commit of course). I have the IRC log on the discussion that happened about this, this is what often happens on IRC. From what I read after this in mailing lists I felt this was interpreted as a QA Team reverting commit trend. I happen to be part of the new QA team effort but this reverted commit was done as annma, annma being part of Plasma. Referring here at http://mail.kde.org/pipermail/plasma-devel/2012-June/020042.html which I immediately denied in http://mail.kde.org/pipermail/plasma-devel/2012-June/020044.html but that was never acknowledged. I clarified again my position in http://mail.kde.org/pipermail/plasma-devel/2012-June/020055.html but again this was never acknowledged. Sebas replies Just removing components or reverting commits is not a way to fix bugs, it probably leads to more regressions even to the Quality Team: LCD weather station and calendar (in panel) are really broken and thus implies reverting commits is part of the QA Team procedure. Nobody ever read my answers and everyone just carried on with his false perception. I feel pretty upset that an action done as annma = member of the plasma team (or so I thought) is interpreted as a QA Team action and generalized. The call for an IRC meeting mail starts with it has become apparent that we need to do something here about the attitude demonstrated by some of those who have chosen to participate in plasma. in which I would have liked the some of those specifically nominated and mailing list mails quoted in order to clear what this is all about. Apparently other people understand this as they jump in to welcome the meeting. This make me feel uncomfortable, not because I might be a target but because I do not know what it is all about. Is my reverted commit a cause of this meeting? is it because other developers questioned some design decisions like having the remaining time displayed on the battery icon? On 06/20/2012 10:27 AM, Valorie Zimmerman wrote: Hello Plasma team, I've heard that this group is experiencing some difficulties, and the Community Working Group has been asked to intervene. We usually are asked to come into crises, while we would really prefer to work with groups to improve community. We've been developing a tool to help with that, and offer it to you to use (or not) as you please. Please ignore what doesn't apply. Notice that we don't focus on the issues under discussion, but rather how the team is functioning, with the goal of improving the conversation, and thus the creativity available. I came across a quote tonight: No problem can be solved from the same level of consciousness that created it. - Albert Einstein The ideal KDE Team The ideal KDE team has fun and is productive. The members trust one another enough to express honest feelings and thoughts about their project, as well as personal issues when appropriate. The team members support and encourage one another, and bring fresh information, resources and entertainment to the group. The ideal KDE team is not only growing, but is always recruiting. Each team member is so happy with the group that new members are drawn-in naturally. Each team member blogs and writes in other places about the work, and about the team. Team members encourage one another to communicate publicly, and also to comment the code. At release time, team members pitch in to help, and celebrate their accomplishments. Team members look for diversity when they recruit, both culturally and in team roles. In times of major disagreements, the ideal team thoroughly airs both facts and feelings honestly, and members do not attack one another. Everyone feels free to express themselves, everyone is heard, everyone feels valued, and every member supports the decisions reached, even if their own ideas were not accepted, because their concerns were taken into account. The ideal team has not only an active group of coders, but also people who do bug triaging, documentation, community, promo, forums, list, and IRC. The developers each do some of this work as appropriate, and also just talk with users. Enthusiastic users become testers, and then perhaps enter the team more formally to help out. As time goes on, a healthy team loses contributors too. However, they leave with fond memories, remain friends, and are often called upon for advice, feedback, or just to swap stories. Team members learn new roles, and train their own replacements all the time. Growing out of a role into a new one is more fun that burnout! Team Health Check [ ] Rate
Re: Review Request: Plasm qml-components: also highlight the dualstate button on keyboard-focus
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105232/#review14909 --- Ship it! can you push it? - Marco Martin On June 20, 2012, 12:15 p.m., Johannes Tröscher wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105232/ --- (Updated June 20, 2012, 12:15 p.m.) Review request for Plasma. Description --- this will enable the highlight on a dualstatebutton (like a checkbox) also if the button has keyboardfocus. Diffs - plasma/declarativeimports/plasmacomponents/qml/private/DualStateButton.qml 1579e88 Diff: http://git.reviewboard.kde.org/r/105232/diff/ Testing --- tested, works Thanks, Johannes Tröscher ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Team meeting today
On Wednesday, June 20, 2012 14:12:48 Anne-Marie Mahfouf wrote: The call for an IRC meeting mail starts with it has become apparent that we need to do something here about the attitude demonstrated by some of those who have chosen to participate in plasma. in which I would have liked the some of those specifically nominated and mailing list mails quoted in order to clear what this is all about. It's not about individuals, and not specifically about you. We have a general attitude / collaboration problem, that's what we're trying to address with this meeting. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Containment default setting
On Tuesday, June 19, 2012 17:41:06 Varun Herale wrote: cool; how it supposed to work? pulling images at a given interval from a digikam album? or..? The plugin hasn't been working since KDE4, so currently the aim is to get it to work for a single image chosen from digikam albums. Once that is so this is meant to be a way to select an image from within digikam to be used as the desktop wallpaper? iow, you want the ability to set the desktop wallpaper from an application running outside of plasma-desktop? -- Aaron J. Seigo 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: Team meeting today
On Wednesday, June 20, 2012 14:12:48 Anne-Marie Mahfouf wrote: I think I might be one of the targets on why this IRC meeting is no one is a target at this, or any other, plasma meeting. it's not about rooting out blame or villianizing anyone. rather we're going to try and re-find our set of common ground rules for working with each other, starting with what we're wanting to personally achieve when working on this project and going from there. procedure. Nobody ever read my answers and everyone just carried on with his false perception. I feel pretty upset that an action done as annma = member of the plasma team (or so I thought) is interpreted as a QA Team action and generalized. i read your answers and i am clear on whether the action was one that you took or that the QA team took. it really does not matter which it was, at least not to me, which is why i didn't address that issue directly but tried to remain focused on the issue of commit reversions and, as a separate though related issue, removal requests. who does it is neither here nor there; what matters is that we have consensus on how to do these things .. this is something we had at one point in our team but which has evidently been lost to some degree as the team has recently grown. The call for an IRC meeting mail starts with it has become apparent that we need to do something here about the attitude demonstrated by some of those who have chosen to participate in plasma. in which I would have liked the some of those specifically nominated and mailing list mails quoted in order to clear what this is all about. ime, when you start singling people out by name it becomes even more uncomfortable and unfair for pretty much everyone involved. what matters is that we have some issues that we can only work through _together_. Is my reverted commit a cause of this meeting? is it because other developers questioned some design decisions like having the remaining time displayed on the battery icon? this and several other events in the last 4-6 weeks. it also has not been just the actions themselves, but the way in which those actions were undertaken. this is all going to be covered during the meeting .. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma Containment default setting
so this is meant to be a way to select an image from within digikam to be used as the desktop wallpaper? iow, you want the ability to set the desktop wallpaper from an application running outside of plasma-desktop? Yes, exactly ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Team meeting today
On 06/20/2012 03:50 PM, Aaron J. Seigo wrote: On Wednesday, June 20, 2012 14:12:48 Anne-Marie Mahfouf wrote: I think I might be one of the targets on why this IRC meeting is no one is a target at this, or any other, plasma meeting. it's not about rooting out blame or villianizing anyone. rather we're going to try and re-find our set of common ground rules for working with each other, starting with what we're wanting to personally achieve when working on this project and going from there. procedure. Nobody ever read my answers and everyone just carried on with his false perception. I feel pretty upset that an action done as annma = member of the plasma team (or so I thought) is interpreted as a QA Team action and generalized. i read your answers and i am clear on whether the action was one that you took or that the QA team took. it really does not matter which it was, at least not to me, which is why i didn't address that issue directly but tried to remain focused on the issue of commit reversions and, as a separate though related issue, removal requests. who does it is neither here nor there; what matters is that we have consensus on how to do these things .. this is something we had at one point in our team but which has evidently been lost to some degree as the team has recently grown. it matters to me to not scapegoat the QA team in order to minimize its work. The call for an IRC meeting mail starts with it has become apparent that we need to do something here about the attitude demonstrated by some of those who have chosen to participate in plasma. in which I would have liked the some of those specifically nominated and mailing list mails quoted in order to clear what this is all about. ime, when you start singling people out by name it becomes even more uncomfortable and unfair for pretty much everyone involved. what matters is that we have some issues that we can only work through _together_. Usually meetings have agendas Is my reverted commit a cause of this meeting? is it because other developers questioned some design decisions like having the remaining time displayed on the battery icon? this and several other events in the last 4-6 weeks. it also has not been just the actions themselves, but the way in which those actions were undertaken. this is all going to be covered during the meeting .. I won't be there at the meeting unfortunately. I'll log it to read it. Personally I like things to be said face to face that's why I take time to write these mails. And I do feel targeted. In any case I hope I clarified my position and if this one reverted commit by me was not done properly (I think I never behaved unfairly within KDE, have I?), this happens quite often. Happened from you too. Let's then have a rule of review everything properly. If Valorie's mail had not come I was about to mail Kevin (ervin) in order to have a mediator of some sort, because I was uncomfortable with this, not for me but for all plasma caring people (which may be or not The Plasma Team). Anne-Marie It'll be probably good to take some time to reflect on the Community Working Group check list, with the help of this group members if necessary. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Raj change
Hello, On Wednesday 20 June 2012 13:05:04 Sebastian Kügler wrote: Triggered by the comments on my blog, I'd like to change Raj's monthly available money from 300€ to 60€, which seems way more in line with reality. Well, we knew it wasn't really 300€ at the time and likely a lot less, but we took cost of living in account to transpose that into the average european frame of reference. So I'd rather see something like the real rupee value, and put next to it that for us westerners it'd be close to a european student living on 300€ per month. I'm concerned that just putting 60€ could be deemed as ridiculously low by someone reading it who would then simply ignore it. I think the mistake we made was to go for 300€ with no explanation, just changing it to 60€ sounds like repeating the same mistake. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.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: Team meeting today
On Wednesday 20 June 2012, Anne-Marie Mahfouf wrote: I won't be there at the meeting unfortunately. I'll log it to read it. Personally I like things to be said face to face that's why I take time to write these mails. And I do feel targeted. In any case I hope I clarified my position and if this one reverted commit by me was not done properly (I think I never behaved unfairly within KDE, have I?), this happens quite often. Happened from you too. Let's then have a rule of review everything properly. If Valorie's mail had not come I was about to mail Kevin (ervin) in order to have a mediator of some sort, because I was uncomfortable with this, not for me but for all plasma caring people (which may be or not The Plasma Team). yes, many thanks to Valorie from me as well for taking care of this. as what should be the content of the meeting: it should be about methodology: there is obviously a problem in how issues are dealth with. what i hope for the meeting is to come out about an agreed procedure on how to deal with when there is a disagreement about a particular thing, in the end accepted conditions where one says i still don't agree, but i'll accept the decision to be clear, there shouldn't be personal issues discussed there, since is a public discussion. there may be some, but if it is the case they should be solved in private Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Use common plasma components Tooltip in battery monitor
On June 18, 2012, 3:37 p.m., Viranch Mehta wrote: The button size and the hover appearance is different from the original one. The IconButton component was made to keep the look of the buttons consistent with the original version of the applet. Do we want to change this? Valid argument for now, won't be valid when everything moves to QML/Plasma Components. You're maintainer, you have final say. If you want me to wait till 4.10 when more applets are QML based I will do. - David --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105283/#review14839 --- On June 17, 2012, 7:52 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105283/ --- (Updated June 17, 2012, 7:52 p.m.) Review request for Plasma. Description --- Current battery monitor implements it's own Button class, this previously broke styles with theme text and overloads icon sizes and such. It's bad for applets to implement their own version of common classes as it prevents consistency. (will fix the whitespace addition before commit) Diffs - plasma/generic/applets/batterymonitor/contents/ui/IconButton.qml d4454c6 plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml a2ab72a Diff: http://git.reviewboard.kde.org/r/105283/diff/ Testing --- Checked applet looked ok. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Raj change
On Wednesday, June 20, 2012 16:46:28 Kevin Ottens wrote: Hello, On Wednesday 20 June 2012 13:05:04 Sebastian Kügler wrote: Triggered by the comments on my blog, I'd like to change Raj's monthly available money from 300€ to 60€, which seems way more in line with reality. Well, we knew it wasn't really 300€ at the time and likely a lot less, but we took cost of living in account to transpose that into the average european frame of reference. So I'd rather see something like the real rupee value, and put next to it that for us westerners it'd be close to a european student living on 300€ per month. I'm concerned that just putting 60€ could be deemed as ridiculously low by someone reading it who would then simply ignore it. I think the mistake we made was to go for 300€ with no explanation, just changing it to 60€ sounds like repeating the same mistake. Yeah, warrants some explanation. I think it's wrong to try to translate such amounts into what's normal in a European context, it adds a layer of abstraction that's highly subjective. When using those numbers, we should give them some more meaning, but keep the original amount, maybe express it in Rupees first (local valuta) and put a few words that it's not a lot but enough to get around as a student. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Re: Raj change
On Wednesday, June 20, 2012 05:22:28 PM Sebastian Kügler wrote: On Wednesday, June 20, 2012 16:46:28 Kevin Ottens wrote: Hello, On Wednesday 20 June 2012 13:05:04 Sebastian Kügler wrote: Triggered by the comments on my blog, I'd like to change Raj's monthly available money from 300€ to 60€, which seems way more in line with reality. Well, we knew it wasn't really 300€ at the time and likely a lot less, but we took cost of living in account to transpose that into the average european frame of reference. So I'd rather see something like the real rupee value, and put next to it that for us westerners it'd be close to a european student living on 300€ per month. I'm concerned that just putting 60€ could be deemed as ridiculously low by someone reading it who would then simply ignore it. I think the mistake we made was to go for 300€ with no explanation, just changing it to 60€ sounds like repeating the same mistake. Björn what's your take on this? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Raj change
Am Mittwoch, 20. Juni 2012, 17:31:04 schrieb Alex Fiestas: On Wednesday, June 20, 2012 05:22:28 PM Sebastian Kügler wrote: On Wednesday, June 20, 2012 16:46:28 Kevin Ottens wrote: Hello, On Wednesday 20 June 2012 13:05:04 Sebastian Kügler wrote: Triggered by the comments on my blog, I'd like to change Raj's monthly available money from 300€ to 60€, which seems way more in line with reality. Well, we knew it wasn't really 300€ at the time and likely a lot less, but we took cost of living in account to transpose that into the average european frame of reference. So I'd rather see something like the real rupee value, and put next to it that for us westerners it'd be close to a european student living on 300€ per month. I'm concerned that just putting 60€ could be deemed as ridiculously low by someone reading it who would then simply ignore it. I think the mistake we made was to go for 300€ with no explanation, just changing it to 60€ sounds like repeating the same mistake. Björn what's your take on this? It is really a minor issue. Do it in that way most people feel comfortable with. It most likely will not affect anything we are doing or deriving out of it... Btw. we do have an expert on Raj and he did participate in creating Raj :) So I would acually suggest to ask Vishesh about a reasonable solution :) Björn ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Raj change
I think the mistake we made was to go for 300€ with no explanation, just changing it to 60€ sounds like repeating the same mistake. When I left home and moved to Delhi to prepare for my mass communication and journalism degree I was getting around 50€-60€ per month. 300€ is more than my first salary as a journalist ;-) So, I think 60€ is closer to reality. My 00.02€ :-) Swapnil ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Containment default setting
On Wednesday, June 20, 2012 19:36:28 Varun Herale wrote: so this is meant to be a way to select an image from within digikam to be used as the desktop wallpaper? iow, you want the ability to set the desktop wallpaper from an application running outside of plasma-desktop? Yes, exactly and how are you attempting to do this right now? (the best way is probably to offer a dbus interface in plasma-desktop that then connects to the active wallpaper plugin ... which has a call for setting wallpapers by url) -- Aaron J. Seigo 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: Plasm qml-components: also highlight the dualstate button on keyboard-focus
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105232/#review14920 --- This review has been submitted with commit a0f6888c23a650f7fe01bc1682b40b37477b4049 by Johannes Tröscher to branch master. - Commit Hook On June 20, 2012, 12:15 p.m., Johannes Tröscher wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105232/ --- (Updated June 20, 2012, 12:15 p.m.) Review request for Plasma. Description --- this will enable the highlight on a dualstatebutton (like a checkbox) also if the button has keyboardfocus. Diffs - plasma/declarativeimports/plasmacomponents/qml/private/DualStateButton.qml 1579e88 Diff: http://git.reviewboard.kde.org/r/105232/diff/ Testing --- tested, works Thanks, Johannes Tröscher ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Use common plasma components Tooltip in battery monitor
On June 18, 2012, 3:37 p.m., Viranch Mehta wrote: The button size and the hover appearance is different from the original one. The IconButton component was made to keep the look of the buttons consistent with the original version of the applet. Do we want to change this? David Edmundson wrote: Valid argument for now, won't be valid when everything moves to QML/Plasma Components. You're maintainer, you have final say. If you want me to wait till 4.10 when more applets are QML based I will do. Well after a second thought, I think its a better idea to use plasma components for consistency over plasma rather than maintaining consistency with previous versions. but the original button for some reason looks *really* better in visual terms to me (in fact, the button is also used in some other plasmoids including the network manager). so... to plasma components dev: can we have an option in the button of what background svg is used? may be a switch between the current one and the one in this plasmoid (widgets/viewitem)? if that may take time to come up, or is not desired, we can have this patch shipped right in! - Viranch --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105283/#review14839 --- On June 17, 2012, 7:52 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105283/ --- (Updated June 17, 2012, 7:52 p.m.) Review request for Plasma. Description --- Current battery monitor implements it's own Button class, this previously broke styles with theme text and overloads icon sizes and such. It's bad for applets to implement their own version of common classes as it prevents consistency. (will fix the whitespace addition before commit) Diffs - plasma/generic/applets/batterymonitor/contents/ui/IconButton.qml d4454c6 plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml a2ab72a Diff: http://git.reviewboard.kde.org/r/105283/diff/ Testing --- Checked applet looked ok. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Team meeting today
Hi all, this is a very raw synopsis of the meeting, i hope we can now transform it in something very productive (i think the meeting especially the last part was useful) The meeting started from the realization that there is an 1% of cases where the discussion doesn't go well and can get people too emotional, making it not productive, for the project and for the morale. Some cases of recent discussions where at first there was disagreement, but the discussion gone completely smoothly were analized (the 99% when things goes like they should), such as: http://old.nabble.com/RFC%3A-Removing-of-decorations-td33476065.html https://bugs.kde.org/show_bug.cgi?id=302077 some points in common have been individuated: * we can see in those discussions the tone never escalated, even with disagreements, they look more like stimulating debates * when someone wants the mantainer to change his mind stays on exclusively technical points: raises concerns and arguments them, like needing an use case for window decoration for remote sessions, that weren't considered in the original decision * the maintainer proposes a third solution, balanced between the problem the original solution tries to address and the problem this causes. like waiting until a particular lightweight window decoration is here * The discussion always stays focused, in topic So that's how we want those discussions to happen. There can be done a series of recommendations in order to do so, and we can point to people when those aren't followed. note that those are just copied/pasted from points made over irc, so if they are incorrect, not completely understandable or if others missing feel free to correct: * we see that there is need to document more * especially if a discussion turns out to be recurring: document the reasons and point out to those * it doesn't need to be done for everything, otherwise becomes not maintainable with bad signal/noise ratio * we have established guidelines on how to interact with each other * we don't want to blame community members for things which happened in the past * We concentrate too much on energy eaters, rather than on progress * we remind each other about our common goals if we see that a discussion goes in the wrong direction * there's a lack of trust we need to address * if anyone breaks the guidelines (whoever they are) breaks these we point it out, and not write a (more angry) reply which escalates * code reverting or being a bit invasive in non familiar areas should at least contact the ML or person affected * we need a list of component and maintainer * we respect maintainer decisions * and, respect the elders! * think about the bigger project, if an issue of disagreement risks of damaging/slowing down the project, is maybe the time to step back and say i stil ldon't agree but i respect the decision * same thing if the maintainer and/or several other maintainers of related components didn't change their mind: respect the decision even if you still disagree raw mammoth irc log: http://paste.opensuse.org/43938417 (not filtered from ot) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
When should a bug be considered as a regression or a release_blocker?
Hi, Yesterday i was looking over quite a few plasma bugs and noticed a lot of bug being filled at the new QML components. I marked most of them as regressions since they looked like regressions to me. To me the definition of a regression is as follows: A regression is an issue that wasn't in the previous release. Things get a bit more complicated with adding the release_blocker keyword. When do you add that keyword to a bug? Thus far i considered a bug a release_blocker if the issue means that the item is unusable or causing loss of data. For example https://bugs.kde.org/show_bug.cgi?id=301854. It's a very innocent plasmoid, but it's unusable on multiscreen environments thus i marked it as a release blocker. Another example is https://bugs.kde.org/show_bug.cgi?id=301854, that bug described the KGet Piechart applet as being broken. I tested that and verified that it indeed is completely broken and even renders outside it's applet space. So i marked that one as release blocker as well because it's useless in it's current state. Both issues are not something that obstruct normal KDE usage, but they do render some parts of KDE completely useless. I'm a bit unsure if i should mark such bugs as release blockers. Perhaps there should be a keyword called component_blocker indicating that a specific component (specified in the component field on bugzilla) is not fit to be shipped with the release. I would like to have some clarification on when something should be marked as a release blocker. So perhaps we can draft up a general guideline for the conditions that justify a bug being marked as release_blocker. Kind regards, Mark ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: When should a bug be considered as a regression or a release_blocker?
On Wednesday 20 June 2012 22:15:35 Mark wrote: Hi, Yesterday i was looking over quite a few plasma bugs and noticed a lot of bug being filled at the new QML components. I marked most of them as regressions since they looked like regressions to me. To me the definition of a regression is as follows: A regression is an issue that wasn't in the previous release. yes, that's how I consider a regression. A bug introduced by a code change in the recent version. Things get a bit more complicated with adding the release_blocker keyword. When do you add that keyword to a bug? Thus far i considered a bug a release_blocker if the issue means that the item is unusable or causing loss of data. I am very careful about using the release_blocker keyword. We have to properly judge it. If we add a release_blocker we consider the issue that strong that it would block all of KDE SC. Given that I consider only very severe issues a release blocker, such as data loss or severe damage to the system. Any non-default component cannot be a blocker in my opinion. For 4.10 I set one bug to release_blocker in KWin and that was the bug to track the writing of the kconf update script. I considered not having a migration as an issue severe enough to say that we cannot release without it. Cheers 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: RFC: Activities vs Virtual Desktop document on the wiki
[Sorry for not replying earlier, I am helping holding a KDE booth at a Linux exhibition until thursday] Le samedi 16 juin 2012 14:21:39 Marco Martin a écrit : I would like to keep this definition of orthogonality between activities and virtual desktops in the definition, describing use cases for a) separation by activity b) spatial organization then describe how b) is coveed by activities. If a) is something that should stay in the long years to come, is an open question. Do you have examples of such use cases I could use in the wiki page? I clearly see (and clearly came out from the Tree game) that in the end in the practical use VDs and Activities often end up overlapping. Also virtual desktops are so limited by x11 and netwm tecnicalities that may become a slowly fading away legacy. VD are so ingrained in X11 users it needs to stay available for now. I wonder what is the status of VD in Wayland though. Does it have support for them? Are they better, worse? Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: RFC: Activities vs Virtual Desktop document on the wiki
Le samedi 16 juin 2012 19:28:45 makism a écrit : Hello, About the example in the wiki, perhaps activities Home and Play should explicitly each contain an empty VD otherwise it could be misleading to new users that each activity defines it's own number of VDs, while it's global. Agreed, this is an oversight. I'll fix it. Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: When should a bug be considered as a regression or a release_blocker?
On Wed, Jun 20, 2012 at 10:50 PM, Martin Gräßlin mgraess...@kde.org wrote: On Wednesday 20 June 2012 22:15:35 Mark wrote: Hi, Yesterday i was looking over quite a few plasma bugs and noticed a lot of bug being filled at the new QML components. I marked most of them as regressions since they looked like regressions to me. To me the definition of a regression is as follows: A regression is an issue that wasn't in the previous release. yes, that's how I consider a regression. A bug introduced by a code change in the recent version. Things get a bit more complicated with adding the release_blocker keyword. When do you add that keyword to a bug? Thus far i considered a bug a release_blocker if the issue means that the item is unusable or causing loss of data. I am very careful about using the release_blocker keyword. We have to properly judge it. If we add a release_blocker we consider the issue that strong that it would block all of KDE SC. Given that I consider only very severe issues a release blocker, such as data loss or severe damage to the system. Any non-default component cannot be a blocker in my opinion. For 4.10 I set one bug to release_blocker in KWin and that was the bug to track the writing of the kconf update script. I considered not having a migration as an issue severe enough to say that we cannot release without it. Cheers Martin I completely agree with you, but that still leaves broken parts of KDE SC. I mean, you obviously can't release them since they are broken so if you follow that logic they block the release or they just don't end up in the release. Both options aren't very attractive. So what do we need to do with broken parts of KDE SC even though they don't interrupt normal KDE usage? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Containment default setting
On Wed, Jun 20, 2012 at 7:04 PM, Aaron J. Seigo ase...@kde.org wrote: On Wednesday, June 20, 2012 19:36:28 Varun Herale wrote: so this is meant to be a way to select an image from within digikam to be used as the desktop wallpaper? iow, you want the ability to set the desktop wallpaper from an application running outside of plasma-desktop? Yes, exactly and how are you attempting to do this right now? (the best way is probably to offer a dbus interface in plasma-desktop that then connects to the active wallpaper plugin ... which has a call for setting wallpapers by url) I imagine this could then be used in Dolphin's context menu 'Actions' and possibly in Gwenview too. Should there be such dbus-interface, I would add those patches to Dolphin and Gwenview. -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: When should a bug be considered as a regression or a release_blocker?
On Wednesday 20 June 2012 22:15:35 Mark wrote: I would like to have some clarification on when something should be marked as a release blocker. Take the word literally. A release blocker is a bug which makes the release unusable. Think it is better to not release KDE at all, instead of releasing it with this bug. Examples: - Code does not even compile to create binary packages - KDM fails to log you in - KWin does not start, or starts without window decorations - Plasma Workspace fails to start, or essential widgets do not work (e.g. task bar, system tray, application launcher) - Essential KDE applications (e.g. Dolphin, Konqueror, KWrite, Konsole) fail to start or do not work at least basically. - Essential system services do not work (this is often not in the scope of KDE, but if for whatever reason keyboard or network do not work because of a KDE issue, it is a release blocker) (CCing kde-testing) Christoph Feck (kdepepo) KDE Quality Team ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Add missing email addresses back into add widget tooltip.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105312/ --- Review request for Plasma, Ivan Čukić and Marco Martin. Description --- When the QML port of the add widget dialog occured, the creator's email address got chopped off. This commit fixes a bug hidding the email address, and also starts displaying it again in the tooltip. There are a couple of issue left with this patch: 1) I have to disable wrapping, otherwise the text wraps at odd points for no reason (it fits fine otherwise). 2) The link currently doesn't work as I'm not sure how to hook it up to send mail. Should it be left as is, or just remove the link for 4.9 and update with a link for 4.10? Diffs - libs/plasmagenericshell/widgetsexplorer/package/contents/ui/Tooltip.qml ba804fd006496ee4a7118e97fe44038f0617eec7 libs/plasmagenericshell/widgetsexplorer/plasmaappletitemmodel_p.h e745ef58533ab0e22d2109d5beeff6c29c4d18b4 Diff: http://git.reviewboard.kde.org/r/105312/diff/ Testing --- Tested locally in Xephyr. The tooltip now contains the email address. Thanks, Matthew John Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma Containment default setting
and how are you attempting to do this right now? Right now I am using DBus to find out the current activity and then the plasma-desktop-appletrc config file to find the current containment information. What I am trying to do is load the containment object using the Plasma::Containment::restore() function, but it fails at this point - Link 1http://api.kde.org/4.8-api/kdelibs-apidocs/plasma/html/containment_8cpp_source.html#l00296. I was intending to try and change wallpaper after loading the containment this way. I am not sure if this will work, but I didn't understand why isContainment() was returning false even when it is a Plasma::Containment object. (the best way is probably to offer a dbus interface in plasma-desktop that then connects to the active wallpaper plugin ... which has a call for setting wallpapers by url) How about adding a DBus function to plasmaapp.cpp which can set any wallpaper plugin into the current desktop containment as long as it is installed ? I am working on the code for that right now. Will post in reviewboard once completed! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
