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

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/karchive%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/48/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 05 Jan 2016 09:00:27 +
Build duration: 1 min 42 sec

CHANGE SET
Revision 77c13da03864bc86715e634523a273a2909b49e1 by David Faure: (fix compiler 
warning/error (gcc and clang disagree on how to write)
  change: edit autotests/kcompressiondevicetest.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 29/30 (97%)CLASSES 29/30 (97%)LINE 4014/4816 
(83%)CONDITIONAL 1962/3142 (62%)

By packages
  
autotests
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 1067/1073 
(99%)CONDITIONAL 677/1293 (52%)
src
FILES 20/21 (95%)CLASSES 20/21 (95%)LINE 2947/3743 
(79%)CONDITIONAL 1285/1849 (69%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/karchive%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/48/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 05 Jan 2016 09:00:27 +
Build duration: 1 min 42 sec

CHANGE SET
Revision 77c13da03864bc86715e634523a273a2909b49e1 by David Faure: (fix compiler 
warning/error (gcc and clang disagree on how to write)
  change: edit autotests/kcompressiondevicetest.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 29/30 (97%)CLASSES 29/30 (97%)LINE 4014/4816 
(83%)CONDITIONAL 1962/3142 (62%)

By packages
  
autotests
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 1067/1073 
(99%)CONDITIONAL 677/1293 (52%)
src
FILES 20/21 (95%)CLASSES 20/21 (95%)LINE 2947/3743 
(79%)CONDITIONAL 1285/1849 (69%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[René J . V . Bertin]

> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).
> 
> René J.V. Bertin wrote:
> Just to be clear: if I am going to introduce restore/saveWindowGeometry 
> methods they'll replace the WindowSize variants on OS X or at least those 
> will then use a different KConfig key to avoid conflicts. 
> I'd also be dropping the MS Windows part of the patch (as this is not a 
> decision I want to make for a platform I don't use).
> 
> But please consider this: that KConfig key has been called `geometry` for 
> a long time. Where exactly is the surprise, that restore/saveWindowSize never 
> did what the key they operate with suggests, or that they have always been 
> using an inaptly named key? For me the answer is straightforward and based on 
> what users will expect...
> 
> Martin Gräßlin wrote:
> I leave it to the maintainers. On API I maintain I would say no to 
> something changing the semantics like that.
> 
> René J.V. Bertin wrote:
> As I just wrote in reply to a message from Valorie, I have absolutely no 
> issue with maintaining methods for saving and restoring only window size, for 
> code that somehow requires that. I'd guess that such code would probably 
> enforce the intended window position itself *after* restoring window size 
> (because that operation *can* affect window position), but in the end that's 
> (indeed) up to the code's developers to decide.
> 
> IOW, I'm perfectly willing to discuss a better solution in which the 
> burden to ensure that window save/restore works as "natively" as possible on 
> each platform is shared. The best way to do that is of course to have a 
> single pair of methods that have platform-specific implementations.
> 
> As far as I'm concerned such a solution might even be prepared completely 
> in KConfig/gui before changes are made everywhere else to deploy that new 
> solution. In that case I would for instance run temporary local (MacPorts) 
> patches that replace saveWindowSize/restoreWindowSize with wrappers for 
> saveWindowGeometry/restoreWindowGeometry.
> 
> Side-observation: OS X (Cocoa) provides a `[NSWindow 
> setFrameAutosaveName:]` method, i.e. it avoids reference to specifics like 
> size or geometry completely.
> 
> That method also provides another thought that could be taken into 
> consideration if it is decided to evolve this part of the frameworks, 
> something I'd be interested in collaborating on. Currently, there is no 
> support for saving and restoring multiple windows per application. That may 
> be more or less sufficient when applications always follow a MDI approach, 
> but even if they do that still doesn't make them applications that are active 
> only in a single instance. Example: KDevelop. One might expect that opening a 
> given, pre-existing session (collection of open projects) restores the main 
> window geometry (size and/or position) that used previously for that session, 
> rather than the geometry used by whatever KDevelop session was run last. On 
> OS X that would be done with something like `[NSWindow 
> setFrameautosaveName:[window representedFile]]`, where `[NSWindow 
> representedFile]` corresponds to `QWindow::filePath` (but AFAICS those are 
> not coupled in Qt5).
> 
> I already had a quick look, but realised I don't know if the KConfig 
> mechanism has facilities to handle cleanup of stale/obsolete key/value 
> entries.
> 
> David Faure wrote:
> Note that most apps use this 

Jenkins-kde-ci: karchive master stable-kf5-qt5 » Linux,gcc - Build # 46 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/karchive%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/46/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 05 Jan 2016 08:19:57 +
Build duration: 1 min 11 sec

CHANGE SET
Revision 4b0842b7c68ebd733271a4208c3bfffe35c76898 by David Faure: (autotest: 
ensure we read the full file (to debug a CI failure))
  change: edit autotests/kcompressiondevicetest.cpp
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/karchive%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/47/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 05 Jan 2016 09:00:27 +
Build duration: 1 min 25 sec

CHANGE SET
Revision 77c13da03864bc86715e634523a273a2909b49e1 by David Faure: (fix compiler 
warning/error (gcc and clang disagree on how to write)
  change: edit autotests/kcompressiondevicetest.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 29/30 (97%)CLASSES 29/30 (97%)LINE 4014/4816 
(83%)CONDITIONAL 1962/3142 (62%)

By packages
  
autotests
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 1067/1073 
(99%)CONDITIONAL 677/1293 (52%)
src
FILES 20/21 (95%)CLASSES 20/21 (95%)LINE 2947/3743 
(79%)CONDITIONAL 1285/1849 (69%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/karchive%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/47/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 05 Jan 2016 09:00:27 +
Build duration: 1 min 25 sec

CHANGE SET
Revision 77c13da03864bc86715e634523a273a2909b49e1 by David Faure: (fix compiler 
warning/error (gcc and clang disagree on how to write)
  change: edit autotests/kcompressiondevicetest.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 29/30 (97%)CLASSES 29/30 (97%)LINE 4014/4816 
(83%)CONDITIONAL 1962/3142 (62%)

By packages
  
autotests
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 1067/1073 
(99%)CONDITIONAL 677/1293 (52%)
src
FILES 20/21 (95%)CLASSES 20/21 (95%)LINE 2947/3743 
(79%)CONDITIONAL 1285/1849 (69%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 118909: Imply SkipTaskbar and SkipPager depending on Window Type

[Thomas Lübking]

> On June 23, 2014, 8:08 p.m., Thomas Lübking wrote:
> > What about (non override) utility windows (eg. assume Qt would not set 
> > floating dock override to bring its own titlebar)?
> > While kwin (iirc by default) hides them for inactive windows, that's rather 
> > a feature.
> > 
> > -> By their nature, they should not be in the taskbar. But should they not 
> > appear in pagers?
> 
> Martin Gräßlin wrote:
> > What about (non override) utility windows
> 
> Eike, what's your opinion on that from task manager perspective? Is the 
> nature of a utility window to skip taskbar?
> 
> > But should they not appear in pagers?
> 
> yes, it has the same text: "This hint should be requested by the 
> application, i.e. it indicates that the window by nature is never in the 
> Pager."
> 
> Eike Hein wrote:
> I totally missed this review somehow. I feel like Utility windows should 
> skip, yeah.
> 
> See also plasma-workspace.git c34550cf.
> 
> Can you recheck you still want this? You can get a +1 then.

I guess we all actually agree on skipping the *taskbar*, the question was about 
pagers.
They're distinct hints - so the nature of one does hardly imply the nature of 
the other.

No idea how widely pagers are used, but it would hide eg. the gimp docks and we 
do not enforce them to be on the VD of the image editor (we would not even if 
they were transient...), ie. they'd loose their representation in the pager 
(and you don't know they're over there)


- Thomas


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


On June 23, 2014, 6:50 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118909/
> ---
> 
> (Updated June 23, 2014, 6:50 p.m.)
> 
> 
> Review request for KDE Frameworks, kwin and Eike Hein.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> Imply SkipTaskbar and SkipPager depending on Window Type
> 
> Quoting EWMH:
> "Applications should not set this hint if _NET_WM_WINDOW_TYPE already
> conveys the exact nature of the window."
> 
> This means if the window type implies a SkipPager or SkipTaskbar the
> window will not have it set. To simplify the life of our API users we
> should add the state and not require our users to check that manually.
> 
> Every Normal or Dialog window does not imply that it shouldn't be shown.
> As our KDE Override is not a proper window type we can assume that it's
> also a Normal window or a Dialog.
> 
> The change is done in KWindowInfo and requires that the API user adds
> NET::WMWindowType explicitly to the properties. NETWinInfo is not
> adjusted to have it reflect the actual state of the atoms. Here we can
> assume that the users of the more low-level API are aware of the EWMH
> spec and will implement these checks themselves.
> 
> 
> Diffs
> -
> 
>   autotests/kwindowinfox11test.cpp 50ce806add5ea8f6cb19e537609e936c3d0275bd 
>   src/kwindowinfo.h e9b7a0af66a1e0e0c4e4b84496157dd53035abc8 
>   src/kwindowinfo_x11.cpp 87a887c7e068f71cffc58c184bcd4b4722564047 
> 
> Diff: https://git.reviewboard.kde.org/r/118909/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Jenkins-kde-ci: karchive master kf5-qt5 » Linux,gcc - Build # 47 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/karchive%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/47/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 05 Jan 2016 08:19:57 +
Build duration: 1 min 10 sec

CHANGE SET
Revision 4b0842b7c68ebd733271a4208c3bfffe35c76898 by David Faure: (autotest: 
ensure we read the full file (to debug a CI failure))
  change: edit autotests/kcompressiondevicetest.cpp
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126632: add a "Complementary" color scheme to kcolorscheme

[Aleix Pol Gonzalez]

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


+1 makes sense to me.

- Aleix Pol Gonzalez


On Jan. 5, 2016, 12:16 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126632/
> ---
> 
> (Updated Jan. 5, 2016, 12:16 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kconfigwidgets
> 
> 
> Description
> ---
> 
> Since some releases, plasma-frameworks locally expands kcolorscheme to have a 
> new "Complementary" section: this is done for things like the lockscreen and 
> the logout ui, where the colors are flipped from the current theme.
> A local extension there is kinda unfortunate as makes the color configs files 
> not completely compatible, and I think there is an use case for this in 
> normal applications as well (Gwenview switches to a dark palette when in 
> fullscreen mode for instance)
> Since I want to make the default plasma theme follow the system color scheme, 
> I would need for it to support this "complementary" area as well.
> 
> 
> Diffs
> -
> 
>   src/kcolorscheme.h 22bc21b 
>   src/kcolorscheme.cpp 427ffa4 
> 
> Diff: https://git.reviewboard.kde.org/r/126632/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)

[René J . V . Bertin]

Hi,

I was experimenting with our 2 different approaches to implement this in kate4 
yesterday. Somehow, after implementing KateApp::eventFilter() I kept seeing 
events being delivered to that function after commenting out the corresponding 
installEventFilter() call. That's with a KApplication::eventFilter() function 
in place, but non-virtual so it should be called instead of 
KateApp::eventFilter when that function is not installed.

Have you checked whether `installEventFilter(this)` is redundant?

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

Re: Review Request 126161: OS X housekeeping

[René J . V . Bertin]

> On Dec. 25, 2015, 3:42 p.m., René J.V. Bertin wrote:
> > src/kdeinit/kinit_mac.mm, lines 662-666
> > 
> >
> > I'd love to add `[NSApp activateIgnoringOtherApps:YES]` and/or `[NSApp 
> > unhide]` here, preceded by `[NSApplication sharedApplication]` so that the 
> > spawned `executable` appears in front and not behind the windows of the 
> > "parent" application.
> > 
> > I think that's a very sensible thing to do, but sadly those calls are 
> > part of (or call into) the SDKs that are off-limits between a `fork()` and 
> > an `exec()`.
> > 
> > This really makes me reconsider to use a wrapper, because it quickly 
> > grows old 1) having to wait for an expected application to appear, 2) 
> > realise it must have opened somewhere in the background and 3) go dig it up.
> > 
> > If only I could be sure that the spawned application is NOT supposed to 
> > inherit the environment and other context from kdeinit5. In that case I 
> > could rewrite the command to execute so that it uses LaunchServices ... via 
> > a proxy that's already available (`/usr/bin/open`).
> > 
> > NB: this may well be why `[NSProcessInfo setProcessName:]` doesn't 
> > appear to have the intended effect.
> > 
> > So, David, what's worse here — introducing an additional layer or 
> > putting up with applications that play hide and seek?
> 
> David Faure wrote:
> Starting apps via kdeinit is only an optimization. It's perfectly OK to 
> start apps directly with QProcess instead. So yes, the spawned application is 
> NOT supposed to inherit the environment from kdeinit5.
> 
> As previously stated, I strongly recommend to avoid the whole 
> complication of "stuff I can't do between fork and exec" on OSX, but not 
> using fork and exec at all (wrapper or not), and just starting the other 
> process directly with QProcess. If that doesn't bring the new app to the 
> front, maybe that's a QProcess bug or missing feature? If you think about 
> this as a "pure Qt application developer", such a developer would expect 
> QProcess to be able to start a GUI app and have it pop up to the front. Maybe 
> you can write a small test with QProcess, to check if that works out of the 
> box (maybe all your troubles actually come from the indirection via 
> kdeinit...)
> 
> René J.V. Bertin wrote:
> I will indeed have to have another look at what QProcess does exactly in 
> qprocess_unix, but a priori it looks a variant on the fork+exec scheme. There 
> is support for app bundles, but that works by obtaining the bundle executable 
> and launching it as it if were a regular application.
> 
> The underlying issue is not with Qt, it's something specific to OS X. 
> Maybe there's a reason for it: it could be a cheap way to avoid stealing 
> focus from the "parent" process. The app bundle detection could be used to 
> channel spawning the new process through LaunchServices so that it does open 
> in the foreground, and that could even be extended to cover symlinks that 
> point inside an app bundle (i.e. open `foo.app` instead of 
> `/path/to/foo.app/Contents/MacOS/foo_bundle_exec`). Qt's design choices may 
> make that impossible though: QProcess's implementatin (notably 
> `QProcessPrivate::startProcess()`) is quite complex and if it is supposed to 
> support Posix-style communication between parent and child (including pipes) 
> then LaunchServices is probably out of the question. I don't think there is 
> any such assumption in kdeinit, correct?
> 
> I have to come back a bit on the idea of using `/usr/bin/open` : it tends 
> to use Terminal.app to launch shell scripts and "certain" regular executables 
> ("BSD utilities" in Mac speak). That's evidently not an option. I do have 
> wrapper utilities lying around that I hacked together, I'll see if and how I 
> can refactor relevant code from them into kinit_mac.mm .

FWIW, a contact at Apple just told me "As far as spawning processes in general, 
please don't use system() or fork()/exec().  Please use the posix_spawn syscall 
instead as it is much cleaner and has less overhead."

I'm not exactly familiar with the API. `QProcess` apparently uses it on QNX, 
but that appears to be a slightly different implementation. Anyone here know 
the API?

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/posix_spawn.2.html


- René J.V.


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


On Nov. 26, 2015, 5:20 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126161/
> 

Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)

[Christoph Cullmann]

Hi,

> Hi,
> 
> I was experimenting with our 2 different approaches to implement this in kate4
> yesterday. Somehow, after implementing KateApp::eventFilter() I kept seeing
> events being delivered to that function after commenting out the corresponding
> installEventFilter() call. That's with a KApplication::eventFilter() function
> in place, but non-virtual so it should be called instead of
> KateApp::eventFilter when that function is not installed.
> 
> Have you checked whether `installEventFilter(this)` is redundant?
I think the difference is that in Kate4 KateApp inherits from *Application,
in Kate5 it is just a simple QObject.

Therefore I do there not installEventFilter(this) but installEventFilter(qApp)
and qApp != this.

For 4 I guess it is easiest to implement ::event like e.g described here:

http://www.qtforum.org/article/23098/how-to-make-my-app-open-a-doc-by-dd-or-doubleclick-on-a-mac.html

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: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)

[René J . V . Bertin]

On Tuesday January 05 2016 15:01:08 Christoph Cullmann wrote:

>Therefore I do there not installEventFilter(this) but installEventFilter(qApp)
>and qApp != this.

Right. I must have seen that but not really realised what it implied.

>For 4 I guess it is easiest to implement ::event like e.g described here:
>
>http://www.qtforum.org/article/23098/how-to-make-my-app-open-a-doc-by-dd-or-doubleclick-on-a-mac.html

Ah, thanks. I certainly did not notice ::event(), interesting.

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

Review Request 126639: Enable date format in tickmark.

[Luca Beldi]

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

Review request for KDE Frameworks and David Faure.


Repository: kplotting


Description
---

Using the 'd' char as format it will format the tickmark as a label assuming 
the value is a julian day, see QDate::fromJulianDay and QDate::toJulianDay


Diffs
-

  src/kplotaxis.h 6d40c43 
  src/kplotaxis.cpp e42c9f1 

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


Testing
---

Tested on my own app


Thanks,

Luca Beldi

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

Re: Review Request 126648: Allow to disable KArchive for internal usage

[David Faure]

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

Ship it!



src/xslt_kde.cpp (line 17)


I would suggest to add a qWarning() under this line, to warn at runtime in 
case this is ever called in a non-karchive build.


- David Faure


On Jan. 6, 2016, 12:58 a.m., Luigi Toscano wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126648/
> ---
> 
> (Updated Jan. 6, 2016, 12:58 a.m.)
> 
> 
> Review request for Build System, KDE Frameworks, Alex Merry, and David Faure.
> 
> 
> Repository: kdoctools
> 
> 
> Description
> ---
> 
> Most of the code was already prepared to compile without the KArchive 
> dependency (including the MEINPROC_NO_KARCHIVE flag).
> This mode should be only enabled on KDE infrastructure, as the compressed 
> cache (the only added feature coming from KArchive) is not used by the 
> generator of the documentation website.
> A warning is printed when the mode is enabled.
> The saveToCache function is preserved, even if without code, to minimize the 
> changes required.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 2ec3027 
>   src/CMakeLists.txt 136fbfb 
>   src/xslt_kde.cpp 7069a28 
> 
> Diff: https://git.reviewboard.kde.org/r/126648/diff/
> 
> 
> Testing
> ---
> 
> Normal compilation, compilation with MEINPROC_NO_KARCHIVE=ON
> 
> 
> Thanks,
> 
> Luigi Toscano
> 
>

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

Review Request 126650: [WIP] Add PM/ScreenSaver Inhibition capabilities to KIdleTime

[Martin Klapetek]

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

Review request for KDE Frameworks and Kai Uwe Broulik.


Repository: kidletime


Description
---

This is a work-in-progress, but I'm putting it up for a feedback now
as most people are gone for the day when I wake up :)

---

After some discussion in https://git.reviewboard.kde.org/r/126627/
and then with Kai Uwe Broulik, I've added a PM/ScreenSaver inhibition
capabilities to KIdleItem.

We decided with Kai that we want simple stuff, encapsulated away for
the client as much as possible. So the Inhibition class has a static
"constructors" which make the usage as easy as follows:

KIdleTime::Inhibition::createInhibition(KIdleTime::Inhibition::InhibitScreen, 
QStringLiteral("Playing Movie"), mainWindow);

That call would return an Inhibition* object which has methods to set
the inhibition type and reason and to activate/deactivate the inhibition.
The static method above would activate() on the Inhibition right away;
this allows a simple fire-and-forget usage. The Inhibition object can
be parented to any other object; the inhibition will be deactivated when
the Inhibition object is destroyed. The user can also keep the pointer
around and call deactivate() whenever actually needed.

The inhibition itself first looks for Solid and if present, it uses the
Solid interface. If not present, it goes for the FDO interfaces.

It comes with an autotest.


Diffs
-

  autotests/qtest_dbus.h PRE-CREATION 
  src/CMakeLists.txt 23e5e29 
  autotests/inhibition_test.cpp PRE-CREATION 
  autotests/CMakeLists.txt PRE-CREATION 
  autotests/fakePMServer.h PRE-CREATION 
  src/inhibition.cpp PRE-CREATION 
  src/inhibition.h PRE-CREATION 
  autotests/fakePMServer.cpp PRE-CREATION 
  CMakeLists.txt ed5dc0c 

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


Testing
---

Everything works as expected, plus there's an autotest.


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 126403: Get rid of QApplication dependency

[Albert Astals Cid]

> On gen. 4, 2016, 7:42 a.m., Martin Gräßlin wrote:
> > anyone tested this on an "affected system"?
> 
> Albert Astals Cid wrote:
> I have not, I thought you had made it clear in the past you thought it 
> was a bad idea since it was all supposed to be widget based anyway.
> 
> Thomas Lübking wrote:
> We're trying to resolve this ;-)
> 
> KWindowSystem could otherwise never be used by QGuiApplication's
> As bonus, we can probably unlink Qt6Widgets in "it's certainly not called 
> KF6 - that would be far too simple" :-P
> (I'm not sure whether we can/should that right now - while you should 
> explicitly link stuff you need, we don't live in a should-land)
> 
> => If you can, give it a try (compiz isn't provided by my distro)

I can be your tester if you tell me what to test.


- Albert


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


On gen. 2, 2016, 9:57 a.m., Thomas Lübking wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126403/
> ---
> 
> (Updated gen. 2, 2016, 9:57 a.m.)
> 
> 
> Review request for KDE Frameworks, kwin and Albert Astals Cid.
> 
> 
> Bugs: 354811
> https://bugs.kde.org/show_bug.cgi?id=354811
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> summarized, alternative to https://git.reviewboard.kde.org/r/126397/
> 
> NOTICE: this compiles but is otherwise *completely* untested!
> 
> 
> Diffs
> -
> 
>   src/platforms/xcb/kwindowsystem.cpp 9d28704 
> 
> Diff: https://git.reviewboard.kde.org/r/126403/diff/
> 
> 
> Testing
> ---
> 
> no, not the least. esp. not on the bug.
> 
> 
> Thanks,
> 
> Thomas Lübking
> 
>

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

Re: Review Request 126403: Get rid of QApplication dependency

[Thomas Lübking]

> On Jan. 4, 2016, 7:42 a.m., Martin Gräßlin wrote:
> > anyone tested this on an "affected system"?
> 
> Albert Astals Cid wrote:
> I have not, I thought you had made it clear in the past you thought it 
> was a bad idea since it was all supposed to be widget based anyway.
> 
> Thomas Lübking wrote:
> We're trying to resolve this ;-)
> 
> KWindowSystem could otherwise never be used by QGuiApplication's
> As bonus, we can probably unlink Qt6Widgets in "it's certainly not called 
> KF6 - that would be far too simple" :-P
> (I'm not sure whether we can/should that right now - while you should 
> explicitly link stuff you need, we don't live in a should-land)
> 
> => If you can, give it a try (compiz isn't provided by my distro)
> 
> Albert Astals Cid wrote:
> I can be your tester if you tell me what to test.

Make kscreenlocker_greet crash when using compiz as WM, see bug #354811


- Thomas


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


On Jan. 2, 2016, 9:57 a.m., Thomas Lübking wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126403/
> ---
> 
> (Updated Jan. 2, 2016, 9:57 a.m.)
> 
> 
> Review request for KDE Frameworks, kwin and Albert Astals Cid.
> 
> 
> Bugs: 354811
> https://bugs.kde.org/show_bug.cgi?id=354811
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> summarized, alternative to https://git.reviewboard.kde.org/r/126397/
> 
> NOTICE: this compiles but is otherwise *completely* untested!
> 
> 
> Diffs
> -
> 
>   src/platforms/xcb/kwindowsystem.cpp 9d28704 
> 
> Diff: https://git.reviewboard.kde.org/r/126403/diff/
> 
> 
> Testing
> ---
> 
> no, not the least. esp. not on the bug.
> 
> 
> Thanks,
> 
> Thomas Lübking
> 
>

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

Review Request 126632: add a "Complementary" color scheme to kcolorscheme

[Marco Martin]

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

Review request for KDE Frameworks and Plasma.


Repository: kconfigwidgets


Description
---

Since some releases, plasma-frameworks locally expands kcolorscheme to have a 
new "Complementary" section: this is done for things like the lockscreen and 
the logout ui, where the colors are flipped from the current theme.
A local extension there is kinda unfortunate as makes the color configs files 
not completely compatible, and I think there is an use case for this in normal 
applications as well (Gwenview switches to a dark palette when in fullscreen 
mode for instance)
Since I want to make the default plasma theme follow the system color scheme, I 
would need for it to support this "complementary" area as well.


Diffs
-

  src/kcolorscheme.h 22bc21b 
  src/kcolorscheme.cpp 427ffa4 

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


Testing
---


Thanks,

Marco Martin

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

Re: Review Request 126632: add a "Complementary" color scheme to kcolorscheme

[Marco Martin]

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

(Updated Jan. 5, 2016, 11:16 a.m.)


Review request for KDE Frameworks and Plasma.


Repository: kconfigwidgets


Description
---

Since some releases, plasma-frameworks locally expands kcolorscheme to have a 
new "Complementary" section: this is done for things like the lockscreen and 
the logout ui, where the colors are flipped from the current theme.
A local extension there is kinda unfortunate as makes the color configs files 
not completely compatible, and I think there is an use case for this in normal 
applications as well (Gwenview switches to a dark palette when in fullscreen 
mode for instance)
Since I want to make the default plasma theme follow the system color scheme, I 
would need for it to support this "complementary" area as well.


Diffs (updated)
-

  src/kcolorscheme.h 22bc21b 
  src/kcolorscheme.cpp 427ffa4 

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


Testing
---


Thanks,

Marco Martin

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

Re: QProcess for GUI apps on OSX (Re: closest equivalent to KApplicationPrivate::init() ?)

[René J . V . Bertin]

On Monday January 04 2016 23:14:23 David Faure wrote:

>> Yes, of course. You were hinting at that I start drafting a patch for 
>> QProcess, no? Or do you have a Mac yourself on which to cook one up?
>
>I'm letting you do this, just providing input.

Ok. Going to let this simmer/ferment/mature a bit then.

>My line above is because you asked "what about the requirements?". So I 
>thought we were talking about features and therefore API (not about 
>implementation).

Ultimately the 2 are linked, no? :)

>Ideally I was hoping for something more feature-based like a flag for "GUI 
>app, bring the window to the front if possible".
>Such a flag would make sense for all platforms where a specific call to 
>QProcess is being made.
>But of course it might be that LaunchServices is so different from the posix 
>way that it's really a bigger switch with lots

It's not that it is so different. My gripe is with the use of the word and 
concept GUI. I'm going to have to figure out exactly what GUI aspects are only 
available to app bundles on OS X currently, and to what extent LaunchServices 
can be used to start regular executables without delegating to Terminal.app.

OTOH, I think that NormalLaunch vs. GUILaunch could do it. That leaves the 
nature of the application open, and applies the concept to the launch 
procedure, which is appropriate.
Apologies if this is what you had in mind all along...

>of behaviour differences which cannot be described as a simple feature-based 
>enum. That's unfortunate. Is there any
>chance for a less intrusive solution to make QProcess bring up the window?

The central issue here is the fact that it is near impossible to tell windows 
from another application what to do, on OS X, and to know when it'll listen to 
such instructions (which appears to be required here). The only way I found for 
the calling process to bring the new application to the front involves using 
AppleScript in a way it wasn't really designed to be used. I doubt that would 
ever be acceptable for inclusion into Qt, partly because it can only be a 
polling algorithm, and it requires either invoking an external utility or else 
linking to AppleScript itself.
It's not impossible though that the service being invoked through AppleScript 
("System Events") can also be invoked directly, but I don't think it'd qualify 
as "less intrusive". More like "reinventing the wheel".

>Otherwise I have another idea, calling the flags NormalLaunch (the current 
>behaviour) and DetachedLaunch.

Or GUILaunch, see above?

>If you look at the way krun.cpp uses QProcess, it answers the above: start, 
>waitForStarted(), getting PID with processId(), and notification of exit with 
>exit code
>(among other things, to terminate startup notification). [1]
>This means startDetached is not good enough, btw, I realize now: we need to 
>get notified when the process exits.

That might be tricky. I don't know if LaunchServices provides such a feature or 
if one would need to tap into even lower-level stuff like Mach ports (Mach, not 
Mac ;)). Applications do receive an "about to exit" message though, possibly 
even a "will exit" message (the difference being that you can prevent the exit 
in the former whereas the latter is a notification of impending doom). It's 
possible that Qt already catches that message, in which case it should be 
possible to emit a signal which can then be used in QProcess. 

>Wild idea:
> startDetached(const QString & program, const QStringList & arguments, 
>const QObject * receiver, const char * member,
>const QString & workingDirectory = QString(), 
> qint64 * pid = 0)
>

I've been wondering why startDetached() wouldn't return a QProcess instance. No 
such instance is created internally in the current implementation, but it seems 
it should be possible to do so, and in that case you can leave much of the 
krun.cpp implementation unchanged (connect to the same signal).

BTW, I see krun uses KProcess. I wasn't aware of that class; could we use it as 
a testbed to develop this whole idea before submitting it to Qt? Is there a 
reason KInit doesn't use KProcess -- it already depends on KIo which depends on 
KCoreAddons so it wouldn't mean pulling in new dependencies?


>- a new QGuiProcess class, tailored to starting GUI apps:
>No channel handling.
>Always start detached (i.e. killing current process won't kill secondary 
> gui app).
>And always uses LaunchServices on OSX.
>Maybe all the above is just the reasoning that justifies having a separate 
>class, to avoid having methods that don't apply.

Would QGuiProcess inherit QProcess?
There's the issue with LaunchServices delegating to Terminal.app for certain 
applications, but one could say that's a side-effect users of QGuiProcess will 
have to take into consideration. But then QGuiProcess would probably have to 
inherit QProcess.

>[1] (BTW a notification that the process is all up and ready for 

Re: QProcess for GUI apps on OSX (Re: closest equivalent to KApplicationPrivate::init() ?)

[David Faure]

On Tuesday 05 January 2016 11:58:49 René J.V. Bertin wrote:
> It's not that it is so different. My gripe is with the use of the word and 
> concept GUI. I'm going to have to figure out exactly what GUI aspects are 
> only available to app bundles on OS X currently, and to what extent 
> LaunchServices can be used to start regular executables without delegating to 
> Terminal.app.

Yes. Such additional data would be useful in this decision making process.

> OTOH, I think that NormalLaunch vs. GUILaunch could do it. That leaves the 
> nature of the application open, and applies the concept to the launch 
> procedure, which is appropriate.

OK.

> Apologies if this is what you had in mind all along...

No worries, we're both evolving our thoughts as the discussion progresses.

> >of behaviour differences which cannot be described as a simple feature-based 
> >enum. That's unfortunate. Is there any
> >chance for a less intrusive solution to make QProcess bring up the window?
> 
> The central issue here is the fact that it is near impossible to tell windows 
> from another application what to do, on OS X, and to know when it'll listen 
> to such instructions (which appears to be required here). The only way I 
> found for the calling process to bring the new application to the front 
> involves using AppleScript in a way it wasn't really designed to be used. I 
> doubt that would ever be acceptable for inclusion into Qt, partly because it 
> can only be a polling algorithm, and it requires either invoking an external 
> utility or else linking to AppleScript itself.
> It's not impossible though that the service being invoked through AppleScript 
> ("System Events") can also be invoked directly, but I don't think it'd 
> qualify as "less intrusive". More like "reinventing the wheel".

I'm surprised it's that complex, and that an OSX app cannot launch another one 
and have it appear in front.
Is there no app with an action that starts a calculator, a special-character 
selector, etc.?
Is there no alternative application launcher? ...

Surely there must be a way to do this without polling or scripting.

> >Otherwise I have another idea, calling the flags NormalLaunch (the current 
> >behaviour) and DetachedLaunch.
> 
> Or GUILaunch, see above?

Works for me, but I guess we need more data to know exactly what the flag would 
entail.

> >If you look at the way krun.cpp uses QProcess, it answers the above: start, 
> >waitForStarted(), getting PID with processId(), and notification of exit 
> >with exit code
> >(among other things, to terminate startup notification). [1]
> >This means startDetached is not good enough, btw, I realize now: we need to 
> >get notified when the process exits.
> 
> That might be tricky. I don't know if LaunchServices provides such a feature 
> or if one would need to tap into even lower-level stuff like Mach ports 
> (Mach, not Mac ;)). Applications do receive an "about to exit" message 
> though, possibly even a "will exit" message (the difference being that you 
> can prevent the exit in the former whereas the latter is a notification of 
> impending doom). It's possible that Qt already catches that message, in which 
> case it should be possible to emit a signal which can then be used in 
> QProcess. 

This assumes that such messages can be captured from *another* process (the Qt 
app). From your description, it doesn't sound like that's the case,
if it's a message being sent to the process which is about to exit. 
SIGCHLD is the posix way for a parent process to know that a child process just 
exited, but that's not available for "detached" processes (not children),
and probably not when using LaunchServices either (also not a child).
I doubt QProcess catches anything else at the moment.

> >Wild idea:
> > startDetached(const QString & program, const QStringList & arguments, 
> >const QObject * receiver, const char * member,
> >const QString & workingDirectory = QString(), 
> > qint64 * pid = 0)
> >
> 
> I've been wondering why startDetached() wouldn't return a QProcess instance. 
> No such instance is created internally in the current implementation, but it 
> seems it should be possible to do so

I'm pretty sure it isn't possible to do so because that QProcess instance 
wouldn't be able to emit finished (see above).

> BTW, I see krun uses KProcess. I wasn't aware of that class; could we use it 
> as a testbed to develop this whole idea before submitting it to Qt? Is there 
> a reason KInit doesn't use KProcess -- it already depends on KIo which 
> depends on KCoreAddons so it wouldn't mean pulling in new dependencies?

KProcess is just a subclass (wrapper) with historic API and with the feature of 
launching a command through a shell (which is what KRun uses it for).
It doesn't change anything of the core implementation of the actual handling of 
a child process.
If you want to hack one instead of the other for 

Re: QProcess for GUI apps on OSX (Re: closest equivalent to KApplicationPrivate::init() ?)

[René J . V . Bertin]

On Tuesday January 05 2016 12:55:57 David Faure wrote:

> I'm surprised it's that complex, and that an OSX app cannot launch another 
> one and have it appear in front.
> Is there no app with an action that starts a calculator, a special-character 
> selector, etc.?
> Is there no alternative application launcher? ...

Those would be written using platform-specific (native) APIs, not a middleware 
like Qt. 
It's pretty much a sign that Qt's OS X platform integration layer does a "come 
to the front ignoring anyone else", which is not exactly the preferred way of 
activating oneself.

I'm attaching a hack I wrote a while ago, an alternative to the standard "open" 
utility. It lacks comments, but should be readable enough. It also uses 
deprecated concepts like PSNs, but I presume modern alternatives exists to 
everything used in there. It has a feature to catch termination of the spawned 
application; evidently this is possible since even "open" itself can do so to 
behave as if the GUI application wasn't detached at all.
> This assumes that such messages can be captured from *another* process (the 
> Qt app). From your description, it doesn't sound like that's the case,

See the attachment for a way to do this from within the calling application. 
The alternative would be to let the spawned application send some kind of Qt 
signal to its "parent", but that's probably not as easy as using the native 
mechanism.

BTW, I'm using a very nifty ObjC feature in that code, extension of an existing 
class instead of subclassing it or creating a whole new class.

> SIGCHLD is the posix way for a parent process to know that a child process 
> just exited, but that's not available for "detached" processes (not children),
> and probably not when using LaunchServices either (also not a child).

Indeed.

> If you want to hack one instead of the other for experimentation purposes, 
> why not, but I don't think it will make it any easier to work on the wrapper
> (which has no access to the QProcess internals).

We might not need access to those if we can override certain things from 
QProcess. To be seen in practice; KCoreAddons *is* a lot less overwhelming to 
start hacking around in of course.

> > There's the issue with LaunchServices delegating to Terminal.app for 
> > certain applications, but one could say that's a side-effect users of 
> > QGuiProcess will have to take into consideration.
> 
> That sounds like an expected result of GuiLaunch or QGuiProcess. You ask for 
> a GUI, you start a commandline exe, you get a GUI terminal running that 
> command.

Yes, agreed. I was thinking about code using the class; it'd probably want to 
assess whether a terminal might be fired and use a regular QProcess in that 
case. That would be much easier to implement if QGuiProcess inherits QProcess, 
no?

> It's rather surprising that the events are not queued until the app processes 
> them.

That may just be how AppleScript implements the feature, but it can also be 
that the applications I tried this with (Qt apps...) simply discard events 
until they're all set up.

R.// a very simple utility to that allows to launch OS X applications (app bundles) from a command line
// and lets them appear in the foreground. Contrary to OS X's own open command, it does not treat all
// arguments like they're documents to be opened, and so doesn't impose to pass non-file arguments after
// a --args option. It also removes the need to specify full paths for the files to be opened for
// certain applications (KDE app bundles for instance).

#import 
#import 
#import 
#import 
#import 
#import 

// from http://stackoverflow.com/a/4933492

@interface NSWorkspace (MDAdditions)
- (pid_t) launchApplicationAtPath:(NSString *)path
withArguments:(NSArray *)argv
 waitFinished:(BOOL)wait
		psn:(ProcessSerialNumber*)psn
	   error:(NSError **)error;
- (void) appTerminated:(NSNotification*)note;
@end

#import 

@interface NSString (MDAdditions)
- (BOOL) getFSRef:(FSRef *)anFSRef error:(NSError **)anError;
@end

#import 

@implementation NSString (MDAdditions)

- (BOOL) getFSRef:(FSRef *)anFSRef error:(NSError **)anError
{
	if( anError ){
		*anError = nil;
	}
	OSStatus status = noErr;
	status = FSPathMakeRef( (const UInt8 *)[self UTF8String], anFSRef, NULL );
	if( status != noErr ){
		if( anError ){
			*anError = [NSError errorWithDomain:NSOSStatusErrorDomain code:status userInfo:nil];
		}
	}
	return (status == noErr);
}
@end

static dispatch_semaphore_t sema;
static pid_t waitPID;

@implementation NSWorkspace (MDAdditions)

- (void)appTerminated:(NSNotification *)note
{
// 	NSLog(@"terminated %@\n", [[note userInfo] objectForKey:@"NSApplicationProcessIdentifier"]);
	if( [[[note userInfo] objectForKey:@"NSApplicationProcessIdentifier"] unsignedLongLongValue] == (unsigned long long) waitPID ){
		dispatch_semaphore_signal(sema);
	}
}

- (pid_t) launchApplicationAtPath:(NSString *)path withArguments:(NSArray *)argv
 waitFinished:(BOOL)wait
	

Review Request 126648: Allow to disable KArchive for internal usage

[Luigi Toscano]

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

Review request for Build System, KDE Frameworks and Alex Merry.


Repository: kdoctools


Description
---

Most of the code was already prepared to compile without the KArchive 
dependency (including the MEINPROC_NO_KARCHIVE flag).
This mode should be only enabled on KDE infrastructure, as the compressed cache 
(the only added feature coming from KArchive) is not used by the generator of 
the documentation website.
A warning is printed when the mode is enabled.
The saveToCache function is preserved, even if without code, to minimize the 
changes required.


Diffs
-

  CMakeLists.txt 2ec3027 
  src/CMakeLists.txt 136fbfb 
  src/xslt_kde.cpp 7069a28 

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


Testing
---

Normal compilation, compilation with MEINPROC_NO_KARCHIVE=ON


Thanks,

Luigi Toscano

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

Re: Review Request 126403: Get rid of QApplication dependency

[Albert Astals Cid]

> On gen. 4, 2016, 7:42 a.m., Martin Gräßlin wrote:
> > anyone tested this on an "affected system"?
> 
> Albert Astals Cid wrote:
> I have not, I thought you had made it clear in the past you thought it 
> was a bad idea since it was all supposed to be widget based anyway.
> 
> Thomas Lübking wrote:
> We're trying to resolve this ;-)
> 
> KWindowSystem could otherwise never be used by QGuiApplication's
> As bonus, we can probably unlink Qt6Widgets in "it's certainly not called 
> KF6 - that would be far too simple" :-P
> (I'm not sure whether we can/should that right now - while you should 
> explicitly link stuff you need, we don't live in a should-land)
> 
> => If you can, give it a try (compiz isn't provided by my distro)
> 
> Albert Astals Cid wrote:
> I can be your tester if you tell me what to test.
> 
> Thomas Lübking wrote:
> Make kscreenlocker_greet crash when using compiz as WM, see bug #354811

Running /usr/lib/x86_64-linux-gnu/libexec/kscreenlocker_greet on Ubuntu Xenial 
under Unity7 crashes before applying this patch to kwindowsystem and seems to 
work fine after applying the patch.


- Albert


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


On gen. 2, 2016, 9:57 a.m., Thomas Lübking wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126403/
> ---
> 
> (Updated gen. 2, 2016, 9:57 a.m.)
> 
> 
> Review request for KDE Frameworks, kwin and Albert Astals Cid.
> 
> 
> Bugs: 354811
> https://bugs.kde.org/show_bug.cgi?id=354811
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> summarized, alternative to https://git.reviewboard.kde.org/r/126397/
> 
> NOTICE: this compiles but is otherwise *completely* untested!
> 
> 
> Diffs
> -
> 
>   src/platforms/xcb/kwindowsystem.cpp 9d28704 
> 
> Diff: https://git.reviewboard.kde.org/r/126403/diff/
> 
> 
> Testing
> ---
> 
> no, not the least. esp. not on the bug.
> 
> 
> Thanks,
> 
> Thomas Lübking
> 
>

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

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

[Martin Gräßlin]

> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).
> 
> René J.V. Bertin wrote:
> Just to be clear: if I am going to introduce restore/saveWindowGeometry 
> methods they'll replace the WindowSize variants on OS X or at least those 
> will then use a different KConfig key to avoid conflicts. 
> I'd also be dropping the MS Windows part of the patch (as this is not a 
> decision I want to make for a platform I don't use).
> 
> But please consider this: that KConfig key has been called `geometry` for 
> a long time. Where exactly is the surprise, that restore/saveWindowSize never 
> did what the key they operate with suggests, or that they have always been 
> using an inaptly named key? For me the answer is straightforward and based on 
> what users will expect...
> 
> Martin Gräßlin wrote:
> I leave it to the maintainers. On API I maintain I would say no to 
> something changing the semantics like that.
> 
> René J.V. Bertin wrote:
> As I just wrote in reply to a message from Valorie, I have absolutely no 
> issue with maintaining methods for saving and restoring only window size, for 
> code that somehow requires that. I'd guess that such code would probably 
> enforce the intended window position itself *after* restoring window size 
> (because that operation *can* affect window position), but in the end that's 
> (indeed) up to the code's developers to decide.
> 
> IOW, I'm perfectly willing to discuss a better solution in which the 
> burden to ensure that window save/restore works as "natively" as possible on 
> each platform is shared. The best way to do that is of course to have a 
> single pair of methods that have platform-specific implementations.
> 
> As far as I'm concerned such a solution might even be prepared completely 
> in KConfig/gui before changes are made everywhere else to deploy that new 
> solution. In that case I would for instance run temporary local (MacPorts) 
> patches that replace saveWindowSize/restoreWindowSize with wrappers for 
> saveWindowGeometry/restoreWindowGeometry.
> 
> Side-observation: OS X (Cocoa) provides a `[NSWindow 
> setFrameAutosaveName:]` method, i.e. it avoids reference to specifics like 
> size or geometry completely.
> 
> That method also provides another thought that could be taken into 
> consideration if it is decided to evolve this part of the frameworks, 
> something I'd be interested in collaborating on. Currently, there is no 
> support for saving and restoring multiple windows per application. That may 
> be more or less sufficient when applications always follow a MDI approach, 
> but even if they do that still doesn't make them applications that are active 
> only in a single instance. Example: KDevelop. One might expect that opening a 
> given, pre-existing session (collection of open projects) restores the main 
> window geometry (size and/or position) that used previously for that session, 
> rather than the geometry used by whatever KDevelop session was run last. On 
> OS X that would be done with something like `[NSWindow 
> setFrameautosaveName:[window representedFile]]`, where `[NSWindow 
> representedFile]` corresponds to `QWindow::filePath` (but AFAICS those are 
> not coupled in Qt5).
> 
> I already had a quick look, but realised I don't know if the KConfig 
> mechanism has facilities to handle cleanup of stale/obsolete key/value 
> entries.
> 
> David Faure wrote:
> Note that most apps use this 

Re: Review Request 126620: Fixed most of level 1 and level 2 warnings

[Artur Puzio]

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

(Updated Jan. 5, 2016, 12:21 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Aleix Pol Gonzalez.


Changes
---

Submitted with commit 5568d780b22e9b247ff2721346f3f380ab2c2a1d by Aleix Pol on 
behalf of Artur Puzio to branch master.


Repository: kparts


Description
---

Fixed `warning: QString* being called 
[-Wclazy-qstring-uneeded-heap-allocations]` by changing to `QStringLiteral`-s.
In `plugin.cpp:96` I haven't fixed the warnings, becouse `QStringLiteral` would 
give an error. I applied my own optimisation instead.
Fixed `warning: Don't call QList::first() on temporary 
[-Wclazy-detaching-temporary]` by changeing to `at(0)`
Fixed `warning: Reserve candidate [-Wclazy-reserve-candidates]` by adding a 
simple `reserve`
Fixed `warning: Old Style Connect [-Wclazy-old-style-connect]` I had to change 
all of them by hand, becouse of a bug in clazy that I will be reporting. I 
wasn't able to change 4 Old Style Connects. (3 in `kreadonlypart.cpp`, 1 in 
`readwritepart.cpp`)
Fixed `warning: KParts::BrowserOpenOrSaveQuestion has dtor but not copy-ctor, 
copy-assignment [-Wclazy-rule-of-three]`, by adding `Q_DISABLE_COPY`, becouse 
`BrowserOpenOrSaveQuestionPrivate` isn't copyable
Only warnings that I left are the `[-Wclazy-function-args-by-ref]` warnings, 
becouse they would involve modifying headers.


Diffs
-

  src/browserextension.cpp 4b7252c 
  src/browseropenorsavequestion.h 85dcfa0 
  src/browseropenorsavequestion.cpp c1425c1 
  src/browserrun.cpp 4756511 
  src/browserrun_p.h 4742598 
  src/mainwindow.cpp 9b0c3c5 
  src/part.cpp 1657561 
  src/partmanager.cpp 81bf73f 
  src/plugin.cpp 97f7d28 
  src/scriptableextension.cpp 27676bc 

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


Testing
---

Automated tests pass.
Imported note: On my computer I'm runing versions 5.17.0 and it wasn't possible 
for me to upgrade easly, so I changed the CMakeFiles.txt to compile it. (of 
course the changed isn't included in this RR)


Thanks,

Artur Puzio

___
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,NoX11,gcc - Build # 218 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20kf5-qt5/PLATFORM=Linux,Variation=NoX11,compiler=gcc/218/
Project: PLATFORM=Linux,Variation=NoX11,compiler=gcc
Date of build: Tue, 05 Jan 2016 12:00:49 +
Build duration: 2 min 34 sec

CHANGE SET
Revision 3992593f31681254fb5fa9bafcaa47e18fc19421 by Martin Klapetek: 
([scriptengine/qml] Allow applets to set full ToolTip item)
  change: edit src/scriptengines/qml/plasmoid/appletinterface.h
  change: edit src/scriptengines/qml/plasmoid/appletinterface.cpp
Revision c532ca8ff74cd99d818024611937794d13daa8ef by Marco Martin: 
(paintedWidth/paintedheight for IconItem)
  change: edit src/declarativeimports/core/iconitem.h
  change: edit src/declarativeimports/core/iconitem.cpp
Revision 4ac969d5f1f0a6a3a5cf4b616a61fbeb635b8a28 by Marco Martin: (the button 
is compose-over-borders)
  change: edit src/desktoptheme/breeze/widgets/button.svgz
Revision 7301bcf42fe17aabe1bae33cd6f0b4e11f042405 by Marco Martin: (fix 
compressed file)
  change: edit src/desktoptheme/breeze/icons/battery.svgz
Revision 5af3ed10d98f4e65c4a056e99705b04d81d19ea7 by Marco Martin: (blue border 
in the active task)
  change: edit src/desktoptheme/breeze/widgets/tasks.svgz


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 5/7 (71%)FILES 58/100 (58%)CLASSES 58/100 (58%)LINE 3435/9624 
(36%)CONDITIONAL 1640/2650 (62%)

By packages
  
autotests
FILES 18/18 (100%)CLASSES 18/18 (100%)LINE 502/517 
(97%)CONDITIONAL 328/586 (56%)
src.declarativeimports.core
FILES 7/20 (35%)CLASSES 7/20 (35%)LINE 272/1831 
(15%)CONDITIONAL 66/112 (59%)
src.plasma
FILES 14/21 (67%)CLASSES 14/21 (67%)LINE 1584/3650 
(43%)CONDITIONAL 790/1220 (65%)
src.plasma.private
FILES 15/24 (63%)CLASSES 15/24 (63%)LINE 843/1677 
(50%)CONDITIONAL 356/544 (65%)
src.plasma.scripting
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/182 (0%)CONDITIONAL 0/0 
(100%)
src.plasmaquick
FILES 4/11 (36%)CLASSES 4/11 (36%)LINE 234/1654 
(14%)CONDITIONAL 100/188 (53%)
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

Jenkins-kde-ci: plasma-framework master kf5-qt5 » Linux,NoX11,gcc - Build # 218 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20kf5-qt5/PLATFORM=Linux,Variation=NoX11,compiler=gcc/218/
Project: PLATFORM=Linux,Variation=NoX11,compiler=gcc
Date of build: Tue, 05 Jan 2016 12:00:49 +
Build duration: 2 min 34 sec

CHANGE SET
Revision 3992593f31681254fb5fa9bafcaa47e18fc19421 by Martin Klapetek: 
([scriptengine/qml] Allow applets to set full ToolTip item)
  change: edit src/scriptengines/qml/plasmoid/appletinterface.h
  change: edit src/scriptengines/qml/plasmoid/appletinterface.cpp
Revision c532ca8ff74cd99d818024611937794d13daa8ef by Marco Martin: 
(paintedWidth/paintedheight for IconItem)
  change: edit src/declarativeimports/core/iconitem.h
  change: edit src/declarativeimports/core/iconitem.cpp
Revision 4ac969d5f1f0a6a3a5cf4b616a61fbeb635b8a28 by Marco Martin: (the button 
is compose-over-borders)
  change: edit src/desktoptheme/breeze/widgets/button.svgz
Revision 7301bcf42fe17aabe1bae33cd6f0b4e11f042405 by Marco Martin: (fix 
compressed file)
  change: edit src/desktoptheme/breeze/icons/battery.svgz
Revision 5af3ed10d98f4e65c4a056e99705b04d81d19ea7 by Marco Martin: (blue border 
in the active task)
  change: edit src/desktoptheme/breeze/widgets/tasks.svgz


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 5/7 (71%)FILES 58/100 (58%)CLASSES 58/100 (58%)LINE 3435/9624 
(36%)CONDITIONAL 1640/2650 (62%)

By packages
  
autotests
FILES 18/18 (100%)CLASSES 18/18 (100%)LINE 502/517 
(97%)CONDITIONAL 328/586 (56%)
src.declarativeimports.core
FILES 7/20 (35%)CLASSES 7/20 (35%)LINE 272/1831 
(15%)CONDITIONAL 66/112 (59%)
src.plasma
FILES 14/21 (67%)CLASSES 14/21 (67%)LINE 1584/3650 
(43%)CONDITIONAL 790/1220 (65%)
src.plasma.private
FILES 15/24 (63%)CLASSES 15/24 (63%)LINE 843/1677 
(50%)CONDITIONAL 356/544 (65%)
src.plasma.scripting
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/182 (0%)CONDITIONAL 0/0 
(100%)
src.plasmaquick
FILES 4/11 (36%)CLASSES 4/11 (36%)LINE 234/1654 
(14%)CONDITIONAL 100/188 (53%)
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