D8006: Add edit button to desktop theme

[Jens Reuterberg]

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

[Jens Reuterberg]

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

[Jens Reuterberg]

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

D7747: Added an extra fuzzytime setting - Hobbit Time

[Jens Reuterberg]

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 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

[Jens Reuterberg]

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

D7957: Turn on frames around dock widgets by default

[Jens Reuterberg]

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

[Jens Reuterberg]

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

[Jens Reuterberg]

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

[Jens Reuterberg]

https://bugs.kde.org/show_bug.cgi?id=384129

Jens Reuterberg <jens...@kolabnow.com> changed:

   What|Removed |Added

 CC|    |jens...@kolabnow.com

--- Comment #1 from Jens Reuterberg <jens...@kolabnow.com> ---
"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.

Re: Splash screen translation

[Jens]

[English Below for everyone]

Tjena,
Jag håller i viss mån med eftersom samma effekt blir gällande på Svenska: 
"Made By" på Svenska, "Gjord av", betyder ingenting. 
Samtidigt tycker jag att det är ett av dom klassiska problemen som dyker upp i 
översättningar i allmänhet. Vi antar att det finns nån form av 
tillgänglighetsprincip som gör att man automatiskt ska översätta och glömmer 
hur vanligt det Engelska (eller Franska) språket är. "Eau de Toilette" på 
Engelska eller Svenska, direktöversatt, exempelvis blir väldigt konstigt.

Men eftersom översättningen är automatiskt så kan vi inte ÄNDRA texten, vi kan 
bara välja att inte översätta delar av den.


Hiya,
I kinda of agree since the same effekt is appearent in Swedish: "Made by" in 
Swedish, "Gjord av", means nothing at all.
At the same time I think this is one of those classic problems that crops up 
with translations in general. We assume that there is some sort of 
accessability principle that means that you need to automatically translate 
everything and forget how common the English (or French) language is. "Eau de 
Toilette" in English and Swedish, directly translated, is for example very 
strange.  ("Toilet Water")

But since the translation is automatic we can't CHANGE the text, we can only 
choose not to translate parts of it.

On Thursday, 3 August 2017 21.00.26 CEST Olivier Churlaud wrote:
> [English below, for plasma people]
> 
> Bonjour,
> 
> J'ai vu que récemment la string "Plasma, made by KDE" a été traduit en
> "Plasma, fait par KDE".
> 
> Mon avis n'est peut-être pas partagé, mais je trouve que ça en jette moins.
> 
> Revenir vers du made by KDE serait préférable, non?
> 
> Qu'en pensez vous?
> 
> Si vous pouviez me mettre en copie de la réponse, je ne suis pas dans la
> mailing-list.
> 
> Olivier
> 
> ---
> Hi!
> 
> I've seen on my French version of Plasma that the string "Plasma, made by
> KDE" on the loading screen (after entering your credentials) was translated
> in French. I think it's a mistake to translate this, because it just
> doesn't sound as cool as the english one.
> 
> Maybe it's just french, or my feeling about it, but I think the "made by"
> works very well in English.
> 
> What do you think?
> Please add me in copy of your answer, as I'm not anymore in the mailing
> list.
> 
> Cheers,
> Olivier

Re: Plasma Vision v 2.0

[Jens]

Ok after much edits and fiddling this is the current one - based on input from 
a wealth of sources and people:

-- --

"Plasma is a cross-device work environment by the KDE Community where 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 workflow that 
makes 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 is allowed to do, it only ensures that she can.

Our motivation is to enable actual work to happen, across devices, across 
different platforms, using any application needed.

We build to be durable, we create to be usable, we design to be elegant."

-- --

This is the final call for feedback and input! Calling all passengers! If you 
have feedback GIVE IT ! :D

/Jens

On Friday, 9 June 2017 09.40.28 CEST 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

[Breeze] [Bug 381288] Breeze could use higher-contrast text by default (tweaked color scheme attached)

[Jens Reuterberg]

https://bugs.kde.org/show_bug.cgi?id=381288

--- Comment #7 from Jens Reuterberg <jens...@kolabnow.com> ---
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 <pointedst...@zoho.com> changed:
> 
>What|Removed |Added
> 
> Status|RESOLVED|UNCONFIRMED
>  Resolution|WONTFIX |---
> 
> --- Comment #6 from Nate Graham <pointedst...@zoho.com> ---
> 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)

