[Differential] [Updated, 45 lines] D2306: Make it possible to provide a page header to ScrollablePage

[apol (Aleix Pol Gonzalez)]

apol updated this revision to Diff 5549.
apol added a comment.


  Fix naming

REPOSITORY
  rKIRIGAMI Kirigami

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D2306?vs=5547=5549

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D2306

AFFECTED FILES
  examples/gallery/contents/ui/gallery/ListViewGallery.qml
  src/controls/ScrollablePage.qml

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: apol, #kirigami, mart
Cc: plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Closed] D2295: improve logging for kscreen

[Sebastian Kügler]

This revision was automatically updated to reflect the committed changes.
sebas marked an inline comment as done.
Closed by commit rLIBKSCREEN08df8462efd9: unit test Log::context (authored by 
sebas).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D2295?vs=5538=5548#toc

REPOSITORY
  rLIBKSCREEN KScreen Library

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D2295?vs=5538=5548

REVISION DETAIL
  https://phabricator.kde.org/D2295

AFFECTED FILES
  autotests/testlog.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: sebas, bshah, #plasma
Cc: davidedmundson, bshah, plasma-devel, ali-mohamed, jensreuterberg, abetts, 
sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Updated, 45 lines] D2306: Make it possible to provide a page header to ScrollablePage

[apol (Aleix Pol Gonzalez)]

apol updated this revision to Diff 5547.
apol added a comment.


  Add api documentation

REPOSITORY
  rKIRIGAMI Kirigami

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D2306?vs=5546=5547

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D2306

AFFECTED FILES
  examples/gallery/contents/ui/gallery/ListViewGallery.qml
  src/controls/ScrollablePage.qml

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: apol, #kirigami, mart
Cc: plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Is it possible to know when a PlasmaCore IconItem is ready?

[Michail Vourlakos]

>
>> for DropShadow and the animation for hover to add it
>> in the PlasmaCore.IconItem right?
>>
>
> I'd put the animation in the DropShadow itself and scale that.
>
> I bet changing the size of a ShaderEffectSource triggers a re-render, and
> that's why you see the performance hit.
>
> Currently you're changing the iconImageBuffer but the QSGTextureProvider it
> created will just remain static.
>

the following code drops my performance to half comparing to the
Images solution,
do I miss something? :


DropShadow {
id:shadowImageNoActive

width: 64
height: 64

scale: wrapper.scale * wrapper.appearScale

anchors.centerIn: parent

radius: 7.0
samples: 10
color: "#90080808"
source: ShaderEffectSource {
id:effectSource
width: iconImage.width
height: iconImage.height
sourceItem: iconImage
hideSource: true
live: false
}

PlasmaCore.IconItem {
id: iconImage

width:64
height:64

anchors.centerIn: parent

active: true
enabled: true
usesPlasmaTheme: false

source: decoration

}

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

[Differential] [Request, 40 lines] D2306: Make it possible to provide a page header to ScrollablePage

[apol (Aleix Pol Gonzalez)]

apol created this revision.
apol added reviewers: Kirigami, mart.
Restricted Application added a project: Kirigami.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  Sometimes we show some information on top of a flickable that goes away as
  soon as the user scrolls down.
  This introduces a property that offers a component to be shown when the view
  is scrolled, optionally of course.

TEST PLAN
  Extends the ListView example. Been tested locally on Discover.

REPOSITORY
  rKIRIGAMI Kirigami

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D2306

AFFECTED FILES
  examples/gallery/contents/ui/gallery/ListViewGallery.qml
  src/controls/ScrollablePage.qml

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: apol, #kirigami, mart
Cc: plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Closed] D2305: Prefer alias to new property

[apol (Aleix Pol Gonzalez)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rKIRIGAMI69d297937b01: Prefer alias to new property (authored 
by apol).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D2305?vs=5541=5543#toc

REPOSITORY
  rKIRIGAMI Kirigami

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D2305?vs=5541=5543

REVISION DETAIL
  https://phabricator.kde.org/D2305

AFFECTED FILES
  src/controls/BasicListItem.qml

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: apol, #kirigami, mart
Cc: plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Accepted] D2305: Prefer alias to new property

[mart (Marco Martin)]

mart accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  rKIRIGAMI Kirigami

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D2305

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: apol, #kirigami, mart
Cc: plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Closed] D2219: Add option to enable volume feedback

[drosca (David Rosca)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rPLASMAPA6814a96da412: Add option to enable volume feedback 
(authored by drosca).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D2219?vs=5299=5542#toc

REPOSITORY
  rPLASMAPA Plasma Audio Volume Applet

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D2219?vs=5299=5542

REVISION DETAIL
  https://phabricator.kde.org/D2219

AFFECTED FILES
  CMakeLists.txt
  applet/contents/config/main.xml
  applet/contents/ui/ConfigGeneral.qml
  applet/contents/ui/ListItemBase.qml
  applet/contents/ui/main.qml
  cmake/FindCanberra.cmake
  src/qml/CMakeLists.txt
  src/qml/plugin.cpp
  src/qml/volumefeedback.cpp
  src/qml/volumefeedback.h

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: drosca, #plasma:_design, #plasma, sebas
Cc: colomar, sebas, plasma-devel, ali-mohamed, jensreuterberg, abetts
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Request, 4 lines] D2305: Prefer alias to new property

[apol (Aleix Pol Gonzalez)]

apol created this revision.
apol added reviewers: Kirigami, mart.
Restricted Application added a project: Kirigami.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  It's better to just have a property aliased than duplicating it. Both for 
readability and performance

REPOSITORY
  rKIRIGAMI Kirigami

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D2305

AFFECTED FILES
  src/controls/BasicListItem.qml

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: apol, #kirigami, mart
Cc: plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Updated] D1816: Switch to Hack as default monospace font

[Sebastian Kügler]

sebas added a reviewer: dhaumann.
sebas added a comment.


  @dhaumann Does this font satisfy your concerns?

REVISION DETAIL
  https://phabricator.kde.org/D1816

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: jriddell, #plasma, #plasma:_design, dhaumann
Cc: sebas, mak, jensreuterberg, palimaka, dhaumann, mart, davidedmundson, 
plasma-devel, ali-mohamed, abetts
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Closed] D2294: categorized logging for kscreen kcm

[Sebastian Kügler]

This revision was automatically updated to reflect the committed changes.
Closed by commit rKSCREENca49b5309ca7: categorized logging for kscreen kcm 
(authored by sebas).

REPOSITORY
  rKSCREEN KScreen

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D2294?vs=5512=5539

REVISION DETAIL
  https://phabricator.kde.org/D2294

AFFECTED FILES
  kcm/src/CMakeLists.txt
  kcm/src/controlpanel.cpp
  kcm/src/debug.cpp
  kcm/src/debug.h
  kcm/src/kcm_kscreen.cpp
  kcm/src/outputconfig.cpp
  kcm/src/unifiedoutputconfig.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: sebas, #plasma, bshah
Cc: bshah, davidedmundson, plasma-devel, ali-mohamed, jensreuterberg, abetts, 
sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D2219: Add option to enable volume feedback

[drosca (David Rosca)]

drosca added a comment.


  > Can we expect canberra to be available everywhere PA is?
  
  KF5 kmix has it as non-optional dependency too, so I think that should not be 
issue.
  
  > Is the feedback only played when there is no other source playing?
  
  It's played even if there is something playing. It uses the notification 
sounds event type, so if the user has it muted there will be no volume feedback 
sound even when enabled.
  Also it is not trivial to detect if there is nothing playing, user may have 
for example some app that sets very low volume for its stream, or even there 
may be stream that is playing silence.

REPOSITORY
  rPLASMAPA Plasma Audio Volume Applet

REVISION DETAIL
  https://phabricator.kde.org/D2219

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: drosca, #plasma, #plasma:_design
Cc: colomar, sebas, plasma-devel, ali-mohamed, jensreuterberg, abetts
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D2295: improve logging for kscreen

[Sebastian Kügler]

sebas added inline comments.

INLINE COMMENTS

> davidedmundson wrote in log.cpp:136
> why call instance() from inside a member function?
> it'll always return this.

Log::log(...) is static.

REPOSITORY
  rLIBKSCREEN KScreen Library

BRANCH
  sebas/log

REVISION DETAIL
  https://phabricator.kde.org/D2295

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: sebas, bshah, #plasma
Cc: davidedmundson, bshah, plasma-devel, ali-mohamed, jensreuterberg, abetts, 
sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Accepted] D2219: Add option to enable volume feedback

[Sebastian Kügler]

sebas accepted this revision.
sebas added a reviewer: sebas.
sebas added a comment.
This revision is now accepted and ready to land.


  In https://phabricator.kde.org/D2219#42920, @drosca wrote:
  
  > > Can we expect canberra to be available everywhere PA is?
  >
  > KF5 kmix has it as non-optional dependency too, so I think that should not 
be issue.
  
  
  Okay, I think it's OK then.

REPOSITORY
  rPLASMAPA Plasma Audio Volume Applet

BRANCH
  volume-feedback (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D2219

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: drosca, #plasma:_design, #plasma, sebas
Cc: colomar, sebas, plasma-devel, ali-mohamed, jensreuterberg, abetts
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D2219: Add option to enable volume feedback

[Sebastian Kügler]

sebas added a comment.


  In https://phabricator.kde.org/D2219#42870, @colomar wrote:
  
  > Is the feedback only played when there is no other source playing?
  >  If not, it should be done like that. If you already have something 
playing, it's just annoying to play an additional sound, and does not provide 
any additional info because you notice how loud whatever is playing plays.
  
  
  I don't think it's technically feasible to detect if something else is 
playing. In general, I agree, but once you look closer, it's really 
complicated, too complicated, in fact.

REPOSITORY
  rPLASMAPA Plasma Audio Volume Applet

REVISION DETAIL
  https://phabricator.kde.org/D2219

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: drosca, #plasma, #plasma:_design
Cc: colomar, sebas, plasma-devel, ali-mohamed, jensreuterberg, abetts
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Updated, 416 lines] D2295: improve logging for kscreen

[Sebastian Kügler]

sebas updated this revision to Diff 5538.
sebas marked 2 inline comments as done.
sebas added a comment.


  - Address comments from David's review

REPOSITORY
  rLIBKSCREEN KScreen Library

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D2295?vs=5514=5538

BRANCH
  sebas/log

REVISION DETAIL
  https://phabricator.kde.org/D2295

AFFECTED FILES
  autotests/CMakeLists.txt
  autotests/testbackendloader.cpp
  autotests/testconfigmonitor.cpp
  autotests/testinprocess.cpp
  autotests/testkwaylandbackend.cpp
  autotests/testkwaylandconfig.cpp
  autotests/testlog.cpp
  autotests/testqscreenbackend.cpp
  autotests/testscreenconfig.cpp
  src/CMakeLists.txt
  src/backendlauncher/main.cpp
  src/backendmanager.cpp
  src/getconfigoperation.cpp
  src/log.cpp
  src/log.h

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: sebas, bshah, #plasma
Cc: davidedmundson, bshah, plasma-devel, ali-mohamed, jensreuterberg, abetts, 
sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D2295: improve logging for kscreen

[Sebastian Kügler]

sebas added inline comments.

INLINE COMMENTS

> davidedmundson wrote in log.cpp:30
> why have it separate instead of a member of log?

I just tried making it a member, but running into problems.

QtMessageHandler is a typedef'ed function pointer,  not a class. If I add a 
static member in my Log class for it, it screws up my header.

I think we need to keep this as is (which arguably is nicer, anyway, since it 
keeps QtMessageHandler outside of the header, and thus the API.

REPOSITORY
  rLIBKSCREEN KScreen Library

BRANCH
  sebas/log

REVISION DETAIL
  https://phabricator.kde.org/D2295

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: sebas, #plasma, bshah
Cc: davidedmundson, bshah, plasma-devel, ali-mohamed, jensreuterberg, abetts, 
sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Is it possible to know when a PlasmaCore IconItem is ready?

[David Edmundson]

On Thu, Jul 28, 2016 at 1:08 PM, Michail Vourlakos 
wrote:

> David, I had tried it some iterations before in my code path, it wasnt
> as equally performant as the Images solution, I will give it one more
> try...
>

> I suppose you are proposing to drop Images, add a ShaderEffectSource
> with live:false


Yes.


> for DropShadow and the animation for hover to add it
> in the PlasmaCore.IconItem right?
>

I'd put the animation in the DropShadow itself and scale that.

I bet changing the size of a ShaderEffectSource triggers a re-render, and
that's why you see the performance hit.

Currently you're changing the iconImageBuffer but the QSGTextureProvider it
created will just remain static.





>  PlasmaCore.IconItem {
>  id: iconImage
>  width: 2 * panel.iconSize - 8
>  height: 2 * panel.iconSize - 8
>
> property int newTempSize: Math.floor(panel.iconSize *
> wrapper.scale * wrapper.appearScale)
> width: newTempSize
> height: newTempSize
>
>
>
> On 7/28/16, David Edmundson  wrote:
> > ShaderEffectSource with live:false should be equally performant as this
> (if
> > anything more so).
> > It /should/ also fix your code.
> >
> > Then call scheduleUpdate() whenever onSourceChanged is emitted.
> >
> > We load the pixmap in the polish() event which happens between all QML
> > processing and the frame being rendered.
> > There's no timer.
> >
> ___
> 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

[Differential] [Commented On] D2295: improve logging for kscreen

[Sebastian Kügler]

sebas added inline comments.

INLINE COMMENTS

> davidedmundson wrote in log.cpp:46
> It doesn't matter if there are threads *in* kscreen.
> 
> The question is: Can a kscreen class be used *in* another thread by $app.

That's what I meant, it's not designed to be thread-safe at all. The backends 
have static members, too, so this pattern isn't exclusive to this class at all.

> davidedmundson wrote in log.cpp:137
> Edit:  Some googling suggests this is fine as-is.
> 
> O_APPEND writes are atomic on local filesystems, and will lock between 
> updating the offset and the end of the write.
> 
> Providing Qt does everything as one write() which it probably will for lines 
> less than ~512bytes or so.

Cool. Thanks for checking this.

REPOSITORY
  rLIBKSCREEN KScreen Library

BRANCH
  sebas/log

REVISION DETAIL
  https://phabricator.kde.org/D2295

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: sebas, #plasma, bshah
Cc: davidedmundson, bshah, plasma-devel, ali-mohamed, jensreuterberg, abetts, 
sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Is it possible to know when a PlasmaCore IconItem is ready?

[Michail Vourlakos]

The IconItem to be done... scale, and appearScale create the hover animation:

PlasmaCore.IconItem {
 id: iconImage
property int newTempSize: Math.floor(panel.iconSize *
wrapper.scale * wrapper.appearScale)
width: newTempSize
height: newTempSize



On 7/28/16, Michail Vourlakos  wrote:
> David, I had tried it some iterations before in my code path, it wasnt
> as equally performant as the Images solution, I will give it one more
> try...
>
> I suppose you are proposing to drop Images, add a ShaderEffectSource
> with live:false for DropShadow and the animation for hover to add it
> in the PlasmaCore.IconItem right?
>
>  PlasmaCore.IconItem {
>  id: iconImage
>  width: 2 * panel.iconSize - 8
>  height: 2 * panel.iconSize - 8
>
> property int newTempSize: Math.floor(panel.iconSize *
> wrapper.scale * wrapper.appearScale)
> width: newTempSize
> height: newTempSize
>
>
>
> On 7/28/16, David Edmundson  wrote:
>> ShaderEffectSource with live:false should be equally performant as this
>> (if
>> anything more so).
>> It /should/ also fix your code.
>>
>> Then call scheduleUpdate() whenever onSourceChanged is emitted.
>>
>> We load the pixmap in the polish() event which happens between all QML
>> processing and the frame being rendered.
>> There's no timer.
>>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Is it possible to know when a PlasmaCore IconItem is ready?

[Michail Vourlakos]

David, I had tried it some iterations before in my code path, it wasnt
as equally performant as the Images solution, I will give it one more
try...

I suppose you are proposing to drop Images, add a ShaderEffectSource
with live:false for DropShadow and the animation for hover to add it
in the PlasmaCore.IconItem right?

 PlasmaCore.IconItem {
 id: iconImage
 width: 2 * panel.iconSize - 8
 height: 2 * panel.iconSize - 8

property int newTempSize: Math.floor(panel.iconSize *
wrapper.scale * wrapper.appearScale)
width: newTempSize
height: newTempSize



On 7/28/16, David Edmundson  wrote:
> ShaderEffectSource with live:false should be equally performant as this (if
> anything more so).
> It /should/ also fix your code.
>
> Then call scheduleUpdate() whenever onSourceChanged is emitted.
>
> We load the pixmap in the polish() event which happens between all QML
> processing and the frame being rendered.
> There's no timer.
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Is it possible to know when a PlasmaCore IconItem is ready?

[David Edmundson]

ShaderEffectSource with live:false should be equally performant as this (if
anything more so).
It /should/ also fix your code.

Then call scheduleUpdate() whenever onSourceChanged is emitted.

We load the pixmap in the polish() event which happens between all QML
processing and the frame being rendered.
There's no timer.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Is it possible to know when a PlasmaCore IconItem is ready?

[Michail Vourlakos]

Image {
id: iconImageBuffer

property int newTempSize: Math.floor(panel.iconSize *
wrapper.scale * wrapper.appearScale)
width: newTempSize
height: newTempSize

anchors.centerIn: parent

source: (wrapper.containsMouse === true)  ? activeIcon.source
: simpleIcon.source
opacity: 0

onSourceChanged: {
opacity = 1;
}

Behavior on opacity {
NumberAnimation { duration: 200 }
}

}

Image{
id:activeIcon
visible:false
}

Component.onCompleted: {
helper.createObject(this);
}

//

// Buffers an active icon into Image, activeIcon
Component {
 id: helper
 Item {
 id: yourImageWithLoadedIconContainer
 anchors.fill: parent

 PlasmaCore.IconItem {
 id: iconImage
 width: 2 * panel.iconSize - 8
 height: 2 * panel.iconSize - 8

 active: true
 enabled: true
 usesPlasmaTheme: false

 source: decoration

 visible: false

// timer taking the appearance of the image with shadow in it
 Timer{
 id:ttt
 repeat:false
 interval: 1
 onTriggered: {
 shadowImageNoActive.grabToImage(function(result) {
 activeIcon.source = result.url;
 }, Qt.size(iconImage.width,iconImage.height) );
 ttt2.start();
 }
 }

 // timer destroying the component
 Timer{
 id:ttt2
 repeat:false
 interval: 100
 onTriggered: {
 yourImageWithLoadedIconContainer.destroy();
 }
 }

// starting the first timer
Component.onCompleted: {
 ttt.start();
 }
 }
 DropShadow {
 id:shadowImageNoActive
 visible:false
 width: 2 * panel.iconSize
 height: 2 * panel.iconSize
 anchors.centerIn: iconImage


 radius: 7.0
 samples: 10
 color: "#aa080808"
 source: iconImage
 }
 } // to be destoyed
 } // helper Component


On 7/28/16, Sebastian Kügler  wrote:
> On donderdag 28 juli 2016 14:03:24 CEST Michail Vourlakos wrote:
>> is it possible to know when a PlasmaCore IconItem in QML is ready?
>> I am trying to use the grabToImage for that element and the only way
>> to achieve this until now, is after Component.OnCompleted to use a
>> timer element.
>>
>> I use a shadereffect to drop a shadow under various IconItems and
>> after that I animate them on hovering. By buffering them into Images
>> and animating these Images instead of the IconItems the interface
>> improves its respovinesss almost to double or even more.
>>
>> So is there a way to drop the Timer for these IconItems by creating
>> the needed buffers when the IconItem is ready? With Images this can be
>> done with onStatusChanged: if (status==Image.Ready)
>
> Could you post some code illustrating what you're trying to do? This makes
> it
> a bit easier to understand and more concrete to propose a solution. (Not
> that
> I know one, off-hand.)
>
> Cheers,
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: multiscreen logging

[David Kahles]

Hi,
Am Donnerstag, 28. Juli 2016 12:23:56 CEST schrieb Sebastian Kügler:

On donderdag 28 juli 2016 01:18:00 CEST David Kahles wrote:

I think the problem with this approach is, that most (or even all?) of
these processes aren't units but simple processes.
A better approach using the power of journald would be something like:

journalctl -b --user _COMM=plasmashell + _COMM=kded5 
QT_CATEGORY=kscreen + 
  _COMM=systemsettings5 + 
_COMM=kscreen_backend


I may add that this makes it a lot more complex for the user 
than just sending 
me a single, combined log file.


Also, what about users without journalctl?


I don't think that executing a one-liner is a lot more complex.
But this won't work for users without journalctl, I didn't think about 
that.

Therefore I think we should go with your solution.

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

Re: Is it possible to know when a PlasmaCore IconItem is ready?

[Sebastian Kügler]

On donderdag 28 juli 2016 14:03:24 CEST Michail Vourlakos wrote:
> is it possible to know when a PlasmaCore IconItem in QML is ready?
> I am trying to use the grabToImage for that element and the only way
> to achieve this until now, is after Component.OnCompleted to use a
> timer element.
> 
> I use a shadereffect to drop a shadow under various IconItems and
> after that I animate them on hovering. By buffering them into Images
> and animating these Images instead of the IconItems the interface
> improves its respovinesss almost to double or even more.
> 
> So is there a way to drop the Timer for these IconItems by creating
> the needed buffers when the IconItem is ready? With Images this can be
> done with onStatusChanged: if (status==Image.Ready)

Could you post some code illustrating what you're trying to do? This makes it 
a bit easier to understand and more concrete to propose a solution. (Not that 
I know one, off-hand.)

Cheers,
-- 
sebas

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

[Differential] [Commented On] D2295: improve logging for kscreen

[davidedmundson (David Edmundson)]

davidedmundson added inline comments.

INLINE COMMENTS

> davidedmundson wrote in log.cpp:137
> It's one QLockFile line...

Edit:  Some googling suggests this is fine as-is.

O_APPEND writes are atomic on local filesystems, and will lock between updating 
the offset and the end of the write.

Providing Qt does everything as one write() which it probably will for lines 
less than ~512bytes or so.

REPOSITORY
  rLIBKSCREEN KScreen Library

BRANCH
  sebas/log

REVISION DETAIL
  https://phabricator.kde.org/D2295

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: sebas, #plasma, bshah
Cc: davidedmundson, bshah, plasma-devel, ali-mohamed, jensreuterberg, abetts, 
sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Is it possible to know when a PlasmaCore IconItem is ready?

[Michail Vourlakos]

Hello,

is it possible to know when a PlasmaCore IconItem in QML is ready?
I am trying to use the grabToImage for that element and the only way
to achieve this until now, is after Component.OnCompleted to use a
timer element.

I use a shadereffect to drop a shadow under various IconItems and
after that I animate them on hovering. By buffering them into Images
and animating these Images instead of the IconItems the interface
improves its respovinesss almost to double or even more.

So is there a way to drop the Timer for these IconItems by creating
the needed buffers when the IconItem is ready? With Images this can be
done with onStatusChanged: if (status==Image.Ready)

thanks  a lot,
Michail
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D2295: improve logging for kscreen

[davidedmundson (David Edmundson)]

davidedmundson added inline comments.

INLINE COMMENTS

> sebas wrote in log.cpp:46
> No threads in libkscreen. It'll probably blow up in many other cases already.

It doesn't matter if there are threads *in* kscreen.

The question is: Can a kscreen class be used *in* another thread by $app.

> sebas wrote in log.cpp:137
> It's actually complexity I want to avoid. If the logs are messed up, bad 
> luck, but introducing wait locks and the likes brings in so much complexity, 
> I think it's better to avoid here  until it becomes a problem.

It's one QLockFile line...

REPOSITORY
  rLIBKSCREEN KScreen Library

BRANCH
  sebas/log

REVISION DETAIL
  https://phabricator.kde.org/D2295

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: sebas, #plasma, bshah
Cc: davidedmundson, bshah, plasma-devel, ali-mohamed, jensreuterberg, abetts, 
sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D2295: improve logging for kscreen

[Sebastian Kügler]

sebas added inline comments.

INLINE COMMENTS

> bshah wrote in testlog.cpp:88
> nitpick - cAPs. ;-)

It's a test, this way it covers strange capitalization. :)

> davidedmundson wrote in log.cpp:46
> Question:
> What's the threading policy on libkscreen?
> 
> This isn't reentrant (which might be fine)

No threads in libkscreen. It'll probably blow up in many other cases already.

> davidedmundson wrote in log.cpp:71
> you probably want to manually force the logging category to enable itself if 
> this env var is set.
> 
> or get rid of this env var, and just check if the logging category is enabled.

Good point. I'll check if it's needed (I was kind of assuming that the policy 
checks are handled in the default handler, so we're not even bothered.)

> davidedmundson wrote in log.cpp:137
> You're going to need a file lock round this aren't you?
> The entire point is that two processes will be writing in here at the same 
> time.

It's actually complexity I want to avoid. If the logs are messed up, bad luck, 
but introducing wait locks and the likes brings in so much complexity, I think 
it's better to avoid here  until it becomes a problem.

REPOSITORY
  rLIBKSCREEN KScreen Library

BRANCH
  sebas/log

REVISION DETAIL
  https://phabricator.kde.org/D2295

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: sebas, #plasma, bshah
Cc: davidedmundson, bshah, plasma-devel, ali-mohamed, jensreuterberg, abetts, 
sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Changed Subscribers] D2295: improve logging for kscreen

[davidedmundson (David Edmundson)]

davidedmundson added inline comments.

INLINE COMMENTS

> log.cpp:30
> +Log* Log::sInstance = nullptr;
> +QtMessageHandler sDefaultMessageHandler = nullptr;
> +

why have it separate instead of a member of log?

> log.cpp:35
> +QByteArray localMsg = msg.toLocal8Bit();
> +if 
> (QString::fromLocal8Bit(context.category).startsWith(QStringLiteral("kscreen")))
>  {
> +Log::log(localMsg.constData(), context.category);

QLatin1String.

> log.cpp:46
> +
> +Log* Log::instance()
> +{

Question:
What's the threading policy on libkscreen?

This isn't reentrant (which might be fine)

> log.cpp:71
> +
> +if (qEnvironmentVariableIsSet(logging_env)) {
> +const QString logging_env_value = qgetenv(logging_env).constData();

you probably want to manually force the logging category to enable itself if 
this env var is set.

or get rid of this env var, and just check if the logging category is enabled.

> log.cpp:136
> +const QString timestamp = 
> QString::number(QDateTime::currentDateTime().toMSecsSinceEpoch());
> +QString logMessage = QString("\n%1 ; %2 ; %3 : %4").arg(timestamp, _cat, 
> instance()->context(), msg);
> +QFile file(instance()->logFile());

why call instance() from inside a member function?
it'll always return this.

> log.cpp:137
> +QString logMessage = QString("\n%1 ; %2 ; %3 : %4").arg(timestamp, _cat, 
> instance()->context(), msg);
> +QFile file(instance()->logFile());
> +if (!file.open(QIODevice::Append | QIODevice::Text)) {

You're going to need a file lock round this aren't you?
The entire point is that two processes will be writing in here at the same time.

REPOSITORY
  rLIBKSCREEN KScreen Library

BRANCH
  sebas/log

REVISION DETAIL
  https://phabricator.kde.org/D2295

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: sebas, #plasma, bshah
Cc: davidedmundson, bshah, plasma-devel, ali-mohamed, jensreuterberg, abetts, 
sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Accepted] D2294: categorized logging for kscreen kcm

[bshah (Bhushan Shah)]

bshah accepted this revision.
bshah added a reviewer: bshah.
bshah added a comment.
This revision is now accepted and ready to land.


  Apart from d_ed's comment looks good, perhaps you can change to ecm macro in 
different revision...

REPOSITORY
  rKSCREEN KScreen

BRANCH
  sebas/kcmcatlogging

REVISION DETAIL
  https://phabricator.kde.org/D2294

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: sebas, #plasma, bshah
Cc: bshah, davidedmundson, plasma-devel, ali-mohamed, jensreuterberg, abetts, 
sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Accepted] D2295: improve logging for kscreen

[bshah (Bhushan Shah)]

bshah accepted this revision.
bshah added a reviewer: bshah.
bshah added inline comments.
This revision is now accepted and ready to land.

INLINE COMMENTS

> testlog.cpp:88
> +qputenv(KSCREEN_LOGFILE, logfile);
> +qputenv(KSCREEN_LOGGING, QByteArray("faLSe"));
> +

nitpick - cAPs. ;-)

REPOSITORY
  rLIBKSCREEN KScreen Library

BRANCH
  sebas/log

REVISION DETAIL
  https://phabricator.kde.org/D2295

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: sebas, #plasma, bshah
Cc: bshah, plasma-devel, ali-mohamed, jensreuterberg, abetts, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D2219: Add option to enable volume feedback

[colomar (Thomas Pfeiffer)]

colomar added a comment.


  Is the feedback only played when there is no other source playing?
  If not, it should be done like that. If you already have something playing, 
it's just annoying to play an additional sound, and does not provide any 
additional info because you notice how loud whatever is playing plays.

REPOSITORY
  rPLASMAPA Plasma Audio Volume Applet

REVISION DETAIL
  https://phabricator.kde.org/D2219

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: drosca, #plasma, #plasma:_design
Cc: colomar, sebas, plasma-devel, ali-mohamed, jensreuterberg, abetts
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D2219: Add option to enable volume feedback

[Sebastian Kügler]

sebas added a comment.


  Can we expect canberra to be available everywhere PA is?
  
  It seems that it's just playing a short ticking sound, perhaps we can avoid 
the dependency easily?

REPOSITORY
  rPLASMAPA Plasma Audio Volume Applet

REVISION DETAIL
  https://phabricator.kde.org/D2219

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: drosca, #plasma, #plasma:_design
Cc: sebas, plasma-devel, jensreuterberg, abetts
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Changed Subscribers] D2296: RFC: "Add Widget" runner

[Sebastian Kügler]

sebas added inline comments.

INLINE COMMENTS

> addwidgetsrunner.cpp:126
> +
> +const QPoint cursorPos = QCursor::pos();
> +const QString script = scriptTemplate.arg(QString::number(cursorPos.x()),

Have you tested if this works on Wayland? (It probably won't, which means the 
widget ends up top-left (my guess).)

REPOSITORY
  rPLASMAWORKSPACE Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D2296

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: broulik, #plasma, #plasma:_design
Cc: sebas, mart, plasma-devel, jensreuterberg, abetts
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Jenkins-kde-ci: plasma-workspace master kf5-qt5 » Linux,gcc - Build # 285 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-workspace%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/285/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 28 Jul 2016 09:57:46 +
Build duration: 12 min

CHANGE SET
Revision 33ca1cae5d27d8e57f216c014ba62ae75e2831ad by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit runners/baloo/plasma-runner-baloosearch.desktop
  change: edit templates/ion-dataengine/src/ion-%{APPNAMELC}.desktop


JUNIT RESULTS

Name: (root) Failed: 2 test(s), Passed: 7 test(s), Skipped: 0 test(s), Total: 9 
test(s)Failed: TestSuite.screenpooltestFailed: TestSuite.testdesktop

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 9/9 (100%)FILES 47/63 (75%)CLASSES 47/63 (75%)LINE 1794/5112 
(35%)CONDITIONAL 1319/5340 (25%)

By packages
  
drkonqi.parser
FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 303/423 (72%)CONDITIONAL 
478/616 (78%)
drkonqi.tests.backtraceparsertest
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 74/74 (100%)CONDITIONAL 
33/50 (66%)
klipper
FILES 12/13 (92%)CLASSES 12/13 (92%)LINE 256/384 
(67%)CONDITIONAL 109/210 (52%)
klipper.autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 630/693 (91%)CONDITIONAL 
377/820 (46%)
libtaskmanager
FILES 5/16 (31%)CLASSES 5/16 (31%)LINE 139/3071 (5%)CONDITIONAL 
88/3209 (3%)
libtaskmanager.autotests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 150/150 
(100%)CONDITIONAL 85/170 (50%)
runners.bookmarks
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 89/159 (56%)CONDITIONAL 
34/96 (35%)
runners.bookmarks.browsers
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 88/93 (95%)CONDITIONAL 
84/107 (79%)
runners.bookmarks.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 65/65 (100%)CONDITIONAL 
31/62 (50%)___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Updated] D2298: allow for lnf packages to override templates

[mart (Marco Martin)]

mart added reviewers: ivan, garg.

REPOSITORY
  rPLASMAWORKSPACE Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D2298

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: mart, #plasma, ivan, garg
Cc: plasma-devel, jensreuterberg, abetts, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D2294: categorized logging for kscreen kcm

[Sebastian Kügler]

sebas added inline comments.

INLINE COMMENTS

> davidedmundson wrote in debug.h:25
> There's a CMake macro for all this file.

That's how it's done for the other components in this repo as well, so I went 
for that same solution here as well.

REPOSITORY
  rKSCREEN KScreen

REVISION DETAIL
  https://phabricator.kde.org/D2294

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: sebas, #plasma
Cc: davidedmundson, plasma-devel, jensreuterberg, abetts, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Changed Subscribers] D2294: categorized logging for kscreen kcm

[davidedmundson (David Edmundson)]

davidedmundson added inline comments.

INLINE COMMENTS

> debug.h:25
> +
> +Q_DECLARE_LOGGING_CATEGORY(KSCREEN_KCM)
> +

There's a CMake macro for all this file.

REPOSITORY
  rKSCREEN KScreen

REVISION DETAIL
  https://phabricator.kde.org/D2294

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: sebas, #plasma
Cc: davidedmundson, plasma-devel, jensreuterberg, abetts, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: multiscreen logging

[Sebastian Kügler]

On donderdag 28 juli 2016 01:18:00 CEST David Kahles wrote:
> I think the problem with this approach is, that most (or even all?) of
> these processes aren't units but simple processes.
> A better approach using the power of journald would be something like:
> 
> journalctl -b --user _COMM=plasmashell + _COMM=kded5 QT_CATEGORY=kscreen + 
>   _COMM=systemsettings5 + _COMM=kscreen_backend

I may add that this makes it a lot more complex for the user than just sending 
me a single, combined log file.

Also, what about users without journalctl?
-- 
sebas

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

Re: multiscreen logging

[Sebastian Kügler]

On woensdag 27 juli 2016 13:45:14 CEST Martin Klapetek wrote:
> On Wed, Jul 27, 2016 at 7:35 AM, Sebastian Kügler  wrote:
> 
> On dinsdag 26 juli 2016 19:44:11 CEST Martin Klapetek wrote:
> > On Tue, Jul 26, 2016 at 8:03 AM, Sebastian Kügler  wrote:
> > 
> > What do you think? If you like the idea, I'll polish up my branch and will
> > post it for review, so we can discuss the actual implementation.
> > 
> > I think a possible better way could be to log each component into each own
> > file (in the same dir) with timestamps and function stamps and process
> > stamps and everything and then merge those files using some automation and
> > sort by timestamp. Unless Qt on Linux actually handles concurrent write
> > access just fine and in the correct order (I know it didn't on Windows
> > last
> > time I looked).
> 
> Potentially, yes. Is it a problem? No.
> 
> The log file isn't critical, and *usually* components are able to write in
> order (appending to a file doesn't take long). If the log ends up being
> slightly corrupted, that's bad luck. Instead of implementing complex merging
> tools
> 
> for i in "file1" "file2" "file3"; do cat $i >> output.file; done; cat
> output.file | sort > final.log
> 
> ...not that complex :) Just the sort needs proper params depending on the
> timestamp. 

But that means that tail -f of the combined log becomes more complex.

> or file-locking mechanism, having just these processes write to the same
> file and cross fingers works well enough. It's a debugging tool, file
> integrity is just not that important.
> 
> Dunno, doesn't seem all that useful to have a debugging tool that may
> or may not work, especially if it is ever going to be used by users to post
> in bugreports. What use would be corrupted logs to us? Might as well do
> it properly, especially when the added complexity can be just oneliner
> bash script.

It does work, but it may have a corrupted line or two in the file once in a 
while, which is really no big deal -- not big enough to warrant more complex 
mechanisms. It really is a minor problem, that I haven't even seen yet.
-- 
sebas

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

Re: Plasma 5.8 and openSUSE 42.2

[Jonathan Riddell]

On Tue, Jul 26, 2016 at 03:56:21PM +0200, Antonio Larrosa wrote:
> This mean bringing forward some kde release dates and postponing some
> opensuse pre-releases to make everything fit tightly.
> 
> 2016-09-01: openSUSE 42.2 Beta 1 (this would include the last Plasma
> release available at that time, 5.7.4 or 5.7.5)
> 2016-09-08: Plasma 5.8 Repo Freeze (last day of Akademy, maybe that
> could be moved to freeze the repo just before QtCon?)
> 2016-09-15: Plasma 5.7.95 LTS (aka 5.8.0 Beta)

So Repo freeze a week earlier (during Akademy) then beta and
everything else following two weeks earlier.

> So, my question is, would you agree with that? Anybody sees any problem
> if both projects agree to those changes to their respective schedules?

It takes us back to a 3 month release scheule rather than 3.5 months
which feels a bit too short for some people.  I don't know if people
were expecting to use that extra time for features or not.

There's also the issue that if we move for one distro we'll end up
with accusations of favouratism and requests for moving for other
distros.  But then maybe we do like openSUSE :)

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

Re: Selecting a Plasma logo

[Olivier Churlaud]

Ivan a écrit :

The one that stands out for me is one of the Kver's mesh-ups. The one
with a part of the current plasma logo '>' inside two pieces of a
gear.

The reason I find that one interesting is that we could use a part of
it for the launcher icon if we wanted - just the '>'.

We could include the gear part, or two. It is open to modification.
The first thing that came to me was that we could easily make t-shirts
for a conference where the 'bumps' on the top gear would be
recognizable buildings of the city we are in.

I like the idea!

I really think the 4th of Ken look like a IM logo. It's the very first 
thing I think about when I see it.


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

Plasma 5.8 and openSUSE 42.2

[Antonio Larrosa]

Hello,

As you know, a few weeks ago openSUSE kde packagers were delighted to
know that Plasma 5.8 would be a LTS release. Let me begin by saying
that's really important for us that Plasma has a LTS release (and I
don't know if I'm saying that with my KDE hat or my SUSE hat, since I
think it benefits both projects), so in any case, thanks a lot for that
decision.

As you probably know, openSUSE has two distributions, openSUSE
Tumbleweed which is a rolling release distribution and openSUSE Leap, a
stable distribution based on the SUSE Linux Enterprise codebase, which
mostly gets bugfix updates and not major version changes (it could get
them, but we really try to discourage that whenever possible). With that
in mind, you can guess that it would benefit both KDE and openSUSE if we
included Plasma 5.8 in the next openSUSE Leap release, Leap 42.2 .

The problem comes when one looks at the schedules for Plasma and
openSUSE Leap releases:

https://community.kde.org/Schedules/Plasma_5
https://en.opensuse.org/openSUSE:Roadmap

The main part of the current schedules is:

2016-08-25: openSUSE 42.2 Beta 1
2016-09-15: KDE 5.8 Repo Freeze
2016-09-21: openSUSE 42.2 Beta 2 - Package freeze
2016-09-29: KDE 5.7.95 LTS (5.8.0 Beta)
2016-10-06: openSUSE 42.2 RC1
2016-10-13: KDE 5.8.0 LTS Release
2016-10-18: openSUSE 42.2 RC2
first week of November 2016: openSUSE 42.2 Release

As you see, there's quite bad timing in there.
I've talked with Martin and Sebas as well as with Ludwig Nussel
(openSUSE's release manager) separately trying to move both schedules
around in a way that could make it possible to get 5.8.0 in openSUSE 42.2.

I have a proposal that I think (and hope) that will satisfy everyone so
I think it's time to move this forward to all involved parties. In that
sense, I wrote a very similar mail to the openSUSE kde packagers and
will send it at the same time than this one. I hope you like the
proposal and note that I've tried to keep in mind the needs of each
project (QtCon/Akademy dates and the desire to have a stable Plasma
release on one side, SUSECon/SLE12SP2/other dates and the desire to have
a stable openSUSE release on the other).

This mean bringing forward some kde release dates and postponing some
opensuse pre-releases to make everything fit tightly.

2016-09-01: openSUSE 42.2 Beta 1 (this would include the last Plasma
release available at that time, 5.7.4 or 5.7.5)
2016-09-08: Plasma 5.8 Repo Freeze (last day of Akademy, maybe that
could be moved to freeze the repo just before QtCon?)
2016-09-15: Plasma 5.7.95 LTS (aka 5.8.0 Beta)
2016-09-21: openSUSE 42.2 Beta 2 - Package freeze (with 5.7.95)
2016-09-29: Plasma 5.8.0 LTS Release
2016-10-06: openSUSE 42.2 RC1 (with Plasma 5.8.0)
2016-10-11: Plasma 5.8.1 LTS
2016-10-18: openSUSE 42.2 RC2 (most probably including Plasma 5.8.1 if
bugs found and depending on the size of changes)
2016-10-18: Plasma 5.8.2 LTS
2016-11-01: Plasma 5.8.3 LTS
First week of November 2016: openSUSE 42.2 Release

This would mean that openSUSE 42.2 would be released including 5.8.1 .
Also, it might be possible to shift the Leap schedule a bit more if we
find grave bugs, so if that's the case, it could even include a newer
version.

This would mean too that if the repo freeze is done just after Akademy,
then you would have one week instead of two between the repo freeze and
the 5.7.95 release. If the repo freeze could be done before Akademy,
then you actually would have more time.

So, my question is, would you agree with that? Anybody sees any problem
if both projects agree to those changes to their respective schedules?

Please, keep in mind that both projects have needs and requirements, but
it would be great to find one solution that benefits both of us and for
that, both projects have to give in a little.

Thanks,

-- 
Antonio Larrosa
alarr...@suse.de
larr...@kde.org
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Javascript to change the default wallpaper in plasma

[Marco Martin]

On Mon, Jul 25, 2016 at 9:01 PM, Raphael Hertzog  wrote:
> d = desktops()
>
> for (i in d) {
> d[i].wallpaperPlugin = 'org.kde.image'
> d[i].currentConfigGroup = Array('Wallpaper', 'org.kde.image', 
> 'General')
> d[i].writeConfig('Image',
> 'file:///usr/share/images/desktop-base/desktop-background')
> d[i].writeConfig('FillMode', '2')  //enables croping
> }
>
> But it doesn't seem to work and I don't know why. It's possible that the 
> script
> is not executed at all...

the script is correct.
you have to make sure the file actually exists looks suspicious that
does't have an extension, for instance on the local installation here
i have
/opt/kde5qt5/share/wallpapers/ColorfulCups/contents/images/1920x1080.jpg

that means i do:
d[i].writeConfig("Image",
"file:///opt/kde5qt5/share/wallpapers/ColorfulCups/contents/images/1920x1080.jpg");

since it's a wallpaper in the plasma wallpaper format with a kpackage
layout and multiple resolutions, i can do as well:
d[i].writeConfig("Image", "ColorfulCups");

but d[i].writeConfig("Image",
"file:///opt/kde5qt5/share/wallpapers/ColorfulCups") wouldn't work
--
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Javascript to change the default wallpaper in plasma

[Bhushan Shah]

Hello Raphael

On Mon, Jul 25, 2016 at 09:01:25PM +0200, Raphael Hertzog wrote:
> Hello,
> 
> I'm a Debian developer trying to fix the plasma integration with default 
> artwork
> in Debian (https://bugs.debian.org/831730). I noticed recently that a plasma
> install did not have the expected wallpaper and thus that the existing
> integration no longer works. The current integration is a file
> /usr/share/kde4/apps/plasma-desktop/init/10-destop-base.js:
> http://sources.debian.net/src/desktop-base/8.0.2/kde-wallpaper/10-desktop-base.js/
> 
> I tried to look out for documentation but the only thing that I did
> find is this wiki page and it doesn't seem to be entirely up-to-date:
> https://userbase.kde.org/KDE_System_Administration/PlasmaDesktopScripting
> 

For Plasma 5, scripting have some bits changed, see following wiki

https://userbase.kde.org/KDE_System_Administration/PlasmaTwoDesktopScripting

> For instance, I was not able to run the interactive scripting dialog
> with "qdbus org.kde.plasma-desktop /MainApplication
> showInteractiveConsole" (it doesn't know about this DBus interface)
> so I could not get very far into debugging my issue.

With Plasma 5, you can start kwin console with following

qdbus org.kde.plasmashell /PlasmaShell 
org.kde.PlasmaShell.showInteractiveConsole

> 
> I tried to update the javascript code like this, based on my reading
> of ~/.config/plasma-org.kde.plasma.desktop-appletsrc after having changed
> the background:
> 
> d = desktops()
> 
> for (i in d) {
>   d[i].wallpaperPlugin = 'org.kde.image'
>   d[i].currentConfigGroup = Array('Wallpaper', 'org.kde.image', 'General')
>   d[i].writeConfig('Image',
>   'file:///usr/share/images/desktop-base/desktop-background')
>   d[i].writeConfig('FillMode', '2')  //enables croping
> }
> 
> But it doesn't seem to work and I don't know why. It's possible that the 
> script
> is not executed at all...
> 
> Do you know what has changed and what I should fix? Any help/pointer is 
> welcome.

I am not completely sure on how to adjust wallpaper, but others might
know.. Also I guess since your scripts are KDE4 based, they might not
work out-of-box with Plasma 5.

Thanks

-- 
Bhushan Shah

http://bhush9.github.io
IRC Nick : bshah on Freenode
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 128423: fix rename file (or folder) in folder plugin (and desktop in folder mode)

[Painless Roaster]

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


Ship it!




Ship It!

- Painless Roaster


On Čec. 13, 2016, 1:13 odp., Painless Roaster wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128423/
> ---
> 
> (Updated Čec. 13, 2016, 1:13 odp.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: https://bugs.kde.org/show_bug.cgi?id=361097
> 
> https://bugs.kde.org/show_bug.cgi?id=https://bugs.kde.org/show_bug.cgi?id=361097
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> fix rename file (or folder) in folder plugin (and desktop in folder mode)
>  - enable multiline edit
>  - fix size and position
>  - fix escape from edit if user pressed Esc
>  - fix suppress open file (or folder) if user clicked in editbox
>  - fix size and position in popup mode
> 
> 
> Diffs
> -
> 
>   containments/desktop/package/contents/ui/FolderView.qml ced3507 
> 
> Diff: https://git.reviewboard.kde.org/r/128423/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Painless Roaster
> 
>

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