Re: Jenkins-kde-ci: plasma-framework master kf5-qt5 » Linux,All,gcc - Build # 116 - Still Unstable!

2015-11-02 Thread Marco Martin 
On Monday 02 November 2015, David Faure wrote:
> On Monday 02 November 2015 12:44:12 no-re...@kde.org wrote:
> > https://build.kde.org/job/frameworkintegration%20master%20kf5-qt5/PLATFOR
> > M=Linux,compiler=gcc/31/ Name: (root) Failed: 1 test(s), Passed: 10
> > test(s), Skipped: 0 test(s), Total: 11 test(s)Failed:
> > TestSuite.dialognativetest
> 
> Is anyone looking into fixing that, before making more commits to
> plasma-framework?

hmm, is the oxygen icon theme not installed anymore in kci?

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

Jenkins-kde-ci: plasma-framework master kf5-qt5 » Linux,All,gcc - Build # 117 - Still Unstable!

2015-11-02 Thread no-reply 

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/117/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Mon, 02 Nov 2015 13:28:29 +
Build duration: 7 min 11 sec

CHANGE SET
Revision 955a7f87b57ab6a406f3ea25322e65ab098036d7 by Marco Martin: (more 
readable spinner at small sizes)
  change: edit src/desktoptheme/breeze/widgets/busywidget.svgz


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 
11 test(s)Failed: TestSuite.dialognativetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 5/7 (71%)FILES 63/104 (61%)CLASSES 63/104 (61%)LINE 3908/10009 
(39%)CONDITIONAL 1917/3034 (63%)

By packages
  
