Re: Review Request 108992: Simple optimizations in SignalPlotter

[Raul Fernandes]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/108992/
---

(Updated May 5, 2014, 10:54 p.m.)


Status
--

This change has been discarded.


Review request for Plasma.


Repository: kdelibs


Description
---

- create variables and classes outside the loops
- reserve space in QList if we know already how many items will be added (avoid 
unnecessary reallocations)
- use const_iterator when possible
- remove a useless call (p->setPen(Qt::NoPen) - it will be set latter before be 
used)
- avoid multiplications (x3, x2, x1 and x0)


Diffs
-

  plasma/widgets/signalplotter.cpp 8e9e294 

Diff: https://git.reviewboard.kde.org/r/108992/diff/


Testing
---

I have tested with KDE 4.10 with no problems.
I have seen a improvement of about 5% in drawPlots() function, the most 
expensive function in painting.


Thanks,

Raul Fernandes

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

Re: Plasma 5?

[Aleix Pol]

On Mon, May 5, 2014 at 7:25 PM, Martin Graesslin  wrote:

> On Monday 05 May 2014 17:56:04 Ivan Čukić wrote:
> > Jens:
> > > the best option is to simply go with "Plasma by KDE"
> >
> > and
> >
> > > "So what version am I running?" is "Plasma 2", "Plasma 5",
> >
> > +1
> >
> > I don't mind the version 5.x (though, I didn't mind any of the proposals)
> >
> > Wondering what is Martin's stance on this since the year.month was his
> > child.
>
> oh well, as I'm addressed I'm going to answer.
>
> As it's well known I dislike the 5 for two reasons:
>
> 1. It will end in "Plasma" == "KDE". sebas's point to that is that he
> doesn't
> care, I understand that, but on the other hand I think it's a lost
> opportunity.
> 2. I'm afraid of people discarding the version because of fear of repeating
> 4.0.
>
> If the version number is turned into a pure technical thing and never ever
> mentioned any where in the promo, I think it can work. But that also
> requires
> that media is informed why we don't want to have the technical version to
> be
> prominent. Otherwise we will have "KDE 5.0 released" - which I just don't
> want
> to see happen.
>
> Now what about the year.month scheme: in my opinion version numbers don't
> carry any information but people try to interpret information into it,
> which
> can only fail. Thus I would like to move away from a version number scheme
> which allows to interpret. The year.month scheme carries one explicit
> information: the age the software has. In a year it's not possible to know
> how
> old 5.3 or 5.0 is. With 2015.04 and 2014.06 this is obvious. Why do I
> think it
> is important to have this information? Because we see quite often that
> distros
> ship outdated versions and that users get upset when we tell them that what
> they use is outdated. With such a version number they would be able to see
> this themselves and maybe even start to look for a newer version, kick the
> distros a** or whatever ;-)
>
> In the end I don't care what will be decided. This has been brought up too
> often for me to care about. I don't want to see a 5 in any public
> communication, also not in our blog posts. If it's internal, it's fine, but
> please no 5 in public communication. I would be way happier with 2 which I
> think is the logical successor to Plasma 1, but I understand sebas's
> argumentation for the 5.
>
> Cheers
> Martin
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
Regarding 1), put it as you wish, but in the end it's KDE 5 without
applications.

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

Re: Multi-screen on Plasma Shell

[Martin Klapetek]

I wanted to test it out a bit as I have a multi-screen setup too, but
plasma-shell crashes on startup for me - backtrace ->
http://paste.kde.org/pscwpjjnp

Also as I mentioned earlier, please run astyle on it before merging to have
a consistent coding style in the files. Please don't ignore that.

Cheers
-- 
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5?

[Jens Reuterberg]

I hate to play the devils (or in this case Martin G's ;) ) advocate but these 
are the issues that will crop up:

People love names to be able to say "I use umptybump and not bippitbop". This 
will make people want to know what version they have in the beginning of the 
process. The upside with the whole "plasma by kde" thing or for that matter 
"Plasma Next" is that it informs users what it is - the cool thing about 
Plasma as term is that its caught on more or less without push in the VDG 
forums. That and "Plasma Next"/"Plasma Current"

But there will be an overlap where people will out of pure confusion go 
"Plasma 5" or "KDE 5" - this can't be avoided. Not this late in the game (but 
on the other hand it wouldn't have been avoided with the date numbers either).

But there are ways to promote the new name - some of whom I mentioned to 
Sebas:

The goal is to separate the two brands "KDE" and "Plasma" or to show that they 
are connected as one is made by the other but not one and the same.
To do this we need to create our own form of branding and marketing. It 
doesn't matter if we scream it at the top of our lungs if the promo adress 
still reads "KDE" or the way we say it (dot-article) is still identical with 
"KDE".
KDE and Plasma are intertwined so hard that we shouldn't even mention KDE 
except as a "by KDE" addendum. The visuals the design the language all have to 
be reworked and revamped to better show that there is a distinction between 
the two. Yes it's true it is made by KDE but we don't have to say that - its 
even positive if people assumed the opposite and claim that we are "moving out 
on our own" because then they will have to ask us and we can say "No its just 
that KDE is one thing and Plasma is another". For every flamer like article 
certain blogs write we are simply doing ourselves a favor.

We don't FORCE the issue "oh don't say KDE 5 say Plasma" we just repeat what 
they said and exchange KDE for Plasma. We try to force the hashtag 
#PlasmaByKDE on Google plus and Twitter. 
We also instead of saying "Oh its Plasma 5/2/2014.6" say "The current version 
of Plasma" or "The coming new version of Plasma". Leaving numbering way 
behind. That will result in some confusion in which we will all have to have 
our ears to the rails and make certain that whenever someone says "So what is 
that? KDE 5?" we can go "No its the next version of Plasma by KDE and its 
'Plasma 5/2/2014.6'" 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5?

[Ivan Čukić]

I meant +1 for "Plasma by KDE", and when someone wants the version, he can
say KDE^WPlasma 5 :)


On 5 May 2014 19:04, Jens Reuterberg  wrote:

> Well to be honest the same can be said of "Plasma 2014.5" - I mean as
> long as that name is kept as a form of technical definer and never ever
> near marketing and promo work.
>
> (So Ivan, no dancing on a beach in black and white while a voice
> whispers "between beauty and desire, between 1337 and n00b lies ...
> Plasma... by KDE" in my "...by Calvin Kline" spoof? ;) )
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>



-- 
Cheerio,
Ivan

--
While you were hanging yourself on someone else's words
Dying to believe in what you heard
I was staring straight into the shining sun
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5?

[Martin Graesslin]

On Monday 05 May 2014 17:56:04 Ivan Čukić wrote:
> Jens:
> > the best option is to simply go with "Plasma by KDE"
> 
> and
> 
> > "So what version am I running?" is "Plasma 2", "Plasma 5",
> 
> +1
> 
> I don't mind the version 5.x (though, I didn't mind any of the proposals)
> 
> Wondering what is Martin's stance on this since the year.month was his
> child.

oh well, as I'm addressed I'm going to answer.

As it's well known I dislike the 5 for two reasons:

1. It will end in "Plasma" == "KDE". sebas's point to that is that he doesn't 
care, I understand that, but on the other hand I think it's a lost 
opportunity.
2. I'm afraid of people discarding the version because of fear of repeating 
4.0.

If the version number is turned into a pure technical thing and never ever 
mentioned any where in the promo, I think it can work. But that also requires 
that media is informed why we don't want to have the technical version to be 
prominent. Otherwise we will have "KDE 5.0 released" - which I just don't want 
to see happen.

