Re: Review Request 124905: Win: Hide console window for binaries in LIBEXEC
> On Aug. 26, 2015, 7:24 a.m., David Faure wrote: > > It sounds to me like ecm_mark_non_gui_executable doesn't do the right thing > > then, and should be fixed, instead? > > > > These are non gui executables, so from an "API" point of view, using this > > function is correct. > > > > Would we ever want a console window when running an app on windows? I guess > > not? > > So maybe we should do whatever "WIN32" does from within that function, if > > it's doable outside the add_executable call? > > Kevin Funk wrote: > It's rather that `ecm_mark_non_gui_executable` is has a misleading > meaning: "Marks an executable target as not being a GUI application" > > Well, in that case setting WIN32_EXECUTABLE to FALSE is *correct*, *but* > in fact marking an executable as console application on Windows implies the > executable showing a console window. I'm not sure if we should just switch > the description/behavior of `ecm_mark_non_gui_executable`, or just not use it > (as I did). Honestly I think we'd be better off just not using it (it doesn't > really increase convenience, in fact my patch just removes code and still > "fixes" things). > > > Documentation of WIN32_EXECUTABLE: > > WIN32_EXECUTABLE > Build an executable with a WinMain entry point on windows. > > When this property is set to true the executable when linked on Windows > will be created with a WinMain() entry point instead of just main(). This > makes it a GUI executable instead of a console application. See the > CMAKE_MFC_FLAG variable documentation to configure use of MFC for WinMain > executables. This property is initialized by the value of the variable > CMAKE_WIN32_EXECUTABLE if it is set when a target is created. > > > http://www.cmake.org/cmake/help/v3.0/prop_tgt/WIN32_EXECUTABLE.html#prop_tgt:WIN32_EXECUTABLE I think what you're missing is that ecm_mark_non_gui_executable aims at "doing the right thing on all platforms", which includes having no .app bundle on OSX. Your patch goes back to unwanted app bundles on OSX, I presume. This is why we should fix ecm_mark_non_gui_executable rather than not use it. Also for a linux developer it's easier to think in terms of "mark as non gui" than "do I need that weird WIN32 thing in there?". But I'm starting to understand something. Applications that are meant to be used on the command line like kioclient, should be console apps on windows i.e. use main() instead of WinMain(), otherwise we can't see any output, is that right? So we don't have two cases (gui and non gui), we have three? * GUI application (user visible) * helper binary (libexec style). Not user visible. Should be WIN32 to avoid a console window. * command line tool (console app, "user visible" in the console). Should not be WIN32. In that case we should have a different ecm macro for the second item in that list, that's what we're missing, isn't it? On OSX, AFAIU, the last two would be "without app bundle". - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124905/#review84389 --- On Aug. 24, 2015, 1:36 p.m., Kevin Funk wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124905/ > --- > > (Updated Aug. 24, 2015, 1:36 p.m.) > > > Review request for KDE Frameworks, David Faure and Boudewijn Rempt. > > > Repository: kio > > > Description > --- > > Win: Hide console window for binaries in LIBEXEC > > > Diffs > - > > src/ioslaves/http/CMakeLists.txt 76a8e2800b84c312431cc1996ac81d1ef6fb5cfc > src/ioslaves/http/kcookiejar/CMakeLists.txt > 7b4778d1f67c1ad9f9edcaa4692b39ee6fe3f365 > src/kioexec/CMakeLists.txt 91284a3a61b86770b4d1939da52d256840803608 > src/kioslave/CMakeLists.txt e02febd380b268c596e8ecc3b745b6f50993ab4e > src/kpac/CMakeLists.txt fc5989714480ca49b5bd72e1c7b458b26bd0d9bc > > Diff: https://git.reviewboard.kde.org/r/124905/diff/ > > > Testing > --- > > > Thanks, > > Kevin Funk > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Paths to internal executables (c.f. libexec) hard-coded
On Thursday 27 August 2015 00:14:50 Kevin Funk wrote:
>
> If we want to support this case, then we'd need to create a
> KSomething::libexecPaths() method returning the following search path (in
> order):
> - Windows:
> - Just QCA::applicationDirPath() (we control the install layout anyway)
> - Unix:
> - a list based on {DY,}LD_LIBRARY_PATH, each suffixed by libexec/
> - then : As fallback: the hardcoded install prefix of KF5 as before
> (otherwise we might not check /usr/lib/libexec at all, if installed there)
>
> This is somewhat in line what David F. suggested in his initial mail, I think.
The reason I got stuck on this issue is that I would want that to be in Qt
(e.g. QStandardPaths) to avoid creating additional inter-frameworks dependencies
just for that "KSomething". But there's no standard solution for libexec, nobody
has been able to present me with any kind of standard there.
I suppose smaller projects just use the applicationDirPath type solution,
or don't support relocateability. Bigger projects control the whole stack and
need no standards (LibreOffice, Firefox etc.).
This being said I like the idea of LD_LIBRARY_PATH + libexec/,
as long as there's the builtin fallback too (which the caller has to pass,
since hardcoded-into-Qt doesn't help us).
Hehe, we could use QT_PLUGIN_PATH instead and call
QStandardPaths::findExecutable("libexec/kfoobar",
QCoreApplication::libraryPaths() + libExecDir)
but ok that might be a bit weird, to treat libexec binaries like "plugins" ;)
It's the easiest solution though, isn't it? We just have to install libexec
stuff under plugins/libexec,
on all platforms
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124905: Win: Hide console window for binaries in LIBEXEC
> On Aug. 26, 2015, 7:24 a.m., David Faure wrote: > > It sounds to me like ecm_mark_non_gui_executable doesn't do the right thing > > then, and should be fixed, instead? > > > > These are non gui executables, so from an "API" point of view, using this > > function is correct. > > > > Would we ever want a console window when running an app on windows? I guess > > not? > > So maybe we should do whatever "WIN32" does from within that function, if > > it's doable outside the add_executable call? > > Kevin Funk wrote: > It's rather that `ecm_mark_non_gui_executable` is has a misleading > meaning: "Marks an executable target as not being a GUI application" > > Well, in that case setting WIN32_EXECUTABLE to FALSE is *correct*, *but* > in fact marking an executable as console application on Windows implies the > executable showing a console window. I'm not sure if we should just switch > the description/behavior of `ecm_mark_non_gui_executable`, or just not use it > (as I did). Honestly I think we'd be better off just not using it (it doesn't > really increase convenience, in fact my patch just removes code and still > "fixes" things). > > > Documentation of WIN32_EXECUTABLE: > > WIN32_EXECUTABLE > Build an executable with a WinMain entry point on windows. > > When this property is set to true the executable when linked on Windows > will be created with a WinMain() entry point instead of just main(). This > makes it a GUI executable instead of a console application. See the > CMAKE_MFC_FLAG variable documentation to configure use of MFC for WinMain > executables. This property is initialized by the value of the variable > CMAKE_WIN32_EXECUTABLE if it is set when a target is created. > > > http://www.cmake.org/cmake/help/v3.0/prop_tgt/WIN32_EXECUTABLE.html#prop_tgt:WIN32_EXECUTABLE > > David Faure wrote: > I think what you're missing is that ecm_mark_non_gui_executable aims at > "doing the right thing on all platforms", which includes having no .app > bundle on OSX. Your patch goes back to unwanted app bundles on OSX, I presume. > This is why we should fix ecm_mark_non_gui_executable rather than not use > it. Also for a linux developer it's easier to think in terms of "mark as non > gui" than "do I need that weird WIN32 thing in there?". > > But I'm starting to understand something. Applications that are meant to > be used on the command line like kioclient, should be console apps on windows > i.e. use main() instead of WinMain(), otherwise we can't see any output, is > that right? > > So we don't have two cases (gui and non gui), we have three? > * GUI application (user visible) > * helper binary (libexec style). Not user visible. Should be WIN32 to > avoid a console window. > * command line tool (console app, "user visible" in the console). Should > not be WIN32. > > In that case we should have a different ecm macro for the second item in > that list, that's what we're missing, isn't it? > > On OSX, AFAIU, the last two would be "without app bundle". I know about OSX bundles. MACOSX_BUNDLE is FALSE by default. However, I just noticed we have this defined somewhere in ECM (thus MACOSX_BUNDLE is indeed TRUE by default b/c of CMAKE_MACOSX_BUNDLE being ON...) ``` # By default, create 'GUI' executables. This can be reverted on a per-target basis # using ECMMarkNonGuiExecutable # Since CMake 2.8.8 set(CMAKE_WIN32_EXECUTABLE ON) set(CMAKE_MACOSX_BUNDLE ON) ``` Didn't realize until now... I totally agree with your remark; there are three cases. Let's solve them by: * (1) -> do nothing * (2) -> ecm_mark_helper_executable() (to be done, sets WIN32 to TRUE, MACOSX_BUNDLE to FALSE) * (3) -> ecm_mark_nongui_executable() Makes sense? - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124905/#review84389 --- On Aug. 27, 2015, 7:31 a.m., Kevin Funk wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124905/ > --- > > (Updated Aug. 27, 2015, 7:31 a.m.) > > > Review request for KDE Frameworks, Alex Merry, David Faure, and Boudewijn > Rempt. > > > Repository: kio > > > Description > --- > > Win: Hide console window for binaries in LIBEXEC > > > Diffs > - > > src/ioslaves/http/CMakeLists.txt 76a8e2800b84c312431cc1996ac81d1ef6fb5cfc > src/ioslaves/http/kcookiejar/CMakeLists.txt > 7b4778d1f67c1ad9f9edcaa4692b39ee6fe3f365 > src/kioexec/CMakeLists.txt 91284a3a61b86770b4d1939da52d256840803608 > src/kioslave/CMakeLists.txt e02febd380b268c596e8ecc3b745b6f50993ab4e > src/kpac/CMakeLists.txt fc598971
Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library
> On Aug. 25, 2015, 2:22 p.m., René J.V. Bertin wrote:
> > > When built as SHARED as in the current code, libdraganddropplugin.dylib
> > > gets installed to $PREFIX/share/qt5/qml/org/kde/draganddrop, but is given
> > > an OS X install_name of $PREFIX/lib/libdraganddropplugin.dylib. This
> > > mismatch can cause problems.
> > > It is also given a compatibility_version of 0.0.0.
> >
> > Both properties are used only when the `dylib` is used as a shared library,
> > because AFAIK they're only used by the dynamic loader when the reference
> > information is available (i.e. stored in the binary by the link editor).
> > Using `dlopen` on a random file, dylib or other, does not provide such
> > information and thus it shouldn't matter what the loaded file claims for
> > its install_name and/or compatibility_version.
> >
> > By contrast, there *is* a difference between shared libraries and loadable
> > modules ("plugins" or `bundles` in OS X speak) on OS X. The latter cannot
> > be used as shared libraries by the link editor (something that certain KDE4
> > projects sin against) while the former can be used as plugins without any
> > issue. However, only plugins can have automatic access to the loader's
> > symbols but that requires the loader to be specified at link time so not of
> > much interest for generic plugins, kparts etc.
> > NB: the `bundle` in this context is unfortunate because they are not
> > generally bundles in the "app bundle" way.
> > NB2: those KDE projects that use modules as shared libraries (kparts, in
> > unit tests IIRC) led me to propose a patch to MacPorts's port:cmake which
> > made cmake create modules with the same linker options as shared libraries
> > (i.e. `-dynamiclib` instead of `-bundle`). I've since tried to get that
> > patch removed, but it is still out there.
>
> Marco Martin wrote:
> if this breaks on linux, it should be reverted for now
Reverted for now. I also reopened the bug report.
Also for the qml side of things:
https://mail.kde.org/pipermail/kde-frameworks-devel/2015-August/026281.html
- Harald
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124892/#review84338
---
On Aug. 23, 2015, 9:16 p.m., Hanspeter Niederstrasser wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124892/
> ---
>
> (Updated Aug. 23, 2015, 9:16 p.m.)
>
>
> Review request for Build System, KDE Software on Mac OS X, KDE Frameworks,
> Plasma, and Harald Sitter.
>
>
> Bugs: 342962
> https://bugs.kde.org/show_bug.cgi?id=342962
>
>
> Repository: kdeclarative
>
>
> Description
> ---
>
> The kdeclarative plugins (draganddropplugin, kcoreaddonsplugin, kio,
> kquickcontrolsprivateplugin, and kquickcontrolsaddonsplugin) are being built
> as shared libraries. They should be built as bundles (MODULE) in the
> CMakeLists.txt file.
>
> When built as SHARED as in the current code, libdraganddropplugin.dylib gets
> installed to $PREFIX/share/qt5/qml/org/kde/draganddrop, but is given an OS X
> install_name of $PREFIX/lib/libdraganddropplugin.dylib. This mismatch can
> cause problems. It is also given a compatibility_version of 0.0.0.
>
>
> Diffs
> -
>
> src/qmlcontrols/draganddrop/CMakeLists.txt e8127e4
> src/qmlcontrols/kcoreaddons/CMakeLists.txt 3f77f2d
> src/qmlcontrols/kioplugin/CMakeLists.txt 7b258e0
> src/qmlcontrols/kquickcontrols/private/CMakeLists.txt da355c1
> src/qmlcontrols/kquickcontrolsaddons/CMakeLists.txt 5b711e1
>
> Diff: https://git.reviewboard.kde.org/r/124892/diff/
>
>
> Testing
> ---
>
> Since the plugin is not supposed to be a linkable library, it should be built
> as MODULE in CMakeLists.txt. The physical install location remains the same
> and plugins don't have install_names. This corrects the install_name/install
> location mismatch. The change should not have any effect on non-OS X systems.
>
>
> Thanks,
>
> Hanspeter Niederstrasser
>
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124905: Win: Hide console window for binaries in LIBEXEC
> On Aug. 26, 2015, 7:24 a.m., David Faure wrote: > > It sounds to me like ecm_mark_non_gui_executable doesn't do the right thing > > then, and should be fixed, instead? > > > > These are non gui executables, so from an "API" point of view, using this > > function is correct. > > > > Would we ever want a console window when running an app on windows? I guess > > not? > > So maybe we should do whatever "WIN32" does from within that function, if > > it's doable outside the add_executable call? > > Kevin Funk wrote: > It's rather that `ecm_mark_non_gui_executable` is has a misleading > meaning: "Marks an executable target as not being a GUI application" > > Well, in that case setting WIN32_EXECUTABLE to FALSE is *correct*, *but* > in fact marking an executable as console application on Windows implies the > executable showing a console window. I'm not sure if we should just switch > the description/behavior of `ecm_mark_non_gui_executable`, or just not use it > (as I did). Honestly I think we'd be better off just not using it (it doesn't > really increase convenience, in fact my patch just removes code and still > "fixes" things). > > > Documentation of WIN32_EXECUTABLE: > > WIN32_EXECUTABLE > Build an executable with a WinMain entry point on windows. > > When this property is set to true the executable when linked on Windows > will be created with a WinMain() entry point instead of just main(). This > makes it a GUI executable instead of a console application. See the > CMAKE_MFC_FLAG variable documentation to configure use of MFC for WinMain > executables. This property is initialized by the value of the variable > CMAKE_WIN32_EXECUTABLE if it is set when a target is created. > > > http://www.cmake.org/cmake/help/v3.0/prop_tgt/WIN32_EXECUTABLE.html#prop_tgt:WIN32_EXECUTABLE > > David Faure wrote: > I think what you're missing is that ecm_mark_non_gui_executable aims at > "doing the right thing on all platforms", which includes having no .app > bundle on OSX. Your patch goes back to unwanted app bundles on OSX, I presume. > This is why we should fix ecm_mark_non_gui_executable rather than not use > it. Also for a linux developer it's easier to think in terms of "mark as non > gui" than "do I need that weird WIN32 thing in there?". > > But I'm starting to understand something. Applications that are meant to > be used on the command line like kioclient, should be console apps on windows > i.e. use main() instead of WinMain(), otherwise we can't see any output, is > that right? > > So we don't have two cases (gui and non gui), we have three? > * GUI application (user visible) > * helper binary (libexec style). Not user visible. Should be WIN32 to > avoid a console window. > * command line tool (console app, "user visible" in the console). Should > not be WIN32. > > In that case we should have a different ecm macro for the second item in > that list, that's what we're missing, isn't it? > > On OSX, AFAIU, the last two would be "without app bundle". > > Kevin Funk wrote: > I know about OSX bundles. MACOSX_BUNDLE is FALSE by default. However, I > just noticed we have this defined somewhere in ECM (thus MACOSX_BUNDLE is > indeed TRUE by default b/c of CMAKE_MACOSX_BUNDLE being ON...) > > ``` ># By default, create 'GUI' executables. This can be reverted on a > per-target basis ># using ECMMarkNonGuiExecutable ># Since CMake 2.8.8 >set(CMAKE_WIN32_EXECUTABLE ON) >set(CMAKE_MACOSX_BUNDLE ON) > ``` > > Didn't realize until now... > > I totally agree with your remark; there are three cases. Let's solve them > by: > * (1) -> do nothing > * (2) -> ecm_mark_helper_executable() (to be done, sets WIN32 to TRUE, > MACOSX_BUNDLE to FALSE) > * (3) -> ecm_mark_nongui_executable() > > Makes sense? Yes, very much. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124905/#review84389 --- On Aug. 27, 2015, 7:31 a.m., Kevin Funk wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124905/ > --- > > (Updated Aug. 27, 2015, 7:31 a.m.) > > > Review request for KDE Frameworks, Alex Merry, David Faure, and Boudewijn > Rempt. > > > Repository: kio > > > Description > --- > > Win: Hide console window for binaries in LIBEXEC > > > Diffs > - > > src/ioslaves/http/CMakeLists.txt 76a8e2800b84c312431cc1996ac81d1ef6fb5cfc > src/ioslaves/http/kcookiejar/CMakeLists.txt > 7b4778d1f67c1ad9f9edcaa4692b39ee6fe3f365 > src/kioexec/CMakeList
Re: Paths to internal executables (c.f. libexec) hard-coded
On Thursday 27 August 2015 00:14:50 Kevin Funk wrote:
> On Wednesday 26 August 2015 13:40:20 Volker Krause wrote:
> > On Wednesday 26 August 2015 13:15:15 Kevin Funk wrote:
> > > Heya,
> > >
> > > This is problem on Windows because the *final* installation location is
> > > not
> > > known at compile-time (obviously software is installed via installers,
> > > users can pick up the installation prefix). Of course this also limits
> > > the relocateability on other platforms, so it's not just a Windows issue
> > > per se.
> > >
> > > I've found this, which describes the issue in detail:
> > > https://www.mail-archive.com/kde-frameworks-devel@kde.org/msg01833.htm
> > > l
> > >
> > > Consider this code (kio.git):
> > >const QLatin1String libExecDir(CMAKE_INSTALL_FULL_LIBEXECDIR_KF5);
> > >const QString kioslaveExecutable =
> > >
> > > QStandardPaths::findExecutable("kioslave", {libExecDir});
> > >
> > > Similar code exists in other frameworks.
> > >
> > > Problem:
> > > - Hard-coding the install path is a no-go (for sure on Windows)
> > >
> > > How can we solve this?
> > >
> > > Proposals:
> > >
> > > - Generic solution:
> > > - Add new API such as KSomeFittingClass::libexecPaths()
> > >
> > > which returns a list of candidates based on the platform
> > >
> > > - Then just do:
> > > `QSP::findExecutable("myexe", KSomeFittingClass::libexecPaths())`
> > >
> > > - Windows solution only (also less pretty):
> > > - In every place where CMAKE_INSTALL_FULL_LIBEXECDIR_KF5 is used:
> > > - Replace install prefix by QCA::applicationDirPath() via #ifdef
> > >
> > > Opinions?
> >
> > You might find useful building blocks for this in GammaRay. Instead of
> > hard- coding the absolute libexec dir there we compile in the relative
> > path from bin to libexec (as that depends on the exact install layout you
> > configure in CMake), and then combine that with
> > QCoreApp::applicationDirPath() at runtime. Makes the whole installation
> > relocatable, as long as you don't move things around within the install
> > prefix itself.
>
> Yep, thanks for this pointer. Didn't even know we had such code in GammaRay.
>
> It's a bit more complex in KDE land because we have multiple levels of
> library dependencies, each can be installed into different locations.
>
> Assume on Linux
> - KF5 installed into /usr
> - KDevelop into $HOME/opt
>
> When invoking `kdevelop` we can't just use
> QCA::applicationDirPath()/../lib/libexec, b/c then we might not find
> executables installed by KF5 in /usr/lib/libexec.
Indeed.
> If we want to support this case, then we'd need to create a
> KSomething::libexecPaths() method returning the following search path (in
> order):
> - Windows:
> - Just QCA::applicationDirPath() (we control the install layout anyway)
> - Unix:
> - a list based on {DY,}LD_LIBRARY_PATH, each suffixed by libexec/
That will miss system search paths (including manually configured ones) and
far more importantly R[UN]PATH, no? When implementing this, you might find
useful building blocks for the library search path logic in elf-dissector,
Linux-only unfortunately. GammaRay recently got RPATH resolution for Mac,
might also come in handy.
However, at that point it might become more reliable to look at the location
of the actual loaded library, ie. like QCA::appDirPath(), just for the DLL
rather than the executable. Then you would just be re-using the lookup logic
of the dynamic linker.
This would be very platform-specific code though, GammaRay has implementations
of this for doing it on external processes (in the probe ABI detector), there
might be more efficient ways to do it in-process, on some platforms at least.
regards,
Volker
> - then : As fallback: the hardcoded install prefix of KF5 as before
> (otherwise we might not check /usr/lib/libexec at all, if installed there)
>
> This is somewhat in line what David F. suggested in his initial mail, I
> think.
>
> If this is not feasible in near future, I'd also be fine just fixing the
> Windows-case by placing a few #ifdefs in KF5 code... (In fact, our shiny
> KDevelop Windows installer already contains such patches)
>
> > regards,
> > Volker
>
> Cheers
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
network manager qt - how to get the passwords
Hi, I am currently developing a gui for our products to edit the network settings. One thing which I cannot figure out is how to get the passwords. Simply calling NetworkManager::Security8021xSetting::password() or any of the other password-methods doesn't seem to work. Is there somewhere a good documentation or example showing how it works? Thanks Heiko ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: network manager qt - how to get the passwords
Hi, On Thursday 27 of August 2015 09:43:54 Boettger, Heiko wrote: > Hi, > > I am currently developing a gui for our products to edit the network > settings. One thing which I cannot figure out is how to get the passwords. > Simply calling NetworkManager::Security8021xSetting::password() or any of > the other password-methods doesn't seem to work. > Unfortunately it doesn't work that way, you need to call NetworkManager::Connection::secrets() for the connection you want secrets for and pass the setting type as a parameter (in your case it would be "NetworkManager::Setting::Security8021x" enum). This would return you a QDBusPendingReply so you need to wait for the reply to finish or connect to a signal finished() and do whatever you want to do with the secrets. Using NetworkManager::Security8021xSetting::password() would work only in case you already have secrets as a part of the setting. > Is there somewhere a good documentation or example showing how it works? > You can check how everything work in plasma-nm [1]. If you want to check how to get secrets go to libs/editor/connectiondetailseditor.cpp. You can also ping me anytime on IRC on #solid channel. [1] - https://quickgit.kde.org/?p=plasma-nm.git[1] > Thanks > Heiko Regards, Jan -- Jan Grulich Software Engineer, Desktop team Red Hat Czech [1] https://quickgit.kde.org/?p=plasma-nm.git ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124698: KPasswordDialog: allow the user to show the password
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124698/#review84491 --- Ship it! Ship It! - David Faure On Aug. 26, 2015, 10:36 a.m., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124698/ > --- > > (Updated Aug. 26, 2015, 10:36 a.m.) > > > Review request for KDE Frameworks and Christoph Feck. > > > Bugs: 224686 > https://bugs.kde.org/show_bug.cgi?id=224686 > > > Repository: kwidgetsaddons > > > Description > --- > > Starting from Qt 5.2, adding a trailing QAction to a QLineEdit is fairly > trivial. This patch implements such an action in order to allow a user to > show the password being typed. The action is only available if no password is > given to the dialog as preset. > > About the icon: for now I've used `games-hint` from Breeze. Let me know > whether there is a more relevant icon already available. If not, we can > either request it or create a symlink for this one, e.g. `password-hint` or > similar. > > About the last screenshot: the greyed icon is due to Qt bug > [39660](https://bugreports.qt.io/browse/QTBUG-39660). Once fixed upstream (Qt > 5.5?), the action will be properly hidden and there will be no icon greyed > out. > > > Diffs > - > > src/CMakeLists.txt 1e664453623b4a03c07b9a478b2ca7e240cb949f > src/icons.qrc PRE-CREATION > src/icons/hint.svg PRE-CREATION > src/icons/visibility.svg PRE-CREATION > src/kpassworddialog.h 9de2724640f483d5ab1134510fb84e1245814d90 > src/kpassworddialog.cpp 3d348964b4c44d26c44856fc08c199007a195aca > > Diff: https://git.reviewboard.kde.org/r/124698/diff/ > > > Testing > --- > > * Create a default KPasswordDialog. The new action is shown as soon as a > password is being typed. The action is no more available as soon as the line > edit is cleared. > * Create a default KPasswordDialog, call `setPassword()` with a non-empty > password and then show the dialog. The action is not available. > > > File Attachments > > > kpassworddialog1.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/08/26/e5333571-d38f-48bb-9b86-4e9ceb1a540b__kpassworddialog1.png > kpassworddialog2.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/08/26/61f321e9-b940-49ad-bc49-1ef136bb758a__kpassworddialog2.png > kpassworddialog3.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/08/26/6b66c26b-09ba-4f9b-852d-69271ffd46cd__kpassworddialog3.png > > > Thanks, > > Elvis Angelaccio > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124698: KPasswordDialog: allow the user to show the password
> On Aug. 27, 2015, 9:35 p.m., David Faure wrote: > > Ship It! Does it make sense to also have this feature in KNewPasswordDialog? - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124698/#review84491 --- On Aug. 26, 2015, 10:36 a.m., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124698/ > --- > > (Updated Aug. 26, 2015, 10:36 a.m.) > > > Review request for KDE Frameworks and Christoph Feck. > > > Bugs: 224686 > https://bugs.kde.org/show_bug.cgi?id=224686 > > > Repository: kwidgetsaddons > > > Description > --- > > Starting from Qt 5.2, adding a trailing QAction to a QLineEdit is fairly > trivial. This patch implements such an action in order to allow a user to > show the password being typed. The action is only available if no password is > given to the dialog as preset. > > About the icon: for now I've used `games-hint` from Breeze. Let me know > whether there is a more relevant icon already available. If not, we can > either request it or create a symlink for this one, e.g. `password-hint` or > similar. > > About the last screenshot: the greyed icon is due to Qt bug > [39660](https://bugreports.qt.io/browse/QTBUG-39660). Once fixed upstream (Qt > 5.5?), the action will be properly hidden and there will be no icon greyed > out. > > > Diffs > - > > src/CMakeLists.txt 1e664453623b4a03c07b9a478b2ca7e240cb949f > src/icons.qrc PRE-CREATION > src/icons/hint.svg PRE-CREATION > src/icons/visibility.svg PRE-CREATION > src/kpassworddialog.h 9de2724640f483d5ab1134510fb84e1245814d90 > src/kpassworddialog.cpp 3d348964b4c44d26c44856fc08c199007a195aca > > Diff: https://git.reviewboard.kde.org/r/124698/diff/ > > > Testing > --- > > * Create a default KPasswordDialog. The new action is shown as soon as a > password is being typed. The action is no more available as soon as the line > edit is cleared. > * Create a default KPasswordDialog, call `setPassword()` with a non-empty > password and then show the dialog. The action is not available. > > > File Attachments > > > kpassworddialog1.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/08/26/e5333571-d38f-48bb-9b86-4e9ceb1a540b__kpassworddialog1.png > kpassworddialog2.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/08/26/61f321e9-b940-49ad-bc49-1ef136bb758a__kpassworddialog2.png > kpassworddialog3.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/08/26/6b66c26b-09ba-4f9b-852d-69271ffd46cd__kpassworddialog3.png > > > Thanks, > > Elvis Angelaccio > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124698: KPasswordDialog: allow the user to show the password
> On Ago. 27, 2015, 9:35 p.m., David Faure wrote: > > Ship It! > > Christoph Feck wrote: > Does it make sense to also have this feature in KNewPasswordDialog? I have another RR ready to submit after this one. I'd like to add a new widget called `KNewPasswordWidget`, meant to be used in custom password dialogs. After that, `KNewPasswordDialog` can be easily refactored and will get this feature too. - Elvis --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124698/#review84491 --- On Ago. 26, 2015, 10:36 a.m., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124698/ > --- > > (Updated Ago. 26, 2015, 10:36 a.m.) > > > Review request for KDE Frameworks and Christoph Feck. > > > Bugs: 224686 > https://bugs.kde.org/show_bug.cgi?id=224686 > > > Repository: kwidgetsaddons > > > Description > --- > > Starting from Qt 5.2, adding a trailing QAction to a QLineEdit is fairly > trivial. This patch implements such an action in order to allow a user to > show the password being typed. The action is only available if no password is > given to the dialog as preset. > > About the icon: for now I've used `games-hint` from Breeze. Let me know > whether there is a more relevant icon already available. If not, we can > either request it or create a symlink for this one, e.g. `password-hint` or > similar. > > About the last screenshot: the greyed icon is due to Qt bug > [39660](https://bugreports.qt.io/browse/QTBUG-39660). Once fixed upstream (Qt > 5.5?), the action will be properly hidden and there will be no icon greyed > out. > > > Diffs > - > > src/CMakeLists.txt 1e664453623b4a03c07b9a478b2ca7e240cb949f > src/icons.qrc PRE-CREATION > src/icons/hint.svg PRE-CREATION > src/icons/visibility.svg PRE-CREATION > src/kpassworddialog.h 9de2724640f483d5ab1134510fb84e1245814d90 > src/kpassworddialog.cpp 3d348964b4c44d26c44856fc08c199007a195aca > > Diff: https://git.reviewboard.kde.org/r/124698/diff/ > > > Testing > --- > > * Create a default KPasswordDialog. The new action is shown as soon as a > password is being typed. The action is no more available as soon as the line > edit is cleared. > * Create a default KPasswordDialog, call `setPassword()` with a non-empty > password and then show the dialog. The action is not available. > > > File Attachments > > > kpassworddialog1.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/08/26/e5333571-d38f-48bb-9b86-4e9ceb1a540b__kpassworddialog1.png > kpassworddialog2.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/08/26/61f321e9-b940-49ad-bc49-1ef136bb758a__kpassworddialog2.png > kpassworddialog3.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/08/26/6b66c26b-09ba-4f9b-852d-69271ffd46cd__kpassworddialog3.png > > > Thanks, > > Elvis Angelaccio > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124905: Win: Hide console window for binaries in LIBEXEC
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124905/#review84496 --- Wait, Wait, Wait. 1) The difference between console apps and GUI apps is that console apps actually have stdin, stdout and stderr streams. So using or not using a console app actually depends on if you need to have these streams! 2) In kde4 (as in standard cmake) the default when you use add_executable is a console application, and if you add WIN32 you'll get a GUI application. In kf5 it was decided that it makes much more sense to mark non-gui applications explicitly, similar to how it is done in qmake (CONFIG += CONSOLE); this is done by the set_target_properties or the ecm macro. About your problem of console windows: there is a different solution for that (it depends on the way the executables are run in QProcess), but I would need to look into the KDE4 code which starts kdeinit4.exe. kdeinit4 *is* a console app. - Patrick Spendrin On Aug. 27, 2015, 7:31 vorm., Kevin Funk wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124905/ > --- > > (Updated Aug. 27, 2015, 7:31 vorm.) > > > Review request for KDE Frameworks, Alex Merry, David Faure, and Boudewijn > Rempt. > > > Repository: kio > > > Description > --- > > Win: Hide console window for binaries in LIBEXEC > > > Diffs > - > > src/ioslaves/http/CMakeLists.txt 76a8e2800b84c312431cc1996ac81d1ef6fb5cfc > src/ioslaves/http/kcookiejar/CMakeLists.txt > 7b4778d1f67c1ad9f9edcaa4692b39ee6fe3f365 > src/kioexec/CMakeLists.txt 91284a3a61b86770b4d1939da52d256840803608 > src/kioslave/CMakeLists.txt e02febd380b268c596e8ecc3b745b6f50993ab4e > src/kpac/CMakeLists.txt fc5989714480ca49b5bd72e1c7b458b26bd0d9bc > > Diff: https://git.reviewboard.kde.org/r/124905/diff/ > > > Testing > --- > > > Thanks, > > Kevin Funk > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
