Re: Review Request 126506: Fix improper destruction of non-virtual KDirModel subclasses

2015-12-25 Thread David Faure 


> On Dec. 25, 2015, 1:58 a.m., Aleix Pol Gonzalez wrote:
> > If making the destructor virtual doesn't break ABI, I'd vote for that...

The node classes are internal, so this wouldn't break ABI indeed.

Hmm, right, this would make "delete node" work everywhere. Michael's fix misses 
the other place where a node is deleted:

2 * delete dirNode->m_childNodes.takeAt(r); in 
KDirModelPrivate::_k_slotDeleteItems
1 * in KDirModelPrivate::_k_slotRefreshItems

You're right, I withdraw my Ship It, we need a virtual dtor instead.


- David


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


On Dec. 25, 2015, 12:12 a.m., Michael Pyne wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126506/
> ---
> 
> (Updated Dec. 25, 2015, 12:12 a.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Noted by Coverity (CID 1019869), and could result in a set of
> partially-destructed objects. Which, in this case, would probably leak
> memory in the event of multiple levels of filesystem hierarchy from the
> root KDirModel, but wouldn't cause any worse problems than that.
> 
> The 'proper' fix would be to add a virtual dtor at the base class but I
> didn't want to add a vtable just for this, so I mirrored the rest of the
> code and utilized the fact that item().isDir() is true for all derived
> classes.
> 
> 
> Diffs
> -
> 
>   src/widgets/kdirmodel.cpp af56a06 
> 
> Diff: https://git.reviewboard.kde.org/r/126506/diff/
> 
> 
> Testing
> ---
> 
> Builds, kdirmodeltest passes.
> 
> 
> Thanks,
> 
> Michael Pyne
> 
>

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

Re: Review Request 126506: Fix improper destruction of non-virtual KDirModel subclasses

2015-12-25 Thread David Faure 


> On Dec. 25, 2015, 9:14 a.m., David Faure wrote:
> > Ship It!

withdrawn, see above


- David


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


On Dec. 25, 2015, 12:12 a.m., Michael Pyne wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126506/
> ---
> 
> (Updated Dec. 25, 2015, 12:12 a.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Noted by Coverity (CID 1019869), and could result in a set of
> partially-destructed objects. Which, in this case, would probably leak
> memory in the event of multiple levels of filesystem hierarchy from the
> root KDirModel, but wouldn't cause any worse problems than that.
> 
> The 'proper' fix would be to add a virtual dtor at the base class but I
> didn't want to add a vtable just for this, so I mirrored the rest of the
> code and utilized the fact that item().isDir() is true for all derived
> classes.
> 
> 
> Diffs
> -
> 
>   src/widgets/kdirmodel.cpp af56a06 
> 
> Diff: https://git.reviewboard.kde.org/r/126506/diff/
> 
> 
> Testing
> ---
> 
> Builds, kdirmodeltest passes.
> 
> 
> Thanks,
> 
> Michael Pyne
> 
>

___
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)

2015-12-25 Thread David Faure 


> On Dec. 17, 2015, 4: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 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

2015-12-25 Thread René J . V . Bertin 


> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> >
> 
> Jaime Torres Amate wrote:
> Hello,
> 
>   This is just a warning to know if this patch has been tested in a two 
> monitor environment in a laptop.
>   In a pyqt application I save and restore the size and position of the 
> window (without additional checks), using:
> settings.setValue("size", self.ui.size())
> settings.setValue("pos", self.ui.pos())   # save
> 
> self.ui.resize(settings.value("size", QSize(400, 400)))
> self.ui.move(settings.value("pos", QPoint(200, 200)))   # restore
>  
>   It works perfectly fine except in this case:
>The window, when saved, was in a monitor that disappears in the next 
> run. In the next run (without the monitor) the window is not shown, because 
> it is still in the other monitor, but it is shown in the taskbar, I have to 
> go to the taskbar or with an advanced task manager, tell the window to become 
> maximized, then it is shown.
>   If this patch shows the window when the monitor disappears, then, 
> please, ignore this comment.

What OS/windowing environment is that?

To the best of my knowledge, OS X will rearrange windows when a monitor is 
disconnected (regardless whether on a laptop or desktop host) and should do the 
same when reopening a window in an offscreen position if that window isn't 
meant to be offscreen. I haven't yet tested this because of the rearranging 
thing, but good point. I'll see if it can be simulated by storing an offscreen 
position (this is where the binary nature of the saved data is annoying indeed!)


- René J.V.


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


On Dec. 14, 2015, 5:04 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126324/
> ---
> 
> (Updated Dec. 14, 2015, 5:04 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> In KDElibs4, the KMainWindow::saveWindowSize() and 
> KMainWindow::restoreWindowSize() function saved and restored not only the 
> size but also the position (i.e. the geometry) of windows, using 
> QWidget::saveGeometry and QWidget::restoreGeometry.
> 
> 2 main reasons for this (according to the comments):
> - Under X11 restoring the position is tricky
> - X11 has a window manager which might be considered responsible for that 
> functionality (and I suppose most modern WMs have the feature enabled by 
> default?)
> 
> Both arguments are moot on MS Windows and OS X, and on both platforms users 
> expect to see window positions restored as well as window size. On OS X there 
> is also little choice in the matter: most applications offer the geometry 
> restore without asking (IIRC it is the same on MS Windows).
> 
> I would thus like to propose to port the platform-specific code that existed 
> for MS Windows (and for OS X as a MacPorts patch that apparently was never 
> submitted upstreams). I realise that this violates the message conveyed by 
> the function names but I would like to think that this is a case where 
> function is more important.
> 
> You may also notice that the Mac version does not store resolution-specific 
> settings. This happens to work best on OS X, where multi-screen support has 
> been present since the early nineties, and where window geometry is restored 
> regardless of the screen resolution (i.e. connect a different external screen 
> with a different resolution, and windows will reopen as they were on that 
> screen, not with some default geometry).
> I required I can update the comments in the header to reflect this subtlety.
> 
> Note that for optimal functionality a companion patch to `KMainWindow::event` 
> is required:
> ```
> --- a/src/kmainwindow.cpp
> +++ b/src/kmainwindow.cpp
> @@ -772,7 +772,7 @@ bool KMainWindow::event(QEvent *ev)
>  {
>  K_D(KMainWindow);
>  switch (ev->type()) {
> -#ifdef Q_OS_WIN
> +#if defined(Q_OS_WIN) || defined(Q_OS_OSX)
>  case QEvent::Move:
>  #endif
>  case QEvent::Resize:
> ```
> 
> This ensures that the window geometry save is performed also after a move (to 
> update the position) without requiring a dummy resizing operation.
> Do I need to create a separate RR for this change or is it small enough that 
> I can push it if and when this RR is accepted?
> 
> 
> Diffs
> -
> 
>   src/gui/kwindowconfig.h 48a8f3c 
>   src/gui/kwindowconfig.cpp d2f355c 
> 
> Diff: https://git.reviewboard.kde.org/r/126324/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.6 through 10.9 with various KDElibs4 versions

Review Request 126516: Add StatusNotifier flag

2015-12-25 Thread Kai Uwe Broulik 

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

Review request for KDE Frameworks.


Repository: kcrash


Description
---

This adds a StatusNotifier flag that starts DrKonqi with the --passive argument 
introduced in Review 126515


Diffs
-

  src/kcrash.cpp 7d3b8a2 
  src/kcrash.h e2b59f2 

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


Testing
---

Works.


Thanks,

Kai Uwe Broulik

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

Review Request 126515: [DrKonqi] RFC: Support showing a StatusNotifierItem instead of bringing up the dialog right away

2015-12-25 Thread Kai Uwe Broulik 

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

Review request for KDE Frameworks, Plasma, KDE Usability, and Martin Gräßlin.


Repository: plasma-workspace


Description
---

This adds a new "--passive" option to DrKonqi where it will only show a 
StatusNotifierItem rather than bringing up the crash dialog right away.

This can be useful for auto-restarting shell services (like plasmashell, 
krunner, kded) to improve the perceived quality of the product.

On Windows RT, for example, the guidelines even explicitly say "rather just 
dump the user on the home screen than telling him something went wrong, so he 
can just quickly start the app again instead of being annoyed by an error 
message". On iOS you also just get dropped on the home screen. Windows desktop 
shows a "Searching for a solution" dialog which was *the* major annoyance when 
something crashed, rather than the actual crash.

Video here: https://www.youtube.com/watch?v=t0ZLs-juYKc


Diffs
-

  drkonqi/statusnotifier.cpp PRE-CREATION 
  drkonqi/statusnotifier.h PRE-CREATION 
  drkonqi/CMakeLists.txt eaeaad4 
  drkonqi/main.cpp 7cbaae7 

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


Testing
---

I crashed plasmashell, it restarted so fast that you didn't even have a black 
screen inbetween, just the panel restarting. Afterwards I got a SNI which 
opened DrKonqi when tapped.

The SNI disappears after 1 minute because if you didn't bother to look after it 
by then, you probably forgot what you did to cause the crash anyway :)


Thanks,

Kai Uwe Broulik

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

Re: klauncher & .desktop Execs

2015-12-25 Thread René J . V . Bertin 
On Friday December 25 2015 09:57:05 David Faure wrote:
> On Tuesday 22 December 2015 11:33:53 René J.V. Bertin 

Bouncing this to the list.

> > Looking at `ps` output klauncher shows up as kcmshell5's parent process, 
> > does that mean we're looking at KLauncher::requestStart using 
> > QProcess::start() ?
> 
> On OSX, yes, probably.

You wouldn't happen to know the reason by any chance? 

> (on Linux klauncher asks kinit to fork+dlopen or fork+exec).

With the proper changes (still assessing them) that should work on OS X too, 
no? With the USE_KPROCESS_FOR_KIOSLAVES/QProcess::start I had to jump to a 
number of hoops and resort to calling the commandline AppleScript interpreter 
(osascript) to ensure that the launched process is started in front of the 
calling process. Not easy, as AppleScript isn't really designed for this so I 
also had to subclass QProcess to launch osascript in detached fashion and set a 
kill timer to get rid of it should it not complete within a reasonable time. 
Since kinit will use ObjC++ in my proposed patch it should be possible to 
achieve the same thing (process opens in front) directly using an appropriate 
API (AppKit).

I'll queue testing this on my todolist.

R.
___
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)

