Re: Review Request 125736: Add Skip Window Close Animation to KWindowEffects

[Boudhayan Gupta]

> On Oct. 23, 2015, 12:11 p.m., Martin Gräßlin wrote:
> > src/kwindoweffects.h, lines 162-168
> > 
> >
> > Maybe we should extend the documentation a little bit? E.g. that it's 
> > only a hint to the WM, that it's free to ignore it, that not all WMs might 
> > support it.
> > 
> > Maybe also give an example for a use case? The screen shot case?

Yep, that sounds like a good idea. I'll do that.


> On Oct. 23, 2015, 12:11 p.m., Martin Gräßlin wrote:
> > src/platforms/xcb/kwindoweffects.cpp, lines 73-75
> > 
> >
> > Just as a note: KWin doesn't set the atom name on the root window, so 
> > it will always return false in this case.
> > 
> > At the moment I don't have an idea for how to do it. Normal way would 
> > be to add it to the NET_SUPPORTED in NETWM.

So should I always return true for this for now? This does mean that the API 
will be lying, at least for now.


> On Oct. 23, 2015, 12:11 p.m., Martin Gräßlin wrote:
> > src/platforms/xcb/kwindoweffects.cpp, line 333
> > 
> >
> > nitpick: unrelated whitespace change.

That's my text-editor (Atom) being a smart-ass. If you really don't want this 
in the patch, I'll use a second text-editor that doesn't automatically trim 
empty lines (nano?) to re-add the space.


- Boudhayan


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


On Oct. 21, 2015, 8:53 p.m., Boudhayan Gupta wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125736/
> ---
> 
> (Updated Oct. 21, 2015, 8:53 p.m.)
> 
> 
> Review request for KDE Frameworks and Martin Gräßlin.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> Adds a Skip Window Close Animation effect to KWindowEffects, with an 
> implementation for X11.
> 
> Binary compatibility with older plugins is **not** preserved. I welcome 
> comments on how exactly to do this - creating a new base class 
> (KWindowEffectsPrivate2 based on KWindowEffectsPrivate and basing the plugins 
> off that sounds kind of complicated). Maybe we can just drop internal ABI 
> compatibility and update kwayland-integration to implement the new method too?
> 
> 
> Diffs
> -
> 
>   autotests/kwindoweffectstest.cpp 0e83bdc 
>   src/CMakeLists.txt 1598b4f 
>   src/kwindoweffects.h bf0ea1e 
>   src/kwindoweffects.cpp 0c6600f 
>   src/kwindoweffects_dummy.cpp 65924ae 
>   src/kwindoweffects_dummy_p.h 2beabdd 
>   src/kwindoweffects_extensions_p.h PRE-CREATION 
>   src/platforms/xcb/atoms_p.h b5a6e7e 
>   src/platforms/xcb/kwindoweffects.cpp c8da6d2 
>   src/platforms/xcb/kwindoweffects_x11.h c240ddf 
> 
> Diff: https://git.reviewboard.kde.org/r/125736/diff/
> 
> 
> Testing
> ---
> 
> * make test succeeds with the new plugin installed
> * make test succeeds on all tests in the kwindoweffects test except the 
> skipCloseAnimation unit with the old plugin installed. skipCloseAnimation 
> segfaults.
> 
> 
> Thanks,
> 
> Boudhayan Gupta
> 
>

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

Re: Review Request 125736: Add Skip Window Close Animation to KWindowEffects

[Martin Gräßlin]

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



src/kwindoweffects.h (lines 162 - 168)


Maybe we should extend the documentation a little bit? E.g. that it's only 
a hint to the WM, that it's free to ignore it, that not all WMs might support 
it.

Maybe also give an example for a use case? The screen shot case?



src/platforms/xcb/kwindoweffects.cpp (lines 73 - 75)


Just as a note: KWin doesn't set the atom name on the root window, so it 
will always return false in this case.

At the moment I don't have an idea for how to do it. Normal way would be to 
add it to the NET_SUPPORTED in NETWM.



src/platforms/xcb/kwindoweffects.cpp (line 333)


nitpick: unrelated whitespace change.


- Martin Gräßlin


On Oct. 21, 2015, 5:23 p.m., Boudhayan Gupta wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125736/
> ---
> 
> (Updated Oct. 21, 2015, 5:23 p.m.)
> 
> 
> Review request for KDE Frameworks and Martin Gräßlin.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> Adds a Skip Window Close Animation effect to KWindowEffects, with an 
> implementation for X11.
> 
> Binary compatibility with older plugins is **not** preserved. I welcome 
> comments on how exactly to do this - creating a new base class 
> (KWindowEffectsPrivate2 based on KWindowEffectsPrivate and basing the plugins 
> off that sounds kind of complicated). Maybe we can just drop internal ABI 
> compatibility and update kwayland-integration to implement the new method too?
> 
> 
> Diffs
> -
> 
>   autotests/kwindoweffectstest.cpp 0e83bdc 
>   src/CMakeLists.txt 1598b4f 
>   src/kwindoweffects.h bf0ea1e 
>   src/kwindoweffects.cpp 0c6600f 
>   src/kwindoweffects_dummy.cpp 65924ae 
>   src/kwindoweffects_dummy_p.h 2beabdd 
>   src/kwindoweffects_extensions_p.h PRE-CREATION 
>   src/platforms/xcb/atoms_p.h b5a6e7e 
>   src/platforms/xcb/kwindoweffects.cpp c8da6d2 
>   src/platforms/xcb/kwindoweffects_x11.h c240ddf 
> 
> Diff: https://git.reviewboard.kde.org/r/125736/diff/
> 
> 
> Testing
> ---
> 
> * make test succeeds with the new plugin installed
> * make test succeeds on all tests in the kwindoweffects test except the 
> skipCloseAnimation unit with the old plugin installed. skipCloseAnimation 
> segfaults.
> 
> 
> Thanks,
> 
> Boudhayan Gupta
> 
>

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

Re: icons packages with frameworks

[Christoph Cullmann]

Hi,

patch for the 2) issue is there:

https://git.reviewboard.kde.org/r/125760/

Greetings
Christoph

- Am 22. Okt 2015 um 23:15 schrieb cullmann cullm...@absint.com:

> Hi,
> 
> btw., to get all things working even if breeze in bundled in that way one 
> needs
> in addition:
> 
> 1) breeze to be default theme in kiconthemes or a way to set it manually
> 2) :/icons being in default search paths in kiconsthemes, too.
> 
> For 2) I already have a patch, is some "setDefaultIconTheme" wanted, too, or 
> do
> we want
> to switch to breeze for that in the near future anyway?
> 
> Didn't follow the oxygen => breeze and back switch discussion for KIconThemes 
> in
> detail.
> 
> Greetings
> Christoph
> 
> - Am 21. Okt 2015 um 21:07 schrieb cullmann cullm...@absint.com:
> 
>> Hi,
>> 
 So maybe this wouldn't be such a bad move after all.
>>> 
>>> Agreed, we have frameworks (e.g. KIconThemes) "depending" on breeze, so it
>>> makes some kind of sense to ship them together.
>> yeah, beside that, if you want to create some self-contained installers,
>> you need breeze (or some other full iconset), too.
>> 
>> Therefore it is nice if one can grab the release matching the framework 
>> release
>> one uses.
>> 
>> Greetings
>> Christoph
>> 
>> --
>> - Dr.-Ing. Christoph Cullmann -
>> AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
>> Science Park 1 Tel:   +49-681-38360-22
>> 66123 Saarbrücken  Fax:   +49-681-38360-20
>> GERMANYWWW:   http://www.AbsInt.com
>> 
>> Geschäftsführung: Dr.-Ing. Christian Ferdinand
>> Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
>> ___
>> Kde-frameworks-devel mailing list
>> Kde-frameworks-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
> 
> --
> - Dr.-Ing. Christoph Cullmann -
> AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
> Science Park 1 Tel:   +49-681-38360-22
> 66123 Saarbrücken  Fax:   +49-681-38360-20
> GERMANYWWW:   http://www.AbsInt.com
> 
> Geschäftsführung: Dr.-Ing. Christian Ferdinand
> Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 125760: Allow local embedded themes, like Qt does a default search in :/icons

[Christoph Cullmann]

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

Review request for KDE Frameworks, Christoph Feck and Boudewijn Rempt.


Repository: kiconthemes


Description
---

Allow icon themes to be embedded in applications and prefer the embedded ones, 
if e.g. Krita or Kate ships an embedded theme, that shall be found and used.
Qt does already do so, by searching in :/icons.


Diffs
-

  src/kicontheme.cpp d0ab4b9 

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


Testing
---

Themes still work, if you have the right theme in :/icons it is found, in 
contrast to before this patch.
Still a problem, that I need to takle in a different patch: How to enforce the 
use of some theme, Qt is able to do so via setThemeName, KIconLoader and Co. 
ignore that.


Thanks,

Christoph Cullmann

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

Re: Review Request 125164: Finish killed KIO jobs

[Aleix Pol Gonzalez]

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

(Updated Oct. 23, 2015, 2:48 a.m.)


Review request for KDE Frameworks.


Changes
---

When killing a job, report it as finished.


Summary (updated)
-

Finish killed KIO jobs


Repository: kio


Description (updated)
---

Scheduler::jobFinished cleans up the job but doesn't report it as such.


Diffs (updated)
-

  src/core/simplejob.cpp 3380cbe 
  autotests/jobtest.cpp c24bcea 
  autotests/jobtest.h ef8c3e1 

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


Testing
---

Added a test and made it pass.


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 125164: Fix misbehavior when canceling a job

[Aleix Pol Gonzalez]

> On Oct. 22, 2015, 9:39 a.m., David Faure wrote:
> > src/core/transferjob.cpp, line 400
> > 
> >
> > Why slotFinished? Wouldn't just return be enough?
> > kill() is supposed to take care of emitting finished already, and you 
> > don't want to emit it twice.
> 
> Aleix Pol Gonzalez wrote:
> slotFinished is never called, if I remove the slotFinished call the test 
> never ends.

I got deep to the issue. Here's the catch:
SchedulerPrivate::jobFinished did finish the job, but it didn't emit anything. 
slotFinished actually needed to be called after killing the job.

Then the modification in TransferJob isn't needed, which restores all of our 
karma and gives us an extra life and 10 coins. *happy*


- Aleix


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


On Oct. 23, 2015, 2:19 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125164/
> ---
> 
> (Updated Oct. 23, 2015, 2:19 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Catch that the job has been cancelled and emit the job as finished.
> 
> Still, I'm not too sure it's the correct fix.
> 
> 
> Diffs
> -
> 
>   autotests/jobtest.h ef8c3e1 
>   autotests/jobtest.cpp c24bcea 
>   src/core/transferjob.cpp 0c38070 
> 
> Diff: https://git.reviewboard.kde.org/r/125164/diff/
> 
> 
> Testing
> ---
> 
> Added a test and made it pass.
> 
> 
> 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 125164: Fix misbehavior when canceling a job

[Aleix Pol Gonzalez]

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

(Updated Oct. 23, 2015, 2:19 a.m.)


Review request for KDE Frameworks.


Changes
---

Simplified test.


Repository: kio


Description
---

Catch that the job has been cancelled and emit the job as finished.

Still, I'm not too sure it's the correct fix.


Diffs (updated)
-

  autotests/jobtest.h ef8c3e1 
  autotests/jobtest.cpp c24bcea 
  src/core/transferjob.cpp 0c38070 

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


Testing
---

Added a test and made it pass.


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 125164: Fix misbehavior when canceling a job

[Aleix Pol Gonzalez]

> On Oct. 22, 2015, 9:39 a.m., David Faure wrote:
> > autotests/jobtest.cpp, line 309
> > 
> >
> > What is the purpose of changing the currently-being-uploaded data 
> > buffer? Ah, from the fix I can see the purpose is to make it emit 
> > readyRead. Can you add a comment here like  "// make it emit readyRead..." 
> > if that's indeed the idea?
> > 
> > (I assume this is to emulate something more like a socket?)

Correct, we originally spot this when testing KDE Connect transfers.


> On Oct. 22, 2015, 9:39 a.m., David Faure wrote:
> > src/core/transferjob.cpp, line 400
> > 
> >
> > Why slotFinished? Wouldn't just return be enough?
> > kill() is supposed to take care of emitting finished already, and you 
> > don't want to emit it twice.

slotFinished is never called, if I remove the slotFinished call the test never 
ends.


- Aleix


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


On Sept. 11, 2015, 3:24 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125164/
> ---
> 
> (Updated Sept. 11, 2015, 3:24 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Catch that the job has been cancelled and emit the job as finished.
> 
> Still, I'm not too sure it's the correct fix.
> 
> 
> Diffs
> -
> 
>   autotests/jobtest.h ef8c3e1 
>   autotests/jobtest.cpp c24bcea 
>   src/core/transferjob.cpp 0c38070 
> 
> Diff: https://git.reviewboard.kde.org/r/125164/diff/
> 
> 
> Testing
> ---
> 
> Added a test and made it pass.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: [KDE/Mac] Question about goal of Windows/Mac frameworks

[René J . V . Bertin]

On Wednesday October 21 2015 13:08:46 Dominik Haumann wrote:

> In Windows, such a package manager does not exist. KDE tried to create
> such a package manager through the emerge/KDE Windows installer, but
> this is non-standard [on Windows] and simply not what users want.

That's not entirely accurate. Microsoft themselves push updates through the 
equivalent of a package manager (I'm getting updates for stuff used by MS 
Office without even having that suite installed). If you install Apple software 
you'll get Apple Software Update which does what its name suggest (how many 
iPhone users don't own a Mac - clearly they are not annoyed enough with the 
situation to dump either the iPhone or MS Windows).

I'm only an occasional MSWin user these days, so I'm not going to say much more 
about this, other than that I'd hesitate a lot to install binary packages 
provided by the KDE community if those all installed their own copy of the 
required dependencies. A matter of principle which I'd also apply to a 
commercial entity providing a range of KF5 applications (those could all share 
a dedicated set of Qt/KF5 dependencies, though). Also, I suppose that if KF5 
applications were to be provided by cygwin, they'd want resources to be shared.

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

Re: icons packages with frameworks

[Christoph Cullmann]

Hi,

btw., to get all things working even if breeze in bundled in that way one needs 
in addition:

1) breeze to be default theme in kiconthemes or a way to set it manually
2) :/icons being in default search paths in kiconsthemes, too.

For 2) I already have a patch, is some "setDefaultIconTheme" wanted, too, or do 
we want
to switch to breeze for that in the near future anyway?

Didn't follow the oxygen => breeze and back switch discussion for KIconThemes 
in detail.

Greetings
Christoph

- Am 21. Okt 2015 um 21:07 schrieb cullmann cullm...@absint.com:

> Hi,
> 
>>> So maybe this wouldn't be such a bad move after all.
>> 
>> Agreed, we have frameworks (e.g. KIconThemes) "depending" on breeze, so it
>> makes some kind of sense to ship them together.
> yeah, beside that, if you want to create some self-contained installers,
> you need breeze (or some other full iconset), too.
> 
> Therefore it is nice if one can grab the release matching the framework 
> release
> one uses.
> 
> Greetings
> Christoph
> 
> --
> - Dr.-Ing. Christoph Cullmann -
> AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
> Science Park 1 Tel:   +49-681-38360-22
> 66123 Saarbrücken  Fax:   +49-681-38360-20
> GERMANYWWW:   http://www.AbsInt.com
> 
> Geschäftsführung: Dr.-Ing. Christian Ferdinand
> Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Ralf Habacker]

Am 21.10.2015 um 12:41 schrieb Christoph Cullmann:
>
> The last time I build umbrello with kf5 (version 5.11) dbus was required
> to run khelpcenter and open/save file dialogs and for remote control.
> http://download.opensuse.org/repositories/home:/rhabacker:/branches:/windows:/mingw:/win32:/KF511/openSUSE_13.1/noarch/mingw32-umbrello5-installer-2.18.99-4.1.noarch.rpm
> (you may open this rpm with ark of 7zip file manager to get the installer)
> open/save stuff is fixed in KF5 master
> But yes, khelpcenter (if it is shipped) might need fixing
khelpcenter is launched by klauncher5 through dbus

Ralf

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

Re: Question about goal of Windows/Mac frameworks

[Ralf Habacker]

Am 21.10.2015 um 01:19 schrieb Aleix Pol:
> On Wed, Oct 21, 2015 at 1:12 AM, Ralf Habacker  wrote:
>>> Christoph Cullmann  hat am 20. Oktober 2015 um 16:49
>>> geschrieben:
>>> That works only, if the applications bundle their ui files in resources,
>>> too, otherwise, they just won't be found
>>> and the applications break, unless you patch again Qt to look in
>>> non-standard locations.
>> yes, the following patch
>> https://build.opensuse.org/package/view_file/home:rhabacker:branches:windows:mingw:win32:Qt54/mingw32-libqt5-qtbase/qt5-qstandardpath-data-location.patch?expand=0
>> is a workaround to fix some of the issues.
> That's why Christoph is saying: "unless you patch again Qt to look in
> non-standard locations.".
umbrello for example depends on about 50 other libraries and packages
https://build.opensuse.org/project/show/home:rhabacker:branches:windows:mingw:win32:KF511.
Not patching Qt requires to repack every single package :-(, by either
hacking the cmake build system to use different install locations or to
reorder the installed files after cmake installing.

Having Qt support for "standard linux path layout" for example by
extending qt.conf to support QStandardPath (qt.conf is already required
for KDE on Windows) shortcuts this repackaging need completly.

Ralf

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

Re: [KDE/Mac] Question about goal of Windows/Mac frameworks

[Ralf Habacker]

Am 22.10.2015 um 19:24 schrieb René J.V. Bertin:
> On Thursday October 22 2015 18:48:30 Marko Käning wrote:
>
>> have you followed the discussion with Qt's developers regarding the QSP 
>> patch [1]?
>> If not, I advise you to do a little reading there!
>> Qt won’t ever support such an approach, i.e. one would have to patch it, if 
>> KDE itself doesn’t
>> come with its own provisions for this...
> Not exactly, no. The patch was rejected in the presented form, but we were 
> invited to file a bug report (I think it's 
> https://bugreports.qt.io/browse/QTBUG-44473). Here we (me, IIRC) managed to 
> make the case for special needs by MacPorts and family.
> My understanding is that the door is still open for a QSP patch that does not 
> alter the default QSP behaviour, which is exactly what my patch does (i.e. it 
> requires activation).
In the related bug I proposed to extended qt.conf support to cover
QStandardPaths too, which does also not alter the defaults (wich is the
case if qt.conf is not present)  and would be highly customizable.
(see
https://bugreports.qt.io/browse/QTBUG-44473?focusedCommentId=272971&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-272971)
Because the proposal supports environment variables too, I guess this
would also cover the OS X needs (env XDG_CONFIG_DIRS).

Ralf

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

Re: [KDE/Mac] Question about goal of Windows/Mac frameworks

[Marko Käning]

Thanks René and Jeremy,

On 22 Oct 2015, at 22:43 , Jeremy Whiting  wrote:

> ...It sounds like a good solution for embedding a copy of Qt next
> to each application for windows use (and maybe for osx use too if
> resources don't make it completely unneccessary), but not for the
> macports shared Qt case.

for clarifying this.

Greets,
Marko


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

Re: [KDE/Mac] Question about goal of Windows/Mac frameworks

[Jeremy Whiting]

Yeah, if we go that direction on mac it would be fine for bundled Qt,
but not for shared Qt. It would make all applications that use qt5-mac
or qt5-kde or whatnot use linuxy paths or not. It's a runtime switch,
so not very helpful if you've installed stuff to linuxy paths and then
let the user choose to toggle it and fail to find all the resources
needed. It sounds like a good solution for embedding a copy of Qt next
to each application for windows use (and maybe for osx use too if
resources don't make it completely unneccessary), but not for the
macports shared Qt case.

On Thu, Oct 22, 2015 at 2:37 PM, René J.V.  wrote:
> On Thursday October 22 2015 22:05:59 Marko Käning wrote:
>
>> > https://bugreports.qt.io/browse/QTBUG-44473?focusedCommentId=272971&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-272971)
>> > Because the proposal supports environment variables too, I guess this
>> > would also cover the OS X needs (env XDG_CONFIG_DIRS).
>>
>> that actually slipped my attention back then! :-|
>>
>> OK, perhaps that is a way to go then also for MacPorts?! @René?
>
> I understood from Jeremy's reply at the time that it wasn't exactly what we'd 
> need. I'm not familiar with how qt.conf is to be used, but my 1st impression 
> is that neither a per-app-bundle qt.conf nor a central, shared one would be 
> the perfect solution. The per-application approach will be much more 
> maintenance-heavy, and a central, shared file would mean that all 
> applications depending on Qt5 use either the one or the other QSP "flavour".
>
>
> R.
> ___
> 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: [KDE/Mac] Question about goal of Windows/Mac frameworks

[René J . V . Bertin]

On Thursday October 22 2015 22:05:59 Marko Käning wrote:

> > https://bugreports.qt.io/browse/QTBUG-44473?focusedCommentId=272971&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-272971)
> > Because the proposal supports environment variables too, I guess this
> > would also cover the OS X needs (env XDG_CONFIG_DIRS).
> 
> that actually slipped my attention back then! :-|
> 
> OK, perhaps that is a way to go then also for MacPorts?! @René?

I understood from Jeremy's reply at the time that it wasn't exactly what we'd 
need. I'm not familiar with how qt.conf is to be used, but my 1st impression is 
that neither a per-app-bundle qt.conf nor a central, shared one would be the 
perfect solution. The per-application approach will be much more 
maintenance-heavy, and a central, shared file would mean that all applications 
depending on Qt5 use either the one or the other QSP "flavour".


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

Re: [KDE/Mac] Question about goal of Windows/Mac frameworks

[Marko Käning]

Sorry Ralf,

On 22 Oct 2015, at 21:54 , Ralf Habacker  wrote:
> In the related bug I proposed to extended qt.conf support to cover
> QStandardPaths too, which does also not alter the defaults (wich is the
> case if qt.conf is not present)  and would be highly customizable.
> (see
> https://bugreports.qt.io/browse/QTBUG-44473?focusedCommentId=272971&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-272971)
> Because the proposal supports environment variables too, I guess this
> would also cover the OS X needs (env XDG_CONFIG_DIRS).

that actually slipped my attention back then! :-|

OK, perhaps that is a way to go then also for MacPorts?! @René?

Greets,
Marko

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

Re: [KDE/Mac] Question about goal of Windows/Mac frameworks

[Marko Käning]

Hi René,

On 22 Oct 2015, at 19:24 , René J.V. Bertin  wrote:
> Not exactly, no. The patch was rejected in the presented form, but we were 
> invited to file a bug report (I think it's 
> https://bugreports.qt.io/browse/QTBUG-44473). Here we (me, IIRC) managed to 
> make the case for special needs by MacPorts and family.
> My understanding is that the door is still open for a QSP patch that does not 
> alter the default QSP behaviour, which is exactly what my patch does (i.e. it 
> requires activation).

ok, you're right.


>> Could it be, that we have to introduce a QSP patch in MacPorts’ qt5-mac to 
>> revert back to the Linuxy way of XDG paths?
> 
> Have you forgotten I'm working on that, and that I actually created a qt5-kde 
> port so that (y)our KF5 ports could depend on a port with the required 
> patch(es) and install layout?

How could I forget that? ;-) I was merely trying to trigger the discussion!


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

Re: [KDE/Mac] Question about goal of Windows/Mac frameworks

[René J . V . Bertin]

On Thursday October 22 2015 18:48:30 Marko Käning wrote:

> have you followed the discussion with Qt's developers regarding the QSP patch 
> [1]?
> If not, I advise you to do a little reading there!
> Qt won’t ever support such an approach, i.e. one would have to patch it, if 
> KDE itself doesn’t
> come with its own provisions for this...

Not exactly, no. The patch was rejected in the presented form, but we were 
invited to file a bug report (I think it's 
https://bugreports.qt.io/browse/QTBUG-44473). Here we (me, IIRC) managed to 
make the case for special needs by MacPorts and family.
My understanding is that the door is still open for a QSP patch that does not 
alter the default QSP behaviour, which is exactly what my patch does (i.e. it 
requires activation).

> If every single KDE application wants to be self-contained - to be more 
> easily distributable -
> then that’s fine, especially for bigger apps like KMail, DigiKam, Marble, 
> KDEnlive… This would
> perhaps even make a distribution via the App Store possible. ;-)

I highly doubt that KMail could be made self-contained. Kontact *maybe*, but 
that will be one hell of a stunt to pull off, I fear.

> Could it be, that we have to introduce a QSP patch in MacPorts’ qt5-mac to 
> revert back to the
> Linuxy way of XDG paths?

Have you forgotten I'm working on that, and that I actually created a qt5-kde 
port so that (y)our KF5 ports could depend on a port with the required 
patch(es) and install layout?

My QSP patch now comes with a way to include the activation switch via qmake's 
"QT += " mechanism, or as an additional package added via cmake. I hope that 
makes it possible to include it via the ECM macro that declares the required Qt 
module without further modifications.
We'd have to patch each toplevel CMakeLists.txt, but for KDE4 we already did 
that for the documentation, so that's not a big deal.

That means that a single Qt install can provide "native" QSPs, or XDG-ish QSPs 
to binaries that include the activation module.

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

Re: Review Request 125515: Preserve relative link targets when copying symlinks.

[Stefan Brüns]

> On Oct. 22, 2015, 4:32 p.m., Frank Reininghaus wrote:
> > 4096 bytes looks reasonable. I think I would still find a fail-safe 
> > solution with a dynamically increasing buffer prettier, but it's so 
> > extremely unlikely that this will ever cause problems that it's not worth 
> > arguing about it :-)

The needed length is available from lstat(.., &stat), stat.st_size.


- Stefan


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


On Oct. 10, 2015, 3:29 p.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125515/
> ---
> 
> (Updated Oct. 10, 2015, 3:29 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Bugs: 352927
> https://bugs.kde.org/show_bug.cgi?id=352927
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> BUG: 352927
> REVIEW: 125515
> Change-Id: I7d3c988da32cae9d14750c8adb9ca5af6d140572
> 
> 
> Diffs
> -
> 
>   autotests/jobtest.h ef8c3e111ec647cc59c5a9715ab3220ce1651c9e 
>   autotests/jobtest.cpp c24bcead70f78f2bec3b938819fb2fa842e937d5 
>   src/ioslaves/file/file.cpp a0a533c957628b00eff175a949685d4497c5f095 
> 
> Diff: https://git.reviewboard.kde.org/r/125515/diff/
> 
> 
> Testing
> ---
> 
> 2 unit tests added
> 
> 
> Thanks,
> 
> David Faure
> 
>

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

Re: [KDE/Mac] Question about goal of Windows/Mac frameworks

[Marko Käning]

Hi Ralf,

On 22 Oct 2015, at 08:35 , Ralf Habacker  wrote:
> umbrello for example depends on about 50 other libraries and packages
> https://build.opensuse.org/project/show/home:rhabacker:branches:windows:mingw:win32:KF511.
> Not patching Qt requires to repack every single package :-(, by either
> hacking the cmake build system to use different install locations or to
> reorder the installed files after cmake installing.
> 
> Having Qt support for "standard linux path layout" for example by
> extending qt.conf to support QStandardPath (qt.conf is already required
> for KDE on Windows) shortcuts this repackaging need completely.


have you followed the discussion with Qt's developers regarding the QSP patch 
[1]?
If not, I advise you to do a little reading there!
Qt won’t ever support such an approach, i.e. one would have to patch it, if KDE 
itself doesn’t
come with its own provisions for this...

If every single KDE application wants to be self-contained - to be more easily 
distributable -
then that’s fine, especially for bigger apps like KMail, DigiKam, Marble, 
KDEnlive… This would
perhaps even make a distribution via the App Store possible. ;-)


However, if one wants to avoid all the duplication of libs to be shipped, then 
one better uses
a package management system like MacPorts, Homebrew, Fink on OSX and who knows 
what on Windows.


This however will require extra efforts for those systems, if KDE doesn’t 
somehow envisions such
distribution mechanisms for non-Linux distros.

Wondering where things are heading to now...


I think it’s great, that this thread(s) started a discussion about this 
pressing topic.

:-)


Could it be, that we have to introduce a QSP patch in MacPorts’ qt5-mac to 
revert back to the
Linuxy way of XDG paths?

Greets,
Marko





[1] https://codereview.qt-project.org/#/c/103277/

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

Re: Review Request 125515: Preserve relative link targets when copying symlinks.

[Frank Reininghaus]

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

Ship it!


4096 bytes looks reasonable. I think I would still find a fail-safe solution 
with a dynamically increasing buffer prettier, but it's so extremely unlikely 
that this will ever cause problems that it's not worth arguing about it :-)

- Frank Reininghaus


On Okt. 10, 2015, 3:29 nachm., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125515/
> ---
> 
> (Updated Okt. 10, 2015, 3:29 nachm.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Bugs: 352927
> https://bugs.kde.org/show_bug.cgi?id=352927
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> BUG: 352927
> REVIEW: 125515
> Change-Id: I7d3c988da32cae9d14750c8adb9ca5af6d140572
> 
> 
> Diffs
> -
> 
>   autotests/jobtest.h ef8c3e111ec647cc59c5a9715ab3220ce1651c9e 
>   autotests/jobtest.cpp c24bcead70f78f2bec3b938819fb2fa842e937d5 
>   src/ioslaves/file/file.cpp a0a533c957628b00eff175a949685d4497c5f095 
> 
> Diff: https://git.reviewboard.kde.org/r/125515/diff/
> 
> 
> Testing
> ---
> 
> 2 unit tests added
> 
> 
> 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 125756: Initialize QFunctionPointer to Q_NULLPTR

[Nicolás Alvarez]

> On Oct. 22, 2015, 9:09 a.m., Martin Gräßlin wrote:
> > src/declarativeimports/core/windowthumbnail.h, lines 128-129
> > 
> >
> > AFAIK we are not yet allowed to use nullptr in frameworks. You need to 
> > use Q_NULLPTR which gets turned into nullptr if available in the compiler 
> > settings.
> > 
> > Also I think header initialization is not yet allowed, so please move 
> > to cpp file.
> > 
> > Meh, I want full C++11 on Linux only code.

Whenever you use `Q_NULLPTR`, please check that the code compiles with either 
`nullptr` or `0`. I have seen code using `Q_NULLPTR` that didn't actually 
compile if it was defined to `0` due to the compiler lacking `nullptr` support.


- Nicolás


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


On Oct. 22, 2015, 10:27 a.m., Dāvis Mosāns wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125756/
> ---
> 
> (Updated Oct. 22, 2015, 10:27 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Need to initialize QFunctionPointer to Q_NULLPTR because otherwise it's used 
> unitialized
> causing m_eglCreateImageKHR check to pass and crashing plasmashell because of 
> invalid call.
> Look at xcbWindowToTextureEGL function in 
> src/declarativeimports/core/windowthumbnail.cpp
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.cpp 
> 5a5274e1eacdb9b91ff500e1ebf9046930891ecf 
> 
> Diff: https://git.reviewboard.kde.org/r/125756/diff/
> 
> 
> Testing
> ---
> 
> Verified that plasmashell doesn't crash anymore.
> 
> 
> Thanks,
> 
> Dāvis Mosāns
> 
>

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

Jenkins-kde-ci: kcoreaddons master stable-kf5-qt5 » Linux,gcc - Build # 64 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kcoreaddons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/64/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 22 Oct 2015 15:40:49 +
Build duration: 3 min 59 sec

CHANGE SET
Revision b5f30bb0af0d0ef58736c25773cc4fa443950d2b by arichardson.kde: (Fix 
parsing escaped values after commit 32e48f)
  change: edit src/lib/plugin/desktopfileparser.cpp


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 21 test(s), Skipped: 0 test(s), Total: 
21 test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 10/10 (100%)FILES 74/88 (84%)CLASSES 74/88 (84%)LINE 5466/7606 
(72%)CONDITIONAL 11590/21521 (54%)

By packages
  
autotests
FILES 31/38 (82%)CLASSES 31/38 (82%)LINE 2327/2431 
(96%)CONDITIONAL 6932/13715 (51%)
src.desktoptojson
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 84/106 (79%)CONDITIONAL 
214/417 (51%)
src.lib
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 221/467 (47%)CONDITIONAL 
159/297 (54%)
src.lib.caching
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 352/764 (46%)CONDITIONAL 
202/384 (53%)
src.lib.io
FILES 9/10 (90%)CLASSES 9/10 (90%)LINE 740/1226 
(60%)CONDITIONAL 894/1466 (61%)
src.lib.jobs
FILES 5/7 (71%)CLASSES 5/7 (71%)LINE 157/305 (51%)CONDITIONAL 
57/96 (59%)
src.lib.plugin
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 614/708 (87%)CONDITIONAL 
1171/2005 (58%)
src.lib.randomness
FILES 1/2 (50%)CLASSES 1/2 (50%)LINE 21/98 (21%)CONDITIONAL 
22/36 (61%)
src.lib.text
FILES 5/8 (63%)CLASSES 5/8 (63%)LINE 312/729 (43%)CONDITIONAL 
1094/1755 (62%)
src.lib.util
FILES 10/10 (100%)CLASSES 10/10 (100%)LINE 638/772 
(83%)CONDITIONAL 845/1350 (63%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kcoreaddons master stable-kf5-qt5 » Linux,gcc - Build # 64 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kcoreaddons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/64/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 22 Oct 2015 15:40:49 +
Build duration: 3 min 59 sec

CHANGE SET
Revision b5f30bb0af0d0ef58736c25773cc4fa443950d2b by arichardson.kde: (Fix 
parsing escaped values after commit 32e48f)
  change: edit src/lib/plugin/desktopfileparser.cpp


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 21 test(s), Skipped: 0 test(s), Total: 
21 test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 10/10 (100%)FILES 74/88 (84%)CLASSES 74/88 (84%)LINE 5466/7606 
(72%)CONDITIONAL 11590/21521 (54%)

By packages
  
autotests
FILES 31/38 (82%)CLASSES 31/38 (82%)LINE 2327/2431 
(96%)CONDITIONAL 6932/13715 (51%)
src.desktoptojson
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 84/106 (79%)CONDITIONAL 
214/417 (51%)
src.lib
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 221/467 (47%)CONDITIONAL 
159/297 (54%)
src.lib.caching
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 352/764 (46%)CONDITIONAL 
202/384 (53%)
src.lib.io
FILES 9/10 (90%)CLASSES 9/10 (90%)LINE 740/1226 
(60%)CONDITIONAL 894/1466 (61%)
src.lib.jobs
FILES 5/7 (71%)CLASSES 5/7 (71%)LINE 157/305 (51%)CONDITIONAL 
57/96 (59%)
src.lib.plugin
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 614/708 (87%)CONDITIONAL 
1171/2005 (58%)
src.lib.randomness
FILES 1/2 (50%)CLASSES 1/2 (50%)LINE 21/98 (21%)CONDITIONAL 
22/36 (61%)
src.lib.text
FILES 5/8 (63%)CLASSES 5/8 (63%)LINE 312/729 (43%)CONDITIONAL 
1094/1755 (62%)
src.lib.util
FILES 10/10 (100%)CLASSES 10/10 (100%)LINE 638/772 
(83%)CONDITIONAL 845/1350 (63%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kcoreaddons master kf5-qt5 » Linux,gcc - Build # 68 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kcoreaddons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/68/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 22 Oct 2015 15:40:49 +
Build duration: 1 min 57 sec

CHANGE SET
Revision b5f30bb0af0d0ef58736c25773cc4fa443950d2b by arichardson.kde: (Fix 
parsing escaped values after commit 32e48f)
  change: edit src/lib/plugin/desktopfileparser.cpp


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 21 test(s), Skipped: 0 test(s), Total: 
21 test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 10/10 (100%)FILES 74/88 (84%)CLASSES 74/88 (84%)LINE 5466/7608 
(72%)CONDITIONAL 11139/20621 (54%)

By packages
  
autotests
FILES 31/38 (82%)CLASSES 31/38 (82%)LINE 2327/2431 
(96%)CONDITIONAL 6702/13255 (51%)
src.desktoptojson
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 84/108 (78%)CONDITIONAL 
195/380 (51%)
src.lib
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 221/467 (47%)CONDITIONAL 
108/195 (55%)
src.lib.caching
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 352/764 (46%)CONDITIONAL 
200/380 (53%)
src.lib.io
FILES 9/10 (90%)CLASSES 9/10 (90%)LINE 740/1226 
(60%)CONDITIONAL 865/1408 (61%)
src.lib.jobs
FILES 5/7 (71%)CLASSES 5/7 (71%)LINE 157/305 (51%)CONDITIONAL 
57/96 (59%)
src.lib.plugin
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 614/708 (87%)CONDITIONAL 
1118/1900 (59%)
src.lib.randomness
FILES 1/2 (50%)CLASSES 1/2 (50%)LINE 21/98 (21%)CONDITIONAL 
20/32 (63%)
src.lib.text
FILES 5/8 (63%)CLASSES 5/8 (63%)LINE 312/729 (43%)CONDITIONAL 
1060/1687 (63%)
src.lib.util
FILES 10/10 (100%)CLASSES 10/10 (100%)LINE 638/772 
(83%)CONDITIONAL 814/1288 (63%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kcoreaddons master kf5-qt5 » Linux,gcc - Build # 68 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kcoreaddons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/68/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 22 Oct 2015 15:40:49 +
Build duration: 1 min 57 sec

CHANGE SET
Revision b5f30bb0af0d0ef58736c25773cc4fa443950d2b by arichardson.kde: (Fix 
parsing escaped values after commit 32e48f)
  change: edit src/lib/plugin/desktopfileparser.cpp


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 21 test(s), Skipped: 0 test(s), Total: 
21 test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 10/10 (100%)FILES 74/88 (84%)CLASSES 74/88 (84%)LINE 5466/7608 
(72%)CONDITIONAL 11139/20621 (54%)

By packages
  
autotests
FILES 31/38 (82%)CLASSES 31/38 (82%)LINE 2327/2431 
(96%)CONDITIONAL 6702/13255 (51%)
src.desktoptojson
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 84/108 (78%)CONDITIONAL 
195/380 (51%)
src.lib
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 221/467 (47%)CONDITIONAL 
108/195 (55%)
src.lib.caching
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 352/764 (46%)CONDITIONAL 
200/380 (53%)
src.lib.io
FILES 9/10 (90%)CLASSES 9/10 (90%)LINE 740/1226 
(60%)CONDITIONAL 865/1408 (61%)
src.lib.jobs
FILES 5/7 (71%)CLASSES 5/7 (71%)LINE 157/305 (51%)CONDITIONAL 
57/96 (59%)
src.lib.plugin
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 614/708 (87%)CONDITIONAL 
1118/1900 (59%)
src.lib.randomness
FILES 1/2 (50%)CLASSES 1/2 (50%)LINE 21/98 (21%)CONDITIONAL 
20/32 (63%)
src.lib.text
FILES 5/8 (63%)CLASSES 5/8 (63%)LINE 312/729 (43%)CONDITIONAL 
1060/1687 (63%)
src.lib.util
FILES 10/10 (100%)CLASSES 10/10 (100%)LINE 638/772 
(83%)CONDITIONAL 814/1288 (63%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Boudewijn Rempt]

On Thu, 22 Oct 2015, Christoph Cullmann wrote:


If such an approach seems reasonable, we could have some helper for this in a 
framework.
Perhaps the "breeze" framework could even just provide such an rcc and a little 
lib to
load it that can be used for people creating bundles/installers.


Yes, I think it's quite reasonable. Once put into an rcc, the theme doesn't even take a 
lot space anymore. I got so many complaints about the number of files in krita's windows

installer -- because of all the icons in the theme I bundled. This is much 
nicer.

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

Re: Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

> On Thu, 22 Oct 2015, Christoph Cullmann wrote:
> 
>> Hi,
>>
>>> Impressive! And cool to see another project using the cmake externals
>>> approach, I can copy a lot of it for Krita 3, I think. How are you
>>> handling icons? Bundling the breeze theme, or putting the icons in resource
>>> files?
>> as I was lazy, I just compiled complete breeze into a binary rcc file like 
>> done
>> in mac.txt: (search for the rcc calls)
>>
>> https://quickgit.kde.org/?p=kate.git&a=blob&h=275a28d36b132f0f5d3963ae40b451d264bae3a5&hb=1486c0e69df54e955e25223ff9d99d87751d2ba3&f=mac.txt
> 
> Ah, interesting... Yesterday, I did something similar, a little helper that
> copies the breeze icons that are in a list and puts them in a qrc file :-)
I just use the rcc -project option for that, to pack all files in the current 
dir ;=)

> 
>>
>> Kate and KWrite call then this helper function after the initial QApplication
>> construction:
>>
>> https://quickgit.kde.org/?p=kate.git&a=blob&h=75b9d81be88aac55a689ca99adc9a5e0ae0bb1d3&hb=1486c0e69df54e955e25223ff9d99d87751d2ba3&f=icons.h
>>
>> The nice thing: that helper is always compiled in, that means you can test it
>> with a normal compiled Kate/KWrite.
>>
>> This for sure can be tuned to just pack the right breeze icons in that you 
>> need,
>> but ATM even breeze lacks some icons
>> we use in KWrite/Kate/KTextEditor (or perhaps even some other frameworks).
>>
>> All in all, the Mac and Windows port need no magic defines ATM, at least 
>> none I
>> am aware off,
>> and no non-native magic (if you ignore that we use cmake/python/perl for some
>> stuff).
> 
> Very, very nice!
And very simple ;=) And without ugly "BUNDLE_MODE_HACK" defines.

If such an approach seems reasonable, we could have some helper for this in a 
framework.
Perhaps the "breeze" framework could even just provide such an rcc and a little 
lib to
load it that can be used for people creating bundles/installers.

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Boudewijn Rempt]

On Thu, 22 Oct 2015, Christoph Cullmann wrote:


Hi,


Impressive! And cool to see another project using the cmake externals
approach, I can copy a lot of it for Krita 3, I think. How are you
handling icons? Bundling the breeze theme, or putting the icons in resource
files?

as I was lazy, I just compiled complete breeze into a binary rcc file like done 
in mac.txt: (search for the rcc calls)

https://quickgit.kde.org/?p=kate.git&a=blob&h=275a28d36b132f0f5d3963ae40b451d264bae3a5&hb=1486c0e69df54e955e25223ff9d99d87751d2ba3&f=mac.txt


Ah, interesting... Yesterday, I did something similar, a little helper that 
copies the breeze icons that are in a list and puts them in a qrc file :-)



Kate and KWrite call then this helper function after the initial QApplication 
construction:

https://quickgit.kde.org/?p=kate.git&a=blob&h=75b9d81be88aac55a689ca99adc9a5e0ae0bb1d3&hb=1486c0e69df54e955e25223ff9d99d87751d2ba3&f=icons.h

The nice thing: that helper is always compiled in, that means you can test it 
with a normal compiled Kate/KWrite.

This for sure can be tuned to just pack the right breeze icons in that you 
need, but ATM even breeze lacks some icons
we use in KWrite/Kate/KTextEditor (or perhaps even some other frameworks).

All in all, the Mac and Windows port need no magic defines ATM, at least none I 
am aware off,
and no non-native magic (if you ignore that we use cmake/python/perl for some 
stuff).


Very, very nice!

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

Re: Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

> Impressive! And cool to see another project using the cmake externals
> approach, I can copy a lot of it for Krita 3, I think. How are you
> handling icons? Bundling the breeze theme, or putting the icons in resource
> files?
as I was lazy, I just compiled complete breeze into a binary rcc file like done 
in mac.txt: (search for the rcc calls)

https://quickgit.kde.org/?p=kate.git&a=blob&h=275a28d36b132f0f5d3963ae40b451d264bae3a5&hb=1486c0e69df54e955e25223ff9d99d87751d2ba3&f=mac.txt

Kate and KWrite call then this helper function after the initial QApplication 
construction:

https://quickgit.kde.org/?p=kate.git&a=blob&h=75b9d81be88aac55a689ca99adc9a5e0ae0bb1d3&hb=1486c0e69df54e955e25223ff9d99d87751d2ba3&f=icons.h

The nice thing: that helper is always compiled in, that means you can test it 
with a normal compiled Kate/KWrite.

This for sure can be tuned to just pack the right breeze icons in that you 
need, but ATM even breeze lacks some icons
we use in KWrite/Kate/KTextEditor (or perhaps even some other frameworks).

All in all, the Mac and Windows port need no magic defines ATM, at least none I 
am aware off,
and no non-native magic (if you ignore that we use cmake/python/perl for some 
stuff).

Greetings
Christoph

> 
> --
> Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
> 
> On Thu, 22 Oct 2015, Christoph Cullmann wrote:
> 
>> Hi,
>>
>> btw., a preliminary self contained Kate for Windows can be found here:
>>
>> ftp://cullmann.io/cullmann/
>>
>> Created with the CMake file from this repo by Kåre Särs
>>
>> https://quickgit.kde.org/?p=scratch%2Fsars%2Fkate-windows.git&a=tree
>>
>> Plain Qt, normal Visual Studio, can be deployed without global stuff.
>> (you need the Visual Studio redist package, thought, or you bundle that .dll
>> in the zip, too)
>>
>> ZIP is only around 30MB, I think that is not that bad, no real need to spend
>> time on sharing stuff.
>>
>> Greetings
>> Christoph
>>
>> - Am 22. Okt 2015 um 8:39 schrieb cullmann cullm...@absint.com:
>>
>>> Hi,
>>> 
 Am 21.10.2015 um 01:19 schrieb Aleix Pol:
> On Wed, Oct 21, 2015 at 1:12 AM, Ralf Habacker  wrote:
>>> Christoph Cullmann  hat am 20. Oktober 2015 um 
>>> 16:49
>>> geschrieben:
>>> That works only, if the applications bundle their ui files in resources,
>>> too, otherwise, they just won't be found
>>> and the applications break, unless you patch again Qt to look in
>>> non-standard locations.
>> yes, the following patch
>> https://build.opensuse.org/package/view_file/home:rhabacker:branches:windows:mingw:win32:Qt54/mingw32-libqt5-qtbase/qt5-qstandardpath-data-location.patch?expand=0
>> is a workaround to fix some of the issues.
> That's why Christoph is saying: "unless you patch again Qt to look in
> non-standard locations.".
 umbrello for example depends on about 50 other libraries and packages
 https://build.opensuse.org/project/show/home:rhabacker:branches:windows:mingw:win32:KF511.
 Not patching Qt requires to repack every single package :-(, by either
 hacking the cmake build system to use different install locations or to
 reorder the installed files after cmake installing.
 
 Having Qt support for "standard linux path layout" for example by
 extending qt.conf to support QStandardPath (qt.conf is already required
 for KDE on Windows) shortcuts this repackaging need completly.
>>> I at least fixed already all frameworks required by the current Kate build
>>> (beside that KIO slave don't work atm and I guess
>>> I missed 1-2 files still not in resources):
>>> 
>>> kconfig
>>> kguiaddons
>>> ki18n
>>> kitemviews
>>> sonnet
>>> kwindowsystem
>>> kwidgetsaddons
>>> kcompletion
>>> kdbusaddons
>>> karchive
>>> kcoreaddons
>>> kjobwidgets
>>> kcrash
>>> kservice
>>> kcodecs
>>> kauth
>>> kconfigwidgets
>>> kiconthemes
>>> ktextwidgets
>>> kglobalaccel
>>> kxmlgui
>>> kbookmarks
>>> solid
>>> kio
>>> kparts
>>> ktexteditor
>>> 
>>> That means they now by "default" just work, if you use the master branch.
>>> More frameworks to go, for sure, but that is really doable ;=)
>>> 
>>> Greetings
>>> Christoph
>>> 
>>> --
>>> - Dr.-Ing. Christoph Cullmann -
>>> AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
>>> Science Park 1 Tel:   +49-681-38360-22
>>> 66123 Saarbrücken  Fax:   +49-681-38360-20
>>> GERMANYWWW:   http://www.AbsInt.com
>>> 
>>> Geschäftsführung: Dr.-Ing. Christian Ferdinand
>>> Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
>>> ___
>>> Kde-frameworks-devel mailing list
>>> Kde-frameworks-devel@kde.org
>>> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>>
>> --
>> - Dr.-Ing. Christoph Cullmann -
>> AbsInt 

Jenkins-kde-ci: kcoreaddons master stable-kf5-qt5 » Linux,gcc - Build # 63 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kcoreaddons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/63/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 22 Oct 2015 13:35:39 +
Build duration: 3 min 56 sec

CHANGE SET
Revision 47c5bfdb269663836f07aa794385db505b0f7ca5 by aleixpol: (Use correct 
escaping character)
  change: edit src/lib/plugin/desktopfileparser.cpp


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 20 test(s), Skipped: 0 test(s), Total: 
21 test(s)Failed: TestSuite.desktoptojsontest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 10/10 (100%)FILES 74/88 (84%)CLASSES 74/88 (84%)LINE 5466/7605 
(72%)CONDITIONAL 11601/21517 (54%)

By packages
  
autotests
FILES 31/38 (82%)CLASSES 31/38 (82%)LINE 2328/2431 
(96%)CONDITIONAL 6945/13715 (51%)
src.desktoptojson
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 84/106 (79%)CONDITIONAL 
214/417 (51%)
src.lib
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 221/467 (47%)CONDITIONAL 
159/297 (54%)
src.lib.caching
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 352/764 (46%)CONDITIONAL 
202/384 (53%)
src.lib.io
FILES 9/10 (90%)CLASSES 9/10 (90%)LINE 740/1226 
(60%)CONDITIONAL 894/1466 (61%)
src.lib.jobs
FILES 5/7 (71%)CLASSES 5/7 (71%)LINE 157/305 (51%)CONDITIONAL 
57/96 (59%)
src.lib.plugin
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 613/707 (87%)CONDITIONAL 
1169/2001 (58%)
src.lib.randomness
FILES 1/2 (50%)CLASSES 1/2 (50%)LINE 21/98 (21%)CONDITIONAL 
22/36 (61%)
src.lib.text
FILES 5/8 (63%)CLASSES 5/8 (63%)LINE 312/729 (43%)CONDITIONAL 
1094/1755 (62%)
src.lib.util
FILES 10/10 (100%)CLASSES 10/10 (100%)LINE 638/772 
(83%)CONDITIONAL 845/1350 (63%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kcoreaddons master kf5-qt5 » Linux,gcc - Build # 67 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kcoreaddons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/67/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 22 Oct 2015 13:35:39 +
Build duration: 2 min 36 sec

CHANGE SET
Revision 47c5bfdb269663836f07aa794385db505b0f7ca5 by aleixpol: (Use correct 
escaping character)
  change: edit src/lib/plugin/desktopfileparser.cpp


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 20 test(s), Skipped: 0 test(s), Total: 
21 test(s)Failed: TestSuite.desktoptojsontest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 10/10 (100%)FILES 74/88 (84%)CLASSES 74/88 (84%)LINE 5466/7607 
(72%)CONDITIONAL 11150/20617 (54%)

By packages
  
autotests
FILES 31/38 (82%)CLASSES 31/38 (82%)LINE 2328/2431 
(96%)CONDITIONAL 6715/13255 (51%)
src.desktoptojson
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 84/108 (78%)CONDITIONAL 
195/380 (51%)
src.lib
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 221/467 (47%)CONDITIONAL 
108/195 (55%)
src.lib.caching
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 352/764 (46%)CONDITIONAL 
200/380 (53%)
src.lib.io
FILES 9/10 (90%)CLASSES 9/10 (90%)LINE 740/1226 
(60%)CONDITIONAL 865/1408 (61%)
src.lib.jobs
FILES 5/7 (71%)CLASSES 5/7 (71%)LINE 157/305 (51%)CONDITIONAL 
57/96 (59%)
src.lib.plugin
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 613/707 (87%)CONDITIONAL 
1116/1896 (59%)
src.lib.randomness
FILES 1/2 (50%)CLASSES 1/2 (50%)LINE 21/98 (21%)CONDITIONAL 
20/32 (63%)
src.lib.text
FILES 5/8 (63%)CLASSES 5/8 (63%)LINE 312/729 (43%)CONDITIONAL 
1060/1687 (63%)
src.lib.util
FILES 10/10 (100%)CLASSES 10/10 (100%)LINE 638/772 
(83%)CONDITIONAL 814/1288 (63%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Boudewijn Rempt]

Impressive! And cool to see another project using the cmake externals 
approach, I can copy a lot of it for Krita 3, I think. How are you 
handling icons? Bundling the breeze theme, or putting the icons in resource

files?

--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

On Thu, 22 Oct 2015, Christoph Cullmann wrote:


Hi,

btw., a preliminary self contained Kate for Windows can be found here:

ftp://cullmann.io/cullmann/

Created with the CMake file from this repo by Kåre Särs

https://quickgit.kde.org/?p=scratch%2Fsars%2Fkate-windows.git&a=tree

Plain Qt, normal Visual Studio, can be deployed without global stuff.
(you need the Visual Studio redist package, thought, or you bundle that .dll
in the zip, too)

ZIP is only around 30MB, I think that is not that bad, no real need to spend
time on sharing stuff.

Greetings
Christoph

- Am 22. Okt 2015 um 8:39 schrieb cullmann cullm...@absint.com:


Hi,


Am 21.10.2015 um 01:19 schrieb Aleix Pol:

On Wed, Oct 21, 2015 at 1:12 AM, Ralf Habacker  wrote:

Christoph Cullmann  hat am 20. Oktober 2015 um 16:49
geschrieben:
That works only, if the applications bundle their ui files in resources,
too, otherwise, they just won't be found
and the applications break, unless you patch again Qt to look in
non-standard locations.

yes, the following patch
https://build.opensuse.org/package/view_file/home:rhabacker:branches:windows:mingw:win32:Qt54/mingw32-libqt5-qtbase/qt5-qstandardpath-data-location.patch?expand=0
is a workaround to fix some of the issues.

That's why Christoph is saying: "unless you patch again Qt to look in
non-standard locations.".

umbrello for example depends on about 50 other libraries and packages
https://build.opensuse.org/project/show/home:rhabacker:branches:windows:mingw:win32:KF511.
Not patching Qt requires to repack every single package :-(, by either
hacking the cmake build system to use different install locations or to
reorder the installed files after cmake installing.

Having Qt support for "standard linux path layout" for example by
extending qt.conf to support QStandardPath (qt.conf is already required
for KDE on Windows) shortcuts this repackaging need completly.

I at least fixed already all frameworks required by the current Kate build
(beside that KIO slave don't work atm and I guess
I missed 1-2 files still not in resources):

kconfig
kguiaddons
ki18n
kitemviews
sonnet
kwindowsystem
kwidgetsaddons
kcompletion
kdbusaddons
karchive
kcoreaddons
kjobwidgets
kcrash
kservice
kcodecs
kauth
kconfigwidgets
kiconthemes
ktextwidgets
kglobalaccel
kxmlgui
kbookmarks
solid
kio
kparts
ktexteditor

That means they now by "default" just work, if you use the master branch.
More frameworks to go, for sure, but that is really doable ;=)

Greetings
Christoph

--
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


--
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-windows mailing list
kde-wind...@kde.org
https://mail.kde.org/mailman/listinfo/kde-windows___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125750: Reduce some allocations

[Alex Richardson]

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

Ship it!


There's probably a way of avoinding the allocation and only iterating over the 
line once but it's a big improvement like this anyway.
Iterating over a few more bytes that are already in the cache shouldn't be 
noticable, whereas saving one call to malloc() per .desktop file line is a big 
improvement.
Also calling contains() it makes the code a lot easier to understand and 
maintain.

I don't really know the details of how plasma plugins are handled but for 
normal shared libraries using .json instead of .desktop is the way to go.
That's why there's the transitional comment in the source.
If plasma plugins have metadata.desktop files, using metadata.json instead 
should (hopefully) just work.
However, I haven't looked into the plasma code so I can't be certain.


src/lib/plugin/desktopfileparser.cpp (line 97)


This should be '\'

Looks I didn't test escaped values if the tests still pass...


- Alex Richardson


On Oct. 22, 2015, 2:20 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125750/
> ---
> 
> (Updated Oct. 22, 2015, 2:20 p.m.)
> 
> 
> Review request for KDE Frameworks and Sebastian Kügler.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> I know this could be done so much better and there's a comment saying it's 
> transitional (heh), but this happens to be called a ton of times on every 
> plasma boot through [1].
> Actually, why is it transitional? Are we supposed to move from 
> metadata.desktop to metadata.json? Or is it because we should all be using 
> `kpackagetool5 --generate-index`?
> 
> [1] KPluginMetaData::loadFromDesktopFile(QString const&, QStringList const&)
> 
> 
> Diffs
> -
> 
>   src/lib/plugin/desktopfileparser.cpp 7a4556a 
> 
> Diff: https://git.reviewboard.kde.org/r/125750/diff/
> 
> 
> Testing
> ---
> 
> Tests pass, plasma still boots.
> 
> 
> 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 125756: Initialize QFunctionPointer to Q_NULLPTR

[Dāvis Mosāns]

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

(Updated Oct. 22, 2015, 1:27 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Plasma.


Changes
---

Submitted with commit 39f8db95c2dd227cf46eccb22b5b3860224894a6 by D?vis Mos?ns 
to branch master.


Repository: plasma-framework


Description
---

Need to initialize QFunctionPointer to Q_NULLPTR because otherwise it's used 
unitialized
causing m_eglCreateImageKHR check to pass and crashing plasmashell because of 
invalid call.
Look at xcbWindowToTextureEGL function in 
src/declarativeimports/core/windowthumbnail.cpp


Diffs
-

  src/declarativeimports/core/windowthumbnail.cpp 
5a5274e1eacdb9b91ff500e1ebf9046930891ecf 

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


Testing
---

Verified that plasmashell doesn't crash anymore.


Thanks,

Dāvis Mosāns

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

Jenkins-kde-ci: kcoreaddons master stable-kf5-qt5 » Linux,gcc - Build # 62 - Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kcoreaddons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/62/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 22 Oct 2015 13:21:09 +
Build duration: 4 min 38 sec

CHANGE SET
Revision 32e48f1911103537645c77d50ea3ddc192b0befe by aleixpol: (Reduce some 
allocations)
  change: edit src/lib/plugin/desktopfileparser.cpp
Revision 30118e319e2446417f57266a212d1c4e45681546 by aleixpol: (--warning)
  change: edit src/lib/plugin/desktopfileparser.cpp


JUNIT RESULTS

Name: (root) Failed: 2 test(s), Passed: 19 test(s), Skipped: 0 test(s), Total: 
21 test(s)Failed: TestSuite.desktoptojsontestFailed: 
TestSuite.kpluginmetadatatest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 10/10 (100%)FILES 74/88 (84%)CLASSES 74/88 (84%)LINE 5421/7605 
(71%)CONDITIONAL 11443/21208 (54%)

By packages
  
autotests
FILES 31/38 (82%)CLASSES 31/38 (82%)LINE 2305/2431 
(95%)CONDITIONAL 6816/13457 (51%)
src.desktoptojson
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 84/106 (79%)CONDITIONAL 
214/417 (51%)
src.lib
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 221/467 (47%)CONDITIONAL 
159/297 (54%)
src.lib.caching
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 352/764 (46%)CONDITIONAL 
202/384 (53%)
src.lib.io
FILES 9/10 (90%)CLASSES 9/10 (90%)LINE 740/1226 
(60%)CONDITIONAL 894/1466 (61%)
src.lib.jobs
FILES 5/7 (71%)CLASSES 5/7 (71%)LINE 157/305 (51%)CONDITIONAL 
57/96 (59%)
src.lib.plugin
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 591/707 (84%)CONDITIONAL 
1140/1950 (58%)
src.lib.randomness
FILES 1/2 (50%)CLASSES 1/2 (50%)LINE 21/98 (21%)CONDITIONAL 
22/36 (61%)
src.lib.text
FILES 5/8 (63%)CLASSES 5/8 (63%)LINE 312/729 (43%)CONDITIONAL 
1094/1755 (62%)
src.lib.util
FILES 10/10 (100%)CLASSES 10/10 (100%)LINE 638/772 
(83%)CONDITIONAL 845/1350 (63%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kcoreaddons master kf5-qt5 » Linux,gcc - Build # 66 - Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kcoreaddons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/66/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 22 Oct 2015 13:21:09 +
Build duration: 2 min 21 sec

CHANGE SET
Revision 32e48f1911103537645c77d50ea3ddc192b0befe by aleixpol: (Reduce some 
allocations)
  change: edit src/lib/plugin/desktopfileparser.cpp
Revision 30118e319e2446417f57266a212d1c4e45681546 by aleixpol: (--warning)
  change: edit src/lib/plugin/desktopfileparser.cpp


JUNIT RESULTS

Name: (root) Failed: 2 test(s), Passed: 19 test(s), Skipped: 0 test(s), Total: 
21 test(s)Failed: TestSuite.desktoptojsontestFailed: 
TestSuite.kpluginmetadatatest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 10/10 (100%)FILES 74/88 (84%)CLASSES 74/88 (84%)LINE 5421/7607 
(71%)CONDITIONAL 10997/20318 (54%)

By packages
  
autotests
FILES 31/38 (82%)CLASSES 31/38 (82%)LINE 2305/2431 
(95%)CONDITIONAL 6591/13007 (51%)
src.desktoptojson
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 84/108 (78%)CONDITIONAL 
195/380 (51%)
src.lib
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 221/467 (47%)CONDITIONAL 
108/195 (55%)
src.lib.caching
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 352/764 (46%)CONDITIONAL 
200/380 (53%)
src.lib.io
FILES 9/10 (90%)CLASSES 9/10 (90%)LINE 740/1226 
(60%)CONDITIONAL 865/1408 (61%)
src.lib.jobs
FILES 5/7 (71%)CLASSES 5/7 (71%)LINE 157/305 (51%)CONDITIONAL 
57/96 (59%)
src.lib.plugin
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 591/707 (84%)CONDITIONAL 
1087/1845 (59%)
src.lib.randomness
FILES 1/2 (50%)CLASSES 1/2 (50%)LINE 21/98 (21%)CONDITIONAL 
20/32 (63%)
src.lib.text
FILES 5/8 (63%)CLASSES 5/8 (63%)LINE 312/729 (43%)CONDITIONAL 
1060/1687 (63%)
src.lib.util
FILES 10/10 (100%)CLASSES 10/10 (100%)LINE 638/772 
(83%)CONDITIONAL 814/1288 (63%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

btw., a preliminary self contained Kate for Windows can be found here:

ftp://cullmann.io/cullmann/

Created with the CMake file from this repo by Kåre Särs

https://quickgit.kde.org/?p=scratch%2Fsars%2Fkate-windows.git&a=tree

Plain Qt, normal Visual Studio, can be deployed without global stuff.
(you need the Visual Studio redist package, thought, or you bundle that .dll
in the zip, too)

ZIP is only around 30MB, I think that is not that bad, no real need to spend
time on sharing stuff.

Greetings
Christoph

- Am 22. Okt 2015 um 8:39 schrieb cullmann cullm...@absint.com:

> Hi,
> 
>> Am 21.10.2015 um 01:19 schrieb Aleix Pol:
>>> On Wed, Oct 21, 2015 at 1:12 AM, Ralf Habacker  wrote:
> Christoph Cullmann  hat am 20. Oktober 2015 um 16:49
> geschrieben:
> That works only, if the applications bundle their ui files in resources,
> too, otherwise, they just won't be found
> and the applications break, unless you patch again Qt to look in
> non-standard locations.
 yes, the following patch
 https://build.opensuse.org/package/view_file/home:rhabacker:branches:windows:mingw:win32:Qt54/mingw32-libqt5-qtbase/qt5-qstandardpath-data-location.patch?expand=0
 is a workaround to fix some of the issues.
>>> That's why Christoph is saying: "unless you patch again Qt to look in
>>> non-standard locations.".
>> umbrello for example depends on about 50 other libraries and packages
>> https://build.opensuse.org/project/show/home:rhabacker:branches:windows:mingw:win32:KF511.
>> Not patching Qt requires to repack every single package :-(, by either
>> hacking the cmake build system to use different install locations or to
>> reorder the installed files after cmake installing.
>> 
>> Having Qt support for "standard linux path layout" for example by
>> extending qt.conf to support QStandardPath (qt.conf is already required
>> for KDE on Windows) shortcuts this repackaging need completly.
> I at least fixed already all frameworks required by the current Kate build
> (beside that KIO slave don't work atm and I guess
> I missed 1-2 files still not in resources):
> 
> kconfig
> kguiaddons
> ki18n
> kitemviews
> sonnet
> kwindowsystem
> kwidgetsaddons
> kcompletion
> kdbusaddons
> karchive
> kcoreaddons
> kjobwidgets
> kcrash
> kservice
> kcodecs
> kauth
> kconfigwidgets
> kiconthemes
> ktextwidgets
> kglobalaccel
> kxmlgui
> kbookmarks
> solid
> kio
> kparts
> ktexteditor
> 
> That means they now by "default" just work, if you use the master branch.
> More frameworks to go, for sure, but that is really doable ;=)
> 
> Greetings
> Christoph
> 
> --
> - Dr.-Ing. Christoph Cullmann -
> AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
> Science Park 1 Tel:   +49-681-38360-22
> 66123 Saarbrücken  Fax:   +49-681-38360-20
> GERMANYWWW:   http://www.AbsInt.com
> 
> Geschäftsführung: Dr.-Ing. Christian Ferdinand
> Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125750: Reduce some allocations

[Aleix Pol Gonzalez]

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

(Updated Oct. 22, 2015, 1:20 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Sebastian Kügler.


Changes
---

Submitted with commit 32e48f1911103537645c77d50ea3ddc192b0befe by Aleix Pol to 
branch master.


Repository: kcoreaddons


Description
---

I know this could be done so much better and there's a comment saying it's 
transitional (heh), but this happens to be called a ton of times on every 
plasma boot through [1].
Actually, why is it transitional? Are we supposed to move from metadata.desktop 
to metadata.json? Or is it because we should all be using `kpackagetool5 
--generate-index`?

[1] KPluginMetaData::loadFromDesktopFile(QString const&, QStringList const&)


Diffs
-

  src/lib/plugin/desktopfileparser.cpp 7a4556a 

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


Testing
---

Tests pass, plasma still boots.


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 125756: Initialize QFunctionPointer to Q_NULLPTR

[Martin Gräßlin]

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

Ship it!


Ship It!

- Martin Gräßlin


On Oct. 22, 2015, 2:31 p.m., Dāvis Mosāns wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125756/
> ---
> 
> (Updated Oct. 22, 2015, 2:31 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Need to initialize QFunctionPointer to Q_NULLPTR because otherwise it's used 
> unitialized
> causing m_eglCreateImageKHR check to pass and crashing plasmashell because of 
> invalid call.
> Look at xcbWindowToTextureEGL function in 
> src/declarativeimports/core/windowthumbnail.cpp
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.cpp 
> 5a5274e1eacdb9b91ff500e1ebf9046930891ecf 
> 
> Diff: https://git.reviewboard.kde.org/r/125756/diff/
> 
> 
> Testing
> ---
> 
> Verified that plasmashell doesn't crash anymore.
> 
> 
> Thanks,
> 
> Dāvis Mosāns
> 
>

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

Re: Review Request 125756: Initialize QFunctionPointer to Q_NULLPTR

[Dāvis Mosāns]

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

(Updated Oct. 22, 2015, 3:31 p.m.)


Review request for KDE Frameworks and Plasma.


Changes
---

Use Q_NULLPTR and initialize in cpp


Summary (updated)
-

Initialize QFunctionPointer to Q_NULLPTR


Repository: plasma-framework


Description (updated)
---

Need to initialize QFunctionPointer to Q_NULLPTR because otherwise it's used 
unitialized
causing m_eglCreateImageKHR check to pass and crashing plasmashell because of 
invalid call.
Look at xcbWindowToTextureEGL function in 
src/declarativeimports/core/windowthumbnail.cpp


Diffs (updated)
-

  src/declarativeimports/core/windowthumbnail.cpp 
5a5274e1eacdb9b91ff500e1ebf9046930891ecf 

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


Testing
---

Verified that plasmashell doesn't crash anymore.


Thanks,

Dāvis Mosāns

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

Re: Review Request 125756: Initialize QFunctionPointer to nullptr

[Martin Gräßlin]

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



src/declarativeimports/core/windowthumbnail.h (lines 128 - 129)


AFAIK we are not yet allowed to use nullptr in frameworks. You need to use 
Q_NULLPTR which gets turned into nullptr if available in the compiler settings.

Also I think header initialization is not yet allowed, so please move to 
cpp file.

Meh, I want full C++11 on Linux only code.


- Martin Gräßlin


On Oct. 22, 2015, 2 p.m., Dāvis Mosāns wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125756/
> ---
> 
> (Updated Oct. 22, 2015, 2 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Need to initialize QFunctionPointer to nullptr because otherwise it's used 
> unitialized
> causing m_eglCreateImageKHR check to pass and crashing plasmashell because of 
> invalid call.
> Look at xcbWindowToTextureEGL function in 
> src/declarativeimports/core/windowthumbnail.cpp
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.h 
> 576b053229a8cfc15b6fadd8d4e6ff07f937565d 
> 
> Diff: https://git.reviewboard.kde.org/r/125756/diff/
> 
> 
> Testing
> ---
> 
> Verified that plasmashell doesn't crash anymore.
> 
> 
> Thanks,
> 
> Dāvis Mosāns
> 
>

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

Review Request 125756: Initialize QFunctionPointer to nullptr

[Dāvis Mosāns]

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

Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

Need to initialize QFunctionPointer to nullptr because otherwise it's used 
unitialized
causing m_eglCreateImageKHR check to pass and crashing plasmashell because of 
invalid call.
Look at xcbWindowToTextureEGL function in 
src/declarativeimports/core/windowthumbnail.cpp


Diffs
-

  src/declarativeimports/core/windowthumbnail.h 
576b053229a8cfc15b6fadd8d4e6ff07f937565d 

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


Testing
---

Verified that plasmashell doesn't crash anymore.


Thanks,

Dāvis Mosāns

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

Re: Review Request 125691: KOpenWithDialog: Fix creating desktop file with empty mimetype

[David Rosca]

> On Oct. 22, 2015, 7:30 a.m., David Faure wrote:
> > src/widgets/kopenwithdialog.cpp, line 911
> > 
> >
> > How about changing this condition to
> >(...) && !qMimeType.isEmpty() ?
> >
> > If there is no mimetype to "remember" then there is little point in 
> > creating a .desktop file in the first place, right?
> > 
> > And this avoids yet another code path at the end with the "else" you 
> > had to add.
> > 
> > 
> > Actually... if mimetype is empty, then bRemember has to be false (the 
> > checkbox isn't even shown). So I suppose createDesktopFile is true because 
> > saveNewApps is true?
> > 
> > Or is there a problem of isNull vs isEmpty in line 676?

Yes, saveNewApps is true and no remember checkbox is visible. 
It calls the addToMimeAppsList and then it hits assert there.


- David


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


On Oct. 18, 2015, 4:09 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125691/
> ---
> 
> (Updated Oct. 18, 2015, 4:09 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> If qMimeType is empty, addToMimeAppsList shouldn't be called.
> 
> 
> Diffs
> -
> 
>   src/widgets/kopenwithdialog.cpp c60a193 
> 
> Diff: https://git.reviewboard.kde.org/r/125691/diff/
> 
> 
> Testing
> ---
> 
> opening new KOpenWithDialog() without mimeType and typing eg "dolphin" to 
> exec line now correctly returns valid KService.
> 
> 
> Thanks,
> 
> David Rosca
> 
>

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

Re: icons packages with frameworks

[Christoph Cullmann]

Hi,

> On Wednesday 21 October 2015 21:07:16 Christoph Cullmann wrote:
>> Hi,
>> 
>> >> So maybe this wouldn't be such a bad move after all.
>> > 
>> > Agreed, we have frameworks (e.g. KIconThemes) "depending" on breeze, so it
>> > makes some kind of sense to ship them together.
>> yeah, beside that, if you want to create some self-contained installers,
>> you need breeze (or some other full iconset), too.
>> 
>> Therefore it is nice if one can grab the release matching the framework 
>> release
>> one uses.
> 
> I thought you wanted frameworks themselves to bundle icons rather
> than depend on a (large) icon theme.
> And I would agree -- I just don't know how this interacts with icon themes, 
> i.e.
> is it a problem to have a single icon in the .qrc.
I just wanted to bundle all images that the frameworks ATM ship with themself
to be in resources instead of spread out in share/., for the icons they use via
fromTheme/KIconLoader we still need the icon theme icons.
Have no real solution for that beside just bundling an theme inside the 
application
package, for Kate/KWrite I just packed complete breeze into some binary 
resource file
and that will be loaded + set as theme, if found.

> 
> But Martin's argument (apps should be able to depend on icons) is indeed
> a good reason to treat the default icon theme like a framework.
> 
> I'm OK with releasing an icon theme with KF5, provided that it follows the
> KF5 rules/policies (buildsystem, versioning etc.) so that it doesn't have
> to be special-cased.
Nice ;=)

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: breeze icons default and its inheritance

[David Faure]

On Thursday 22 October 2015 07:28:09 Harald Sitter wrote:
> if
> an icon was in oxygen (by default, or installed by an application)

I never understood why apps were changed to install their own icons
in oxygen rather than hicolor (which was the standard way to ensure icons
would be available whatever icon theme is being used).

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

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

Re: icons packages with frameworks

[David Faure]

On Wednesday 21 October 2015 21:07:16 Christoph Cullmann wrote:
> Hi,
> 
> >> So maybe this wouldn't be such a bad move after all.
> > 
> > Agreed, we have frameworks (e.g. KIconThemes) "depending" on breeze, so it
> > makes some kind of sense to ship them together.
> yeah, beside that, if you want to create some self-contained installers,
> you need breeze (or some other full iconset), too.
> 
> Therefore it is nice if one can grab the release matching the framework 
> release one uses.

I thought you wanted frameworks themselves to bundle icons rather
than depend on a (large) icon theme.
And I would agree -- I just don't know how this interacts with icon themes, i.e.
is it a problem to have a single icon in the .qrc.

But Martin's argument (apps should be able to depend on icons) is indeed
a good reason to treat the default icon theme like a framework.

I'm OK with releasing an icon theme with KF5, provided that it follows the
KF5 rules/policies (buildsystem, versioning etc.) so that it doesn't have
to be special-cased.


(Notice I don't say oxygen or breeze, because I'm confused about that ;)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

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

Re: Review Request 125725: Make KCrash optional for kservice

[David Faure]

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


For the record, I would have approved this. This is really just extra 
rarely-needed safety, because nowadays the apps themselves rebuild sycoca 
directly, so the use of kcrash here is really just for the corner case of "all 
my apps crash because of ksycoca being corrupted" and then you try to run 
kbuildsycoca to repair that, it crashes - and the crash handler deletes the bad 
file. Corner case, because you could have use --noincremental instead, or just 
deleted the cache by hand.

- David Faure


On Oct. 20, 2015, 2 p.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125725/
> ---
> 
> (Updated Oct. 20, 2015, 2 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kservice
> 
> 
> Description
> ---
> 
> kservice depends on KCrash only for kbuildsycoca.
> make this optional and link only against it, if around. Move check to 
> kbuildsyscoca file.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 4c0f269 
>   src/kbuildsycoca/CMakeLists.txt 19bdc84 
>   src/kbuildsycoca/kbuildsycoca_main.cpp 03619cc 
> 
> Diff: https://git.reviewboard.kde.org/r/125725/diff/
> 
> 
> Testing
> ---
> 
> Seems to compile fine without it.
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

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

Re: Review Request 125436: Add an interface which allow plugin to show custom overlay icons (in KIO)

[David Faure]

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



src/widgets/koverlayiconplugin.h (line 44)


It was virtual already anyway, given that this derives from QObject.


- David Faure


On Oct. 19, 2015, 9:08 a.m., Olivier Goffart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125436/
> ---
> 
> (Updated Oct. 19, 2015, 9:08 a.m.)
> 
> 
> Review request for Dolphin and KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> The interface from https://git.reviewboard.kde.org/r/125136/ moved into KIO.
> 
> 
> Diffs
> -
> 
>   src/widgets/CMakeLists.txt d249c0c 
>   src/widgets/koverlayiconplugin.h PRE-CREATION 
>   src/widgets/koverlayiconplugin.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/125436/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Olivier Goffart
> 
>

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

Re: Review Request 125164: Fix misbehavior when canceling a job

[David Faure]

> On Oct. 19, 2015, 5:44 p.m., Albert Astals Cid wrote:
> > Is this trying to fix something similar to 
> > https://git.reviewboard.kde.org/r/125613/diff/ ?

No, completely unrelated.


- David


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


On Sept. 11, 2015, 1:24 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125164/
> ---
> 
> (Updated Sept. 11, 2015, 1:24 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Catch that the job has been cancelled and emit the job as finished.
> 
> Still, I'm not too sure it's the correct fix.
> 
> 
> Diffs
> -
> 
>   autotests/jobtest.h ef8c3e1 
>   autotests/jobtest.cpp c24bcea 
>   src/core/transferjob.cpp 0c38070 
> 
> Diff: https://git.reviewboard.kde.org/r/125164/diff/
> 
> 
> Testing
> ---
> 
> Added a test and made it pass.
> 
> 
> 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 125164: Fix misbehavior when canceling a job

[David Faure]

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



autotests/jobtest.cpp (line 298)


did you copy/paste all that stuff from elsewhere? I don't see why you need 
that modificationtime stuff for this test.



autotests/jobtest.cpp (line 309)


What is the purpose of changing the currently-being-uploaded data buffer? 
Ah, from the fix I can see the purpose is to make it emit readyRead. Can you 
add a comment here like  "// make it emit readyRead..." if that's indeed the 
idea?

(I assume this is to emulate something more like a socket?)



autotests/jobtest.cpp (line 311)


Why restart the timer here? You kill the job more than once? I'm confused.



src/core/transferjob.cpp (line 400)


Why slotFinished? Wouldn't just return be enough?
kill() is supposed to take care of emitting finished already, and you don't 
want to emit it twice.


- David Faure


On Sept. 11, 2015, 1:24 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125164/
> ---
> 
> (Updated Sept. 11, 2015, 1:24 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Catch that the job has been cancelled and emit the job as finished.
> 
> Still, I'm not too sure it's the correct fix.
> 
> 
> Diffs
> -
> 
>   autotests/jobtest.h ef8c3e1 
>   autotests/jobtest.cpp c24bcea 
>   src/core/transferjob.cpp 0c38070 
> 
> Diff: https://git.reviewboard.kde.org/r/125164/diff/
> 
> 
> Testing
> ---
> 
> Added a test and made it pass.
> 
> 
> 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 125691: KOpenWithDialog: Fix creating desktop file with empty mimetype

[David Faure]

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



src/widgets/kopenwithdialog.cpp (line 911)


How about changing this condition to
   (...) && !qMimeType.isEmpty() ?
   
If there is no mimetype to "remember" then there is little point in 
creating a .desktop file in the first place, right?

And this avoids yet another code path at the end with the "else" you had to 
add.

Actually... if mimetype is empty, then bRemember has to be false (the 
checkbox isn't even shown). So I suppose createDesktopFile is true because 
saveNewApps is true?

Or is there a problem of isNull vs isEmpty in line 676?


- David Faure


On Oct. 18, 2015, 4:09 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125691/
> ---
> 
> (Updated Oct. 18, 2015, 4:09 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> If qMimeType is empty, addToMimeAppsList shouldn't be called.
> 
> 
> Diffs
> -
> 
>   src/widgets/kopenwithdialog.cpp c60a193 
> 
> Diff: https://git.reviewboard.kde.org/r/125691/diff/
> 
> 
> Testing
> ---
> 
> opening new KOpenWithDialog() without mimeType and typing eg "dolphin" to 
> exec line now correctly returns valid KService.
> 
> 
> 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 125158: add logic to use icons for default xdg user dirs

[Harald Sitter]

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

(Updated Oct. 22, 2015, 7:26 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit 93d71cdd19a6a844363751bd0299205d00d9a3a6 by Harald Sitter 
to branch master.


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


Repository: kio


Description
---

this acts as an additional fallback to mimetype iconing and .directory
overrides. xdg user dirs are relocatable and can change depending on user
locale as well as user configuration and additionally are used in a range
of different desktop environments making this a very runtime sort of
decision.

BUG: 352498


Diffs
-

  autotests/kfileitemtest.h 615324f2b45fdc90a7841bdd0c8aa7f47cdf57a2 
  autotests/kfileitemtest.cpp 5f728a411401fe3009924b66970d9ae6f12c60f2 
  src/core/kfileitem.cpp 966d8626708a8f2672f1777c873f4e27e13023d6 

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


Testing
---

maked
autotested
installed
dolphin and file open dialogs now show icons


Thanks,

Harald Sitter

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

Re: Review Request 125158: add logic to use icons for default xdg user dirs

[David Faure]

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

Ship it!


This looks good to me. Don't move the struct out of the function, it's very 
local to it, and initializing on first use is better than during every program 
startup.

- David Faure


On Oct. 2, 2015, 12:59 p.m., Harald Sitter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125158/
> ---
> 
> (Updated Oct. 2, 2015, 12:59 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Bugs: 352498
> https://bugs.kde.org/show_bug.cgi?id=352498
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> this acts as an additional fallback to mimetype iconing and .directory
> overrides. xdg user dirs are relocatable and can change depending on user
> locale as well as user configuration and additionally are used in a range
> of different desktop environments making this a very runtime sort of
> decision.
> 
> BUG: 352498
> 
> 
> Diffs
> -
> 
>   autotests/kfileitemtest.h 615324f2b45fdc90a7841bdd0c8aa7f47cdf57a2 
>   autotests/kfileitemtest.cpp 5f728a411401fe3009924b66970d9ae6f12c60f2 
>   src/core/kfileitem.cpp 966d8626708a8f2672f1777c873f4e27e13023d6 
> 
> Diff: https://git.reviewboard.kde.org/r/125158/diff/
> 
> 
> Testing
> ---
> 
> maked
> autotested
> installed
> dolphin and file open dialogs now show icons
> 
> 
> Thanks,
> 
> Harald Sitter
> 
>

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

Re: Review Request 125325: New widget KCollapsibleGroupBox

[David Faure]

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

Ship it!


Ship It!

- David Faure


On Oct. 20, 2015, 9:20 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125325/
> ---
> 
> (Updated Oct. 20, 2015, 9:20 p.m.)
> 
> 
> Review request for KDE Frameworks and Christoph Feck.
> 
> 
> Repository: kwidgetsaddons
> 
> 
> Description
> ---
> 
> A groupbox featuring a clickable header and arrow indicator that can be
> expanded and collapsed to reveal the box content
> 
> Widget features a close and collapse animation and works as expected in
> QtDesigner.
> 
> --
> Screenshot explains what I mean better than the description above.
> 
> I've been given at least 3 mockups from the VDG mockup which feature using 
> this widget, clearly there's a demand for it. 
> 
> It's a bit like QToolBox, except no-one uses it because QToolbox has a weird 
> way of only expanding one at a time, and looks a bit weird so no-one uses it.
> 
> 
> Diffs
> -
> 
>   src/CMakeLists.txt cc32508aff5452ec95f666d1a6545fd2dd1294f8 
>   src/kcollapsiblegroupbox.h PRE-CREATION 
>   src/kcollapsiblegroupbox.cpp PRE-CREATION 
>   tests/CMakeLists.txt 180b0ef1f8900247da59112612ee87dd3164c8af 
>   tests/kcollapsiblegroupboxtest.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/125325/diff/
> 
> 
> Testing
> ---
> 
> Made little test app (see screenshot)
> 
> Wrote QtDesigner plugin, and played with it there.
> 
> 
> File Attachments
> 
> 
> kcollapsiblegroupbox.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/09/20/f9758e22-0043-4876-b462-364c3b2854dc__kcollapsiblegroupbox.png
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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