Re: Review Request 127813: Reduce string modifications when calling translatePath

[Aleix Pol Gonzalez]

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

(Updated July 13, 2016, 12:37 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Matthew Dawson.


Changes
---

Submitted with commit 6c4e504d76b2424ac06c50394a0cca63860e65b5 by Aleix Pol to 
branch master.


Repository: kconfig


Description
---

Don't drop the file: prefix twice in every run.
Use appropriate API on paths rather than string handling, when possible.


Diffs
-

  src/core/kconfiggroup.cpp 39d2441 

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


Testing
---

Tests pass, apps work.


Thanks,

Aleix Pol Gonzalez

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: QIcon::fromTheme() does not load scalable icons

[Antonio Rojas]

Olivier Churlaud wrote:

> 
> Can you point me to the right place where to open the bug?
> 

Already fixed in 
http://commits.kde.org/kiconthemes/0abf1b7a148cf6b27caea01a329631e0f1daa983

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

[Differential] [Closed] D2142: KGlobalAccel: Fix deadlock on exit under Windows

[kfunk (Kevin Funk)]

kfunk closed this revision.
kfunk added a comment.


  Pushed.
  
  commit 2bdb684a872aff26c01f5e1fc175fbaf663ad8ba
  Author: Kevin Funk 
  Date:   Tue Jul 12 10:18:40 2016 +0200

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

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

To: kfunk, vonreth, graesslin, dfaure
Cc: graesslin, #frameworks
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

[Differential] [Accepted] D2142: KGlobalAccel: Fix deadlock on exit under Windows

[dfaure (David Faure)]

dfaure accepted this revision.
dfaure added a comment.


  Looks good to me. I don't think we have the need to use the singleton from 
other global destructors.

BRANCH
  master

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

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

To: kfunk, vonreth, graesslin, dfaure
Cc: graesslin, #frameworks
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: QIcon::fromTheme() does not load scalable icons

[Olivier Churlaud]

Le 12/07/2016 à 15:54, Elvis Angelaccio a écrit :

For some time I was debugging why TeXstudio didn't have an icon in the task
manager. After comparing, the only difference with working apps was that
TeXStudio has only an icon in

/usr/share/icons/hicolor/scalable/apps/texstudio.svg

but not in

/usr/share/icons/hicolor/32x32/apps/texstudio.png
/usr/share/icons/hicolor/..x../apps/texstudio.png
...

Exporting a png icon and copy pasting it at theses missing places corrected
the issue.

Now the question

Is it a bug from Qt or KDE? Or does the upstream dev or packager generate
and ship the png files? The latter seems stupid as it makes a lot of
redundancy.

Can you point me to the right place where to open the bug?

Not sure this is an actual bug. Applications are supposed to ship the
app icon in png format. See this thread [1] for more informations.
Ok, according to the thread the problem comes from upstream or 
packaging. Where should I open the bug?


Cheers
Olivier

Cheers
Elvis

[1]: 
http://lists-archives.com/kde-devel/34061-how-to-properly-install-app-icons.html



Thank you

Olivier


--
Olivier CHURLAUD
Engineer Student at Ecole Centrale de Lyon
in Dual Degree at TU Berlin, M.Sc. Elektrotechnik
@: oliv...@churlaud.com
tel: +49 (0)1575-2931348
in:  http://linkedin.com/in/olivierchurlaud
web: http://olivier.churlaud.com


___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel



___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: QIcon::fromTheme() does not load scalable icons

[Elvis Angelaccio]

2016-07-12 15:47 GMT+02:00 Olivier Churlaud :
> Hello

Hi

>
> For some time I was debugging why TeXstudio didn't have an icon in the task
> manager. After comparing, the only difference with working apps was that
> TeXStudio has only an icon in
>
> /usr/share/icons/hicolor/scalable/apps/texstudio.svg
>
> but not in
>
> /usr/share/icons/hicolor/32x32/apps/texstudio.png
> /usr/share/icons/hicolor/..x../apps/texstudio.png
> ...
>
> Exporting a png icon and copy pasting it at theses missing places corrected
> the issue.
>
> Now the question
>
> Is it a bug from Qt or KDE? Or does the upstream dev or packager generate
> and ship the png files? The latter seems stupid as it makes a lot of
> redundancy.
>
> Can you point me to the right place where to open the bug?

Not sure this is an actual bug. Applications are supposed to ship the
app icon in png format. See this thread [1] for more informations.

Cheers
Elvis

[1]: 
http://lists-archives.com/kde-devel/34061-how-to-properly-install-app-icons.html


>
> Thank you
>
> Olivier
>
>
> --
> Olivier CHURLAUD
> Engineer Student at Ecole Centrale de Lyon
> in Dual Degree at TU Berlin, M.Sc. Elektrotechnik
> @: oliv...@churlaud.com
> tel: +49 (0)1575-2931348
> in:  http://linkedin.com/in/olivierchurlaud
> web: http://olivier.churlaud.com
>
>
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

QIcon::fromTheme() does not load scalable icons

[Olivier Churlaud]

Hello

For some time I was debugging why TeXstudio didn't have an icon in the 
task manager. After comparing, the only difference with working apps was 
that TeXStudio has only an icon in


/usr/share/icons/hicolor/scalable/apps/texstudio.svg

but not in

/usr/share/icons/hicolor/32x32/apps/texstudio.png
/usr/share/icons/hicolor/..x../apps/texstudio.png
...

Exporting a png icon and copy pasting it at theses missing places 
corrected the issue.


*Now the question*

Is it a bug from Qt or KDE? Or does the upstream dev or packager 
generate and ship the png files? The latter seems stupid as it makes a 
lot of redundancy.


Can you point me to the right place where to open the bug?

Thank you

Olivier


--
Olivier CHURLAUD
Engineer Student at Ecole Centrale de Lyon
in Dual Degree at TU Berlin, M.Sc. Elektrotechnik
@: oliv...@churlaud.com
tel: +49 (0)1575-2931348
in:  http://linkedin.com/in/olivierchurlaud
web: http://olivier.churlaud.com

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128426: Support OpenGL 3.2 Core profile in FadingNode shaders

[Martin Gräßlin]

> On July 12, 2016, 8:07 a.m., Martin Gräßlin wrote:
> > What about shader variants for GLES? There are also two versions, one being 
> > like the old one and one like core. In KWin we can handle this with the 
> > same shader code and rewriting e.g. the version statement. Do you know how 
> > this is handled in QtQuick?
> 
> David Edmundson wrote:
> As I understand it GLES is a subset of GL, so as long as you just stick 
> to using only subset in the first place you don't need two.
> 
> I tried to mimc what Qt does exactly. They seem to just have the two:
> "normal" and ">3.2 Core" both completely from scratch.
> Poke me on IRC and I'll point you to the code locations.
>  
> The only difference is they have the shaders as embedded Qt resources 
> file and load them by name.

GLES being a subset of GL - keep on dreaming ;-) GLES is both a subset and a 
superset of GL. And the shading language has quite some differences, especially 
different version numbers.