autotests
FILES 20/20 (100%)CLASSES 20/20 (100%)LINE 543/564 
(96%)CONDITIONAL 338/606 (56%)
src.declarativeimports.core
FILES 7/20 (35%)CLASSES 7/20 (35%)LINE 355/2003 
(18%)CONDITIONAL 148/228 (65%)
src.plasma
FILES 14/21 (67%)CLASSES 14/21 (67%)LINE 1588/3635 
(44%)CONDITIONAL 776/1192 (65%)
src.plasma.private
FILES 18/26 (69%)CLASSES 18/26 (69%)LINE 942/1739 
(54%)CONDITIONAL 395/600 (66%)
src.plasma.scripting
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/184 (0%)CONDITIONAL 0/0 
(100%)
src.plasmaquick
FILES 4/11 (36%)CLASSES 4/11 (36%)LINE 480/1771 
(27%)CONDITIONAL 260/408 (64%)
src.plasmaquick.private
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/113 (0%)CONDITIONAL 0/0 
(100%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Failure while executing KTar::open while using KCompressionDevice as the device

2015-11-02 Thread Luiz Romário Santana Rios 
Hello,

I'm trying to decompress a XZ archive downloaded using
QNetworkAccessManager, so, according to the documents, I have to pass
the QNetworkReply pointer to a KCompressionDevice and, then, use it as
Ktar's device like this:

https://gist.github.com/anonymous/b8fb686367f518a7dbb5

The problem is that KTar::open() fails and returns false. The file I'm
trying to extract has the following structure more or less:
/root
/root/dir
/root/dir/file1
/root/dir/file2
...

So, as far as I've seen, the code runs normally when entering /root
and /root/dir, but, pretty high in the stack, at
KXzFilter::uncompress(), the call to lzma_code returns
LZMA_FORMAT_ERROR while trying to uncompress file1 (or file2, I'm not
sure). Here's the call stack:

https://gist.github.com/anonymous/9ea380cfe48daadb5971

Is this a bug? If it's a bug, how can I proceed to fix it?

Thanks for the attention.

-- 
Luiz Romário Santana Rios
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Failure while executing KTar::open while using KCompressionDevice as the device

2015-11-02 Thread Boudhayan Gupta 
I'd first ascertain whether the file is corrupt. Why don't you dump
the tar to a QFile and manually use tar -xvf to extract it, just to
test whether the download is working?

On 2 November 2015 at 23:23, Luiz Romário Santana Rios
 wrote:
> Hello,
>
> I'm trying to decompress a XZ archive downloaded using
> QNetworkAccessManager, so, according to the documents, I have to pass
> the QNetworkReply pointer to a KCompressionDevice and, then, use it as
> Ktar's device like this:
>
> https://gist.github.com/anonymous/b8fb686367f518a7dbb5
>
> The problem is that KTar::open() fails and returns false. The file I'm
> trying to extract has the following structure more or less:
> /root
> /root/dir
> /root/dir/file1
> /root/dir/file2
> ...
>
> So, as far as I've seen, the code runs normally when entering /root
> and /root/dir, but, pretty high in the stack, at
> KXzFilter::uncompress(), the call to lzma_code returns
> LZMA_FORMAT_ERROR while trying to uncompress file1 (or file2, I'm not
> sure). Here's the call stack:
>
> https://gist.github.com/anonymous/9ea380cfe48daadb5971
>
> Is this a bug? If it's a bug, how can I proceed to fix it?
>
> Thanks for the attention.
>
> --
> Luiz Romário Santana Rios
> ___
> 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: Review Request 125915: Drop runtime dependency on QApplication

2015-11-02 Thread Martin Gräßlin 

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


I consider this a very dangerous change. We don't have unit tests for this 
specific code, it's an unlikely code path to be taken and we won't notice 
regressions.

Personally I don't see a problem with having a dependency on QApplication. 
KWindowSystem links against Qt::Widgets that makes it obvious to any user that 
it requires a QApplication. If we want to make it work with QGuiApplication, 
then we need to make sure that we also get rid of Qt::Widgets dependency. 
Otherwise I think we are still in undefined behavior area if someone uses 
KWindowSystem without a QApplication.

So overall from my side rather a -1 to this change. Risk of breakage too high 
for little benefit.

- Martin Gräßlin


On Nov. 1, 2015, 11:58 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125915/
> ---
> 
> (Updated Nov. 1, 2015, 11:58 p.m.)
> 
> 
> Review request for KDE Frameworks and Albert Astals Cid.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> QDesktopWidget was used which is broken for applications using
> QGuiApplication.
> 
> QDesktopWidget is now just a thin wrapper over QScreen so we can use that 
> directly.
> 
> QApplication::activeWindow is ported to QGuiApplication::topLevelWindows
> and then itterating to see if one is active.
> 
> 
> Diffs
> -
> 
>   src/platforms/xcb/kwindowsystem.cpp 
> 9d287043c24894ca3c29c439c7939b139da055e8 
> 
> Diff: https://git.reviewboard.kde.org/r/125915/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: Review Request 125905: Make kactivitymanagerd a QApplication

2015-11-02 Thread Martin Gräßlin 


> On Nov. 1, 2015, 11:35 p.m., David Edmundson wrote:
> > I've made https://git.reviewboard.kde.org/r/125915/

back referencing my comment to that review: I think trying to change 
KWindowSystem to not use desktopWidget doesn't solve the problem. KWindowSystem 
is a QWidget based framework. Thus it requires a QApplication.


- Martin


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


On Nov. 1, 2015, 2:33 a.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125905/
> ---
> 
> (Updated Nov. 1, 2015, 2:33 a.m.)
> 
> 
> Review request for KDE Frameworks, Martin Gräßlin and Ivan Čukić.
> 
> 
> Repository: kactivities
> 
> 
> Description
> ---
> 
> KWindowSystem is QWidget based so needs QApplication or asserts in some 
> situations (when run on unity7 for example)
> 
> 
> Diffs
> -
> 
>   src/service/Application.h 387d4d7 
>   src/service/Application.cpp ec74daa 
> 
> Diff: https://git.reviewboard.kde.org/r/125905/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>

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

Re: Review Request 125817: Add plugin system for Calendar events

2015-11-02 Thread Martin Klapetek 

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

(Updated Nov. 2, 2015, 6:35 p.m.)


Review request for KDE Frameworks, Plasma and Daniel Vrátil.


Changes
---

* Fixed David's issues
* Sorted the events by their starttime


Repository: plasma-framework


Description
---

This adds a simple plugin interface that can be subclassed
and provide events integration with Plasma Calendar applet.

It's asynchronous and I've kept it deliberately simple.
For now the Calendar tells the plugins which date range
is being displayed, the plugins load the data and then
emit the dataReady() signal containing the events.

The events are stored in a multihash for quick access
by the Calendar's agenda part but also for overall
easy-to-use (eg. in teh model data()).

The event data is stored in EventData class, which has
a pretty self-explanatory members, except perhaps the
"isMinor" one. The intention with this is to support
namedays, where in some countries the calendars have
different name every day. This is just a minor holiday
and as such should not mark the calendar grid, otherwise
the whole grid would be in a different color.

Putting the interface here might raise the question of
depending on plasma-framework, but plugins provided by
KDE can go to plasma-workspace and other 3rd party ones
would just have to live with it. I don't think it will
be a problem but if it turns out it is, we can rethink
the placement.


Diffs (updated)
-

  src/declarativeimports/calendar/CMakeLists.txt 40ead91 
  src/declarativeimports/calendar/calendarplugin.cpp bafe80c 
  src/declarativeimports/calendar/daysmodel.h a5bdac9 
  src/declarativeimports/calendar/daysmodel.cpp 2d059a8 
  src/declarativeimports/calendar/eventdatadecorator.h PRE-CREATION 
  src/declarativeimports/calendar/eventdatadecorator.cpp PRE-CREATION 
  src/declarativeimports/calendar/plasmacalendarintegration/CMakeLists.txt 
PRE-CREATION 
  
src/declarativeimports/calendar/plasmacalendarintegration/PlasmaCalendarIntegrationConfig.cmake.in
 PRE-CREATION 
  
src/declarativeimports/calendar/plasmacalendarintegration/calendareventsplugin.h
 PRE-CREATION 
  
src/declarativeimports/calendar/plasmacalendarintegration/calendareventsplugin.cpp
 PRE-CREATION 
  src/declarativeimports/calendar/plasmacalendarintegration/eventdata_p.cpp 
PRE-CREATION 
  
src/declarativeimports/calendar/plasmacalendarintegration/plasmacalendarintegration_export.h
 PRE-CREATION 

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


Testing
---

I have a simple KHolidays based plugin written (patch should be up later today)
and patches in the Calendar applet.

Everything works as expected:
* the days are marked as containing an event
* the agenda part displays details of that event (name)


Thanks,

Martin Klapetek

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

Re: Review Request 125911: EventGenerator: Add support for sending wheel events

2015-11-02 Thread David Rosca 

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

(Updated Nov. 2, 2015, 9:48 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit 2e363913cc3b2b416a98df17420820f1d1bc37f5 by David Rosca 
to branch master.


Repository: kdeclarative


Description
---

Add sendWheelEvent and sendWheelEventRecursive


Diffs
-

  src/qmlcontrols/kquickcontrolsaddons/eventgenerator.cpp 4026a88 
  src/qmlcontrols/kquickcontrolsaddons/eventgenerator.h 8e719ae 

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


Testing
---


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 125884: Set default value for WheelScrollLines

2015-11-02 Thread David Rosca 

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

(Updated Nov. 2, 2015, 9:21 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit 70c200431e02fc00ce1e496ead9e8f0980d24525 by David Rosca 
to branch master.


Repository: frameworkintegration


Description
---

Use 3 (same as mouse kcm) as default value instead of 
QApplication::wheelScrollLines().


Diffs
-

  src/platformtheme/khintssettings.cpp e5c362a 

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


Testing
---

No longer sets 0 lines when WheelScrollLines entry is not in kdeglobals.


Thanks,

David Rosca

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

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

2015-11-02 Thread no-reply 

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/frameworkintegration%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/31/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 Nov 2015 09:21:58 +
Build duration: 4 min 1 sec

CHANGE SET
Revision 70c200431e02fc00ce1e496ead9e8f0980d24525 by nowrep: (Set default value 
for WheelScrollLines)
  change: edit src/platformtheme/khintssettings.cpp


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 7 
test(s)Failed: TestSuite.frameworkintegration-kdeplatformtheme_unittest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 3/3 (100%)FILES 20/20 (100%)CLASSES 20/20 (100%)LINE 1119/1749 
(64%)CONDITIONAL 426/795 (54%)

By packages
  
autotests
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 410/435 (94%)CONDITIONAL 
211/389 (54%)
src.kstyle
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 45/178 (25%)CONDITIONAL 
28/103 (27%)
src.platformtheme
FILES 12/12 (100%)CLASSES 12/12 (100%)LINE 664/1136 
(58%)CONDITIONAL 187/303 (62%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125905: Make kactivitymanagerd a QApplication

2015-11-02 Thread Martin Gräßlin 


> On Nov. 1, 2015, 12:49 p.m., Ivan Čukić wrote:
> > So, we went a full circle back to QApplication :)
> > 
> > What assert are you hitting on unity?
> 
> Albert Astals Cid wrote:
> KWindowSystem uses QApplication::desktopWidget which you can't if you're 
> not a QApplication

> What assert are you hitting on unity?

The reason for this is that Compiz in opposite to KWin does virtual desktops 
through viewports. The code paths with the desktopWidget are the fallback code 
paths for viewport handling.


- Martin


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


On Nov. 1, 2015, 2:33 a.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125905/
> ---
> 
> (Updated Nov. 1, 2015, 2:33 a.m.)
> 
> 
> Review request for KDE Frameworks, Martin Gräßlin and Ivan Čukić.
> 
> 
> Repository: kactivities
> 
> 
> Description
> ---
> 
> KWindowSystem is QWidget based so needs QApplication or asserts in some 
> situations (when run on unity7 for example)
> 
> 
> Diffs
> -
> 
>   src/service/Application.h 387d4d7 
>   src/service/Application.cpp ec74daa 
> 
> Diff: https://git.reviewboard.kde.org/r/125905/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>

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

Re: Review Request 125915: Drop runtime dependency on QApplication

2015-11-02 Thread David Edmundson 


> On Nov. 2, 2015, 8:04 a.m., Martin Gräßlin wrote:
> > I consider this a very dangerous change. We don't have unit tests for this 
> > specific code, it's an unlikely code path to be taken and we won't notice 
> > regressions.
> > 
> > Personally I don't see a problem with having a dependency on QApplication. 
> > KWindowSystem links against Qt::Widgets that makes it obvious to any user 
> > that it requires a QApplication. If we want to make it work with 
> > QGuiApplication, then we need to make sure that we also get rid of 
> > Qt::Widgets dependency. Otherwise I think we are still in undefined 
> > behavior area if someone uses KWindowSystem without a QApplication.
> > 
> > So overall from my side rather a -1 to this change. Risk of breakage too 
> > high for little benefit.

>Very dangerous

It's not that bad, it's a copy and paste from 
QDesktopWidgetPrivate::_q_updateScreens 

>Personally I don't see a problem with having a dependency on QApplication. 
>KWindowSystem links against Qt::Widgets that makes it obvious to any user that 
>it requires a QApplication. 

Not that obvious, I made the "mistake". You get to save nearly ~4Mb from QApp 
-> QGuiApp
Also PlasmaCore import is full of KWindowSystem calls which means ksplashapp, 
sddm-greeter and probably few others are already in the same situation.


> then we need to make sure that we also get rid of Qt::Widgets dependency.

++. Espsecially if we think longer term. 
Unfortuantely, we can't without an API break. There's a few helper methods 
where we have a version with wID and a version with QWidget* just to get the 
wID.


- David


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


On Nov. 1, 2015, 10:58 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125915/
> ---
> 
> (Updated Nov. 1, 2015, 10:58 p.m.)
> 
> 
> Review request for KDE Frameworks and Albert Astals Cid.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> QDesktopWidget was used which is broken for applications using
> QGuiApplication.
> 
> QDesktopWidget is now just a thin wrapper over QScreen so we can use that 
> directly.
> 
> QApplication::activeWindow is ported to QGuiApplication::topLevelWindows
> and then itterating to see if one is active.
> 
> 
> Diffs
> -
> 
>   src/platforms/xcb/kwindowsystem.cpp 
> 9d287043c24894ca3c29c439c7939b139da055e8 
> 
> Diff: https://git.reviewboard.kde.org/r/125915/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: Jenkins-kde-ci: plasma-framework master kf5-qt5 » Linux, All, gcc - Build # 116 - Still Unstable!

2015-11-02 Thread Albert Astals Cid 
El Monday 02 November 2015, a les 14:56:15, Marco Martin va escriure:
> On Monday 02 November 2015, David Faure wrote:
> > On Monday 02 November 2015 12:44:12 no-re...@kde.org wrote:
> > > https://build.kde.org/job/frameworkintegration%20master%20kf5-qt5/PLATFO
> > > R
> > > M=Linux,compiler=gcc/31/ Name: (root) Failed: 1 test(s), Passed: 10
> > > test(s), Skipped: 0 test(s), Total: 11 test(s)Failed:
> > > TestSuite.dialognativetest
> > 
> > Is anyone looking into fixing that, before making more commits to
> > plasma-framework?
> 
> hmm, is the oxygen icon theme not installed anymore in kci?

oxygen is not a dependency of frameworksintegration so i guess no.

How does oxygen being installed influence the wheelScrollLines though?

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

KPixmapCache in kdelibs4support uses QDateTime in mmap'ed struct

2015-11-02 Thread Albert Astals Cid 
Someone went a bit too far in the "port away from time_t to QDateTime" and 
changed the timestamp member of the KPixmapCacheIndexHeader struct.

According to mpyne and thiago this is a big no-no.

I'm suggesting bringing the code back to using time_t so it still works, this 
may be a bit less portable, but it's kdelibs4support support anyway, i think 
we can compromise portability here for "it works" :D

Opinions?

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

Re: Review Request 125915: Drop runtime dependency on QApplication

2015-11-02 Thread Martin Gräßlin 


> On Nov. 2, 2015, 9:04 a.m., Martin Gräßlin wrote:
> > I consider this a very dangerous change. We don't have unit tests for this 
> > specific code, it's an unlikely code path to be taken and we won't notice 
> > regressions.
> > 
> > Personally I don't see a problem with having a dependency on QApplication. 
> > KWindowSystem links against Qt::Widgets that makes it obvious to any user 
> > that it requires a QApplication. If we want to make it work with 
> > QGuiApplication, then we need to make sure that we also get rid of 
> > Qt::Widgets dependency. Otherwise I think we are still in undefined 
> > behavior area if someone uses KWindowSystem without a QApplication.
> > 
> > So overall from my side rather a -1 to this change. Risk of breakage too 
> > high for little benefit.
> 
> David Edmundson wrote:
> >Very dangerous
> 
> It's not that bad, it's a copy and paste from 
> QDesktopWidgetPrivate::_q_updateScreens 
> 
> >Personally I don't see a problem with having a dependency on 
> QApplication. KWindowSystem links against Qt::Widgets that makes it obvious 
> to any user that it requires a QApplication. 
> 
> Not that obvious, I made the "mistake". You get to save nearly ~4Mb from 
> QApp -> QGuiApp
> Also PlasmaCore import is full of KWindowSystem calls which means 
> ksplashapp, sddm-greeter and probably few others are already in the same 
> situation.
> 
> 
> > then we need to make sure that we also get rid of Qt::Widgets 
> dependency.
> 
> ++. Espsecially if we think longer term. 
> Unfortuantely, we can't without an API break. There's a few helper 
> methods where we have a version with wID and a version with QWidget* just to 
> get the wID.

> It's not that bad,

I stay with "very dangerous" without having a single test case for this code.

> ksplashapp, sddm-greeter and probably few others are already in the same 
> situation.

yes, and they all should use QApplication to get QStyle. Otherwise there might 
be runtime breakage like wrong colours being picked up, etc.

> Unfortuantely, we can't without an API break

I know.

> There's a few helper methods where we have a version with wID and a version 
> with QWidget* just to get the wID.

We can deprecate those and add QWindow variants. But that's about it. No chance 
to get this changed till KF 6.

But it's not the only usage. There is also usage of QWidget in the library. An 
example is kxmessages. As long as we internally use QWidget I think it's a sure 
thing that this is a QWidget library and requires QApplication.


- Martin


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


On Nov. 1, 2015, 11:58 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125915/
> ---
> 
> (Updated Nov. 1, 2015, 11:58 p.m.)
> 
> 
> Review request for KDE Frameworks and Albert Astals Cid.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> QDesktopWidget was used which is broken for applications using
> QGuiApplication.
> 
> QDesktopWidget is now just a thin wrapper over QScreen so we can use that 
> directly.
> 
> QApplication::activeWindow is ported to QGuiApplication::topLevelWindows
> and then itterating to see if one is active.
> 
> 
> Diffs
> -
> 
>   src/platforms/xcb/kwindowsystem.cpp 
> 9d287043c24894ca3c29c439c7939b139da055e8 
> 
> Diff: https://git.reviewboard.kde.org/r/125915/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: KPixmapCache in kdelibs4support uses QDateTime in mmap'ed struct

2015-11-02 Thread Michael Pyne 
On Tue, November 3, 2015 00:40:58 Albert Astals Cid wrote:
> Someone went a bit too far in the "port away from time_t to QDateTime" and
> changed the timestamp member of the KPixmapCacheIndexHeader struct.
> 
> According to mpyne and thiago this is a big no-no.

The reason it's a big no-no is because KPixmapCacheIndexHeader is meant to be 
held and used from mmap()'d shared memory, which generally requires the use of 
plain old data (POD) types only, to avoid inadvertent constructor or 
destructor calls once the memory is freed.

QDateTime will (and is) leak applications to crash so I'd +1 the 
recommendation to change back to time_t (or at least some kind of integral 
type), and the type is internal-only so there's no API concern. Just don't 
forget to bump the defined KPIXMAPCACHE_VERSION so that old caches are flushed 
;).

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

Re: Failure while executing KTar::open while using KCompressionDevice as the device

2015-11-02 Thread Aleix Pol 
On Mon, Nov 2, 2015 at 6:53 PM, Luiz Romário Santana Rios
 wrote:
> Hello,
>
> I'm trying to decompress a XZ archive downloaded using
> QNetworkAccessManager, so, according to the documents, I have to pass
> the QNetworkReply pointer to a KCompressionDevice and, then, use it as
> Ktar's device like this:
>
> https://gist.github.com/anonymous/b8fb686367f518a7dbb5
>
> The problem is that KTar::open() fails and returns false. The file I'm
> trying to extract has the following structure more or less:
> /root
> /root/dir
> /root/dir/file1
> /root/dir/file2
> ...
>
> So, as far as I've seen, the code runs normally when entering /root
> and /root/dir, but, pretty high in the stack, at
> KXzFilter::uncompress(), the call to lzma_code returns
> LZMA_FORMAT_ERROR while trying to uncompress file1 (or file2, I'm not
> sure). Here's the call stack:
>
> https://gist.github.com/anonymous/9ea380cfe48daadb5971
>
> Is this a bug? If it's a bug, how can I proceed to fix it?
>
> Thanks for the attention.

Hi,
A good first step would be coming up with a unit test like the ones
you can find in karchive/autotests. If we have a reproducible test
case it will be much faster to fix (for you and for us).

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

Jenkins-kde-ci: plasma-framework master kf5-qt5 » Linux,All,gcc - Build # 116 - Still Unstable!

2015-11-02 Thread no-reply 

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/116/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Mon, 02 Nov 2015 12:31:09 +
Build duration: 3 min 3 sec

CHANGE SET
Revision 02210d4e7ea10b35fc475edb79aefa1d4b1691a5 by Marco Martin: (colored 
view-history)
  change: edit src/desktoptheme/breeze/icons/view.svgz


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 
11 test(s)Failed: TestSuite.dialognativetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 5/7 (71%)FILES 63/104 (61%)CLASSES 63/104 (61%)LINE 3910/10009 
(39%)CONDITIONAL 1918/3036 (63%)

By packages
  
autotests
FILES 20/20 (100%)CLASSES 20/20 (100%)LINE 541/564 
(96%)CONDITIONAL 338/606 (56%)
src.declarativeimports.core
FILES 7/20 (35%)CLASSES 7/20 (35%)LINE 355/2003 
(18%)CONDITIONAL 148/228 (65%)
src.plasma
FILES 14/21 (67%)CLASSES 14/21 (67%)LINE 1588/3635 
(44%)CONDITIONAL 776/1192 (65%)
src.plasma.private
FILES 18/26 (69%)CLASSES 18/26 (69%)LINE 946/1739 
(54%)CONDITIONAL 396/602 (66%)
src.plasma.scripting
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/184 (0%)CONDITIONAL 0/0 
(100%)
src.plasmaquick
FILES 4/11 (36%)CLASSES 4/11 (36%)LINE 480/1771 
(27%)CONDITIONAL 260/408 (64%)
src.plasmaquick.private
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/113 (0%)CONDITIONAL 0/0 
(100%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Failure while executing KTar::open while using KCompressionDevice as the device

2015-11-02 Thread Aleix Pol 
On Tue, Nov 3, 2015 at 3:00 AM, Luiz Romário Santana Rios
 wrote:
> 2015-11-02 22:41 GMT-03:00 Aleix Pol :
>> On Mon, Nov 2, 2015 at 6:53 PM, Luiz Romário Santana Rios
>>  wrote:
>>> Hello,
>>>
>>> I'm trying to decompress a XZ archive downloaded using
>>> QNetworkAccessManager, so, according to the documents, I have to pass
>>> the QNetworkReply pointer to a KCompressionDevice and, then, use it as
>>> Ktar's device like this:
>>>
>>> https://gist.github.com/anonymous/b8fb686367f518a7dbb5
>>>
>>> The problem is that KTar::open() fails and returns false. The file I'm
>>> trying to extract has the following structure more or less:
>>> /root
>>> /root/dir
>>> /root/dir/file1
>>> /root/dir/file2
>>> ...
>>>
>>> So, as far as I've seen, the code runs normally when entering /root
>>> and /root/dir, but, pretty high in the stack, at
>>> KXzFilter::uncompress(), the call to lzma_code returns
>>> LZMA_FORMAT_ERROR while trying to uncompress file1 (or file2, I'm not
>>> sure). Here's the call stack:
>>>
>>> https://gist.github.com/anonymous/9ea380cfe48daadb5971
>>>
>>> Is this a bug? If it's a bug, how can I proceed to fix it?
>>>
>>> Thanks for the attention.
>>
>> Hi,
>> A good first step would be coming up with a unit test like the ones
>> you can find in karchive/autotests. If we have a reproducible test
>> case it will be much faster to fix (for you and for us).
>>
>> Regards,
>> Aleix
>
> I'll do that, but how do I host a local file so that it can be
> "downloaded" from QNAM?
>
> --
> Luiz Romário Santana Rios

Using file:/// url scheme you can asynchronously read local files.

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