[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.

Re: [Breeze] [Bug 381288] Breeze could use higher-contrast text by default (tweaked color scheme attached)

[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/

Re: Plasma Vision v 2.0

[Jens Reuterberg]

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

[Jens Reuterberg]

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 <mgraess...@kde.org> wrote:
> > Am 2017-06-12 01:19, schrieb Aleix Pol:
> >> On Sun, Jun 11, 2017 at 11:13 PM, Jonathan Riddell <j...@jriddell.org>
> >> 
> >> 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

[Jens Reuterberg]

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

[Jens Reuterberg]

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

[Jens Reuterberg]

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

[Jens Reuterberg]

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

[Jens Reuterberg]

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

[Jens Reuterberg]

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

[Jens Reuterberg]

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

[Jens Reuterberg]

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

[Jens Reuterberg]

https://bugs.kde.org/show_bug.cgi?id=378606

--- Comment #5 from Jens Reuterberg <jens...@kolabnow.com> ---
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

[Jens Reuterberg]

https://bugs.kde.org/show_bug.cgi?id=378606

Jens Reuterberg <jens...@kolabnow.com> changed:

   What|Removed |Added

 CC|    |jens...@kolabnow.com

--- Comment #3 from Jens Reuterberg <jens...@kolabnow.com> ---
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

[Jens Reuterberg]

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

[Jens Reuterberg]

https://bugs.kde.org/show_bug.cgi?id=374300

Jens Reuterberg <jens...@kolabnow.com> changed:

   What|Removed |Added

 CC|    |jens...@kolabnow.com

--- Comment #1 from Jens Reuterberg <jens...@kolabnow.com> ---
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

[Jens Reuterberg]

https://bugs.kde.org/show_bug.cgi?id=373668

Jens Reuterberg <jens...@kolabnow.com> changed:

   What|Removed |Added

 CC|    |jens...@kolabnow.com

--- Comment #8 from Jens Reuterberg <jens...@kolabnow.com> ---
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 (Jens Reuterberg)]

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

[Jens Reuterberg]

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=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 (Jens Reuterberg)]

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

[Jens Reuterberg]

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 <mgraess...@kde.org>
> 
> 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 and the 
i

Re: Touchpad Gestures - Experimental

[Jens Reuterberg]

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 <mgraess...@kde.org> 
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

[Jens Reuterberg]

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

[Jens Reuterberg]

https://bugs.kde.org/show_bug.cgi?id=370374

Jens Reuterberg <jens...@kolabnow.com> changed:

   What|Removed |Added

 CC|    |jens...@kolabnow.com

--- Comment #10 from Jens Reuterberg <jens...@kolabnow.com> ---
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 (Jens Reuterberg)]

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 (Jens Reuterberg)]

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

[Jens Reuterberg]

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
> > <oliv...@churlaud.com>
> 
> 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.
> > >> 
> > >> It's

Re: A Plasma Vision draft

[Jens Reuterberg]

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: Plasma desktop/mobile initial setup

[Jens]

Well ok it's not a perfect example. Also having a chat with one of the GNOME 
designers about fedora s welcome thing on what they learned and thought about 
it since theirs is kinda nice and non intrusive as well as helping set up 
things like social accounts etc.

Not saying it's rubbish just that it has to be considered for what it brings to 
the table. Is the introduction too in depth we may consider it something that 
needs redesign. What does it give the user beyond helping him/her getting 
acquainted with the DE? Like things like "do you want to install an office 
suite?" Or help setting up email etc?

It's a big topic and it's also a risk of using it as an excuse instead of 
redesigning stuff that needs it

On 15 September 2016 09:20:19 CEST, "Ivan Čukić"  wrote:
>Hi all,
>
>I agree that the first-run wizard might be annoying. But if it was a
>first-screen with options to have 'introduction', 'new features',
>'setup wizard', I think it would be ok. Manjaro has had a first-run
>screen for ages, I never found it problematic.
>
>Plus, Martin had a few really nice points there.
>
>> Beyond that there is also the old truism that if you need to explain
>to
>> the user how to do common tasks then those tasks need redesign.
>
>I think this is a fallacy. If you had a lumberjack that used an axe
>for his whole life, and got him a chainsaw, without any introductory
>instructions, he would just keep swinging that thing at the tree.
>
>The fact that people are used to a certain kind of UI is not the
>reason for you not to invent something new and better.
>
>Cheers,
>Ivan

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Plasma desktop/mobile initial setup