2015-12-25 Thread 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

Re: Review Request 126515: [DrKonqi] RFC: Support showing a StatusNotifierItem instead of bringing up the dialog right away

2015-12-25 Thread Kai Uwe Broulik 

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


Usability: I envisioned this to be used for auto-restarting shell services and 
not to be used by applications.
Another interesting thought could be enabling this by default for all 
applications but for regular applications trigger a desktop notification (with 
report bug / restart app) together with the tray icon.

Mockup: http://wstaw.org/m/2015/12/25/drkonqipassive.png

- Kai Uwe Broulik


On Dez. 25, 2015, 4:24 nachm., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126515/
> ---
> 
> (Updated Dez. 25, 2015, 4:24 nachm.)
> 
> 
> Review request for KDE Frameworks, Plasma, KDE Usability, and Martin Gräßlin.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This adds a new "--passive" option to DrKonqi where it will only show a 
> StatusNotifierItem rather than bringing up the crash dialog right away.
> 
> This can be useful for auto-restarting shell services (like plasmashell, 
> krunner, kded) to improve the perceived quality of the product.
> 
> On Windows RT, for example, the guidelines even explicitly say "rather just 
> dump the user on the home screen than telling him something went wrong, so he 
> can just quickly start the app again instead of being annoyed by an error 
> message". On iOS you also just get dropped on the home screen. Windows 
> desktop shows a "Searching for a solution" dialog which was *the* major 
> annoyance when something crashed, rather than the actual crash.
> 
> Video here: https://www.youtube.com/watch?v=t0ZLs-juYKc
> 
> 
> Diffs
> -
> 
>   drkonqi/statusnotifier.cpp PRE-CREATION 
>   drkonqi/statusnotifier.h PRE-CREATION 
>   drkonqi/CMakeLists.txt eaeaad4 
>   drkonqi/main.cpp 7cbaae7 
> 
> Diff: https://git.reviewboard.kde.org/r/126515/diff/
> 
> 
> Testing
> ---
> 
> I crashed plasmashell, it restarted so fast that you didn't even have a black 
> screen inbetween, just the panel restarting. Afterwards I got a SNI which 
> opened DrKonqi when tapped.
> 
> The SNI disappears after 1 minute because if you didn't bother to look after 
> it by then, you probably forgot what you did to cause the crash anyway :)
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
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)