Now what about the year.month scheme: in my opinion version numbers don't 
carry any information but people try to interpret information into it, which 
can only fail. Thus I would like to move away from a version number scheme 
which allows to interpret. The year.month scheme carries one explicit 
information: the age the software has. In a year it's not possible to know how 
old 5.3 or 5.0 is. With 2015.04 and 2014.06 this is obvious. Why do I think it 
is important to have this information? Because we see quite often that distros 
ship outdated versions and that users get upset when we tell them that what 
they use is outdated. With such a version number they would be able to see 
this themselves and maybe even start to look for a newer version, kick the 
distros a** or whatever ;-)

In the end I don't care what will be decided. This has been brought up too 
often for me to care about. I don't want to see a 5 in any public 
communication, also not in our blog posts. If it's internal, it's fine, but 
please no 5 in public communication. I would be way happier with 2 which I 
think is the logical successor to Plasma 1, but I understand sebas's 
argumentation for the 5.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5?

[Jens Reuterberg]

Well to be honest the same can be said of "Plasma 2014.5" - I mean as 
long as that name is kept as a form of technical definer and never ever 
near marketing and promo work.

(So Ivan, no dancing on a beach in black and white while a voice 
whispers "between beauty and desire, between 1337 and n00b lies ... 
Plasma... by KDE" in my "...by Calvin Kline" spoof? ;) )
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Multi-screen on Plasma Shell

[Aleix Pol]

Hi,
As some of you know, I've been trying to polish the plasma shell usage on
two screens. It's a use-case I hit a lot given that I have 2 screens both
in the office and at home and I think it's really important to be on par
with Plasma 1 on this area, at least, especially if we want to be appealing
in the desktop world.

When I started to work on it, I got stuck when I wanted to figure out the
primary screens management [1]. It works well, but then there's important
API missing, so I decided to give a try to libkscreen. The reason behind it
is that I do believe that Qt's API should be fixed, but then I would like
Plasma Next to start shipping with an acceptable support of multiple
screens. My first approach can be found in the plasmashell+libkscreen
branch.

I've been testing it locally and it works quite well, it seems to do what
we want it to do and I'm committing to the approach.

Since it's a rather big change and it involves a new dependency, I decided
to send this e-mail first and ask for comments. If nobody is against it I
will merge it to master in a couple of days.

Cheers!
Aleix

[1] https://bugreports.qt-project.org/browse/QTBUG-38404
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Breeze QML window decoration

[Andrew Lake]

On Mon, May 5, 2014 at 6:54 AM, Martin Gräßlin wrote:

>
> some feedback after running the deco for most of today:
> * in maximized state there is still a round corner in top left and top
> right
> * I experience a slight flicker when mouse over buttons
> * there's a config dialog (which looks like forked from Plastik) which is
> not
> updated in the deco? Maybe remove?
> * Changing button sizes has no effect - this is important for accessibility
>
>
Awesome, thanks for the feedback Martin. Hope it's working mostly ok
otherwise.

I'll be sure to take a look at this stuff over the next day or two.
Obviously, if anyone else finds solutions before I get to them feel free to
share them.

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

Re: Plasma 5?

[Ivan Čukić]

Jens:
> the best option is to simply go with "Plasma by KDE"
and
> "So what version am I running?" is "Plasma 2", "Plasma 5",

+1

I don't mind the version 5.x (though, I didn't mind any of the proposals)

Wondering what is Martin's stance on this since the year.month was his
child.

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

Re: Plasma 5?

[Jens Reuterberg]

Personally (and I've said this before) from my point of view a name is either

a) a technical definition
b) a form of promotion

As for technical reasoning behind either name - I have little or no opinion. 
This is not my field to piss in as it where. BUT for the usage of promo work 
the best option is to simply go with "Plasma by KDE" (which opens the 
wonderful opportunity to do a spoof of the "by Calvin Klein" perfume ads (but 
with devs on a beach))
Then if the proper answer to the question "So what version am I running?" is 
"Plasma 2", "Plasma 5", "Plasma Current" or "Plasma 2014.06" is less relevant 
as long as there is one.

With a 5 we can do some things too, the two as well... actually from a 
communicative standpoint I think we can do something with all ...

Anyway I am all thumbs and a smile to whatever you guys decide as long as 
using "Plasma" is ok.

(oh and lets remember that "confused user" isn't always bad. If its an 
annoying thing, something that makes you angry - then yes its bad. If its 
something that makes you ask in a public forum "Oh so thats like what Plasma 
5? Or Next?" its good since it will make more of a splash - as long as the 
answer is accessible we're fine)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5?

[Shantanu Tushar Jha]

+1

And, its easier to "say" as well :)


On Mon, May 5, 2014 at 8:51 PM, Marco Martin  wrote:

> On Monday 05 May 2014, Sebastian Kügler wrote:
>
> > The baseline, to use "Plasma" as the brand, and only refer to the version
> > as a technicality should of course stay the same.
> >
> > Why do I think 5 is better than 2014.6, or .?
>
> After trying (with not much success) to use publicly the next/2014.06
> scheme,
> I have to agree that I would feel more confortable with either Plasma 5 or
> Plasma 2
> To me either of which wouldn't make much difference, it's true tough that
> looks less confusing if it has the same number as frameworks and Qt
>
>
> --
> Marco Martin
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>



-- 
Shantanu Tushar(UTC +0530)
http://www.shantanutushar.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5?

[Marco Martin]

On Monday 05 May 2014, Sebastian Kügler wrote:

> The baseline, to use "Plasma" as the brand, and only refer to the version
> as a technicality should of course stay the same.
> 
> Why do I think 5 is better than 2014.6, or .?

After trying (with not much success) to use publicly the next/2014.06 scheme, 
I have to agree that I would feel more confortable with either Plasma 5 or 
Plasma 2
To me either of which wouldn't make much difference, it's true tough that 
looks less confusing if it has the same number as frameworks and Qt


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

Re: Plasma 5?

[Martin Klapetek]

On Mon, May 5, 2014 at 4:59 PM, Mark Gaiser  wrote:

>
> I do wonder though, why didn't you folks decide this on the plasma
> sprint earlier this year?
>

We did. That's where the original proposal came from.

Cheers
-- 
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5?

[Mark Gaiser]

On Mon, May 5, 2014 at 3:55 PM, Sebastian Kügler  wrote:
> Hi all,
>
> I am not happy with the 2014.6 name and naming scheme. There I said it.
>
> The reasons for this are multi-fold. First, and to me most importantly: It
> feels awkward. Now that might be because it's new, but it also feels like no
> one else is going to understand it.
>
> My thinking goes towards an option that we had briefly discussed, and I think
> dismissed too quickly, and for the wrong reasons.
>
> So, I'd like to get some feedback on the proposal to call the new Plasma
> release Plasma 5.0, and use the "old" version numbering scheme going forwards.
> That means after 5.0 comes 5.1, 5.2, and so on, same for minor releases
> (however that is going to end up being decided). This feedback can then be
> taken up with the promo and marketing department, I think that we should first
> make up our own minds (for that reason, no cross-post to kde-promo at this
> point).
>
> The baseline, to use "Plasma" as the brand, and only refer to the version as a
> technicality should of course stay the same.
>
> Why do I think 5 is better than 2014.6, or .?
>
> - It communicates continuity: Plasma Next really is the continuation of 15+
> years of doing a desktop. It has our DNA all over it, and it's not a
> disconnected "today's thing". Especially to our existing userbase, and those
> just outside of it (other people known to Free desktops), this has a real
> meaning. It's something people love, and sometimes hate, and it's not a
> completely new thing. This is well in line with what we've been talking about
> all along for Plasma Next.
>
> - It's trusted and proven: it works and will cause no problems with packaging,
> and comparing version number
>
> - It solves a bunch of technical inconsistencies (plasmapkg2 vs kcmshell5 --
> why has one the 2 appended, the other 5?), library sonames are 5 as well.
>
> - It indicates (like we did traditionally) that this is the 5th major version,
> building on a new Qt5, and Frameworks 5, we get to re-use that kind of
> consistency.
>
> - To me, it feels just right. I know many others feel that 2014.6 is bad, and
> I've yet to hear somebody that really likes it (might be my limitation of
> course).
>
> Now one of the reasons to not go for Plasma 5 was that "people would say
> that's KDE5, and we don't want that". To be honest, I stopped caring about
> that, if people want to call it KDE5, so be it, we'll call it Plasma 5 and do
> that consistently, as long as people understand what's talked about -- cool.
>
> We won't convince people to stop calling it "KDE 5" by introducing an awkward
> versioning scheme, but we can do that by properly adjusting our communication
> towards that. The distinction between Platform, Workspaces and Applications is
> more clear with our separated release cycles anyway, and perception of that
> will just make this topic easier.