[Jens]

The issue with first-run wizards is that they tend to get in the way more than 
they help, and are often skipped past and difficult to get back. 

One idea would be to have the "introduction" something that cm can be launched 
from the launcher or from system settings.

Beyond that there is also the old truism that if you need to explain to the 
user how to do common tasks then those tasks need redesign. I am more than 
intetested in this subject though and think that any work on it whether it's 
realized or not will be valuable. If nothing else to explore the pitfalls of 
design clearly and how we can improve them (to avoid an install wizard)

On 14 September 2016 14:25:26 CEST, "Martin Gräßlin"  wrote:
>Am 2016-09-14 13:54, schrieb Jan Grulich:
>> Hi,
>> 
>> some time ago I had an idea to propose something like Plasma initial 
>> setup as
>> a bachelor thesis to our RedHat system, where students then can pick
>up 
>> our
>> ideas and realize them as their theses. Recently I got a student who 
>> would
>> like to work on this and I would like to know whether it's a good
>idea 
>> and
>> something like this would be desired. The initial setup would allow
>to
>> configure basic stuff like language, keyboard layout, online accounts
>
>> and so
>> on. What I realized now that we could actually do this for both
>desktop 
>> and
>> mobile using Kirigami. What do you think?
>
>I think that sounds great. Of course Johnathan has a point - it
>overlaps 
>with distro setup. But distro setup cannot handle new users or users 
>switching from GNOME ;-)
>
>There are certainly a few things which I would love to have in a first 
>run "wizard" which we currently don't expose at all. E.g. the location 
>service based on WIFI - or ideas like collecting user data where we
>need 
>them to opt in.
>
>So to me it's something which we absolutely lack at the moment! But 
>anyway: I think that needs close interaction with VDG (especially 
>Thomas).
>
>Cheers
>Martin

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Plasma 5.8 Beta Release announcement

[Jens]

I'd love to mention that without bugtesting, no LTS, since we need to push more 
for bugtesting in general and especially now. So essentially what's already in 
there but with a longer explenation or its own section about the need for bug 
tests.  

(Or talk about and link to how-to for bug triage)



On 14 September 2016 10:12:23 CEST, Kai Uwe Broulik  
wrote:
>Hi all,
>
>
>I wrote a preliminary release announcement for 5.8 Beta (due
>tomorrow!).
>
>
>Please help. :) Especially the paragraph about the new look and feel
>export json stuff, I have no idea about, needs extending. 
>
>
>Thanks,
>
>Kai Uwe 
>
>
>[1] https://notes.kde.org/p/plasma_5_8

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Plasma 5.8 Promo

[Jens]

Lukas one of the guys from Linux Action Show wanted to do voice over for the 
next video.  It's a dude sadly but it's also a well known dude so that would be 
good for us.

There are some things I wanted to ask in general: do we have a slogan for the 
release? "Fly!" Or something similarly abstract and easy to reuse for other 
promo things? 

On 12 September 2016 14:07:25 CEST, Jonathan Riddell  wrote:
>At Akademy is was discussed 5.8 LTS promo and the idea to market it as
>a milestone for Plasma and KDE and an excuse for people to re-evaluate
>our software.
>
>So the 5.8 announcement will focus on the great features of Plasma and
>not just the change from 5.7
>
>Lukasz are you able to take this into account when making your
>wonderful video?
>
>I think David has the notes from the BoF on what those great features
>are, he should send them on shortly.
>
>Jonathan

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: From Grub to Shutdown project update

[Jens Reuterberg]

> 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

[Jens Reuterberg]

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.
> 
> Other parts 

From Grub to Shutdown project update

[Jens Reuterberg]

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 

[Breeze] [Bug 365318] KRDC is unreadable under breeze dark theme

[Jens Reuterberg via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=365318

Jens Reuterberg <ohy...@gmail.com> changed:

   What|Removed |Added

 CC||ohy...@gmail.com

--- Comment #12 from Jens Reuterberg <ohy...@gmail.com> ---
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

[Jens Reuterberg]

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?

[Jens Reuterberg]

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

[Jens Reuterberg via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364953

--- Comment #4 from Jens Reuterberg <ohy...@gmail.com> ---
Created attachment 99798
  --> https://bugs.kde.org/attachment.cgi?id=99798=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

[Jens Reuterberg via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364953

Jens Reuterberg <ohy...@gmail.com> changed:

   What|Removed |Added

 CC||ohy...@gmail.com

--- Comment #3 from Jens Reuterberg <ohy...@gmail.com> ---
"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

[Jens Reuterberg]

> 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

[Jens Reuterberg]

---
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

[Jens Reuterberg]

---
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 (Jens Reuterberg)]

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 (Jens Reuterberg)]

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: Requirements for Plasma Mobile at CyanogenModBase and Neon for other devices

[Gerold Jens Wucherpfennig]

Am 09.05.2016 um 15:44 schrieb Bhushan Shah:
...
> 
> You need to enable the VT console in the kernel config,
> 
> CONFIG_VT_CONSOLE=y
> CONFIG_VT_CONSOLE_SLEEP=y
> 
> In specific, for hammerhead config,
> 
> % grep "CONSOLE" cyanogenmod_hammerhead_defconfig | grep '^CONFIG.*'
> CONFIG_CONSOLE_TRANSLATIONS=y
> CONFIG_VT_CONSOLE=y
> CONFIG_VT_CONSOLE_SLEEP=y
> CONFIG_HW_CONSOLE=y
> CONFIG_SERIAL_CORE_CONSOLE=y
> CONFIG_SERIAL_MSM_HSL_CONSOLE=y
> CONFIG_DUMMY_CONSOLE=y
> CONFIG_ANDROID_RAM_CONSOLE=y
> 
>>
>> Here is /proc/cmdline:
>>
>> console=ttySAC2,115200 consoleblank=0 androidboot.selinux=permissive
>> loglevel=4 console=ram androidboot.serialno=000934b07d3f2f
>> sec_debug.enable=0 sec_debug.enable_user=0 c1_watchdog.sec_pet=5
>> sec_log=0x10@0x4d90 s3cfb.bootloaderfb=0x5ec0
>> ld9040.get_lcdtype=0x0 consoleblank=0 lpj=3981312 vmalloc=144m
>>
> 
> You will also need to change the BoardConfig.mk for your device to have,
> 
> console=tty0 instead of console=ttySAC2,115200 in the device tree, see
> patch to hammerhead device tree.
> 

It still does not work. kernel_config2.gz ist attached to this email.
/proc/cmdline is:

console=tty0 consoleblank=0 androidboot.selinux=permissive loglevel=4
console=ram androidboot.serialno=000934b07d3f2f sec_debug.enable=0
sec_debug.enable_user=0 c1_watchdog.sec_pet=5
sec_log=0x10@0x4d90 s3cfb.bootloaderfb=0x5ec0
ld9040.get_lcdtype=0x0 consoleblank=0 lpj=3981312 vmalloc=144m


And /var/log/upstart/lightdm.log is:

Failed to open VT master: No such file or directory
Jumping to VT -1
Failed to open /dev/tty-1: No such file or directory
Using /dev/tty0 instead of /dev/tty-1!
Failed to manage VT manually: Bad file descriptor
Couldn't initiate jump to VT -1: Bad file descriptor
[PAM] Starting...
[PAM] Authenticating...
[PAM] returning.
startng process
starting  "/usr/bin/kwinwrapper"
"cat: "
"/sys/devices/virtual/dmi/id/board_name"
": No such file or directory"
"\n"
"No backend specified through command line argument, trying auto resolution"
"\n"
"QSocketNotifier: Invalid socket 15 and type 'Read', disabling...\n"
"KCrash: crashing... crashRecursionCounter = 2\n"
"KCrash: Application Name = kwin_wayland path = /usr/bin pid = 1869\n"
"KCrash: Arguments: "
"/usr/bin/kwin_wayland "
"--xwayland "
"--libinput "
"--lockscreen "
"--inputmethod "
"maliit-server "
"plasma-phone "
"\n"
"KCrash: Attempting to start
/usr/lib/arm-linux-gnueabihf/libexec/drkonqi from kdeinit\n"
"Warning: connect() failed: : No such file or directory\n"
"KCrash: Attempting to start
/usr/lib/arm-linux-gnueabihf/libexec/drkonqi directly\n"
"This application failed to start because it could not find or load the
Qt platform plugin \"wayland-org.kde.kwin.qpa\"\nin \"\".\n\nAvailable
platform plugins are: wayland-org.kde.kwin.qpa, eglfs, linuxfb, minimal,
minimalegl, offscreen, wayland-egl, wayland, xcb.\n\nReinstalling the
application may fix this problem.\n"


In /dev there is only "tty" and not "tty0"



I hope you can help me in this regard ...





kernel_config2.gz
Description: application/gzip
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Requirements for Plasma Mobile at CyanogenModBase and Neon for other devices

[Gerold Jens Wucherpfennig]

Am 09.05.2016 um 08:15 schrieb Bhushan Shah:
> On Monday, May 9, 2016 11:14:23 AM IST, Gerold Jens Wucherpfennig wrote:
>> Hi everybody,
>>
>> I'd like to "port" Plasma Mobile to my smartphone device. (GT-I9100)
>> I've read about https://community.kde.org/Plasma/Mobile/CyanogenModBase
>> I've compiled the whole CyanogenMod 11 for my smartphone device.
>> I've compiled the DorimanX v10 Kernel with namespaces support
>> (based on linux kernel 3.15).
> 
> Awesome and thanks for stepping up on porting :-)
> 
>> I am able to start the LXC container.
>> I can log into the ubuntu operating system.
> 
> Sounds good so far..
> 
>> It's impossible to start the wayland session!
>>
>> What are the CyanogenModBase requirements for Plasma Mobile?
> 
> There are some changes required in CyanogenMod, but it is entierly
> possible that they may not be required at all for your device.
> 
>> Are there any changes required at the KDE neon operating system?
> 
> None, I can think of..
> 
>> Here is the output of "/var/log/upstart/lightdm.log"
>>
>>
>> Failed to open VT master: No such file or directory
>> Jumping to VT -1
>> Failed to open /dev/tty-1: No such file or directory
>> Using /dev/tty0 instead of /dev/tty-1!
>> Failed to manage VT manually: Bad file descriptor
>> Couldn't initiate jump to VT -1: Bad file descriptor
> 
> This sounds bad..