KWin's generation code is:
} else {
const bool glsl_es_300 = GLPlatform::instance()->glslVersion() >= 
kVersionNumber(3, 0);

if (glsl_es_300)
stream << "#version 300 es\n\n";

// From the GLSL ES specification:
//
// "The fragment language has no default precision qualifier for 
floating point types."
stream << "precision highp float;\n\n";

varying   = glsl_es_300 ? QByteArrayLiteral("in") : 
QByteArrayLiteral("varying");
textureLookup = glsl_es_300 ? QByteArrayLiteral("texture"): 
QByteArrayLiteral("texture2D");
output= glsl_es_300 ? QByteArrayLiteral("fragColor")  : 
QByteArrayLiteral("gl_FragColor");
}

In general each and every function one uses needs to be verified whether they 
exist in GLES and in which version. GLSL is a mess in that regard. I hate it 
that you need to write your code four times and that's why KWin mostly 
generates the code nowadays.


- Martin


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


On July 12, 2016, 1:34 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128426/
> ---
> 
> (Updated July 12, 2016, 1:34 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Qt has two shaders for all items; one for when running OpenGL3.2+ without 
> backwards compatibility (i.e running CoreProfile) and one that supports more 
> legacy systems. (see
> the shaders directory and the versions ending with _core)
> 
> core profile is only used if explicitly by the app enabled when creating the 
> GL context. 
> 
> Something we don't currently do in Plasma, but a 3d party user could be doing.
> 
> Long term it's also something I want to do in Plasma optionally as it gives a 
> 15Mb memory saving with Mesa.
> 
> This patch updates our material to provide the right shader for the
> given version matching the behavior of
> QSGShaderSourceBuilder::resolveShaderPath which Qt uses internally.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/fadingnode.cpp 
> 88b7310641f58c2b74fe61d2c5a97847cf7dc3b8 
> 
> Diff: https://git.reviewboard.kde.org/r/128426/diff/
> 
> 
> Testing
> ---
> 
> ran krunner with 
> +QSurfaceFormat format;
> +format.setVersion(3,2);
> +format.setProfile(QSurfaceFormat::CoreProfile);
> +QSurfaceFormat::setDefaultFormat(format);
> 
> and it still works.
> 
> plasmashell unchanged (so still requesting an GL 2.0 context) also still 
> works.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128426: Support OpenGL 3.2 Core profile in FadingNode shaders

[David Edmundson]

> On July 12, 2016, 6:07 a.m., Martin Gräßlin wrote:
> > What about shader variants for GLES? There are also two versions, one being 
> > like the old one and one like core. In KWin we can handle this with the 
> > same shader code and rewriting e.g. the version statement. Do you know how 
> > this is handled in QtQuick?

As I understand it GLES is a subset of GL, so as long as you just stick to 
using only subset in the first place you don't need two.

I tried to mimc what Qt does exactly. They seem to just have the two:
"normal" and ">3.2 Core" both completely from scratch.
Poke me on IRC and I'll point you to the code locations.
 
The only difference is they have the shaders as embedded Qt resources file and 
load them by name.


> On July 12, 2016, 6:07 a.m., Martin Gräßlin wrote:
> > src/declarativeimports/core/fadingnode.cpp, line 72
> > 
> >
> > varying doesn't exist in core profile. It's "out"

You're right - weird that it threw a fatal error over "attribute" but not this 
one - when they're both equally deprecated.


- David


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


On July 11, 2016, 11:34 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128426/
> ---
> 
> (Updated July 11, 2016, 11:34 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Qt has two shaders for all items; one for when running OpenGL3.2+ without 
> backwards compatibility (i.e running CoreProfile) and one that supports more 
> legacy systems. (see
> the shaders directory and the versions ending with _core)
> 
> core profile is only used if explicitly by the app enabled when creating the 
> GL context. 
> 
> Something we don't currently do in Plasma, but a 3d party user could be doing.
> 
> Long term it's also something I want to do in Plasma optionally as it gives a 
> 15Mb memory saving with Mesa.
> 
> This patch updates our material to provide the right shader for the
> given version matching the behavior of
> QSGShaderSourceBuilder::resolveShaderPath which Qt uses internally.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/fadingnode.cpp 
> 88b7310641f58c2b74fe61d2c5a97847cf7dc3b8 
> 
> Diff: https://git.reviewboard.kde.org/r/128426/diff/
> 
> 
> Testing
> ---
> 
> ran krunner with 
> +QSurfaceFormat format;
> +format.setVersion(3,2);
> +format.setProfile(QSurfaceFormat::CoreProfile);
> +QSurfaceFormat::setDefaultFormat(format);
> 
> and it still works.
> 
> plasmashell unchanged (so still requesting an GL 2.0 context) also still 
> works.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

[Differential] [Commented On] D2142: KGlobalAccel: Fix deadlock on exit under Windows

[kfunk (Kevin Funk)]

kfunk added a comment.


  FYI: There are more issues in other frameworks, the next deadlock is in 
kiconthemes...

BRANCH
  master

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

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

To: kfunk, dfaure, vonreth, graesslin
Cc: graesslin, #frameworks
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

[Differential] [Commented On] D2142: KGlobalAccel: Fix deadlock on exit under Windows

[kfunk (Kevin Funk)]

kfunk added a comment.


  Waiting for a +1 from David.
  
  There's one possible point of regression, namely if `KGlobalAccel::self()` is 
being used after qApp ran all the post routines (and 
`KGlobalAccelPrivate::cleanup()` has been invoked already). Not sure if this is 
a problem, though.

BRANCH
  master

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

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

To: kfunk, dfaure, vonreth, graesslin
Cc: graesslin, #frameworks
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

[Differential] [Accepted] D2142: KGlobalAccel: Fix deadlock on exit under Windows

[Martin Gräßlin]

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


  nice one.

BRANCH
  master

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

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

To: kfunk, dfaure, vonreth, graesslin
Cc: graesslin, #frameworks
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

[Differential] [Updated] D2142: KGlobalAccel: Fix deadlock on exit under Windows

[kfunk (Kevin Funk)]

kfunk added reviewers: dfaure, vonreth.
kfunk added a subscriber: Frameworks.

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

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

To: kfunk, dfaure, vonreth
Cc: #frameworks
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 128428: KRecursiveFilterProxyModel: fix QSFPM corruption due to filtering out rowsRemoved signal

[David Faure]

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

Review request for KDE Frameworks, Laurent Montel and Stephen Kelly.


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


Repository: kitemmodels


Description
---

If the row being removed from the source model isn't shown by KRFPM,
it's correct that we don't need to emit any signals, however we still
need to tell our base class QSFPM so that it updates the mappings
of the visible siblings below that removed row.

Testcase: deleting the Last Search folder in kmail
(full integration test for this testcase will be added to mailcommon).


Diffs
-

  autotests/krecursivefilterproxymodeltest.cpp 
85dbdfa293563671f885df8d09bac30db64ec1cc 
  src/krecursivefilterproxymodel.cpp 10632ec00f2942ba559f710fc83f60dfd84af790 

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


Testing
---

* Removing the Last Search folder in kmail
* This unittest showed [3* ] instead of [2* 3*] before the fix
* As mentionned, I wrote an automated test in mailcommon that creates+deletes 
the search folder, after ensuring it's above other resources in the ETM 
toplevel collection order.
I spent about 15-20 hours debugging this before finally being able to create a 
failing test (then it was easy).


Thanks,

David Faure

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128397: KIconEngine: Fix QIcon::hasThemeIcon always returning true

[David Rosca]

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

(Updated July 12, 2016, 12:55 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Olivier Goffart.


Changes
---

Submitted with commit 0abf1b7a148cf6b27caea01a329631e0f1daa983 by David Rosca 
to branch master.


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


Repository: kiconthemes


Description
---

QIcon::hasThemeIcon(name) checks if QIcon::name() == name, so icon engine must 
return empty string when icon doesn't exist.
Also implement IsNullHook for Qt 5.7. Comes with autotest.


Diffs
-

  autotests/CMakeLists.txt 0c7de50 
  autotests/kiconengine_unittest.cpp PRE-CREATION 
  src/kiconengine.h 21a63f5 
  src/kiconengine.cpp 3ccc7d1 

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


Testing
---

Issue was reported in https://bugreports.qt.io/browse/QTBUG-54595
Also similar issue https://bugs.kde.org/show_bug.cgi?id=365031 (there is a 
check for hasThemeIcon before using the icon, but it returns true which results 
in invalid icon name -> no icon).


Thanks,

David Rosca

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128427: Make sure ECMGeneratePriFile.cmake behaves like the rest of ECM

[Antonio Rojas]

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



Works here, thanks

- Antonio Rojas


On Jul. 12, 2016, 12:21 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128427/
> ---
> 
> (Updated Jul. 12, 2016, 12:21 a.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and Antonio Rojas.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> In `KDEInstallDirs` we have some code to make sure that qmake is asked when 
> the project shares the prefix with the installed Qt, to make sure that if 
> something was changed in the distribution it would reflect on the projects.
> Make sure PRI files are installed using the same reasoning.
> 
> 
> Diffs
> -
> 
>   modules/ECMGeneratePriFile.cmake af4b877 
> 
> Diff: https://git.reviewboard.kde.org/r/128427/diff/
> 
> 
> Testing
> ---
> 
> The issue was reported by `arojas`, I haven't been able to reproduce myself.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128426: Support OpenGL 3.2 Core profile in FadingNode shaders

[Martin Gräßlin]

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



What about shader variants for GLES? There are also two versions, one being 
like the old one and one like core. In KWin we can handle this with the same 
shader code and rewriting e.g. the version statement. Do you know how this is 
handled in QtQuick?


src/declarativeimports/core/fadingnode.cpp (line 72)


varying doesn't exist in core profile. It's "out"



src/declarativeimports/core/fadingnode.cpp (line 93)


s/varying/in


- Martin Gräßlin


On July 12, 2016, 1:34 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128426/
> ---
> 
> (Updated July 12, 2016, 1:34 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Qt has two shaders for all items; one for when running OpenGL3.2+ without 
> backwards compatibility (i.e running CoreProfile) and one that supports more 
> legacy systems. (see
> the shaders directory and the versions ending with _core)
> 
> core profile is only used if explicitly by the app enabled when creating the 
> GL context. 
> 
> Something we don't currently do in Plasma, but a 3d party user could be doing.
> 
> Long term it's also something I want to do in Plasma optionally as it gives a 
> 15Mb memory saving with Mesa.
> 
> This patch updates our material to provide the right shader for the
> given version matching the behavior of
> QSGShaderSourceBuilder::resolveShaderPath which Qt uses internally.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/fadingnode.cpp 
> 88b7310641f58c2b74fe61d2c5a97847cf7dc3b8 
> 
> Diff: https://git.reviewboard.kde.org/r/128426/diff/
> 
> 
> Testing
> ---
> 
> ran krunner with 
> +QSurfaceFormat format;
> +format.setVersion(3,2);
> +format.setProfile(QSurfaceFormat::CoreProfile);
> +QSurfaceFormat::setDefaultFormat(format);
> 
> and it still works.
> 
> plasmashell unchanged (so still requesting an GL 2.0 context) also still 
> works.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel