D8006: Add edit button to desktop theme
jensreuterberg added a comment. Sry for not pinging back earlier but this sounds awesome. REPOSITORY R119 Plasma Desktop BRANCH master REVISION DETAIL https://phabricator.kde.org/D8006 To: davidedmundson, #plasma, apol Cc: jensreuterberg, apol, abetts, ngraham, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, sebas, mart
D8441: Wallpaper: hide color or blur filling options for full filling mode
jensreuterberg accepted this revision. jensreuterberg added a comment. This revision is now accepted and ready to land. Sure thing - I worry that there may be some technical difficulties even though I, with my limited technical skillset, can't foresee any. (Waiting nervously for a dev to kick down my door and kill me :) ) REPOSITORY R120 Plasma Workspace BRANCH master REVISION DETAIL https://phabricator.kde.org/D8441 To: guoyunhe, ngraham, jensreuterberg Cc: jensreuterberg, broulik, ngraham, davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, abetts, sebas, apol, mart
D8441: Wallpaper: hide color or blur filling options for full filling mode
jensreuterberg added a comment. Heh I may be the one who used transparent images - the idea being that you could, in theory set colour of an entire wallpaper based on icon colour using the correct kind of transparent image (essentially making darker parts less transparent meaning the lighter the area the brighter the underlying colour, creating a monochromatic image). To be quite frank as an idea it demanded slightly more work than was feasible, so I support this. REPOSITORY R120 Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D8441 To: guoyunhe, ngraham Cc: jensreuterberg, broulik, ngraham, davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, abetts, sebas, apol, mart
D7424: Very slightly increase text contrast for the default Breeze color scheme
jensreuterberg added a comment. I agree with this change but want to add, for posterity, since we don't know the future effects: IF something collaps due to this, some text-colour-to-icon thing pops up - we need to revert or work around it. So essentially banking on the edit to be easily done and easier reverted. +1 REPOSITORY R31 Breeze BRANCH arcpatch-D7424 REVISION DETAIL https://phabricator.kde.org/D7424 To: ngraham, hpereiradacosta, jensreuterberg, jriddell, kvermette, #vdg, abetts Cc: subdiff, abetts, januz, progwolff, broulik, sebas, plasma-devel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, apol, mart
D7747: Added an extra fuzzytime setting - Hobbit Time
jensreuterberg added a comment. Just throwing this in: Hobbit is a tricky one - remember that most for example fantasy games etc translate to "halfling" (I feel randomly disappointed there aren't more D&D players in this crowd) REPOSITORY R114 Plasma Addons REVISION DETAIL https://phabricator.kde.org/D7747 To: jayturner, ngraham Cc: jensreuterberg, broulik, ngraham, davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, abetts, sebas, apol, mart
D8607: Move power management checkbox to the top
jensreuterberg added a comment. Say FOR EXAMPLE (an example, not a clear suggestion or goal) - we could design all popups to follow a simple layout like this https://imgur.com/a/xbGt1 REPOSITORY R120 Plasma Workspace BRANCH master REVISION DETAIL https://phabricator.kde.org/D8607 To: ngraham, #plasma_workspaces, broulik, mck182, davidedmundson Cc: jensreuterberg, davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, abetts, sebas, apol, mart
D8607: Move power management checkbox to the top
jensreuterberg added a comment. To be quite honest I don't think there is a complete agreement on the layouts of the systray dialogues, although one should be considered - but since systray dialogues have a bit of a history and there are still plans going about another systray dialogue layout, we should be careful with adding work to current design. ON THE OTHER HAND: As long as the edits we plan are sort of careful we could create a unified ideal for the system tray popups with an eye towards eventual future edits. Is there an interest from a developer POV to create such a thing? REPOSITORY R120 Plasma Workspace BRANCH master REVISION DETAIL https://phabricator.kde.org/D8607 To: ngraham, #plasma_workspaces, broulik, mck182, davidedmundson Cc: jensreuterberg, davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, abetts, sebas, apol, mart
D7957: Turn on frames around dock widgets by default
jensreuterberg added a comment. I would avoid the shadows personally - it would be better to focus on better spacing between the two areas and a clearer font usage to define them. Like Broulik mentions it was removed more or less by active choice REPOSITORY R31 Breeze REVISION DETAIL https://phabricator.kde.org/D7957 To: ngraham, #breeze, #vdg Cc: jensreuterberg, abetts, broulik, emmanuelp, elvisangelaccio, nicolasfella, markg, cfeck, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, sebas, apol, mart
D8362: Added setting to toggle drawing of title bar separator
jensreuterberg added a comment. From the VDG's standpoint there is zero reason to block this - as Andy have mentioned above. As for adding options to breeze I didn't know we had anything against it. REPOSITORY R31 Breeze BRANCH titlebar-highlight REVISION DETAIL https://phabricator.kde.org/D8362 To: emateli, #breeze, #vdg, ngraham, hpereiradacosta Cc: andreaska, abetts, jensreuterberg, broulik, rpelorosso, #breeze, ngraham, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, sebas, apol, mart
D7905: Remove launch feature from hamburger button and restore to the toolbar
jensreuterberg added a comment. The hamburger menu was my suggestion so I should probably say something about it - for me the "launch" option is completely meaningless fluff. Another button to nothing. That being said, if this is something critical in normal usage then it should be in there - and as we have no chance to do a proper test of it doing what everyone else is doing might be preferred. I say go for it REPOSITORY R134 Discover Software Store REVISION DETAIL https://phabricator.kde.org/D7905 To: ngraham, apol, #discover_software_store Cc: jensreuterberg, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, abetts, sebas, apol, mart
[Breeze] [Bug 384129] Rename colors from British to American English
https://bugs.kde.org/show_bug.cgi?id=384129 Jens Reuterberg changed: What|Removed |Added CC||jens...@kolabnow.com --- Comment #1 from Jens Reuterberg --- "In this class we learn English, not American" as my old English teacher used to say. The choice of names for colours are most probably my fault simply because that is how I spell them. "Grey", "Colour", "Aluminium". But its potato/potato as far as I am concerned -- You are receiving this mail because: You are the assignee for the bug.
[Breeze] [Bug 381288] Breeze could use higher-contrast text by default (tweaked color scheme attached)
https://bugs.kde.org/show_bug.cgi?id=381288 --- Comment #7 from Jens Reuterberg --- You do have a good point. Perfect black on light-light grey is the preferred one... (although as a print-monkey I need to say "Bright Yellow on Dark Grey" or the other print monkeys may get angry ;) ) I worry about the inverted colour scheme though and icon effects. I propose this - lets create a secondary theme and then try to do some proper testing. I mean the tricky bit is tying up the bag as it where (because we don't want #00 background for breeze dark) as the colour scheme is such a huge chunk of the identity in so many other areas (from mascots to print material, webpages etc) - will the gain from swapping to #00 in readability justify eventual issues there? Or am I just bikeshedding? We also need to see if we are creating a huge problem for the developers in the future... so we would need to have a dev in on it to supervise so we don't create a mess Sebas (et al) can we sort of hold off on this while we drag poor Nate into the VDG room for a chat? On Sunday, 18 June 2017 15.42.54 CEST Nate Graham wrote: > https://bugs.kde.org/show_bug.cgi?id=381288 > > Nate Graham changed: > >What|Removed |Added > > Status|RESOLVED|UNCONFIRMED > Resolution|WONTFIX |--- > > --- Comment #6 from Nate Graham --- > Thanks for the comments, everyone. > > I have to disagree that this is a matter of subjectivity or taste--this is > just my preference and other people might not like it. There are objective, > scientifically derived principles governing things like eyestrain and > readability: > > https://www.nngroup.com/articles/low-contrast/ > http://www.tinhat.com/usability/color.html > http://contrastrebellion.com/ > http://universalusability.com/access_by_design/text/contrast.html > > From the above articles, you can see that the *most* readable, usable text > is 100% black on a not-quite-100%-white background, since pure white can be > blinding on bright screens. Breeze is *so close* with the pleasant light > gray backgrounds, but the text itself needs to be a bit bolder to reap the > rewards of maximum readability. This will not present a "harsh" contrast; > on the contrary, it will make the text *more attractive*, not less. Again, > this is not my personal preference, but rather the result of decades of > hard-earned usability investigation. I encourage you to read those > articles. -- You are receiving this mail because: You are the assignee for the bug.
Re: [Breeze] [Bug 381288] Breeze could use higher-contrast text by default (tweaked color scheme attached)
You do have a good point. Perfect black on light-light grey is the preferred one... (although as a print-monkey I need to say "Bright Yellow on Dark Grey" or the other print monkeys may get angry ;) ) I worry about the inverted colour scheme though and icon effects. I propose this - lets create a secondary theme and then try to do some proper testing. I mean the tricky bit is tying up the bag as it where (because we don't want #00 background for breeze dark) as the colour scheme is such a huge chunk of the identity in so many other areas (from mascots to print material, webpages etc) - will the gain from swapping to #00 in readability justify eventual issues there? Or am I just bikeshedding? We also need to see if we are creating a huge problem for the developers in the future... so we would need to have a dev in on it to supervise so we don't create a mess Sebas (et al) can we sort of hold off on this while we drag poor Nate into the VDG room for a chat? On Sunday, 18 June 2017 15.42.54 CEST Nate Graham wrote: > https://bugs.kde.org/show_bug.cgi?id=381288 > > Nate Graham changed: > >What|Removed |Added > > Status|RESOLVED|UNCONFIRMED > Resolution|WONTFIX |--- > > --- Comment #6 from Nate Graham --- > Thanks for the comments, everyone. > > I have to disagree that this is a matter of subjectivity or taste--this is > just my preference and other people might not like it. There are objective, > scientifically derived principles governing things like eyestrain and > readability: > > https://www.nngroup.com/articles/low-contrast/ > http://www.tinhat.com/usability/color.html > http://contrastrebellion.com/ > http://universalusability.com/access_by_design/text/contrast.html > > From the above articles, you can see that the *most* readable, usable text > is 100% black on a not-quite-100%-white background, since pure white can be > blinding on bright screens. Breeze is *so close* with the pleasant light > gray backgrounds, but the text itself needs to be a bit bolder to reap the > rewards of maximum readability. This will not present a "harsh" contrast; > on the contrary, it will make the text *more attractive*, not less. Again, > this is not my personal preference, but rather the result of decades of > hard-earned usability investigation. I encourage you to read those > articles.
Re: [Breeze] [Bug 381288] Breeze could use higher-contrast text by default (tweaked color scheme attached)
I have to agree with Sebas here: the choice is a "damned if you do, damned if you don't level" - the harsh contrasts would make many users feel as if the experience is worse... I am not trying to wave you away of course - you are more than right there are many users who find the theme too vague but as there is a contrast colour scheme of Breeze Dark it feels as if its kinda covered. On Friday, 16 June 2017 17.46.16 CEST Nate Graham wrote: > https://bugs.kde.org/show_bug.cgi?id=381288 > > Nate Graham changed: > >What|Removed |Added > > CC||pointedst...@zoho.com > > --- Comment #3 from Nate Graham --- > It's worth mentioning that reviewers have noted Breeze's lack of sufficient > text contrast. For example: > http://www.ocsmag.com/2017/02/17/the-state-of-plasma/
[Breeze] [Bug 381288] Breeze could use higher-contrast text by default (tweaked color scheme attached)
https://bugs.kde.org/show_bug.cgi?id=381288 --- Comment #5 from Jens Reuterberg --- I have to agree with Sebas here: the choice is a "damned if you do, damned if you don't level" - the harsh contrasts would make many users feel as if the experience is worse... I am not trying to wave you away of course - you are more than right there are many users who find the theme too vague but as there is a contrast colour scheme of Breeze Dark it feels as if its kinda covered. On Friday, 16 June 2017 17.46.16 CEST Nate Graham wrote: > https://bugs.kde.org/show_bug.cgi?id=381288 > > Nate Graham changed: > >What|Removed |Added > > CC||pointedst...@zoho.com > > --- Comment #3 from Nate Graham --- > It's worth mentioning that reviewers have noted Breeze's lack of sufficient > text contrast. For example: > http://www.ocsmag.com/2017/02/17/the-state-of-plasma/ -- You are receiving this mail because: You are the assignee for the bug.
Re: Plasma Vision v 2.0
Yes that was a worry of mine too - that certain people in the community would use the vision as a club against developers but then I thought that the issue there isn't so much the vision - its the person using it as a club. Any vision can be used as a club, every statement of intent, even now where we don't have one certain people are using it on reddit to harass, harangue or simply misuse it as their idea of an "argument". It can't be avoided. Some people are simply going to take whatever ammunition they can use and at the same time ignore the realities of developers ("no I can't make it controllable through telepathy, even if that is your workflow!") If someone uses the vision (or ANYTHING) to harass our developers I think we as a community must be more vocal. Its a lacking of ours to not step up and just set that person right. Simply going "well the realities of programming is that even though your idea is something the developer would LOVE to include its not feasible right now" - or if its actually more on the harassing side speak up in that channel and clearly put yourself between developer and harasser. This is a very very relevant topic but one where the key aspect of it is 1) us being able to tell users and actual commentators that "Well that feature is a good idea but currently there is no way to do it, help out though!" or "Hmm that would make the rest of the application worse - do you have a suggestion on making your idea fit more gracefully?" 2) us being able to tell trolls and harassers to bugger off more quickly. We loose developers when we don't step up and give the only argument some of these people deserve: "No, go away" (sry this is a sore topic of mine and something that kinda pisses me off more than I thought it would :) ) As for the vision: I think that as a statement of intent its good, toning it down may hurt it to the point its more a Mission Statement or Strategy Document - we want the vision to be a flag in the distance to aim for as well. On Thursday, 15 June 2017 21.11.34 CEST Martin Flöser wrote: > Am 2017-06-09 09:40, schrieb Jens Reuterberg: > > Time to get back to the vision. > > > > Plasma Vision 2 > > Plasma never dictates the user's needs, it only strives to solve them. > > Plasma > > never defines what the user should be allowed to do, it only ensures > > that she > > can. > > I'm not too happy with this part as it can be interpreted by the user > that we must support his/her weird workflow. I can already see how users > bring up the old "you must support this, because you are all about > customization" now backed with the vision. > > Cheers > Martin
Re: Plasma Vision v 2.0
I will add all these as notes on Phabricator task as well - keep the ideas coming everyone its golden so far! On Friday, 16 June 2017 01.27.42 CEST Aleix Pol wrote: > On Thu, Jun 15, 2017 at 9:16 PM, Martin Flöser wrote: > > Am 2017-06-12 01:19, schrieb Aleix Pol: > >> On Sun, Jun 11, 2017 at 11:13 PM, Jonathan Riddell > >> > >> wrote: > >>> Yay, I like it. > >>> > >>> Across different operating systems? We don't do anything on Windows or > >>> Mac. > >>> > >>> Jonathan > >>> > >>> On Fri, Jun 09, 2017 at 09:40:28AM +0200, Jens Reuterberg wrote: > >>>> Time to get back to the vision. > >>>> > >>>> Plasma Vision 2 > >>>> > >>>> Plasma Desktop is a cross device work environment where total trust is > >>>> put on > >>>> the user's capacity to best define her own workflow and preferences. > >>>> > >>>> Plasma is simple by default, a clean work area for real world usage > >>>> which > >>>> intends to stay out of your way. > >>>> Plasma is powerful when needed, enabling the user to create the > >>>> workflows that > >>>> make her more effective to complete her tasks. > >>>> > >>>> Plasma never dictates the user's needs, it only strives to solve them. > >>>> Plasma > >>>> never defines what the user should be allowed to do, it only ensures > >>>> that she > >>>> can. > >>>> > >>>> Our motivation is that we enable actual work to happen, across devices, > >>>> across > >>>> different operating systems, using any application needed. > >>>> > >>>> We build to be durable, we create to be usable, we design to be > >>>> interesting. > >>>> > >>>> > >>>> > >>>> Reasoning behind the vision: > >>>> The key aspects of it is that Plasma is "Cross Device" - we state that > >>>> as > >>>> clearly as possible. "Simple by default, powerful when needed" has to > >>>> be > >>>> repeated within it to hammer that in as that is, in many ways a > >>>> communicative > >>>> tool we really want associated with Plasma. > >>>> > >>>> Removed Desktop Environment after last one as that was seen as too much > >>>> "computer" and too little "Mobile" etc. > >>>> > >>>> The focus is "work" and "tasks", IRL stuff focusing on a user that > >>>> needs > >>>> to > >>>> solve an actual problem instead of an attempt to create further ones > >>>> through > >>>> complexity. At the same time we want to ensure that we never strip the > >>>> user of > >>>> options (this is one of the weak points in the vision - more on that > >>>> below) > >>>> > >>>> Finally its the poetic vitruvian line at the end: Firmitas, Utilitas, > >>>> Venustatis. That something is "well built" or "durable", that something > >>>> is > >>>> "usable" (from a users perspective easy to use) and finally "beautiful" > >>>> or > >>>> interesting to use - inspiring usage. Build/Create/Design is intended > >>>> not as > >>>> work roles ("designer" etc) but something we all do ("designing the > >>>> system" > >>>> for example). > >>>> > >>>> > >>>> > >>>> Feedback, spellchecking, grammar checking and just "yay" or "neigh" > >>>> wanted. > >>>> > >>>> /Jens > >> > >> Plasma Desktop doesn't work on Windows/OS X, but we know our users > >> will be using different systems on different machines: maybe Android > >> or iOS on the phone, maybe OS X or Windows at work or at home. > >> When developing Plasma we need to keep that in mind and leverage it. > > > > Nevertheless we shouldn't give users hope of having Plasma available on > > Windows, OSX or iOS. Even for Android it does not look like any part of > > Plasma could be available anytime soon. > > > > Given that I'm also very uneasy with the formulation of operating systems. > > Personally I would like to not see operating systems mentioned in the > > vision. Personally - as most know - I wouldn't mind if we would only > > support Linux (and maybe, maybe the BSDs). Given that at least for me > > this part of the vision is not fitting and nothing I strive for with my > > work. > > As I said above: > > Plasma Desktop doesn't work on Windows/OS X, but we know our users > > will be using different systems on different machines: maybe Android > > or iOS on the phone, maybe OS X or Windows at work or at home. > > When developing Plasma we need to keep that in mind and leverage it. > > This doesn't mean that the vision text is okay, it means that we need > to tune it so that it communicates properly. > > Aleix
Re: Plasma Vision v 2.0
Awesome! "elegant" is a lovelly way to cover that ground - what do you think Martin? /jens On tisdag 13 juni 2017 kl. 11:30:10 CEST Sebastian Kügler wrote: > On zaterdag 10 juni 2017 09:28:38 CEST Jens Reuterberg wrote: > > You are a man of my own heart! > > > > Beautiful is the core ideal of "venustatis" - I just went for > > "interesting" > > because beautiful has become so... depricated in English usage (or modern/ > > western usage). Almost like a pejorative. In practice beauty contains > > "interesting" as well so thats why I went for that as a go-between. > > A sort of city planning idea where beauty is the thing that drives people > > to want to explore something - a slight bend in a road so you can't see > > down it. An inexplicable park placed between houses to entice you. > > > > For me, and to Vitruvius, beauty was the thing in any design that gave the > > user pleasure and need to be near it. A object or construct needed to be > > stable and durable, then it needed to be usable by a human, designed by > > human metrics - but then it also needed to be pleasurable to be near > > ("pleasurable" has a completely different context now so I didn't use that > > - don't want us blocked in security-filters on search engines ) > > > > I would more than happily change it to "we design to be beautiful" I just > > worry that it sounds negative? But if you and others think that would be > > better - I would LOVE to change it to "beautiful" > > > > Oh also here is the phabricator task https://phabricator.kde.org/T2070 > > How about "elegant" instead of beautiful? For me, it encompasses even more > positive aspects we strive for. > > Also, I'd remove the total in total trust as it could be seen as us shifting > responsibility to the user, for example in picking excellent defaults. > Moreover, total doesn't actually add a lot here, at least IMO.
Re: Plasma Vision v 2.0
Thanks :) I tried to find a different, less convuluted way of saying "different distros" - that also tied in other devices beyond laptops and stationary. If you have a better wording I would love to have it - I can't think of one single word that better fits the need. On Sunday, 11 June 2017 23.13.12 CEST Jonathan Riddell wrote: > Yay, I like it. > > Across different operating systems? We don't do anything on Windows or Mac. > > Jonathan > > On Fri, Jun 09, 2017 at 09:40:28AM +0200, Jens Reuterberg wrote: > > Time to get back to the vision. > > > > Plasma Vision 2 > > > > Plasma Desktop is a cross device work environment where total trust is put > > on the user's capacity to best define her own workflow and preferences. > > > > Plasma is simple by default, a clean work area for real world usage which > > intends to stay out of your way. > > Plasma is powerful when needed, enabling the user to create the workflows > > that make her more effective to complete her tasks. > > > > Plasma never dictates the user's needs, it only strives to solve them. > > Plasma never defines what the user should be allowed to do, it only > > ensures that she can. > > > > Our motivation is that we enable actual work to happen, across devices, > > across different operating systems, using any application needed. > > > > We build to be durable, we create to be usable, we design to be > > interesting. > > > > > > > > Reasoning behind the vision: > > The key aspects of it is that Plasma is "Cross Device" - we state that as > > clearly as possible. "Simple by default, powerful when needed" has to be > > repeated within it to hammer that in as that is, in many ways a > > communicative tool we really want associated with Plasma. > > > > Removed Desktop Environment after last one as that was seen as too much > > "computer" and too little "Mobile" etc. > > > > The focus is "work" and "tasks", IRL stuff focusing on a user that needs > > to > > solve an actual problem instead of an attempt to create further ones > > through complexity. At the same time we want to ensure that we never > > strip the user of options (this is one of the weak points in the vision - > > more on that below) > > > > Finally its the poetic vitruvian line at the end: Firmitas, Utilitas, > > Venustatis. That something is "well built" or "durable", that something is > > "usable" (from a users perspective easy to use) and finally "beautiful" or > > interesting to use - inspiring usage. Build/Create/Design is intended not > > as work roles ("designer" etc) but something we all do ("designing the > > system" for example). > > > > > > > > Feedback, spellchecking, grammar checking and just "yay" or "neigh" > > wanted. > > > > /Jens
Re: Plasma Vision v 2.0
You are a man of my own heart! :) Beautiful is the core ideal of "venustatis" - I just went for "interesting" because beautiful has become so... depricated in English usage (or modern/ western usage). Almost like a pejorative. In practice beauty contains "interesting" as well so thats why I went for that as a go-between. A sort of city planning idea where beauty is the thing that drives people to want to explore something - a slight bend in a road so you can't see down it. An inexplicable park placed between houses to entice you. For me, and to Vitruvius, beauty was the thing in any design that gave the user pleasure and need to be near it. A object or construct needed to be stable and durable, then it needed to be usable by a human, designed by human metrics - but then it also needed to be pleasurable to be near ("pleasurable" has a completely different context now so I didn't use that - don't want us blocked in security-filters on search engines :) ) I would more than happily change it to "we design to be beautiful" I just worry that it sounds negative? But if you and others think that would be better - I would LOVE to change it to "beautiful" Oh also here is the phabricator task https://phabricator.kde.org/T2070 /Jens PS: And although I know this is a plasma-devel list I would love to discuss the concept of crafts-vs-arts in regards to your definition of beauty as "lacking function" (or functionalism/brutalism) - perhaps that is for another time? On Friday, 9 June 2017 11.10.11 CEST Martin Steigerwald wrote: > Jens Reuterberg - 09.06.17, 09:40: > > We build to be durable, we create to be usable, we design to be > > interesting. > […] > > > Reasoning behind the vision: > […] > > > Finally its the poetic vitruvian line at the end: Firmitas, Utilitas, > > Venustatis. That something is "well built" or "durable", that something is > > "usable" (from a users perspective easy to use) and finally "beautiful" or > > interesting to use - inspiring usage. Build/Create/Design is intended not > > as work roles ("designer" etc) but something we all do ("designing the > > system" for example). > > I´d like to see the word beautiful in the vision or a word that more clearly > indicates that beauty is part of the vision. > > Why? Cause I believe utility is not everything. If something is just useful, > but not beautiful, I believe something is missing. As… in the other way > around as well an application is just beautiful, but basically unuseable. > > You have it in "design to be interesting"… but for me "interesting" just > does not mean beautiful. I am not completely sure whether "beautiful" would > be the right word. What came to my mind was also: > > "we design to be engaging." > > But that might also miss an important aspect. > > For me beauty has two aspects: > > 1. One is beauty without function. In nature, if left alone, or carefully > cared for, all that lives tends to create beauty. It doesn´t seem to do so > to reach a certain goal, at least not solely, but it (also) seems to be the > pure joy of expressing itself – of course you can call this a goal as well > – to me. > > 2. Beauty that engages. In the terms of a work environment this would be > beauty that actually makes it a joy to work with the environment. > > Of course these are overlapping each other. > > I definately see roam for the second aspect in Plasma, but also… for the > first one. > > Thanks,
Plasma Vision v 2.0
Time to get back to the vision. Plasma Vision 2 Plasma Desktop is a cross device work environment where total trust is put on the user's capacity to best define her own workflow and preferences. Plasma is simple by default, a clean work area for real world usage which intends to stay out of your way. Plasma is powerful when needed, enabling the user to create the workflows that make her more effective to complete her tasks. Plasma never dictates the user's needs, it only strives to solve them. Plasma never defines what the user should be allowed to do, it only ensures that she can. Our motivation is that we enable actual work to happen, across devices, across different operating systems, using any application needed. We build to be durable, we create to be usable, we design to be interesting. Reasoning behind the vision: The key aspects of it is that Plasma is "Cross Device" - we state that as clearly as possible. "Simple by default, powerful when needed" has to be repeated within it to hammer that in as that is, in many ways a communicative tool we really want associated with Plasma. Removed Desktop Environment after last one as that was seen as too much "computer" and too little "Mobile" etc. The focus is "work" and "tasks", IRL stuff focusing on a user that needs to solve an actual problem instead of an attempt to create further ones through complexity. At the same time we want to ensure that we never strip the user of options (this is one of the weak points in the vision - more on that below) Finally its the poetic vitruvian line at the end: Firmitas, Utilitas, Venustatis. That something is "well built" or "durable", that something is "usable" (from a users perspective easy to use) and finally "beautiful" or interesting to use - inspiring usage. Build/Create/Design is intended not as work roles ("designer" etc) but something we all do ("designing the system" for example). Feedback, spellchecking, grammar checking and just "yay" or "neigh" wanted. /Jens
D6140: Standardize the GlobalHeader height
jensreuterberg added a comment. I have to agree with Marco (inside) although I am currently wearing a striped tanktop and chequered shorts so "good taste" may not apply to me ;) REPOSITORY R169 Kirigami REVISION DETAIL https://phabricator.kde.org/D6140 To: apol, #kirigami, mart Cc: jensreuterberg, plasma-devel, apol, mart
D3650: lower mouse acceleration limit to 0.0
jensreuterberg added a comment. Ping? REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D3650 To: sitter, plasma-devel Cc: graesslin, broulik, jensreuterberg, ZrenBot, spstarr, progwolff, lesliezhai, ali-mohamed, abetts, sebas, apol, mart, lukas
Re: Plasma 5.10 video NOT FINAL
Sry not critical input or anything - but wanted to say "Great work!" :) On Sunday, 28 May 2017 23.51.19 CEST Łukasz Sawicki wrote: > Hi, > > Here is a Plasma 5.10 video NOT FINAL yet ;). Feel free to post your > opinions, comments etc about it. I don't plan any radical changes but > I can still tweak it a bit if there will be such a need. > > https://youtu.be/AtI2DcA70bY > > Cheers > Łukasz
D5767: Postpone searches for half a human moment
jensreuterberg added a comment. Sry for seeming obtuse here but isn't the results from previous queries saved between sessions and displayed for the search? REPOSITORY R134 Discover Software Store REVISION DETAIL https://phabricator.kde.org/D5767 To: leinir, apol Cc: jensreuterberg, markg, plasma-devel, ZrenBot, spstarr, progwolff, lesliezhai, ali-mohamed, abetts, sebas, apol, lukas
[Breeze] [Bug 378606] Please replace those childish avatar images
https://bugs.kde.org/show_bug.cgi?id=378606 --- Comment #5 from Jens Reuterberg --- I'm not entirely certain which are the "technical" ones you refer - is it the B/W then thank you I made them. I rather disagree with you except on one point - the default avatar - I think that was just chosen more or less at random at the time and was the stock/base out of which the "famous people" avatars where made (Gandhi, Da Vinci etc) That leaves us with the issue of which one to chose. B/W penguin? -- You are receiving this mail because: You are the assignee for the bug.
[Breeze] [Bug 378606] Please replace those childish avatar images
https://bugs.kde.org/show_bug.cgi?id=378606 Jens Reuterberg changed: What|Removed |Added CC||jens...@kolabnow.com --- Comment #3 from Jens Reuterberg --- We have a rather eclectic mix of avatars to chose from http://i.imgur.com/eOZn8D8.png , anyone can suggest more images if they want to. We are serious. Any distro can, if they choose, define WHAT kind of user they prefer. If you want to stick to "as serious as possible" you can just keep the B/W avatars. You can even remove every single avatar except one or two that you prefer. We are a DE, we don't tell distros what they're user group should be and we have added up a few avatars that we felt like doing - our job is to ensure that. -- You are receiving this mail because: You are the assignee for the bug.
D5339: Include a bottom toolbar for the application page
jensreuterberg added a comment. I think both are good (but man those colours Aleix :D also the text should be white) The logic behind the alternatives for posterity: 1. Buttons on bottom of Detail view - the install button in the detail view is there for those who will want to read information about the application. The goal being that all applications should have a wealth of meta data (we're not there yet but "one day" etc) and since a user can install from the middle column as well the assumption is that a user in the detail view will be interested in the information within. So the bottom right is in that case (and in the case of left-to-right reading of course) is the naturall place for such a button. 2. Buttons on the top of Detail view - the back button is in this case slightly more natural as it resembles a breadcrumb its a page system and that is where its often expected, that being said the downside is that it camoflages the install button. Since we don't have coloured buttons and can't make the install button pop out that makes it slightly more tricky. 3. Coloured areas instead of buttons - this is the tack-and-paste solution to #2's problem. By making strikingly coloured areas instead of buttons we can essentially put the install button wherever we like since it will scream for attention no matter what. REPOSITORY R134 Discover Software Store REVISION DETAIL https://phabricator.kde.org/D5339 To: apol, leinir, colomar, jensreuterberg Cc: plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
[Breeze] [Bug 374300] Option to change the font color on the lock screen
https://bugs.kde.org/show_bug.cgi?id=374300 Jens Reuterberg changed: What|Removed |Added CC||jens...@kolabnow.com --- Comment #1 from Jens Reuterberg --- Currently the only option is to change the wallpaper you use (either by modding it to include lighter sections in the area where the dark text is or changing it entirely). The issue isn't that there is anything blocking a way to set it from a design perspective but rather where to include it currently and how hard it is to do from a technical standpoint. We have a massive problem with settings - and there has been quite the discussion about SDDM/Lockscreen/Wallpaper-settings which will probably affect this. Adding it in the "set wallpaper" section for Lockscreen and SDDM seems like a good temporary solution (since they are mostly empty space currently) but then again what will happen with the work when those are redesigned? TL;DR from a design perspective nothing blocks the idea that you can change font colour - at the same time, the programmers will have to reply on how complex it is to add - and whether the risk of a future overhaul will make that effort worthless. -- You are receiving this mail because: You are the assignee for the bug.
[Breeze] [Bug 373668] Tiny keyboard layout indicator is the Lock Screen
https://bugs.kde.org/show_bug.cgi?id=373668 Jens Reuterberg changed: What|Removed |Added CC||jens...@kolabnow.com --- Comment #8 from Jens Reuterberg --- Ok I think this discussion needs to mellow out a tad... BACKGROUND TO CURRENT PLACEMENT: The assumption was that the users who did need it would find it, where as the users who didn't need it wouldn't have the entire screen muddled up with different controls. This in combination with the motivation to make the act of starting and shutting down feel like one unified whole instead of different aspects of the DE handing over to each other. Now that was designed slightly before the fact that the keyboard layout isn't visible if you don't have another keyboard layout installed - which sorta turns the tables. That leaves another issue - will putting every single control on prime real estate solve the issue? It will for you (Anton) because that is what you personally need - but will it do that for all or will that as well as the switcher for different DE's (which would then have to be moved as well) just clog up the controls? WHAT TO DO: Looking at SDDM - the key task there is to fill in your password (which is why its centered). The second task is to switch users, the third is to shut down the computer, reboot etc. The date/time is there to ensure the similarity between the login and the lock screen visually. So whatever we change here - will affect the design of Lock Screen, etc. There is a future addon for the lock screen (not SDDM) where you can control the music player and that will be placed in the center column of the lock screen but underneath. We could dedicate that area to it BUT that may also result in some issues like a TON of stuff clogging it up. Making the buttons bigger would be interesting but that wont fix much either in the long run since the reason they are pushed away to the sides is to 1) get them out of the way as not being universally relevant objects and 2) get some kind of balance (and not make it look like a middle school book report (center aligned text everywhere)). So what we need is something that not only displays the lesser relevance of the keyboard layout in comparison with login etc - but also balances it out. TL;DR its an issue, but a slightly fiddlier one than one may think -- You are receiving this mail because: You are the assignee for the bug.
[Differential] [Commented On] D3549: [Lock Screen] Add keyboard icon for keyboard layout switcher
jensreuterberg added a comment. Fancy work! REPOSITORY R120 Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D3549 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: broulik, #plasma, #plasma:_design, mart Cc: jensreuterberg, graesslin, plasma-devel, lesliezhai, ali-mohamed, abetts, sebas
Re: Selecting a Plasma logo
About half a year ago this thread started and so far no actual change has happened. The background is that the past logo for Plasma Desktop was disagreed upon by the Plasma developer team and they wanted a new one. Thomas created a competition of sorts which had a lot of suggestions in it. Currently, no final decision has been made on this which leaves us with three options: 1) VDG decides. 2) The developers decide 3) We use the KDE logo Now #1 means that we with a high level of chance will go to the Plasma logo we had before this started. There is zero criticism against it that has been valid except that the developers who didn't like it in the first place didn't like it. Which is relevant of course. #2 means this thread needs a choice. This WILL NOT continue in any structured form where people are egged on to make "suggestions" and then a round table debate. It has taken work time from VDG contributors, caused meaningless arguments and bikeshedding and has been the kind of work we can all see will never end. I honestly regret not having the courage to say "No" when it was first debated. (if some designer wants to work with the Plasma Developers on this, go for it, no one will stop you of course. But the VDG will not supply designers to this task formally or make any further efforts which has been so far a half a year of throwing manhours into a pit) #3 Means that we take the work on seperating KDE the community from Plasma the desktop and pretend it didn't happen. Which sounds dramatic but its essentially leaving it as a status quo. Now this is Open Source and KDE, none of us have the right to dictate to others what to do with their spare time. But as a designer I can assure you that what we are doing with this is wasting our collective time. There is NO perfect solution. No perfect logo for a project which out of the blue will summarize everyones expectations and hopes. Nothing that can't be shredded in a round session of bikeshedding and "uhms" and "ehrs". There will never be a choice made. The reason why the old icon was the one we stuck with has parts to do with no one actually speaking up at the time when it was thrown in there. But that is not relevant. It is good because it is different from the K, clearly different. It is good because it played on the shape of the cashew symbol but using the design guides formed in the beginning of Plasma 5. It is good because it is so absolutely abstract as to not clash with any other symbolism out there. It is a blank slate to be loaded with meaning instead of an heraldic symbol where the meaning and statements we feel we are part of need to be presented. This is also BAD as it needs to be used and reused to gain meaning. If we don't use it it is JUST a bit of abstract scribble. None of this means that the suggestions in the thread Thomas posted are bad, or worse than, or subpar or anything. It just means that if the choice was mine - if we where picking one thing to present to a client in a professional setting. I would pick the original logo without a second hesitation. Unless something is posted here my assumption is that the design decision is up to the KDE Design Group/VDG and we will choose, reply and move on with this and our lives. On Monday, 25 July 2016 20:54:14 CET Thomas Pfeiffer wrote: > Dear Plasma development team, dear VDG, > the official deadline for the Plasma logo contest has passed yesterday. > We have five entries into the contest, with one actually consisting of five > different mash-ups and modifications of the other entries, and one being > Plasma's current logo. > You can find all the proposals here: > https://forum.kde.org/viewtopic.php?f=285&t=133836 > I think we have quite a good selection here, and hope that we can find > something here which we can agree on. > In the contest thread, I promised a jury consisting of VDG members and > Plasma team members. > Now I've decided that since the whole Plasma team has to be able to identify > themselves with the logo, and all VDG members should have the possibility > to chip in as well, everyone who participates in the discussion is part of > the jury. There won't be a voting process. Either we can agree on a logo, > or everything stays like it is (the official Plasma logo still being what > we have now, and the K logo being used for the launchers). > I'd give us a discussion period until Sunday, unless a clear agreement can > be reached before that. > Please refer to the logo proposals by the creator's forum name (remember > that our current logo is Uri's, not mine ;) ), and for Ken's just say e.g. > "Ken's fourth logo". > Happy discussions, here is to us finding a logo we can all (at least more or > less) identify with! > > Thomas > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Commented On] D3538: Drop resize animation when adding pages
jensreuterberg added a comment. Lovelly! <3 The animations remaining feel way cleaner REPOSITORY R169 Kirigami REVISION DETAIL https://phabricator.kde.org/D3538 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: apol, #kirigami, mart Cc: jensreuterberg, colomar, plasma-devel, apol
Re: Touchpad Gestures - Experimental
Hell and High water has been passed, here is the new and improved! Martin G and whomever else is interested I would love to chat about it tomorrow on IRC (I may be late up since I've been sick for a few days so my wake time is a tad too late but I will be there with a sunny disposition) /Jens On Saturday, 26 November 2016 13:44:50 CET Jens Reuterberg wrote: > It will, come hell or high water be finished tomorrow > (Got three other projects that needs to be worked on today) > > Miscommunication is a bummer but it happens - no hard feelings or anything I > hope. Let's laugh about it when we're older :) > > On Friday, 25 November 2016 16:23:44 CET Marco Martin wrote: > > On Thu, Nov 24, 2016 at 3:44 PM, Martin Graesslin > > wrote: > > > Hi Jens, > > > > > > I'm extremely sorry, there must have been a huge misunderstanding. > > > > > > Most of the gestures you came up with are not at all supported. We only > > > get > > > the following touchpad gestures reported: > > > > > > * multi-finger pinch/rotate gesture > > > * multi-finger swipe gesture > > > > There has been a problem in communication for sure. but, whatever > > happened, is happened, let's try to do more back and forth in the > > future. > > In this particular case, how do we proceed? > > Jens, can you adapt the document only treating cases regarding multi > > finger pinch and multi finger swipe? > > > > -- > > Marco Martin Touchpad Gestures New Logic: Forming Groups of current actions we need covering. These are not at all "any possible" but they are the ones we should consider or remove only with good reason. Please remember that they are all experimental, tentative design and not in any way a final design choice. The idea is still to create a logical langauge of touchpad gestures with connections to the touchscreen notes taken earlier. Reasoning for that has already been presented. The action groups: These are sorted into Window Control, which is when the user want to handle her windows on the desktop. Desktop Control which is handling all actions for the desktop and session. Mouse Control are the actions we already cover and needs to be handled as well as zoom in-app. Further is a side idea, for a way to leave open existing gestures something the user can define. Again: none of this will scream "wow" these are all ment to be USEFUL more than exciting. We should keep this in focus, our goal is to be functional and flexible - our key part is the users right to edit the shortcuts, for now only through a textfile instead of a GUI setting considering the state the system settings are still in. --Relevant Notes- To simplify the actions with less possible gesture the one issue is three-finger tap to activate Middle Click. By exchanging it we are liberating a lot of different gestures - BUT this MUST, MUST be able to be set by the user otherwise we are forcing a gesture on a user. --Actions Suggested- WINDOW CONTROL Close Active Window Maximize / Un-maximize Alt-Tab, Swapping Window Window Spread -> Leads to further controls Move Window Resize Window DESKTOP CONTROL Desktop Grid -> Leads to further controls Switch Desktop (Move between desktops) Lock Screen Show Desktop MOUSE ACTIONS Single Click Right Click Middle Click Zoom/Unzoom Scroll Horizontal/Vertical FURTHER Specific App Launch or App Menu --Gestures Available- After the last email some miscommunication was cleared up. These are the actions - one of them is NOT clear and need a "ok" from Martin G. TAPPING (touch and release, noticing on release) Note on Tapping: there are some issues concerning the logic of the touchpad, for example touch and hold on most touchpads do not at all mimic holding the left mousebutton. Instead it is a deep press. The issue lies in that we don't have any test machines where there isnt this "deep press" available. So in most cases double tapping for example the window border triggers a move effect. But single tapping and dragging does not. This seems fairly natural. The issue of course is what happens if a machine does NOT have this "deep press" of the touchpad. Information on this would be interesting. Tapping also have subgestures. Doubletaps for example where you click+release in quick succession. But interesting also the Double tap + Hold where the user double taps for example the window border but holds the second tap. Tap, release, tap and hold. This to activate moving the window. Also there is the issue of touchpad areas - where top right is reserved for rightclick for example. All this shows the complexity of the touchpad
Re: Touchpad Gestures - Experimental
It will, come hell or high water be finished tomorrow (Got three other projects that needs to be worked on today) Miscommunication is a bummer but it happens - no hard feelings or anything I hope. Let's laugh about it when we're older :) On Friday, 25 November 2016 16:23:44 CET Marco Martin wrote: > On Thu, Nov 24, 2016 at 3:44 PM, Martin Graesslin wrote: > > Hi Jens, > > > > I'm extremely sorry, there must have been a huge misunderstanding. > > > > Most of the gestures you came up with are not at all supported. We only > > get > > the following touchpad gestures reported: > > > > * multi-finger pinch/rotate gesture > > * multi-finger swipe gesture > > There has been a problem in communication for sure. but, whatever > happened, is happened, let's try to do more back and forth in the > future. > In this particular case, how do we proceed? > Jens, can you adapt the document only treating cases regarding multi > finger pinch and multi finger swipe? > > -- > Marco Martin
Touchpad Gestures - Experimental
Sry for long wait, there was some misunderstandings concerning touchpad gestures based on past work and was set right today that no matter on what level we where at, we should pass it onward. So these are all based on the normal assumptions and understanding of how designing something which we don't know the technical limitations of will work. This it is the design of a pattern, a language (since otherwise its just another desktop cube or burning closing of windows) - so if one isn't possible, chances are we are back to square one. For example, most of these have to do with Windows and Workspaces (giving a quick nod to apps in Pinch- to-zoom and Rotate) which is intentional. Also note that Windows and Workspaces use four fingers to control things, which is also intentional (with the exception of the Pinch manouver which is really tricky to do with four fingers in the little available testing I could do). The actions SHOULD mimic each other so that each one isn't one more complex detail unrelated to everything else that the user have to learn. While "Four fingers reserved for WM/DE" is a good guide some care have to be taken since cramming four fingers onto a touchpad can be tricky. The question is if it is technically possible. If not, should "three fingers reserved for WM/DE" replace it? This is impossible to tell now of course. This is a link to the draft of the design document: https://notes.kde.org/p/touchpadgestures The document is split into 1) Design Notes (information about the idea of the design) 2) Possible Actions (list of Actions mostly focusing of course (see above) on the WM/DE) 3) Possible Gestures (a list of gestures ranging from unused now, to probably impossible technically) 4) Suggested Combinations (suggested to be implemented as standards) 5) Notes and planning (some notes on planning for the future and the problems we will run into design wise) 6) (For reference) Touch Screen notes (early notes of a talk between me and Aleix about touchscreens where the initial idea of "reserve N finger actions to DE/WM came from) Finally - these are of course all experimental and tentative design. Anything else would be practically impossible.
[Breeze] [Bug 370374] GRUB menu has huge lag due to theme
https://bugs.kde.org/show_bug.cgi?id=370374 Jens Reuterberg changed: What|Removed |Added CC||jens...@kolabnow.com --- Comment #10 from Jens Reuterberg --- I'm interested whether this effect is true when using other grub themes? Because if it is, it's something way bigger than KDE/Plasma and something that would make sense to ask around about since many distros and DE's also provide their own themed grub. If on the other hand it isn't then obviously something is terribly wrong in OUR grub theme that needs figuring out. -- You are receiving this mail because: You are the assignee for the bug.
[Differential] [Commented On] D2984: Center the notification label on Breeze's lockscreen and make it use the full width before wrapping
jensreuterberg added a comment. True it is a bit of an odd duck that whole area :) Either way, no blockage from our POV as far as I can tell REPOSITORY rPLASMAWORKSPACE Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D2984 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: pritambaral, #plasma Cc: jensreuterberg, pritambaral, plasma-devel, lesliezhai, ali-mohamed, abetts, sebas
[Differential] [Commented On] D2984: Center the notification label on Breeze's lockscreen and make it use the full width before wrapping
jensreuterberg added a comment. From a visual standpoint: on the one hand it breaks the "Left Align Text" when available, on the other the key feature of it is to inform the user of something critical (which trumps visual coherence to the theme). So there is no protest from the Visual/Design side of things REPOSITORY rPLASMAWORKSPACE Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D2984 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: pritambaral, #plasma Cc: jensreuterberg, pritambaral, plasma-devel, lesliezhai, ali-mohamed, abetts, sebas
Re: A Plasma Vision draft
This is actually fairly tricky because what is needed is a metric to work towards: sayiing "fast and stable" is not very exact. But you raise fair points - how do we ensure that it doesn't exclude anyone? To me a vision is a statement of intent, but not a boundary beyond practical choices. "Should we pick Y or X, we can only pick one?" Should be something that you can answer with it. In this case "Does one of them help professional users? Pick that!". Not "I want to do Y!" and then someone going "No you can't because X and Z would be more for professional users". One is a boundary, the other is a vision I feel. We can't make a few sentences work as a complete boundary - that would take a way longer document. This is more like the header for a longer text, a statement of intent or coming things but it can't be something that defines complete usage. Still, you bring up good points - but how can we realize them as a vision? How can "fast/stable" function except as something that would work for everyone, all DE's etc? (also added plasma-devel since the thread is made for plasma-devel the reply got weird though halfway through) /Jens > > IMO, the first step is to get rock-solid stable, performant (whatever you > call that in English) and productive desktop, so that everyone says: "I > want to use that". This is, to me, a nice vision. > > Also, most of my friends (often using Ubuntu+Unity) told me "KDE (understand > Plasma) is the most good looking desktop out there those days". Don't look > boring, please (Office=boring). Also when I think office, I think excel + > word + firefox. You don't need a nice desktop for that, anything would be > ok. Geeks and private people have more needs. > > Disclaimer: I might have had one beer to many, and I mostly speak with my > kind of user case in mind, and try to extrapolate. I'm not always using > Plasma at work, but I think it's the best at home, and as a geek as well. > > > If on the other hand this is a real worry, and an issue then the > > discussion > > shouldn't be what the vision statement should say but if it should say > > something at all. Which is not something negative but an actual option :) > > I agree with that, but I don't agree that my point of view doesn't say > anything: see above. > > Cheers > Olivier > > > On 26 September 2016 18:33:00 CEST, Olivier Churlaud > > > > wrote: > > >Le lundi 26 septembre 2016, 15:12:08 CEST Thomas Pfeiffer a écrit : > > >> On 26.09.2016 13:27, Olivier Churlaud wrote: > > >> > Hi, > > >> > Sorry if I come late, I wasn't aware of this thread... > > >> > > > >> > Le lundi 26 septembre 2016, 12:56:25 CEST Jens Reuterberg a écrit : > > >> >> "Plasma is for people using a computing device in a professional > > > > > >context, > > > > > >> >> where productivity, performance and privacy are essential" > > >> > > > >> > I find that the "is for people .." kind of restrictive. I agree > > > > > >that you > > > > > >> > need to have a precise target audience, but don't freak out other > > > > > >people. > > > > > >> > If this is your vision, it should be the first big sentence that > > > > > >people > > > > > >> > will read. Normal users might say, 'uh, I want games as well, and > > >> > listening to music and editing videos: it's not for me'. > > >> > > >> We could replace "is for" with "focuses on" if necessary. > > >> On the other hand, the stricter a vision is, the more useful it > > > > > >becomes to > > > > > >> focus effort. With the above vision, if someone complains about bad > > > > > >gaming > > > > > >> performance in Plasma, we can just ask "Do you play games in a > > > > > >professional > > > > > >> context? If not, then sorry, your usecase is not what Plasma is made > > > > > >for." > > > > > >> Editing videos, though, for me is a classic example of a professional > > >> context. Not everybody edits videos professionally, but if Plasma > > > > > >works > > > > > >> well for those who do it professionally, it should also work well for > > > > > >those > > > > > >> who do it privately.
Re: A Plasma Vision draft
So the current version after revisions looks like this. To this comes of course addendums like the one in previous versions. We simply want feedback on this so that we know the previous objections are cleared out and we can go forward "Plasma is for people using a computing device in a professional context, where productivity, performance and privacy are essential" Added to that may come the "detail parts" and it will be packaged up, we just want to give everyone a chance to comment first until we nail it down. /Jens On Monday, 4 April 2016 15:45:30 CEST Jens Reuterberg wrote: > Hey, so me and Thomas have been hard at work on this for a while now and I > think we are at a good point to show what we got. > > Please remember that THIS IS JUST A DRAFT! Nothing is set in stone even if > the document looks fancy (the PNG attached to this email) > Below is the raw text of it. > > /Jens > > The Vision is split into three subsections: > Vision, Details and and three key points. > The actual Vision: > Plasma is created to be the primary user interface for multiple device > classes providing a stable, performant, usable and above all productive > environment for professional computer users. > Plasma's feature set is selected for its usefulness in a productive context > with a constant care to user privacy. > > Detail 1: Plasma not only promises to never invade its users' privacy > itself, but also protect against other parties' attempts to spy on them. > Security is a precondition to privacy, all privacy measures are useless in > an insecure system. > Detail 2: Our target audience works with their devices in a professional > setting. Productivity is key for them and their user interface must give > them an efficient and swift way of completing tasks. > Detail 3: A perfomant desktop is the base of any productive environment and > code quality, usability and aesthetic value are relevant to the experience. > Nothing in the interface exists on its own merits but for what it brings to > the user. > > The Three Key points: > Private, Professional, Performant.
Re: From Grub to Shutdown project update
> As you walked me trough the design a bit before, I think the design is quite > reasonable and feasible (i have doubts only on the semitransparent session > switcher, it may have to be baked in the lockscreen for now instead, but > those are just small details right now) > Yes added an alternative version of a session switcher using the lockscreen wallpaper (in the mockup "stock blue") - as that is not in anyway a show stopper and any thing that can help this get sorted by 5.8 is good. The main thing is that you guys can expect us in the VDG to be VERY VERY flexible with reworking mockups if that is needed for something to get it to work. > now, one thing i would like to happen is people taking up a piece of it, of > the thing they are more versed into (being sddm, the lockscreen, whatever) > signal here they are going to work on it, and have the pieces of the puzzle > then merged in master asap so they can run some months on devel machines to > be ironed out before release. That would be awesome. My goal is to have this implemented for 5.8 come what may and will be happy to focus hard on whatever is needed for the design personally ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: From Grub to Shutdown project update
Please note that the green buttons in SDDM and Lockscreen will change to proper Plasma buttons instead of wide green ones. Here is the Pholio page which might be valuable to keep an eye on https://phabricator.kde.org/M58 On Monday, 25 July 2016 12:24:56 CEST Jens Reuterberg wrote: > From Grub-to-shutdown, a unified experience > > GOAL OF PROJECT: > To create one sensation from grub to shutdown, where the user whenever she > is outside of the desktop environment and interacting with the parts needed > to make the desktop environment make sense feel like she is part of one > unified whole instead of several small bits and pieces all working on their > own. > > PROJECT HISTORY AND ISSUES: > All you all probably recall the initial release of it was met with very > negative opinions, mostly based on details (like the grub menu being bright > blue) and that parts where implemented but not the whole making if feel less > as a whole than some new details. Now these criticisms will come again > during this release but it will at least be the criticism towards something > new, than something that simply does not work to accomplish the intended > effect. > > Due to the projects size it has put a massive strain on the way we, > developers and designers work. As the design in itself is in practice > several small parts all being redesined individually it seems fairly > straight forward, but without them all based on each other as one > overarching whole, they simply don't make sense. Since it is almost > impossible to test for designers before release and small glitches or > misunderstandings when finally discovered are incredibly huge issues for > the design - it becomes frustrating to designers. Since these fixes comes > in AFTER the work is done and released and what seems as frivolous changes > that are technically huge are pushed hard by designers, its incredibly > frustrating for developers. > > Added to that the several different channels of communications means > individual devs for each individual part talk to individual designers. > Confusion ensues when the way designers and devs work, individual designers > have fun ideas and suggestions that get easily translated into "hmmm the > VDG wants this". Then the VDG as a whole notice parts have been implemented > assuming that "hmmm the devs wants this" and the whole cycle continues. > > PROJECT FIX: > This is a rather new development for us - and it requires some kind of > extraordinary fix. > > We have settled for two: the first is to set the entire project on lockdown. > That means that ALL information not being followed by a "This is the > opinion of the VDG that we want to implement" and combined with mockups or > wikiedits is NOT ment as anything more as discussion topics or looking for > theoretical input from the developers. We will as a group ensure that we > minimize all this as much as possible, be clear with our intentions in > discussions and that we as a group sign off properly on work. > > Second fix is the barebone-design of the project. What this is is that we > create the BARE MINIMUM of what is needed for the design to work. A minimum > of animations, effects etc. The entire design we are sending you now is > what is the minimum for the entire project to make sense. The reason for > that is so that instead of regressions, we have addons. Perhaps a new > animation in the future, perhaps some tweaked placement or color changes at > some point. What will NOT happen is that you (developers) will have people > from us (VDG) turning up a month or two away demanding that everything in a > certain area will be scrapped. > What we need, the VDG, is that when something is not clear, when something > isn't obvious to you in the mockups - no matter how silly it may seem - you > have to ask. And you have to accept that there may not be a direct answer. > The person you ask may not be able to answer and it is up to us in the VDG > to ensure that we all feel capable of saying "I don't know" (which has been > an issue before). Our point is to ensure that the answer you get is > correct. > > __ > > > The Design: > This is a text run through of the proposed design for From Grub to Shutdown. > Future ideas are placed within [brackets] and mean plans for future tweaks, > things that do are not intended for this release or critical for the design > to work as a whole. > > Certain parts will have "Critical Notes" these are notes about technical > things, usually concerning speed or feasibility that needs answering and > testing first before too much work goes in as they otherwise need a > redesign. > &g
From Grub to Shutdown project update
From Grub-to-shutdown, a unified experience GOAL OF PROJECT: To create one sensation from grub to shutdown, where the user whenever she is outside of the desktop environment and interacting with the parts needed to make the desktop environment make sense feel like she is part of one unified whole instead of several small bits and pieces all working on their own. PROJECT HISTORY AND ISSUES: All you all probably recall the initial release of it was met with very negative opinions, mostly based on details (like the grub menu being bright blue) and that parts where implemented but not the whole making if feel less as a whole than some new details. Now these criticisms will come again during this release but it will at least be the criticism towards something new, than something that simply does not work to accomplish the intended effect. Due to the projects size it has put a massive strain on the way we, developers and designers work. As the design in itself is in practice several small parts all being redesined individually it seems fairly straight forward, but without them all based on each other as one overarching whole, they simply don't make sense. Since it is almost impossible to test for designers before release and small glitches or misunderstandings when finally discovered are incredibly huge issues for the design - it becomes frustrating to designers. Since these fixes comes in AFTER the work is done and released and what seems as frivolous changes that are technically huge are pushed hard by designers, its incredibly frustrating for developers. Added to that the several different channels of communications means individual devs for each individual part talk to individual designers. Confusion ensues when the way designers and devs work, individual designers have fun ideas and suggestions that get easily translated into "hmmm the VDG wants this". Then the VDG as a whole notice parts have been implemented assuming that "hmmm the devs wants this" and the whole cycle continues. PROJECT FIX: This is a rather new development for us - and it requires some kind of extraordinary fix. We have settled for two: the first is to set the entire project on lockdown. That means that ALL information not being followed by a "This is the opinion of the VDG that we want to implement" and combined with mockups or wikiedits is NOT ment as anything more as discussion topics or looking for theoretical input from the developers. We will as a group ensure that we minimize all this as much as possible, be clear with our intentions in discussions and that we as a group sign off properly on work. Second fix is the barebone-design of the project. What this is is that we create the BARE MINIMUM of what is needed for the design to work. A minimum of animations, effects etc. The entire design we are sending you now is what is the minimum for the entire project to make sense. The reason for that is so that instead of regressions, we have addons. Perhaps a new animation in the future, perhaps some tweaked placement or color changes at some point. What will NOT happen is that you (developers) will have people from us (VDG) turning up a month or two away demanding that everything in a certain area will be scrapped. What we need, the VDG, is that when something is not clear, when something isn't obvious to you in the mockups - no matter how silly it may seem - you have to ask. And you have to accept that there may not be a direct answer. The person you ask may not be able to answer and it is up to us in the VDG to ensure that we all feel capable of saying "I don't know" (which has been an issue before). Our point is to ensure that the answer you get is correct. __ The Design: This is a text run through of the proposed design for From Grub to Shutdown. Future ideas are placed within [brackets] and mean plans for future tweaks, things that do are not intended for this release or critical for the design to work as a whole. Certain parts will have "Critical Notes" these are notes about technical things, usually concerning speed or feasibility that needs answering and testing first before too much work goes in as they otherwise need a redesign. Other parts have details pending. This will be marked clearly in this document. That means that the needed detail isn't exactly defined yet but will be done within days and will be communicated as clearly as possible. GRUB MENU https://share.kde.org/index.php/s/CUJB96B7daE0buh The grub menu has to be minimalistic in format. The criticism towards the old grub menu was that the blue color was too sharp and sudden. It also caused issues with the "dark square" that turn up after grub menu and the issues with the sudden sharp break between the blue grub menu and scrolling text when Plymouth doesn't work (due to proprietary drivers). In this redesign we have essentially taken the earlier pr
[Breeze] [Bug 365318] KRDC is unreadable under breeze dark theme
https://bugs.kde.org/show_bug.cgi?id=365318 Jens Reuterberg changed: What|Removed |Added CC||ohy...@gmail.com --- Comment #12 from Jens Reuterberg --- Neither Okular, k3b or ktorrent are affected by what gtk theme you use though... unless you have set the KDE themes to pick up the GTK theme - which looking at it seems unlikely. With the GTK theme there is a generation shift that happened quite recently (and may not have picked up) where GTK3 apps suddenly didn't work with the old GTK3 theme. But that seems like it's not whats happening at all (that glitch just messed with rightclick menu's being white-on-white). What happens when you set the entire destop via Look n Feel to "Breeze Dark" and then go to GTK theme, set that in turn to Breeze Dark (and Breeze Dark Icons) - then do the log-in-log-out dance? -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Big font and icon sizes on master
I would make a bugreport of it. (Also I notice that you have a few icons there that don't come with any padding at all (like trojita icons (hmm you've managed to sort out multiple IMAP accounts?) and the weird circle one)) which is something we simply can't fix except by actively fixing all broken icons) Looking at the clock it seems like there is something odd afoot as the outer numbers are completely hidden outside of the panel. But make a bugreport if you can. On Friday, 8 July 2016 21:35:08 CEST Jan Kundrát wrote: > Hi, > after my recent upgrade of all of KF5 and Plasma to git master from git > master from around 2016-06-21, the icon sizes in the System Tray and the > font size in my clock applet are now huge -- see the attached image. > > Please note that my panel is vertical, on the right edge of the display. I > also tend to switch screens, but the wrong size is present also right after > login. > > (Please let me know if you would prefer me to submit this over bugzilla, > trello, phabricator or IRC, I don't really care about the channel.) > > Cheers, > Jan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Which applications does the Plasma team recommend to use with Plasma?
IRC is too uncommon to be "ship by default" - Cantata is not relevant enough and VLC will work as that if needed, or something more simplistic would be good (and Luca's criticism is relevant as the distro maintainers for distros more focused on software freedom would have massive issues). The lightest possible image viewer would be good but to be honest there are very few that fit the bill: some stick to menubars on top (for no reason) some use a completely different logic than normal (like Photoqt) making them fiddly to use. Gwenview but edited to at least not stick to the menu bar logic would be good enough I suppose. Also isn't Kwalletmanager dead and the replacement has yet to make an appearence? (is there any other walletmanager, Qtbased that would be a good replacement until the replacement comes along?) Aside from that I ppersonally have no objections. On Monday, 4 July 2016 14:43:07 CEST Thomas Pfeiffer wrote: > Hi everyone, > every now and then, distributions approach us asking which applications they > should ship by default with Plasma, or they complain about us not providing > such information. > Although the Plasma team of course does not have to provide such > information, it may still be helpful also for us because we can try to make > sure that these applications work well in Plasma. > Choosing such applications is not an easy task, but to get things started, a > group of people who were stranded in Bielefeld waiting for their trains > after a meeting sat together to come up with an initial suggestion. Here is > the result: > > File manager: Dolphin > Music player: Cantata > Video player: VLC > Document viewer: Okular > Software center: Discover > Communication: Konversation, KDE Telepathy (cautiously, because while it > works well at the moment, it is also looking for a maintainer) > Password storage: KWalletmanager, kwallet-pam > Hardware support: Skanlite, Print manager > Utilities/system tools: KCalc, KDE Connect, Konsole, KSysguard, Kate, Kamoso > (if a distro wants to ship a webcam app at all) > Office suite: We do not recommend one at the moment > Pim suite: We do not recommend one at the moment. > Browser: We do not recommend one at the moment > > If an applicaiton does not show up in this list, this does of course not > mean we don't like the application or the team behind it, it just means > that we _currently_ don't feel confident to recommend it to users. > > This is our initial proposal, now we'd like to get the input from the rest > of the Plasma team! > > Thanks, > Thomas > ___ > 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
[Breeze] [Bug 364953] Breeze and Breeze Light themes are the same but listed twice
https://bugs.kde.org/show_bug.cgi?id=364953 --- Comment #4 from Jens Reuterberg --- Created attachment 99798 --> https://bugs.kde.org/attachment.cgi?id=99798&action=edit example for new Breeze multicolour image -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Breeze] [Bug 364953] Breeze and Breeze Light themes are the same but listed twice
https://bugs.kde.org/show_bug.cgi?id=364953 Jens Reuterberg changed: What|Removed |Added CC||ohy...@gmail.com --- Comment #3 from Jens Reuterberg --- "Breeze Light", "Breeze Dark" and "Breeze" should be the naming. As for image to represent each differently I think it wont be that difficult - we could add the 5.4 wallpaper or something in the background instead of just light grey colour to represent "any colour you like"? -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 128332: [Plasma-nm] Indicate flight mode in system tray icon
> On July 1, 2016, 7:23 a.m., Jan Grulich wrote: > > Looks good for me, let's wait for the VDG approval. [adds the seal of "Approved by Designers" to the code] - Jens --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128332/#review96984 --- On June 30, 2016, 8:21 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128332/ > --- > > (Updated June 30, 2016, 8:21 p.m.) > > > Review request for Network Management, Plasma and KDE Usability. > > > Repository: plasma-nm > > > Description > --- > > This changes the tray icon to the airplane icon when in flight mode. > > Also changes the SwitchButton to use a PlasmaCore.IconItem instead of a > PlasmaCore.Svg to be consisteht with the tray icon. > > BUG: 364626 > > > Diffs > - > > applet/contents/ui/SwitchButton.qml 3ea3079 > applet/contents/ui/Toolbar.qml 64b6e0a > libs/declarative/connectionicon.h 499b4f6 > libs/declarative/connectionicon.cpp 90060a3 > > Diff: https://git.reviewboard.kde.org/r/128332/diff/ > > > Testing > --- > > Enabled flightmode, got airplane icon > Disabled flightmode, briefly got "no network" icon until my wifi was > connected again. > > The flight mode is only shown when flight mode is enabled and there really > isn't any connection. > > NOTE VDG: The icon flightmode-on and flightmode-off need to be renamed to > network-flightmode-on and network-flightmode-off (keeping the old ones in > there for compatibility!) so Plasma IconItem finds it. > > > File Attachments > > > Flightmode icon > > https://git.reviewboard.kde.org/media/uploaded/files/2016/06/30/df8a84c2-5a91-42d1-be43-70685061c8e4__Screenshot_20160630_221424.png > > > Thanks, > > Kai Uwe Broulik > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 128332: [Plasma-nm] Indicate flight mode in system tray icon
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128332/#review97012 --- Looks good, as long as it doesn't add an extra icon visible at all times but replace the network icon we are all for. - Jens Reuterberg On June 30, 2016, 8:21 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128332/ > --- > > (Updated June 30, 2016, 8:21 p.m.) > > > Review request for Network Management, Plasma and KDE Usability. > > > Repository: plasma-nm > > > Description > --- > > This changes the tray icon to the airplane icon when in flight mode. > > Also changes the SwitchButton to use a PlasmaCore.IconItem instead of a > PlasmaCore.Svg to be consisteht with the tray icon. > > BUG: 364626 > > > Diffs > - > > applet/contents/ui/SwitchButton.qml 3ea3079 > applet/contents/ui/Toolbar.qml 64b6e0a > libs/declarative/connectionicon.h 499b4f6 > libs/declarative/connectionicon.cpp 90060a3 > > Diff: https://git.reviewboard.kde.org/r/128332/diff/ > > > Testing > --- > > Enabled flightmode, got airplane icon > Disabled flightmode, briefly got "no network" icon until my wifi was > connected again. > > The flight mode is only shown when flight mode is enabled and there really > isn't any connection. > > NOTE VDG: The icon flightmode-on and flightmode-off need to be renamed to > network-flightmode-on and network-flightmode-off (keeping the old ones in > there for compatibility!) so Plasma IconItem finds it. > > > File Attachments > > > Flightmode icon > > https://git.reviewboard.kde.org/media/uploaded/files/2016/06/30/df8a84c2-5a91-42d1-be43-70685061c8e4__Screenshot_20160630_221424.png > > > Thanks, > > Kai Uwe Broulik > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 128311: standardize kcm layout - autostart
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128311/#review97011 --- This is one of those base things we need sorting out as "buttons moving around between KCM's" is a no brainer UI wise to fix. When one button which does the same thing is flung across the screen this cause all other fixes to the layout to be more or less meaningless. - Jens Reuterberg On July 2, 2016, 8:34 a.m., Andreas Kainz wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128311/ > --- > > (Updated July 2, 2016, 8:34 a.m.) > > > Review request for Plasma. > > > Repository: plasma-desktop > > > Description > --- > > rearrange buttons according to other kcm's > > > Diffs > - > > kcms/autostart/autostartconfig.ui 6dfdb8b > > Diff: https://git.reviewboard.kde.org/r/128311/diff/ > > > Testing > --- > > > File Attachments > > > before > > https://git.reviewboard.kde.org/media/uploaded/files/2016/07/02/67d0047a-124e-4c7a-b14f-b0656b67019c__before.png > after > > https://git.reviewboard.kde.org/media/uploaded/files/2016/07/02/90dcdd71-e769-4116-adb3-1adcfe45fcbd__after.png > > > Thanks, > > Andreas Kainz > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Commented On] D2000: Make it possible to adjust volume even if it's muted
jensreuterberg added a comment. How is this presented to the user, visually? I mean when using shortcuts the pop-up (early morning the oms/cms/abbreviation-thing) that shows you sound is muted, or lowered/raised is on screen for just a flicker - which for most are enough since the information is so clear and if you raise/lower it becomes a string of images creating an animation. Wont adding a third effect sort of make that too complex? Then the slider: the issue with a slider thats not opaque is that it tend to grey out, a greyed out object is by all norms something you can't interact with. Not saying that its wrong - just wondering if you guys would want suggestions for alternative ways to present it from us in the VDG? REPOSITORY rPLASMAPA Plasma Audio Volume Applet REVISION DETAIL https://phabricator.kde.org/D2000 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: xuetianweng, drosca Cc: jensreuterberg, plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Commented On] D1816: Switch to Noto Mono as default monospace font
jensreuterberg added a comment. From a design perspective this is a no-brainer. Using another font is meaningless. So we in the VDG obviously approve of a switch to Noto Mono. (that said I cant comment on the technical issues only the design ones) REPOSITORY rPLASMAINTEGRATION Integration for Qt applications in Plasma REVISION DETAIL https://phabricator.kde.org/D1816 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: jriddell, #plasma, #plasma:_design Cc: jensreuterberg, palimaka, dhaumann, mart, davidedmundson, plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5.7 Test Days scheduled for June 19th+20th; report from first prep meeting
Addendum from me: I'm working on some nice infopgraphic for "How to do a bugreport" - the idea being that it should be inviting, simple and suggesting different paths to contact devs in a good and friendly way. The notes I have so far about it is: 1) How to get the relevant data about the bug out This is tricky because we want someone checking it to feel like they are doing a good job without overwhelming them with info. 2) How to check for duplicates Here I want to show how to search for the right place to put the bug, but also introduce the simplest sort of "bug triaging light" for people just to show how it works without scaring people away. 3) How to remain active with a bug This is where I want to present what to expect with bugs, how bug checking works from a dev POV and why its relevant to remain active on a bug report. (also a way to prepare for the rather clipped language in Bugzilla) What I need help with is: - Suggestion for a way to get the "relevant data" when you encounter a bug - What devs want users to think about when they may want to talk to you When I get the notes in a line (this is just the quick notes I took during the meeting that I thought I'd expand upon) I would love to pass them around to devs with some doodles for graphics just to ensure that everything feels good since they may affect you guys and gals eventually. :) /Jens On Tuesday, 12 April 2016 19:42:02 CEST Eike Hein wrote: > Hi everyone, > > below are the notes for our first prep meeting for our upcoming > Plasma 5.7 Test Days. You can also find the full log attached to > this mail: > > attendees: eike, bhushan, jens, riddell, notmart, kbroulik > chair: eike > > intro (excerpt, see full log): > > [19:02] ok, so we want to hold a Plasma Bug Day on June 19th or > 20th (or both), with developer and user participation, both to find out > what sort of impact we can have on quality with that sort of thing, and > also to send a message that we do care about Plasma 5 being reliable at > this point > [19:02] Also its about trying to find users who could see > themselves being part. > [19:02] the idea will be to give the impending 5.7 release a good > run-through and find any regressions/problems that need to be addressed > for the release > [19:03] So for me the relevant bit is that users who have > until now not helped out, get a good report with KDE people in general > and may feel like helping out again > [19:03] that means we should discuss (a) prereqs, (b) test day > content, (c) assign some tasks in prep, (d) messaging/promo and (e) nail > down a date > > (a) prereqs > - we will need ISO images to base tests on > -- jens will talk to kaos, opensuse, fedora; riddell (neon) was also > listening in > -- rotating isos in future test days can be good for distro relations, > it's all one team > > (b) test day content > - we want testcases a la > https://fedoraproject.org/wiki/Test_Results:Fedora_23_Final_RC10_Desktop > (final table) > - avoids everyone bringing their pet bug, instead they get asked to > accomplish a task and log the results, and find new problems along the way > - unclear how specific or coarse test cases need to be (example: "add a > widget and position it to your liking"), experience will tell > - VDG will produce some example test case content for us to discuss and > mull more at next week's meeting > - sample test case areas: widget management, panel management, common > customization settings, device control (network, audio), launching apps, > window management, .. > > (c) messaging/promo > - banners, stickers etc for test days (webbanner - talk to eV about > sticker printing) > - blog posts > - "how to file a bug report" infographic > - promo launch deadline is first week of june (three weeks before test > day), materials for blogs need to be ready by then > > (d) workflow during test day > - direct to bugzilla vs logging results on wiki, then devs generating > their own reports from it > - pro bugzilla: educating users to use the real thing > - pro wiki: avoids torrent of issues on bugzilla; devs have to do triage > either way > - no final decision, leaning towards wiki, but may need more feedback > > (e) dates > - weekly prep meetings; next meeting tuesday 12:00 UTC in #plasma again > - our test day will be Test Days: June 19th (Sunday) + June 20th > (Monday) to catch users off-work and devs at-work > - two stages: Sunday might be focused on collection, giving devs to roll > in on Monday content to work on > - means it will collide with plasma monday hangout, though ... > > > Cheers, > Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: A Plasma Vision draft
On the one hand I fell in love with the word "nimble" (We have to do something cool based on words like "nimble" and "swift" one day - I don't know what but I will bribe you till you do it Sebas, we can't let those two words get to some marketing department somewhere) On the other David has some good points - "performant" although fiddly is a better word I think. Also this thread is GOLD - keep the critique coming everyone I am taking notes like paper is going out of style. On Tuesday, 5 April 2016 00:17:59 CEST David Edmundson wrote: > On Mon, Apr 4, 2016 at 11:48 PM, Sebastian Kügler wrote: > > On Monday 04 April 2016 17:29:58 Thomas Pfeiffer wrote: > > > On Montag, 4. April 2016 15:04:30 CEST Jonathan Riddell wrote: > > > > I'm not convinced performant is a word although it seems to be used > > > > for computer jargon > > > > http://english.stackexchange.com/questions/38945/what-is-wrong-with-the-wo > > > > > > rd -performant > > > > > > It is clearly jargon. As Jens already said, the question is: Can we > > > > afford > > > > > the jargon or not? We think we can, but there are certainly also good > > > arguments against it. > > > > I don't like it. How about "nimble", it expresses power and speed in a > > positively sounding adjective. > > What I like about "performant" is it doesn't just mean fast *. > It covers a broader range of metrics, and the text beneath it in Detail 3 > goes on about code quality and usability which "nimble" doesn't really > cover in itself. > > David > > *or at least it would if it was a proper word > > > -- > > sebas > > > > Sebastian Kügler•http://vizZzion.org•http://www.kde.org > > ___ > > 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
Re: A Plasma Vision draft
In all fairness Thomas mentioned that too :D But we thought "oh computer stuff works, lets keep it" plus its a nice catch-all word isn't it... Don't know of an alternative to it without adding a lot of extra word faffing tbh. (Anyone who knows: HALP!) During CERN professionals came up as an example of what we wanted to aim to, now we may have gone in a tad hard for that (since I like exclusions as a way to define ourselves) - either that or we are stuck with "enthusiasts" (which means nothing at all) or "hobbyists" (which is not a grand group to be connected to when it comes to words I feel - I may be wrong of course these are just my reasonings) On Monday, 4 April 2016 15:04:30 CEST Jonathan Riddell wrote: > On 4 April 2016 at 14:58, Jens Reuterberg wrote: > > Thanks for feedback! :) > > > >> First, it looks very professional, nice :) > >> one thing tough , is the underline of the words, the red underline may > >> look > >> like a spellcheck error (i'm wondering if something else could be used > >> instead of an underline, like bullets, those icons in small, or just a > >> background..) > > > > Yes now that you say it it does look like a spelling check going on :D Ok > > ok this calls for some experimentation. Will edit that > > > > But the text? What do you think about the text? > > I'm not convinced performant is a word although it seems to be used > for computer jargon > > http://english.stackexchange.com/questions/38945/what-is-wrong-with-the-word > -performant > > The main part which surprises me is the user profile for professional > users. I guess you've thought about who that includes and who it > excludes? How does it differentiate us from the competition? > > Jonathan > ___ > 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
Re: A Plasma Vision draft
MORE IRC stuff posted for safekeeping: [16:04] "for multiple device classes" and "computer users" could be better coupled, "device" can be all kind of things, but is first in text, while "computer" might be more bound to "desktop computer" and comes second. that part IMHO needs rework [16:04] or "devices" On Monday, 4 April 2016 16:05:25 CEST Jens Reuterberg wrote: > Ok so some good criticism from IRC that I thought I should document here for > posterity: > > [15:57] - criticism: "Plasma is not good enough for professional > use" [15:58] - people complaining "but this is supposed to be a > just for fun thing, nothing serious! I hate you now!" > [15:58] jensreu: point #3 : This is plasma vision and in 3rd detail > you say.. "A perfomant desktop..." > [15:58] We can meet both with sensible arguments, just needs to be > thought through > [15:59] jensreu: so I would rephrase 3rd detail completely... just > not sure how > [16:01] bshah: would "performant user interface" work better? > [16:01] depends on if we consider Plasma technology or user > interface.. > [16:01] sebas: yeah true, should we soften the "professional" bit? > [16:02] yes, please try (not sure it'll work, but I'm curious what > you can come up with) > > > On Monday, 4 April 2016 15:45:30 CEST Jens Reuterberg wrote: > > Hey, so me and Thomas have been hard at work on this for a while now and I > > think we are at a good point to show what we got. > > > > Please remember that THIS IS JUST A DRAFT! Nothing is set in stone even if > > the document looks fancy (the PNG attached to this email) > > Below is the raw text of it. > > > > /Jens > > > > The Vision is split into three subsections: > > Vision, Details and and three key points. > > The actual Vision: > > Plasma is created to be the primary user interface for multiple device > > classes providing a stable, performant, usable and above all productive > > environment for professional computer users. > > Plasma's feature set is selected for its usefulness in a productive > > context > > with a constant care to user privacy. > > > > Detail 1: Plasma not only promises to never invade its users' privacy > > itself, but also protect against other parties' attempts to spy on them. > > Security is a precondition to privacy, all privacy measures are useless in > > an insecure system. > > Detail 2: Our target audience works with their devices in a professional > > setting. Productivity is key for them and their user interface must give > > them an efficient and swift way of completing tasks. > > Detail 3: A perfomant desktop is the base of any productive environment > > and > > code quality, usability and aesthetic value are relevant to the > > experience. > > Nothing in the interface exists on its own merits but for what it brings > > to > > the user. > > > > The Three Key points: > > Private, Professional, Performant. > > ___ > 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
Re: A Plasma Vision draft
Ok so some good criticism from IRC that I thought I should document here for posterity: [15:57] - criticism: "Plasma is not good enough for professional use" [15:58] - people complaining "but this is supposed to be a just for fun thing, nothing serious! I hate you now!" [15:58] jensreu: point #3 : This is plasma vision and in 3rd detail you say.. "A perfomant desktop..." [15:58] We can meet both with sensible arguments, just needs to be thought through [15:59] jensreu: so I would rephrase 3rd detail completely... just not sure how [16:01] bshah: would "performant user interface" work better? [16:01] depends on if we consider Plasma technology or user interface.. [16:01] sebas: yeah true, should we soften the "professional" bit? [16:02] yes, please try (not sure it'll work, but I'm curious what you can come up with) On Monday, 4 April 2016 15:45:30 CEST Jens Reuterberg wrote: > Hey, so me and Thomas have been hard at work on this for a while now and I > think we are at a good point to show what we got. > > Please remember that THIS IS JUST A DRAFT! Nothing is set in stone even if > the document looks fancy (the PNG attached to this email) > Below is the raw text of it. > > /Jens > > The Vision is split into three subsections: > Vision, Details and and three key points. > The actual Vision: > Plasma is created to be the primary user interface for multiple device > classes providing a stable, performant, usable and above all productive > environment for professional computer users. > Plasma's feature set is selected for its usefulness in a productive context > with a constant care to user privacy. > > Detail 1: Plasma not only promises to never invade its users' privacy > itself, but also protect against other parties' attempts to spy on them. > Security is a precondition to privacy, all privacy measures are useless in > an insecure system. > Detail 2: Our target audience works with their devices in a professional > setting. Productivity is key for them and their user interface must give > them an efficient and swift way of completing tasks. > Detail 3: A perfomant desktop is the base of any productive environment and > code quality, usability and aesthetic value are relevant to the experience. > Nothing in the interface exists on its own merits but for what it brings to > the user. > > The Three Key points: > Private, Professional, Performant. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: A Plasma Vision draft
Thanks for feedback! :) > First, it looks very professional, nice :) > one thing tough , is the underline of the words, the red underline may look > like a spellcheck error (i'm wondering if something else could be used > instead of an underline, like bullets, those icons in small, or just a > background..) Yes now that you say it it does look like a spelling check going on :D Ok ok this calls for some experimentation. Will edit that But the text? What do you think about the text? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 127085: Make the desfault theme follow system colors
> On Feb. 16, 2016, 5:05 p.m., Kai Uwe Broulik wrote: > > File Attachment: color4.png - color4.png > > <https://git.reviewboard.kde.org/r/127085/#fcomment508> > > > > This is hard to read, perhaps the background contrast effect is still > > using light color? > > Marco Martin wrote: > yeah, it's not adjusting backgroundcontrast, that may need fixing somehow > and that's *also* why is not exactly the same color > > Jens Reuterberg wrote: > Note in general - as someone who dislike contrast at night - that is > essentially the same visual effect I use on my computer making it on the one > hand "hard to read" but on the other "calmer to read". Again, a user who > prefers this will have to take their options into consideration > > Andreas Kainz wrote: > i like the idea but I think it's to dangerous for set it by default. I > would add it in the kcm to the advonced settings. I disagree. Since the default is perfect the only effect it will have that will be negative is if the user plays around with colour themes too aggressively, in which case said user will be able to repair it easier. - Jens --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127085/#review92462 --- On Feb. 16, 2016, 12:28 p.m., Marco Martin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127085/ > --- > > (Updated Feb. 16, 2016, 12:28 p.m.) > > > Review request for Plasma and Jens Reuterberg. > > > Repository: plasma-framework > > > Description > --- > > this makes the default plasma theme follow system colors, there are still > "breeze light" and "breeze dark" themes that behave like the old two > > > Diffs > - > > src/desktoptheme/CMakeLists.txt 3087c17 > src/desktoptheme/breeze-light/CMakeLists.txt PRE-CREATION > src/desktoptheme/breeze-light/colors PRE-CREATION > src/desktoptheme/breeze-light/metadata.desktop PRE-CREATION > src/desktoptheme/breeze/CMakeLists.txt 2e28287 > src/desktoptheme/breeze/colors d701701 > > Diff: https://git.reviewboard.kde.org/r/127085/diff/ > > > Testing > --- > > > File Attachments > > > color1.png > > https://git.reviewboard.kde.org/media/uploaded/files/2016/02/16/24f7dc82-1d66-4052-bc6f-af4aab0f15df__color1.png > color2.png > > https://git.reviewboard.kde.org/media/uploaded/files/2016/02/16/93188d4f-242a-46ac-94a7-182ed600817b__color2.png > color3.png > > https://git.reviewboard.kde.org/media/uploaded/files/2016/02/16/5151b63c-476b-4ff3-a653-42bf8168836f__color3.png > color4.png > > https://git.reviewboard.kde.org/media/uploaded/files/2016/02/16/41febde6-795d-437c-b17e-ace92c84ea73__color4.png > > > Thanks, > > Marco Martin > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 127085: Make the desfault theme follow system colors
> On Feb. 16, 2016, 5:05 p.m., Kai Uwe Broulik wrote: > > File Attachment: color4.png - color4.png > > <https://git.reviewboard.kde.org/r/127085/#fcomment506> > > > > This is hard to read, perhaps the background contrast effect is still > > using light color? > > Marco Martin wrote: > yeah, it's not adjusting backgroundcontrast, that may need fixing somehow > and that's *also* why is not exactly the same color Note in general - as someone who dislike contrast at night - that is essentially the same visual effect I use on my computer making it on the one hand "hard to read" but on the other "calmer to read". Again, a user who prefers this will have to take their options into consideration - Jens --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127085/#review92462 --- On Feb. 16, 2016, 12:28 p.m., Marco Martin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127085/ > ------- > > (Updated Feb. 16, 2016, 12:28 p.m.) > > > Review request for Plasma and Jens Reuterberg. > > > Repository: plasma-framework > > > Description > --- > > this makes the default plasma theme follow system colors, there are still > "breeze light" and "breeze dark" themes that behave like the old two > > > Diffs > - > > src/desktoptheme/CMakeLists.txt 3087c17 > src/desktoptheme/breeze-light/CMakeLists.txt PRE-CREATION > src/desktoptheme/breeze-light/colors PRE-CREATION > src/desktoptheme/breeze-light/metadata.desktop PRE-CREATION > src/desktoptheme/breeze/CMakeLists.txt 2e28287 > src/desktoptheme/breeze/colors d701701 > > Diff: https://git.reviewboard.kde.org/r/127085/diff/ > > > Testing > --- > > > File Attachments > > > color1.png > > https://git.reviewboard.kde.org/media/uploaded/files/2016/02/16/24f7dc82-1d66-4052-bc6f-af4aab0f15df__color1.png > color2.png > > https://git.reviewboard.kde.org/media/uploaded/files/2016/02/16/93188d4f-242a-46ac-94a7-182ed600817b__color2.png > color3.png > > https://git.reviewboard.kde.org/media/uploaded/files/2016/02/16/5151b63c-476b-4ff3-a653-42bf8168836f__color3.png > color4.png > > https://git.reviewboard.kde.org/media/uploaded/files/2016/02/16/41febde6-795d-437c-b17e-ace92c84ea73__color4.png > > > Thanks, > > Marco Martin > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 127085: Make the desfault theme follow system colors
> On Feb. 16, 2016, 12:09 p.m., David Edmundson wrote: > > Breeze theme version needs bumping as you need the cache to clear. > > > > Are you planning on migrating existing users onto breeze-light? > > Marco Martin wrote: > hmm no, I wanted to have existing users to the new one, if they don't > have weird color schemes they don't notice, otherwise they'll find the whole > desktop on the same color scheme, that i think makes sense (they can still go > back to breeze light) > > If the vdg thinks that it's not an unacceptable default change, we can do > a kconfupdate script > > Andreas Kainz wrote: > how does the monochrome system tray icons look like cause they use also > the colors from system color? > > Marco Martin wrote: > yes, like the k menu > > Andreas Kainz wrote: > Is it possible to 1. change the behavior and 2. do the kde applications > (e.g. dolphin) use also colored monochrome icons? > > Marco Martin wrote: > neither of those, sorry > > Andreas Kainz wrote: > It look like a biger change so how can I test your review? > > Marco Martin wrote: > i want in the long run have qwidget applications to be able to use > colored icons, and thoise are all bady steps for it. > but as you know for qwidget applicatons is all a problem 10 times as hard > > Andreas Kainz wrote: > would it be possible to change also the color of some application > elements like menu, toolbar, ... like you see it here > https://dl.dropboxusercontent.com/u/1642456/VDG/KF5/photo59126345614076845.jpg > Alex from the VDG make it and it would be awesome to integrate something > like "material stuff" in the KCM UI and as you do some stuff here, ... You > know VDG has nice ideas but is always searching for some dev. > > Marco Martin wrote: > that is unrelated.. it would be a change for the Breeze c++ theme and yes > i guess it's possible. > opinion/help of Hugo would be the best for that. The issue here is that this hands over a large amount of power to the user, if she sets a colour theme that will make some icons tricky to see - then that is what will happen. This doesn't stop us from releasing a "hardcoded" plasma theme - just like the "old Plasma 5.4 theme" still available. The idea here is that IF a user want to swap around color themes, make one herself - then she is most probably capable of looking for the effects of that. - Jens --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127085/#review92431 --- On Feb. 16, 2016, 12:28 p.m., Marco Martin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127085/ > --- > > (Updated Feb. 16, 2016, 12:28 p.m.) > > > Review request for Plasma and Jens Reuterberg. > > > Repository: plasma-framework > > > Description > --- > > this makes the default plasma theme follow system colors, there are still > "breeze light" and "breeze dark" themes that behave like the old two > > > Diffs > - > > src/desktoptheme/CMakeLists.txt 3087c17 > src/desktoptheme/breeze-light/CMakeLists.txt PRE-CREATION > src/desktoptheme/breeze-light/colors PRE-CREATION > src/desktoptheme/breeze-light/metadata.desktop PRE-CREATION > src/desktoptheme/breeze/CMakeLists.txt 2e28287 > src/desktoptheme/breeze/colors d701701 > > Diff: https://git.reviewboard.kde.org/r/127085/diff/ > > > Testing > --- > > > File Attachments > > > color1.png > > https://git.reviewboard.kde.org/media/uploaded/files/2016/02/16/24f7dc82-1d66-4052-bc6f-af4aab0f15df__color1.png > color2.png > > https://git.reviewboard.kde.org/media/uploaded/files/2016/02/16/93188d4f-242a-46ac-94a7-182ed600817b__color2.png > color3.png > > https://git.reviewboard.kde.org/media/uploaded/files/2016/02/16/5151b63c-476b-4ff3-a653-42bf8168836f__color3.png > color4.png > > https://git.reviewboard.kde.org/media/uploaded/files/2016/02/16/41febde6-795d-437c-b17e-ace92c84ea73__color4.png > > > Thanks, > > Marco Martin > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: RFC: plasma logo as start menu icon and ksplash logo
As the one responsible for the logo work (since Uri who made that and other bits is in the VDG) I should probably shime in here. The three dots and the arrow is simply because of the connections to the K logo. The reasoning for it is to make it flexible (do note that we came in blind into this, so creating something for the future, when the future wasn't clear was simply a bit tricky) What that means is that it needs to be distinguishable from the K logo (since that was one of the brief points we where given: "Plasma != KDE" while still being reminiscent of that). Also it needs to be so simplistic and "empty" as it possibly can to be able to be filled with meaning at a later point depending on needs. It has to be recognizable so it had to be unique enough that you could take parts and shapes of it and reuse them while still being easily connected to Plasma. The arrow and the three dots where in my professional opinion the best choice as a good mix between "recognizable while still being abstract", "looking sorta like the K but not so it connects up to the K" and "flexible" What IS relevant though is that since our brand presence isn't all that grand (web presence is still stuck on KDE 4.x fortt example) the usage of it simply isn't there yet and the possability to push it out isn't as much available. So what I think is: We should push for that logo more, instead of slapping together something new... again... still following that brief (OR we get people to give us a NEW brief). We do need to be pushier and change our webpresence quicker, be more aggressive in our communication etc. Also "New challenge: Show off the flexibility of the Plasma logo and use it in a way that Dirk will like and fall in love with it" - Challenge accepted. :) On Wednesday, 3 February 2016 09:10:06 CET Dirk Hohndel wrote: > On Wed, Feb 03, 2016 at 05:48:40PM +0100, Marco Martin wrote: > > On Wednesday 03 February 2016 16:24:10 David Edmundson wrote: > > > If you mean this one? > > > https://dot.kde.org/sites/dot.kde.org/files/plasma-mobile-logo.png > > > Sure. > > > > > > Anything more radical I'm against as it breaks not only our current > > > branding, but all screenshot based tutorials. > > > > the current one is more like > > http://4.bp.blogspot.com/-jwBzU1YZWLI/U8U2E1nDM8I/mfY/jDbBMq9GkP4/ > > s1600/plasma-5-banner.png > As someone with a more "outside" perspective... boy that one is ugly. And > really doesn't provide a lot of "recognizability". I'm running Plasma on > ArchLinux and I see the "K in the gear" logo in the bottom left corner of > my screen; replacing this with the three different sized, oddly spaced > dots and the '>' symbol? Doesn't sound like an improvement in branding to > me. > > And if I go to https://www.kde.org/workspaces/plasmadesktop/ I don't see a > consistent brand identity at all. The logo you mention here isn't even on > that site. > > My 2¢ would be to come up with a strong logo that is simple and provides a > good connection to Plasma as a brand and then use that consistently > everywhere. But you first need the artwork. > > /D > ___ > 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
Re: Review Request 126632: add a "Complementary" color scheme to kcolorscheme
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126632/#review90998 --- If I could take this, steal it away on a summer cruise, propose, marry and have ten kids with it I would. (I had no idea this was in the pipes but from a design perspective this makes PERFECT sense) VDG approves - Jens Reuterberg On Jan. 5, 2016, 11:16 a.m., Marco Martin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126632/ > --- > > (Updated Jan. 5, 2016, 11:16 a.m.) > > > Review request for KDE Frameworks and Plasma. > > > Repository: kconfigwidgets > > > Description > --- > > Since some releases, plasma-frameworks locally expands kcolorscheme to have a > new "Complementary" section: this is done for things like the lockscreen and > the logout ui, where the colors are flipped from the current theme. > A local extension there is kinda unfortunate as makes the color configs files > not completely compatible, and I think there is an use case for this in > normal applications as well (Gwenview switches to a dark palette when in > fullscreen mode for instance) > Since I want to make the default plasma theme follow the system color scheme, > I would need for it to support this "complementary" area as well. > > > Diffs > - > > src/kcolorscheme.h 22bc21b > src/kcolorscheme.cpp 427ffa4 > > Diff: https://git.reviewboard.kde.org/r/126632/diff/ > > > Testing > --- > > > Thanks, > > Marco Martin > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Noto fonts screw my system, please stop forcing fonts upon me!
Hello, concerning fonts - the choice of fonts is always a tricky call. Aside from an exact, and more feature complete version of Oxygen which sadly doesn't exist, Noto is the perfect choice for us. It's a very well made standardized font and the only other contender was the Firefox Fira IIRC and that had other issues (as in being to visually tied to Firefox and Mozilla where as Noto was not visibly connected to Google). As for the technical bits I can't reply because that is sadly not my forté, as for the visuals I am sorry that you experience these problems and as someone who doesn't experience them and can't duplicate them there is a large issue here from a visual design bug standard. But from a design perspective the work done on the Noto Font is top class meassured by any metric available and it also provides a good testing ground for the font as that font is present in a very very large chunk of places. You claim that it is unusable on larger screens except smaller form factors like mobiles can easily be argued by the very same reasoning why we picked a well liked, well made and standard sans font like Noto in the first place. It exists on many many machines. I realize this isn't the answer but as you are well aware we give every single option possible from our POV to the end user via distros to change the font, to edit it out. The size is negligent by modern standards, the choice available and the choice of Noto as a standard font is a well founded one without any clear alternatives that cover as many different symbols and alphabetical variants as that. We haven't forced anything down anyones throat. Now many of the more technically adept people have fairly replied, repeating the fact that from a technical standpoint no one is forcing you to use anything. But that again is their debate with you, not mine. Since no better alternatives are presented (if you know a font that is seeing more active upkeep, with as good a spread or better and with more suitability as a standard font - this is your time to speak up), the choice of Noto was a necessity and one made carefully with plenty of deliberation, then I consider this from a VDG standpoint, a closed subject. On Friday, December 18, 2015 12:42:50 AM Mark Gaiser wrote: > On Fri, Dec 18, 2015 at 12:00 AM, Kai Uwe Broulik > > wrote: > > Hi, > > > > > It is a very hard forced dependency on that font. > > > > I'll send you a bigger hard drive for Christmas as you constantly complain > > about a few megs of dependencies without any runtime overhead. I'm glad > > that we enforce some rules on fonts in Plasma 5 as in the 4.x times it was > > usually just embarrassing. > > I consider that to be one of the biggest issues in plasma. > > > > and i'm not going to make bug reports about that. > > > > So don't expect anybody to fix your issues. > > If i report font issues, nobody is looking at them anyway. See [1] for > oxygen. > Besides, this is a google font so i would have to report it against their > bug tracker (github in this case i guess?). But what if the thing i want to > report is not a bug at all? To mee, it just looks that way because it has > too much line spacing. But the font just seems to be that way so the font > itself is probably not the problem here. Just using it as desktop font is > the problem and _that_ is where plasma comes in. > > > > It is the google font (noto) with the google browser (chromium) that > > > > mainly screws things up completely. > > > > So what? > > If THAT combination isn't tested by google, then perhaps that combination > is not meant to used at all. > > > > Either case should be sufficient reason to not use it in Plasma 5. > > > > To be honest, I still use Oxygen as I couldn't be bothered to change my > > settings. Anyway line height looks okay'ish - if you really display that > > much continuous text anywhere that this matters, except an editor or help, > > you probably did something wrong. > > Please join the discussion when you know what you're talking about. > It was visible on every web page. Even on gmail itself. > > I'm not going to send you a screenshot. Just install the font and run > chromium. At first you will instantly notice the fonts looking weirdly > different with more space around them. Then you start noticing layout > breakage. Then you start wondering: "hmm, what screwed my system up this > time".. two days later you will figure out it's a font installed by plasma. > > > Cheers, > > Kai Uwe > > > > > > > > ___ > > Plasma-devel mailing list > > Plasma-devel@kde.org > > https://mail.kde.org/mailman/listinfo/plasma-devel > > [1] https://bugs.kde.org/show_bug.cgi?id=332059 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Noto fonts screw my system, please stop forcing fonts upon me!
Hello, concerning fonts - the choice of fonts is always a tricky call. Aside from an exact, and more feature complete version of Oxygen which sadly doesn't exist, Noto is the perfect choice for us. It's a very well made standardized font and the only other contender was the Firefox Fira IIRC and that had other issues (as in being to visually tied to Firefox and Mozilla where as Noto was not visibly connected to Google). As for the technical bits I can't reply because that is sadly not my forté, as for the visuals I am sorry that you experience these problems and as someone who doesn't experience them and can't duplicate them there is a large issue here from a visual design bug standard. But from a design perspective the work done on the Noto Font is top class meassured by any metric available and it also provides a good testing ground for the font as that font is present in a very very large chunk of places. You claim that it is unusable on larger screens except smaller form factors like mobiles can easily be argued by the very same reasoning why we picked a well liked, well made and standard sans font like Noto in the first place. It exists on many many machines. I realize this isn't the answer but as you are well aware we give every single option possible from our POV to the end user via distros to change the font, to edit it out. The size is negligent by modern standards, the choice available and the choice of Noto as a standard font is a well founded one without any clear alternatives that cover as many different symbols and alphabetical variants as that. We haven't forced anything down anyones throat. Now many of the more technically adept people have fairly replied, repeating the fact that from a technical standpoint no one is forcing you to use anything. But that again is their debate with you, not mine. Since no better alternatives are presented (if you know a font that is seeing more active upkeep, with as good a spread or better and with more suitability as a standard font - this is your time to speak up), the choice of Noto was a necessity and one made carefully with plenty of deliberation, then I consider this from a VDG standpoint, a closed subject. On Friday, December 18, 2015 01:34:24 AM Mark Gaiser wrote: > On Fri, Dec 18, 2015 at 1:24 AM, Eike Hein wrote: > > On 12/18/2015 12:31 AM, Mark Gaiser wrote: > > > You will hear me when my workflow is severely interrupted and when i > > > find the cause of it. > > > > plasma-devel@kde.org is not mark-gaisers-workf...@kde.org. > > > > Bug reports go to bugs.kde.org. User support happens on the > > user list and in the KDE Forums. > > > > > Sorry, but that is just a bogus argument for the sake of arguing. > > > It's very obvious and expected that a sample of a specific font is meant > > > to represent how the font looks when installed. > > > > Ah c'mon. Take a look at the glyph data with FontForge and then get > > out a ruler and check the SVG again. I don't have time to prove to > > you the SVG isn't equivalent to Qt and CSS line height defaults. > > Ohh just stop it! > You're going into technical implementation details of a specification (SVG > in this case). > > The noto font is on the google site. It has examples of how it looks and > you as a user can expect it to look like that. > I see the same line height freakyness in their examples as on my computer > and i don't like it. > > That's it, end of discussion. > > > Here's Google Chrome overlaid over the SVG though, re default > > intra-glyph and intra-line spacing: > > > > http://i.imgur.com/FlnxgGp.png > > > > http://i.imgur.com/6d0sBup.png > > > > Did you even check this stuff or is it OK if it's my time ...? > > > > > And there i see too much spacing between the lines. > > > > I don't, and I know this stuff pretty well. > > > > > There it's somewhat fine, but that isn't the default! And that can't be > > > influenced as user of the font. > > > > It's the default. > > > > Then your default differs from mine. > > And i didn't change font settings at all! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Minutes Monday Plasma Hangout
On Monday, August 17, 2015 05:12:00 AM Jeremy Whiting wrote: > On Mon, Aug 17, 2015 at 4:42 AM, Sebastian Kügler wrote: > > Present: Bhushan, David, Jens, Kai Uwe, Martin G, Ozark, Sebastian > > Date: 17 August, 2015 > > > > Bhushan: > > - working on apps, first off comic book reader > > - Looked into Plasma Moible on Archlinux: > > https://github.com/bhush9/plasma-arch > > > > David: > > - fixed some shoddy porting > > - Fixed translations > > - Fixed a bug in KScreen > > - 5.4 looks pretty good, probably not a log of real bugs (or too little > > testing!) > > - will fix davetray after 5.4 is out > > > > > > Jens: > > - visited GUADEC, GNOME struggles with many of the same problems as KDE > > does > Which problems are you referring to specifically? For those of us that > weren't at GUADEC and are curious. Well they have similar issues as us when it comes to things like dev-bleeding, how to attract new people, retain people who are here, how to minimize the threshold to get into KDE/GNOME and in general make our communities more pleasant places to be in, work in and be part of. That issue balloons into things like "What technical methods do we employ to make contributing code easier" and things like "How to make sure our community remain visible" and to "How to make sure the community remains independent from companies and sponsors". One proposal was to see if the people in Gnome working on that issue (Sriram for example) could talk to people withing KDE who does the same thing (Like Lydia) to at least compare notes. Why do twice the work independently when we can help each other out. Other issues was how to make certain the drawbridge is down between the Gnome community and the KDE community. The fact that we know fairly little about each other in comparison how theoretically close we are (and practically close we could be) shows that we should see if we couldn't make that communication simpler (outside of bugreports that tend to go into slugfests). Just a shortlist of things... > > > Kai Uwe: > > - Fixes here and there > > - interfaces powerdevil with his ambient light sensor in a hackish way > > - tried Skeyer, gesture-based keyboard which comes with a maliit plugin > > > > [1] https://saidinesh5.wordpress.com/2014/05/20/on-the-way-to-skeyer/ > > [2] https://bitbucket.org/skeyer/skeyer/ > > > > Martin: > > - Working on KWin QPA progressing well > > - now working on input devices > > - looking into "the OpenGL story" right now > > > > Sebas: > > - Worked on KScreen/Wayland wl protocol for disconnected outputs w/ Martin > > - Discussed merge plans with dvratil (either wayland-integration or > > libkscreen) > > - Finalized Plasma Mobile vision > > - Worked a lot on docs for Plasma Mobile (see wiki) > > - will do more docs > > - more phabricator (task workflow basics are there, migrate more, then > > move on to code reviews) > > - interview this afternoon > > - finalize > > > > > > -- > > 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 > > ___ > 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
Re: Plasma Interface Guidelines
Perhaps link to the toolkit in the HIG? Den 23 aug 2015 10:34 fm skrev Alex Merry : > > Techbase has a page titled "Plasma Interface Guidelines"[0]. Leaving > aside the unfortunate acronym, this page is sparsely populated and last > edited in 2012. It is also linked from the development guidelines > page[1]. > > Could someone have a look and decide what to do with that page, please? > If it's no longer useful, it should at least be removed from the > guidelines page. > > Thanks > > Alex > > [0]: https://techbase.kde.org/Projects/Plasma/PIG > [1]: https://techbase.kde.org/Development/Guidelines > ___ > 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
Re: Desktop Theme Details KCM
On Friday, August 21, 2015 09:13:11 PM Andrew Lake wrote: > My own opinion, having written the original code, is that we should simply > remove it altogether. I consider it an extreme corner case for > customization that, at best, belongs in a Plasma theme creation tool, not > system settings. > > Andrew I agree but, with the caveat that we really should look into some way to get work on a theme creator tool underfoot somehow (I have no idea what the most sensible way to do that would be) > > On Fri, Aug 21, 2015, 1:40 PM Kai Uwe Broulik wrote: > > Hi all, > > > > I was just looking at the Desktop Theme Details KCM (System Settings → > > Workspace Design → Details) and figured it's of not much use anymore. Imho > > the > > way the interaction with it worked wasn't particularly good to begin with, > > suddenly creating a "(Custom)" theme when you edited another one, but the > > one > > you selected in the list above isn't neccessarily the theme you're using, > > etc. > > > > So, let's look at the options it offers: > > > > * Color Scheme: Kinda works but given it also influences the background > > contrast, conflicts with the dialog/panel backgrounds > > * Panel background: Doesn't always work (panel stays the same somtimes) > > * Kickoff: No effect? What should it change anyway, it's up to the applet > > (it > > changes dialogs/kickoff, if that is even used anymore..) > > * Task items: Completely screws up the task manager if I touch that > > * Widget background: Seems okay > > * Translucent background: also okay > > * Dialog background: doesn't do anything > > * Analog Clock: works, seems kinda valid usecase; though all other DEs > > I've > > seen just provide that in the clock itself > > * Sticky Notes: Dunno, should work, but then I haven't seen a theme with > > different sticky notes - we still use the Oxygen ones even now :) One > > thing I > > would like to see is a default color for the notes, so a dark theme can > > have > > black notes by default > > * Tooltip: doesn't do anything > > * Pager: seems to work > > * Run dialog: Given KRunner is a regular dialog nowadays doesn't do > > anything > > * Logout dialog: Provided by LNF theme anyway > > * Icons: Kinda works, mostly seems to affect only system tray, as most > > icons > > are provided by the overall icon theme > > > > What should we do with this thing? > > > > PS: Air and even more Oxygen Plasma theme are pretty broken, we should > > either > > fix them (especially task manager, potentially revert the follow theme > > color > > stuff to provide a more 4.x-esque look) or kill them. > > ___ > > 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
Re: Minutes Monday Plasma Hangout
On Monday, August 17, 2015 05:12:00 AM Jeremy Whiting wrote: > On Mon, Aug 17, 2015 at 4:42 AM, Sebastian Kügler wrote: > > Present: Bhushan, David, Jens, Kai Uwe, Martin G, Ozark, Sebastian > > Date: 17 August, 2015 > > > > Bhushan: > > - working on apps, first off comic book reader > > - Looked into Plasma Moible on Archlinux: > > https://github.com/bhush9/plasma-arch > > > > David: > > - fixed some shoddy porting > > - Fixed translations > > - Fixed a bug in KScreen > > - 5.4 looks pretty good, probably not a log of real bugs (or too little > > testing!) > > - will fix davetray after 5.4 is out > > > > > > Jens: > > - visited GUADEC, GNOME struggles with many of the same problems as KDE > > does > Which problems are you referring to specifically? For those of us that > weren't at GUADEC and are curious. Well they have similar issues as us when it comes to things like dev-bleeding, how to attract new people, retain people who are here, how to minimize the threshold to get into KDE/GNOME and in general make our communities more pleasant places to be in, work in and be part of. That issue balloons into things like "What technical methods do we employ to make contributing code easier" and things like "How to make sure our community remain visible" and to "How to make sure the community remains independent from companies and sponsors". One proposal was to see if the people in Gnome working on that issue (Sriram for example) could talk to people withing KDE who does the same thing (Like Lydia) to at least compare notes. Why do twice the work independently when we can help each other out. Other issues was how to make certain the drawbridge is down between the Gnome community and the KDE community. The fact that we know fairly little about each other in comparison how theoretically close we are (and practically close we could be) shows that we should see if we couldn't make that communication simpler (outside of bugreports that tend to go into slugfests). Just a shortlist of things... > > > Kai Uwe: > > - Fixes here and there > > - interfaces powerdevil with his ambient light sensor in a hackish way > > - tried Skeyer, gesture-based keyboard which comes with a maliit plugin > > > > [1] https://saidinesh5.wordpress.com/2014/05/20/on-the-way-to-skeyer/ > > [2] https://bitbucket.org/skeyer/skeyer/ > > > > Martin: > > - Working on KWin QPA progressing well > > - now working on input devices > > - looking into "the OpenGL story" right now > > > > Sebas: > > - Worked on KScreen/Wayland wl protocol for disconnected outputs w/ Martin > > - Discussed merge plans with dvratil (either wayland-integration or > > libkscreen) > > - Finalized Plasma Mobile vision > > - Worked a lot on docs for Plasma Mobile (see wiki) > > - will do more docs > > - more phabricator (task workflow basics are there, migrate more, then > > move on to code reviews) > > - interview this afternoon > > - finalize > > > > > > -- > > 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 > > ___ > 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
Plasma Mobile Vision, intended personas & meeting notes
PRESENT: Ivan, Sebas, Thomas and Jens MEETING GOAL: write up a vision statement for Plasma Mobile and talk about the early work of the Plasma Mobile HIG and design goals. The vision we ended with, after much debate of different wordings, what should and shouldn't be included in a vision statement was VISION STATEMENT: "Plasma Mobile aims to become a complete software system for mobile devices. It is designed to give privacy-aware users back the full-control over their information and communication. Plasma Mobile takes a pragmatic approach and is inclusive to 3rd party software, allowing the user to choose which applications and services to use. It provides a seamless experience across multiple devices. Plasma Mobile implements open standards, and -- unlike Android -- it is developed in a transparent process that is open for the community to participate in." NOTES ON VISION STATEMENT: We wanted the vision statement to reflect not the projects current position but our future goals in full. A system for actual users with a focus on privacy, control of information and your own system and working in the open as a community using open source. We also included information about our pragmatism and how the phone intends to be easily adaptable to different apps from other eco-systems and also our intent to make it a pairing with desktops. PERSONAS: We also talked about future Personas that we want to work towards when creating user stories and scenarios and settled fairly quickly on Berna (the office worker) and Susan (the recreational user). (1) DESIGN NOTES: Further notes of interest during the meeting where a few bullet points concerning future design goals for individual apps which will reach the HIG in the end 1) All applications should be private by default - no sending data in the default configuration, must not phone home 2) Applications should try to include security and control of info. Should be apparent not hidden. This is not an excuse for geeky "design". 3) Applications should always aim for integration between devices, for example using kdeconnect FUTURE COMMUNICATION: We also brainstormed on communication taglines for the project that will be narrowed down further as time goes by (and should probably be a case for the KDE Promo team) - centering mostly on user self control over his or her information and communication but also communication ideas concerning pragmatism. "Pragmatic to the bone" "Think Similar" "This is your phone, no one elses" "Plasma's Satellite" "Your phone. Your stuff. Your Plasma Mobile." "Plasma Mobile. Yours." "Yours" "For your eyes only." "Yours truly." All in all a very productive meeting. - 1) https://techbase.kde.org/Projects/Usability/Principles/KDE4_Personas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124589: Add Disk Quota Plasmoid
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124589/#review83345 --- Awesome! From a visual perspective two things, the line width of the icon when in systray is kinda off it seems in the screenshots (the line is thinner in the other icons, 1px I think) and the icon itself is too big taking over a large chunk of the intended padding. Maybe those are connected? I'll ping Uri and double check - Jens Reuterberg On Aug. 2, 2015, 2:06 p.m., Dominik Haumann wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124589/ > --- > > (Updated Aug. 2, 2015, 2:06 p.m.) > > > Review request for Plasma, Kai Uwe Broulik and Sebastian Kügler. > > > Repository: kdeplasma-addons > > > Description > --- > > The disk quota is usually used in enterprise installations where network > shares are mounted locally. Typically, sysadmins want to avoid that users > copy lots of data into their folders, and therefor set quotas (the quota > limit has nothing to do with the physical size of a partition). Typically, > once a user gets over the hard limit of the quota, the account is blocked and > the user cannot login anymore. This happens from time to time, since the > users are not really aware of the current quota limit and the already used > disk space. > > Here is where the "Disk Quota" plasmoid helps: It continusouly monitors the > disk quota and warns the quota apprpriately. > > A detailed description including screenshots can be found in this blog: > http://kate-editor.org/?p=3591 > > (I had a KDE4 hack of this plasmoid running at university, and it proved very > usable over the years, so it is probably a good idea to have it by default in > plasma) > > Issues: > - the panel icon is larger than the others (some wrong margin?) > - an icon for the metadata.desktop is missing (the shipped quota.svg file is > not available here, it seems). > - the grid units probably need some more tuning > > > Diffs > - > > applets/CMakeLists.txt c60c350 > applets/diskquota/CMakeLists.txt PRE-CREATION > applets/diskquota/Messages.sh PRE-CREATION > applets/diskquota/icons/quota.svg PRE-CREATION > applets/diskquota/package/contents/ui/ListDelegateItem.qml PRE-CREATION > applets/diskquota/package/contents/ui/main.qml PRE-CREATION > applets/diskquota/package/metadata.desktop PRE-CREATION > applets/diskquota/plugin/DiskQuota.h PRE-CREATION > applets/diskquota/plugin/DiskQuota.cpp PRE-CREATION > applets/diskquota/plugin/QuotaItem.h PRE-CREATION > applets/diskquota/plugin/QuotaItem.cpp PRE-CREATION > applets/diskquota/plugin/QuotaListModel.h PRE-CREATION > applets/diskquota/plugin/QuotaListModel.cpp PRE-CREATION > applets/diskquota/plugin/plugin.h PRE-CREATION > applets/diskquota/plugin/plugin.cpp PRE-CREATION > applets/diskquota/plugin/qmldir PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/124589/diff/ > > > Testing > --- > > Tested combinations: > - no quota installed: A nice message is displayed telling the user that > 'quota' is missing. > - quota installed, but no quota restrictions set: The applet says "No quota > restrictions found" > - quota installed, quotas active: The applet continuously shows the data. The > quota entries are in a QAbstractItemModel derived class, so > inserting/removing quotas all works (tested). > - filelight installed: the item under mouse gets highlighted. If clicked, > filelight starts with the correct location. > > > Thanks, > > Dominik Haumann > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124409: Begin fading the OSD immediately
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124409/#review82734 --- Ship it! Ship It! - Jens Reuterberg On juli 20, 2015, 8:19 e.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124409/ > --- > > (Updated juli 20, 2015, 8:19 e.m.) > > > Review request for Plasma and KDE Usability. > > > Repository: plasma-workspace > > > Description > --- > > This makes the OSD begin fading out over a long period of time immediately > after it has shown. Makes the OSD less annoying while currently reading > something or watching a video. See https://www.youtube.com/watch?v=HxmpwG-2saE > > > Diffs > - > > lookandfeel/contents/osd/Osd.qml 2288ec1 > shell/osd.cpp 0573d51 > > Diff: https://git.reviewboard.kde.org/r/124409/diff/ > > > Testing > --- > > Works. Quite enjoyable. As suggested by mklapetek > > > Thanks, > > Kai Uwe Broulik > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Breeze] [Bug 347123] OSD is distracting and annoying
https://bugs.kde.org/show_bug.cgi?id=347123 Jens Reuterberg changed: What|Removed |Added CC||j...@ohyran.se --- Comment #11 from Jens Reuterberg --- Since it can be fixed by creating a Plasma theme without it it seems there is at least a short term solution. At the same time adding a new bit in System Settings seems frivolous and risk overcluttering, and since its not an ordinary widget it can't just use the "Alternatives" pop-up. On the other hand this is a good example of why a Plasma theme creator would be such a great thing. -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124149: Rework the notifications sizing code
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124149/#review81659 --- Ship it! Ship It! - Jens Reuterberg On June 22, 2015, 3:04 p.m., Martin Klapetek wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124149/ > --- > > (Updated June 22, 2015, 3:04 p.m.) > > > Review request for Plasma and Kai Uwe Broulik. > > > Bugs: 339588 and 349142 > https://bugs.kde.org/show_bug.cgi?id=339588 > https://bugs.kde.org/show_bug.cgi?id=349142 > > > Repository: plasma-workspace > > > Description > --- > > This reworks the notification sizing computation to use Layouts. This should > fix all the popup sizing issues there are (including a binding loop error). > > Now it also properly elides after max 4 lines of text. > > > Diffs > - > > applets/notifications/package/contents/ui/NotificationItem.qml 176ae91 > applets/notifications/package/contents/ui/NotificationPopup.qml e4e5fad > > Diff: https://git.reviewboard.kde.org/r/124149/diff/ > > > Testing > --- > > I've been running it for couple hours, all notifications have correct sizes, > see screenshot > > > File Attachments > > > Screenshot > > https://git.reviewboard.kde.org/media/uploaded/files/2015/06/22/f4f7689c-2a95-46aa-8e51-e90d25d99bb2__notifications-layout.png > > > Thanks, > > Martin Klapetek > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Breeze] [Bug 349468] Colour of all 'Leave' options should correspond to selected theme
https://bugs.kde.org/show_bug.cgi?id=349468 Jens Reuterberg changed: What|Removed |Added CC||ohy...@gmail.com --- Comment #4 from Jens Reuterberg --- That's part of the theme and a conscious decision. Aside from moving OT about the importance of a simpler theme editor there really isn't much to add. -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Component chooser kcm
I think its a lot more complex - because in reality what is KDE? If KDE is ment to be a set of applications which also have a desktop available then the applications should be able to set preferred browser or if nothing else pick up what browser is preferred by the desktop (unless stated elsewhere by a desktop with the possibility to pick per-app preferences) If we are a desktop which also provides a large set of applications then we can safely assume that this is entirely up to the desktop in question. We could argue that its not our fault that other DE's are so hopelessly outdated but that wouldn't gain us anything. Is there something that stops us from letting Konsole check what the preferred browser is in whatever DE is available? Or is it that they simply don't tell what that is? On Monday 08 June 2015 11:58:47 David Edmundson wrote: > If it was a KDE specific thing, maybe there'd be an argument but this just > modifies standard fd.o local mimedb. > > Any reasonable desktop (Plasma, XFCE and probably Gnome) will provide a GUI > to change them. > If people choose to run a desktop that doesn't provide all the tools you > need, they deserve to edit the file by hand or you should choose a desktop > that does. > > David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma wallpapers
Well I'm no legal expert so neither can I. I just think that beyond some care to tell people not to break any local laws there isn't much we can do without making it a contest for "who can grasp international trademark law the best". Lets just roll with it for now. Perhaps tell people to check in with legal issues and that its GPL we're going with license wise and not stress out about to much at this early stage, On Thursday, March 12, 2015 02:00:23 PM Martin Klapetek wrote: > On Thu, Mar 12, 2015 at 1:53 PM, Jens Reuterberg wrote: > > Well just as a suggestion can't we post something like "please > > remember to check your local laws concerning official > > buildings and people" and then IF someone hands over an > > image of an official building then we can ask them. > > > > I mean there's no point burning the house down to protect it > > from burglars is there? > > It gets complicated with KDE's international distribution though, > one law not being valid in one country might be very valid in > another country. > > But then again, I don't understand it enough to make educated > claims, I'm just raising what I know as a photographer who > actually tried to license some of his photos to a company. > > Cheers ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma wallpapers
Well just as a suggestion can't we post something like "please remember to check your local laws concerning official buildings and people" and then IF someone hands over an image of an official building then we can ask them. I mean there's no point burning the house down to protect it from burglars is there? On Thursday, March 12, 2015 01:45:34 PM Martin Klapetek wrote: > On Thu, Mar 12, 2015 at 1:31 PM, Jonathan Riddell wrote: > > On Thu, Mar 12, 2015 at 01:20:35PM +0100, Martin Klapetek wrote: > > >However do you know how it is with property licenses when used as > > >backgrounds? > > > > It varies by country, sensible countries make sure that photos of > > public buildings are not restricted by copyright. Both the UK and the > > US are sensible countries in this regard. > > > > http://en.wikipedia.org/wiki/Freedom_of_panorama > > That is not true, for example Trafalgar Square or Parliament Square > in London that are not private tourist photos _must_ have a property > release before using it commercially. And there are many such buildings > or landmarks in US and everywhere else too. > > > >Same goes with children or any person on photos, > > >there you need "model release" (ie. the person's signature that > > > > his/her > > > > >photo > > >can be used for various purposes). > > > > Personality rights for people modelling is only a US concept, sensible > > countries have no such restrictions. > > That is also not true and it's more complicated. Basically, taking a picture > on the public space/street should be safe, but as soon as the person (and > especially children) are the main object of the photos, you do need to have > a license to use those in a non-private way. > > All I'm saying is, better stay safe (licensing Golden Gate Bridge for > non-private use is 2000$, getting sued could be very very very > expensive). > > Cheers ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: theme mixing
Well there was talk about some easy way to edit colors and spacing of individual SVG-files (I mean it IS reaaally complex to edit themes)... Might be worth looking into? Pedro: I can only suggest that you try to edit them in Karbon instead of Inkscape since it contains a better sorting of objects in files. (although saving it is a pest in Karbon) On Mon, 9 Feb, 2015 at 2:04 PM, Sebastian Kügler wrote: Hi Pedro, On Sunday, February 08, 2015 12:10:12 Pedro Rosado wrote: I don't know if this is the right place, but I wanted to suggest something. KDE is by far the most modern and efficient desktop I've came to know (not dissing all the others), but regarding customization it's falling a little behind. Compared to gnome-look org, KDE look feels abandoned and there aren't many themes available at all, most are not even online anymore (host site doesn't have the file anymore). Most themes work like a charm on plasma 5, it's not like gnome that breaks a theme everytime it's updated. So, could the kde development theme give end users a tool to combine or make their own themes with a user friendly interface? I've tried myself to make a kwin theme - only found despair and wasted time looking inside svg files (I'm an end user, not an IT guy :c ) Also, it would be nice to have all those themes shared if you want to, so that the whole community can use them. Instead of searching themes on the settings (that most times doesn't work because the files aren't hosted anymore at kde look.org), users could have this "customization" tool that allows users to search and create themes and share them into a repo or github so that anyone can find them and use them, independent of distro (as long as you are using kde) Summary: - Easy tool to make kwin and desktop themes for kde - Able to share and download the themes from the desktop app - kde kicks ass You can mix-and-match workspace themes in systemsettings, go to "Workspace Theme" -> "Desktop Theme" -> "Details". This allows you to combine elements from different themes convienently in the UI. If that doesn't allow you to do what you'd like to, it indeed comes down to managing SVG files and combining them into a new theme. You've already found that out, it's a bit fiddly, but so is anything advanced enough to satisfy the complex need for a complete theming system. As to the quality of kde-look.org, we cannot do much about it, since it's a community-run site, which doesn't receive much love in terms of maintainance and content curation, unfortunately. 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: RFC: Use Grid as default for KWin's Presnt windows effect
One idea could be to use the size differences and placement mean something. Say that I have five windows open, one that I use constantly and one that keep checking out every now and then - the placement that would make most sense then is to make sure that I as a user can quickest focus on the window most probably needed. So say its a grid sollution - the second most used window should be placed nearest to the mouse (under the mouse currents position so that whether the window grid was started with a keyboard shortcut or a screen edge it would have the same result). OR by size - where the largest is the second most used and then falling in size to the last used (thats the smallest) On Friday 09 January 2015 09.35.14 Andres Betts wrote: > Maybe another thing that could help in the case of having a ton of windows > is to actually have them all be presented and not shaded. So not making all > of them be dark and only lighten up the one where the cursor is over. > > Maybe in the VDG we could come up with some ideas. You could post it there > if you wanted extra input. > > -- > Andres Betts > > On January 9, 2015 at 9:32:55 AM, Martin Klapetek > (martin.klape...@gmail.com) wrote: > > On Fri, Jan 9, 2015 at 5:24 PM, Andres Betts > wrote: My only objection to that is that the grid will end up making the > each window generally smaller until it could be hard to know what window > represents what content. There are other methods that could be used for > that, like stacking similar windows close together, or having really good > typography to name each window. > > Well if you have /that/ many windows, I think neither setting for that > effect will be good enough :) But I tried with 16 windows on my 1920x1200 > and I can still make out very well what's what > --> http://paste.opensuse.org/images/4207e18f.png > > There are also still the text labels over the window, so if you cannot tell > a window by the thumb size, you can just read it (that imo works well). > > Cheers > -- > Martin Klapetek | KDE Developer > ___ > 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
Re: Plasma naming scheme
On Monday 05 January 2015 01:34:17 Aleix Pol wrote: > On Sat, Jan 3, 2015 at 6:23 PM, Thomas Pfeiffer wrote: > > Hi everyone, > > while writing up a vision for Plasma interaction, the VDG noticed that it > > was unclear exactly what terms to use when referring to Plasma Desktop > > specifically, so we thought it would make sense to clarify this. > > > > Therefore, we went ahead and drafted some communication guidelines I'd > > like to present for discussion: > > > > - When talking about the the Plasma technology generically, use only > > "Plasma", omitting the "5" as that is just an iteration of Plasma. > > > > > > - When talking about a particular version of the technology, but not a > > specific shell, use "Plasma [version]" e.g. "Plasma 5.1". > > > > - When talking about the a specific shell but not about a specific > > version, > > use "Plasma [shell], e.g. "Plasma Desktop" > > > > - When talking about a specific shell in a particular version, use > > "Plasma > > [version] [shell]" e.g. "Plasma 5.2 Desktop", "Plasma 5.4 Active" > > > > For example in release announcement we'd talk about the Plasma 5.2 release > > and when there are shell specific changes we could write "Plasma Desktop > > now has addition X" > > > > Does that make sense to everyone? And if so: Where should we publish it > > and > > where should we announce it? > > Well, it's still weird as Plasma is more than a technology. Also note > there's a Plasma framework. > > To me, the biggest problem with this is that you're just covering part > of it here, given that Plasma is not only the shell(s) but the entire > solution as well (kwin, system settings, some of the apps) or maybe > not. > > I've always missed something there, many people have tried to explain > it to me, maybe I'm a bit hard. > > Aleix > > PS: thanks for raising the issue, I keep failing to explain it > baltasar (kdeblog.com) or, well, we even fail to discuss Plasma in the > office, where we often end up saying "plasma? which plasma?" > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel What we need is a way to simply describe the desktop IN AN APPEALING way that still allows for version number should the need arise. One way is going the Mac route and name the desktop things. The tricky bit there is that considering the number of releases we have this may fast become a very long list of animals (or whatever it might be). We do have a massive communications issue - on the upshot "Plasma 5" is getting more and more foothold. Also sidenote, its "Maybe I'm a bit thick" not "hard" Aleix... ehm ... :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5.2 Kickoff meeting minutes
Martin is totally to blame I think. I remember, if it was a few days ago when it essentially was a large, communal "AHAAA" moment. Which is sort of the reason for DWD as a term for it. We need to communicate the relevant differences for the technical reasons behind not using CSD's but also that that doesn't stop us from using the windeco as a way to place objects. On Wednesday 22 October 2014 17.39.27 Martin Gräßlin wrote: > On Wednesday 22 October 2014 17:25:33 Christoph Feck wrote: > > On Wednesday 22 October 2014 16:37:26 Jonathan Riddell wrote: > > > -Jens announced "Dynamic Window Decoration", an idea of using > > > > > > server side decoations with widgets in the decoration mockup > > > http://starsky.19inch.net/~jr/tmp/ssd.png > > > > ... and mgraesslin didn't cringe? :) > > no, I'm very happy with this and I think I am at least partially to blame > that VDG started to look into it. > > Cheers > Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5.2 Kickoff meeting minutes
Oh you're thinking of Client Side Decorations, not DWD's. On Wednesday 22 October 2014 17.25.33 Christoph Feck wrote: > On Wednesday 22 October 2014 16:37:26 Jonathan Riddell wrote: > > -Jens announced "Dynamic Window Decoration", an idea of using > > > > server side decoations with widgets in the decoration mockup > > http://starsky.19inch.net/~jr/tmp/ssd.png > > ... and mgraesslin didn't cringe? :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wallpapers on lock screen
Sry for a late reply (sick and been sleeping) but the one Harald Sitter and I fiddled with during Akademy was kinda nice where it used a blurred version of your wallpaper. 1) It didn't reveal the nature of your wallpaper (we tested, extensively) 2) It creates the sensation of "fading to desktop" when unlocked. If it IS somehow a security issue I don't know but it was way cooler than having a random wallpaper set by default which made the login process from a lock screen feel jerky and out of phase. On Monday 13 October 2014 17.11.20 Marco Martin wrote: > On Monday 13 October 2014, Eike Hein wrote: > > Still, adding the functionality to pick up the current or a > > custom wallpaper is fine if done correctly, of course, but not > > as a default IMHO. > > instead of some automagic and default i was more thinking about some option > in the ordinary wallpaper settings "use this in the lockscreen" maybe > unchecked by default ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Moving kde:muon repository to kde/workspaces
[silently cheering you on!] On Thursday 02 October 2014 19.23.17 Aleix Pol wrote: > On Fri, Sep 26, 2014 at 4:44 PM, Aleix Pol wrote: > > Hi, > > I'd like to have it moved to get it released with the Plasma 5.2 release, > > so no rush. I think though it's a good match as I think KDE has had a need > > for offering resources that are not part of the actual release and also > > Muon could really use some visibility outside of the Kubuntu world. > > > > Since Muon adopted PackageKit and Appstream, the technology tie is no > > more, so we'll be able to consider it a part of the Plasma Workspace > > solutions. > > > > If there's no considerable objections, I'd like to request the repository > > move next week. > > > > Cheers! > > Aleix > > Since there hasn't been any complaints, I'll request the move. > > Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breeze dark theme white edge outlines
No objections just a massive thumbs up! On Wednesday 01 October 2014 16.21.03 Andrew Lake wrote: > For anyone using the breeze dark theme, I've been meaning for a while to > make some adjustments so that the edges aren't quite so pronounced and high > contrast. It looks this way because it's currently using the same svgs (and > edge highlights) from the normal breeze theme svgs. > > I have changes ready to push to reduce that high contrast edge outline, but > I wanted to check to see if there was anyone that was particularly wedded > to the those white outlines before I do. I'd do up a screen shot but just > imagine those bright white outlines turned all the way down. > > Holler if anyone has any objections. :-) > > Thanks, > Andrew ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5 RC
Well the point I'm going for that beyond a technical issue - communications wise it doesn't matter really. As long as whatever you say contains some indication that its the older version. As for the technical side of things - I can't comment. But from a communicative standpoint it really isn't that big a deal if its packaged correctly in communications. On Monday 07 July 2014 10.47.00 Jonathan Riddell wrote: > It's not good to rename stuff which has already been released. When > KDE branding all changed we still used the terms KDE 3 and KDE 4 to > talk about old releases, try to be a revisionist rarely works. > > Jonathan > > On Mon, Jul 07, 2014 at 11:44:32AM +0200, Jens Reuterberg wrote: > > Someone said "branding" so I appeared like a Bloody Mary figure in the > > mirror. > > > > Why not Plasma 4? Or "Plasma Past"? I mean in all honesty the issue isn't > > that big except from a communicative aspect (in which case "Plasma Past", > > "Former Plasma" etc are all good) or a technical aspect (in which case > > the 4.12.something or just Plasma 4 works) > > > > On Monday 07 July 2014 10.16.44 Jonathan Riddell wrote: > > > On Fri, Jul 04, 2014 at 10:36:00AM +0100, John Layt wrote: > > > > Co-installabilty of Plasma 4 and Plasma 5 with minimal work required > > > > by the distros is a must if we want to avoid the mess of KDE4. > > > > Already openSUSE has announced that you can't have both installed at > > > > once, which will force people to choose one or other, when what we > > > > really want is for them to be able to try Plasma 5 out while still > > > > being able to switch back to 4 if there are things that break their > > > > workflow. > > > > > > They won't be co-installable just as konsole won't be co-installable > > > with its kdelibs4 version, it's a new version of the same programme. > > > But the parts that are used by applications, libraries and runtime > > > parts need to be co-installable so kdelibs4 and kf5 applications can > > > be installed on the same system. > > > > > > Your e-mail also highlights a branding issue, now that we are calling > > > the new version of Plasma, Plasma 5 what do we call the old version. > > > I've been calling it Plasma 1 as that was the version number used and > > > it's not a good idea to be revisionist. > > > > > > Jonathan > > > ___ > > > 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 > > ___ > 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
Re: Plasma 5 RC
Someone said "branding" so I appeared like a Bloody Mary figure in the mirror. Why not Plasma 4? Or "Plasma Past"? I mean in all honesty the issue isn't that big except from a communicative aspect (in which case "Plasma Past", "Former Plasma" etc are all good) or a technical aspect (in which case the 4.12.something or just Plasma 4 works) On Monday 07 July 2014 10.16.44 Jonathan Riddell wrote: > On Fri, Jul 04, 2014 at 10:36:00AM +0100, John Layt wrote: > > Co-installabilty of Plasma 4 and Plasma 5 with minimal work required > > by the distros is a must if we want to avoid the mess of KDE4. > > Already openSUSE has announced that you can't have both installed at > > once, which will force people to choose one or other, when what we > > really want is for them to be able to try Plasma 5 out while still > > being able to switch back to 4 if there are things that break their > > workflow. > > They won't be co-installable just as konsole won't be co-installable > with its kdelibs4 version, it's a new version of the same programme. > But the parts that are used by applications, libraries and runtime > parts need to be co-installable so kdelibs4 and kf5 applications can > be installed on the same system. > > Your e-mail also highlights a branding issue, now that we are calling > the new version of Plasma, Plasma 5 what do we call the old version. > I've been calling it Plasma 1 as that was the version number used and > it's not a good idea to be revisionist. > > Jonathan > ___ > 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
Re: Background for login, splash, and lockscreen
(Im really really tired - please let me rephrase) Ok so you have the default blurred wallpaper for the login, based on the default wallpaper. But then you pick a new wallpaper, and instead of having it get blurred during login (which would make it really heavy and annoying) the wallpaper picker blurs at the time of choosing, saving it (and the default one) in some folder to be used as background for the login. When you pick a new wallpaper the picker deletes the current one and replaces it with the blurred image of your current choice. The PNG of the blurred wallpaper can even be smaller in resolution (to save on space I guess) since, using gaussian blur removes all detail anyway and the resolution becomes almost meaningless. (Granted I know close to nothing about the subject - just wondering why that wouldn't work) On Monday 23 June 2014 08.42.27 Jens Reuterberg wrote: > Ok so I have to ask (because my mum once told me as a child, slow people ask > a lot of questions - but only complete idiots don't) :) > > Place be nice. > > Wouldn't it be possible to have the wallpaper picker pick the login > wallpaper as well? I mean say I choose a wallpaper with a photo of a dog or > something - can't the wallpaper picker, blur it with gaussian blur at the > time of picking, saving it in a special folder and at the same time > deleting the past blurred wallpaper? > > So that when you log in you have your current wallpaper, blured as > background? > > /Jens > > On Sunday 22 June 2014 20.57.11 Martin Graesslin wrote: > > On Saturday 21 June 2014 16:18:10 Kai Uwe Broulik wrote: > > > Can't we just use QtGraphicalEffects and just blur (and/or desaturate > > > and/or darken) whatever picture the user has chosen? > > > > > > The overall performance of these is great (at least on Android which is > > > slow in any other QtQuick respect) but their instantiation takes ages, > > > so > > > might not be suitable for lockscreen which needs to start quickly or > > > splash which shouldn't unnecessarily delay startup. > > > > > > So, umm, while writing this I figured it's not that good of an idea as I > > > initially thought :-) > > > > so you suggest that on millions of devices we blur the window fullscreen > > every time the user logs in (lots of more important stuff to do) and locks > > the screen? Compared to preparing it once and just installing it? That > > sounds like a very bad memory-time tradeoff [1]. > > > > Cheers > > Martin > > > > [1] https://en.wikipedia.org/wiki/Time-memory_tradeoff > > ___ > 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
Re: Background for login, splash, and lockscreen
Ok so I have to ask (because my mum once told me as a child, slow people ask a lot of questions - but only complete idiots don't) :) Place be nice. Wouldn't it be possible to have the wallpaper picker pick the login wallpaper as well? I mean say I choose a wallpaper with a photo of a dog or something - can't the wallpaper picker, blur it with gaussian blur at the time of picking, saving it in a special folder and at the same time deleting the past blurred wallpaper? So that when you log in you have your current wallpaper, blured as background? /Jens On Sunday 22 June 2014 20.57.11 Martin Graesslin wrote: > On Saturday 21 June 2014 16:18:10 Kai Uwe Broulik wrote: > > Can't we just use QtGraphicalEffects and just blur (and/or desaturate > > and/or darken) whatever picture the user has chosen? > > > > The overall performance of these is great (at least on Android which is > > slow in any other QtQuick respect) but their instantiation takes ages, so > > might not be suitable for lockscreen which needs to start quickly or > > splash which shouldn't unnecessarily delay startup. > > > > So, umm, while writing this I figured it's not that good of an idea as I > > initially thought :-) > > so you suggest that on millions of devices we blur the window fullscreen > every time the user logs in (lots of more important stuff to do) and locks > the screen? Compared to preparing it once and just installing it? That > sounds like a very bad memory-time tradeoff [1]. > > Cheers > Martin > > [1] https://en.wikipedia.org/wiki/Time-memory_tradeoff ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ship with Aurorae and Qtcurve or not...
I guess I am sooo not the dude to say this as it's technical in nature but Aurorae theme is, as far as I recall, out as it has some issues speed wise (?) it was too taxing if I recall correctly (I'm sure I don't Martin G gave a handful of really good reasons why we shouldn't use it) But I have a question - would cutting down features in Qtcurve make sense? Or would that be more trouble than its worth in the end? I am interested to know whether that is even an option to essentially go in with a chainsaw and cut lumps off as they become superflous and then allow people to install Qtcurve in its entirety if they want? /Jens On Thursday 19 June 2014 14.20.06 Hugo Pereira Da Costa wrote: > On 06/17/2014 10:56 AM, Marco Martin wrote: > > On Thu, May 29, 2014 at 3:09 PM, Marco Martin > > > <mailto:notm...@gmail.com>> wrote: > > On Thursday 15 May 2014 11:39:00 Jens Reuterberg wrote: > > > Ok so after the feedback from the Beta Release an issue that we > > > > knew was > > > > > coming have happened. Visuals being the most easily accessible > > > > bit of > > > > > anything technical, people have reacted negatively to the lack > > > > of change. > > > > just to give a shot on every and single options, i gave a try to > > modifying > > oxygen in order to make it look like breeze (therefore sharing all > > the things > > that it does that are not related to painting, like drag the > > window from > > anywhere) > > this is the half done, half missing attempt (ignore the non > > changed elements) > > http://wstaw.org/m/2014/05/29/plasma-desktophP1414.png > > > > is pretty hacky, but *maybe* is possible to have in the end only a > > different > > stylehelper (and pixelmetrics/stylehints) > > so could be something worth exploring in the future > > > > Adding Hugo with a very due explanation of what it is: > > The Visual Design Group came up with an idea for a new design for a > > widget style in KDE. > > But of course a Qt widget style is an huge undertaking that will take > > a lot to do. > > Now, Oxygen is the sum of years of experience and fixes, (and also > > does a ton of things to make application behave well that are beside > > just "painting", not to mention the companion themes that integrate > > nicely gtk 2 and 3 apps) and would really be a shame to lose all those > > years of development and experience, so I was wondering how hard would > > be to adapt the Oxygen codebase to a new visual style (would be a new > > style, or perhaps hopefully something sharing a lot of code) > > > > in the link above, there is a screenshot of an attemptIi made to quick > > and dirty try to adapt some of the elements (is incomplete and only > > partial, but promising, seems that changing rounded radiuses and > > removing some gradients here and there gets pretty close) > > > > Hugo, do you think it would be a feasible thing? And would you be > > interested in it? (I was thinking about something like maintaining > > most of the style, and set apart an oxygenhelper(as is now) vs > > breezehelper for the different visual related things) > > > > Cheers, > > Marco Martin > > Hi Marco, others, > > Sorry for the delayed answer. > > First off, I unfortunately have very little time left since about half a > year to dedicate to KDE/Oxygen aside from bug fixing and it is likely > not going to improve. So that I would not be a reliable choice for > undertaking the development of a Breeze Qt4/Qt5/Gtk2/Gtk3 widget theme. > (though I could give an occasional hand to anyone volunteering). > > As for starting from Oxygen's code base, I think it is a good idea > indeed. Large amount of code could likely be reused quite unchanged: > animations, window grabbing, fancy splitters. They could even be moved > to a library, that Breeze would load. > (ok there is versionning, API freeze etc. involved, but no serious core > development) > > As for the styling, indeed rewriting the helper class is a possible > start. Also, current oxygen has basically one method for every > primitive/control/etc. So it should also be easy to just inherit from > it, and just re-implement these methods one after the other ... > > Still, that would not bring you Gtk2 and Gtk3, which is quite a serious > issue. > > For such things, QtCurve is indeed a good candidate, since as far as I > know it is the only widget theme around that im
Re: [RFC] Which icon to use for kwin's killer helper
> > Then just leave the bomb? We probably have more important issues than this. > No, we don't. It may seem really silly and tiny (I completely agree, I don't even understand why the icon is there - but as Martin said, every window has an icon). But these are the things that add up. If we don't look at the small stuff the big stuff will be borked. (I really want to use an example like the Royal Ship Wasa which when built was brilliant - only they added stuff, never looking at the small details and the effect it had on the whole which is why hundreds of years later it had to be fished out of the waters 500 meters away from where it first set sail (check it up on wikipedia for an awesome lesson in why top-down-management and lack of detail checking isn't a good thing) Now this is OT but I think it should be called out - the tiny details are as relevant. Of course it this strangles the entire work flow of Martin G that's another thing but it sounds like its something fairly easy to fix. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Icons for Paste Bin and Paste
Haha! That was AWESOME! ok okokok I wanna do that! On Thursday 22 May 2014 21.54.33 Marco Martin wrote: > what about the paperclip bended in cloud shape? > (admittely this attempt isn't that great, but maybe can be evolved a bit) > > On Thursday 22 May 2014, Jens wrote: > > I already tried it and it became just a lot of lines > > http://wstaw.org/m/2014/05/22/paste3.svg > > > > On Thursday 22 May 2014 21.25.31 Mark Gaiser wrote: > > > On Thu, May 22, 2014 at 9:07 PM, Jens wrote: > > > > http://wstaw.org/m/2014/05/22/paste2.svg > > > > > > > > mmh... > > > > > > Err, the paperclip isn't really working out with the black cloud. > > > > > > Here is my suggestion. I hope you can use it :) > > > 1. Don't draw the cloud as filled black. Only draw the cloud > > > > outline. > > > > > 2. Have the paperclip in black inside the cloud. Fully inside. > > > > > > Would that look better? > > > > > > > On Thursday 22 May 2014 20.19.13 Jens wrote: > > > >> Trying to get the paperclip thing to work but considering the > > > > size > > > > > >> it's hell making them look better than "perhaps a cloud with > > > > > > > > some > > > > > > > >> lines" :) Give a second more ok? > > > >> > > > >> On Thursday 22 May 2014 20.00.04 Ivan Čukić wrote: > > > >> > +1 for a paperclipped cloud > > > >> > > > > >> > On 22 May 2014 19:33, Thomas Pfeiffer > > > > > > > > > > > > > > > >> wrote: > > > >> > > On Thursday 22 May 2014 19:17:22 Jens wrote: > > > >> > > > Ah the issue that there are TWO pastebin, one good for > > > >> > > > >> images (of > > > >> > > > >> > > > all kinds, including the link above btw) as well as text and > > > > > > > > one > > > > > > > >> not > > > >> > > > >> > > > so good that is just for text > > > >> > > > > > > >> > > > Perhaps a paperclip instead of the image then? > > > >> > > > > > >> > > Oh, sorry, I was spewing nonsense. Of course the applet is > > > > for > > > > > >> both text > > > >> > > > >> > > and > > > >> > > images. I think the name is quite misleading because > > > > > > > > Pastebin > > > > > > > >> (the > > > >> > > > >> > > service) > > > >> > > supports only text. Maybe the name should change? > > > >> > > ___ > > > >> > > 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 > > > > > > > > ___ > > > > 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 > > > > ___ > > 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
Re: Icons for Paste Bin and Paste
Good call - Im trying to do the preview icon too now and thought "wth the thing with it ISNT that its a clipboard but more that its a cloud sollution" so I thought I should change it anyway... Give me an hour or two On Thursday 22 May 2014 10.36.29 Marco Martin wrote: > On Wednesday 21 May 2014 21:37:19 Jens Reuterberg wrote: > > http://wstaw.org/m/2014/05/21/pastebin.svg > > http://wstaw.org/m/2014/05/21/harddrive.svg > > > > So these two in sorta the style of fabian, do they work for now? Will do > > the plasmoid preview too > > is pastebin ok for being displayed very small too? > should be ok till around 16px, but would be pretty much the same thing as > klipper at that size.. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Icons for Paste Bin and Paste
Theres a short talk concerning file systems and icons on the forums btw that I think one of you devs should get into... http://forum.kde.org/viewtopic.php?f=285&t=121251 On Thursday 22 May 2014 10.33.10 Marco Martin wrote: > On Thursday 22 May 2014 09:58:07 Martin Klapetek wrote: > > On Wed, May 21, 2014 at 9:37 PM, Jens Reuterberg wrote: > > > http://wstaw.org/m/2014/05/21/pastebin.svg > > > http://wstaw.org/m/2014/05/21/harddrive.svg > > > > > > So these two in sorta the style of fabian, do they work for now? Will do > > > the > > > plasmoid preview too > > > > Harddrive is great, thanks! /me puts it into the theme > > should be drive.svgz, containing the id drive-harddisk ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Icons for Paste Bin and Paste
http://wstaw.org/m/2014/05/21/pastebin.svg http://wstaw.org/m/2014/05/21/harddrive.svg So these two in sorta the style of fabian, do they work for now? Will do the plasmoid preview too On Wednesday 21 May 2014 10.23.39 Jens Reuterberg wrote: > Ok I'm on it. Have some laundry to do but will get to "the office" after > lunch > On Wednesday 21 May 2014 10.20.03 Martin Klapetek wrote: > > Speaking of which - we do need one new systray icon for [1], the current > > oxygen one is "drive-harddisk". It shows up when you're running low on > > your > > disk space, so doesn't need to be a hard drive icon but something > > resembling that. > > > > [1] - https://git.reviewboard.kde.org/r/118205/file/1263/ > > > > > > Cheers > > ___ > 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
Re: Icons for Paste Bin and Paste
Marco if you have a list send it send it :) On Tuesday 20 May 2014 19.00.08 Marco Martin wrote: > On Tuesday 20 May 2014, Ivan Čukić wrote: > > The issue is a bit broader. > > > > 1. There are a few whose icons are overlapping (my favourite is an icon > > with an analogue clock on the digital clock applet :) ) > > hmm, if we provide a list of applets that have this problem, could the vdg > do icons for them? > > > 2. All applet icons are coloured. > > if the vdg thinks that the share applet should be monochrome in the UI, this > can be done: > * do an icon for it in the png icon theme, colored and all > * same name, monochrome and svg version in the plasma theme, so that would > be taken by the applet, but the colored icon would be in the widget > explorer. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Icons for Paste Bin and Paste
Ok I'm on it. Have some laundry to do but will get to "the office" after lunch On Wednesday 21 May 2014 10.20.03 Martin Klapetek wrote: > Speaking of which - we do need one new systray icon for [1], the current > oxygen one is "drive-harddisk". It shows up when you're running low on your > disk space, so doesn't need to be a hard drive icon but something > resembling that. > > [1] - https://git.reviewboard.kde.org/r/118205/file/1263/ > > > Cheers ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel