D5143: Introduce fetch-translations build command

apol added a comment. In https://phabricator.kde.org/D5143#97847, @aacid wrote: > That creates a dependency for ki18n for frameworks that only use .ts files, no? It's not really a dependency. It just won't do much over there. AFAIK. FWIW, I thought this for KI18n framework

D5143: Introduce fetch-translations build command

aacid added a comment. That creates a dependency for ki18n for frameworks that only use .ts files, no? REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D5143 To: apol, #frameworks, #build_system, kfunk, ltoscano, aacid Cc: sitter

D5143: Introduce fetch-translations build command

apol added a comment. In https://phabricator.kde.org/D5143#97840, @aacid wrote: > why find_package(KF5I18n) ? Because `ki18n_install(po)` REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D5143 To: apol, #frameworks, #build_system, kfunk,

D5143: Introduce fetch-translations build command

aacid added a comment. why find_package(KF5I18n) ? REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D5143 To: apol, #frameworks, #build_system, kfunk, ltoscano, aacid Cc: sitter

D5167: Move .po and .ts files look-up to build-time

aacid added a comment. s/Tried/try REPOSITORY R249 KI18n REVISION DETAIL https://phabricator.kde.org/D5167 To: apol, #frameworks, sitter, ltoscano, ilic Cc: aacid

D5167: Move .po and .ts files look-up to build-time

aacid added a comment. Tried it in kde-l10n-sr for example REPOSITORY R249 KI18n REVISION DETAIL https://phabricator.kde.org/D5167 To: apol, #frameworks, sitter, ltoscano, ilic Cc: aacid

D5167: Move .po and .ts files look-up to build-time

aacid added a comment. Have you tried this? That commented out test doesn't seem like a good idea. REPOSITORY R249 KI18n REVISION DETAIL https://phabricator.kde.org/D5167 To: apol, #frameworks, sitter, ltoscano, ilic Cc: aacid

D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.

