Re: About Plasma Active
+1 :) On 29 March 2012 10:04, Maurice de la Ferte maurice.fe...@basyskom.com wrote: Dean Hi, I'm doing much of the Plasma Active Integration on MeeGo/Mer, also I'm involved in some x86/arm hardware adaptions and building device images. You can count me in. Cheers Maurice On March 27, 2012 at 5:06 PM Dean Howell d...@thepowerbase.com wrote: Plasma Active Team, We at The Powerbase http://www.thepowerbase.com are probably the most excited blog on the Internet when it comes to Vivaldi, Plasma-Active and everything related to it. We want to bring some attention to the core team and thought it would be fun to interview you guys *like a team*. We would like to send you some of our questions and *hopefully,* more than one of you will be able to answer. It would be great for our readers to get the perspective of some of the other developers. Would you guys be interested in doing that? In addition to that, we are opening up guest blogs on The Powerbase, 'ala what OMG Ubuntu does for the Ubuntu developer community. We have a strong KDE readership and it would be a great place for you guys to share development updates. Best Regards, -- Dean Howell, Editor-in-chief The Powerbase http://www.thepowerbase.com ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: activity configuration UI
On Wednesday, March 28, 2012 17:46:52 Fania Bremmer wrote: implementation-wise. Now there comes in a new requirement, the smaller screensize, and we need to find another good solution. I agree that for new while the lack of elegance is more obvious at lower screen sizes, the lack of elegance was quite apparent at larger screen sizes as well. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: activity configuration UI
On Wednesday, March 28, 2012 19:56:46 Thomas Pfeiffer wrote: Generally when designers and developers meet, the developer is in the stronger position. this statement speaks to a large challenge we apparently face: seeing other members in the team as people to be opposed rather than a team working together towards a shared goal that has a higher operational value than our differences. this is poison. i will address this in a following email in a new thread so as to not drag this one further off-topic. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: activity configuration UI
On Wednesday, March 28, 2012 17:31:00 Sebastian Kügler wrote: Does this make sense? +1 from me. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: activity configuration UI
On Wednesday 28 March 2012, Sebastian Kügler wrote: The general rule should be to not use Apply buttons, and for dialogs, dismiss them when clicked outside. (This is btw also how the Harmattan components work, and I think it leads to smooth workflows.) Note that dismissing the dialog means that settings are *not* applied / changed, so in some cases, we'll still need Apply/Save/OK/whatever. Does this make sense? +1, and in general,instant can be guaranteed when there is a direct manipulation of the thing you want to configure, may be resizing or closing something.. whatever... we should in general prefer this kind of direct interaction when possible, and a dialog (so indirect, kinda a remote control) only when needed. in this case what you are changing may or may not be immediately applied, sometimes for technical reasons (like too heavy to apply) or for workflow reasons (difficult to manually revert) -- Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: activity configuration UI
On Thursday 29 March 2012, Aaron J. Seigo wrote: On Wednesday, March 28, 2012 19:56:46 Thomas Pfeiffer wrote: Generally when designers and developers meet, the developer is in the stronger position. this statement speaks to a large challenge we apparently face: seeing other members in the team as people to be opposed rather than a team working together towards a shared goal that has a higher operational value than our differences. this is poison. i will address this in a following email in a new thread so as to not drag this one further off-topic. you mean this? ;) http://fritzboyle.com/wp-content/uploads/2012/02/workplace-subjectivity.jpg or this? http://www.youtube.com/watch?v=FitG_PLO9Rg (laughably aside, typical example of knowing the own field but not thinking the other parts of the problem are important as well) interestingly enough, since i often wear 2 (3, 4...) hats, i often have this struggle even with myself (ok, this sounds quite schizophrenic ;) so in the end the thing that becomes my opinion is the result of a weighted pro/cons of some thing being or not being implemented, in terms of perceived quality/experience by the user vs code quality vs maintanability etc, even tough the puzzle will be quite incomplete, given that of some fields i know, of some just uuh, kindof. can we translate this train of tough to a multi people team? (therefore being more complete) i think we can and became not (too) bad at this, but it's for the other thread ;) Cheers, Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Mentors for GSoC project
Hi Arjun, On Thursday, March 29, 2012 10:56:42 Arjun Basu wrote: I am Arjun (ultimatrix on irc) .This is a follow up to the mail I posted some days back. I was looking for a mentor who could guide me on the project Write a QML based client to GHNS(Get Hot New Stuff) . My earlier mentor can't mentor me anymore on account of being overloaded with mentoring tasks. This is intended to be a plasma active/ Harmattan based project. So I was wondering if someone could mentor me. As the proposal submitting has already started, I would really appreciate if someone could come forward to guide me. We got it, read your previous email, and the question on IRC a few times as well. No need to further inquire, it just produces extra noise. :) If you've sent in your proposal, and it's deemed good enough and interesting, there'll be a mentor for you. If not, that's bad luck. While it helps a bit to have someone already willing to mentor you, it's on no way necessary at this point for you to try finding someone yourself. Now sit back, relaxed and cross fingers :-) Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
[Bug 297043] Run kquiapp to stop plasma-device failed
https://bugs.kde.org/show_bug.cgi?id=297043 Lamarque V. Souza lamar...@kde.org changed: What|Removed |Added CC||lamar...@kde.org Component|General |desktop Assignee|active@kde.org |plasma-b...@kde.org Product|Active |plasma --- Comment #1 from Lamarque V. Souza lamar...@kde.org --- Maybe we need a QWeakPointer to hold the DialogProxy object. -- You are receiving this mail because: You are the assignee for the bug. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: activity configuration UI
On Thursday 29 March 2012 17:34:02 Marco Martin wrote: On Wednesday 28 March 2012, Marco Martin wrote: i still think the best way to still have buttons, have them always visible and taking less space is having them in the titlebar, like the ipad and the n9 do: http://www.silicon.com/i/s4/illo/photos/2010/June/iPad%20test/iPad%20VPN%2 0config%20screengrab.PNG btw, if now one uses the branch mart/useFullScreenSheet the confirm/cancel buttons of both the configure and add resources ui are embedded in the titlebar, they seem to look nice. as soon as we can break master again i'll merge so people can test it (for both speed differences and difference in look) Could you please post a screenshot so we can test the look immediately? Tank you :) ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: embracing our goals together
On Thursday 29 March 2012 14:16:43 Aaron J. Seigo wrote: hi... listening to the various people involved in the creation of new bits of UI in the shell, it seems that people concentrated on or were distracted by various issues and let's make a pleasing and elegant UI got lost. here's the hard and uncomfortable reality: when i first saw the new UI changes, i instantly realized i could not show it to others and be proud. it was not up to the standards we had shown ourselves capable of in the past. it was, in a word, embarrassing. Could you please indicate what other UI parts you are referring to? We have improve all of them, then. Imo it would be ideal to discuss each problematic UI separately, though. this is not limited to the Activity Settings UI, but when looking at the result of the work on the Activity Settings UI and then listening to various people involved, here is what i noted : * there was a lack of consensus around the implementation * the reasons why certain things could/could not be done was not well understood by everyone (both technical requirements as well as UI design) +1 I know that I don't completely understand the technical requirements and I suspect that some developers did not completely understand the reasons for some of our design decisions. Not because anybody is ignorant or stupid, but because we didn't explain them to each other well enough. * there was a feeling of conflict between the different people involved, a feeling derived from the belief that different people had different goals that could not be harmonized I can only speak for myself here, but I don't believe that members of the team have different goals. Different priorities, maybe, but personally, I don't perceive an actual conflict of goals. put bluntly, people focusing on UI design did not fully appreciate the technical hurdles and those working on the technical requirements seemed to view those working on UI design as obstacles in the path to implementation. the result was something nobody was truly happy with. this leads to a shocking question: if no one involved in the creative process was truly happy with it, how did it become the result of our efforts? it would be easier to understand if someone in our team thought it was the best UI ever; but was anyone truly, deeply proud of that result? did anyone feel that awesome! feeling when it was finally completed? or did everyone feel they'd compromised somehow, producing something dominated by the weaknesses of the compromise rather than by the strengths of an answer the team came up with together? It does look like a product of compromises to me as well. And compromise is rarely a good thing in UI design. Yet it's something likely to happen when people grow tired of discussing and just want to get it over with. And this is what seems to have happened for many - or all - of us here. Or, to use another term: What we did here was design by committee, which is pretty much always a bad thing. we need to remember that we have a shared goal here: to make an elegant user experience that supports life's activities that trumps everything. EVERYTHING. there is no implementation principle that is more important than that, there is no design concept that deserves attention before that goal is understood. +1 And that requires *lots* of effort in creative thinking from all those involved to overcome technical obstacles while minimizing the impact on the user's experience. technical issues and design decisions are the tools to reach that goal, but they are not the goal in themselves. we each have unique tools which we bring to the team so that we can reach that goal together. our individual skill sets are not to be used in conflict, but to create a coherent direction that brings us to our shared goal. Yes. And this requires lots and lots of communication, as direct as possible, and coordination of efforts. And maybe - I barely dare mentioning it - some kind of processes. Lean and flexible processes, of course, but it seems to me that wild-style does not work here. And I have an idea for that (or, to be exact, I present someone else's idea) which I will post in another email. that was seemingly lost in the creation of this particular UI component, and it showed starkly in the results. having thought about it some more, i regret having proposed a set of improvements as i did. It was good that you pointed us to the need of improving the dialog. it would have been better if i had first asked you if you were truly happy with the result, and if not what you would do to improve it. once improvements had been found by working together, we could then have reflected on the differences in process that got us from nobody is 100% happy with it to something that is elegant +1 i
How to avoid Design by Committee
Hi all, as announced in my previous mail, here is my idea for reducing the likelihood of Design by Committee. One disclaimer up-front: I don't want to abolish Democracy. Democracy is an essential part of Free Software and it's not necessarily a bad thing. Everybody's voice should be heard. *But*, democracy should not be confused with Everybody tosses his opinion in, we mix it all up and get... something. This leads to things that nobody is happy with, as we've just experienced. And here, my favorite author about product design, Marty Cagan, comes in. He is the author of Inspired: How to Create Products Customers Love [1], a book which I passionately recommend to everybody who is involved in the creation if digital products in any way. And so far, everybody who read it liked it just as much as I do. On his company blog, Marty wrote an article Avoiding Design By Committee [2]. Although I recommend everyone to read the article, here is the gist (already slightly adapted to our situation by me): Product design should mainly be done in a small team consisting of: - The product manager (not sure if we can always have a specific person for that, but it would be great if we did imo) - A development lead - A user experience lead Each member of the team must have the authority and competence to represent a complete perspective (PM for business and market, UX for the user, and Dev for the technology perspective). That way, all perspectives are represented right from the start. And if a specialist needs to be involved for a specific question, the corresponding core member can call him in for that question. Then, when the core team has come up with a design, it has to be presented to the larger group of stakeholders which then have their say. The benefit here is that at this point, the core team should already have considered, discussed and found solutions to at least the more obvious issues. According to Marty, a good product has to be - Useful - Usable - Feasible And only if the core team thinks that all three criteria are met they present their design to the stakeholders. When done exactly by the book, one team would be responsible for a whole product. However, I don't think this works in a project like Plasma Active. That does not mean, though, that we can't have core teams design specific features. If a small team with a representative for each perspective does the initial design for a feature, they can discuss issues much more efficiently than if they are discussed by the whole PA team. And only if the core team missed an issue or could not find an elegant solution to it does it need to be discussed by all. I wouldn't be surprised if this suggestion provokes negative initial reactions in many of you because it seems to contradict the values of Free Software, but I don't think it does. As I said, I don't mean to exclude anyone. Everybody should have a chance to voice his or her opinion. It's just that finding solutions to issues can be done much more efficiently upfront in a small group. So let's hear what you guys think about it. Thomas [1] http://www.amazon.com/Inspired-Create-Products-Customers- Love/dp/0981690408/ [2] http://www.svpg.com/avoiding-design-by-committee/ ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
[Bug 297068] New: When shutting down via Lock Screen, the sleep countdown runs first
https://bugs.kde.org/show_bug.cgi?id=297068 Bug ID: 297068 Severity: normal Version: unspecified Priority: NOR Assignee: active@kde.org Summary: When shutting down via Lock Screen, the sleep countdown runs first Classification: Unclassified OS: Linux Reporter: colo...@autistici.org Hardware: Meego/Harmattan Status: UNCONFIRMED Component: General Product: Active When I activate the Shutdown slider in the Lock Screen, the following happens: - The Lock Screen shortly disappears - The Lock Screen reappers and the Sleep countdown starts again - Once the countdown has finished, the device shuts down The shutdown should be initiated immediately. In case we want a countdown for the shutdown (so users could still cancel if they had accidentally initiated it), the countdown should not be on the Sleeping side. But imo there just should be no countdown for shutdown. -- You are receiving this mail because: You are the assignee for the bug. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: share-like-connect icons
Hi all, since nothing moved yet, i gave it a go, agreed shapes, systray style (definitely not finished, especially the hearth). the icons are in master even if not used, so if anyone wants to try to improve them is welcome to do so -- Marco Martin attachment: slc.png___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
[Bug 297068] When shutting down via Lock Screen, the sleep countdown runs first
https://bugs.kde.org/show_bug.cgi?id=297068 Lamarque V. Souza lamar...@kde.org changed: What|Removed |Added CC||lamar...@kde.org --- Comment #1 from Lamarque V. Souza lamar...@kde.org --- I had already noticed those problems: 1. The lock screen disappears because ksmserver (a KDE program) closes all user programas before exiting and ending the KDE session. 2. kwin is the last program ksmserver closes before exiting. I think kwin is re-launching the lock screen when it notices it was closed. 3. Since ksmserver gets the list of programs to kill before start killing processes the new lock screen is not killed and lonly disappears when Xorg is closed and the system proceed with the shutdown process. The shutdown is slow because ksmserver first try to contact each program for them to save their data and close themselves gracefully. If we do a fast shutdown we will be risking losing user data. The shutdown can also be very slow (2 or more minutes) if there are too much data on the swap partition. If we move the lockscreen code to ksmserver I think that will prevent the second launch of the lock screen and there will be no countdown after triggering the shutdown process too. -- You are receiving this mail because: You are the assignee for the bug. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: share-like-connect icons
On Thursday, March 29, 2012 21:52:11 Marco Martin wrote: Hi all, since nothing moved yet, i gave it a go, nice; a 100%+ improvement over the current ones. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
