D28020: New class ProcessLauncherJob in KIOGui

dfaure added a task: T11549: KIO: remove unneeded QWidget dependencies to set parent windows or display errors. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D28020 To: dfaure, apol, davidedmundson, nicolasfella, vkrause, broulik Cc: jbbgameich, kde-frameworks-devel,

D28020: New class ProcessLauncherJob in KIOGui

nicolasfella added a comment. IIRC startup notification is still a big question mark in Wayland, but other Plasma devs know better REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D28020 To: dfaure, apol, davidedmundson, nicolasfella, vkrause, broulik Cc: jbbgameich,

D28020: New class ProcessLauncherJob in KIOGui

dfaure added a comment. > Would it be possible to expose the finished signal of QProcess in KIO::ApplicationLauncherJob? By design the job finishes before the subprocess finishes (which could be in 3 days, if the user keeps the window open that long). Also this would only help you for

D28020: New class ProcessLauncherJob in KIOGui

jbbgameich added a comment. Sorry for using this diff to ask this question, I couldn't find you in kde-devel. Would it be possible to expose the finished signal of QProcess in KIO::ApplicationLauncherJob? I need something like this to close the startup feedback in the Plasma Mobile

D28020: New class ProcessLauncherJob in KIOGui

davidedmundson added a comment. In D28020#630185 , @dfaure wrote: > Ah there was still the WId question. I'll remove it before anyone starts using this API. > > We can always add a setter later if we want to (but if it's just for the unused

D28020: New class ProcessLauncherJob in KIOGui

dfaure added a comment. Ah there was still the WId question. I'll remove it before anyone starts using this API. We can always add a setter later if we want to (but if it's just for the unused setLaunchedBy, I'm not convinced...) REPOSITORY R241 KIO REVISION DETAIL

D28020: New class ProcessLauncherJob in KIOGui

dfaure closed this revision. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D28020 To: dfaure, apol, davidedmundson, nicolasfella, vkrause, broulik Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D28020: New class ProcessLauncherJob in KIOGui

dfaure added inline comments. INLINE COMMENTS > davidedmundson wrote in kprocessrunner.cpp:194 > It's the DBus calls that come before start that I want to get async, not the > tiny bit between fork and the child process exec()'ing. > > Obviously we can do that piecemeal later, and it isn't a

D28020: New class ProcessLauncherJob in KIOGui

davidedmundson accepted this revision. davidedmundson added inline comments. This revision is now accepted and ready to land. INLINE COMMENTS > kprocessrunner.cpp:194 > +{ > +return m_process->waitForStarted(); > +} It's the DBus calls that come before start that I want to get async, not

D28020: New class ProcessLauncherJob in KIOGui

dfaure updated this revision to Diff 77682. dfaure added a comment. - Don't block in start(), make it fully async - Add waitForStarted() for KRun (with unittests) - Add test for non-existing executables, with and without kioexec - after making sure that the command isn't trivial, by

D28020: New class ProcessLauncherJob in KIOGui

dfaure planned changes to this revision. dfaure added inline comments. INLINE COMMENTS > davidedmundson wrote in kprocessrunner.cpp:39 > WId as an int is problematic for wayland. > > Can we do QWindow*? it'll allow adding support in future. > > For the compatibility path we can loop through

D28020: New class ProcessLauncherJob in KIOGui

davidedmundson added a comment. From the POV of the task at hand, it's great. If we are making new public API I have some minor requests for things we want in future. INLINE COMMENTS > kprocessrunner.cpp:39 > + > +KProcessRunner::KProcessRunner(const KService::Ptr , const > QList ,

D28020: New class ProcessLauncherJob in KIOGui

moved to KIOGui, but still private. Next step: also routing KRun::runCommand via ProcessLauncherJob, and then writing OpenUrlJob on top of ProcessLauncherJob (but runUrl calling KOpenWithDialog is a problem in KIOGui...). TEST PLAN see new unittest (which is based on krununittest

Re: Review Request 126963: New class FavIconRequestJob in new lib KIOGui, for favicons retrieval.

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126963/ --- (Updated Feb. 5, 2016, 8:22 a.m.) Status -- This change has been

Review Request 126963: New class FavIconRequestJob in new lib KIOGui, for favicons retrieval.

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126963/ --- Review request for KDE Frameworks, Kevin Ottens, Laurent Montel, and Sune

Re: Review Request 126963: New class FavIconRequestJob in new lib KIOGui, for favicons retrieval.

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126963/#review91922 --- autotests/CMakeLists.txt (line 50)

Re: Review Request 126963: New class FavIconRequestJob in new lib KIOGui, for favicons retrieval.

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126963/ --- (Updated Feb. 2, 2016, 11:46 a.m.) Review request for KDE Frameworks,

Re: KIOGui ?

ise) > > module. > > > > I think there just isn't any point in using a central DBus module to handle > > a shared cache when a lock file can do the job. > > > > The question is: this would only depend on KIOCore and QImage. Shall I put > > it in KIOWid

Re: KIOGui ?

On Wednesday, January 13, 2016 12:33:36 AM David Faure wrote: > The question is: this would only depend on KIOCore and QImage. Shall I put > it in KIOWidgets or shall I create a new KIOGui library, for QML apps to > avoid the QWidget dependency ? I'd use this in the angelfish (exp

Re: KIOGui ?

On Wednesday 13 January 2016 00:57:57 Kai Uwe Broulik wrote: > Hi, > > I think there are many more features in KIO that aren't really > widget-dependant, so +1 for that, though we probably cannot move them anymore > now. Yes that's exactly why I'm thinking "at least for new classes, better put

Re: KIOGui ?

ral DBus module to handle > a shared cache when a lock file can do the job. > > The question is: this would only depend on KIOCore and QImage. Shall I put > it in KIOWidgets or shall I create a new KIOGui library, for QML apps to > avoid the QWidget dependency ? +1 for KIOGui. Eve

KIOGui ?

is: this would only depend on KIOCore and QImage. Shall I put it in KIOWidgets or shall I create a new KIOGui library, for QML apps to avoid the QWidget dependency ? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5

Re: KIOGui ?

Hi, I think there are many more features in KIO that aren't really widget-dependant, so +1 for that, though we probably cannot move them anymore now. Cheers,  Kai Uwe ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org

Re: KIOGui ?

using a central DBus module to handle a > shared cache > when a lock file can do the job. > > The question is: this would only depend on KIOCore and QImage. Shall I put it > in KIOWidgets > or shall I create a new KIOGui library, for QML apps to avoid the QWidget > depend