habacker added inline comments. INLINE COMMENTS > kbugreport.cpp:527 > if (command.isEmpty()) { > -command = QFile::decodeName(CMAKE_INSTALL_PREFIX "/" > KF5_LIBEXEC_INSTALL_DIR "/ksendbugmail"); > +command = QFile::decodeName(CMAKE_INSTALL_PREFIX "/" >

D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.

habacker added a comment. I did not took a look into every location where an executable is installed into KDE_INSTALL_LIBEXECDIR_KF5, but I guess on Windows any application which may be started *only* by a KF5 provided api may be located in the libexec dir ; all other needs to stay into

D5181: API dox: fix missing note to call setXMLFile with KParts::MainWindow

This revision was automatically updated to reflect the committed changes. Closed by commit R306:c86a0f9f7de9: API dox: fix missing note to call setXMLFile with KParts::MainWindow (authored by kossebau). REPOSITORY R306 KParts CHANGES SINCE LAST UPDATE

D5181: API dox: fix missing note to call setXMLFile with KParts::MainWindow

kossebau added a comment. > Also note that lxr finds all calls to setXMLFile, including those in parts and plugins, while here we're only talking about kparts mainwindows. Eh, I had made the extra effort to first do string search for "KParts::MainWindow", then manually grep in linked

D5185: prevent signals in glib2 be defined by QT

dfaure accepted this revision. dfaure added a comment. This revision is now accepted and ready to land. Ah, networkmanager-qt itself uses KDEFrameworkCompilerSettings so it gets -DQT_NO_SIGNALS_SLOTS_KEYWORDS, i.e. signals isn't defined. But indeed this is an installed public header, so the

D5181: API dox: fix missing note to call setXMLFile with KParts::MainWindow

dfaure accepted this revision. dfaure added a comment. This revision is now accepted and ready to land. I agree. The person who wrote this API doc was aiming for something slightly simpler (one less method to call), but my original design was for everyone to call setXMLFile, and it would

D5181: API dox: fix missing note to call setXMLFile with KParts::MainWindow

kossebau added a comment. In https://phabricator.kde.org/D5181#97662, @dfaure wrote: > Not sure which solution is better. Considered that alternative as well, but then chose to propose the given patch for these reasons: - code supporting KF <5.34 would still need some

D5185: prevent signals in glib2 be defined by QT

RobberPhex created this revision. RobberPhex added a project: Frameworks. REVISION SUMMARY Because signals in glib2 be defined by QT, cause Bug 378109 - signals in glib2 was defined by QT . This solved this. TEST PLAN Use nm_conn.cpp

D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.

dfaure added a comment. If "findable by dbus services" is the only argument for polluting bin with libexec binaries on Windows, then it doesn't apply to *everything* in libexec, only to a handful of executables. lib64/libexec/kauth/backlighthelper lib64/libexec/kauth/discretegpuhelper

D5181: API dox: fix missing note to call setXMLFile with KParts::MainWindow

dfaure added a comment. Seems right. The alternative is to make it work. Not sure which solution is better. - kxmlgui/src/kxmlguiwindow.cpp +++ kxmlgui/src/kxmlguiwindow.cpp @@ -203,6 +203,8 @@ void KXmlGuiWindow::setupGUI(const QSize , StandardWindowOptions opt if

D5173: Fix 'Installation of ksendbugmail.exe conflicts with related KDE4 package'.

habacker added a comment. You saw the related bug report at https://bugs.kde.org/show_bug.cgi?id=374347 ? "ksendbugmail is installed into KDE_INSTALL_LIBEXECDIR_KF5, which seems to be set on Windows to 'bin'. At KDE4 times all executables are installed in /bin to be findable by dbus

D5181: API dox: fix missing note to call setXMLFile with KParts::MainWindow

kossebau edited the summary of this revision. REPOSITORY R306 KParts REVISION DETAIL https://phabricator.kde.org/D5181 To: kossebau, dfaure, elvisangelaccio, #frameworks

D5181: API dox: fix missing note to call setXMLFile with KParts::MainWindow

kossebau edited reviewers, added: Frameworks; removed: KDevelop. kossebau removed a subscriber: Frameworks. REPOSITORY R306 KParts REVISION DETAIL https://phabricator.kde.org/D5181 To: kossebau, dfaure, elvisangelaccio, #frameworks

Re: Review Request 128159: Suggest to use setupGUI() instead of setXMLFile()

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128159/#review102950 --- Not using "Create" with the setupGUI() call though ran

D5181: API dox: fix missing note to call setXMLFile with KParts::MainWindow

kossebau created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY Calling KXmlGuiWindow::setupGUI(flags, xmlfile) without the "Create" flag will result in the xmlfile argument being ignored. So

Re: Review Request 129983: [RFC] PoC patch for polkit support in kio.

> On March 25, 2017, 4:30 p.m., Elvis Angelaccio wrote: > > src/ioslaves/file/file.cpp, line 1428 > > > > > > I tried to delete a folder (`kioclient5 remove /opt/test/`) but I > > didn't get this warning. > >

Re: Review Request 129983: [RFC] PoC patch for polkit support in kio.

> On March 22, 2017, 10:08 a.m., Elvis Angelaccio wrote: > > src/ioslaves/file/kauth/file.actions, lines 1-5 > > > > > > I don't see the advantage of using a single kauth action. This way you > > are generating

Re: Review Request 129983: [RFC] PoC patch for polkit support in kio.

> On March 25, 2017, 4:30 p.m., Elvis Angelaccio wrote: > > src/ioslaves/file/file.cpp, line 1423 > > > > > > `kioclient5 remove /opt/test/ /opt/test2/` shows this warning, while I > > was expecting the one

Re: Review Request 129983: [RFC] PoC patch for polkit support in kio.

> On March 22, 2017, 10:08 a.m., Elvis Angelaccio wrote: > > src/ioslaves/file/kauth/file.actions, lines 1-5 > > > > > > I don't see the advantage of using a single kauth action. This way you > > are generating

D5178: QtCurve/Qt5 : further KF5 adaptation

rjvbb added a comment. KWin5 context menus with an item selected, with my regular light desktop theme and the Breeze Dark palette (with and without the patch). QtCurve is configured to render the menu backdrop with a 100% HSV-based shade lightening (the main reason why KWin's context

D5178: QtCurve/Qt5 : further KF5 adaptation

rjvbb added a comment. KWin5 context menu when (only) the application uses the Breeze Dark palette, with and without the current patch. F3241430: qtcurve-winmenu-brdark-unreadable.png F3241429: qtcurve-winmenu-brdark.png

D5178: QtCurve/Qt5 : further KF5 adaptation

rjvbb added a comment. Menu appearance with my regular light desktop palette and when only the application (oxygen-demo5) was switched to the Breeze Dark palette. F3241388: qtcurve-winmenu.png F3241387: qtcurve-menu.png

D5178: QtCurve/Qt5 : further KF5 adaptation

rjvbb updated this revision to Diff 12817. rjvbb added a comment. this version attempts to take a few settings into account for rendering the items in the special-case KWin context menus. CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D5178?vs=12799=12817 REVISION DETAIL