Re: Review Request 123846: Enable translations for devicenotifications dataengine

[Burkhard Lück]

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

Ship it!


Thanks

- Burkhard Lück


On Mai 18, 2015, 11:21 nachm., Luigi Toscano wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123846/
> ---
> 
> (Updated Mai 18, 2015, 11:21 nachm.)
> 
> 
> Review request for Localization and Translation (l10n) and Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> The patch should be quite straightforward, but see below.
> 
> If correct, can I apply it to Plasma/5.3 as well? Allowing translations of 
> previously untranslatable strings does not break the string freeze.
> 
> 
> Diffs
> -
> 
>   dataengines/devicenotifications/CMakeLists.txt 0b89b5e 
>   dataengines/devicenotifications/Messages.sh PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/123846/diff/
> 
> 
> Testing
> ---
> 
> I could not test it, sorry, but I had to report it before forgetting.
> 
> 
> Thanks,
> 
> Luigi Toscano
> 
>

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

Re: Plasma 5 is awesome...and some help required with build instructions

[Siddhartha]

On 18 May 2015 at 22:58, David Edmundson  wrote:

> Just setting up on a new machine and thought I'd try following these
> instructions exactly, the way a new developer would.
>
> I got stuck on something I don't know how to solve.
>
> Under Kubuntu because Qt is compiled with a hardcoded plugindir for some
> reason.
> This means setting QT_PLUGIN_PATH env variables does nothing, which means
> you'll always be loading any plugins from /usr/ rather than the ones we
> just built.
>
> How did you get round that? Any ideas?
>

By using Arch Linux? :P

I did not do anything special in this regard, so I guess on my system
QT_PLUGIN_PATH is being picked up properly.

Btw, you commented out QTDIR in the wiki script, so a few of the later
variables will have weird paths (QTDIR/plugins=/plugins)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 123846: Enable translations for devicenotifications dataengine

[Luigi Toscano]

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

Review request for Plasma.


Repository: plasma-workspace


Description
---

The patch should be quite straightforward, but see below.

If correct, can I apply it to Plasma/5.3 as well? Allowing translations of 
previously untranslatable strings does not break the string freeze.


Diffs
-

  dataengines/devicenotifications/CMakeLists.txt 0b89b5e 
  dataengines/devicenotifications/Messages.sh PRE-CREATION 

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


Testing
---

I could not test it, sorry, but I had to report it before forgetting.


Thanks,

Luigi Toscano

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

Re: Plasma 5 is awesome...and some help required with build instructions

[Aleix Pol]

On Mon, May 18, 2015 at 8:07 PM, David Edmundson
 wrote:
>
>
> On Mon, May 18, 2015 at 7:05 PM, Aleix Pol  wrote:
>>
>> On Mon, May 18, 2015 at 7:28 PM, David Edmundson
>>  wrote:
>> > Just setting up on a new machine and thought I'd try following these
>> > instructions exactly, the way a new developer would.
>> >
>> > I got stuck on something I don't know how to solve.
>> >
>> > Under Kubuntu because Qt is compiled with a hardcoded plugindir for some
>> > reason.
>> > This means setting QT_PLUGIN_PATH env variables does nothing, which
>> > means
>> > you'll always be loading any plugins from /usr/ rather than the ones we
>> > just
>> > built.
>> >
>> > How did you get round that? Any ideas?
>> >
>> > David
>> >
>> > ___
>> > Plasma-devel mailing list
>> > Plasma-devel@kde.org
>> > https://mail.kde.org/mailman/listinfo/plasma-devel
>> >
>>
>> On Kubuntu, you probably want to enable KDE_INSTALL_USE_QT_SYS_PATHS
>> cmake option.
>
>
> but that will install to /usr
>
>
>>
>> Aleix
>> ___
>> 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
>

That's the downside, yes.

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

Re: Planning merging the single qqml engine

[Ivan Čukić]

> The ironic thing here is that something would have to be introduced
> that will be deprecated

Not really. It would deprecate the old qml engine per plasmoid.

It is not about deprecating the opt-in thing. The ideal is to achieve
100% opt-in, that is, for all plugins to eventually get the
SingleEngine requirement.

Cheers,
Ivan


On 18 May 2015 at 22:51, Mark Gaiser  wrote:
> On Mon, May 18, 2015 at 9:53 PM, Marco Martin  wrote:
>>
>> On Monday 18 May 2015, Mark Gaiser wrote:
>> > Anyway, with that attribute you let the applet developer OPT-IN in for
>> > shared engine. Setting that attribute can be easily forgotten. If
>> > anything,
>> > they should OPT-OUT thus by default use the shared engine.
>> > Perhaps a attribute like this is more appropriate?:
>> > X-Plasma-RequiresOwnQmlEngine=true
>> >
>> > or something alike.
>> >
>> > I'd definitely go for OPT-OUT (defaults = use shared engine).
>>
>> no, because the key here is retrocompatibility, old applets have to work
>> as
>> is.
>> it's true that this makes it error prone, but that's the ugly need :/
>> otherwise there wouldn't be any reason for supporting both modes
>
>
> While that - on it's own - is a very nice goal, sometimes you just have new
> developments that are clearly better and the way forward. This is one such
> case. Sure, you want to keep compatibility, but you should also strongly
> motivate those that develop applets to use the shared engine.
>
> Ivan's idea of deprecating it and clearly letting the user know might be a
> good compromise here. The ironic thing here is that something would have to
> be introduced that will be deprecated from the beginning. Something sounds
> wrong about that :)
>
> ___
> 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: Planning merging the single qqml engine

[Mark Gaiser]

On Mon, May 18, 2015 at 9:53 PM, Marco Martin  wrote:

> On Monday 18 May 2015, Mark Gaiser wrote:
> > Anyway, with that attribute you let the applet developer OPT-IN in for
> > shared engine. Setting that attribute can be easily forgotten. If
> anything,
> > they should OPT-OUT thus by default use the shared engine.
> > Perhaps a attribute like this is more appropriate?:
> > X-Plasma-RequiresOwnQmlEngine=true
> >
> > or something alike.
> >
> > I'd definitely go for OPT-OUT (defaults = use shared engine).
>
> no, because the key here is retrocompatibility, old applets have to work as
> is.
> it's true that this makes it error prone, but that's the ugly need :/
> otherwise there wouldn't be any reason for supporting both modes


While that - on it's own - is a very nice goal, sometimes you just have new
developments that are clearly better and the way forward. This is one such
case. Sure, you want to keep compatibility, but you should also strongly
motivate those that develop applets to use the shared engine.

