date:20140728

On Mon, Jul 28, 2014 at 5:56 PM, Marco Martin  wrote:

> On Monday 28 July 2014, Marco Martin wrote:
> > On Monday 28 July 2014, Sebastian Kügler wrote:
> > > - Started mechanism to load stuff from Look and Feel packages
> > >
> > >   would like comment on https://git.reviewboard.kde.org/r/119451/
> >
> > Based on the discussion with David in the hangout, i would still do:
> > - the look and feel package provides qml files for some parts of the
> shell
> > - most theme elements (icons, plasma theme, widget style etc) are usually
> > provided only referred in a config file
> > - if a theme wants to phisically provide something, like a plasma theme,
> > icon theme etc, it can, bout would be task of the kcm to either copy or
> > make a link of say, the icon theme in the proper directory where an icon
> > theme would be expected.
> > - or in alternative, the theme could be specified in the config file as a
> > full path, so for icons if you are using the "foo" look and feel package,
> > you could have in kdeglobals
> >
> > [Icons]
> > Theme=~/.share/plasma/lookandfeel/foo/icons
>
> comments on that?
> furthermore, how would you prefer to use it?
> as a standalone library? static in plasma-workspace stuff? in
> libplasmaquick?
> other?
>
>
Maybe we should have a library for accessing look&feel packages? I don't
think it belongs to libplasma, since libplasma is about applets and
containments management. We could have a library within plasma-workspace
that does this? If we need to expose it further we could consider at some
point, but I don't think it will be needed.

About how to tell what icon theme the look&feel package suggests to use, I
think that rather than specifying a path, it should be specifying a unique
identifier so that we know how to get it.
Something like
Themes=default:/breeze
or
Themes=kns:/diamond
or
Themes=bodega:/awesomefuturisticrainbows
or
Themes=http://...

Does that make sense?
Aleix
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Minutes Monday Plasma Hangout

On Mon, Jul 28, 2014 at 9:36 PM, Marco Martin  wrote:

> On Monday 28 July 2014, Marco Martin wrote:
> > > [Icons]
> > > Theme=~/.share/plasma/lookandfeel/foo/icons
> >
> > comments on that?
> > furthermore, how would you prefer to use it?
> > as a standalone library? static in plasma-workspace stuff? in
> > libplasmaquick? other?
>
> next on that, the lookandfeel package should somehowinfluence
> khintsettings in
> the frameworkintegration framework (that of course couldn't depend from a
> package)
>
> khintsettings should do something along the lines:
> * with some heuristics access the lookandfeel package (it's only a folder
> after all, wouldn't be very difficult) and open a config file with default
> icons/widget style etc
> * read the default if available, fallback to an hardcoded internal one if
> fail
>
>
Agreed, also fonts could have a place there.

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

Re: Review Request 119524: Force OpenGLES if on Qt 5.4



> On July 28, 2014, 7:03 p.m., Mark Gaiser wrote:
> > If there is one hardware combination that works best on linux, it's OpenGL 
> > + Intel.
> > I find it hard to believe that GLES is better and in all cases. That must 
> > be a driver/mesa bug that should be investigated and fixed.
> > 
> > If this would've been a fix to workaround crappy AMD drivers, then this 
> > patch would be understandable. AMD is just slacking.
> > But switching to OpenGL ES on all platforms because intel supposedly 
> > performs better is a bit weird. Can't the plasma graphics stack (OpenGL or 
> > OpenGL ES) be chosen at runtime like it can with KWin? Perhaps you can even 
> > re-use KWin's GL setting in plasma?

Well, OpenGL ES is a subset of OpenGL, so less things will be available but I'd 
say it's better to use the small thing until we need the big one rather than 
the other way around. Especially if we want to think about devices, some day.


- Aleix


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


On July 28, 2014, 6:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119524/
> ---
> 
> (Updated July 28, 2014, 6:09 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> When trying to reduce memory usage in plasma shell, we realized that one of 
> the reasons we got such big memory footprint was actually the intel driver 
> (on intel systems, that is). After some investigation, David found out we 
> were going through some memory-consuming path [1]. A way to workaround it is 
> by using only OpenGLES. Everything still works here after this patch, so it 
> seems to be a good change to get in.
> 
> This change needs Qt 5.4, to get the new API that lets us enforce a 
> QSurfaceFormat, hence having it ifdef'd.
> I'm quite unaware of problems we might find. Knowing we probably want to work 
> in different embedded devices, suggests that OpenGLES on all platforms sounds 
> like a safe bet.
> 
> [1] http://comments.gmane.org/gmane.comp.video.mesa3d.devel/60848
> 
> 
> Diffs
> -
> 
>   shell/main.cpp e34578d 
> 
> Diff: https://git.reviewboard.kde.org/r/119524/diff/
> 
> 
> Testing
> ---
> 
> I'm using it now, without visible problems. Now we see no trace of i915 in 
> the massif reports.
> 
> 
> File Attachments
> 
> 
> before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/5a6beb4f-24c0-4cee-a7a2-038385e35119__plasma-massif-opengl.png
> after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/fc301ff5-cb1d-4654-a57f-82990220c8e3__plasma-massif-opengles.png
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Review Request 119524: Force OpenGLES if on Qt 5.4



> On July 28, 2014, 6:25 p.m., Eike Hein wrote:
> > Can you recompile plasma-desktop with OpenGL ES and test if the drag pixmap 
> > for Folder icons works?
> > 
> > I wrote the code in a way that ought to work on both desktop GL and ES, but 
> > it's worth testing.

I have it running with OpenGLES at the moment, it seems to work fine the Folder 
View. If there's anything specific you want me to try, don't hesitate to tell 
me (here or in IRC, etc.).


- Aleix


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


On July 28, 2014, 6:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119524/
> ---
> 
> (Updated July 28, 2014, 6:09 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> When trying to reduce memory usage in plasma shell, we realized that one of 
> the reasons we got such big memory footprint was actually the intel driver 
> (on intel systems, that is). After some investigation, David found out we 
> were going through some memory-consuming path [1]. A way to workaround it is 
> by using only OpenGLES. Everything still works here after this patch, so it 
> seems to be a good change to get in.
> 
> This change needs Qt 5.4, to get the new API that lets us enforce a 
> QSurfaceFormat, hence having it ifdef'd.
> I'm quite unaware of problems we might find. Knowing we probably want to work 
> in different embedded devices, suggests that OpenGLES on all platforms sounds 
> like a safe bet.
> 
> [1] http://comments.gmane.org/gmane.comp.video.mesa3d.devel/60848
> 
> 
> Diffs
> -
> 
>   shell/main.cpp e34578d 
> 
> Diff: https://git.reviewboard.kde.org/r/119524/diff/
> 
> 
> Testing
> ---
> 
> I'm using it now, without visible problems. Now we see no trace of i915 in 
> the massif reports.
> 
> 
> File Attachments
> 
> 
> before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/5a6beb4f-24c0-4cee-a7a2-038385e35119__plasma-massif-opengl.png
> after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/fc301ff5-cb1d-4654-a57f-82990220c8e3__plasma-massif-opengles.png
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: qml controls and documentation

On Mon, Jul 28, 2014 at 8:07 PM, Marco Martin  wrote:

> On Monday 28 July 2014, Aleix Pol wrote:
>
> > > does somebody knows if is possible with the markup used now for
> > > extracting documentation to still have comments to document all the
> > > properties, even those *not* defined in the qml file in question?
> >
> > It should probably look more or less like KPushButton [1], properly
> showing
> > inheritance. Anybody knows how this is implemented in doxygen?
> >
> > Aleix
> >
> > [1]
> >
> http://api.kde.org/4.12-api/kdelibs-apidocs/kdeui/html/classKPushButton.htm
> > l
>
> I think the support for Qml is way more basic.
> doxygen didn't use to support qml at all iirc the support was added by
> Aurelien some time ago, but doesn't do for sure the "x methods inherited
> from
> foo" part.
>
> but i wouldn't know how to make it go to fetch the documentation from the
> corresponfing qtcontrol.
>
>
Well, maybe it should stop being basic :D.
/me invokes an Aurélien.

Hey, do you know where can we find the code that generates the
documentation for QML modules? Do you know how hard would it be to
implement inheritance and inheritance graphs like in C++?

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

Re: Minutes Monday Plasma Hangout

On Monday 28 July 2014, Marco Martin wrote:
> > [Icons]
> > Theme=~/.share/plasma/lookandfeel/foo/icons
> 
> comments on that?
> furthermore, how would you prefer to use it?
> as a standalone library? static in plasma-workspace stuff? in
> libplasmaquick? other?

next on that, the lookandfeel package should somehowinfluence khintsettings in 
the frameworkintegration framework (that of course couldn't depend from a 
package)

khintsettings should do something along the lines:
* with some heuristics access the lookandfeel package (it's only a folder 
after all, wouldn't be very difficult) and open a config file with default 
icons/widget style etc
* read the default if available, fallback to an hardcoded internal one if fail


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

Re: Review Request 119523: port TextField to QtControls



> On July 28, 2014, 6:54 p.m., David Edmundson wrote:
> > src/declarativeimports/plasmacomponents/qml/TextField.qml, line 366
> > 
> >
> > This is going to overlap with the text I think.
> > It might be worth trying to upstream the concept of a clear button 
> > rather than working round it here. It'll be less work in the long term. 
> > 
> > I filed a bug report on this once, they're ok with the concept but want 
> > to make it so you can add any random button on the left/right, not just 
> > clear.
> 
> Marco Martin wrote:
> yes, it does overlap, i don't have much ways to avoid it.
> maybe worth it upstreaming yeah, I guess they would like something
> TextField {
>   property Item ActionButton
> }
> and actionButton would be a whatever item that gets anchored on the right 
> area, or  would that be restricted to a button? (so just being able to set 
> text, tooltip and a signal handler?)

EDIT: I didn't file a bug, Martin G did. I get the two of us confused sometimes.
https://bugreports.qt-project.org/browse/QTBUG-37373


- David


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


On July 28, 2014, 6:10 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119523/
> ---
> 
> (Updated July 28, 2014, 6:10 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> this ports TextField to Qt Controls.
> 
> Not sure if is really meargeable tough, because the old one used to export 
> several properties and functions more, but they are not possible anymore, 
> because in order for them to work is needed the access to the internal 
> TextInput, and we don't have that, so some api should have to be dropped, 
> breaking the compatibility promise.
> (another option would be to still use an own implementation, but use a 
> compatible style anyways)
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qml/TextField.qml 5bc6b58 
>   src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml 
> PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/119523/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 119523: port TextField to QtControls



> On July 28, 2014, 7:09 p.m., Kai Uwe Broulik wrote:
> > src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml, line 
> > 52
> > 
> >
> > Can't you account for the clear button width here?

probably


> On July 28, 2014, 7:09 p.m., Kai Uwe Broulik wrote:
> > src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml, line 
> > 49
> > 
> >
> > Why no binding?

I can't access the framesvg from the level of the root.
could probably use a Binding {} tough


- Marco


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


On July 28, 2014, 6:10 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119523/
> ---
> 
> (Updated July 28, 2014, 6:10 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> this ports TextField to Qt Controls.
> 
> Not sure if is really meargeable tough, because the old one used to export 
> several properties and functions more, but they are not possible anymore, 
> because in order for them to work is needed the access to the internal 
> TextInput, and we don't have that, so some api should have to be dropped, 
> breaking the compatibility promise.
> (another option would be to still use an own implementation, but use a 
> compatible style anyways)
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qml/TextField.qml 5bc6b58 
>   src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml 
> PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/119523/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 119523: port TextField to QtControls

2014-07-28 Thread Kai Uwe Broulik


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



src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml


Why no binding?



src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml


Can't you account for the clear button width here?


- Kai Uwe Broulik


On Juli 28, 2014, 6:10 nachm., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119523/
> ---
> 
> (Updated Juli 28, 2014, 6:10 nachm.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> this ports TextField to Qt Controls.
> 
> Not sure if is really meargeable tough, because the old one used to export 
> several properties and functions more, but they are not possible anymore, 
> because in order for them to work is needed the access to the internal 
> TextInput, and we don't have that, so some api should have to be dropped, 
> breaking the compatibility promise.
> (another option would be to still use an own implementation, but use a 
> compatible style anyways)
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qml/TextField.qml 5bc6b58 
>   src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml 
> PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/119523/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 119524: Force OpenGLES if on Qt 5.4

2014-07-28 Thread Mark Gaiser


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


If there is one hardware combination that works best on linux, it's OpenGL + 
Intel.
I find it hard to believe that GLES is better and in all cases. That must be a 
driver/mesa bug that should be investigated and fixed.

If this would've been a fix to workaround crappy AMD drivers, then this patch 
would be understandable. AMD is just slacking.
But switching to OpenGL ES on all platforms because intel supposedly performs 
better is a bit weird. Can't the plasma graphics stack (OpenGL or OpenGL ES) be 
chosen at runtime like it can with KWin? Perhaps you can even re-use KWin's GL 
setting in plasma?

- Mark Gaiser


On jul 28, 2014, 6:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119524/
> ---
> 
> (Updated jul 28, 2014, 6:09 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> When trying to reduce memory usage in plasma shell, we realized that one of 
> the reasons we got such big memory footprint was actually the intel driver 
> (on intel systems, that is). After some investigation, David found out we 
> were going through some memory-consuming path [1]. A way to workaround it is 
> by using only OpenGLES. Everything still works here after this patch, so it 
> seems to be a good change to get in.
> 
> This change needs Qt 5.4, to get the new API that lets us enforce a 
> QSurfaceFormat, hence having it ifdef'd.
> I'm quite unaware of problems we might find. Knowing we probably want to work 
> in different embedded devices, suggests that OpenGLES on all platforms sounds 
> like a safe bet.
> 
> [1] http://comments.gmane.org/gmane.comp.video.mesa3d.devel/60848
> 
> 
> Diffs
> -
> 
>   shell/main.cpp e34578d 
> 
> Diff: https://git.reviewboard.kde.org/r/119524/diff/
> 
> 
> Testing
> ---
> 
> I'm using it now, without visible problems. Now we see no trace of i915 in 
> the massif reports.
> 
> 
> File Attachments
> 
> 
> before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/5a6beb4f-24c0-4cee-a7a2-038385e35119__plasma-massif-opengl.png
> after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/fc301ff5-cb1d-4654-a57f-82990220c8e3__plasma-massif-opengles.png
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Review Request 119523: port TextField to QtControls



On July 28, 2014, 6:54 p.m., Marco Martin wrote:
> > Which methods do we need the inner control for? I saw positionAtPos and 
> > positionToRectangle, any others?
> 
> Marco Martin wrote:
> those two and passwordCharacter

and missing properties are:

passwordCharacter
errorHighlight


- David


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


On July 28, 2014, 6:10 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119523/
> ---
> 
> (Updated July 28, 2014, 6:10 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> this ports TextField to Qt Controls.
> 
> Not sure if is really meargeable tough, because the old one used to export 
> several properties and functions more, but they are not possible anymore, 
> because in order for them to work is needed the access to the internal 
> TextInput, and we don't have that, so some api should have to be dropped, 
> breaking the compatibility promise.
> (another option would be to still use an own implementation, but use a 
> compatible style anyways)
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qml/TextField.qml 5bc6b58 
>   src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml 
> PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/119523/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 119523: port TextField to QtControls



> On July 28, 2014, 6:54 p.m., David Edmundson wrote:
> > src/declarativeimports/plasmacomponents/qml/TextField.qml, line 366
> > 
> >
> > This is going to overlap with the text I think.
> > It might be worth trying to upstream the concept of a clear button 
> > rather than working round it here. It'll be less work in the long term. 
> > 
> > I filed a bug report on this once, they're ok with the concept but want 
> > to make it so you can add any random button on the left/right, not just 
> > clear.

yes, it does overlap, i don't have much ways to avoid it.
maybe worth it upstreaming yeah, I guess they would like something
TextField {
  property Item ActionButton
}
and actionButton would be a whatever item that gets anchored on the right area, 
or  would that be restricted to a button? (so just being able to set text, 
tooltip and a signal handler?)


On July 28, 2014, 6:54 p.m., Marco Martin wrote:
> > Which methods do we need the inner control for? I saw positionAtPos and 
> > positionToRectangle, any others?

those two and passwordCharacter


- Marco


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


On July 28, 2014, 6:10 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119523/
> ---
> 
> (Updated July 28, 2014, 6:10 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> this ports TextField to Qt Controls.
> 
> Not sure if is really meargeable tough, because the old one used to export 
> several properties and functions more, but they are not possible anymore, 
> because in order for them to work is needed the access to the internal 
> TextInput, and we don't have that, so some api should have to be dropped, 
> breaking the compatibility promise.
> (another option would be to still use an own implementation, but use a 
> compatible style anyways)
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qml/TextField.qml 5bc6b58 
>   src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml 
> PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/119523/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 119523: port TextField to QtControls


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


Even if we fix the methods it's too close to 5.1 to merge right now. Definitely 
wait till after that so we have some time to find problems.


src/declarativeimports/plasmacomponents/qml/TextField.qml


This is going to overlap with the text I think.
It might be worth trying to upstream the concept of a clear button rather 
than working round it here. It'll be less work in the long term. 

I filed a bug report on this once, they're ok with the concept but want to 
make it so you can add any random button on the left/right, not just clear.



src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml


RAndon capitals


Which methods do we need the inner control for? I saw positionAtPos and 
positionToRectangle, any others?

- David Edmundson


On July 28, 2014, 6:10 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119523/
> ---
> 
> (Updated July 28, 2014, 6:10 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> this ports TextField to Qt Controls.
> 
> Not sure if is really meargeable tough, because the old one used to export 
> several properties and functions more, but they are not possible anymore, 
> because in order for them to work is needed the access to the internal 
> TextInput, and we don't have that, so some api should have to be dropped, 
> breaking the compatibility promise.
> (another option would be to still use an own implementation, but use a 
> compatible style anyways)
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qml/TextField.qml 5bc6b58 
>   src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml 
> PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/119523/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 119524: Force OpenGLES if on Qt 5.4

2014-07-28 Thread Eike Hein


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


Can you recompile plasma-desktop with OpenGL ES and test if the drag pixmap for 
Folder icons works?

I wrote the code in a way that ought to work on both desktop GL and ES, but 
it's worth testing.

- Eike Hein


On July 28, 2014, 6:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119524/
> ---
> 
> (Updated July 28, 2014, 6:09 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> When trying to reduce memory usage in plasma shell, we realized that one of 
> the reasons we got such big memory footprint was actually the intel driver 
> (on intel systems, that is). After some investigation, David found out we 
> were going through some memory-consuming path [1]. A way to workaround it is 
> by using only OpenGLES. Everything still works here after this patch, so it 
> seems to be a good change to get in.
> 
> This change needs Qt 5.4, to get the new API that lets us enforce a 
> QSurfaceFormat, hence having it ifdef'd.
> I'm quite unaware of problems we might find. Knowing we probably want to work 
> in different embedded devices, suggests that OpenGLES on all platforms sounds 
> like a safe bet.
> 
> [1] http://comments.gmane.org/gmane.comp.video.mesa3d.devel/60848
> 
> 
> Diffs
> -
> 
>   shell/main.cpp e34578d 
> 
> Diff: https://git.reviewboard.kde.org/r/119524/diff/
> 
> 
> Testing
> ---
> 
> I'm using it now, without visible problems. Now we see no trace of i915 in 
> the massif reports.
> 
> 
> File Attachments
> 
> 
> before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/5a6beb4f-24c0-4cee-a7a2-038385e35119__plasma-massif-opengl.png
> after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/fc301ff5-cb1d-4654-a57f-82990220c8e3__plasma-massif-opengles.png
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Review Request 119524: Force OpenGLES if on Qt 5.4


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


I still don't have 5.4 to test for now..
but, are you sure this works on the other drivers? such changes should get a 
test also at least on
nvidia
catalyst
radeonhd (or whatever they're called nowdays)

- Marco Martin


On July 28, 2014, 6:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119524/
> ---
> 
> (Updated July 28, 2014, 6:09 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> When trying to reduce memory usage in plasma shell, we realized that one of 
> the reasons we got such big memory footprint was actually the intel driver 
> (on intel systems, that is). After some investigation, David found out we 
> were going through some memory-consuming path [1]. A way to workaround it is 
> by using only OpenGLES. Everything still works here after this patch, so it 
> seems to be a good change to get in.
> 
> This change needs Qt 5.4, to get the new API that lets us enforce a 
> QSurfaceFormat, hence having it ifdef'd.
> I'm quite unaware of problems we might find. Knowing we probably want to work 
> in different embedded devices, suggests that OpenGLES on all platforms sounds 
> like a safe bet.
> 
> [1] http://comments.gmane.org/gmane.comp.video.mesa3d.devel/60848
> 
> 
> Diffs
> -
> 
>   shell/main.cpp e34578d 
> 
> Diff: https://git.reviewboard.kde.org/r/119524/diff/
> 
> 
> Testing
> ---
> 
> I'm using it now, without visible problems. Now we see no trace of i915 in 
> the massif reports.
> 
> 
> File Attachments
> 
> 
> before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/5a6beb4f-24c0-4cee-a7a2-038385e35119__plasma-massif-opengl.png
> after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/fc301ff5-cb1d-4654-a57f-82990220c8e3__plasma-massif-opengles.png
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Review Request 119523: port TextField to QtControls


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

Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

this ports TextField to Qt Controls.

Not sure if is really meargeable tough, because the old one used to export 
several properties and functions more, but they are not possible anymore, 
because in order for them to work is needed the access to the internal 
TextInput, and we don't have that, so some api should have to be dropped, 
breaking the compatibility promise.
(another option would be to still use an own implementation, but use a 
compatible style anyways)


Diffs
-

  src/declarativeimports/plasmacomponents/qml/TextField.qml 5bc6b58 
  src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml 
PRE-CREATION 

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


Testing
---


Thanks,

Marco Martin

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

Review Request 119524: Force OpenGLES if on Qt 5.4

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

Review request for Plasma.

Repository: plasma-workspace

Description
---

When trying to reduce memory usage in plasma shell, we realized that one of the
reasons we got such big memory footprint was actually the intel driver (on
intel systems, that is). After some investigation, David found out we were
going through some memory-consuming path [1]. A way to workaround it is by
using only OpenGLES. Everything still works here after this patch, so it seems
to be a good change to get in.

This change needs Qt 5.4, to get the new API that lets us enforce a
QSurfaceFormat, hence having it ifdef'd.
I'm quite unaware of problems we might find. Knowing we probably want to work
in different embedded devices, suggests that OpenGLES on all platforms sounds
like a safe bet.

[1] http://comments.gmane.org/gmane.comp.video.mesa3d.devel/60848

Diffs
-

shell/main.cpp e34578d

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

Testing
---

I'm using it now, without visible problems. Now we see no trace of i915 in the
massif reports.

File Attachments

before

https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/5a6beb4f-24c0-4cee-a7a2-038385e35119__plasma-massif-opengl.png
after

https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/fc301ff5-cb1d-4654-a57f-82990220c8e3__plasma-massif-opengles.png

Thanks,

Aleix Pol Gonzalez

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

Re: qml controls and documentation

On Monday 28 July 2014, Aleix Pol wrote:

> > does somebody knows if is possible with the markup used now for
> > extracting documentation to still have comments to document all the
> > properties, even those *not* defined in the qml file in question?
> 
> It should probably look more or less like KPushButton [1], properly showing
> inheritance. Anybody knows how this is implemented in doxygen?
> 
> Aleix
> 
> [1]
> http://api.kde.org/4.12-api/kdelibs-apidocs/kdeui/html/classKPushButton.htm
> l

I think the support for Qml is way more basic.
doxygen didn't use to support qml at all iirc the support was added by 
Aurelien some time ago, but doesn't do for sure the "x methods inherited from 
foo" part.

but i wouldn't know how to make it go to fetch the documentation from the 
corresponfing qtcontrol.

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

Re: Review Request 119515: Support per-activity favourites


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

(Updated July 28, 2014, 5:50 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma, Eike Hein, Marco Martin, and Sebastian Kügler.


Repository: plasma-desktop


Description
---

This patch adds the support to have favourites linked to activities.

It uses org.kde.activities.ResourceModel to show favorites.

It supports:
 - adding a favourite to all activities (the previous behaviour)
 - adding a favourite to the current activity
 - moving a favourite between 'all activities' and 'current activity' modes (it 
does not affect non-current activities)
 - drag-and-drop reordering of items (like the previous one)
 - sorting A-Z, Z-A (like the previous one)
 - transitions previously defined favourites to the new system*

Context menu item captions could maybe use some improvement.

Screenshot available at: 
http://ivan.fomentgroup.org/blog/2014/07/27/per-activity-favourites-in-kickoff/#/comments

* this can also be used for defining the default favourites in a global 
kickoffrc file - instead of them being hard-coded like they currently are.


Diffs
-

  applets/kickoff/CMakeLists.txt 28e7029 
  applets/kickoff/core/favoritesmodel.h 27a0626 
  applets/kickoff/core/favoritesmodel.cpp f05588b 
  applets/kickoff/core/kickoffplugin.cpp f549981 
  applets/kickoff/core/krunnermodel.h 3916829 
  applets/kickoff/core/krunnermodel.cpp db2adab 
  applets/kickoff/package/contents/ui/ContextMenu.qml 6a67874 
  applets/kickoff/package/contents/ui/FavoritesView.qml 6c2d5d4 
  applets/kickoff/package/contents/ui/FullRepresentation.qml 6291b7c 

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


Testing
---

Yes


Thanks,

Ivan Čukić

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

Re: Review Request 119522: readlink fails whens the folder does not exist.

2014-07-28 Thread Rohan Garg



> On July 28, 2014, 11:14 p.m., Aleix Pol Gonzalez wrote:
> > So does it still work if it's a link, after this patch?

Yep, works when my ~/.config is a symlink.


- Rohan


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


On July 28, 2014, 10:47 p.m., Rohan Garg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119522/
> ---
> 
> (Updated July 28, 2014, 10:47 p.m.)
> 
> 
> Review request for Plasma and Àlex Fiestas.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/f01badb5aa3f76b27955f4fee2cb7281dd490353
>  introduced a regression in startkde whereby if ~/.config does not exist 
> readlink will not output the right path.
> 
> This leads to startkde trying to write to /startupconfigkeys or /kdeglobals 
> which obviously won't work.
> 
> Since the original commit mentions that relative paths weren't working, I've 
> taken a alternative approach of using ${HOME} instead.
> 
> 
> Diffs
> -
> 
>   startkde/startkde.cmake 281bd43 
> 
> Diff: https://git.reviewboard.kde.org/r/119522/diff/
> 
> 
> Testing
> ---
> 
> Kubuntu Plasma 5 ISO's did not have the right cursor theme before this patch, 
> after editing startkde by hand, the right files were being correctly written, 
> and the cursor theme worked as expected.
> 
> 
> Thanks,
> 
> Rohan Garg
> 
>

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

Re: Review Request 119465: Have separate texture hashes for each window


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

(Updated July 28, 2014, 5:48 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Repository: plasma-framework


Description
---

Apparently in nvidia we get corruptions when a texture created for a window is 
used in another one.
With this patch we tell the texture has changed when we move it from a window 
to another, so it's re-created and we keep textures for all windows separately. 
This way we ensure they don't mix.


Diffs
-

  src/declarativeimports/core/framesvgitem.h 0b39c70 
  src/declarativeimports/core/framesvgitem.cpp ebac29f 

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


Testing
---

Still works here, I hope Marco can confirm it fixes the problem.


Thanks,

Aleix Pol Gonzalez

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

Re: Review Request 119515: Support per-activity favourites



> On July 28, 2014, 5:31 p.m., Thomas Braxton wrote:
> > applets/kickoff/package/contents/ui/ContextMenu.qml, line 62
> > 
> >
> > addToGlobalFavorites sounds better

Agreed.


- Ivan


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


On July 28, 2014, 11:49 a.m., Ivan Čukić wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119515/
> ---
> 
> (Updated July 28, 2014, 11:49 a.m.)
> 
> 
> Review request for Plasma, Eike Hein, Marco Martin, and Sebastian Kügler.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This patch adds the support to have favourites linked to activities.
> 
> It uses org.kde.activities.ResourceModel to show favorites.
> 
> It supports:
>  - adding a favourite to all activities (the previous behaviour)
>  - adding a favourite to the current activity
>  - moving a favourite between 'all activities' and 'current activity' modes 
> (it does not affect non-current activities)
>  - drag-and-drop reordering of items (like the previous one)
>  - sorting A-Z, Z-A (like the previous one)
>  - transitions previously defined favourites to the new system*
> 
> Context menu item captions could maybe use some improvement.
> 
> Screenshot available at: 
> http://ivan.fomentgroup.org/blog/2014/07/27/per-activity-favourites-in-kickoff/#/comments
> 
> * this can also be used for defining the default favourites in a global 
> kickoffrc file - instead of them being hard-coded like they currently are.
> 
> 
> Diffs
> -
> 
>   applets/kickoff/CMakeLists.txt 28e7029 
>   applets/kickoff/core/favoritesmodel.h 27a0626 
>   applets/kickoff/core/favoritesmodel.cpp f05588b 
>   applets/kickoff/core/kickoffplugin.cpp f549981 
>   applets/kickoff/core/krunnermodel.h 3916829 
>   applets/kickoff/core/krunnermodel.cpp db2adab 
>   applets/kickoff/package/contents/ui/ContextMenu.qml 6a67874 
>   applets/kickoff/package/contents/ui/FavoritesView.qml 6c2d5d4 
>   applets/kickoff/package/contents/ui/FullRepresentation.qml 6291b7c 
> 
> Diff: https://git.reviewboard.kde.org/r/119515/diff/
> 
> 
> Testing
> ---
> 
> Yes
> 
> 
> Thanks,
> 
> Ivan Čukić
> 
>

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

Re: Review Request 119522: readlink fails whens the folder does not exist.


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


So does it still work if it's a link, after this patch?

- Aleix Pol Gonzalez


On July 28, 2014, 5:17 p.m., Rohan Garg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119522/
> ---
> 
> (Updated July 28, 2014, 5:17 p.m.)
> 
> 
> Review request for Plasma and Àlex Fiestas.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/f01badb5aa3f76b27955f4fee2cb7281dd490353
>  introduced a regression in startkde whereby if ~/.config does not exist 
> readlink will not output the right path.
> 
> This leads to startkde trying to write to /startupconfigkeys or /kdeglobals 
> which obviously won't work.
> 
> Since the original commit mentions that relative paths weren't working, I've 
> taken a alternative approach of using ${HOME} instead.
> 
> 
> Diffs
> -
> 
>   startkde/startkde.cmake 281bd43 
> 
> Diff: https://git.reviewboard.kde.org/r/119522/diff/
> 
> 
> Testing
> ---
> 
> Kubuntu Plasma 5 ISO's did not have the right cursor theme before this patch, 
> after editing startkde by hand, the right files were being correctly written, 
> and the cursor theme worked as expected.
> 
> 
> Thanks,
> 
> Rohan Garg
> 
>

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

Re: Review Request 119515: Support per-activity favourites

2014-07-28 Thread Thomas Braxton


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



applets/kickoff/package/contents/ui/ContextMenu.qml


addToGlobalFavorites sounds better



applets/kickoff/package/contents/ui/ContextMenu.qml


same here
addToActivityFavorites


- Thomas Braxton


On July 28, 2014, 11:49 a.m., Ivan Čukić wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119515/
> ---
> 
> (Updated July 28, 2014, 11:49 a.m.)
> 
> 
> Review request for Plasma, Eike Hein, Marco Martin, and Sebastian Kügler.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This patch adds the support to have favourites linked to activities.
> 
> It uses org.kde.activities.ResourceModel to show favorites.
> 
> It supports:
>  - adding a favourite to all activities (the previous behaviour)
>  - adding a favourite to the current activity
>  - moving a favourite between 'all activities' and 'current activity' modes 
> (it does not affect non-current activities)
>  - drag-and-drop reordering of items (like the previous one)
>  - sorting A-Z, Z-A (like the previous one)
>  - transitions previously defined favourites to the new system*
> 
> Context menu item captions could maybe use some improvement.
> 
> Screenshot available at: 
> http://ivan.fomentgroup.org/blog/2014/07/27/per-activity-favourites-in-kickoff/#/comments
> 
> * this can also be used for defining the default favourites in a global 
> kickoffrc file - instead of them being hard-coded like they currently are.
> 
> 
> Diffs
> -
> 
>   applets/kickoff/CMakeLists.txt 28e7029 
>   applets/kickoff/core/favoritesmodel.h 27a0626 
>   applets/kickoff/core/favoritesmodel.cpp f05588b 
>   applets/kickoff/core/kickoffplugin.cpp f549981 
>   applets/kickoff/core/krunnermodel.h 3916829 
>   applets/kickoff/core/krunnermodel.cpp db2adab 
>   applets/kickoff/package/contents/ui/ContextMenu.qml 6a67874 
>   applets/kickoff/package/contents/ui/FavoritesView.qml 6c2d5d4 
>   applets/kickoff/package/contents/ui/FullRepresentation.qml 6291b7c 
> 
> Diff: https://git.reviewboard.kde.org/r/119515/diff/
> 
> 
> Testing
> ---
> 
> Yes
> 
> 
> Thanks,
> 
> Ivan Čukić
> 
>

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

Re: Review Request 119515: Support per-activity favourites


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

Ship it!


for kickoff, for what i'm concerned is good to go

- Marco Martin


On July 28, 2014, 11:49 a.m., Ivan Čukić wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119515/
> ---
> 
> (Updated July 28, 2014, 11:49 a.m.)
> 
> 
> Review request for Plasma, Eike Hein, Marco Martin, and Sebastian Kügler.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This patch adds the support to have favourites linked to activities.
> 
> It uses org.kde.activities.ResourceModel to show favorites.
> 
> It supports:
>  - adding a favourite to all activities (the previous behaviour)
>  - adding a favourite to the current activity
>  - moving a favourite between 'all activities' and 'current activity' modes 
> (it does not affect non-current activities)
>  - drag-and-drop reordering of items (like the previous one)
>  - sorting A-Z, Z-A (like the previous one)
>  - transitions previously defined favourites to the new system*
> 
> Context menu item captions could maybe use some improvement.
> 
> Screenshot available at: 
> http://ivan.fomentgroup.org/blog/2014/07/27/per-activity-favourites-in-kickoff/#/comments
> 
> * this can also be used for defining the default favourites in a global 
> kickoffrc file - instead of them being hard-coded like they currently are.
> 
> 
> Diffs
> -
> 
>   applets/kickoff/CMakeLists.txt 28e7029 
>   applets/kickoff/core/favoritesmodel.h 27a0626 
>   applets/kickoff/core/favoritesmodel.cpp f05588b 
>   applets/kickoff/core/kickoffplugin.cpp f549981 
>   applets/kickoff/core/krunnermodel.h 3916829 
>   applets/kickoff/core/krunnermodel.cpp db2adab 
>   applets/kickoff/package/contents/ui/ContextMenu.qml 6a67874 
>   applets/kickoff/package/contents/ui/FavoritesView.qml 6c2d5d4 
>   applets/kickoff/package/contents/ui/FullRepresentation.qml 6291b7c 
> 
> Diff: https://git.reviewboard.kde.org/r/119515/diff/
> 
> 
> Testing
> ---
> 
> Yes
> 
> 
> Thanks,
> 
> Ivan Čukić
> 
>

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

Review Request 119522: readlink fails whens the folder does not exist.

2014-07-28 Thread Rohan Garg


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

Review request for Plasma and Àlex Fiestas.


Repository: plasma-workspace


Description
---

https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/f01badb5aa3f76b27955f4fee2cb7281dd490353
 introduced a regression in startkde whereby if ~/.config does not exist 
readlink will not output the right path.

This leads to startkde trying to write to /startupconfigkeys or /kdeglobals 
which obviously won't work.

Since the original commit mentions that relative paths weren't working, I've 
taken a alternative approach of using ${HOME} instead.


Diffs
-

  startkde/startkde.cmake 281bd43 

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


Testing
---

Kubuntu Plasma 5 ISO's did not have the right cursor theme before this patch, 
after editing startkde by hand, the right files were being correctly written, 
and the cursor theme worked as expected.


Thanks,

Rohan Garg

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

Re: Review Request 119515: Support per-activity favourites



> On July 28, 2014, 12:03 p.m., Marco Martin wrote:
> > +1 from me, would like toknow from Eike if this provides all is needed for 
> > use cases outside kickoff
> 
> Eike Hein wrote:
> Kicker doesn't use Kickoff's models, i.e. activity support has to be 
> implemented in Kicker's own favorites model.

So, what is the decision for the kickoff patch?


- Ivan


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


On July 28, 2014, 11:49 a.m., Ivan Čukić wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119515/
> ---
> 
> (Updated July 28, 2014, 11:49 a.m.)
> 
> 
> Review request for Plasma, Eike Hein, Marco Martin, and Sebastian Kügler.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This patch adds the support to have favourites linked to activities.
> 
> It uses org.kde.activities.ResourceModel to show favorites.
> 
> It supports:
>  - adding a favourite to all activities (the previous behaviour)
>  - adding a favourite to the current activity
>  - moving a favourite between 'all activities' and 'current activity' modes 
> (it does not affect non-current activities)
>  - drag-and-drop reordering of items (like the previous one)
>  - sorting A-Z, Z-A (like the previous one)
>  - transitions previously defined favourites to the new system*
> 
> Context menu item captions could maybe use some improvement.
> 
> Screenshot available at: 
> http://ivan.fomentgroup.org/blog/2014/07/27/per-activity-favourites-in-kickoff/#/comments
> 
> * this can also be used for defining the default favourites in a global 
> kickoffrc file - instead of them being hard-coded like they currently are.
> 
> 
> Diffs
> -
> 
>   applets/kickoff/CMakeLists.txt 28e7029 
>   applets/kickoff/core/favoritesmodel.h 27a0626 
>   applets/kickoff/core/favoritesmodel.cpp f05588b 
>   applets/kickoff/core/kickoffplugin.cpp f549981 
>   applets/kickoff/core/krunnermodel.h 3916829 
>   applets/kickoff/core/krunnermodel.cpp db2adab 
>   applets/kickoff/package/contents/ui/ContextMenu.qml 6a67874 
>   applets/kickoff/package/contents/ui/FavoritesView.qml 6c2d5d4 
>   applets/kickoff/package/contents/ui/FullRepresentation.qml 6291b7c 
> 
> Diff: https://git.reviewboard.kde.org/r/119515/diff/
> 
> 
> Testing
> ---
> 
> Yes
> 
> 
> Thanks,
> 
> Ivan Čukić
> 
>

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

Re: Review Request 119464: port ToolButton to QtControls



> On July 28, 2014, 4:40 p.m., David Edmundson wrote:
> > >The ugly thing here is that QtControls ToolButton doesn't have a flat 
> > >property, it should probably be upstreamed, at least for compatibility 
> > >with the qwidgets ToolButton
> > 
> > I can't see a flat property on the widget's toolbutton. 
> > http://qt-project.org/doc/qt-5/qtoolbutton.html, which property are you 
> > thinking of?

right.
it's called autoRaise there, and it's the negation of flat


- Marco


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


On July 28, 2014, 3:50 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119464/
> ---
> 
> (Updated July 28, 2014, 3:50 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> this ports ToolButton.
> It's a different style than Button since it's way more complicated.
> 
> The ugly thing here is that QtControls ToolButton doesn't have a flat 
> property, it should probably be upstreamed, at least for compatibility with 
> the qwidgets ToolButton
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qml/styles/ComboBoxStyle.qml 
> 20caef6 
>   src/declarativeimports/plasmacomponents/qml/ToolButton.qml 6dcbf7b 
>   src/declarativeimports/plasmacomponents/qml/styles/ToolButtonStyle.qml 
> PRE-CREATION 
>   src/declarativeimports/plasmacomponents/qml/styles/ButtonStyle.qml d92a662 
> 
> Diff: https://git.reviewboard.kde.org/r/119464/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 119464: port ToolButton to QtControls


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


>The ugly thing here is that QtControls ToolButton doesn't have a flat 
>property, it should probably be upstreamed, at least for compatibility with 
>the qwidgets ToolButton

I can't see a flat property on the widget's toolbutton. 
http://qt-project.org/doc/qt-5/qtoolbutton.html, which property are you 
thinking of?

- David Edmundson


On July 28, 2014, 3:50 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119464/
> ---
> 
> (Updated July 28, 2014, 3:50 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> this ports ToolButton.
> It's a different style than Button since it's way more complicated.
> 
> The ugly thing here is that QtControls ToolButton doesn't have a flat 
> property, it should probably be upstreamed, at least for compatibility with 
> the qwidgets ToolButton
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qml/styles/ComboBoxStyle.qml 
> 20caef6 
>   src/declarativeimports/plasmacomponents/qml/ToolButton.qml 6dcbf7b 
>   src/declarativeimports/plasmacomponents/qml/styles/ToolButtonStyle.qml 
> PRE-CREATION 
>   src/declarativeimports/plasmacomponents/qml/styles/ButtonStyle.qml d92a662 
> 
> Diff: https://git.reviewboard.kde.org/r/119464/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Running Plasma on Qt 5.4

Hi,
Just in case somebody has the magic idea of trying Qt 5.4, bear in mind
that it's currently not working (or, well, working very bad). Here's a
patch if you really feel like trying it [1] which seems to work.

Cheers!
Aleix

[1] https://codereview.qt-project.org/#/c/90811/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: qml controls and documentation

On Mon, Jul 28, 2014 at 6:11 PM, Marco Martin  wrote:

> Hi all,
>
> right now the plasma qml components are documented not bad, like:
>
> http://api.kde.org/frameworks-api/frameworks5-apidocs/plasma-framework/html/classorg_1_1kde_1_1plasma_1_1components_1_1TextField.html
>
> however, porting them to QtControls, has the sideeffect of pretty much
> killing
> the documentation of those that will inherit from a qtcontrol.
>
> like, button became:
>
> http://api.kde.org/frameworks-api/frameworks5-apidocs/plasma-framework/html/classorg_1_1kde_1_1plasma_1_1components_1_1Button.html
>
> even tough one can just say just use the documentation of controls, since
> there isn't an exact 100% correspondence, i would like to still have that
> doc
> usable.
>
> does somebody knows if is possible with the markup used now for extracting
> documentation to still have comments to document all the properties, even
> those *not* defined in the qml file in question?
>

It should probably look more or less like KPushButton [1], properly showing
inheritance. Anybody knows how this is implemented in doxygen?

Aleix

[1]
http://api.kde.org/4.12-api/kdelibs-apidocs/kdeui/html/classKPushButton.html
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

qml controls and documentation

Hi all,

right now the plasma qml components are documented not bad, like:
http://api.kde.org/frameworks-api/frameworks5-apidocs/plasma-framework/html/classorg_1_1kde_1_1plasma_1_1components_1_1TextField.html

however, porting them to QtControls, has the sideeffect of pretty much killing 
the documentation of those that will inherit from a qtcontrol.

like, button became:
http://api.kde.org/frameworks-api/frameworks5-apidocs/plasma-framework/html/classorg_1_1kde_1_1plasma_1_1components_1_1Button.html

even tough one can just say just use the documentation of controls, since 
there isn't an exact 100% correspondence, i would like to still have that doc 
usable.

does somebody knows if is possible with the markup used now for extracting 
documentation to still have comments to document all the properties, even 
those *not* defined in the qml file in question?

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

Re: Minutes Monday Plasma Hangout

On Monday 28 July 2014, Marco Martin wrote:
> On Monday 28 July 2014, Sebastian Kügler wrote:
> > - Started mechanism to load stuff from Look and Feel packages
> > 
> >   would like comment on https://git.reviewboard.kde.org/r/119451/
> 
> Based on the discussion with David in the hangout, i would still do:
> - the look and feel package provides qml files for some parts of the shell
> - most theme elements (icons, plasma theme, widget style etc) are usually
> provided only referred in a config file
> - if a theme wants to phisically provide something, like a plasma theme,
> icon theme etc, it can, bout would be task of the kcm to either copy or
> make a link of say, the icon theme in the proper directory where an icon
> theme would be expected.
> - or in alternative, the theme could be specified in the config file as a
> full path, so for icons if you are using the "foo" look and feel package,
> you could have in kdeglobals
> 
> [Icons]
> Theme=~/.share/plasma/lookandfeel/foo/icons

comments on that?
furthermore, how would you prefer to use it?
as a standalone library? static in plasma-workspace stuff? in libplasmaquick?
other?


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

Re: Review Request 119464: port ToolButton to QtControls


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

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


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

this ports ToolButton.
It's a different style than Button since it's way more complicated.

The ugly thing here is that QtControls ToolButton doesn't have a flat property, 
it should probably be upstreamed, at least for compatibility with the qwidgets 
ToolButton


Diffs
-

  src/declarativeimports/plasmacomponents/qml/styles/ComboBoxStyle.qml 20caef6 
  src/declarativeimports/plasmacomponents/qml/ToolButton.qml 6dcbf7b 
  src/declarativeimports/plasmacomponents/qml/styles/ToolButtonStyle.qml 
PRE-CREATION 
  src/declarativeimports/plasmacomponents/qml/styles/ButtonStyle.qml d92a662 

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


Testing
---


Thanks,

Marco Martin

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

Re: Review Request 119464: port ToolButton to QtControls


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

Ship it!


Ship It!

- David Edmundson


On July 25, 2014, 4:52 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119464/
> ---
> 
> (Updated July 25, 2014, 4:52 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> this ports ToolButton.
> It's a different style than Button since it's way more complicated.
> 
> The ugly thing here is that QtControls ToolButton doesn't have a flat 
> property, it should probably be upstreamed, at least for compatibility with 
> the qwidgets ToolButton
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qml/styles/ComboBoxStyle.qml 
> 20caef6 
>   src/declarativeimports/plasmacomponents/qml/ToolButton.qml 6dcbf7b 
>   src/declarativeimports/plasmacomponents/qml/styles/ToolButtonStyle.qml 
> PRE-CREATION 
>   src/declarativeimports/plasmacomponents/qml/styles/ButtonStyle.qml d92a662 
> 
> Diff: https://git.reviewboard.kde.org/r/119464/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 119025: Actually pass IBUS_DEFINITIONS when compiling ibus-panel

2014-07-28 Thread Raphael Kubo da Costa



On July 19, 2014, 12:17 a.m., Vadim Zhukov wrote:
> > (As a general note, for build system related stuff like this you can also 
> > try including the "buildsystem" group, which can be more responsive at 
> > times)
> > 
> > > The ibus-panel can't build on OpenBSD because some required definitions 
> > > obtained from pkgconfig file are not used.
> > > 1. IBUS_DEFINITIONS is not used in ibus-panel/CMakeLists.txt
> > 
> > Can you post the error you get here? I've tried building kimtoy here on 
> > FreeBSD expecting to hit the same issue(s), but it all went along just fine.
> > 
> > > 2. IBUS_DEFINITIONS is not saved in cache, and thus isn't available at 
> > > compile time
> > 
> > This doesn't make much sense; all values found at configuration time in 
> > CMake are then used to generate your make/ninja/whatever files, regardless 
> > of whether they are cached or not.
> 
> Vadim Zhukov wrote:
> Raphael, thank you for your input!
> 
> The issue was caused by the fact that X includes are placed in the 
> /usr/X11R6/include directory on OpenBSD. This catalog is mentioned in 
> PC_IBUS_DEFINITIONS variable but isn't propagated to the caller of 
> find_package(IBus). Yes, I was wrong: the CACHE part may and should be 
> omitted. This patch was added by me a long time ago (7 Feb 2012 according to 
> git log; guess the KDE version used then), when I was much less expirienced 
> in CMake... I've started a massive push of OpenBSD local patches upstream 
> recently during OpenBSD hackathon, when I got time for such cleanup.
> 
> At the present time, the /usr/X11R6/include gets to the 
> include_directories() from another place, so the patch isn't required at all. 
> But, still, the PC_IBUS_DEFINITIONS should be respected, IMHO. What do you 
> think?
> 
> Please note that FreeBSD and OpenBSD and quiet different. So you can't 
> test on one OS instead of another.

> The issue was caused by the fact that X includes are placed in the 
> /usr/X11R6/include directory on OpenBSD. This catalog is mentioned in 
> PC_IBUS_DEFINITIONS variable but isn't propagated to the caller of 
> find_package(IBus).
> [...]
> At the present time, the /usr/X11R6/include gets to the include_directories() 
> from another place, so the patch isn't required at all. But, still, the 
> PC_IBUS_DEFINITIONS should be respected, IMHO. What do you think?

While that is not wrong, the approach we normally take with CMake is that 
pkg-config's presence is optional, and we don't depend on its output to be able 
to build a module. In practice, this means one should look for IBus and X11 
separately, as well as add their compiler flags/link against them 
independently. If kimtoy already does that, I just wouldn't make any change.

> Please note that FreeBSD and OpenBSD and quiet different. So you can't test 
> on one OS instead of another.

You don't need to preach to the choir :-) I'm well aware of the differences 
between them, my point is that in many cases packaging problems in one also 
impact the other (missing includes because people assume all software is in 
`/usr`, reliance on non-POSIX features without checking for their availability 
etc).


- Raphael


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


On July 19, 2014, 9:43 p.m., Vadim Zhukov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119025/
> ---
> 
> (Updated July 19, 2014, 9:43 p.m.)
> 
> 
> Review request for kde-workspace, Plasma and Hui Ni.
> 
> 
> Repository: kimtoy
> 
> 
> Description
> ---
> 
> The ibus-panel can't build on OpenBSD because some required definitions 
> obtained from pkgconfig file are not used. This happens due to the following 
> reasons:
> 
> 1. IBUS_DEFINITIONS is not used in ibus-panel/CMakeLists.txt
> 2. IBUS_DEFINITIONS is not saved in cache, and thus isn't available at 
> compile time
> 
> This patch resolves both issues and makes ibus-panel compile on OpenBSD.
> 
> (I found no suitable review group and therefore used "plasma" instead, as it 
> was in "plasma-addons" previously; please, feel free to correct me if I'm 
> wrong and sorry for any possible inconvenience)
> 
> ((as there was no feedback for more than a week, I've added "kde-workspace" 
> group to list of reviewers, too))
> 
> 
> Diffs
> -
> 
>   ibus-panel/CMakeLists.txt 3a1ee49 
> 
> Diff: https://git.reviewboard.kde.org/r/119025/diff/
> 
> 
> Testing
> ---
> 
> OpenBSD/i386-CURRENT, KDE 4.13 (it doesn't have kimtoy package, of course, 
> but the code is same)
> 
> 
> Thanks,
> 
> Vadim Zhukov
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org

Re: port plasma to imx6 device (cubox-i)

On Mon, Jul 21, 2014 at 2:32 PM, Malte Grosse 
wrote:

> Dear plasma team,
>
> ive seen a review about the new plasma 5.
> i really like the design - it looks really nice.
> my question is - if anybody is interested in porting the new plasma to the
> cubox-i?
> the cubox i is a small arm device (freescale imx6)
> http://www.solid-run.com/wiki/CuBox-i_Hardware
> the communnity currently tries to get the cubox into the mainline kernel.
> few operation systems already work on the cubox
> (debian,fedora,opensuse,arch linux...)
>
> I look forward to hearing from you shortly
>
> best
>
> Malte


Hi Malte,
If some OS already works it should mean KDE already works there, right?
What kind of port do you expect from the Plasma team?

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

Re: Using more of our CI, Coverage and cppcheck

On Sun, Jul 27, 2014 at 11:59 PM, Àlex Fiestas  wrote:

> Hi there!
>
> During this weekend Ben and I have enabled the code-coverage in plasma-
> framework, my personal idea is to enable it in most projects.
>
> We should not go loco with code coverage, we stand where we stand and
> adding
> test non-stop will not fix anything. What we can do though is use this
> tool to
> make sure we don't make the situation worse, and to check which parts might
> need special love.
>
> http://build.kde.org/job/plasma-framework_master_qt5/665/Variation=All,label=LINBUILDER/cobertura/
>
> Also, most projects have cppcheck enabled, this thing is usually right so
> we
> want to to make it happy:
>
> http://build.kde.org/job/plasma-framework_master_qt5/665/Variation=All,label=LINBUILDER/cppcheckResult/
>
> If you want to enable it in more projects, look at:
>
> https://techbase.kde.org/Development/Tutorials/Unittests#Coverage_tools_and_CI
>
> Cheers!
>

Looks interesting, lots of work to be done :).

>From the wiki: [1]
Do we need special powers to change these?

Aleix

[1] And add this option in the configuraiotn of your CI build:
http://quickgit.kde.org/?p=websites%2Fbuild-kde-org. [DEFAULT]
configureExtraArgs=-DBUILD_COVERAGE=ON
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 119515: Support per-activity favourites

2014-07-28 Thread Eike Hein



> On July 28, 2014, 12:03 p.m., Marco Martin wrote:
> > +1 from me, would like toknow from Eike if this provides all is needed for 
> > use cases outside kickoff

Kicker doesn't use Kickoff's models, i.e. activity support has to be 
implemented in Kicker's own favorites model.


- Eike


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


On July 28, 2014, 11:49 a.m., Ivan Čukić wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119515/
> ---
> 
> (Updated July 28, 2014, 11:49 a.m.)
> 
> 
> Review request for Plasma, Eike Hein, Marco Martin, and Sebastian Kügler.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This patch adds the support to have favourites linked to activities.
> 
> It uses org.kde.activities.ResourceModel to show favorites.
> 
> It supports:
>  - adding a favourite to all activities (the previous behaviour)
>  - adding a favourite to the current activity
>  - moving a favourite between 'all activities' and 'current activity' modes 
> (it does not affect non-current activities)
>  - drag-and-drop reordering of items (like the previous one)
>  - sorting A-Z, Z-A (like the previous one)
>  - transitions previously defined favourites to the new system*
> 
> Context menu item captions could maybe use some improvement.
> 
> Screenshot available at: 
> http://ivan.fomentgroup.org/blog/2014/07/27/per-activity-favourites-in-kickoff/#/comments
> 
> * this can also be used for defining the default favourites in a global 
> kickoffrc file - instead of them being hard-coded like they currently are.
> 
> 
> Diffs
> -
> 
>   applets/kickoff/CMakeLists.txt 28e7029 
>   applets/kickoff/core/favoritesmodel.h 27a0626 
>   applets/kickoff/core/favoritesmodel.cpp f05588b 
>   applets/kickoff/core/kickoffplugin.cpp f549981 
>   applets/kickoff/core/krunnermodel.h 3916829 
>   applets/kickoff/core/krunnermodel.cpp db2adab 
>   applets/kickoff/package/contents/ui/ContextMenu.qml 6a67874 
>   applets/kickoff/package/contents/ui/FavoritesView.qml 6c2d5d4 
>   applets/kickoff/package/contents/ui/FullRepresentation.qml 6291b7c 
> 
> Diff: https://git.reviewboard.kde.org/r/119515/diff/
> 
> 
> Testing
> ---
> 
> Yes
> 
> 
> Thanks,
> 
> Ivan Čukić
> 
>

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

Re: Minutes Monday Plasma Hangout

On Monday 28 July 2014, Sebastian Kügler wrote:
> - Started mechanism to load stuff from Look and Feel packages
>   would like comment on https://git.reviewboard.kde.org/r/119451/

Based on the discussion with David in the hangout, i would still do:
- the look and feel package provides qml files for some parts of the shell
- most theme elements (icons, plasma theme, widget style etc) are usually 
provided only referred in a config file
- if a theme wants to phisically provide something, like a plasma theme, icon 
theme etc, it can, bout would be task of the kcm to either copy or make a link 
of say, the icon theme in the proper directory where an icon theme would be 
expected.
- or in alternative, the theme could be specified in the config file as a full 
path, so for icons if you are using the "foo" look and feel package, you could 
have in kdeglobals

[Icons]
Theme=~/.share/plasma/lookandfeel/foo/icons



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

Re: Review Request 119515: Support per-activity favourites


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


+1 from me, would like toknow from Eike if this provides all is needed for use 
cases outside kickoff

- Marco Martin


On July 28, 2014, 11:49 a.m., Ivan Čukić wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119515/
> ---
> 
> (Updated July 28, 2014, 11:49 a.m.)
> 
> 
> Review request for Plasma, Eike Hein, Marco Martin, and Sebastian Kügler.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This patch adds the support to have favourites linked to activities.
> 
> It uses org.kde.activities.ResourceModel to show favorites.
> 
> It supports:
>  - adding a favourite to all activities (the previous behaviour)
>  - adding a favourite to the current activity
>  - moving a favourite between 'all activities' and 'current activity' modes 
> (it does not affect non-current activities)
>  - drag-and-drop reordering of items (like the previous one)
>  - sorting A-Z, Z-A (like the previous one)
>  - transitions previously defined favourites to the new system*
> 
> Context menu item captions could maybe use some improvement.
> 
> Screenshot available at: 
> http://ivan.fomentgroup.org/blog/2014/07/27/per-activity-favourites-in-kickoff/#/comments
> 
> * this can also be used for defining the default favourites in a global 
> kickoffrc file - instead of them being hard-coded like they currently are.
> 
> 
> Diffs
> -
> 
>   applets/kickoff/CMakeLists.txt 28e7029 
>   applets/kickoff/core/favoritesmodel.h 27a0626 
>   applets/kickoff/core/favoritesmodel.cpp f05588b 
>   applets/kickoff/core/kickoffplugin.cpp f549981 
>   applets/kickoff/core/krunnermodel.h 3916829 
>   applets/kickoff/core/krunnermodel.cpp db2adab 
>   applets/kickoff/package/contents/ui/ContextMenu.qml 6a67874 
>   applets/kickoff/package/contents/ui/FavoritesView.qml 6c2d5d4 
>   applets/kickoff/package/contents/ui/FullRepresentation.qml 6291b7c 
> 
> Diff: https://git.reviewboard.kde.org/r/119515/diff/
> 
> 
> Testing
> ---
> 
> Yes
> 
> 
> Thanks,
> 
> Ivan Čukić
> 
>

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

Review Request 119515: Support per-activity favourites


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

Review request for Plasma, Eike Hein, Marco Martin, and Sebastian Kügler.


Repository: plasma-desktop


Description
---

This patch adds the support to have favourites linked to activities.

It uses org.kde.activities.ResourceModel to show favorites.

It supports:
 - adding a favourite to all activities (the previous behaviour)
 - adding a favourite to the current activity
 - moving a favourite between 'all activities' and 'current activity' modes (it 
does not affect non-current activities)
 - drag-and-drop reordering of items (like the previous one)
 - sorting A-Z, Z-A (like the previous one)
 - transitions previously defined favourites to the new system*

Context menu item captions could maybe use some improvement.

Screenshot available at: 
http://ivan.fomentgroup.org/blog/2014/07/27/per-activity-favourites-in-kickoff/#/comments

* this can also be used for defining the default favourites in a global 
kickoffrc file - instead of them being hard-coded like they currently are.


Diffs
-

  applets/kickoff/CMakeLists.txt 28e7029 
  applets/kickoff/core/favoritesmodel.h 27a0626 
  applets/kickoff/core/favoritesmodel.cpp f05588b 
  applets/kickoff/core/kickoffplugin.cpp f549981 
  applets/kickoff/core/krunnermodel.h 3916829 
  applets/kickoff/core/krunnermodel.cpp db2adab 
  applets/kickoff/package/contents/ui/ContextMenu.qml 6a67874 
  applets/kickoff/package/contents/ui/FavoritesView.qml 6c2d5d4 
  applets/kickoff/package/contents/ui/FullRepresentation.qml 6291b7c 

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


Testing
---

Yes


Thanks,

Ivan Čukić

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

Re: Review Request 119513: reintroduce containmentForScreen(int screen, const QString &defaultPluginIfNonExistent, args)


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

(Updated July 28, 2014, 11:46 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

reintroduces an api call from plasma1:
its the only way to solve
https://bugs.kde.org/show_bug.cgi?id=337200
basically to avoid a crash when plasma starts with missing containments in the 
appletsrc and a locked corona, or a screen added with locked widgets.

it's the only entry point that allows a creation of a containment when widgets 
are locked


Diffs
-

  src/plasma/corona.h f60fd74 
  src/plasma/corona.cpp c6bd949 

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


Testing
---


Thanks,

Marco Martin

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

Re: Review Request 119513: reintroduce containmentForScreen(int screen, const QString &defaultPluginIfNonExistent, args)

2014-07-28 Thread Sebastian Kügler


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

Ship it!


Ship It!

- Sebastian Kügler


On July 28, 2014, 11:13 a.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119513/
> ---
> 
> (Updated July 28, 2014, 11:13 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> reintroduces an api call from plasma1:
> its the only way to solve
> https://bugs.kde.org/show_bug.cgi?id=337200
> basically to avoid a crash when plasma starts with missing containments in 
> the appletsrc and a locked corona, or a screen added with locked widgets.
> 
> it's the only entry point that allows a creation of a containment when 
> widgets are locked
> 
> 
> Diffs
> -
> 
>   src/plasma/corona.h f60fd74 
>   src/plasma/corona.cpp c6bd949 
> 
> Diff: https://git.reviewboard.kde.org/r/119513/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Review Request 119513: reintroduce containmentForScreen(int screen, const QString &defaultPluginIfNonExistent, args)


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

Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

reintroduces an api call from plasma1:
its the only way to solve
https://bugs.kde.org/show_bug.cgi?id=337200
basically to avoid a crash when plasma starts with missing containments in the 
appletsrc and a locked corona, or a screen added with locked widgets.

it's the only entry point that allows a creation of a containment when widgets 
are locked


Diffs
-

  src/plasma/corona.h f60fd74 
  src/plasma/corona.cpp c6bd949 

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


Testing
---


Thanks,

Marco Martin

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

Minutes Monday Plasma Hangout

2014-07-28 Thread Sebastian Kügler

Minutes Plasma Hangout week 31, 28th July 2014

Present: Antonis, Marco, David, Ivan, Jonathan, Vishesh, Sebastian, Aleix,


Aleix:
- worked on texture sharing in FrameSvg

Antonis:
- Worked on widgetexplorer in Active shell
- Worked on main containment for Active
- both need more work

David:
- Worked on porting SDDM's KCM
- Fixing KAuth in frameworks

Ivan:
- Activity switcher is almost complete
- Merging it bit by bit now
- Kickoff favorites model which takes activities into account to land in RB 
shortly
- Next up: pinned apps

Jonathan:
- Reminds of schedule: 
  - Thursday tagging Frameworks
  - Monday Plasma 5.0.1
- Plasma 5.0 ISO is there (non-Neon5)

Marco:
- Merged Applet alternatives feature
- started to move some PlasmaComponents to QQuickControls
  - Button is done & merged)
- Started mechanism to load stuff from Look and Feel packages
  would like comment on https://git.reviewboard.kde.org/r/119451/

Vishesh:
- Worked on enabling preview support in Milou (not enabled yet)
- Worked on removable media support
- Improved unicode support
- Worked on better xattr support
- Looked at kdeplasma-addons

Sebastian
- Moving KUser QML bindings into kdeclarative / coreaddons
- Working on KScreen backend using QScreen

-- 
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 119465: Have separate texture hashes for each window