2015-12-25 Thread René J . V . Bertin 


> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> >
> 
> Jaime Torres Amate wrote:
> Hello,
> 
>   This is just a warning to know if this patch has been tested in a two 
> monitor environment in a laptop.
>   In a pyqt application I save and restore the size and position of the 
> window (without additional checks), using:
> settings.setValue("size", self.ui.size())
> settings.setValue("pos", self.ui.pos())   # save
> 
> self.ui.resize(settings.value("size", QSize(400, 400)))
> self.ui.move(settings.value("pos", QPoint(200, 200)))   # restore
>  
>   It works perfectly fine except in this case:
>The window, when saved, was in a monitor that disappears in the next 
> run. In the next run (without the monitor) the window is not shown, because 
> it is still in the other monitor, but it is shown in the taskbar, I have to 
> go to the taskbar or with an advanced task manager, tell the window to become 
> maximized, then it is shown.
>   If this patch shows the window when the monitor disappears, then, 
> please, ignore this comment.
> 
> René J.V. Bertin wrote:
> What OS/windowing environment is that?
> 
> To the best of my knowledge, OS X will rearrange windows when a monitor 
> is disconnected (regardless whether on a laptop or desktop host) and should 
> do the same when reopening a window in an offscreen position if that window 
> isn't meant to be offscreen. I haven't yet tested this because of the 
> rearranging thing, but good point. I'll see if it can be simulated by storing 
> an offscreen position (this is where the binary nature of the saved data is 
> annoying indeed!)
> 
> Jaime Torres Amate wrote:
> Oh!, I'm sorry, I forgot to say. It is a windows 7. It rearranges other 
> windows, but as it's position is restored, it goes to the non connected 
> monitor. I hope it does not happen with this patch (In linux it does not 
> happen to that pyqt program).

Even if it doesn't on OS X, someone will have to test on MS Windows.