Ivan's idea of deprecating it and clearly letting the user know might be a
good compromise here. The ironic thing here is that something would have to
be introduced that will be deprecated from the beginning. Something sounds
wrong about that :)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Planning merging the single qqml engine

[Marco Martin]

On Monday 18 May 2015, Kai Uwe Broulik wrote:
> What I found interesting that you changed import "plasmapkg:/code/logic.js"
> to import "logic.js" although the qml file is in a different folder, why
> does that work?

since it can still figure out the package, the url interceptor takes js files 
from code/ and images from images/
on that the behavior didn't change, it was already rewriting paths like that


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

Re: Planning merging the single qqml engine

[Kai Uwe Broulik]

Hi,

> That's running:
> kdeclarative - your branch
> plasma-framework - your branch
> plsama-workspace - master
> (which is pretty close to running latest frameworks with Plasma 5.3)

Are there any significant changes in plasma-workspace and plasma-desktop, 
other than applet migration, since there's also a branch for them?

Looking pretty nice though! Memory consumption for a freshly started Plasma 
session (no applets expanded so far) went from 215MiB to 145MiB on my laptop, 
startup also feels a little bit faster.

What I found interesting that you changed import "plasmapkg:/code/logic.js" to 
import "logic.js" although the qml file is in a different folder, why does 
that work?

> Being a massively miserable grumpy git, I'd rather merge just after 5.11,
> giving us 4 weeks of testing.

+1 for that

Cheers,
Kai Uwe

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

Re: Planning merging the single qqml engine

[Ivan Čukić]

While I'm usually more conservative, I do think that something more
decisive should be done in this case (and cases like these). While we
do not want to break everything with each new release (wink wink ghm
ghm nudge nudge), I don't think we want to support every
not-still-preferred-approach-of-implementing-something we made before
indefinitely.

If there are important 3rd-party plasma 5 applets (are there?) that we
really need to keep back-compatibility for, I'd propose this:

 - make it opt-in (as Marco says)
 - deprecate it
 - report notifications to the user 'this applet might make your
desktop unstable' for all used applets that haven't opted-in - this
would serve as a notification both to the users and the developers of
said applets
 - schedule marking the support for these applets for the release
after next, or something.

Cheers,
Ivan




On 18 May 2015 at 21:53, Marco Martin  wrote:
> On Monday 18 May 2015, Mark Gaiser wrote:
>> Anyway, with that attribute you let the applet developer OPT-IN in for
>> shared engine. Setting that attribute can be easily forgotten. If anything,
>> they should OPT-OUT thus by default use the shared engine.
>> Perhaps a attribute like this is more appropriate?:
>> X-Plasma-RequiresOwnQmlEngine=true
>>
>> or something alike.
>>
>> I'd definitely go for OPT-OUT (defaults = use shared engine).
>
> no, because the key here is retrocompatibility, old applets have to work as
> is.
> it's true that this makes it error prone, but that's the ugly need :/
> otherwise there wouldn't be any reason for supporting both modes
>
> --
> Marco Martin
> ___
> 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: Planning merging the single qqml engine

[David Edmundson]

On Mon, May 18, 2015 at 8:28 PM, Marco Martin  wrote:

> Hi all,
>
> I think the branches for the single shared qqmlengine are pretty much ready
> (few cleanups upcoming days), seems pretty stable here.. did someone ran
> the
> branch for a while as well?


Thanks for doing all that.

Now to make you hate me.
I have a crash, https://paste.kde.org/ppeqjl1c1

That's running:
kdeclarative - your branch
plasma-framework - your branch
plsama-workspace - master
(which is pretty close to running latest frameworks with Plasma 5.3)

It's possibly unrelated, but I switched the top two back to master and it
went away.



Other than that, I think code-wise from me it's nearly good to go.

Can I check it's these
https://git.reviewboard.kde.org/r/123736/
and
https://git.reviewboard.kde.org/r/123735/

and the branches in p-w, p-d, are just changing the metadata?

in plasma-workspace TaskDelegate.qml has an import line removed, is that
intended?



In the end i managed to get a single engine for the whole session, views
> included (had to duplicate the View class in plasmaquick and kept the old
> one
> as deprecated for retrocompatibility unfortunately)
>
> the memory save seems pretty good, i *hope* stability improved as well :p
>
> what still uses separed engines are the applet configuration dialogs: this
> is
> necessary because they are supposed to use a different style for the
> qquickcontrols, and being the settings object that decides the style a qml
> singleton (qml singletons are unique by engine), the engine has to be
> different from the desktop/panel. The good thing is that config dialogs are
> instantiated relatively rarely, in most sessions not at all, so shouldn't
> touch too much a "normal run"
>
> Lets not worry about that for now, we've got from super many -> just a
few.
Better to get this stuff merged, than worry about getting it down to 1.

For retrocompatibility the applets unfortunately have to specify explicitly
> they can share the engine in their metadata file (or eventual
> plasmapackage:/
> urls break)
>
> at the moment it's using
> X-Plasma-RequiredExtensions=SharedEngine
>
> but I'm leaning more on the direction of something like
> X-Plasma-MinimumAPIVersion=5.11
>



Out of curiosity, which plasmoids actually need their own engine?

Were they all changed as a bulk find & replace?


> I would like to have all set before frameworks 5.11
>

So that gives us roughly 2 weeks of testing.

Without the plasma-workspace changes coming in 5.4 it doesn't really have
any benefit to the user.
Being a massively miserable grumpy git, I'd rather merge just after 5.11,
giving us 4 weeks of testing.


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

Re: Review Request 123735: version of QmlObject with a static engine

[Marco Martin]

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

(Updated May 18, 2015, 8 p.m.)


Review request for KDE Frameworks and Plasma.


Repository: kdeclarative


Description
---

to make easier doing applications like plasma that use a lot of qml to have a 
single engine make a subclass of QmlObject called QmlObjectSharedEngine that 
has a single, static QQmlEngine

Adds a class called QuickViewSharedEngine that has the same behavior as 
QmlObjectSharedEngine(using it): static QQmlEngine, separed rootContexts() for 
each instance.
This is used by desktopviews and panelviews to share their engine.

Unfortunately it may not be possible to get the applet configuration dialogs to 
use this, since they still need a separed engine in order to have a different 
controls style (qstyle based) than the stuff in the desktop/panel


