Re: Review Request 119411: Plasmate-Kdev: Port plasmate to KDevPlatform's shell part 1

[Aleix Pol Gonzalez]

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



plasmate/app/plasmateapp.cpp


Put the error directly inside i18n()? Otherwise it won't get translated.


This looks far simpler than I'd have anticipated. Maybe you'd like to put some 
screenshots? What's the completion of the branch?

- Aleix Pol Gonzalez


On July 22, 2014, 5:47 p.m., Giorgos Tsiapaliokas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119411/
> ---
> 
> (Updated July 22, 2014, 5:47 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasmate
> 
> 
> Description
> ---
> 
> I have separated this task to two reviews, because there are also some
> `git mv` in order to have a decent directory structure which I don't have
> included in this review for readability.
> 
> Below is the list of commits from which this review has been made.
> 
> 
> 
> * use some private members and improve readability
> 
> 
> * Every project must have a .plasmate file in order to pick the Manager.
> 
> 
> * Initial commit for porting plasmate to kdevplatform
> 
> We introduce a new class named PlasmateApp which will
> show the Startpage and hide it, when it must do it.
> 
> 
> Diffs
> -
> 
>   plasmate/CMakeLists.txt 1a6ce8799741b70abf4d19c7df9ea1d11d4779f8 
>   plasmate/app/main.cpp PRE-CREATION 
>   plasmate/app/plasmateapp.h PRE-CREATION 
>   plasmate/app/plasmateapp.cpp PRE-CREATION 
>   plasmate/app/plasmateextention.h PRE-CREATION 
>   plasmate/app/plasmateextention.cpp PRE-CREATION 
>   plasmate/app/plasmateui.rc PRE-CREATION 
>   plasmate/main.cpp 633c4cc86b4795418d1ed90028165615a2e6f2ec 
>   plasmate/plasmateui.rc 41f602591cf9596c0dae13f111845630e96f19f6 
>   plasmate/startpage.h 4c77e29bc2dd93977e06bdeec45c753a568e374a 
>   plasmate/startpage.cpp a65a2cc48afa4eef0db6d6248e31ac2111b42d8d 
> 
> Diff: https://git.reviewboard.kde.org/r/119411/diff/
> 
> 
> Testing
> ---
> 
> You can also test this review from
> 
> url: 
> http://quickgit.kde.org/?p=clones%2Fplasmate%2Ftsiapaliwkas%2Fplasmate-kdevplatform.git
> git: 
> git://anongit.kde.org/clones/plasmate/tsiapaliwkas/plasmate-kdevplatform.git
> branch: r/119411
> 
> 
> Thanks,
> 
> Giorgos Tsiapaliokas
> 
>

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

Re: Review Request 119406: Always take the painter based path for composeOverBorder

[Eike Hein]

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


Two issues:

- Existing Dialog instances don't get the corner mask applied correctly when 
switching from transparent to opague:

![Shot](http://wstaw.org/m/2014/07/23/cornermask.png)

- Compiler warning:

framesvgitem.cpp:119:10: warning: unused parameter ‘composeOverBorder’ 
[-Wunused-parameter]
 void updateTexture(const QSize &size, const QString &elementId, bool 
composeOverBorder)

- Eike Hein


On July 22, 2014, 2:24 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119406/
> ---
> 
> (Updated July 22, 2014, 2:24 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Always take the painter based path for composeOverBorder
> 
> We previously only supported compose-over-border when the centre was not
> set to tile.
> 
> A recent change to the breeze theme put everything into tiling, even if
> some things used compose-over-border, which broke opaque widgets.
> 
> Given that creating an opacityMask loads most of the image anyway, we
> can make use of the FrameSVG painter path and avoid any additional code
> complexity here.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/framesvgitem.cpp a5fe315 
> 
> Diff: https://git.reviewboard.kde.org/r/119406/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: Review Request 119411: Plasmate-Kdev: Port plasmate to KDevPlatform's shell part 1

[David Edmundson]

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


> I have separated this task to two reviews, because there are also some
git mv in order to have a decent directory structure which I don't have

FYI: If you create the diff with --find-renames it /should/ track the file 
movements.

You've split things now, so it's possibly not worth updating, but might make 
your life a bit easier next time.

- David Edmundson


On July 22, 2014, 5:47 p.m., Giorgos Tsiapaliokas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119411/
> ---
> 
> (Updated July 22, 2014, 5:47 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasmate
> 
> 
> Description
> ---
> 
> I have separated this task to two reviews, because there are also some
> `git mv` in order to have a decent directory structure which I don't have
> included in this review for readability.
> 
> Below is the list of commits from which this review has been made.
> 
> 
> 
> * use some private members and improve readability
> 
> 
> * Every project must have a .plasmate file in order to pick the Manager.
> 
> 
> * Initial commit for porting plasmate to kdevplatform
> 
> We introduce a new class named PlasmateApp which will
> show the Startpage and hide it, when it must do it.
> 
> 
> Diffs
> -
> 
>   plasmate/CMakeLists.txt 1a6ce8799741b70abf4d19c7df9ea1d11d4779f8 
>   plasmate/app/main.cpp PRE-CREATION 
>   plasmate/app/plasmateapp.h PRE-CREATION 
>   plasmate/app/plasmateapp.cpp PRE-CREATION 
>   plasmate/app/plasmateextention.h PRE-CREATION 
>   plasmate/app/plasmateextention.cpp PRE-CREATION 
>   plasmate/app/plasmateui.rc PRE-CREATION 
>   plasmate/main.cpp 633c4cc86b4795418d1ed90028165615a2e6f2ec 
>   plasmate/plasmateui.rc 41f602591cf9596c0dae13f111845630e96f19f6 
>   plasmate/startpage.h 4c77e29bc2dd93977e06bdeec45c753a568e374a 
>   plasmate/startpage.cpp a65a2cc48afa4eef0db6d6248e31ac2111b42d8d 
> 
> Diff: https://git.reviewboard.kde.org/r/119411/diff/
> 
> 
> Testing
> ---
> 
> You can also test this review from
> 
> url: 
> http://quickgit.kde.org/?p=clones%2Fplasmate%2Ftsiapaliwkas%2Fplasmate-kdevplatform.git
> git: 
> git://anongit.kde.org/clones/plasmate/tsiapaliwkas/plasmate-kdevplatform.git
> branch: r/119411
> 
> 
> Thanks,
> 
> Giorgos Tsiapaliokas
> 
>

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

Review Request 119411: Plasmate-Kdev: Port plasmate to KDevPlatform's shell part 1

[Giorgos Tsiapaliokas]

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

Review request for Plasma.


Repository: plasmate


Description
---

I have separated this task to two reviews, because there are also some
`git mv` in order to have a decent directory structure which I don't have
included in this review for readability.

Below is the list of commits from which this review has been made.



* use some private members and improve readability


* Every project must have a .plasmate file in order to pick the Manager.


* Initial commit for porting plasmate to kdevplatform

We introduce a new class named PlasmateApp which will
show the Startpage and hide it, when it must do it.


Diffs
-

  plasmate/CMakeLists.txt 1a6ce8799741b70abf4d19c7df9ea1d11d4779f8 
  plasmate/app/main.cpp PRE-CREATION 
  plasmate/app/plasmateapp.h PRE-CREATION 
  plasmate/app/plasmateapp.cpp PRE-CREATION 
  plasmate/app/plasmateextention.h PRE-CREATION 
  plasmate/app/plasmateextention.cpp PRE-CREATION 
  plasmate/app/plasmateui.rc PRE-CREATION 
  plasmate/main.cpp 633c4cc86b4795418d1ed90028165615a2e6f2ec 
  plasmate/plasmateui.rc 41f602591cf9596c0dae13f111845630e96f19f6 
  plasmate/startpage.h 4c77e29bc2dd93977e06bdeec45c753a568e374a 
  plasmate/startpage.cpp a65a2cc48afa4eef0db6d6248e31ac2111b42d8d 

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


Testing
---

You can also test this review from

url: 
http://quickgit.kde.org/?p=clones%2Fplasmate%2Ftsiapaliwkas%2Fplasmate-kdevplatform.git
git: 
git://anongit.kde.org/clones/plasmate/tsiapaliwkas/plasmate-kdevplatform.git
branch: r/119411


Thanks,

Giorgos Tsiapaliokas

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

Re: Review Request 119409: framework part of the applet alternatives shooser

[Marco Martin]

> On July 22, 2014, 3:59 p.m., Aleix Pol Gonzalez wrote:
> > src/scriptengines/qml/plasmoid/appletinterface.cpp, line 555
> > 
> >
> > Why can't you just call the method? You're not delaying it
> 
> Marco Martin wrote:
> ah, no, because that thig is a bit hackish..
> is not a method of corona, just a slot of desktopcorona.
> not proud of it at all, but that doesn't really belong to the base 
> corona, but i think creating and showing the ui is a very shell thing..
> 
> Aleix Pol Gonzalez wrote:
> I'd say that if it's generic enough for plasma-framework, then it can be 
> in corona. I can see it being useful for plasma kpart, for example.
> 
> Also if it's only available on some shells, maybe you only want to add 
> the action on those?
> 
> Marco Martin wrote:
> I don't think as a method, but as corona has the signal
> void configureRequested(Plasma::Applet *applet); it may have a similar 
> behaving signal appletAlternativesRequested(Applet*), it would make a nice 
> symmetry (in this case the creation of the action may even go down in Applet).
> 
> about the action, yeah, would be nice to only have it on some shells, 
> tough i can't add it from within the shell (since i would have to iterate all 
> applets and add it when a containment appears) so i think it may have to stay 
> there for all of them.
> 
> Aleix Pol Gonzalez wrote:
> Maybe it would make sense to have something like:
> virtual void Corona::configureApplet(Applet* a)
> 
> So that shells could set up actions as they pleased.
> 
> Marco Martin wrote:
> hmm, this would make possible to move almost everything of this in the 
> shell, and would be nice, like the idea.
> wonder if it's not giving it too much control tough
> 
> David Edmundson wrote:
> ABI means you can't add a virtual (easily), which sucks. 
> 
> A signal appletAdded(Applet*) might be more generic and still allow the 
> same functionality. This could just be forwarding the signal that containment 
> has anyway so not providing any new control, just making it easier for people 
> to inject actions and alike.

connecting to an appletadded after all those signals have been emitted wouldn't 
be much useful, because too late.
soo, thinking about it i woul go for 
Containment::appletAlternativesRequested(Applet) that makes the same behavior 
used for config dialog creation


- Marco


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


On July 22, 2014, 4:10 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119409/
> ---
> 
> (Updated July 22, 2014, 4:10 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> this is the little part in plasma-framework for the applet alternatives 
> chooser.
> works together the branch mart/alternativesConfig of plasma-workspace and 
> plsma-desktop.
> for how it looks and why, see the vdg forum thread:
> https://forum.kde.org/viewtopic.php?f=285&t=122067&p=315919#p315919
> 
> still possible problems:
> * the branch in framework is kinda screwed, too many merges, is probably 
> better to push this diff as a single commit
> * I'm not sure about using a new desktop file entry X-Plasma-Provides, 
> *maybe* Categories could be enough, but it may produce many false positives 
> as well
> 
> 
> Diffs
> -
> 
>   src/plasma/data/servicetypes/plasma-applet.desktop b75c3d6 
>   src/scriptengines/qml/plasmoid/appletinterface.h fe50825 
>   src/scriptengines/qml/plasmoid/appletinterface.cpp e5f7985 
> 
> Diff: https://git.reviewboard.kde.org/r/119409/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 119409: framework part of the applet alternatives shooser

[David Edmundson]

> On July 22, 2014, 3:59 p.m., Aleix Pol Gonzalez wrote:
> > src/scriptengines/qml/plasmoid/appletinterface.cpp, line 555
> > 
> >
> > Why can't you just call the method? You're not delaying it
> 
> Marco Martin wrote:
> ah, no, because that thig is a bit hackish..
> is not a method of corona, just a slot of desktopcorona.
> not proud of it at all, but that doesn't really belong to the base 
> corona, but i think creating and showing the ui is a very shell thing..
> 
> Aleix Pol Gonzalez wrote:
> I'd say that if it's generic enough for plasma-framework, then it can be 
> in corona. I can see it being useful for plasma kpart, for example.
> 
> Also if it's only available on some shells, maybe you only want to add 
> the action on those?
> 
> Marco Martin wrote:
> I don't think as a method, but as corona has the signal
> void configureRequested(Plasma::Applet *applet); it may have a similar 
> behaving signal appletAlternativesRequested(Applet*), it would make a nice 
> symmetry (in this case the creation of the action may even go down in Applet).
> 
> about the action, yeah, would be nice to only have it on some shells, 
> tough i can't add it from within the shell (since i would have to iterate all 
> applets and add it when a containment appears) so i think it may have to stay 
> there for all of them.
> 
> Aleix Pol Gonzalez wrote:
> Maybe it would make sense to have something like:
> virtual void Corona::configureApplet(Applet* a)
> 
> So that shells could set up actions as they pleased.
> 
> Marco Martin wrote:
> hmm, this would make possible to move almost everything of this in the 
> shell, and would be nice, like the idea.
> wonder if it's not giving it too much control tough

ABI means you can't add a virtual (easily), which sucks. 

A signal appletAdded(Applet*) might be more generic and still allow the same 
functionality. This could just be forwarding the signal that containment has 
anyway so not providing any new control, just making it easier for people to 
inject actions and alike.


- David


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


On July 22, 2014, 4:10 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119409/
> ---
> 
> (Updated July 22, 2014, 4:10 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> this is the little part in plasma-framework for the applet alternatives 
> chooser.
> works together the branch mart/alternativesConfig of plasma-workspace and 
> plsma-desktop.
> for how it looks and why, see the vdg forum thread:
> https://forum.kde.org/viewtopic.php?f=285&t=122067&p=315919#p315919
> 
> still possible problems:
> * the branch in framework is kinda screwed, too many merges, is probably 
> better to push this diff as a single commit
> * I'm not sure about using a new desktop file entry X-Plasma-Provides, 
> *maybe* Categories could be enough, but it may produce many false positives 
> as well
> 
> 
> Diffs
> -
> 
>   src/plasma/data/servicetypes/plasma-applet.desktop b75c3d6 
>   src/scriptengines/qml/plasmoid/appletinterface.h fe50825 
>   src/scriptengines/qml/plasmoid/appletinterface.cpp e5f7985 
> 
> Diff: https://git.reviewboard.kde.org/r/119409/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 119409: framework part of the applet alternatives shooser

[Marco Martin]

> On July 22, 2014, 3:59 p.m., Aleix Pol Gonzalez wrote:
> > src/scriptengines/qml/plasmoid/appletinterface.cpp, line 555
> > 
> >
> > Why can't you just call the method? You're not delaying it
> 
> Marco Martin wrote:
> ah, no, because that thig is a bit hackish..
> is not a method of corona, just a slot of desktopcorona.
> not proud of it at all, but that doesn't really belong to the base 
> corona, but i think creating and showing the ui is a very shell thing..
> 
> Aleix Pol Gonzalez wrote:
> I'd say that if it's generic enough for plasma-framework, then it can be 
> in corona. I can see it being useful for plasma kpart, for example.
> 
> Also if it's only available on some shells, maybe you only want to add 
> the action on those?
> 
> Marco Martin wrote:
> I don't think as a method, but as corona has the signal
> void configureRequested(Plasma::Applet *applet); it may have a similar 
> behaving signal appletAlternativesRequested(Applet*), it would make a nice 
> symmetry (in this case the creation of the action may even go down in Applet).
> 
> about the action, yeah, would be nice to only have it on some shells, 
> tough i can't add it from within the shell (since i would have to iterate all 
> applets and add it when a containment appears) so i think it may have to stay 
> there for all of them.
> 
> Aleix Pol Gonzalez wrote:
> Maybe it would make sense to have something like:
> virtual void Corona::configureApplet(Applet* a)
> 
> So that shells could set up actions as they pleased.

hmm, this would make possible to move almost everything of this in the shell, 
and would be nice, like the idea.
wonder if it's not giving it too much control tough


- Marco


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


On July 22, 2014, 4:10 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119409/
> ---
> 
> (Updated July 22, 2014, 4:10 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> this is the little part in plasma-framework for the applet alternatives 
> chooser.
> works together the branch mart/alternativesConfig of plasma-workspace and 
> plsma-desktop.
> for how it looks and why, see the vdg forum thread:
> https://forum.kde.org/viewtopic.php?f=285&t=122067&p=315919#p315919
> 
> still possible problems:
> * the branch in framework is kinda screwed, too many merges, is probably 
> better to push this diff as a single commit
> * I'm not sure about using a new desktop file entry X-Plasma-Provides, 
> *maybe* Categories could be enough, but it may produce many false positives 
> as well
> 
> 
> Diffs
> -
> 
>   src/plasma/data/servicetypes/plasma-applet.desktop b75c3d6 
>   src/scriptengines/qml/plasmoid/appletinterface.h fe50825 
>   src/scriptengines/qml/plasmoid/appletinterface.cpp e5f7985 
> 
> Diff: https://git.reviewboard.kde.org/r/119409/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 119409: framework part of the applet alternatives shooser

[Aleix Pol Gonzalez]

> On July 22, 2014, 3:59 p.m., Aleix Pol Gonzalez wrote:
> > src/scriptengines/qml/plasmoid/appletinterface.cpp, line 555
> > 
> >
> > Why can't you just call the method? You're not delaying it
> 
> Marco Martin wrote:
> ah, no, because that thig is a bit hackish..
> is not a method of corona, just a slot of desktopcorona.
> not proud of it at all, but that doesn't really belong to the base 
> corona, but i think creating and showing the ui is a very shell thing..
> 
> Aleix Pol Gonzalez wrote:
> I'd say that if it's generic enough for plasma-framework, then it can be 
> in corona. I can see it being useful for plasma kpart, for example.
> 
> Also if it's only available on some shells, maybe you only want to add 
> the action on those?
> 
> Marco Martin wrote:
> I don't think as a method, but as corona has the signal
> void configureRequested(Plasma::Applet *applet); it may have a similar 
> behaving signal appletAlternativesRequested(Applet*), it would make a nice 
> symmetry (in this case the creation of the action may even go down in Applet).
> 
> about the action, yeah, would be nice to only have it on some shells, 
> tough i can't add it from within the shell (since i would have to iterate all 
> applets and add it when a containment appears) so i think it may have to stay 
> there for all of them.

Maybe it would make sense to have something like:
virtual void Corona::configureApplet(Applet* a)

So that shells could set up actions as they pleased.


- Aleix


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


On July 22, 2014, 4:10 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119409/
> ---
> 
> (Updated July 22, 2014, 4:10 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> this is the little part in plasma-framework for the applet alternatives 
> chooser.
> works together the branch mart/alternativesConfig of plasma-workspace and 
> plsma-desktop.
> for how it looks and why, see the vdg forum thread:
> https://forum.kde.org/viewtopic.php?f=285&t=122067&p=315919#p315919
> 
> still possible problems:
> * the branch in framework is kinda screwed, too many merges, is probably 
> better to push this diff as a single commit
> * I'm not sure about using a new desktop file entry X-Plasma-Provides, 
> *maybe* Categories could be enough, but it may produce many false positives 
> as well
> 
> 
> Diffs
> -
> 
>   src/plasma/data/servicetypes/plasma-applet.desktop b75c3d6 
>   src/scriptengines/qml/plasmoid/appletinterface.h fe50825 
>   src/scriptengines/qml/plasmoid/appletinterface.cpp e5f7985 
> 
> Diff: https://git.reviewboard.kde.org/r/119409/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 119409: framework part of the applet alternatives shooser

[Marco Martin]

> On July 22, 2014, 3:59 p.m., Aleix Pol Gonzalez wrote:
> > src/scriptengines/qml/plasmoid/appletinterface.cpp, line 555
> > 
> >
> > Why can't you just call the method? You're not delaying it
> 
> Marco Martin wrote:
> ah, no, because that thig is a bit hackish..
> is not a method of corona, just a slot of desktopcorona.
> not proud of it at all, but that doesn't really belong to the base 
> corona, but i think creating and showing the ui is a very shell thing..
> 
> Aleix Pol Gonzalez wrote:
> I'd say that if it's generic enough for plasma-framework, then it can be 
> in corona. I can see it being useful for plasma kpart, for example.
> 
> Also if it's only available on some shells, maybe you only want to add 
> the action on those?

I don't think as a method, but as corona has the signal
void configureRequested(Plasma::Applet *applet); it may have a similar behaving 
signal appletAlternativesRequested(Applet*), it would make a nice symmetry (in 
this case the creation of the action may even go down in Applet).

about the action, yeah, would be nice to only have it on some shells, tough i 
can't add it from within the shell (since i would have to iterate all applets 
and add it when a containment appears) so i think it may have to stay there for 
all of them.


- Marco


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


On July 22, 2014, 4:10 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119409/
> ---
> 
> (Updated July 22, 2014, 4:10 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> this is the little part in plasma-framework for the applet alternatives 
> chooser.
> works together the branch mart/alternativesConfig of plasma-workspace and 
> plsma-desktop.
> for how it looks and why, see the vdg forum thread:
> https://forum.kde.org/viewtopic.php?f=285&t=122067&p=315919#p315919
> 
> still possible problems:
> * the branch in framework is kinda screwed, too many merges, is probably 
> better to push this diff as a single commit
> * I'm not sure about using a new desktop file entry X-Plasma-Provides, 
> *maybe* Categories could be enough, but it may produce many false positives 
> as well
> 
> 
> Diffs
> -
> 
>   src/plasma/data/servicetypes/plasma-applet.desktop b75c3d6 
>   src/scriptengines/qml/plasmoid/appletinterface.h fe50825 
>   src/scriptengines/qml/plasmoid/appletinterface.cpp e5f7985 
> 
> Diff: https://git.reviewboard.kde.org/r/119409/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 119409: framework part of the applet alternatives shooser

[Aleix Pol Gonzalez]

> On July 22, 2014, 3:59 p.m., Aleix Pol Gonzalez wrote:
> >

Forgot to say, I think introducing a X-Plasma-Provides is ok.
I guess that it will contain the concepts it's fulfilling, right? such as:

X-Plasma-Provides=clock


> On July 22, 2014, 3:59 p.m., Aleix Pol Gonzalez wrote:
> > src/scriptengines/qml/plasmoid/appletinterface.cpp, line 555
> > 
> >
> > Why can't you just call the method? You're not delaying it
> 
> Marco Martin wrote:
> ah, no, because that thig is a bit hackish..
> is not a method of corona, just a slot of desktopcorona.
> not proud of it at all, but that doesn't really belong to the base 
> corona, but i think creating and showing the ui is a very shell thing..

I'd say that if it's generic enough for plasma-framework, then it can be in 
corona. I can see it being useful for plasma kpart, for example.

Also if it's only available on some shells, maybe you only want to add the 
action on those?


- Aleix


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


On July 22, 2014, 4:10 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119409/
> ---
> 
> (Updated July 22, 2014, 4:10 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> this is the little part in plasma-framework for the applet alternatives 
> chooser.
> works together the branch mart/alternativesConfig of plasma-workspace and 
> plsma-desktop.
> for how it looks and why, see the vdg forum thread:
> https://forum.kde.org/viewtopic.php?f=285&t=122067&p=315919#p315919
> 
> still possible problems:
> * the branch in framework is kinda screwed, too many merges, is probably 
> better to push this diff as a single commit
> * I'm not sure about using a new desktop file entry X-Plasma-Provides, 
> *maybe* Categories could be enough, but it may produce many false positives 
> as well
> 
> 
> Diffs
> -
> 
>   src/plasma/data/servicetypes/plasma-applet.desktop b75c3d6 
>   src/scriptengines/qml/plasmoid/appletinterface.h fe50825 
>   src/scriptengines/qml/plasmoid/appletinterface.cpp e5f7985 
> 
> Diff: https://git.reviewboard.kde.org/r/119409/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 119409: framework part of the applet alternatives shooser

[Marco Martin]

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

(Updated July 22, 2014, 4:10 p.m.)


Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

this is the little part in plasma-framework for the applet alternatives chooser.
works together the branch mart/alternativesConfig of plasma-workspace and 
plsma-desktop.
for how it looks and why, see the vdg forum thread:
https://forum.kde.org/viewtopic.php?f=285&t=122067&p=315919#p315919

still possible problems:
* the branch in framework is kinda screwed, too many merges, is probably better 
to push this diff as a single commit
* I'm not sure about using a new desktop file entry X-Plasma-Provides, *maybe* 
Categories could be enough, but it may produce many false positives as well


Diffs (updated)
-

  src/plasma/data/servicetypes/plasma-applet.desktop b75c3d6 
  src/scriptengines/qml/plasmoid/appletinterface.h fe50825 
  src/scriptengines/qml/plasmoid/appletinterface.cpp e5f7985 

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


Testing
---


Thanks,

Marco Martin

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

Re: Review Request 119409: framework part of the applet alternatives shooser

[Marco Martin]

> On July 22, 2014, 3:59 p.m., Aleix Pol Gonzalez wrote:
> > src/scriptengines/qml/plasmoid/appletinterface.cpp, line 555
> > 
> >
> > Why can't you just call the method? You're not delaying it

ah, no, because that thig is a bit hackish..
is not a method of corona, just a slot of desktopcorona.
not proud of it at all, but that doesn't really belong to the base corona, but 
i think creating and showing the ui is a very shell thing..


- Marco


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


On July 22, 2014, 3:40 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119409/
> ---
> 
> (Updated July 22, 2014, 3:40 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> this is the little part in plasma-framework for the applet alternatives 
> chooser.
> works together the branch mart/alternativesConfig of plasma-workspace and 
> plsma-desktop.
> for how it looks and why, see the vdg forum thread:
> https://forum.kde.org/viewtopic.php?f=285&t=122067&p=315919#p315919
> 
> still possible problems:
> * the branch in framework is kinda screwed, too many merges, is probably 
> better to push this diff as a single commit
> * I'm not sure about using a new desktop file entry X-Plasma-Provides, 
> *maybe* Categories could be enough, but it may produce many false positives 
> as well
> 
> 
> Diffs
> -
> 
>   src/plasma/data/servicetypes/plasma-applet.desktop b75c3d6 
>   src/scriptengines/qml/plasmoid/appletinterface.h fe50825 
>   src/scriptengines/qml/plasmoid/appletinterface.cpp e5f7985 
> 
> Diff: https://git.reviewboard.kde.org/r/119409/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 119409: framework part of the applet alternatives shooser

[Aleix Pol Gonzalez]

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



src/scriptengines/qml/plasmoid/appletinterface.cpp


Missing &.



src/scriptengines/qml/plasmoid/appletinterface.cpp


Why can't you just call the method? You're not delaying it


- Aleix Pol Gonzalez


On July 22, 2014, 3:40 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119409/
> ---
> 
> (Updated July 22, 2014, 3:40 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> this is the little part in plasma-framework for the applet alternatives 
> chooser.
> works together the branch mart/alternativesConfig of plasma-workspace and 
> plsma-desktop.
> for how it looks and why, see the vdg forum thread:
> https://forum.kde.org/viewtopic.php?f=285&t=122067&p=315919#p315919
> 
> still possible problems:
> * the branch in framework is kinda screwed, too many merges, is probably 
> better to push this diff as a single commit
> * I'm not sure about using a new desktop file entry X-Plasma-Provides, 
> *maybe* Categories could be enough, but it may produce many false positives 
> as well
> 
> 
> Diffs
> -
> 
>   src/plasma/data/servicetypes/plasma-applet.desktop b75c3d6 
>   src/scriptengines/qml/plasmoid/appletinterface.h fe50825 
>   src/scriptengines/qml/plasmoid/appletinterface.cpp e5f7985 
> 
> Diff: https://git.reviewboard.kde.org/r/119409/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 119409: framework part of the applet alternatives shooser

[Marco Martin]

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

(Updated July 22, 2014, 3:40 p.m.)


Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

this is the little part in plasma-framework for the applet alternatives chooser.
works together the branch mart/alternativesConfig of plasma-workspace and 
plsma-desktop.
for how it looks and why, see the vdg forum thread:
https://forum.kde.org/viewtopic.php?f=285&t=122067&p=315919#p315919

still possible problems:
* the branch in framework is kinda screwed, too many merges, is probably better 
to push this diff as a single commit
* I'm not sure about using a new desktop file entry X-Plasma-Provides, *maybe* 
Categories could be enough, but it may produce many false positives as well


Diffs
-

  src/plasma/data/servicetypes/plasma-applet.desktop b75c3d6 
  src/scriptengines/qml/plasmoid/appletinterface.h fe50825 
  src/scriptengines/qml/plasmoid/appletinterface.cpp e5f7985 

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


Testing
---


Thanks,

Marco Martin

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

Review Request 119409: framework part of the applet alternatives shooser

[Marco Martin]

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

Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

this is the little part in plasma-framework for the applet alternatives chooser.
works together the branch mart/alternativesConfig of plasma-workspace and 
plsma-desktop.
for how it looks and why, see the vdg forum thread:
https://forum.kde.org/viewtopic.php?f=285&t=122067&p=315919#p315919

still possible problems:
* the branch in framework is kinda screwed, too many merges, is probably better 
to push this diff as a single commit
* I'm not sure about using a new desktop file entry X-Plasma-Provides, *maybe* 
Categories could be enough, but it may produce many false positives as well


Diffs
-

  src/plasma/data/servicetypes/plasma-applet.desktop b75c3d6 
  src/scriptengines/qml/plasmoid/appletinterface.h fe50825 
  src/scriptengines/qml/plasmoid/appletinterface.cpp e5f7985 

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


Testing
---


Thanks,

Marco Martin

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

Re: Review Request 119250: Events and trips according to date ranges

[Shantanu Tushar]

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

(Updated July 22, 2014, 3:28 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Repository: plasma-mediacenter


Description
---

I got this idea on a recent trip that usually a family would have a device 
where they store their trips/events photos on. Easier than tagging everything, 
what if you could just say "Hey, I went to Kashmir during 5 April to 14 April 
2014" and voila!

This backend implements this idea in a (hopefully) easy-to-use way. I'll love 
to hear some feedback around this :)


Diffs
-

  browsingbackends/metadatabackends/CMakeLists.txt ae56603 
  browsingbackends/metadatabackends/eventsbackend/CMakeLists.txt PRE-CREATION 
  browsingbackends/metadatabackends/eventsbackend/eventsbackend.cpp 
PRE-CREATION 
  browsingbackends/metadatabackends/eventsbackend/eventsbackend.desktop 
PRE-CREATION 
  browsingbackends/metadatabackends/eventsbackend/eventsbackend.h PRE-CREATION 
  
browsingbackends/metadatabackends/eventsbackend/eventscomponents/DatePicker.qml 
PRE-CREATION 
  browsingbackends/metadatabackends/eventsbackend/eventscomponents/Digit.qml 
PRE-CREATION 
  
browsingbackends/metadatabackends/eventsbackend/eventscomponents/EventsConfiguration.qml
 PRE-CREATION 
  browsingbackends/metadatabackends/eventsbackend/eventscomponents/qmldir 
PRE-CREATION 
  browsingbackends/metadatabackends/eventsbackend/eventsfiltermodel.h 
PRE-CREATION 
  browsingbackends/metadatabackends/eventsbackend/eventsfiltermodel.cpp 
PRE-CREATION 
  browsingbackends/metadatabackends/eventsbackend/eventsmodel.h PRE-CREATION 
  browsingbackends/metadatabackends/eventsbackend/eventsmodel.cpp PRE-CREATION 
  browsingbackends/metadatabackends/eventsbackend/eventspicturesmodel.h 
PRE-CREATION 
  browsingbackends/metadatabackends/eventsbackend/eventspicturesmodel.cpp 
PRE-CREATION 
  browsingbackends/onlineservices/picasa/picasabackend.h 83b3eb2 
  browsingbackends/onlineservices/picasa/picasabackend.cpp b01ba4a 
  browsingbackends/onlineservices/picasa/picasacomponents/PicasaSidePanel.qml 
d15a46e 
  libs/mediacenter/abstractbrowsingbackend.h 14ad502 
  libs/mediacenter/abstractbrowsingbackend.cpp 6cd32f8 
  libs/mediacenter/backendsmodel.cpp 2823fb6 
  libs/mediacenter/filtermediamodel.h b8272f6 
  mediaelements/mediabrowser/MediaBrowser.qml b4ebdf9 
  shells/newshell/package/contents/ui/mediacenter.qml 15c9cee 

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


Testing
---

Seems to work as expected, I will be attaching screenshots.


File Attachments


Showing events
  
https://git.reviewboard.kde.org/media/uploaded/files/2014/07/12/c4c99bbd-f77f-4167-922e-79f90949040b__events.png
Showing photos from an event
  
https://git.reviewboard.kde.org/media/uploaded/files/2014/07/12/a4ed7663-64b6-4963-aed3-5e41cc8e51ee__showing-event.png
Editing dates of an existing event
  
https://git.reviewboard.kde.org/media/uploaded/files/2014/07/12/965b667b-e209-44a3-bc64-95f81b18913e__editing-event.png


Thanks,

Shantanu Tushar

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

Re: Review Request 119406: Always take the painter based path for composeOverBorder

[Aleix Pol Gonzalez]

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


+1, this escentially means that it now will use the same code as it used in 
5.0, so no regressions at least.

It means though, that everything that has composeOverBorders will be rendered 
by the CPU rather than the GPU.

- Aleix Pol Gonzalez


On July 22, 2014, 2:24 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119406/
> ---
> 
> (Updated July 22, 2014, 2:24 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Always take the painter based path for composeOverBorder
> 
> We previously only supported compose-over-border when the centre was not
> set to tile.
> 
> A recent change to the breeze theme put everything into tiling, even if
> some things used compose-over-border, which broke opaque widgets.
> 
> Given that creating an opacityMask loads most of the image anyway, we
> can make use of the FrameSVG painter path and avoid any additional code
> complexity here.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/framesvgitem.cpp a5fe315 
> 
> Diff: https://git.reviewboard.kde.org/r/119406/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Review Request 119406: Always take the painter based path for composeOverBorder

[David Edmundson]

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

Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

Always take the painter based path for composeOverBorder

We previously only supported compose-over-border when the centre was not
set to tile.

A recent change to the breeze theme put everything into tiling, even if
some things used compose-over-border, which broke opaque widgets.

Given that creating an opacityMask loads most of the image anyway, we
can make use of the FrameSVG painter path and avoid any additional code
complexity here.


Diffs
-

  src/declarativeimports/core/framesvgitem.cpp a5fe315 

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


Testing
---


Thanks,

David Edmundson

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

Re: Review Request 119402: Remove unused dependencies.

[Michael Palimaka]

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

(Updated July 22, 2014, 1:52 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Repository: powerdevil


Description
---

- KF5WindowSystem is only used by xlibandxrandr.h, which is no longer has any 
references to it.
- KF5Plasma is unused, presumably since plasmashell was moved to 
plasma-workspace
- Cleanup XCB requirements to what is actually used


Diffs
-

  CMakeLists.txt c80465709a701e9703405ac9e6b7c91f08d0db1f 

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


Testing
---

Inspected source. Builds.


Thanks,

Michael Palimaka

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

Re: Review Request 119402: Remove unused dependencies.

[Aleix Pol Gonzalez]

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

Ship it!


Ship It!

- Aleix Pol Gonzalez


On July 22, 2014, 11:57 a.m., Michael Palimaka wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119402/
> ---
> 
> (Updated July 22, 2014, 11:57 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: powerdevil
> 
> 
> Description
> ---
> 
> - KF5WindowSystem is only used by xlibandxrandr.h, which is no longer has any 
> references to it.
> - KF5Plasma is unused, presumably since plasmashell was moved to 
> plasma-workspace
> - Cleanup XCB requirements to what is actually used
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt c80465709a701e9703405ac9e6b7c91f08d0db1f 
> 
> Diff: https://git.reviewboard.kde.org/r/119402/diff/
> 
> 
> Testing
> ---
> 
> Inspected source. Builds.
> 
> 
> Thanks,
> 
> Michael Palimaka
> 
>

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

Re: Review Request 119384: Plasma-Active: Make widget explorer more friendly on touch devices.

[Antonis Tsiapaliokas]

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

(Updated July 22, 2014, 1:41 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma and Marco Martin.


Repository: plasma-mobile


Description
---

This patch make the widget explorer more friendly on touch devices.


Diffs
-

  activeshellpackage/package/contents/explorer/AppletDelegate.qml 35c62fc 
  activeshellpackage/package/contents/explorer/Tooltip.qml 0eafa19 
  activeshellpackage/package/contents/explorer/WidgetExplorer.qml 9ad9b88 
  activeshellpackage/package/contents/views/Desktop.qml 6582fd7 

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


Testing
---


File Attachments


widget exploer
  
https://git.reviewboard.kde.org/media/uploaded/files/2014/07/21/522038d2-b4da-4c34-9d9c-11aa5666fe8d__widgetexplorer.png


Thanks,

Antonis Tsiapaliokas

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

Review Request 119404: Use full libexec location

[Hrvoje Senjan]

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

Review request for Plasma.


Repository: plasma-workspace


Description
---

resolves the problem of relative vs. absolute LIBEXEC_INSTALL_DIR var usage.


Diffs
-

  ksmserver/config-ksmserver.h.cmake a454a4d 
  startkde/startkde.cmake 281bd43 

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


Testing
---

builds


Thanks,

Hrvoje Senjan

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

Review Request 119402: Remove unused dependencies.

[Michael Palimaka]

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

Review request for Plasma.


Repository: powerdevil


Description
---

- KF5WindowSystem is only used by xlibandxrandr.h, which is no longer has any 
references to it.
- KF5Plasma is unused, presumably since plasmashell was moved to 
plasma-workspace
- Cleanup XCB requirements to what is actually used


Diffs
-

  CMakeLists.txt c80465709a701e9703405ac9e6b7c91f08d0db1f 

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


Testing
---

Inspected source. Builds.


Thanks,

Michael Palimaka

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

Re: Fallbacks for packages

[Marco Martin]

On Tuesday 22 July 2014 11:27:48 Sebastian Kügler wrote:
> > And a last one, would be to just use two packages in the client code. It
> > would  be the solution i would normally prefer, but since the look and
> > feel
> > package is accessed by too many different processes, entry points, it
> > would
> > mean a lot of duplication of error prone code.
> > 
> > opinions? comments?
> 
> I think the main problem with one, or a hardcoded fallback is that, we might
> not always want to fall back to for example the desktop shell, or do we?
> People might want to customize certain aspects of the shell, and then want
> to fall back on the tablet or desktop shell, depending. I've been wondering
> how we can express that. For that reason, I think we might need a flexible
> fallback, which means solution 1 you propose.

yeah, seems useful in many situations.
however, the concern i have is the following:
basically, any plasmoid being able to depend from nay other plasmoid..
so any random change, would break the depending plasmoids. This violates the 
isolation promise that is one of the points o Package..

thinking..
there should be something to define that the package can be used as a 
fallback.. may depend from the package structure so only some types of 
packages would allow it, or the package providing a file that contains a 
whitelist of files it can expose..
hmm

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

[plasma-framework] src/desktoptheme/breeze: Optimize breeze theme

[Aleix Pol]

Git commit 0b1bb7edd84b77c4cf5baae8f9e59473c9265f26 by Aleix Pol.
Committed on 22/07/2014 at 10:59.
Pushed by apol into branch 'master'.

Optimize breeze theme

Breeze theme usually has borders and center that can be tiled, which
ends up in more performant rendering, as we don't need to re-render
anything from the svg every time we resize an element.

Basically what we did was "s/hint-stretch-borders/hint-tile-center/g".
The only exceptions we found for this were: picker, dragger and monitor.

Reviewed by David Edmundson

CCMAIL: plasma-devel@kde.org

M  +---src/desktoptheme/breeze/dialogs/background.svgz
M  +---src/desktoptheme/breeze/opaque/dialogs/background.svgz
M  +---src/desktoptheme/breeze/opaque/widgets/panel-background.svgz
M  +---src/desktoptheme/breeze/opaque/widgets/tooltip.svgz
M  +---src/desktoptheme/breeze/translucent/dialogs/background.svgz
M  +---src/desktoptheme/breeze/translucent/widgets/panel-background.svgz
M  +---src/desktoptheme/breeze/translucent/widgets/tooltip.svgz
M  +---src/desktoptheme/breeze/widgets/action-overlays.svgz
M  +---src/desktoptheme/breeze/widgets/actionbutton.svgz
M  +---src/desktoptheme/breeze/widgets/analog_meter.svgz
M  +---src/desktoptheme/breeze/widgets/arrows.svgz
M  +---src/desktoptheme/breeze/widgets/background.svgz
M  +---src/desktoptheme/breeze/widgets/bar_meter_horizontal.svgz
M  +---src/desktoptheme/breeze/widgets/bar_meter_vertical.svgz
M  +---src/desktoptheme/breeze/widgets/branding.svgz
M  +---src/desktoptheme/breeze/widgets/busywidget.svgz
M  +---src/desktoptheme/breeze/widgets/button.svgz
M  +---src/desktoptheme/breeze/widgets/calendar.svgz
M  +---src/desktoptheme/breeze/widgets/checkmarks.svgz
M  +---src/desktoptheme/breeze/widgets/clock.svgz
M  +---src/desktoptheme/breeze/widgets/configuration-icons.svgz
M  +---src/desktoptheme/breeze/widgets/containment-controls.svgz
M  +---src/desktoptheme/breeze/widgets/frame.svgz
M  +---src/desktoptheme/breeze/widgets/glowbar.svgz
M  +---src/desktoptheme/breeze/widgets/line.svgz
M  +---src/desktoptheme/breeze/widgets/lineedit.svgz
M  +---src/desktoptheme/breeze/widgets/listitem.svgz
M  +---src/desktoptheme/breeze/widgets/media-delegate.svgz
M  +---src/desktoptheme/breeze/widgets/pager.svgz
M  +---src/desktoptheme/breeze/widgets/panel-background.svgz
M  +---src/desktoptheme/breeze/widgets/plot-background.svgz
M  +---src/desktoptheme/breeze/widgets/scrollbar.svgz
M  +---src/desktoptheme/breeze/widgets/scrollwidget.svgz
M  +---src/desktoptheme/breeze/widgets/slider.svgz
M  +---src/desktoptheme/breeze/widgets/tabbar.svgz
M  +---src/desktoptheme/breeze/widgets/tasks.svgz
M  +---src/desktoptheme/breeze/widgets/toolbar.svgz
M  +---src/desktoptheme/breeze/widgets/tooltip.svgz
M  +---src/desktoptheme/breeze/widgets/translucentbackground.svgz
M  +---src/desktoptheme/breeze/widgets/viewitem.svgz

http://commits.kde.org/plasma-framework/0b1bb7edd84b77c4cf5baae8f9e59473c9265f26

diff --git a/src/desktoptheme/breeze/dialogs/background.svgz 
b/src/desktoptheme/breeze/dialogs/background.svgz
index 66af710..0053d47 100644
Binary files a/src/desktoptheme/breeze/dialogs/background.svgz and 
b/src/desktoptheme/breeze/dialogs/background.svgz differ
diff --git a/src/desktoptheme/breeze/opaque/dialogs/background.svgz 
b/src/desktoptheme/breeze/opaque/dialogs/background.svgz
index d3b263a..1501447 100644
Binary files a/src/desktoptheme/breeze/opaque/dialogs/background.svgz and 
b/src/desktoptheme/breeze/opaque/dialogs/background.svgz differ
diff --git a/src/desktoptheme/breeze/opaque/widgets/panel-background.svgz 
b/src/desktoptheme/breeze/opaque/widgets/panel-background.svgz
index d7dcae2..8ac1c5b 100644
Binary files a/src/desktoptheme/breeze/opaque/widgets/panel-background.svgz and 
b/src/desktoptheme/breeze/opaque/widgets/panel-background.svgz differ
diff --git a/src/desktoptheme/breeze/opaque/widgets/tooltip.svgz 
b/src/desktoptheme/breeze/opaque/widgets/tooltip.svgz
index d7dcae2..8ac1c5b 100644
Binary files a/src/desktoptheme/breeze/opaque/widgets/tooltip.svgz and 
b/src/desktoptheme/breeze/opaque/widgets/tooltip.svgz differ
diff --git a/src/desktoptheme/breeze/translucent/dialogs/background.svgz 
b/src/desktoptheme/breeze/translucent/dialogs/background.svgz
index c1fbf0d..c0a625f 100644
Binary files a/src/desktoptheme/breeze/translucent/dialogs/background.svgz and 
b/src/desktoptheme/breeze/translucent/dialogs/background.svgz differ
diff --git a/src/desktoptheme/breeze/translucent/widgets/panel-background.svgz 
b/src/desktoptheme/breeze/translucent/widgets/panel-background.svgz
index dce0440..760ec15 100644
Binary files 
a/src/desktoptheme/breeze/translucent/widgets/panel-background.svgz and 
b/src/desktoptheme/

Re: Review Request 118638: Install bzip2 and LZMA filter and documentation based on available support in KArchive.

[Michael Palimaka]

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

(Updated July 22, 2014, 10:57 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Repository: kio-extras


Description
---

Decompression is handled in KArchive; the format libraries are not
used directly.


Diffs
-

  doc/kioslave/CMakeLists.txt d2766d69f92ab28bda08e304dff89d202e0c1d35 
  filter/CMakeLists.txt 240cc7b57bd38e86fd50084e53c17f1672b2b946 

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


Testing
---

Builds and filter/documentation files install as expected depending on what 
KArchive was build with.


Thanks,

Michael Palimaka

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

Re: Review Request 118900: Improve dependencies.

[Michael Palimaka]

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

(Updated July 22, 2014, 10:53 a.m.)


Status
--

This change has been discarded.


Review request for Plasma.


Repository: plasma-workspace


Description
---

KF5WebKit is only used if drkonqi is built with (optional) KF5XmlRpcClient. 
Qt5Concurrent is only required for tests.


Diffs
-

  CMakeLists.txt 4bfa2e93abfc6f8087693c363e5982fa862cf0fa 
  drkonqi/CMakeLists.txt 8224900e633c18f57ac3fbc7e5a77a8f5a34edb0 

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


Testing
---

Inspected source, builds, tests pass.


Thanks,

Michael Palimaka

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

Re: 4.x transition blockage - workspace libs

[Sebastian Kügler]

On Tuesday, July 22, 2014 19:09:26 Michael Palimaka wrote:
> On 07/22/2014 06:10 AM, Martin Gräßlin wrote:
> > On Tuesday 22 July 2014 05:28:36 Michael Palimaka wrote:
> >> On 07/18/2014 06:54 PM, Harald Sitter wrote:
> > wrote:
> >> I'm very interested in renaming libkworkspace in Plasma5 at a minimum.
> >> What do you suggest for the include directory - just kworkspace ->
> >> kworkspace5 or go further and make the whole thing KF5Workspace?
> >> 
> >> I'm happy to provide patches, but didn't so far since there was
> >> resistance to the idea last time it was brought up.
> >
> > Personally I'm very reluctant to the idea of changing the includes. The
> > risk  of us having to hunt down breakage for weeks is IMHO way too high
> > for the possible benefits. We just had it too often during
> > the  frameworks transition that a header file got renamed, missed in one
> > place and it starts to randomly break to compile on some systems because
> > a kde4 header is picked. Then we easily waste huge amounts of work power
> > on people trying to fix their build. That's also the reason why I decided
> > against renaming the headers for KWin.
> That's fair enough, although I note the comparatively low number of
> consumers would limit the scope for breakage.
> 
> I personally think it's worth the effort (and am willing to do the work)
> for certain items because, for example, I can't offer our users the
> ability to run KDE 4-based applications that depend on libkworkspace in
> a Plasma 5 environment. It would be nice if we could, but if we can't,
> we can't.

Co-installability would indeed be very nice.

I wouldn't have much problems with such a change, I think it'd be fairly easy 
to catch on systems that have KDE4 in an entirely different prefix (my 
laptop), or not installed at all, and by our build farm.

libkworkspace would not be a framework, since we don't want to provide the 
guarantees for API and ABI, a libkworkspace works exactly for the release it's 
shipped with. That means just adding 5 to the name is good enough.

I'd also not complain if I have to fix the occasional build breaking.

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: Review Request 119330: Convert FrameSvgItem to use 9 tiles instead of a big texture.

[Sebastian Kügler]

On Monday, July 21, 2014 19:07:52 Martin Gräßlin wrote:
> On Monday 21 July 2014 16:40:48 David Edmundson wrote:
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > https://git.reviewboard.kde.org/r/119330/
> > ---

> > This change has been marked as submitted.
> 
> congrats! And thanks to everyone involved to be patient about it.

That struck me as well. Nice work, guys!
-- 
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: Fallbacks for packages

[Sebastian Kügler]

On Monday, July 21, 2014 11:26:58 Marco Martin wrote:
> I have been thinking about the problem of the look and feel and shell 
> packages: we want them to be easily customizable for distributions without 
> forcing to copy and paste the mayority of the qml in the package (and also 
> having things like providing only a spashscreen and nothing else)
> 
> so when a different look and feel package is configured, when a file is not 
> found there, it should be checked for in the default one instead.
> 
> some different scenarios/ideas popped in mind:
> 
> Completely generic: in the package desktop file there is the name of
> another  one used as fallback
> Pros:
> * very flexible, easy way to share code between plasmoids (like various 
> taskbars)
> Cons:
> * all packages become public api, maintainace nightmare
> * possibility of circular dependencies
> 
> One partial solution would be limiting the allowed fallbacks only to
> packages  that start with org.kde.* , but seems quite ineffective, in
> reality.
> 
> Another solution is to have a single one default package to fallback,
> (defined  in the packagestructure) so in case of lookandfeel the base
> org.kde.lookandfeel would be the fallback and no other one could be used.
> It's limited, but (for this very reason) i very much prefer this.
> The drawback is that it could be used for lookandfeel and for the shell 
> packages, but *not* for plasmoids.
> 
> And a last one, would be to just use two packages in the client code. It
> would  be the solution i would normally prefer, but since the look and feel
> package is accessed by too many different processes, entry points, it would
> mean a lot of duplication of error prone code.
> 
> opinions? comments?

I think the main problem with one, or a hardcoded fallback is that, we might 
not always want to fall back to for example the desktop shell, or do we? 
People might want to customize certain aspects of the shell, and then want to 
fall back on the tablet or desktop shell, depending. I've been wondering how 
we can express that. For that reason, I think we might need a flexible 
fallback, which means solution 1 you propose.
-- 
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: 4.x transition blockage - workspace libs

[Michael Palimaka]

On 07/22/2014 06:10 AM, Martin Gräßlin wrote:
> On Tuesday 22 July 2014 05:28:36 Michael Palimaka wrote:
>> On 07/18/2014 06:54 PM, Harald Sitter wrote:
>>> On Thu, Jul 17, 2014 at 1:37 PM, Michael Palimaka  
> wrote:
> I  just discused this with mgraesslin on IRC and he's fine with adding
> a compatibility build flag to 4.x that makes it only install the
> necessary libraries to avoid file conflicts with plasma-workspace 5.
>
> Does that sounds suitable for gentoo and if so, do you guys want to
> come up with a patch? :)

 I'm very interested in this, but what did you have in mind - a collision
 is a collision, right?
>>>
>>> As far as I can tell the colliding bits are:
>>> a) certain binaries/data/nonesense
>>> b) all libfoo.so files
>>> c) the include directories (assuming neither plasma5 nor kde-workspace
>>> were put in an explicit subdir)
>>>
>>> So, to get the first collision out of the way kde-workspace needs a
>>> flag to not build or install those bits (i.e. build in a library
>>> compatibility mode).
>>>
>>> The latter two could be addressed by renaming the libraries in plasma5
>>> to libkworkspace5.so etc. and respective include directory names. What
>>> I am not sure about here is whether there are more suitable
>>> distro-level solutions to this. Surely libfoo.so (libfoo.so.0) and
>>> libfoo.so (libfoo.so.1) conflicting cannot be a new issue, so I do
>>> wonder how this would be resolved in general.
>>>
>>> HS
>>
>> I'm very interested in renaming libkworkspace in Plasma5 at a minimum.
>> What do you suggest for the include directory - just kworkspace ->
>> kworkspace5 or go further and make the whole thing KF5Workspace?
>>
>> I'm happy to provide patches, but didn't so far since there was
>> resistance to the idea last time it was brought up.
> 
> Personally I'm very reluctant to the idea of changing the includes. The risk 
> of us having to hunt down breakage for weeks is IMHO way too high for the 
> possible benefits. We just had it too often during the  frameworks transition 
> that a header file got renamed, missed in one place and it starts to randomly 
> break to compile on some systems because a kde4 header is picked. Then we 
> easily waste huge amounts of work power on people trying to fix their build. 
> That's also the reason why I decided against renaming the headers for KWin.

That's fair enough, although I note the comparatively low number of
consumers would limit the scope for breakage.

I personally think it's worth the effort (and am willing to do the work)
for certain items because, for example, I can't offer our users the
ability to run KDE 4-based applications that depend on libkworkspace in
a Plasma 5 environment. It would be nice if we could, but if we can't,
we can't.

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