Re: Review Request 122987: Allow user to specify path to myspell dictionary files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122987/#review87098 --- May as well drop this now, it's largely superceded by code in in repo already, for example, https://quickgit.kde.org/?p=sonnet.git&a=commit&h=0e6edac621fbd366b126ebd851fbea21355e02d0 - Rex Dieter On April 27, 2015, 1:30 p.m., Eugene Shalygin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122987/ > --- > > (Updated April 27, 2015, 1:30 p.m.) > > > Review request for KDE Frameworks and kdelibs. > > > Repository: sonnet > > > Description > --- > > Not on all systems myspell dictionaries are located in > /usr/share/myspell/dicts/, which is hardcoded in the hunspell plugin > sources. For instance, on Gentoo it is /usr/share/myspell/. So let the user > define this path. > > > Diffs > - > > src/plugins/hunspell/CMakeLists.txt e35fe8c > src/plugins/hunspell/config-hunspellplugin.h.cmake PRE-CREATION > src/plugins/hunspell/hunspellclient.cpp 46963ef > src/plugins/hunspell/hunspelldict.cpp fda4a4c > > Diff: https://git.reviewboard.kde.org/r/122987/diff/ > > > Testing > --- > > hunspell plugin began to work on Gentoo > > > Thanks, > > Eugene Shalygin > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
Mirko Boehm wrote: > Pretty strong language. Not much proof. Do you *know* how Red Hat or SuSE > build their packages? I can vouche for fedora/redhat that the buildsystem does not have internet access. -- rex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115683: Install app desktop files to share/applications, not in a kde5 subdir
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115683/#review49689 --- fyi, http://standards.freedesktop.org/menu-spec/menu-spec-latest.html , supporting vendor prefixes are not only a good idea, but is strongly encouraged. "... it is recommended that providers of desktop-files ensure that all desktop-file ids start with a vendor prefix." - Rex Dieter On Feb. 12, 2014, 10:37 a.m., Alex Merry wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115683/ > --- > > (Updated Feb. 12, 2014, 10:37 a.m.) > > > Review request for Build System, Extra Cmake Modules, KDE Frameworks, and > David Faure. > > > Repository: extra-cmake-modules > > > Description > --- > > Install app desktop files to share/applications, not in a kde5 subdir > > Given that binaries are all installed in PREFIX/bin, and have to avoid > clashes, doing the same for desktop files is no great issue, and > installing into a subdirectory of applications/ just complicates matters > for client code that needs to refer to the desktop file (is it > "kde5-foo[.desktop]", "kde5/foo[.desktop]" or just "foo[.desktop]"?). > > > Diffs > - > > kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 > > Diff: https://git.reviewboard.kde.org/r/115683/diff/ > > > Testing > --- > > > Thanks, > > Alex Merry > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115683: Install app desktop files to share/applications, not in a kde5 subdir
> On Feb. 13, 2014, 4:28 a.m., Rex Dieter wrote: > > fyi, http://standards.freedesktop.org/menu-spec/menu-spec-latest.html , > > supporting vendor prefixes are not only a good idea, but is strongly > > encouraged. "... it is recommended that providers of desktop-files ensure > > that all desktop-file ids start with a vendor prefix." > > Alex Merry wrote: > However, in practice, dealing with the MPRIS spec > (http://specifications.freedesktop.org/mpris-spec/latest/Media_Player.html#Property:DesktopEntry) > I've found it was just an absolute pain to deal with. Please at least allow for some discussion and feedback, before introducing such a big change. It will likely have significant impact on downstream distributions. - Rex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115683/#review49689 --- On Feb. 12, 2014, 10:37 a.m., Alex Merry wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115683/ > --- > > (Updated Feb. 12, 2014, 10:37 a.m.) > > > Review request for Build System, Extra Cmake Modules, KDE Frameworks, and > David Faure. > > > Repository: extra-cmake-modules > > > Description > --- > > Install app desktop files to share/applications, not in a kde5 subdir > > Given that binaries are all installed in PREFIX/bin, and have to avoid > clashes, doing the same for desktop files is no great issue, and > installing into a subdirectory of applications/ just complicates matters > for client code that needs to refer to the desktop file (is it > "kde5-foo[.desktop]", "kde5/foo[.desktop]" or just "foo[.desktop]"?). > > > Diffs > - > > kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 > > Diff: https://git.reviewboard.kde.org/r/115683/diff/ > > > Testing > --- > > > Thanks, > > Alex Merry > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115683: Install app desktop files to share/applications, not in a kde5 subdir
> On Feb. 13, 2014, 4:28 a.m., Rex Dieter wrote: > > fyi, http://standards.freedesktop.org/menu-spec/menu-spec-latest.html , > > supporting vendor prefixes are not only a good idea, but is strongly > > encouraged. "... it is recommended that providers of desktop-files ensure > > that all desktop-file ids start with a vendor prefix." > > Alex Merry wrote: > However, in practice, dealing with the MPRIS spec > (http://specifications.freedesktop.org/mpris-spec/latest/Media_Player.html#Property:DesktopEntry) > I've found it was just an absolute pain to deal with. > > Rex Dieter wrote: > Please at least allow for some discussion and feedback, before > introducing such a big change. It will likely have significant impact on > downstream distributions. > > Alex Merry wrote: > What would be an appropriate forum for such a discussion? Certainly the > few people on kde-frameworks-devel who showed any interest in the topic were > in favour of the change. kde-packagers, maybe? > > A quick look at my /usr/share/applications suggests that only KDE > software uses a subdirectory. Other software seems to use filename prefixes > (like gnome- and xfce-) when the software has a generic name (gnome-disks, > xfce-settings-manager), but no prefix at all otherwise (Thunar and evolution, > for example, have no prefix). Given how my distro (Archlinux) does things, > these almost certainly reflect the upstream decisions of those projects. As far as discussion is concerned, kde-core-devel would be appropriate I think. I don't care which style is used (prefix/ or prefix-) personally. - Rex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115683/#review49689 --- On Feb. 12, 2014, 10:37 a.m., Alex Merry wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115683/ > --- > > (Updated Feb. 12, 2014, 10:37 a.m.) > > > Review request for Build System, Extra Cmake Modules, KDE Frameworks, and > David Faure. > > > Repository: extra-cmake-modules > > > Description > --- > > Install app desktop files to share/applications, not in a kde5 subdir > > Given that binaries are all installed in PREFIX/bin, and have to avoid > clashes, doing the same for desktop files is no great issue, and > installing into a subdirectory of applications/ just complicates matters > for client code that needs to refer to the desktop file (is it > "kde5-foo[.desktop]", "kde5/foo[.desktop]" or just "foo[.desktop]"?). > > > Diffs > - > > kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 > > Diff: https://git.reviewboard.kde.org/r/115683/diff/ > > > Testing > --- > > > Thanks, > > Alex Merry > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124610: do not install namelink for private library
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124610/#review83440 --- Ship it! definitely a "good thing" for private libraries (without public api). - Rex Dieter On Aug. 4, 2015, 8:04 a.m., Harald Sitter wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124610/ > --- > > (Updated Aug. 4, 2015, 8:04 a.m.) > > > Review request for Baloo, Build System and KDE Frameworks. > > > Repository: baloo > > > Description > --- > > please note that the private target is appearing in the resulting cmake > config all the same and we cannot prevent this because of a cmake oddity > Alex Merry was kind enough to track down [1]. > testing suggests that this is however not breaking anything (what with the > library being private). > > [1] http://public.kitware.com/pipermail/cmake-developers/2015-July/025798.html > > > Diffs > - > > src/engine/CMakeLists.txt 8e2b5b9c0294a08142f4dc486eecab442167b1ec > > Diff: https://git.reviewboard.kde.org/r/124610/diff/ > > > Testing > --- > > make && make install > no .so symlink installed > > made sure there is no symlink on the system and rebuilt gwenview: > gwenview builds just fine > > > Thanks, > > Harald Sitter > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122987: Allow user to specify path to myspell dictionary files
> On April 7, 2015, 1:44 a.m., Aleix Pol Gonzalez wrote: > > This doesn't let the user change the path but the distributor, that's quite > > a different thing. Maybe it should be a runtime check? Ideally yes, but the approach taken here so far is at least an incremental improvement over the status quo. So, I wouldn't let "perfect" be the enemy of "good" here - Rex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122987/#review78586 --- On April 27, 2015, 1:30 p.m., Eugene Shalygin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122987/ > --- > > (Updated April 27, 2015, 1:30 p.m.) > > > Review request for KDE Frameworks and kdelibs. > > > Repository: sonnet > > > Description > --- > > Not on all systems myspell dictionaries are located in > /usr/share/myspell/dicts/, which is hardcoded in the hunspell plugin > sources. For instance, on Gentoo it is /usr/share/myspell/. So let the user > define this path. > > > Diffs > - > > src/plugins/hunspell/CMakeLists.txt e35fe8c > src/plugins/hunspell/config-hunspellplugin.h.cmake PRE-CREATION > src/plugins/hunspell/hunspellclient.cpp 46963ef > src/plugins/hunspell/hunspelldict.cpp fda4a4c > > Diff: https://git.reviewboard.kde.org/r/122987/diff/ > > > Testing > --- > > hunspell plugin began to work on Gentoo > > > Thanks, > > Eugene Shalygin > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122987: Allow user to specify path to myspell dictionary files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122987/#review83458 --- Ship it! This is the obvious easy fix (I was about to submit when I noticed this already-open reviewboard submission). Given the polish and feedback already (and lack of any notable objections), let's get it committed asap. - Rex Dieter On April 27, 2015, 1:30 p.m., Eugene Shalygin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122987/ > --- > > (Updated April 27, 2015, 1:30 p.m.) > > > Review request for KDE Frameworks and kdelibs. > > > Repository: sonnet > > > Description > --- > > Not on all systems myspell dictionaries are located in > /usr/share/myspell/dicts/, which is hardcoded in the hunspell plugin > sources. For instance, on Gentoo it is /usr/share/myspell/. So let the user > define this path. > > > Diffs > - > > src/plugins/hunspell/CMakeLists.txt e35fe8c > src/plugins/hunspell/config-hunspellplugin.h.cmake PRE-CREATION > src/plugins/hunspell/hunspellclient.cpp 46963ef > src/plugins/hunspell/hunspelldict.cpp fda4a4c > > Diff: https://git.reviewboard.kde.org/r/122987/diff/ > > > Testing > --- > > hunspell plugin began to work on Gentoo > > > Thanks, > > Eugene Shalygin > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
D15091: Compile python bindings with the same sipname used by PyQt
rdieter added a comment. Why are you simply not using all PYQT_CONFIGURATION["sip_flags"]? REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D15091 To: arojas, #frameworks, bruns Cc: rdieter, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns
D15091: Compile python bindings with the same sipname used by PyQt
rdieter added a comment. I was asking mostly because that's what pyqt upstream strongly suggested (to use all sip_flags) when I asked them. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D15091 To: arojas, #frameworks, bruns Cc: rdieter, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns
D15091: Compile python bindings with the same sipname used by PyQt
rdieter added a comment. These 2 threads: https://www.riverbankcomputing.com/pipermail/pyqt/2018-August/040759.html https://www.riverbankcomputing.com/pipermail/pyqt/2018-August/040771.html REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D15091 To: arojas, #frameworks, bruns Cc: rdieter, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns
Re: what about the scalable subdir in the oxygen-icons5 sources?
René J. V. Bertin wrote: >> So all the PNG versions are there as handcrafted optimized versions of >> their SVG counterpart, so the icons are still usable when needed in sizes >> of 16,22,24,32,48,... > > Isn't that an answer to the question "why are there also png icons" (or to > "why are so many provided as svgs for a particular bitmap size")? > >> SVG versions no longer need handcrafted substitutes) that would not >> really be recommended, so no-one has yet added support for that. > > I actually discovered the existence of the scalable icons because of > "oxygen- icons5-scalable" packages provided by Fedora and Arch. I'm not aware of fedora providing any such thing. As far as I know, the .svg icons included in the tarball is generally considered the "source code" for the shipped (generally png) icons -- Rex
Re: what about the scalable subdir in the oxygen-icons5 sources?
René J. V. Bertin wrote: > Rex Dieter wrote: > >> I'm not aware of fedora providing any such thing. > > I still had the link in my terminal scrollback: > http://ftp.gwdg.de/pub/opensuse/tumbleweed/repo/oss/suse/noarch/oxygen5-icon-theme-scalable-5.42.0-1.1.noarch.rpm That's an opensuse rpm, not fedora or arch (as you'd previously mentioned). -- rex