Diffs (updated)
-

  src/kdeclarative/CMakeLists.txt d73bff0 
  src/kdeclarative/kdeclarative.cpp b3906e2 
  src/kdeclarative/qmlobject.h f26b67d 
  src/kdeclarative/qmlobject.cpp c483665 
  src/kdeclarative/qmlobjectsharedengine.h PRE-CREATION 
  src/kdeclarative/qmlobjectsharedengine.cpp PRE-CREATION 
  src/quickaddons/CMakeLists.txt 777d07c 
  src/quickaddons/quickviewsharedengine.h PRE-CREATION 
  src/quickaddons/quickviewsharedengine.cpp PRE-CREATION 

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


Testing
---


Thanks,

Marco Martin

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

Re: Planning merging the single qqml engine

[Marco Martin]

On Monday 18 May 2015, Mark Gaiser wrote:
> Anyway, with that attribute you let the applet developer OPT-IN in for
> shared engine. Setting that attribute can be easily forgotten. If anything,
> they should OPT-OUT thus by default use the shared engine.
> Perhaps a attribute like this is more appropriate?:
> X-Plasma-RequiresOwnQmlEngine=true
> 
> or something alike.
> 
> I'd definitely go for OPT-OUT (defaults = use shared engine).

no, because the key here is retrocompatibility, old applets have to work as 
is.
it's true that this makes it error prone, but that's the ugly need :/
otherwise there wouldn't be any reason for supporting both modes

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

Re: Planning merging the single qqml engine

[Mark Gaiser]

On Mon, May 18, 2015 at 9:28 PM, Marco Martin  wrote:

> Hi all,
>
> I think the branches for the single shared qqmlengine are pretty much ready
> (few cleanups upcoming days), seems pretty stable here.. did someone ran
> the
> branch for a while as well?
>
> In the end i managed to get a single engine for the whole session, views
> included (had to duplicate the View class in plasmaquick and kept the old
> one
> as deprecated for retrocompatibility unfortunately)
>
> the memory save seems pretty good, i *hope* stability improved as well :p
>
> what still uses separed engines are the applet configuration dialogs: this
> is
> necessary because they are supposed to use a different style for the
> qquickcontrols, and being the settings object that decides the style a qml
> singleton (qml singletons are unique by engine), the engine has to be
> different from the desktop/panel. The good thing is that config dialogs are
> instantiated relatively rarely, in most sessions not at all, so shouldn't
> touch too much a "normal run"
>
> For retrocompatibility the applets unfortunately have to specify explicitly
> they can share the engine in their metadata file (or eventual
> plasmapackage:/
> urls break)
>
> at the moment it's using
> X-Plasma-RequiredExtensions=SharedEngine
>

What does "RequiredExtensions" mean anyway? Is that a new attribute where
you intent to add more "extensions" or does it already exist?
It's name sounds slightly confusing to me. How can a SharedEngine be a
"extension"?

Anyway, with that attribute you let the applet developer OPT-IN in for
shared engine. Setting that attribute can be easily forgotten. If anything,
they should OPT-OUT thus by default use the shared engine.
Perhaps a attribute like this is more appropriate?:
X-Plasma-RequiresOwnQmlEngine=true

or something alike.

I'd definitely go for OPT-OUT (defaults = use shared engine).


> but I'm leaning more on the direction of something like
> X-Plasma-MinimumAPIVersion=5.11
>
> I would like to have all set before frameworks 5.11
>
> thoughts?
>
> --
> 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

Re: Review Request 123738: Use column major in the taskbar when "Force row settings" is set

[Kåre Särs]

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

(Updated maj 18, 2015, 7:40 e.m.)


Review request for Plasma and Eike Hein.


Changes
---

Change to "Always arrange tasks in columns of as many rows"


Repository: plasma-desktop


Description
---

When we have "Force row settings" and more than one row of items, the items 
start to jump around and it is had to keep track of where each item is. 

The atached patch changes the flow to TopToBottom, in stead of LeftToRight, 
when we have a horizontal layout and "Force row settings", and similarly to 
LeftToRight in vertical layout. (In practice the vertical layout is always one 
column and this patch has no effect)

Here are two videos that describe the problem
First is the row major where taskbar items jump around:
https://youtu.be/8udr2DJKobw

And the second with a patched taskbar where the items jump around a lot less:
https://youtu.be/bk17gnu1ETo


Diffs (updated)
-

  applets/taskmanager/package/contents/ui/ConfigGeneral.qml 36dd134 
  applets/taskmanager/package/contents/ui/main.qml 98ba7c3 

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


Testing
---

I have applied this patch to the system installed plasma 5.3 installation.


Thanks,

Kåre Särs

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

Re: Review Request 123735: version of QmlObject with a static engine

[David Edmundson]

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



src/quickaddons/quickviewsharedengine.cpp (lines 35 - 39)


needed?



src/quickaddons/quickviewsharedengine.cpp (line 63)


initialise.



src/quickaddons/quickviewsharedengine.cpp (line 228)


syncWidth();
syncHeight();

here?

Maybe move to a private method to share with executionFinished()



src/quickaddons/quickviewsharedengine.cpp (line 252)


why the cast? it's already a QQmlComponent::Status?


- David Edmundson


On May 18, 2015, 7:09 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123735/
> ---
> 
> (Updated May 18, 2015, 7:09 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> to make easier doing applications like plasma that use a lot of qml to have a 
> single engine make a subclass of QmlObject called QmlObjectSharedEngine that 
> has a single, static QQmlEngine
> 
> Adds a class called QuickViewSharedEngine that has the same behavior as 
> QmlObjectSharedEngine(using it): static QQmlEngine, separed rootContexts() 
> for each instance.
> This is used by desktopviews and panelviews to share their engine.
> 
> Unfortunately it may not be possible to get the applet configuration dialogs 
> to use this, since they still need a separed engine in order to have a 
> different controls style (qstyle based) than the stuff in the desktop/panel
> 
> 
> Diffs
> -
> 
>   src/kdeclarative/CMakeLists.txt d73bff0 
>   src/kdeclarative/kdeclarative.cpp b3906e2 
>   src/kdeclarative/qmlobject.h f26b67d 
>   src/kdeclarative/qmlobject.cpp c483665 
>   src/kdeclarative/qmlobjectsharedengine.h PRE-CREATION 
>   src/kdeclarative/qmlobjectsharedengine.cpp PRE-CREATION 
>   src/quickaddons/CMakeLists.txt 777d07c 
>   src/quickaddons/quickviewsharedengine.h PRE-CREATION 
>   src/quickaddons/quickviewsharedengine.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/123735/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Planning merging the single qqml engine

[Marco Martin]

Hi all,

I think the branches for the single shared qqmlengine are pretty much ready 
(few cleanups upcoming days), seems pretty stable here.. did someone ran the 
branch for a while as well?

In the end i managed to get a single engine for the whole session, views 
included (had to duplicate the View class in plasmaquick and kept the old one 
as deprecated for retrocompatibility unfortunately)

the memory save seems pretty good, i *hope* stability improved as well :p

what still uses separed engines are the applet configuration dialogs: this is 
necessary because they are supposed to use a different style for the 
qquickcontrols, and being the settings object that decides the style a qml 
singleton (qml singletons are unique by engine), the engine has to be 
different from the desktop/panel. The good thing is that config dialogs are 
instantiated relatively rarely, in most sessions not at all, so shouldn't 
touch too much a "normal run"

For retrocompatibility the applets unfortunately have to specify explicitly 
they can share the engine in their metadata file (or eventual plasmapackage:/ 
urls break)

at the moment it's using
X-Plasma-RequiredExtensions=SharedEngine

but I'm leaning more on the direction of something like
X-Plasma-MinimumAPIVersion=5.11

I would like to have all set before frameworks 5.11

thoughts?

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

Re: Review Request 123735: version of QmlObject with a static engine

[Marco Martin]

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

(Updated May 18, 2015, 7:09 p.m.)


Review request for KDE Frameworks and Plasma.


Repository: kdeclarative


Description (updated)
---

to make easier doing applications like plasma that use a lot of qml to have a 
single engine make a subclass of QmlObject called QmlObjectSharedEngine that 
has a single, static QQmlEngine

Adds a class called QuickViewSharedEngine that has the same behavior as 
QmlObjectSharedEngine(using it): static QQmlEngine, separed rootContexts() for 
each instance.
This is used by desktopviews and panelviews to share their engine.

Unfortunately it may not be possible to get the applet configuration dialogs to 
use this, since they still need a separed engine in order to have a different 
controls style (qstyle based) than the stuff in the desktop/panel


Diffs
-

  src/kdeclarative/CMakeLists.txt d73bff0 
  src/kdeclarative/kdeclarative.cpp b3906e2 
  src/kdeclarative/qmlobject.h f26b67d 
  src/kdeclarative/qmlobject.cpp c483665 
  src/kdeclarative/qmlobjectsharedengine.h PRE-CREATION 
  src/kdeclarative/qmlobjectsharedengine.cpp PRE-CREATION 
  src/quickaddons/CMakeLists.txt 777d07c 
  src/quickaddons/quickviewsharedengine.h PRE-CREATION 
  src/quickaddons/quickviewsharedengine.cpp PRE-CREATION 

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


Testing
---


Thanks,

Marco Martin

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

Re: Review Request 123783: Adjust showing desktop behavior

[Thomas Pfeiffer]

> On May 14, 2015, 11:23 p.m., Thomas Pfeiffer wrote:
> > > 1) The minimizability of windows is ignored. It's a cornercase, but the 
> > > former behavior was a side-effect of the implementation. (At least I 
> > > don't know a reason to keep them)
> > 
> > Could you explain what minimizability of windows means, please?
> > 
> > > 2) The state is broken with the activation of windows, not them becoming 
> > > visible. Latter doesn't work for most cases (unminimizing) for obvious 
> > > reasons (they're not minimized ;-) and when a new window is mapped, the 
> > > focus stealing prevention seems a good filter (if it's not good enough to 
> > > gain the focus, it's not good enough to break the state either ;-)
> > 
> > Sounds sensible
> > 
> > > 3) Keep above windows remain visible and do not break the state (as if 
> > > they'd belong to the desktop) for a request by the HIG group. I'm frankly 
> > > not sure about the background of this behavior (hopefully not krunner - 
> > > that doesn't work)
> > 
> > The reasoning behind that was the assumption that keepabove is used for 
> > windows that one always wants to see (e.g. because they contain some 
> > information one is monitoring). We have no data to back that assumption up, 
> > though, so please challenge it if you have reason to believe that keepabove 
> > is mostly used for windows which do not have to be always visible. Our 
> > words are not gospel, after all ;)
> > 
> > > 4) Windows in the desktop group initially remain above the desktop and 
> > > can be activated w/ breaking the state, but can also hide behind the 
> > > desktop (notably when that is clicked/activated)
> > 
> > I'm not sure if I understood this correctly. My interpretation is this:
> > * If I open a window that is related to the desktop and *then* activate 
> > Show Desktop, the window gets hidden
> > * If I then activate the hidden window, it brakes the state
> > * If I activate Show Desktop and *then* open a window that is related to 
> > the desktop, it gets shown without braking the state
> > 
> > Is that correct? If so, sounds good to me!
> 
> Thomas Lübking wrote:
> > Could you explain what minimizability of windows means, please?
> 
> Believe it or not, but windows can hint to be not minimizable (what KWin 
> boldly ignores) and KWin has a rule to control that (you can specify that a 
> particular window cannot be minimized)
> It's a corner case ;-)
> 
> > that one always wants to see
> 
> In doubt, we'd meanwhile have an "on screen display" layer which is even 
> above the fullscreen layer.
> The question is whether this context (showing desktop) is similar to eg. 
> running a fullscreen game or video. Both would overlay even keep above 
> windows.
> 
> I'm not afraid of another field test, though >-)
> 
> > I'm not sure if I understood this correctly.
> 
> Second part: yes, first part: no.
> Basically they behave like keep above windows. They initially remain 
> visible. If you click (activate/raise) the desktop, they'll go behind, if you 
> then reactivate them (through the taskbar or eg. the desktop RMB menu), 
> they'll show up WITHOUT breaking the state.
> 
> I'm agnostic to whether they should be initially hidden, but would object 
> having them break the state depending on whether they were visible while 
> entering the state.
> 
> 1st because it makes the code more complex ;-)
> 
> 2nd because "visible" is relative in this context: they're neither keep 
> above (so could have been behind a maximized window) nor on all virtual 
> desktops (so could have been on such)
> They could even have randomly been occluded by three other windows.
> 
> In return the assumed usecase "show desktop -> change wallpaper" would 
> "randomly" turn into "show desktop -> restore all windows -> change wallpaper"

Sorry for not replying earlier :(

> Believe it or not, but windows can hint to be not minimizable (what KWin 
> boldly ignores) and KWin has a rule to control that (you can specify that a 
> particular window cannot be minimized)
It's a corner case ;-)

I assume non-minimizable windows are things like modal dialogs where someone at 
Microsoft (or Xerox or... I dunno) once had the bright idea that they should 
not have a minimize button. Those windows are not supposed to stay open for 
long anyway, so yes, corner case which does not deserve much attention (e.g. 
just treating them like any other window is fine).

> I'm not afraid of another field test, though >-)

Yeah, let's see what happens ;)

> Second part: yes, first part: no.
Basically they behave like keep above windows. They initially remain visible. 
If you click (activate/raise) the desktop, they'll go behind, if you then 
reactivate them (through the taskbar or eg. the desktop RMB menu), they'll show 
up WITHOUT breaking the state.

Ah okay. Yes, that is fine, too (better, probably).

So yes, green light from my sid

Re: Review Request 123735: version of QmlObject with a static engine

[Marco Martin]

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

(Updated May 18, 2015, 7:02 p.m.)


Review request for KDE Frameworks and Plasma.


Repository: kdeclarative


Description
---

to make easier doing applications like plasma that use a lot of qml to have a 
single engine make a subclass of QmlObject called QmlObjectSharedEngine that 
has a single, static QQmlEngine


Diffs (updated)
-

  src/kdeclarative/CMakeLists.txt d73bff0 
  src/kdeclarative/kdeclarative.cpp b3906e2 
  src/kdeclarative/qmlobject.h f26b67d 
  src/kdeclarative/qmlobject.cpp c483665 
  src/kdeclarative/qmlobjectsharedengine.h PRE-CREATION 
  src/kdeclarative/qmlobjectsharedengine.cpp PRE-CREATION 
  src/quickaddons/CMakeLists.txt 777d07c 
  src/quickaddons/quickviewsharedengine.h PRE-CREATION 
  src/quickaddons/quickviewsharedengine.cpp PRE-CREATION 

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


Testing
---


Thanks,

Marco Martin

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

Re: Review Request 123783: Adjust showing desktop behavior

[Martin Gräßlin]

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

Ship it!


Ship It!

- Martin Gräßlin


On May 14, 2015, 12:21 a.m., Thomas Lübking wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123783/
> ---
> 
> (Updated May 14, 2015, 12:21 a.m.)
> 
> 
> Review request for kwin, Plasma, Kai Uwe Broulik, David Edmundson, Martin 
> Gräßlin, Marco Martin, Sebastian Kügler, and Thomas Pfeiffer.
> 
> 
> Bugs: 346837, 346933 and 347212
> https://bugs.kde.org/show_bug.cgi?id=346837
> https://bugs.kde.org/show_bug.cgi?id=346933
> https://bugs.kde.org/show_bug.cgi?id=347212
> 
> 
> Repository: kwin
> 
> 
> Description
> ---
> 
> Errhe... while we're waiting for final comments of the HIG group ;-)
> Here's a patch that *mostly* restores the 5.2 behavior
> 
> Notable differences:
> 
> 1) The minimizability of windows is ignored. It's a cornercase, but the 
> former behavior was a side-effect of the implementation. (At least I don't 
> know a reason to keep them)
> 
> 2) The state is broken with the *activation* of windows, not them becoming 
> visible. Latter doesn't work for most cases (unminimizing) for obvious 
> reasons (they're not minimized ;-) and when a new window is mapped, the focus 
> stealing prevention seems a good filter (if it's not good enough to gain the 
> focus, it's not good enough to break the state either ;-)
> 
> 3) Keep above windows remain visible and do not break the state (as if they'd 
> belong to the desktop) for a request by the HIG group. I'm frankly not sure 
> about the background of this behavior (hopefully not krunner - that doesn't 
> work)
> 
> 4) Windows in the desktop group initially remain above the desktop and can be 
> activated w/ breaking the state, but can also hide behind the desktop 
> (notably when that is clicked/activated)
> 
> 
> Diffs
> -
> 
>   activation.cpp fe0a51f 
>   client.h 40d503c 
>   client.cpp a6fbf3e 
>   layers.cpp b6d5b75 
>   manage.cpp 75af4e5 
>   workspace.cpp 09ae9a2 
> 
> Diff: https://git.reviewboard.kde.org/r/123783/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Thomas Lübking
> 
>

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

Re: Review Request 123783: Adjust showing desktop behavior

[Thomas Lübking]

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


Plasma workspace 5.3.1 is tagged *Thu 2015-05-21*, 3 days from now.

Therefore I'd like to call for "vetos" until *Tue 2015-05-19*, then pass myself 
a "ship it!" to not have this move in in the very last seconds.

- Thomas Lübking


On Mai 13, 2015, 10:21 nachm., Thomas Lübking wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123783/
> ---
> 
> (Updated Mai 13, 2015, 10:21 nachm.)
> 
> 
> Review request for kwin, Plasma, Kai Uwe Broulik, David Edmundson, Martin 
> Gräßlin, Marco Martin, Sebastian Kügler, and Thomas Pfeiffer.
> 
> 
> Bugs: 346837, 346933 and 347212
> https://bugs.kde.org/show_bug.cgi?id=346837
> https://bugs.kde.org/show_bug.cgi?id=346933
> https://bugs.kde.org/show_bug.cgi?id=347212
> 
> 
> Repository: kwin
> 
> 
> Description
> ---
> 
> Errhe... while we're waiting for final comments of the HIG group ;-)
> Here's a patch that *mostly* restores the 5.2 behavior
> 
> Notable differences:
> 
> 1) The minimizability of windows is ignored. It's a cornercase, but the 
> former behavior was a side-effect of the implementation. (At least I don't 
> know a reason to keep them)
> 
> 2) The state is broken with the *activation* of windows, not them becoming 
> visible. Latter doesn't work for most cases (unminimizing) for obvious 
> reasons (they're not minimized ;-) and when a new window is mapped, the focus 
> stealing prevention seems a good filter (if it's not good enough to gain the 
> focus, it's not good enough to break the state either ;-)
> 
> 3) Keep above windows remain visible and do not break the state (as if they'd 
> belong to the desktop) for a request by the HIG group. I'm frankly not sure 
> about the background of this behavior (hopefully not krunner - that doesn't 
> work)
> 
> 4) Windows in the desktop group initially remain above the desktop and can be 
> activated w/ breaking the state, but can also hide behind the desktop 
> (notably when that is clicked/activated)
> 
> 
> Diffs
> -
> 
>   activation.cpp fe0a51f 
>   client.h 40d503c 
>   client.cpp a6fbf3e 
>   layers.cpp b6d5b75 
>   manage.cpp 75af4e5 
>   workspace.cpp 09ae9a2 
> 
> Diff: https://git.reviewboard.kde.org/r/123783/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Thomas Lübking
> 
>

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

Re: Plasma 5 is awesome...and some help required with build instructions

[David Edmundson]

On Mon, May 18, 2015 at 7:05 PM, Aleix Pol  wrote:

> On Mon, May 18, 2015 at 7:28 PM, David Edmundson
>  wrote:
> > Just setting up on a new machine and thought I'd try following these
> > instructions exactly, the way a new developer would.
> >
> > I got stuck on something I don't know how to solve.
> >
> > Under Kubuntu because Qt is compiled with a hardcoded plugindir for some
> > reason.
> > This means setting QT_PLUGIN_PATH env variables does nothing, which means
> > you'll always be loading any plugins from /usr/ rather than the ones we
> just
> > built.
> >
> > How did you get round that? Any ideas?
> >
> > David
> >
> > ___
> > Plasma-devel mailing list
> > Plasma-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel
> >
>
> On Kubuntu, you probably want to enable KDE_INSTALL_USE_QT_SYS_PATHS
> cmake option.
>

but that will install to /usr
 ​


> Aleix
> ___
> 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 is awesome...and some help required with build instructions

[Aleix Pol]

On Mon, May 18, 2015 at 7:28 PM, David Edmundson
 wrote:
> Just setting up on a new machine and thought I'd try following these
> instructions exactly, the way a new developer would.
>
> I got stuck on something I don't know how to solve.
>
> Under Kubuntu because Qt is compiled with a hardcoded plugindir for some
> reason.
> This means setting QT_PLUGIN_PATH env variables does nothing, which means
> you'll always be loading any plugins from /usr/ rather than the ones we just
> built.
>
> How did you get round that? Any ideas?
>
> David
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>

On Kubuntu, you probably want to enable KDE_INSTALL_USE_QT_SYS_PATHS
cmake option.

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

Re: Plasma 5 is awesome...and some help required with build instructions

[David Edmundson]

Just setting up on a new machine and thought I'd try following these
instructions exactly, the way a new developer would.

I got stuck on something I don't know how to solve.

Under Kubuntu because Qt is compiled with a hardcoded plugindir for some
reason.
This means setting QT_PLUGIN_PATH env variables does nothing, which means
you'll always be loading any plugins from /usr/ rather than the ones we
just built.

How did you get round that? Any ideas?

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

Re: Review Request 123807: Fix popup menu items getting stray highlighted

[Lukáš Tinkl]

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

Ship it!


Ship It!

- Lukáš Tinkl


On Kvě. 16, 2015, 12:39 dop., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123807/
> ---
> 
> (Updated Kvě. 16, 2015, 12:39 dop.)
> 
> 
> Review request for Plasma, David Edmundson and Hugo Pereira Da Costa.
> 
> 
> Bugs: 332377
> https://bugs.kde.org/show_bug.cgi?id=332377
> 
> 
> Repository: oxygen
> 
> 
> Description
> ---
> 
> Make sure we "finish" the animation before stopping it.
> 
> 
> Diffs
> -
> 
>   kstyle/animations/oxygenmenubardata_imp.h fcfe788 
> 
> Diff: https://git.reviewboard.kde.org/r/123807/diff/
> 
> 
> Testing
> ---
> 
> Moved the mouse like crazy over the "Help" menu of konsole and can't get it 
> to be wrong anymore.
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>

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

Re: Review Request 123836: Ensure KNotification can be used from a non-GUI thread

[Martin Klapetek]

> On May 18, 2015, 4:15 p.m., Aleix Pol Gonzalez wrote:
> > This fixes my boot. I wasn't able to boot for the whole day because it was 
> > showing a QWidget from the wrong thread.
> > 
> > On a related note, let's port away from QDesktopWidget, it has these 
> > things...
> 
> Martin Klapetek wrote:
> Ok, QScreen then?
> 
> Aleix Pol Gonzalez wrote:
> That would work. You can do 
> notification->widget()->screen()->geometry()->top().

That wouldn't work because the widget() does not need to be set. So I'll use 
QScreen directly.


- Martin


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


On May 18, 2015, 5:34 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123836/
> ---
> 
> (Updated May 18, 2015, 5:34 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: knotifications
> 
> 
> Description
> ---
> 
> The NotifyByPopup plugin is accessing QApplication::desktop()
> in constructor which Qt does not like when that happens on non-GUI
> thread and asserts. So this moves that code only when actually
> needed plus it checks first if the code is run in non-GUI thread
> and does nothing if it's not.
> 
> This is only for the popup fallback notifications, normal notifications
> work just fine.
> 
> 
> Diffs
> -
> 
>   src/notifybypopup.cpp 2f84ab0 
> 
> Diff: https://git.reviewboard.kde.org/r/123836/diff/
> 
> 
> Testing
> ---
> 
> Tested with both multi-threaded and single-threaded codes.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: Review Request 123836: Ensure KNotification can be used from a non-GUI thread

[Martin Klapetek]

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

(Updated May 18, 2015, 3:34 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Plasma.


Changes
---

Submitted with commit bbf19c13ee61fe0f09263d2fdd40207a71dca6fd by Martin 
Klapetek to branch master.


Repository: knotifications


Description
---

The NotifyByPopup plugin is accessing QApplication::desktop()
in constructor which Qt does not like when that happens on non-GUI
thread and asserts. So this moves that code only when actually
needed plus it checks first if the code is run in non-GUI thread
and does nothing if it's not.

This is only for the popup fallback notifications, normal notifications
work just fine.


Diffs
-

  src/notifybypopup.cpp 2f84ab0 

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


Testing
---

Tested with both multi-threaded and single-threaded codes.


Thanks,

Martin Klapetek

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

Re: Review Request 123836: Ensure KNotification can be used from a non-GUI thread

[Aleix Pol Gonzalez]

> On May 18, 2015, 4:15 p.m., Aleix Pol Gonzalez wrote:
> > This fixes my boot. I wasn't able to boot for the whole day because it was 
> > showing a QWidget from the wrong thread.
> > 
> > On a related note, let's port away from QDesktopWidget, it has these 
> > things...
> 
> Martin Klapetek wrote:
> Ok, QScreen then?

That would work. You can do notification->widget()->screen()->geometry()->top().


- Aleix


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


On May 18, 2015, 2:13 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123836/
> ---
> 
> (Updated May 18, 2015, 2:13 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: knotifications
> 
> 
> Description
> ---
> 
> The NotifyByPopup plugin is accessing QApplication::desktop()
> in constructor which Qt does not like when that happens on non-GUI
> thread and asserts. So this moves that code only when actually
> needed plus it checks first if the code is run in non-GUI thread
> and does nothing if it's not.
> 
> This is only for the popup fallback notifications, normal notifications
> work just fine.
> 
> 
> Diffs
> -
> 
>   src/notifybypopup.cpp 2f84ab0 
> 
> Diff: https://git.reviewboard.kde.org/r/123836/diff/
> 
> 
> Testing
> ---
> 
> Tested with both multi-threaded and single-threaded codes.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: Review Request 123836: Ensure KNotification can be used from a non-GUI thread

[Martin Klapetek]

> On May 18, 2015, 4:15 p.m., Aleix Pol Gonzalez wrote:
> > This fixes my boot. I wasn't able to boot for the whole day because it was 
> > showing a QWidget from the wrong thread.
> > 
> > On a related note, let's port away from QDesktopWidget, it has these 
> > things...

Ok, QScreen then?


- Martin


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


On May 18, 2015, 2:13 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123836/
> ---
> 
> (Updated May 18, 2015, 2:13 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: knotifications
> 
> 
> Description
> ---
> 
> The NotifyByPopup plugin is accessing QApplication::desktop()
> in constructor which Qt does not like when that happens on non-GUI
> thread and asserts. So this moves that code only when actually
> needed plus it checks first if the code is run in non-GUI thread
> and does nothing if it's not.
> 
> This is only for the popup fallback notifications, normal notifications
> work just fine.
> 
> 
> Diffs
> -
> 
>   src/notifybypopup.cpp 2f84ab0 
> 
> Diff: https://git.reviewboard.kde.org/r/123836/diff/
> 
> 
> Testing
> ---
> 
> Tested with both multi-threaded and single-threaded codes.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: Review Request 123836: Ensure KNotification can be used from a non-GUI thread

[Aleix Pol Gonzalez]

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

Ship it!


This fixes my boot. I wasn't able to boot for the whole day because it was 
showing a QWidget from the wrong thread.

On a related note, let's port away from QDesktopWidget, it has these things...

- Aleix Pol Gonzalez


On May 18, 2015, 2:13 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123836/
> ---
> 
> (Updated May 18, 2015, 2:13 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: knotifications
> 
> 
> Description
> ---
> 
> The NotifyByPopup plugin is accessing QApplication::desktop()
> in constructor which Qt does not like when that happens on non-GUI
> thread and asserts. So this moves that code only when actually
> needed plus it checks first if the code is run in non-GUI thread
> and does nothing if it's not.
> 
> This is only for the popup fallback notifications, normal notifications
> work just fine.
> 
> 
> Diffs
> -
> 
>   src/notifybypopup.cpp 2f84ab0 
> 
> Diff: https://git.reviewboard.kde.org/r/123836/diff/
> 
> 
> Testing
> ---
> 
> Tested with both multi-threaded and single-threaded codes.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: Review Request 123381: Fallback to AttentionIcon for SNI when animations are disabled

[Martin Klapetek]

> On April 16, 2015, 1:43 p.m., Kai Uwe Broulik wrote:
> > I think we should always pulse, and if available, use the needs attention 
> > icon (but don't cycle between normal and attention icon)
> 
> Martin Klapetek wrote:
> If you don't cycle it's quite easy to miss, so I think there'd be very 
> little point in just switching the icon (the purpose is to get your 
> attention).
> 
> Martin Klapetek wrote:
> Ah I misunderstood. The slight problem I see with always using the 
> attention icon for the pulse animation is that they are not necessarily 
> covered by the plasma theme, so when it starts pulsing with attention icon, 
> the icon can look completely different while simply pulsing the normal icon 
> seems more consistent. Dunno.

So uhhany comments?


- Martin


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


On April 16, 2015, 1:23 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123381/
> ---
> 
> (Updated April 16, 2015, 1:23 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This returns the kde4 behavior of simply switching the icon for attention 
> icon when animations are disabled.
> 
> I don't think that always using the attention icon with the pulse animation 
> looks good, it looks like there's too much going on. I believe it should be 
> an either-or. So I did it only as a fallback.
> 
> 
> Diffs
> -
> 
>   applets/systemtray/package/contents/ui/StatusNotifierItem.qml 5380b09 
>   applets/systemtray/package/contents/ui/TaskDelegate.qml f2738bd 
> 
> Diff: https://git.reviewboard.kde.org/r/123381/diff/
> 
> 
> Testing
> ---
> 
> I didn't test with animations off (I'm not sure how to set) so I just 
> explicitly enabled the timer and disabled the PulseAnimation. Works just like 
> in the old times.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: Review Request 122648: Make notifications --reverse aware

[Martin Klapetek]

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

(Updated May 18, 2015, 12:54 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit 7253c12a2b089176d0354c6a3a88b536befb5653 by Martin 
Klapetek to branch Plasma/5.3.


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


Repository: plasma-workspace


Description
---

Now it works with plasmashell --reverse


Diffs
-

  applets/notifications/package/contents/ui/NotificationItem.qml 86b0b6e 
  applets/notifications/package/contents/ui/NotificationPopup.qml 6902459 
  applets/notifications/package/contents/ui/main.qml 1e5efa3 
  applets/notifications/plugin/notificationshelper.h ca0b63b 
  applets/notifications/plugin/notificationshelper.cpp e7c4e29 

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


Testing
---

Tested both --reverse and not --reverse and both look good. See screenshot.


File Attachments


--reverse
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/02/20/5058fe12-ecdd-4345-bcec-4392bbfa78f5__notifications-reverse.png


Thanks,

Martin Klapetek

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

Re: Review Request 123731: Cleanup handling of notifications closing

[Martin Klapetek]

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

(Updated May 18, 2015, 2:14 p.m.)


Review request for KDE Frameworks and Plasma.


Changes
---

Add plasma


Repository: knotifications


Description
---

While investigating the cause of crash of 
https://bugs.kde.org/show_bug.cgi?id=342752 I've come across some loose ends in 
how KNotifications is handling closing of notifications.

As for the crash itself, I never managed to reproduce even with special written 
test cases, but what happens (or seem to) is this:
 * KNotification object gets deleted
 * The destructor calls close() on all plugins
 * The NotifyByPopup plugin does async dbus call to close the notification and 
returns
 * KNotification's dpointer is deleted
 * The DBus reply returns, calling NotifyByPopup::finished()
 * Now for some reason the KNotification object is still not null but its 
dpointer is gone, so the check "if (!notification || 
d->notifications.contains(notification->id()))" crashes on the 
notification->id() call

So I've made it simply return -1 when dpointer is null, which should ideally 
prevent the crashes


Diffs
-

  src/knotification.cpp 01962b3 
  src/knotificationmanager.cpp 0d9b3b0 
  src/knotificationmanager_p.h f8e7df8 
  src/notifybypopup.cpp 2f84ab0 

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


Testing
---


Thanks,

Martin Klapetek

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

Review Request 123836: Ensure KNotification can be used from a non-GUI thread

[Martin Klapetek]

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

Review request for KDE Frameworks and Plasma.


Repository: knotifications


Description
---

The NotifyByPopup plugin is accessing QApplication::desktop()
in constructor which Qt does not like when that happens on non-GUI
thread and asserts. So this moves that code only when actually
needed plus it checks first if the code is run in non-GUI thread
and does nothing if it's not.

This is only for the popup fallback notifications, normal notifications
work just fine.


Diffs
-

  src/notifybypopup.cpp 2f84ab0 

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


Testing
---

Tested with both multi-threaded and single-threaded codes.


Thanks,

Martin Klapetek

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

[Plasma Workspace Wallpapers] [Bug 347532] preferencias de escritorio no permite establecer fondo de pantalla ni individual ni en presentacion solo las del sistenma

[Sebastian Kügler]

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

Sebastian Kügler  changed:

   What|Removed |Added

 CC||se...@kde.org
 Resolution|--- |WAITINGFORINFO
 Status|UNCONFIRMED |NEEDSINFO

--- Comment #4 from Sebastian Kügler  ---
I don't understand your problem.

Could you perhaps try to phrase it in terms of actual and expected behaviour,
and explain more clearly what exactly you are trying?

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

Minutes Monday Plasma Hangout

[Sebastian Kügler]

Present: Antonis, Marco, Martin G., Sebastian, Kai Uwe, Vishesh, David

Date: 18 May, 2015

Next week: no hangout on Monday, but on Tuesday due to public holiday in 
relevant regions

Antonis:
- Working on bugs in  https://codereview.qt-project.org/#/c/112296/
- Will fix issues pointed out in https://git.reviewboard.kde.org/r/123682/ , 
then merge into ported kcm modules branch

Kai Uwe:
- Klipper now highlights trailing and leading whitespace 
https://git.reviewboard.kde.org/media/uploaded/files/2015/05/16/e31d060b-ab13-4f37-9ba3-26cb743ddee4__klippercolorcoded.png
- visual fix for polkit kde dialog thingie
- merged https://codereview.qt-project.org/#/c/111791/ so we now get proper 
scroll bars on desktops, starting qt 5.5
- devicepixelratio for icons https://codereview.qt-project.org/#/c/112435/
- notification countdown https://www.youtube.com/watch?v=k0KxRORAOng

Marco:
- working on branch of single, shared QML engine (huge memory savings) where 
possible
- views (desktop, panel) can't share engine

Martin:
- Investigated why KWin's own windows don't work on Wayland

Problem scope Alt+F3 popup:

* QtWayland only creates popups if they have a parent QWindow
* If there is no parent QtWindow it uses the last QWindow which got focus
* Solution: create a dummy window and fake a mouse press
* New problem: how to identify windows? QWindow::winId() is useless on 
wayland
* New solution: KWayland interacts with QPA and can create a 
Client::Surface for a QWindow
* New problem: QtWayland crashes if one sends mouse events without a 
keymap sent before
* New solution: fix in Qt
* New problem: popup not shown as 
QWindowSystemInterface::sendWindowSystemEvents is never called
* Reason: KWin uses QEventDispatcherUNIX instead of 
QUnixEventDispatcherQPA
* Cannot use QUnixEventDispatcherQPA as it's in QtPlatformSupport which 
doesn't have cmake support
* New solution: implement a subclass for QEventDispatcherUNIX with same 
functionality
* New problem: KWin dead locks when showing the popup
* Reason: when starting painting Qt blocks main gui thread for last 
rendering being presented by compositor
* New solution: fake frame rendered directly on damage events
* doesn't work reliably
* New solution: KWayland::Client can create a Client::ConnectionThread for 
the QPA connection. Whenever we process events we flush Qt's 
Client::ConnectionThread, then we dispatch the WaylandServer and ensure thus 
that the frameRendered is send before we start to process any events which 
could trigger a repaint
* popups work now

Problem scope QtQuick windows
---
* QtWayland doesn't create windows with Qt::BypasssWindowManagerHint, but 
we use that on each of KWin's window...
* Qt wants to add it's beautiful window decorations -> disable in KWin 
through env variable
* Mesa performs blocking waits for frame rendered - same problem scope as 
with Alt+F3
* changes for Alt+F3 seem to help also with QtQuick windows, but still the 
Outline can freeze KWin (needs more investigation).

Vishesh:
- Fixing bugs in Baloo's new backend
- KRunner fixes (for example threading issue)
- LMB needs patch to clean up locks when indexer crashes, being merged, hasn't 
arrived upstream yet

David:
- investigated crasher with statusnotifieritems
- we may want API changes in libdbusmenu-qt, not too urgent, so let's sit down 
at Akademy to look at the grand scheme

Sebastian:
- Trying to get kwin_wayland running, problem loading drm backend
- Chipping away at write support in kscreen wayland backend, making progres, 
but it's a lot of work


-- 
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 123817: Device notifier: Refresh the space indicator every 5 seconds.

[Martin Klapetek]

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


Fwiw, I think it would be much better if the dataengine actually signalled the 
disk space change rather than polling, then the applet could just handle the 
incoming "changed" signals -> less polling around.

- Martin Klapetek


On May 17, 2015, 1:01 p.m., Yoann Laissus wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123817/
> ---
> 
> (Updated May 17, 2015, 1:01 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Previously, it was set to 0 so the space indicator was never refreshed.
> 
> 
> Diffs
> -
> 
>   applets/devicenotifier/package/contents/ui/devicenotifier.qml 
> 1fb3d28736fc5effb7e6a6e5940a7bab28c19798 
> 
> Diff: https://git.reviewboard.kde.org/r/123817/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Yoann Laissus
> 
>

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

Review Request 123834: Switch the login sound to Phonon directly...for now

[Martin Klapetek]

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

Review request for Plasma.


Repository: plasma-workspace


Description
---

With its current architecture, KNotification can cause crashes on logout (and 
also cause asserts in certain situations, that will be another fix). So in the 
meantime, this replaces the KNotification-in-a-thread with Phonon directly.

This is exactly what KNotification would do. This is for the time being until 
the crash on logout is sorted out.

Additionally, this also fixes logout sound which was missing before. This uses 
normal KNotification as at that point we don't need to be threading or 
anything, so KNotification is just safe.


Diffs
-

  CMakeLists.txt 8ffccad 
  ksmserver/CMakeLists.txt c0543e2 
  ksmserver/shutdown.cpp 7600c30 
  ksmserver/startup.cpp f79fd4f 

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


Testing
---

Login sound works as expected, logout sound as well. Also tested by couple 
other people.


Thanks,

Martin Klapetek

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