I think that I need to recompile the kernel with
some additional kernel features again.

I do not want to speculate, so I seek your advice.

> 
> Can you provide /proc/cmdline and kernel config?


The kernel configuration is attached to this email.
Look at kernel_config.gz


Here is /proc/cmdline:

console=ttySAC2,115200 consoleblank=0 androidboot.selinux=permissive
loglevel=4 console=ram androidboot.serialno=000934b07d3f2f
sec_debug.enable=0 sec_debug.enable_user=0 c1_watchdog.sec_pet=5
sec_log=0x10@0x4d90 s3cfb.bootloaderfb=0x5ec0
ld9040.get_lcdtype=0x0 consoleblank=0 lpj=3981312 vmalloc=144m

> 
> Thanks

I thank you in advance...






kernel_config.gz
Description: application/gzip
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Requirements for Plasma Mobile at CyanogenModBase and Neon for other devices

[Gerold Jens Wucherpfennig]

Hi everybody,

I'd like to "port" Plasma Mobile to my smartphone device. (GT-I9100)
I've read about https://community.kde.org/Plasma/Mobile/CyanogenModBase
I've compiled the whole CyanogenMod 11 for my smartphone device.
I've compiled the DorimanX v10 Kernel with namespaces support
(based on linux kernel 3.15).

I followed the steps mentioned in:
https://community.kde.org/Plasma/Mobile/CyanogenModBase

I am able to start the LXC container.
I can log into the ubuntu operating system.

It's impossible to start the wayland session!

What are the CyanogenModBase requirements for Plasma Mobile?
Are there any changes required at the KDE neon operating system?


Here is the output of "/var/log/upstart/lightdm.log"


Failed to open VT master: No such file or directory
Jumping to VT -1
Failed to open /dev/tty-1: No such file or directory
Using /dev/tty0 instead of /dev/tty-1!
Failed to manage VT manually: Bad file descriptor
Couldn't initiate jump to VT -1: Bad file descriptor
[PAM] Starting...
[PAM] Authenticating...
[PAM] returning.
startng process
starting  "/usr/bin/kwinwrapper"
"cat: "
"/sys/devices/virtual/dmi/id/board_name"
": No such file or directory"
"\n"
"No backend specified through command line argument, trying auto resolution"
"\n"
"QSocketNotifier: Invalid socket 15 and type 'Read', disabling...\n"
"KCrash: crashing... crashRecursionCounter = 2\nKCrash: Application Name
= kwin_wayland path = /usr/bin pid = 1851\n"
"KCrash: Arguments: /usr/bin/kwin_wayland --xwayland --libinput
--lockscreen --inputmethod maliit-server plasma-phone \n"
deinit\n"
"Warning: connect() failed: : No such file or directory\n"
ly\n"
n"



___
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

[Jens Reuterberg]

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

[Jens Reuterberg]

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 <se...@kde.org> 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

[Jens Reuterberg]

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 <jens...@kolabnow.com> 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

[Jens Reuterberg]

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

[Jens Reuterberg]

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

[Jens Reuterberg]

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

[Jens Reuterberg]

> 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

[Jens Reuterberg]

> 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

[Jens Reuterberg]

> 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

[Jens Reuterberg]

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: Noto fonts screw my system, please stop forcing fonts upon me!

[Jens Reuterberg]

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!

[Jens Reuterberg]

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

[Jens Reuterberg]

On Monday, August 17, 2015 05:12:00 AM Jeremy Whiting wrote:
 On Mon, Aug 17, 2015 at 4:42 AM, Sebastian Kügler se...@kde.org 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

[Jens Reuterberg]

Perhaps link to the toolkit in the HIG?

Den 23 aug 2015 10:34 fm skrev Alex Merry alex.me...@kde.org:

 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

[Jens Reuterberg]

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 k...@privat.broulik.de 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

[Jens Reuterberg]

On Monday, August 17, 2015 05:12:00 AM Jeremy Whiting wrote:
 On Mon, Aug 17, 2015 at 4:42 AM, Sebastian Kügler se...@kde.org 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

[Jens Reuterberg]

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

[Jens Reuterberg]

---
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

[Jens Reuterberg]

---
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

[Jens Reuterberg]

https://bugs.kde.org/show_bug.cgi?id=347123

Jens Reuterberg j...@ohyran.se changed:

   What|Removed |Added

 CC||j...@ohyran.se

--- Comment #11 from Jens Reuterberg j...@ohyran.se ---
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

[Jens Reuterberg]

---
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

[Jens Reuterberg]

https://bugs.kde.org/show_bug.cgi?id=349468

Jens Reuterberg ohy...@gmail.com changed:

   What|Removed |Added

 CC||ohy...@gmail.com

--- Comment #4 from Jens Reuterberg ohy...@gmail.com ---
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

[Jens Reuterberg]

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

[Jens Reuterberg]

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 
j...@jriddell.org 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: plasma wallpapers

[Jens Reuterberg]

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 
j...@ohyran.se 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

[Plasma Workspace Wallpapers] [Bug 344586] New: No download and setting of new wallpapers, themes and so on possible.

[Jens Goller]

https://bugs.kde.org/show_bug.cgi?id=344586

Bug ID: 344586
   Summary: No download and setting of new wallpapers, themes and
so on possible.
   Product: Plasma Workspace Wallpapers
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: plasma-devel@kde.org
  Reporter: jens.gol...@jensgoller.de

Since I upgraded my system to KDE 5.2 and Plasma 5 it is impossible to download
and change desktop stuff like wallpapers. The download doesnt work and gives a
message like Download from http://download.kde.org/ocs/providers.xml failed.
Trying to open pictures from my computer does only open a file system window
that doen't do anything... :-(
Earlier versions of KDE provided the possibility to set different wallpapers to
each workspace. But I can't find it in the new desktop ... :-(
Thanks for your kind help in advance!
Regards
Jens

Reproducible: Always

-- 
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: theme mixing

[Jens Reuterberg]

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 se...@kde.org 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

[Jens Reuterberg]

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 anditosan1...@gmail.com
 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

[Jens Reuterberg]

On Monday 05 January 2015 01:34:17 Aleix Pol wrote:
 On Sat, Jan 3, 2015 at 6:23 PM, Thomas Pfeiffer 
thomas.pfeif...@kde.org 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

[Jens Reuterberg]

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: Plasma 5.2 Kickoff meeting minutes

[Jens Reuterberg]

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: wallpapers on lock screen

[Jens Reuterberg]

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: Breeze dark theme white edge outlines

[Jens Reuterberg]

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: Moving kde:muon repository to kde/workspaces

[Jens Reuterberg]

[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 aleix...@kde.org 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: Plasma 5 T-Shirts

[Jens]

I know the guy who pushed for it BUT we where all caught up in the end run for 
5 so no one could deal with it.

All it takes is a PNG of reasonable size and off we go. All that matters is 
asking the promo team what the promotion goals are for 5 and what they wish to 
aim for in terms of values.

On Thursday 17 July 2014 00.51.25 Aleix Pol wrote:
 Hi,
 Has anybody thought about this? It could make sense to get t-shirts, we
 need a good design, but we have material I'd say and it can be a nice way
 to gather some income and have some things to offer.
 
 Somebody pushed this in the VDG forum [1] but he wasn't very successful.
 
 Aleix
 
 [1] https://forum.kde.org/viewtopic.php?f=285t=121831

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 119232: Rewrite the Calendar component grid + small refactor

[Jens]

 I don't get why they're brighter anyway. borderOpacity is 1.0, so if they
 overlap that shouldn't have any impact?
 
 
 - David

Just a shot in the dark here but if its two vector lines on top of each other 
the bitmap version of them tend to be a tad more than the exact line width 
making parts of them a bit transparent and when two are on top of each other 
it makes the line bigger and so when you look at it, they are brighter

(Note: know nothing about this issue but exactly THIS happens to me all the 
time when dealing with vector images and thin lines)

 
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119232/#review62191
 ---
 
 On July 12, 2014, 11:52 a.m., Martin Klapetek wrote:
  ---
  This is an automatically generated e-mail. To reply, visit:
  https://git.reviewboard.kde.org/r/119232/
  ---
  
  (Updated July 12, 2014, 11:52 a.m.)
  
  
  Review request for Plasma.
  
  
  Repository: plasma-framework
  
  
  Description
  ---
  
  Currently the grid itself is composed of 88 rectangles that draw all the
  lines in a way that two big rect draws the whole two topmost horizontal
  and leftmost vertical border lines and then each day rectangle is drawing
  small bottom and right rect.
  
  This patch reduces it to 13 rects only where one rect draws the whole
  frame around the grid and then 1px wide/high rects draw the inner lines.
  Results in much cleaner  simple code.
  
  Plus there's a small refactor on the id names so it makes more sense.
  
  This does not require any additional changes in the applets.
  
  
  Diffs
  -
  
src/declarativeimports/calendar/qml/MonthMenu.qml 5209816
src/declarativeimports/calendar/qml/MonthView.qml ba3fe95
src/declarativeimports/calendar/qml/CalendarToolbar.qml cd28702
src/declarativeimports/calendar/qml/DayDelegate.qml 11f0afa
src/declarativeimports/calendar/qml/DaysCalendar.qml ae9df01
  
  Diff: https://git.reviewboard.kde.org/r/119232/diff/
  
  
  Testing
  ---
  
  All applets using the Calendar component looks exactly the same and work
  perfectly fine with no changes in the applets.
  
  
  File Attachments
  
  
  digital-clock before/after
  
https://git.reviewboard.kde.org/media/uploaded/files/2014/07/11/9a4f02eb
-b06c-4d13-8ea5-94276659fba8__plasma_cal4.png 
  Thanks,
  
  Martin Klapetek

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Munich Sprint in November?

[Jens]

If you guys need a graphics designer with a mustasche I am s there!

On Tuesday 08 July 2014 19.40.04 Michael Bohlender wrote:
 Hey everyone!
 
 The City of Munich (one of our largest institutional users) has offered
 Kubuntu, Debian, LibreOffice and KDE PIM to host two hackfests/sprints in
 November (two teams per event). The LibreOffice guys are busy with another
 sprint somewhere in France and can't make it.  So the choice is now to
 either have a single event with three teams, or to find another team that
 wants to come to Munich.
 
 Are you guys interested ?
 I should probably mention, that there is free food and beverages for the
 entire weekend, cooked and payed for by our gracious host.
 
 Cheers
 
 M.

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5 RC

[Jens Reuterberg]

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: Plasma 5 RC

[Jens Reuterberg]

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: Background for login, splash, and lockscreen

[Jens Reuterberg]

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