A very massive big +1 to the above.
I never understood the choice of going for "2014.06" since the
reasoning didn't make much sense to me. What you said now makes
complete sense.

I do wonder though, why didn't you folks decide this on the plasma
sprint earlier this year?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Locale settings in Plasma Next

[Sebastian Kügler]

On Sunday, February 23, 2014 20:10:31 John Layt wrote:
> One question is when these changes to the envvars will get applied, and the 
> action required to apply them to the apps.  I believe Gnome forces you to
> log out and in again before the new envvars are applied.  In KDE4 you could
> simply restart individual apps, but to update Plasma itself you had to log
> out and in.  Do we update the envars as soon as the KCM changes are saved,
> which would allow apps to simply be restarted, or would that be considered
> dangerous for running apps that assume the envvars won't change, e.g. would
> something like glibc immediately pick up the change and return inconsistent
> results?

I'd say let's try writing out the envvars immediately, we'll see soon enough 
if things break. (Which to me would be application-level bugs, but if they're 
too bad, we might want to indirected the setting.)

John, you said that you started splitting the locale KCM already, is that work 
already available somewhere? I could put some time into trying to get it up to 
scratch for an initial release. (To me, right now, even disabling the locale 
KCM altogether is better than keeping it as-is.)

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [plasma-devel] Plasma 5?

[Jonathan Riddell]

Plasma 5 certainly makes it a lot easier to name betas.

It also means if the release date slips there's no need for a quick reversion.  
Frameworks want an extra beta so it may well slip.

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

Re: Plasma 5?

[Eike Hein]

On Monday 05 May 2014 15:55:27 Sebastian Kügler wrote:
> Hi all,
> 
> I am not happy with the 2014.6 name and naming scheme. There I said it.

I'm not either.

I think that going with the 5 scheme:

(a) Provides a nice continuity for users, packagers and developers,
who don't need to get used to a new way of managing versions.

(b) Has great synergy with Qt and Frameworks, simplifying our
messaging. It seems to be easy to take advantage of this
synergy since we're provided with the opportunity.

(c) Avoids confusion with the release names of a certain popular
distribution vendor.

(d) Avoids a lot of friction and uphill-battling against what
people already have in their heads.

I don't really see a case for the .MM scheme that convinces
me it offsets a-d.


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

Re: Plasma 5?

[Teo Mrnjavac]

On Monday, May 05, 2014 15:55:27 Sebastian Kügler wrote:
> Hi all,
> 
> I am not happy with the 2014.6 name and naming scheme. There I said it.
> 
> The reasons for this are multi-fold. First, and to me most importantly: It
> feels awkward. Now that might be because it's new, but it also feels like no
> one else is going to understand it.
> 
> My thinking goes towards an option that we had briefly discussed, and I
> think dismissed too quickly, and for the wrong reasons.
> 
> So, I'd like to get some feedback on the proposal to call the new Plasma
> release Plasma 5.0, and use the "old" version numbering scheme going
> forwards. That means after 5.0 comes 5.1, 5.2, and so on, same for minor
> releases (however that is going to end up being decided). This feedback can
> then be taken up with the promo and marketing department, I think that we
> should first make up our own minds (for that reason, no cross-post to
> kde-promo at this point).
> 
> The baseline, to use "Plasma" as the brand, and only refer to the version as
> a technicality should of course stay the same.
> 
> Why do I think 5 is better than 2014.6, or .?
> 
> - It communicates continuity: Plasma Next really is the continuation of 15+
> years of doing a desktop. It has our DNA all over it, and it's not a
> disconnected "today's thing". Especially to our existing userbase, and those
> just outside of it (other people known to Free desktops), this has a real
> meaning. It's something people love, and sometimes hate, and it's not a
> completely new thing. This is well in line with what we've been talking
> about all along for Plasma Next.
> 
> - It's trusted and proven: it works and will cause no problems with
> packaging, and comparing version number
> 
> - It solves a bunch of technical inconsistencies (plasmapkg2 vs kcmshell5 --
> why has one the 2 appended, the other 5?), library sonames are 5 as well.
> 
> - It indicates (like we did traditionally) that this is the 5th major
> version, building on a new Qt5, and Frameworks 5, we get to re-use that
> kind of consistency.
> 
> - To me, it feels just right. I know many others feel that 2014.6 is bad,
> and I've yet to hear somebody that really likes it (might be my limitation
> of course).
> 
> Now one of the reasons to not go for Plasma 5 was that "people would say
> that's KDE5, and we don't want that". To be honest, I stopped caring about
> that, if people want to call it KDE5, so be it, we'll call it Plasma 5 and
> do that consistently, as long as people understand what's talked about --
> cool.
> 
> We won't convince people to stop calling it "KDE 5" by introducing an
> awkward versioning scheme, but we can do that by properly adjusting our
> communication towards that. The distinction between Platform, Workspaces
> and Applications is more clear with our separated release cycles anyway,
> and perception of that will just make this topic easier.
> 
> 
> 
> 
> Take to kde-promo for further discussion

A big +1 to all of the above.

To me going with 2014.6 always felt like a compromise that few (if any) really 
like... IMO year.month doesn't add anything valuable in terms of branding, and 
it suggests a loss of continuity at a time where we should be comunicating 
that this is not a revolutionary change like KDE3->4.

Cheers,
-- 
Teo Mrnjavac
http://teom.org | t...@kde.org
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Breeze QML window decoration

[Martin Gräßlin]

On Sunday 04 May 2014 22:28:23 Andrew Lake wrote:
> Based on the design we came up with in the VDG forum, I completed a first
> go at doing up a Aurorae QML window decoration.
> 
> I added it to the 'working' branch of the Breeze repo. As far as I can tell
> it works about as well as the Plastik QML decoration.

some feedback after running the deco for most of today:
* in maximized state there is still a round corner in top left and top right
* I experience a slight flicker when mouse over buttons
* there's a config dialog (which looks like forked from Plastik) which is not 
updated in the deco? Maybe remove?
* Changing button sizes has no effect - this is important for accessibility

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Plasma 5?

[Sebastian Kügler]

Hi all,

I am not happy with the 2014.6 name and naming scheme. There I said it.

The reasons for this are multi-fold. First, and to me most importantly: It 
feels awkward. Now that might be because it's new, but it also feels like no 
one else is going to understand it.

My thinking goes towards an option that we had briefly discussed, and I think 
dismissed too quickly, and for the wrong reasons.

So, I'd like to get some feedback on the proposal to call the new Plasma 
release Plasma 5.0, and use the "old" version numbering scheme going forwards. 
That means after 5.0 comes 5.1, 5.2, and so on, same for minor releases 
(however that is going to end up being decided). This feedback can then be 
taken up with the promo and marketing department, I think that we should first 
make up our own minds (for that reason, no cross-post to kde-promo at this 
point).

The baseline, to use "Plasma" as the brand, and only refer to the version as a 
technicality should of course stay the same.

Why do I think 5 is better than 2014.6, or .?

- It communicates continuity: Plasma Next really is the continuation of 15+  
years of doing a desktop. It has our DNA all over it, and it's not a 
disconnected "today's thing". Especially to our existing userbase, and those 
just outside of it (other people known to Free desktops), this has a real 
meaning. It's something people love, and sometimes hate, and it's not a 
completely new thing. This is well in line with what we've been talking about 
all along for Plasma Next.

- It's trusted and proven: it works and will cause no problems with packaging, 
and comparing version number

- It solves a bunch of technical inconsistencies (plasmapkg2 vs kcmshell5 -- 
why has one the 2 appended, the other 5?), library sonames are 5 as well.

- It indicates (like we did traditionally) that this is the 5th major version, 
building on a new Qt5, and Frameworks 5, we get to re-use that kind of 
consistency.

- To me, it feels just right. I know many others feel that 2014.6 is bad, and 
I've yet to hear somebody that really likes it (might be my limitation of 
course).

Now one of the reasons to not go for Plasma 5 was that "people would say 
that's KDE5, and we don't want that". To be honest, I stopped caring about 
that, if people want to call it KDE5, so be it, we'll call it Plasma 5 and do 
that consistently, as long as people understand what's talked about -- cool. 

We won't convince people to stop calling it "KDE 5" by introducing an awkward 
versioning scheme, but we can do that by properly adjusting our communication 
towards that. The distinction between Platform, Workspaces and Applications is 
more clear with our separated release cycles anyway, and perception of that 
will just make this topic easier.




Take to kde-promo for further discussion


-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Breeze repo

[Aleix Pol]

On Mon, May 5, 2014 at 7:43 AM, Andrew Lake  wrote:

> I went ahead and added a 'working' branch and added the following:
>
> - Colors: This is the Breeze color scheme that has the both the style and
> the window decoration colors. I think this is releasable, so if there are
> no objections I'd like to move this over 'master' so it can ship in the
> june release, hopefully as the default color scheme.
> - Widget Style: I added the QtQuickControlsStyle that we recently
> completed and the QtCurve settings file.
> - Window Decoration: I added the newly implemented Aurorae QML window
> decoration and the current Aurorae SVG theme (which has a some buttons
> missing for now).
>
> My cmake foo is weak, so I may need some help to get some of these
> installed in the right locations.
>
> I might also need a little help getting a measure of goodenough(tm) that's
> appropriate for shipping in June as *optional*. i.e. installed but not
> default. I think the widget styles and the QML windec *might* be
> goodenough(tm) in that sense but I'm a little uncertain what I might not be
> thinking of. :-)
>
> Hope this helps,
> Andrew
>
>
> On Tue, Apr 29, 2014 at 3:32 AM, Marco Martin  wrote:
>
>> On Monday 28 April 2014 16:16:03 you wrote:
>> > So, following the discussion last week, i made a scratch called breeze
>> here:
>> > http://quickgit.kde.org/?p=scratch%2Fmart%2Fbreeze.git
>> >
>> > that at the moment has only the cursor theme.
>> >
>> > and opened a sysadmin ticket for the final repository location at
>> > kde/workspace/breeze.git
>>
>> Aaaan, is done
>> https://projects.kde.org/projects/kde/workspace/breeze
>>
>> right now it just contains the cursor theme (i would put also the
>> temporary
>> wallpaper we have in it)
>>
>> Andrew: I've put you as admin of the repo as well.
>>
>> People are encouraged to move in things that are in topic with it.
>>
>> only thing to pay attention, (I'm thinking about the kwin theme and
>> possibly
>> the qml style) since we are so near to the release, only things that we
>> are
>> sure that end up releasable for june should go in master.
>> what is still not sure, please put it in a branch, eventually merging it
>> in
>> master when goodenough (tm) ;)
>>
>> --
>> Marco Martin
>> ___
>> 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
>
>
Wouldn't it be better to have a branch for each? Otherwise you'll have to
merge them to master all at once.

Also, I wanted to test it and so it's missing some CMake to get things
installed. Do you need help with this?

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

Re: Review Request 117894: Add a kscreenlocker_test test application