I presume one can obtain the limits within which the position has to lie and 
constrain the position so that at least part of the window is visible (even if 
those limits reflect only the rectangle within which the available screens lie).


- René J.V.


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


On Dec. 14, 2015, 5:04 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126324/
> ---
> 
> (Updated Dec. 14, 2015, 5:04 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> In KDElibs4, the KMainWindow::saveWindowSize() and 
> KMainWindow::restoreWindowSize() function saved and restored not only the 
> size but also the position (i.e. the geometry) of windows, using 
> QWidget::saveGeometry and QWidget::restoreGeometry.
> 
> 2 main reasons for this (according to the comments):
> - Under X11 restoring the position is tricky
> - X11 has a window manager which might be considered responsible for that 
> functionality (and I suppose most modern WMs have the feature enabled by 
> default?)
> 
> Both arguments are moot on MS Windows and OS X, and on both platforms users 
> expect to see window positions restored as well as window size. On OS X there 
> is also little choice in the matter: most applications offer the geometry 
> restore without asking (IIRC it is the same on MS Windows).
> 
> I would thus like to propose to port the platform-specific code that existed 
> for MS Windows (and for OS X as a MacPorts patch that apparently was never 
> submitted upstreams). I realise that this violates the message conveyed by 
> the function names but I would like to think that this is a case where 
> function is more important.
> 
> You may also notice that the Mac version does not store resolution-specific 
> settings. This happens to work best on OS X, where multi-screen support has 
> been present since the early nineties, and where window geometry is restored 
> regardless of the screen resolution (i.e. connect a different external screen 
> with a different resolution, and windows will reopen as they were on that 
> screen, not with some default geometry).
> I required I can update the comments in the header to reflect this subtlety.
> 
> Note that for optimal functionality a companion patch to `KMainWindow::event` 
> is required:
> ```
> --- a/src/kmainwindow.cpp
> +++ b/src/kmainwindow.cpp
> @@ -772,7 +772,7 @@ bool KMainWindow::event(QEvent *ev)
>  {
>  K_D(KMainWindow);
>  switch (ev->type()) {
>

Re: Review Request 126515: [DrKonqi] RFC: Support showing a StatusNotifierItem instead of bringing up the dialog right away

2015-12-25 Thread David Edmundson 

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


code looks fine.

Though please do the TODOs before merging as historically we have a have a 
habbit of them not getting done
Also your StatusNotifierItem leaks  - but it proably wants to be the lifespan 
of the application anyway.

- David Edmundson


On Dec. 25, 2015, 4:24 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126515/
> ---
> 
> (Updated Dec. 25, 2015, 4:24 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma, KDE Usability, and Martin Gräßlin.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This adds a new "--passive" option to DrKonqi where it will only show a 
> StatusNotifierItem rather than bringing up the crash dialog right away.
> 
> This can be useful for auto-restarting shell services (like plasmashell, 
> krunner, kded) to improve the perceived quality of the product.
> 
> On Windows RT, for example, the guidelines even explicitly say "rather just 
> dump the user on the home screen than telling him something went wrong, so he 
> can just quickly start the app again instead of being annoyed by an error 
> message". On iOS you also just get dropped on the home screen. Windows 
> desktop shows a "Searching for a solution" dialog which was *the* major 
> annoyance when something crashed, rather than the actual crash.
> 
> Video here: https://www.youtube.com/watch?v=t0ZLs-juYKc
> 
> 
> Diffs
> -
> 
>   drkonqi/statusnotifier.cpp PRE-CREATION 
>   drkonqi/statusnotifier.h PRE-CREATION 
>   drkonqi/CMakeLists.txt eaeaad4 
>   drkonqi/main.cpp 7cbaae7 
> 
> Diff: https://git.reviewboard.kde.org/r/126515/diff/
> 
> 
> Testing
> ---
> 
> I crashed plasmashell, it restarted so fast that you didn't even have a black 
> screen inbetween, just the panel restarting. Afterwards I got a SNI which 
> opened DrKonqi when tapped.
> 
> The SNI disappears after 1 minute because if you didn't bother to look after 
> it by then, you probably forgot what you did to cause the crash anyway :)
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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

Re: klauncher & .desktop Execs

2015-12-25 Thread René J . V . Bertin 
On Friday December 25 2015 18:03:47 René J.V. Bertin wrote:

>So what I'd like to do as a last test is this:
>- leave the mechanism by which klauncher is started alone, as well as a few 
>others (to be defined)
>- for everything else, use the fact that /usr/bin/open will spawn in the 
>background, and call it via QProcess instead of a fork+exec protocol. 
>
>Can I just do that in kinit::launch(), instead of (and before) the fork() call?

Answer: yes, and before the call to pipe() too.

First impression is that this works: applications open in the foreground (those 
that have an interface to come to the foreground of course).

But as I feared, klauncher exits some time after spawning a command, and is 
then relaunched. How can I avoid that?

Thanks,

R
___
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

2015-12-25 Thread René J . V . Bertin 

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



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?


- René J.V. Bertin


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/
> ---
> 
> (Updated Nov. 26, 2015, 5:20 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kinit
> 
> 
> Description
> ---
> 
> This patch addresses several issues with the OS X adaptations:
> 
> -1 replaces the obsolete Q_OS_MAC with Q_OS_OSX
> -2 builds the relevant applications `nongui` instead of as app bundles
> -3 turns klauncher into an "agent" by setting `LSUIElement` to true 
> programmatically
> -4 ports a patch that has been in MacPorts' `port:kdelibs4` since October 
> 14th 2009, which prevents a kdeinit crash that is caused by calling exec 
> after `fork()` in an application that has used non-POSIX APIs and/or calling 
> those APIs in the exec'ed application. This patch (originally by MacPorts 
> developers Jeremy Lainé and Jeremy Lavergne) rearranges call order and uses a 
> proxy application to do the actual exec.
> 
> 
> Diffs
> -
> 
>   src/kdeinit/CMakeLists.txt f94db71 
>   src/kdeinit/kdeinit5_proxy.mm PRE-CREATION 
>   src/kdeinit/kinit.cpp a18008a 
>   src/kdeinit/kinit_mac.mm PRE-CREATION 
>   src/klauncher/CMakeLists.txt 746edfa 
>   src/klauncher/klauncher.h e155f72 
>   src/klauncher/klauncher.cpp 8b3d343 
>   src/klauncher/klauncher_main.cpp f69aaa5 
>   src/start_kdeinit/CMakeLists.txt 46d6cb3 
>   src/wrapper.cpp 95b7ec2 
> 
> Diff: https://git.reviewboard.kde.org/r/126161/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with Qt 5.5.1 and KF5rameworks 5.16.0 . With this patch, 
> starting `kded5` will launch kdeinit5 and klauncher5 as expected, but 
> `kdeinit5 --kded` does not yet launch `kded5`. This is probably acceptable 
> for typical KF5 use on OS X (kded5 can be launched as a login item or as a 
> LaunchAgent) but I will have another look at why the kded isn't started.
> 
> I am not yet able to perform further testing; practice will for instance have 
> to show whether point 2 above needs revision (apps that need to be installed 
> as app bundles).
> 
> Similarly it will have to be seen whether point 3 above has any drawbacks. 
> Applications running as agents do not show up in the Dock or App Switcher. 
> Thus, klauncher will not be able to "turn itself into" an application that 
> does have a full GUI presence with my current modification. I don't know if 
> that's supposed to be possible though.
> NB: I have been building the KDE4 klauncher in a way that makes it impossible 
> to construct a GUI at all, so I'm not expecting issues in KF5 as long as 
> klauncher's role hasn't evolved too much.
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

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

Re: Review Request 126515: [DrKonqi] RFC: Support showing a StatusNotifierItem instead of bringing up the dialog right away

2015-12-25 Thread Kai Uwe Broulik 


> On Dez. 25, 2015, 5:31 nachm., David Edmundson wrote:
> > code looks fine.
> > 
> > Though please do the TODOs before merging as historically we have a have a 
> > habbit of them not getting done
> > Also your StatusNotifierItem leaks  - but it proably wants to be the 
> > lifespan of the application anyway.

The sad face icon is used wrongly *everywhere* so I guess we can use it here, 
too.

About the context menu, I thought I could add a couple of shortcuts there but I 
guess just having a "Quit" option (unfortunately you cannot tell 
KStatusNotifierItem *not* to ask before quitting) is sufficient.

I was thinking off adding the app icon as overlay but that probably wouldn't 
work well, at least not with the black KDE logo.


- Kai Uwe


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


On Dez. 25, 2015, 4:24 nachm., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126515/
> ---
> 
> (Updated Dez. 25, 2015, 4:24 nachm.)
> 
> 
> Review request for KDE Frameworks, Plasma, KDE Usability, and Martin Gräßlin.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This adds a new "--passive" option to DrKonqi where it will only show a 
> StatusNotifierItem rather than bringing up the crash dialog right away.
> 
> This can be useful for auto-restarting shell services (like plasmashell, 
> krunner, kded) to improve the perceived quality of the product.
> 
> On Windows RT, for example, the guidelines even explicitly say "rather just 
> dump the user on the home screen than telling him something went wrong, so he 
> can just quickly start the app again instead of being annoyed by an error 
> message". On iOS you also just get dropped on the home screen. Windows 
> desktop shows a "Searching for a solution" dialog which was *the* major 
> annoyance when something crashed, rather than the actual crash.
> 
> Video here: https://www.youtube.com/watch?v=t0ZLs-juYKc
> 
> 
> Diffs
> -
> 
>   drkonqi/statusnotifier.cpp PRE-CREATION 
>   drkonqi/statusnotifier.h PRE-CREATION 
>   drkonqi/CMakeLists.txt eaeaad4 
>   drkonqi/main.cpp 7cbaae7 
> 
> Diff: https://git.reviewboard.kde.org/r/126515/diff/
> 
> 
> Testing
> ---
> 
> I crashed plasmashell, it restarted so fast that you didn't even have a black 
> screen inbetween, just the panel restarting. Afterwards I got a SNI which 
> opened DrKonqi when tapped.
> 
> The SNI disappears after 1 minute because if you didn't bother to look after 
> it by then, you probably forgot what you did to cause the crash anyway :)
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
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)

2015-12-25 Thread Jaime Torres Amate 


> On Dec. 17, 2015, 4:16 p.m., Martin Gräßlin wrote:
> >

Hello,

  This is just a warning to know if this patch has been tested in a two monitor 
environment in a laptop.
  In a pyqt application I save and restore the size and position of the window 
(without additional checks), using:
settings.setValue("size", self.ui.size())
settings.setValue("pos", self.ui.pos())   # save

self.ui.resize(settings.value("size", QSize(400, 400)))
self.ui.move(settings.value("pos", QPoint(200, 200)))   # restore
 
  It works perfectly fine except in this case:
   The window, when saved, was in a monitor that disappears in the next run. In 
the next run (without the monitor) the window is not shown, because it is still 
in the other monitor, but it is shown in the taskbar, I have to go to the 
taskbar or with an advanced task manager, tell the window to become maximized, 
then it is shown.
  If this patch shows the window when the monitor disappears, then, please, 
ignore this comment.


- Jaime Torres


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


On Dec. 14, 2015, 4:04 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126324/
> ---
> 
> (Updated Dec. 14, 2015, 4:04 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> In KDElibs4, the KMainWindow::saveWindowSize() and 
> KMainWindow::restoreWindowSize() function saved and restored not only the 
> size but also the position (i.e. the geometry) of windows, using 
> QWidget::saveGeometry and QWidget::restoreGeometry.
> 
> 2 main reasons for this (according to the comments):
> - Under X11 restoring the position is tricky
> - X11 has a window manager which might be considered responsible for that 
> functionality (and I suppose most modern WMs have the feature enabled by 
> default?)
> 
> Both arguments are moot on MS Windows and OS X, and on both platforms users 
> expect to see window positions restored as well as window size. On OS X there 
> is also little choice in the matter: most applications offer the geometry 
> restore without asking (IIRC it is the same on MS Windows).
> 
> I would thus like to propose to port the platform-specific code that existed 
> for MS Windows (and for OS X as a MacPorts patch that apparently was never 
> submitted upstreams). I realise that this violates the message conveyed by 
> the function names but I would like to think that this is a case where 
> function is more important.
> 
> You may also notice that the Mac version does not store resolution-specific 
> settings. This happens to work best on OS X, where multi-screen support has 
> been present since the early nineties, and where window geometry is restored 
> regardless of the screen resolution (i.e. connect a different external screen 
> with a different resolution, and windows will reopen as they were on that 
> screen, not with some default geometry).
> I required I can update the comments in the header to reflect this subtlety.
> 
> Note that for optimal functionality a companion patch to `KMainWindow::event` 
> is required:
> ```
> --- a/src/kmainwindow.cpp
> +++ b/src/kmainwindow.cpp
> @@ -772,7 +772,7 @@ bool KMainWindow::event(QEvent *ev)
>  {
>  K_D(KMainWindow);
>  switch (ev->type()) {
> -#ifdef Q_OS_WIN
> +#if defined(Q_OS_WIN) || defined(Q_OS_OSX)
>  case QEvent::Move:
>  #endif
>  case QEvent::Resize:
> ```
> 
> This ensures that the window geometry save is performed also after a move (to 
> update the position) without requiring a dummy resizing operation.
> Do I need to create a separate RR for this change or is it small enough that 
> I can push it if and when this RR is accepted?
> 
> 
> Diffs
> -
> 
>   src/gui/kwindowconfig.h 48a8f3c 
>   src/gui/kwindowconfig.cpp d2f355c 
> 
> Diff: https://git.reviewboard.kde.org/r/126324/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.6 through 10.9 with various KDElibs4 versions and now with Qt 
> 5.5.1 and frameworks 5.16.0 (and Kate as a test application).
> I presume that the MS Windows code has been tested sufficiently in KDELibs4; 
> I have only adapted it to Qt5 and tested if it builds.
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

___
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)

2015-12-25 Thread Jaime Torres Amate 


> On Dec. 17, 2015, 4:16 p.m., Martin Gräßlin wrote:
> >
> 
> Jaime Torres Amate wrote:
> Hello,
> 
>   This is just a warning to know if this patch has been tested in a two 
> monitor environment in a laptop.
>   In a pyqt application I save and restore the size and position of the 
> window (without additional checks), using:
> settings.setValue("size", self.ui.size())
> settings.setValue("pos", self.ui.pos())   # save
> 
> self.ui.resize(settings.value("size", QSize(400, 400)))
> self.ui.move(settings.value("pos", QPoint(200, 200)))   # restore
>  
>   It works perfectly fine except in this case:
>The window, when saved, was in a monitor that disappears in the next 
> run. In the next run (without the monitor) the window is not shown, because 
> it is still in the other monitor, but it is shown in the taskbar, I have to 
> go to the taskbar or with an advanced task manager, tell the window to become 
> maximized, then it is shown.
>   If this patch shows the window when the monitor disappears, then, 
> please, ignore this comment.
> 
> René J.V. Bertin wrote:
> What OS/windowing environment is that?
> 
> To the best of my knowledge, OS X will rearrange windows when a monitor 
> is disconnected (regardless whether on a laptop or desktop host) and should 
> do the same when reopening a window in an offscreen position if that window 
> isn't meant to be offscreen. I haven't yet tested this because of the 
> rearranging thing, but good point. I'll see if it can be simulated by storing 
> an offscreen position (this is where the binary nature of the saved data is 
> annoying indeed!)

Oh!, I'm sorry, I forgot to say. It is a windows 7. It rearranges other 
windows, but as it's position is restored, it goes to the non connected 
monitor. I hope it does not happen with this patch (In linux it does not happen 
to that pyqt program).


- Jaime Torres


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


On Dec. 14, 2015, 4:04 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126324/
> ---
> 
> (Updated Dec. 14, 2015, 4:04 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> In KDElibs4, the KMainWindow::saveWindowSize() and 
> KMainWindow::restoreWindowSize() function saved and restored not only the 
> size but also the position (i.e. the geometry) of windows, using 
> QWidget::saveGeometry and QWidget::restoreGeometry.
> 
> 2 main reasons for this (according to the comments):
> - Under X11 restoring the position is tricky
> - X11 has a window manager which might be considered responsible for that 
> functionality (and I suppose most modern WMs have the feature enabled by 
> default?)
> 
> Both arguments are moot on MS Windows and OS X, and on both platforms users 
> expect to see window positions restored as well as window size. On OS X there 
> is also little choice in the matter: most applications offer the geometry 
> restore without asking (IIRC it is the same on MS Windows).
> 
> I would thus like to propose to port the platform-specific code that existed 
> for MS Windows (and for OS X as a MacPorts patch that apparently was never 
> submitted upstreams). I realise that this violates the message conveyed by 
> the function names but I would like to think that this is a case where 
> function is more important.
> 
> You may also notice that the Mac version does not store resolution-specific 
> settings. This happens to work best on OS X, where multi-screen support has 
> been present since the early nineties, and where window geometry is restored 
> regardless of the screen resolution (i.e. connect a different external screen 
> with a different resolution, and windows will reopen as they were on that 
> screen, not with some default geometry).
> I required I can update the comments in the header to reflect this subtlety.
> 
> Note that for optimal functionality a companion patch to `KMainWindow::event` 
> is required:
> ```
> --- a/src/kmainwindow.cpp
> +++ b/src/kmainwindow.cpp
> @@ -772,7 +772,7 @@ bool KMainWindow::event(QEvent *ev)
>  {
>  K_D(KMainWindow);
>  switch (ev->type()) {
> -#ifdef Q_OS_WIN
> +#if defined(Q_OS_WIN) || defined(Q_OS_OSX)
>  case QEvent::Move:
>  #endif
>  case QEvent::Resize:
> ```
> 
> This ensures that the window geometry save is performed also after a move (to 
> update the position) without requiring a dummy resizing operation.
> Do I need to create a separate RR for this change or is it

Re: klauncher & .desktop Execs

2015-12-25 Thread René J . V . Bertin 
On Friday December 25 2015 12:34:08 René J.V. Bertin wrote:

> With the proper changes (still assessing them) that should work on OS X too, 
> no? With the USE_KPROCESS_FOR_KIOSLAVES/QProcess::start I had to jump to a 
> number of hoops and resort to calling the commandline AppleScript interpreter 
> (osascript) to ensure that the launched process is started in front of the 
> calling process. Not easy, as AppleScript isn't really designed for this so I 
> also had to subclass QProcess to launch osascript in detached fashion and set 
> a kill timer to get rid of it should it not complete within a reasonable 
> time. Since kinit will use ObjC++ in my proposed patch it should be possible 
> to achieve the same thing (process opens in front) directly using an 
> appropriate API (AppKit).
> 
> I'll queue testing this on my todolist.

Aaargghh ...

It turns out that [NSApp activateIgnoringOtherApps:YES] has no effect between a 
fork and an exec (i.e. in kinit::launch) unless I call a forbidden function 
first. For some reason it is also not possible to use /usr/bin/open as a proxy. 
More precisely it will fail when the application to be launched is "not an 
application", i.e. it's a shell script.
Annoyingly the exact same command that fails via execvp() succeeds from the 
command line ...
It's quite likely that this whole endeavour was bound to fail from the onset 
because  I doubt that /usr/bin/open preserves the filedescriptor or supports 
whatever mechanism kinit::launch() uses in the parent process to know that the 
child launched successfully.

Now I presume that is really not supposed to be the case by design, but also 
not impossible (and sometimes damn useful on OS X when something needs to be 
both in an app bundle and in ${prefix}/bin or libexec).

So what I'd like to do as a last test is this:
- leave the mechanism by which klauncher is started alone, as well as a few 
others (to be defined)
- for everything else, use the fact that /usr/bin/open will spawn in the 
background, and call it via QProcess instead of a fork+exec protocol. 

Can I just do that in kinit::launch(), instead of (and before) the fork() call?

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

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

2015-12-25 Thread René J . V . Bertin 


> On Dec. 2, 2015, 8:51 a.m., David Faure wrote:
> > Please kind in mind that kded must be able to pop up dialogs, though.
> > (cookie dialog, SSL cert messagebox + dialog, etc. etc.).
> > 
> > If making it an "agent" doesn't prevent it from showing GUI elements now 
> > and then, then no problem.
> 
> René J.V. Bertin wrote:
> With the earlier approach of setting `LSUIElement` that is guaranteed to 
> be the case.
> 
> I just checked; launching Qt's Assistant with 
> `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM=1` all that changes is that 
> the application remains in the background; it can be brought into the 
> foreground, and it retains its presence in the Dock and app switcher.
> 
> IOW, I'm not really sure I understand why kded5 doesn't retain that 
> presence with `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM` set. It's 
> possible that all the env. variable does is postpone the actions that lead to 
> that presence. If that's true than we'd have to come back to the more 
> appropriate previous revision of this patch.
> 
> OTOH: the only dialogs I have seen under KDE4 that are related to kded 
> (unknown cert) were posted when kded4 was *not* running. Ditto for cookie 
> related things. Under what circumstances is kded supposed to present a GUI?
> 
> David Faure wrote:
> Here is an easy way to test this: do the same change for kiod in kio 
> (it's like a mini kded) and then
> cd kio/tests ; ./listjobtest ftp://t...@upload.kde.org
> should bring up a password dialog.
> 
> Except that with Qt 5.6 from git here (from some time ago) it asserts in 
> DBus (looking into that now)... but hopefully you have Qt 5.5 ?

OK, here's a reason NOT to use QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM: 
it has to be unset, and I'm not sure when this would have to/could be done such 
that the variable is picked up for kded5 itself, but not by anything that is 
launched subsequently.

If kded5 is used to start kdeinit5 for instances, everything launched through 
there will launch in the background.

So I'm going to go back to the original proposition, because an LSUIElement app 
is exactly what kded ought to be.


- René J.V.


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


On Nov. 25, 2015, 7:12 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126170/
> ---
> 
> (Updated Nov. 25, 2015, 7:12 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kded
> 
> 
> Description
> ---
> 
> There should be no reason to build `kded5` as an app bundle on OS X, and with 
> recent feedback in mind I postulated that marking it "nongui" 
> (`ecm_mark_nongui_application`) would be acceptable on other platforms too.
> 
> Additionally, `kded5` doesn't have any more reason to appear in the Dock or 
> app switcher, on OS X, so I have added the code to make it an agent.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 4b9a5ff 
>   src/CMakeLists.txt 5e95df8 
>   src/kded.cpp 6929d7d 
> 
> Diff: https://git.reviewboard.kde.org/r/126170/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with Qt 5.5.1 and FWs 5.16.0 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

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

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

2015-12-25 Thread René J . V . Bertin 

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

(Updated Dec. 25, 2015, 10:14 p.m.)


Review request for KDE Software on Mac OS X and KDE Frameworks.


Changes
---

This takes the patch back to my original proposition, because of my previous 
comment (avoid unheriting `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM`).

There is one additional minor modification: `KDE_FULL_SESSION` has no special 
meaning on OS X. Advanced users might set it however, to unblock certain 
functionality elsewhere. Shunting kde_running to false means `kdeinit5` can be 
started through `kded5` regardless of whether `KDE_FULL_SESSION` is set; 
`kded5` is a "logical" utility to start in order to bootstrap the KDE runtime 
infrastructure (e.g. via a launchd plist).


Repository: kded


Description
---

There should be no reason to build `kded5` as an app bundle on OS X, and with 
recent feedback in mind I postulated that marking it "nongui" 
(`ecm_mark_nongui_application`) would be acceptable on other platforms too.

Additionally, `kded5` doesn't have any more reason to appear in the Dock or app 
switcher, on OS X, so I have added the code to make it an agent.


Diffs (updated)
-

  src/CMakeLists.txt 5e95df8 
  src/kded.cpp c7fdfee 

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


Testing
---

On OS X 10.9.5 with Qt 5.5.1 and FWs 5.16.0 .


Thanks,

René J.V. Bertin

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