Re: Review Request 126149: [Icon widget] Bring back properties dialog

2015-11-26 Thread Kai Uwe Broulik
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126149/ --- (Updated Nov. 26, 2015, 8:15 nachm.) Review request for KDE Frameworks

Re: Review Request 126161: OS X housekeeping

2015-11-26 Thread René J . V . Bertin
Alex Merry wrote: > If I recall rightly, it's a speed thing. kdeinit pre-loads some > libraries common across most KDE applications (eg: Qt5Core and Qt5Gui, Ah, right. Dive in too deeply and you can forget about underlying reasons. The real underlying mechanism is of course (IIUC) the fact that

Re: Review Request 125988: [KUrlCompletion] Add autocompletion for '.' input which offers all hidden files/folders

2015-11-26 Thread David Faure
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125988/#review88860 --- src/widgets/kurlcompletion.cpp (line 531)

Re: Review Request 126161: OS X housekeeping

2015-11-26 Thread René J . V . Bertin
On Thursday November 26 2015 08:54:25 David Faure wrote: >> No, with "my" fix, applications started through kwrapper appear as >> individual entries in `ps` listings, with your fix only the `kwrapper5 >> /path/to/command` entry shows up. > >I don't see how that's possible. >If kdeinit forks,

Re: Review Request 126161: OS X housekeeping

2015-11-26 Thread René J . V . Bertin
On Thursday November 26 2015 08:54:25 David Faure wrote: > Not at all, kdeinit on linux does fork+dlopen, no exec. Actually, that is true only when launch() is called with a library (.so), not when it's called with an executable! R ___

kdeinit freezes on Wayland in OOM protection

2015-11-26 Thread Martin Graesslin
Hi all, we are facing a problem during the startup of Plasma on Wayland. If OOM protection is enabled for kdeinit and we already have a running X server, kdeinit freezes dead. I'm sorry for having ignored the issue for too long and had just disabled OOM protection on my system, so I never hit

Re: Review Request 126161: OS X housekeeping

2015-11-26 Thread René J . V . Bertin
On Thursday November 26 2015 08:54:25 David Faure wrote: > But my point is exactly that: if fork+dlopen is a problem on OSX, then don't > do it, do fork+exec. That's what you do, > but then why exec something that will dlopen, instead of exec the real thing? Indeed, it's fork+dlopen that is the

Re: Review Request 126161: OS X housekeeping

2015-11-26 Thread René J . V . Bertin
--- 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

Re: Review Request 126161: OS X housekeeping

2015-11-26 Thread René J . V . Bertin
> On Nov. 25, 2015, 8:39 a.m., David Faure wrote: > > src/kdeinit/kinit.cpp, line 1621 > > > > > > Yes if you have to run a separate process which will then dlopen the > > kdeinit module, the whole purpose of

Re: Review Request 126161: OS X housekeeping

2015-11-26 Thread Alex Merry
On 2015-11-26 09:27, René J.V. Bertin wrote: There's something I don't really understand though: the exact same question you asked above. What's the difference between starting kwrite directly on the commandline (or through execve()), and dlopen'ing it? Why does the code go through that on