[Martin Gräßlin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117894/
---

(Updated May 5, 2014, 1:19 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma, David Edmundson and Wolfgang Bauer.


Repository: plasma-workspace


Description
---

Add a kscreenlocker_test test application

The idea is to have a small test application for the screenlocker part
to test without having to restart ksmserver.


Diffs
-

  ksmserver/screenlocker/CMakeLists.txt 
700cdff95f46125952ab2503bb125c5b6cd3ce67 
  ksmserver/screenlocker/tests/CMakeLists.txt PRE-CREATION 
  ksmserver/screenlocker/tests/kscreenlocker_main.cpp PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/117894/diff/


Testing
---


Thanks,

Martin Gräßlin

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

Re: Review Request 117894: Add a kscreenlocker_test test application

[Commit Hook]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117894/#review57312
---


This review has been submitted with commit 
b762c3732bccc265fe24c57f6bda41b237324635 by Martin Gräßlin to branch master.

- Commit Hook


On April 30, 2014, 9:44 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117894/
> ---
> 
> (Updated April 30, 2014, 9:44 a.m.)
> 
> 
> Review request for Plasma, David Edmundson and Wolfgang Bauer.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Add a kscreenlocker_test test application
> 
> The idea is to have a small test application for the screenlocker part
> to test without having to restart ksmserver.
> 
> 
> Diffs
> -
> 
>   ksmserver/screenlocker/CMakeLists.txt 
> 700cdff95f46125952ab2503bb125c5b6cd3ce67 
>   ksmserver/screenlocker/tests/CMakeLists.txt PRE-CREATION 
>   ksmserver/screenlocker/tests/kscreenlocker_main.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/117894/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Breeze repo

[Marco Martin]

On Monday 05 May 2014, Andrew Lake wrote:
> Yay, thanks!
> 
> One thing I noticed, does the top level cmake include the Breeze color
> scheme? Both the controls style and the QML windec use the system color

gah, forgot it.
now should be ok :)


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

Re: Breeze repo

[Andrew Lake]

On May 5, 2014 5:55 AM, "Marco Martin" wrote:
> ok,
> so now everything is installed by the toplevel cmake, hopefully in the
proper
> place.

Yay, thanks!

One thing I noticed, does the top level cmake include the Breeze color
scheme? Both the controls style and the QML windec use the system color
scheme, so the visuals won't be quite complete without it.

Thanks again Marco!
Andrew
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 117894: Add a kscreenlocker_test test application

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117894/#review57311
---

Ship it!


Ship It!

- David Edmundson


On April 30, 2014, 9:44 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117894/
> ---
> 
> (Updated April 30, 2014, 9:44 a.m.)
> 
> 
> Review request for Plasma, David Edmundson and Wolfgang Bauer.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Add a kscreenlocker_test test application
> 
> The idea is to have a small test application for the screenlocker part
> to test without having to restart ksmserver.
> 
> 
> Diffs
> -
> 
>   ksmserver/screenlocker/CMakeLists.txt 
> 700cdff95f46125952ab2503bb125c5b6cd3ce67 
>   ksmserver/screenlocker/tests/CMakeLists.txt PRE-CREATION 
>   ksmserver/screenlocker/tests/kscreenlocker_main.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/117894/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Breeze repo

[Marco Martin]

On Monday 05 May 2014, Andrew Lake wrote:
> On May 5, 2014 4:32 AM, "Marco Martin" wrote:
> > On Monday 05 May 2014, Andrew Lake wrote:
> > > - Window Decoration: I added the newly implemented Aurorae QML window
> > > decoration and the current Aurorae SVG theme (which has a some buttons
> > > missing for now).
> > 
> > I am seeing a  "qml" folder with the actual aurorae decoration and an svg
> > folder with graphics, but no cmake to install it.
> > shouldn't be in the same package as the qml files?
> 
> No, actually those are two separate Auroras themes. One is the new
> QML-based theme - no svg, no C++. One is the old-style svg based theme
> we've been using on Plasma Current for quick validation. For Plasma Next
> the QML-based one is the target and is the most complete one right now.
> 
> Hope this helps,
> Andrew

ok,
so now everything is installed by the toplevel cmake, hopefully in the proper 
place.
one thing i see, the qt5 version of qtcurve doesn't have the configuration ui 
ported, so there is no obvious way to load the breeze preset (kde4 
systemsettings has to be used)
also i see even in the qt5 port there are still quite some kde4-isms


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

Re: Review Request 117839: [kglobalaccel] Update X11 appTime from key press events

[Commit Hook]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117839/#review57310
---


This review has been submitted with commit 
54287c8e37679d21a4b1ac34f51e0f9627f9834f by Martin Gräßlin to branch master.

- Commit Hook


On April 28, 2014, 1:47 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117839/
> ---
> 
> (Updated April 28, 2014, 1:47 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> [kglobalaccel] Update X11 appTime from key press events
> 
> KGlobalAccelD sends the current appTime through DBus to the application
> and KF5::GlobalAccel updates the appTime from the timestamp. This is
> needed for following actions to succeed. E.g. KWin needs the updated
> appTime for grabbing the keyboard following the kill window shortcut.
> 
> To get the current timestamp we just use the timestamp of the key press
> event delivered to kglobalacceld.
> 
> 
> Diffs
> -
> 
>   kglobalaccel/kglobalaccel_x11.cpp 454c62e17ac0fb188bbbf2bcefcf42241d7f4ec1 
> 
> Diff: https://git.reviewboard.kde.org/r/117839/diff/
> 
> 
> Testing
> ---
> 
> Tested with ctrl+alt+esc
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 117839: [kglobalaccel] Update X11 appTime from key press events

[Martin Gräßlin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117839/
---

(Updated May 5, 2014, 12:46 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Repository: plasma-workspace


Description
---

[kglobalaccel] Update X11 appTime from key press events

KGlobalAccelD sends the current appTime through DBus to the application
and KF5::GlobalAccel updates the appTime from the timestamp. This is
needed for following actions to succeed. E.g. KWin needs the updated
appTime for grabbing the keyboard following the kill window shortcut.

To get the current timestamp we just use the timestamp of the key press
event delivered to kglobalacceld.


Diffs
-

  kglobalaccel/kglobalaccel_x11.cpp 454c62e17ac0fb188bbbf2bcefcf42241d7f4ec1 

Diff: https://git.reviewboard.kde.org/r/117839/diff/


Testing
---

Tested with ctrl+alt+esc


Thanks,

Martin Gräßlin

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

i18n in Plasma [Was Re: Minutes Monday Plasma hangout]

[Martin Gräßlin]

On Monday 05 May 2014 13:10:44 Sebastian Kügler wrote:
>   - Discovered problems in Kwin and Plasma localization (to be discussed on
> mailinglist)

ok, so with frameworks i18n changed a bit. I highly recommend to read the 
documentation in [1].

Things to be done are:
* set KLocalizedString::setApplicationDomain [2] in the application, never in 
libs
* for libraries (this includes plugins!) set in CMakeLists.txt:
   add_definitions(-DTRANSLATION_DOMAIN=\"nameofcatalog\")
   for an example see [3]
* for ui files one needs to use ki18n_wrap_ui - for an example also see [3]
* ensure that every component has Messages.sh

Things I do not know yet:
* how to handle qml, this also needs the translation domain, but no idea how 
to set it.
* how to handle ui files which are loaded at runtime
* how to test an application with translations

After adjusting KWin I have a bad feeling that we have to audit all components 
for i18n usage. Everything will need adjustments, especially the plugins. 
Though this should be said: it's way simpler and more intuitive than it used 
to be in kde4.

Cheers
Martin

[1] 
http://api.kde.org/frameworks-api/frameworks5-apidocs/ki18n/html/prg_guide.html
[2] 
http://api.kde.org/frameworks-api/frameworks5-apidocs/ki18n/html/classKLocalizedString.html#ad866b11bf396b9d93b7dc313a1930b7b
[3] http://commits.kde.org/kwin/1c2f27945c8c50612a75cec6cb773a710b6fad15

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 112208: KMix qml applet

[Sebastian Kügler]

> On March 22, 2014, 11:09 p.m., Mark Gaiser wrote:
> > Is there still an intention on getting this in KDE 4.xx?
> > Just wondering since it seems to be much better then the current kmix popup.
> 
> Christian Esken wrote:
> I also haven't heard about further development here. Diego as original 
> submitter or somebody else would have to push this. I added this as a topic 
> for the KDE Multimedia Sprint. It takes place in about 4 months (August 
> 2014): https://sprints.kde.org/sprint/212
> 
> Diego Casella wrote:
> My bad, sorry guys but I'm still in a busy period of my life :/
> I'll try to fix the remaining issues pointed out in this review request, 
> and then submit the changes here.
> There is still an ongoing (and BIG imho) issue anyway: we really really 
> really need a Plasma QML callback to capture mouse scroll events. AFAIK there 
> still isn't in both Plasma 4.13 and also Plasma Next. And talking about kmix 
> applet, one feature everyone is using is the ability to adjust volume level 
> with just few mouse scrolls over the applet icon.
> I think we need to fix this problem as well, what do you think?
> 
> Christian Esken wrote:
> Yes, most definitely we should have mouse scroll events. I guess 
> everybody is using it on the tray icon and in the main window, and so it 
> should also be there for the applet.
> But if users can choose the plasmoid as an optional, then this is not a 
> showstopper. It is probably better to get it started as is. We could mark it 
> "early-access", so interested people can start playing around with it and 
> using it.
> 
> Mark Gaiser wrote:
> Quote: "There is still an ongoing (and BIG imho) issue anyway: we really 
> really really need a Plasma QML callback to capture mouse scroll events"
> Seriously?
> 
> I never ever used the scrolling on the tray icon itself. I didn't even 
> know it was possible till you said it in this post.
> But please don't let such a minor issue block your progress :)
> 
> Clicking the icon or using the media keys on most keyboards is probably 
> enough possibilities for people change the volume. Scrolling on the icon is 
> imho just bonus stuff.
> 
> Martin Klapetek wrote:
> > Clicking the icon or using the media keys on most keyboards is probably 
> enough possibilities for people change the volume. Scrolling on the icon is 
> imho just bonus stuff.
> 
> I use it extensively and every new user I put on Plasma, that's one of 
> the first things I teach them. It's much more convenient because ~80% of the 
> time you're holding your mouse in your hand and ~95% of the time you have 
> your eyes on the screen. Going for keyboard button means in many cases taking 
> your eyes off the screen and looking at the exact button position, often you 
> even have to let the mouse go and move your hand to keyboard (for example 
> YouTube video/any other media being too loud).
> 
> Mark Gaiser wrote:
> But you can do it all with your mouse.
> 1. Click the icon
> 2. move your cursor to the stream (or master channel).
> 3. scroll...
> 
> Just to be sure, scrolling (as i described in the steps above) works in 
> this proposed component, right?
> All that's not working is scrolling on the tray icon, correct?
> 
> Note: I happen to have a keyboard without media keys. I always click the 
> icon and scroll on the stream where i want to change the sound level.
> 
> Martin Klapetek wrote:
> Sure you can, it's just way easier to simply scroll on an icon than 
> opening this -> http://i.imgur.com/LcyFzq6.png and identifying the channel 
> you need to change (the assumption being that you want to change only the 
> main volume, not per stream controls). That way you're doing the visual 
> identification twice - first locating the systray icon, , now locating 
> the proper handle. So doing it that way is mentally harder task than simply 
> scroll the icon, which also saves you a click ;)
> 
> Diego Casella wrote:
> @Mark Gaiser: volume change on scroll is a very, very, handy and smart 
> feature (Martin's answer sums up everything nicely): it would be a pity if we 
> lose it because of a lack in the Plasma QML bindings. By the way, an other 
> plasma applet which uses such feature is, for example, the clock applet: it 
> uses mouse scrolls to loop between timezones (if selected by the user), which 
> is handy for example to check the UTC time before an IRC meeting ;)
> Besides, you're the first person who _wasn't_ aware of that feature :P
> As last resort, if we can't come up with a proper solution to whether add 
> this feature back or not, I could blog about it and open a poll to planetkde 
> readers, in order to collect as much feedbacks as possible, what do you think?
> 
> Mark Gaiser wrote:
> Quote: "By the way, an other plasma applet which uses such feature is, 
> for example, the clock applet: it uses mouse scrolls to loop between 

Re: Breeze repo

[Andrew Lake]

On May 5, 2014 4:32 AM, "Marco Martin" wrote:
>
> On Monday 05 May 2014, Andrew Lake wrote:
> > - Window Decoration: I added the newly implemented Aurorae QML window
> > decoration and the current Aurorae SVG theme (which has a some buttons
> > missing for now).
>
> I am seeing a  "qml" folder with the actual aurorae decoration and an svg
> folder with graphics, but no cmake to install it.
> shouldn't be in the same package as the qml files?

No, actually those are two separate Auroras themes. One is the new
QML-based theme - no svg, no C++. One is the old-style svg based theme
we've been using on Plasma Current for quick validation. For Plasma Next
the QML-based one is the target and is the most complete one right now.

Hope this helps,
Andrew
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 117995: [screenlocker] Add a unit test for KSldApp

[Martin Gräßlin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117995/
---

Review request for Plasma and David Edmundson.


Repository: plasma-workspace


Description
---

[screenlocker] Add a unit test for KSldApp

The unit test so far only tests establishGrab. This is a little bit
tricky as we need a different X Client which grabs pointer or keyboard
to make establishGrab fail. For that two small helper applications are
included which do nothing else than connecting to X and the one grabbing
keyboard the other grabbing pointer.

The applications are started from the test to get the keyboard/pointer
grabbed which results in ::establishGrab to return false.

What this test is not yet able to test is handling the sleep between two
grab attemps.


Diffs
-

  ksmserver/screenlocker/autotests/CMakeLists.txt 
ff95d9d031cdac32085e358e30b95a9e9a6fb7dc 
  ksmserver/screenlocker/autotests/keyboardgrabber.cpp PRE-CREATION 
  ksmserver/screenlocker/autotests/ksldtest.cpp PRE-CREATION 
  ksmserver/screenlocker/autotests/pointergrabber.cpp PRE-CREATION 
  ksmserver/screenlocker/ksldapp.h 958b55c1ff83e21d57e3c1dfb812016f325046be 

Diff: https://git.reviewboard.kde.org/r/117995/diff/


Testing
---


Thanks,

Martin Gräßlin

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

Re: Breeze repo

[Marco Martin]

On Monday 05 May 2014, Andrew Lake wrote:
> - Window Decoration: I added the newly implemented Aurorae QML window
> decoration and the current Aurorae SVG theme (which has a some buttons
> missing for now).

I am seeing a  "qml" folder with the actual aurorae decoration and an svg 
folder with graphics, but no cmake to install it.
shouldn't be in the same package as the qml files?

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

Re: Review Request 117839: [kglobalaccel] Update X11 appTime from key press events

[Àlex Fiestas]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117839/#review57299
---

Ship it!


Code looks good.

- Àlex Fiestas


On April 28, 2014, 1:47 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117839/
> ---
> 
> (Updated April 28, 2014, 1:47 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> [kglobalaccel] Update X11 appTime from key press events
> 
> KGlobalAccelD sends the current appTime through DBus to the application
> and KF5::GlobalAccel updates the appTime from the timestamp. This is
> needed for following actions to succeed. E.g. KWin needs the updated
> appTime for grabbing the keyboard following the kill window shortcut.
> 
> To get the current timestamp we just use the timestamp of the key press
> event delivered to kglobalacceld.
> 
> 
> Diffs
> -
> 
>   kglobalaccel/kglobalaccel_x11.cpp 454c62e17ac0fb188bbbf2bcefcf42241d7f4ec1 
> 
> Diff: https://git.reviewboard.kde.org/r/117839/diff/
> 
> 
> Testing
> ---
> 
> Tested with ctrl+alt+esc
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Fwd: [kconfig] src/core: Store app config file in ~/.config//rc

[Sebastian Kügler]

On Monday, May 05, 2014 11:13:31 Marco Martin wrote:
> On Sunday 04 May 2014, David Faure wrote:

> > please note this change in KConfig.
> >
> > I would recommend making sure your applications call
> > app.setOrganizationDomain("kde.org") so that the config files go into the
> > right subdir right now. Otherwise you'll face migration issues later when
> > setting that.
> 
> In plasma 3 config files are used, plasmarc, plasma_shellrc,
> plasma-shellname- appletsrc (like plasma-org.kde.desktop-appletsrc)

And kickoffrc. This is fairly isolated in the codebase, though. if David's 
patch goes in, I'll put it on my list to change.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Minutes Monday Plasma hangout

[Sebastian Kügler]

On Monday, May 05, 2014 12:30:15 Ivan Čukić wrote:
> Ivan:
> - Resource linking is almost back. A few kinks to work out. Will be merged
> after the first release of kf5.
> 
> Cheerio,
> Ivan
> 
> p.s. I'm not properly online to join in the hangout :/

Thanks for prenatal and proactive hijacking of this thread! Here goes the 
rest:

Plasma Meeting 05-05-2015

Present: David, Jens, Marco, Martin G., Martin K., Sebastian, Aleix, Alex,

Jens:
  - The mythical Andrew has done mythical work on windecos, in a branch in 
kde:breeze
  - Work on icon theme starts, we'd like it packaged so it can be tested 
easily
  - Some communication strategy around branding and user feedback
  - Worked on OSD icons together with Martin Klapetek

Marco:
  - Breeze repo is up, receiving artwork-related work (cursor theme already in 
there, QML style coming up, Arorae style coming up)
  - New splash screen is merged
  - Working on bugfixes
  - More work on Plasma::Dialog improvements

Aleix:
  - Started working on port of libkscreen patches for Plasma (Qt API is 
lacking for screen management)

Alex:
  - Ported libkscreen to XCB, to continue this week
  - Works on Solid::PowerManagement (release blocker for frameworks)
  - Tracking down crash in favicon kded
  
Martin Grässlin:
  - Mouse interaction with Arorae theme is fixed
  - XCB porting in kwin
  - Audited screenlocker code, worked on some simplification and unit tests
  - Fixed crasher in windowthumbnails
  - Discovered problems in Kwin and Plasma localization (to be discussed on 
mailinglist)
  - Important fix to kglobalaccel needs review: 
https://git.reviewboard.kde.org/r/117839/
  
Martin Klapetek:
  - Finished notifications patch for memory usage improvement
  - investigated bug with new panels overlapping
  - Panel struts patch coming up

David:
  - Worked on various bugfixes and SDDM improvements
  - Working on SDDM
- work on not running too much stuff as root
- SDDM and lockscreen theme
  - QtQuickControls layout improvements
 
Sebastian:
  - Fixed up fontinst KCM, font installation and deinstallation now worked in 
my tests (port was incomplete)
  - Worked on resizing Plasma panel popups: basically works, few bugs (also 
uncovers bad minimum- vs. preferred sizes, fixing those as well
  - Will also work on Kickoff bugs

-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 117839: [kglobalaccel] Update X11 appTime from key press events

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117839/#review57298
---


maybe add kdeframeworks group?

- Marco Martin


On April 28, 2014, 1:47 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117839/
> ---
> 
> (Updated April 28, 2014, 1:47 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> [kglobalaccel] Update X11 appTime from key press events
> 
> KGlobalAccelD sends the current appTime through DBus to the application
> and KF5::GlobalAccel updates the appTime from the timestamp. This is
> needed for following actions to succeed. E.g. KWin needs the updated
> appTime for grabbing the keyboard following the kill window shortcut.
> 
> To get the current timestamp we just use the timestamp of the key press
> event delivered to kglobalacceld.
> 
> 
> Diffs
> -
> 
>   kglobalaccel/kglobalaccel_x11.cpp 454c62e17ac0fb188bbbf2bcefcf42241d7f4ec1 
> 
> Diff: https://git.reviewboard.kde.org/r/117839/diff/
> 
> 
> Testing
> ---
> 
> Tested with ctrl+alt+esc
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Minutes Monday Plasma hangout

[Ivan Čukić]

Ivan:
- Resource linking is almost back. A few kinks to work out. Will be merged 
after the first release of kf5.

Cheerio,
Ivan

p.s. I'm not properly online to join in the hangout :/


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

Re: Review Request 117813: Make the system tray faster

[Martin Klapetek]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117813/#review57296
---

Ship it!



applets/systemtray/package/contents/ui/StatusNotifierItem.qml


This could be removed, sebas said



applets/systemtray/package/contents/ui/TaskDelegate.qml


This is used (remove the fixme)



applets/systemtray/plugin/host.cpp


Remove this please, it adds nothing useful to the output


- Martin Klapetek


On May 2, 2014, 6:10 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117813/
> ---
> 
> (Updated May 2, 2014, 6:10 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Port QQmlListProperty to QAbstractListModel.
> QQmlListProperty only has a signal that the list has changed.This means when 
> used in a ListView every delegate has to be redone whenever a single item is 
> inserted or removed rather than just moved.
> 
> Given TaskDelegate is not the simplest of things this has a performance gain, 
> most noticeably on startup. Also rather than sorting all items after an 
> insert items are inserted in the right place using qLowerBound. Now we have 
> the correct signals we can remove the compression, they won't add anything. 
> 
> 
> Other commits:
> 
> Avoid constructing a QString for comparing, use QLatin1String for == 
> operators.
> 
> Remove useless include
> 
> Do not construct a map inside a lessThan function
> 
> lessThan functions have to be fast.
> Also Map -> Hash as we're not using order here.
> 
> 
> Diffs
> -
> 
>   applets/systemtray/package/contents/ui/CompactRepresentation.qml 01308e7 
>   applets/systemtray/package/contents/ui/ExpandedRepresentation.qml 646b908 
>   applets/systemtray/package/contents/ui/PlasmoidItem.qml 0eb1687 
>   applets/systemtray/package/contents/ui/StatusNotifierItem.qml fc889a8 
>   applets/systemtray/package/contents/ui/TaskDelegate.qml 913d8f1 
>   applets/systemtray/package/contents/ui/TaskListDelegate.qml 5501e02 
>   applets/systemtray/package/contents/ui/main.qml d1a6851 
>   applets/systemtray/plugin/CMakeLists.txt f6e23b4 
>   applets/systemtray/plugin/host.h 02c5bbe 
>   applets/systemtray/plugin/host.cpp eafd0b6 
>   applets/systemtray/plugin/task.h 68dcd12 
>   applets/systemtray/plugin/task.cpp 1f8e3ca 
>   applets/systemtray/plugin/tasklistmodel.h PRE-CREATION 
>   applets/systemtray/plugin/tasklistmodel.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/117813/diff/
> 
> 
> Testing
> ---
> 
> Seems to work :)
> 
> see branch davidedmundson/faster_systray to test
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: Fwd: [kconfig] src/core: Store app config file in ~/.config//rc

[Marco Martin]

On Monday 05 May 2014, David Faure wrote:
> > does KSharedConfig::openConfig("confignamerc") now tries in ~/.config or
> > in ~/.config/kde.org ? (supposing the domain is set)
> 
> I reverted the change for now.

ok, so i will delay any local change in plasma

> Let's discuss whether the alternative is
> better

so, the choice if i understood correctly is basically between:

defaulting to use the domain in KSharedConfig::openConfig("confignamerc") that 
would probably be faster porting, *but* risking to break all uses of 
kdeglobals and the like,

or not use the domain in this case, *but* risks to break all openconfig of a 
filename (that is not intended to be a global one) right?

i don't see much painless ways..
almost seems to call for another method like "openGlobalConfig()" or something 
like that, like the flag but even more explicit.
would perhaps be less confusing, but a bit late to be any painless never the 
less...

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

Re: Review Request 117946: Track screen changes in the containment when the containment is inside an applet

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117946/
---

(Updated May 5, 2014, 9:39 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

Track screen changes in the containment when the containment is inside an applet

Make the system tray containment update which screen it is on when the
system tray applet is moved.

This fixes notifications if the panel is moved between screens.


Diffs
-

  src/plasma/private/containment_p.h 24049c7 
  src/plasma/private/containment_p.cpp 9e67382 

Diff: https://git.reviewboard.kde.org/r/117946/diff/


Testing
---


Thanks,

David Edmundson

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

Re: Review Request 117946: Track screen changes in the containment when the containment is inside an applet

[Commit Hook]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117946/#review57294
---


This review has been submitted with commit 
873106a7ca4ff8f15e823b1019b4f5b66332867a by David Edmundson to branch master.

- Commit Hook


On May 2, 2014, 2:42 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117946/
> ---
> 
> (Updated May 2, 2014, 2:42 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Track screen changes in the containment when the containment is inside an 
> applet
> 
> Make the system tray containment update which screen it is on when the
> system tray applet is moved.
> 
> This fixes notifications if the panel is moved between screens.
> 
> 
> Diffs
> -
> 
>   src/plasma/private/containment_p.h 24049c7 
>   src/plasma/private/containment_p.cpp 9e67382 
> 
> Diff: https://git.reviewboard.kde.org/r/117946/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: Fwd: [kconfig] src/core: Store app config file in ~/.config//rc

[David Faure]

On Monday 05 May 2014 11:13:31 Marco Martin wrote:
> On Sunday 04 May 2014, David Faure wrote:
> > Hello,
> > 
> > please note this change in KConfig.
> > 
> > I would recommend making sure your applications call
> > app.setOrganizationDomain("kde.org") so that the config files go into the
> > right subdir right now. Otherwise you'll face migration issues later when
> > setting that.
> 
> In plasma 3 config files are used, plasmarc, plasma_shellrc,
> plasma-shellname- appletsrc (like plasma-org.kde.desktop-appletsrc)
> 
> so i guess all 3 files should go under kde.org subdirectory.
> 
> configuration files are now open from different places in different ways, so
> i guess it will take a bit of doublechecking to see it always searches for
> the correct ones.
> 
> does KSharedConfig::openConfig("confignamerc") now tries in ~/.config or in
> ~/.config/kde.org ? (supposing the domain is set)

I reverted the change for now. Let's discuss whether the alternative is better 
:)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

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

Re: Fwd: [kconfig] src/core: Store app config file in ~/.config//rc

[Marco Martin]

On Sunday 04 May 2014, David Faure wrote:
> Hello,
> 
> please note this change in KConfig.
> 
> I would recommend making sure your applications call
> app.setOrganizationDomain("kde.org") so that the config files go into the
> right subdir right now. Otherwise you'll face migration issues later when
> setting that.

In plasma 3 config files are used, plasmarc, plasma_shellrc, plasma-shellname-
appletsrc (like plasma-org.kde.desktop-appletsrc)

so i guess all 3 files should go under kde.org subdirectory.

configuration files are now open from different places in different ways, so i 
guess it will take a bit of doublechecking to see it always searches for the 
correct ones.

does KSharedConfig::openConfig("confignamerc") now tries in ~/.config or in 
~/.config/kde.org ? (supposing the domain is set)


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

Re: Re: Breeze QML window decoration

[Martin Gräßlin]

On Monday 05 May 2014 10:33:33 Marco Martin wrote:
> On Monday 05 May 2014, Martin Gräßlin wrote:
> > On Sunday 04 May 2014 22:28:23 Andrew Lake wrote:
> > > Based on the design we came up with in the VDG forum, I completed a
> > > first
> > > go at doing up a Aurorae QML window decoration.
> > > 
> > > I added it to the 'working' branch of the Breeze repo. As far as I can
> > > tell it works about as well as the Plastik QML decoration.
> > > 
> > > Quick screenshot: http://wstaw.org/m/2014/05/05/QMLsnapshot.png
> > 
> > I'll give it a try with my KWin maintainer hat on :-)
> > 
> > FYI: I just pushed some important bug fixes for Aurorae - the mouse
> > interaction is fixed \o/
> 
> btw, if you can push in a branch a very basic c++ one, me and hopefully
> others can finish it.
> (i am not sure what is the minimum amount of stuff to reimplement, can also
> be tried to start from oxygen, but there may be too much stuff to
> dismantle)

Oxygen is probably a bad place to start, it's doing too much.

I can try to schedule some time to look at the QML base and try to come up 
with a good C++ design for it. Probably not this week as I want to spend time 
on the screenlocker.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Breeze QML window decoration

[Marco Martin]

On Monday 05 May 2014, Martin Gräßlin wrote:
> On Sunday 04 May 2014 22:28:23 Andrew Lake wrote:
> > Based on the design we came up with in the VDG forum, I completed a first
> > go at doing up a Aurorae QML window decoration.
> > 
> > I added it to the 'working' branch of the Breeze repo. As far as I can
> > tell it works about as well as the Plastik QML decoration.
> > 
> > Quick screenshot: http://wstaw.org/m/2014/05/05/QMLsnapshot.png
> 
> I'll give it a try with my KWin maintainer hat on :-)
> 
> FYI: I just pushed some important bug fixes for Aurorae - the mouse
> interaction is fixed \o/

btw, if you can push in a branch a very basic c++ one, me and hopefully others 
can finish it.
(i am not sure what is the minimum amount of stuff to reimplement, can also be 
tried to start from oxygen, but there may be too much stuff to dismantle)

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

Re: Breeze repo

[Marco Martin]

On Monday 05 May 2014, Andrew Lake wrote:
> I went ahead and added a 'working' branch and added the following:
> 

later i'll check and see to make everything built and installed

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

Re: Fwd: [kconfig] src/core: Store app config file in ~/.config//rc

[David Faure]

On Monday 05 May 2014 08:29:07 Martin Gräßlin wrote:
> On Monday 05 May 2014 08:17:49 David Faure wrote:
> > On Monday 05 May 2014 07:25:37 Martin Gräßlin wrote:
> > > On Sunday 04 May 2014 23:53:40 David Faure wrote:
> > > > Hello,
> > > > 
> > > > please note this change in KConfig.
> > > > 
> > > > I would recommend making sure your applications call
> > > > app.setOrganizationDomain("kde.org") so that the config files go into
> > > > the
> > > > right subdir right now. Otherwise you'll face migration issues later
> > > > when
> > > > setting that.
> > > 
> > > How does that affect setting configuration from a kcm? E.g. if loaded
> > > through systemsettings one could assume that setOrganizationDomain is
> > > set
> > > to "kde.org" which could break any kcm needing another organization
> > > domain.
> > > Or if a KCM sets this to foo.bar than any kcm not resetting to kde.org
> > > would break, wouldn't it?
> > 
> > I doubt KCMs use KSharedConfig::openConfig() or KConfig() without
> > arguments. That would lead to "kcmshell5rc" or "systemsettingsrc" right
> > now.
> > Instead they surely name the config file they want to edit.
> > 
> > If that config file happens to be for a specific application (rather than
> > shared), then the KCM will need to open e.g. "kde.org/konquerorrc" instead
> > of "konquerorrc", indeed.
> 
> Yes, that's what I mean. E.g. in KWin our kcms do:
> KSharedConfig::openConfig("kwin");
> 
> while in KWin it might be possible that we do:
> KSharedConfig::openConfig();
> 
> (though I think most use KSharedConfig::openConfig())
> 
> which would result in breakage if we forget to adjust one.
> 
> Thus it looks to me that we need to verify each and every KConfig and
> KSharedConfig::openConfig call and also kcfg files, right?

Right.

I just thought about an alternative:

KConfig defaults to "/" for all config files including the 
named ones, but gains a flag "NoOrganizationDomain" which we'd have to use for 
files that are shared between applications, such as kdeglobals, kdebugrc, 
trashrc, servicetype_profilerc, kbookmarkrc, emaildefaults, kwalletrc, etc. 
Anything that is opened by a framework or other general-purpose libraries 
needs that flag, otherwise apps with a different org domain wouldn't find 
them.
At best, for cleanliness, libs can hardcode a prefix such as kde.org, but they 
can't rely on the value of organizationDomain.

Maybe this way around is less work indeed. I'm not sure. The risk for 
undetected breakages is higher (since we'd only notice it when running an app 
with a different org domain). Kate will end up being the perfect test app for 
this, with its kate-editor.org domain :-)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 117900: Cleanup of screenlocker

[Martin Gräßlin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117900/
---

(Updated May 5, 2014, 9 a.m.)


Review request for Plasma and David Edmundson.


Changes
---

changed the grabKeyboard and grabMouse to not be a lambda.


Repository: plasma-workspace


Description
---

[screenlocker] Remove saverLockReady from org.kde.screensaver interface

Wasn't implemented.

[screenlocker] Remove setupPlasma from org.kde.screensaver interface

We don't have the plasma-overlay anymore, so let's remove it.

[screenlocker] Remove boolean trap in ::lock

Use an enum value to indicate whether there's an immediate or a delayed
lock. At the same time lock is no longer a slot.

[screenlocker] Remove lock slot without argument

Replace by lambda slot which delegates to lock(true).

[screenlocker] Turn idleTimeout slot into lambda slot

Code is only and should only be executed after the timeoutReached signal
from KIdleTime. Using a lambda slot enforces that as well as adding
compile time checking for connect syntax.

[screenlocker] Turn lockProcessReady slot into a lambda slot

Code should only be executed in reply to signal
QProcess::readyReadStandardOutput. From anywhere else it would have been
wrong. By using a lambda slot this gets enforces and the connection gets
compile time checked.

[screenlocker] Turn lockProcessFinished slot into a lambda slot

LockProcessFinished should only be invoked when the QProcess::finished
signal fired. Right now it was possible to invoke that from other code
paths. By turning it into a lambda slot this becomes more clear and we
get compile time checking for the connection.

[screenlocker] Turn KSldApp::grabKeyboard and ::grabMouse into lambdas

It's only used by ::establishGrab and shouldn't be used from anywhere
else. To make this more clear the code is moved into lambda functions
in ::establishGrab.

[screenlocker] Move sanity checks for lockGrace to kcfg

Kcfg provides min/max values, so we don't need the qBound in source code
side.

[screenlocker] Remove not needed includes

Instead of using QDesktopWidget to get the id of the X11 rootWindow we
just ask QX11Info.


Diffs (updated)
-

  ksmserver/screenlocker/dbus/org.kde.screensaver.xml 
e700b88215973f11b2601e5d164371874d262580 
  ksmserver/screenlocker/interface.h 97a60737632e1cd799c0a1b09cc73ab4b580d757 
  ksmserver/screenlocker/interface.cpp 0ce68c0d0d8aaf41588d5b5e73e66aa1b6320d15 
  ksmserver/screenlocker/kcfg/kscreensaversettings.kcfg 
6a1cbb0935461c8045dd847a63e31e72fb6ca007 
  ksmserver/screenlocker/ksldapp.h 958b55c1ff83e21d57e3c1dfb812016f325046be 
  ksmserver/screenlocker/ksldapp.cpp c678cfc33f82509776047894e46c4fbe15563d49 

Diff: https://git.reviewboard.kde.org/r/117900/diff/


Testing
---


Thanks,

Martin Gräßlin

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