D24453: [RFC] Unify style of new Kirigami.ListSectionHeader and CategoryDrawer
staniek removed a reviewer: KEXI. REPOSITORY R276 KItemViews BRANCH newcategorystyle (branched from master) REVISION DETAIL https://phabricator.kde.org/D24453 To: davidre, #frameworks, #vdg, #konversation, #kde_edu, #kde_pim, #kpublictransport, #amarok, ngraham, #kexi Cc: ndavis, ognarb, ngraham, kde-frameworks-devel, LeGast00n, GB_2, michaelh, bruns
Re: Review Request 129253: Support non integer scale factors in kiconengine
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129253/#review100239 --- > didn't look blurry on mouseover Did you test particular theme or can we assume lines are sharp regardless of theme? (for the record, when I removed 24x24 icons I got blurry icons for default Windows style on Windows as 24px is a standard for toolbars) - Jarosław Staniek On Oct. 24, 2016, 5:06 p.m., David Edmundson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129253/ > --- > > (Updated Oct. 24, 2016, 5:06 p.m.) > > > Review request for KDE Frameworks and Christoph Feck. > > > Repository: kiconthemes > > > Description > --- > > Support non integer scale factors in kiconengine > > > Diffs > - > > src/kiconengine.cpp c31829e82237a7432e3b7c6b1cf85cc3b2bc3ebe > > Diff: https://git.reviewboard.kde.org/r/129253/diff/ > > > Testing > --- > > Ran system settings with QT_SCALE_FACTOR=2.3 > didn't look blurry on mouseover > > > Thanks, > > David Edmundson > >
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/#review99926 --- Reposting here, proposing to reopen it. After a while: I think forcing to skip Qt LTS and going for 5.8.0 is not practical. Are users of KIO and alike forced to patch KF5 to remove unwanted "black windows"? That would look like unfortunate for developer experience of KF5 on Windows. That's what exactly I am facing (and in fact migrating away from dbus too, thus decreasing my use of KF5 unfortunately on Windows). Can we have a temporary fix at ECM of KF5 level (e.g. for Qt < 5.8.0)? Kevin wrote: > Well, you can always patch Qt? > > Emerge applies that patch to qtbase already. So when you use Emerge, your issue is fixed. > Regarding upstream: I didn't push it to anything below Qt 5.8 b/c it's a behavioral change after all. Not a simple bug fix. > I'm lacking the motivation/time do so unfortunately. I've already spent significant amount of my time on this issue, not planning to continue. First, thanks for your time Kevin! At my side, I am patching KF5 but am not very happy since we were close to have a solution and keep it 'proactively' until nobody is using Qt < 5.8.[*] This post isn't a request to grab your time away from the main project. Because I don't know if I'll be posting complete patch, so let's just have a reminder here for others that the workaround at the very downstream level is one of the worst solutions. The only worse thing is potential users of KF5 giving up for so easily avoidable issue. We can even have an option that sets WIN32, just not by default. In theory Qt can be patched but I am not asking about the KDE-windows' development team itself using emerge. Sorry if that was not clear. I am more wondering about where do we want to be with KF5 on Windows for 3rd-party users that would eventually download prepackaged libs. I'd like to think about KF5 like about similar product as Qt is. Stable API with (eventually) binaries available maybe via shiny installer. That's the way of consumption for most users not only on Windows. I think we don't need to discuss that there is Qt 5.6 LTS, why it exists and was demanded, and that users don't compile Qt. And that many people will stay with LTS for a long time. Or with Qt 5.7. And with not the newest compilers for that matter (even if this is unrelated to this very bug). Because what we have is perceived as a bug or at least non-professional behavior. So if patching is performed, and users are motivated to use the KF5 bits in question nevertheless, it's the KF5 that would be patched. While better than asking to patch the Qt, that would be still unfortunate in my opinion because we have all means to act at our end even it "that's not our fault and the one-liner does not belong to KF5". [*] That was more or less an attitude I practiced when developed the 1st KDE on Windows port in 2004 :) - Jarosław Staniek On July 11, 2016, 6:15 p.m., Kevin Funk wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124905/ > --- > > (Updated July 11, 2016, 6:15 p.m.) > > > Review request for KDE Frameworks, Alex Merry and David Faure. > > > 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 > >
[Differential] [Updated] D2854: New: ECMGenerateApiDox, for generating qch & tag files
staniek added a comment. Added myself as reviewer, let's use Reviewers field so that people can see what's todo on the Phab home page. REVISION DETAIL https://phabricator.kde.org/D2854 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: kossebau, staniek Cc: staniek, winterz, ochurlaud, #kdevelop, #frameworks
[Differential] [Updated] D2854: New: ECMGenerateApiDox, for generating qch & tag files
staniek added a reviewer: staniek. REVISION DETAIL https://phabricator.kde.org/D2854 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: kossebau, staniek Cc: staniek, winterz, ochurlaud, #kdevelop, #frameworks
Re: Review Request 127462: Add support for XDG_*_HOME enviroment variables.
> On March 24, 2016, 10:15 a.m., Jarosław Staniek wrote: > > My thoughts mostly related to non-Plasma, non-XDG run environments. > > > > KF5 is a great addition, in hierarchy often sitting aside of Qt, not a part > > of XDG-compliant desktop. As such we can't say too much about the > > underlying OS. It may be XDG-compliant but athis can be a decission at > > various levels: by application developer or on deployment. Things can of > > course also change after the binary is compiled. > > > > It's hard to see any benefit that apps 'pretend' being XDG-compliant by > > setting vartiables this way on, say, MS Windows or Mac. Qt applications on > > these systems do not traditionally alter the OS' paradigm, they are.. just > > apps, as native as possible/reasonable. Example: there are portable apps > > (on an USB stick) - I believe we can benefit if we help making them. These > > apps choose not to integrate too much with what's found on the system, > > often the user account is shared or temporary. > > > > Setting the variable makes KConfig closer to specific groups of desktop, > > which is a a small step back. People may be interested in KConfig lib as a > > general purpose utility in their apps. > > I'd compare setting the variable this way to setting Windows' USERPROFILE > > variable on Linux systems, just because it's standard under the former and > > under Wine. it does not hurt but leaves bad taste. > > > > So the behaviour at least shall be ifdef'd and the ifdef shall depend on OS > > for which we're building. But if the same binary should behave well in > > various environments, I am unsure about hardcoding the behaviour. Also I am > > not sure if this behaviour should be ON by default. I'd rather have it OFF > > if it's present at all. > > Sandro Knauß wrote: > Well I see it the other way around. Without support of XDG variables > replacement, we need to use env varaible that are available on all systems > f.ex. $HOME, so the only way to set the datalocaltion to write it hardcoded > in the config to $HOME/.local/share. This is really ony true for linux for > others OSes you want to have other diretories. So now we are able to use > XDG_DATA_HOME to be used in kconfig and it will be replaced for linux to > $HOME/.local/share, for windows to C:/Users//AppData/Local and so on. > We use QStandardsPaths for replacing so if the replacement is not correct > for an OS this is a bug on Qt side, that should be fixed :D > > And I can't see how this support can harm anyone - if the env is set this > is prefered and only if it is not set it is replaced. No dependecy is added > and applications are free to not use it at all. If you use XDG_*_HOME without > this patch you will return an empty string for it: > > i[$e] = $XDG_DATA_HOME/bla > > -> will return /bla > > with the patch you will get: > $HOME/.local/share/bla ( for linux) > C:/Users//AppData/Local/bla ( for windows) > [...] Before we discuss anything, let's narrow to non-Unix OSes (considering Mac OS X as non-Unix): - Does these OSes use XDG_ to locate anything? I can't spot. - Isn't it misleading to use the XDG_ variables to pass the locations on these OSes? Don't we have a choice? Digression: I am asking because one quality attribute of KF5 for could be to behave or "think" like Qt would, without spreading a "Unix-y" / "XDG" feel when not really necessary. Non-Unix OSes have own equivalents for many things (e.g. xdg-open), at times these equivalents can be found inferior but we, not being authors of the OSes, can just say "let them be such". We have enough of layers and emulators, subsystems e.g. on Windows (see .NET or chrome-based hybrid apps). Frameworks for developing native apps on these OSes shall not attempt to fix these system facilities but just integrate. Users wanting XDG experience have choice to use XDG-compliant systems... Summing up, an #ifdef and update of documentation would be nice. My 2c... - Jarosław --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127462/#review93920 --- On March 22, 2016, 4:23 p.m., Sandro Knauß wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127462/ > --- > > (Updated March 22, 2016, 4:23 p.m.) > > > Review request for KDE Frameworks and Matthew
Re: Review Request 127462: Add support for XDG_*_HOME enviroment variables.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127462/#review93920 --- My thoughts mostly related to non-Plasma, non-XDG run environments. KF5 is a great addition, in hierarchy often sitting aside of Qt, not a part of XDG-compliant desktop. As such we can't say too much about the underlying OS. It may be XDG-compliant but athis can be a decission at various levels: by application developer or on deployment. Things can of course also change after the binary is compiled. It's hard to see any benefit that apps 'pretend' being XDG-compliant by setting vartiables this way on, say, MS Windows or Mac. Qt applications on these systems do not traditionally alter the OS' paradigm, they are.. just apps, as native as possible/reasonable. Example: there are portable apps (on an USB stick) - I believe we can benefit if we help making them. These apps choose not to integrate too much with what's found on the system, often the user account is shared or temporary. Setting the variable makes KConfig closer to specific groups of desktop, which is a a small step back. People may be interested in KConfig lib as a general purpose utility in their apps. I'd compare setting the variable this way to setting Windows' USERPROFILE variable on Linux systems, just because it's standard under the former and under Wine. it does not hurt but leaves bad taste. So the behaviour at least shall be ifdef'd and the ifdef shall depend on OS for which we're building. But if the same binary should behave well in various environments, I am unsure about hardcoding the behaviour. Also I am not sure if this behaviour should be ON by default. I'd rather have it OFF if it's present at all. - Jarosław Staniek On March 22, 2016, 4:23 p.m., Sandro Knauß wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127462/ > --- > > (Updated March 22, 2016, 4:23 p.m.) > > > Review request for KDE Frameworks and Matthew Dawson. > > > Repository: kconfig > > > Description > --- > > According to freedesktop specification XDG_*_HOME env varaible should be > replaced, if they are not setted with default values. > > https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html > > as qgetenv only calls getenv, so no path is traslated to it default values. > So we have to add this replacement manually. This would help to use > XDG_*_HOME more often in configfiles. > > > Diffs > - > > autotests/kconfigtest.cpp e92197f3be57ead47b70ca5d040474e7a554c416 > src/core/kconfig.cpp 07fa6f552c61c52cc1dd64a1c5fb0e2f00873d50 > > Diff: https://git.reviewboard.kde.org/r/127462/diff/ > > > Testing > --- > > Adding tests for XDG_*_HOME variables. > > > Thanks, > > Sandro Knauß > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 127031: Add function to get runtime frameworks version information
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127031/#review93814 --- Just wanted to say: thanks for this addition! It is useful for collecting feedback/support information (Kexi does it per user demand as a part of its QA -- https://blogs.kde.org/2013/12/09/usage-stats). - Jarosław Staniek On Feb. 25, 2016, 2:02 a.m., David Edmundson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127031/ > --- > > (Updated Feb. 25, 2016, 2:02 a.m.) > > > Review request for KDE Frameworks. > > > Repository: kcoreaddons > > > Description > --- > > Adds a method similar to qVersion() that returns a string of the > frameworks version being run. This differs from the header file which > can only provide the version this app is compiled against. > > The intended usage is in drkonqi system information. > > > Diffs > - > > src/lib/CMakeLists.txt a36eed26a281baf9ef1064dfb9aed3c394c52604 > src/lib/kcoreaddons.h PRE-CREATION > src/lib/kcoreaddons.cpp PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/127031/diff/ > > > Testing > --- > > See https://git.reviewboard.kde.org/r/127032/ > > > Thanks, > > David Edmundson > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 126199: Don't warn when SVG(Z) icons are provided with multiple sizes/levels of detail
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126199/ --- (Updated Nov. 30, 2015, 5:05 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Alex Merry. Changes --- Submitted with commit 18243570bcae0cf02a4a87eff2f1834500ae955d by Jaroslaw Staniek to branch master. Repository: extra-cmake-modules Description --- This change adds SVG(Z) extensions to the list of allowed icons for specific sizes. This technically works and is practiced, e.g. for some Breeze icons. Reasoning: Some SVG icons do not scale well down from 32 to 22 or up from 16 to 22. For such cases icons are typically specially crafted for 22 and 16, at least. Then there's no single icon that be marked as "sc". So warnings such as: CMake Warning at /ECMInstallIcons.cmake:272 (message): Fixed-size icon foo.svg is not PNG or MNG ... are misleading. Diffs - modules/ECMInstallIcons.cmake 549ebe1 Diff: https://git.reviewboard.kde.org/r/126199/diff/ Testing --- ECM no longer warns for projects that use .svg icons of multiple variants (e.g. kreport.git master) Thanks, Jarosław Staniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 126199: Don't warn when SVG(Z) icons are provided with multiple sizes/levels of detail
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126199/ --- Review request for KDE Frameworks and Alex Merry. Repository: extra-cmake-modules Description --- This change adds SVG(Z) extensions to the list of allowed icons for specific sizes. This technically works and is practiced, e.g. for some Breeze icons. Reasoning: Some SVG icons do not scale well down from 32 to 22 or up from 16 to 22. For such cases icons are typically specially crafted for 22 and 16, at least. Then there's no single icon that be marked as "sc". So warnings such as: CMake Warning at /ECMInstallIcons.cmake:272 (message): Fixed-size icon foo.svg is not PNG or MNG ... are misleading. Diffs - modules/ECMInstallIcons.cmake 549ebe1 Diff: https://git.reviewboard.kde.org/r/126199/diff/ Testing --- ECM no longer warns for projects that use .svg icons of multiple variants (e.g. kreport.git master) Thanks, Jarosław Staniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125527: Add mimeTypes() to KPluginMetaData
> On Nov. 28, 2015, 8:10 p.m., Jarosław Staniek wrote:
> > Hi, I see one regression.
> > Before this change I had "MimeType" field. And I've been using this field.
> >
> > Now I miss miss this field and have "KPlugin/MimeTypes" field. This means
> > plugin error if KF5 5.16.x is installed. I cannot fix my sources: if I do
> > users of KF5 <= 5.15.x will get equivalent error.
>
> Alex Richardson wrote:
> Hmm I hadn't thought of that. Sorry for causing a regression. I assume
> you are using kcoreaddons_desktop_to_json() to generate the JSON file
> otherwise this issue shouldn't appear
>
> I see a few ways of working around this in the sources:
>
> - Depend on KF >= 5.16 (easiest but unlikely to be possible)
> - Change MimeType= into X-MyApp-MimeType= and then read that field
> - You could use JSON files directly instead of .desktop files
> - a) add the MimeType string to the root object
> - b) use the 5.16 JSON with a string list and use
> KPluginMetaData::readStringList(rawData()["KPlugin"],
> QStringLiteral("MimeTypes")); for KF <= 5.16
>
> Jarosław Staniek wrote:
> Thanks for the quick reply with options.
>
> Yes, I am using kcoreaddons_desktop_to_json().
>
> The error is at
> https://build.kde.org/job/kdb%20master%20kf5-qt5/36/PLATFORM=Linux,compiler=gcc/testReport/%28root%29/TestSuite/ConnectionTest/
> I did not notice before because CI does not send notification for my
> repos (no idea how to enable them, reported to Sysadmin).
>
> Yes, I plan to switch to JSON files entirely, so now I have extra reason.
>
> Do you think the regression is worth removing or instead some statement
> can be made in the docs for kcoreaddons_desktop_to_json() about what are the
> guaranteed contents of the JSON?
PS: KPluginMetaData::mimeTypes() is advertised for use but is it good habit to
depend on KF 5.16 just for that?
Personally I am not using it.
- Jarosław
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125527/#review88915
---
On Oct. 6, 2015, 1:42 p.m., Alex Richardson wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125527/
> ---
>
> (Updated Oct. 6, 2015, 1:42 p.m.)
>
>
> Review request for KDE Frameworks, David Faure and Sebastian Kügler.
>
>
> Repository: kcoreaddons
>
>
> Description
> ---
>
> When loading a .desktop file this will parse the XDG MimeType= key
>
> Contrary to KService we don't merge these with ServiceTypes but rather
> have them as a separate property.
>
> REVIEW: 125261
>
> KPluginMetaData: Warn when a list entry is not a JSON list
>
> We still convert single values to a list with one entry but now also
> output a warning.
>
> REVIEW: 125261
>
>
> Diffs
> -
>
> autotests/data/fakeplugin.desktop 30ff9a98d4587507620f70e3c271456877ab1812
> autotests/kpluginmetadatatest.cpp 3af5e1b842b0bc231a5ac001112e141f751d2ff5
> src/lib/plugin/desktopfileparser.h 98d47ddf0f877c4a25928026b3d5fe169cfc9e75
> src/lib/plugin/desktopfileparser.cpp
> 0b03eb154deb58840c91c12658780c0d492b593c
> src/lib/plugin/kpluginmetadata.h 183b0d0583259f7ed74e97858a68c5c388fd0a9a
> src/lib/plugin/kpluginmetadata.cpp b13d6dd52827cc03d9473600aa4d2bab8a95a1d4
>
> Diff: https://git.reviewboard.kde.org/r/125527/diff/
>
>
> Testing
> ---
>
> This is the same as review 125261 but for some reason I kept getting a
> internal server error when I tried to update it.
>
>
> Used this for a WIP port of Okular to new Plugin loading. Could also be used
> by KDevelop instead of the custom X-KDevelop-SupportedMimeTypes property
>
> Requires https://git.reviewboard.kde.org/r/125263/ to ensure that there are
> no regressions
>
>
> Thanks,
>
> Alex Richardson
>
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125527: Add mimeTypes() to KPluginMetaData
> On Nov. 28, 2015, 8:10 p.m., Jarosław Staniek wrote:
> > Hi, I see one regression.
> > Before this change I had "MimeType" field. And I've been using this field.
> >
> > Now I miss miss this field and have "KPlugin/MimeTypes" field. This means
> > plugin error if KF5 5.16.x is installed. I cannot fix my sources: if I do
> > users of KF5 <= 5.15.x will get equivalent error.
>
> Alex Richardson wrote:
> Hmm I hadn't thought of that. Sorry for causing a regression. I assume
> you are using kcoreaddons_desktop_to_json() to generate the JSON file
> otherwise this issue shouldn't appear
>
> I see a few ways of working around this in the sources:
>
> - Depend on KF >= 5.16 (easiest but unlikely to be possible)
> - Change MimeType= into X-MyApp-MimeType= and then read that field
> - You could use JSON files directly instead of .desktop files
> - a) add the MimeType string to the root object
> - b) use the 5.16 JSON with a string list and use
> KPluginMetaData::readStringList(rawData()["KPlugin"],
> QStringLiteral("MimeTypes")); for KF <= 5.16
Thanks for the quick reply with options.
Yes, I am using kcoreaddons_desktop_to_json().
The error is at
https://build.kde.org/job/kdb%20master%20kf5-qt5/36/PLATFORM=Linux,compiler=gcc/testReport/%28root%29/TestSuite/ConnectionTest/
I did not notice before because CI does not send notification for my repos (no
idea how to enable them, reported to Sysadmin).
Yes, I plan to switch to JSON files entirely, so now I have extra reason.
Do you think the regression is worth removing or instead some statement can be
made in the docs for kcoreaddons_desktop_to_json() about what are the
guaranteed contents of the JSON?
- Jarosław
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125527/#review88915
---
On Oct. 6, 2015, 1:42 p.m., Alex Richardson wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125527/
> ---
>
> (Updated Oct. 6, 2015, 1:42 p.m.)
>
>
> Review request for KDE Frameworks, David Faure and Sebastian Kügler.
>
>
> Repository: kcoreaddons
>
>
> Description
> ---
>
> When loading a .desktop file this will parse the XDG MimeType= key
>
> Contrary to KService we don't merge these with ServiceTypes but rather
> have them as a separate property.
>
> REVIEW: 125261
>
> KPluginMetaData: Warn when a list entry is not a JSON list
>
> We still convert single values to a list with one entry but now also
> output a warning.
>
> REVIEW: 125261
>
>
> Diffs
> -
>
> autotests/data/fakeplugin.desktop 30ff9a98d4587507620f70e3c271456877ab1812
> autotests/kpluginmetadatatest.cpp 3af5e1b842b0bc231a5ac001112e141f751d2ff5
> src/lib/plugin/desktopfileparser.h 98d47ddf0f877c4a25928026b3d5fe169cfc9e75
> src/lib/plugin/desktopfileparser.cpp
> 0b03eb154deb58840c91c12658780c0d492b593c
> src/lib/plugin/kpluginmetadata.h 183b0d0583259f7ed74e97858a68c5c388fd0a9a
> src/lib/plugin/kpluginmetadata.cpp b13d6dd52827cc03d9473600aa4d2bab8a95a1d4
>
> Diff: https://git.reviewboard.kde.org/r/125527/diff/
>
>
> Testing
> ---
>
> This is the same as review 125261 but for some reason I kept getting a
> internal server error when I tried to update it.
>
>
> Used this for a WIP port of Okular to new Plugin loading. Could also be used
> by KDevelop instead of the custom X-KDevelop-SupportedMimeTypes property
>
> Requires https://git.reviewboard.kde.org/r/125263/ to ensure that there are
> no regressions
>
>
> Thanks,
>
> Alex Richardson
>
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125527: Add mimeTypes() to KPluginMetaData
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125527/#review88915 --- Hi, I see one regression. Before this change I had "MimeType" field. And I've been using this field. Now I miss miss this field and have "KPlugin/MimeTypes" field. This means plugin error if KF5 5.16.x is installed. I cannot fix my sources: if I do users of KF5 <= 5.15.x will get equivalent error. - Jarosław Staniek On Oct. 6, 2015, 1:42 p.m., Alex Richardson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125527/ > --- > > (Updated Oct. 6, 2015, 1:42 p.m.) > > > Review request for KDE Frameworks, David Faure and Sebastian Kügler. > > > Repository: kcoreaddons > > > Description > --- > > When loading a .desktop file this will parse the XDG MimeType= key > > Contrary to KService we don't merge these with ServiceTypes but rather > have them as a separate property. > > REVIEW: 125261 > > KPluginMetaData: Warn when a list entry is not a JSON list > > We still convert single values to a list with one entry but now also > output a warning. > > REVIEW: 125261 > > > Diffs > - > > autotests/data/fakeplugin.desktop 30ff9a98d4587507620f70e3c271456877ab1812 > autotests/kpluginmetadatatest.cpp 3af5e1b842b0bc231a5ac001112e141f751d2ff5 > src/lib/plugin/desktopfileparser.h 98d47ddf0f877c4a25928026b3d5fe169cfc9e75 > src/lib/plugin/desktopfileparser.cpp > 0b03eb154deb58840c91c12658780c0d492b593c > src/lib/plugin/kpluginmetadata.h 183b0d0583259f7ed74e97858a68c5c388fd0a9a > src/lib/plugin/kpluginmetadata.cpp b13d6dd52827cc03d9473600aa4d2bab8a95a1d4 > > Diff: https://git.reviewboard.kde.org/r/125527/diff/ > > > Testing > --- > > This is the same as review 125261 but for some reason I kept getting a > internal server error when I tried to update it. > > > Used this for a WIP port of Okular to new Plugin loading. Could also be used > by KDevelop instead of the custom X-KDevelop-SupportedMimeTypes property > > Requires https://git.reviewboard.kde.org/r/125263/ to ensure that there are > no regressions > > > Thanks, > > Alex Richardson > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 126196: Fix regression caused by RR 125527
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126196/#review88920 --- Ship it! Brilliant fix. Thanks a lot, Alex! - Jarosław Staniek On Nov. 28, 2015, 11:25 p.m., Alex Richardson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126196/ > --- > > (Updated Nov. 28, 2015, 11:25 p.m.) > > > Review request for KDE Frameworks and Jarosław Staniek. > > > Repository: kcoreaddons > > > Description > --- > > Make sure that applications using kcoreaddons_desktop_to_json() that > depend on reading the MimeType property of the root object still work > > See https://git.reviewboard.kde.org/r/125527/ > > > Diffs > - > > src/lib/plugin/desktopfileparser.cpp > eae91881bafc93b047b81a2b21634223dd5d89f4 > > Diff: https://git.reviewboard.kde.org/r/126196/diff/ > > > Testing > --- > > compiles, tests pass > > > Thanks, > > Alex Richardson > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124065: KMimeType mimeTypeForNameAndData() - mimeTypeForFileNameAndData()
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124065/ --- (Updated July 26, 2015, 9:38 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Laurent Montel. Changes --- Submitted with commit 7c937ed14e89adcc62f8ee050a84c966053307b4 by Jaroslaw Staniek to branch master. Repository: kde-dev-scripts Description --- There's apparent mistake; mimeTypeForNameAndData() does not exist, shall be mimeTypeForFileNameAndData(). Diffs - kf5/convert-kmimetype.pl 363ff21cd46331efe209a5051feca58e971739b2 Diff: https://git.reviewboard.kde.org/r/124065/diff/ Testing --- Thanks, Jarosław Staniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 124065: KMimeType mimeTypeForNameAndData() - mimeTypeForFileNameAndData()
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124065/ --- Review request for KDE Frameworks and Laurent Montel. Repository: kde-dev-scripts Description --- There's apparent mistake; mimeTypeForNameAndData() does not exist, shall be mimeTypeForFileNameAndData(). Diffs - kf5/convert-kmimetype.pl 363ff21cd46331efe209a5051feca58e971739b2 Diff: https://git.reviewboard.kde.org/r/124065/diff/ Testing --- Thanks, Jarosław Staniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 123974: Add more symbols to convert-klineedit.pl
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123974/ --- Review request for KDE Frameworks. Repository: kde-dev-scripts Description --- Add a property names/getters/signals to convert-klineedit.pl. Diffs - kf5/convert-klineedit.pl 33044d8e7812c8fcadedccc77dc6a200f8247bd1 Diff: https://git.reviewboard.kde.org/r/123974/diff/ Testing --- Thanks, Jarosław Staniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123974: Add more symbols to convert-klineedit.pl
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123974/ --- (Updated June 1, 2015, 1:10 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, Aleix Pol Gonzalez and Laurent Montel. Changes --- Submitted with commit 64789d05c9b27a3ae2031738e516ec2d31ab39e4 by Jaroslaw Staniek to branch master. Repository: kde-dev-scripts Description --- Add a property names/getters/signals to convert-klineedit.pl. Diffs - kf5/convert-klineedit.pl 33044d8e7812c8fcadedccc77dc6a200f8247bd1 Diff: https://git.reviewboard.kde.org/r/123974/diff/ Testing --- Thanks, Jarosław Staniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 123902: Missing or when looking for .cmake and CMakeLists.txt files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123902/ --- Review request for KDE Frameworks, Plasma, Kevin Ottens, and Burkhard Lück. Repository: plasma-framework Description --- Missing or when looking for .cmake and CMakeLists.txt files Diffs - src/tools/port-cmake-style.sh e182e60abe32fbcf379871abbe6b491e9678cd25 Diff: https://git.reviewboard.kde.org/r/123902/diff/ Testing --- Finds well now Thanks, Jarosław Staniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123902: Missing or when looking for .cmake and CMakeLists.txt files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123902/ --- (Updated May 25, 2015, 4:06 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, Plasma, Kevin Ottens, and Burkhard Lück. Changes --- Submitted with commit 1fcdc08826659245a4c39ff0cb1b11b02faf by Jaroslaw Staniek to branch master. Repository: plasma-framework Description --- Missing or when looking for .cmake and CMakeLists.txt files Diffs - src/tools/port-cmake-style.sh e182e60abe32fbcf379871abbe6b491e9678cd25 Diff: https://git.reviewboard.kde.org/r/123902/diff/ Testing --- Finds well now Thanks, Jarosław Staniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121379: kwidgetsaddons/kpageview.cpp: remove top-right icon
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121379/#review71632 --- Ship it! Very good, maybe we can assume a silent consent. On the forum I've suggested the pencil icon is misleading and why. http://feinstaub.github.io/struct/img/top-right-icon-plasma5-1.png https://forum.kde.org/viewtopic.php?f=285t=123837p=325691 - Jarosław Staniek On Dec. 7, 2014, 11:49 a.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121379/ --- (Updated Dec. 7, 2014, 11:49 a.m.) Review request for KDE Frameworks, Christoph Feck and Dominik Haumann. Repository: kwidgetsaddons Description --- As mentioned in [KPageView/KTitleWidget: Remove top right icon](https://forum.kde.org/viewtopic.php?f=285t=123837) the top-right icon serves no visible purpose and can even be a distraction. This patch removes the code that adds the icon. Diffs - src/kpageview.cpp 69d1bf9a20549b74557f3fdf9a7057cb74258cb1 Diff: https://git.reviewboard.kde.org/r/121379/diff/ Testing --- Screenshots: http://wstaw.org/m/2014/12/07/kcmshell5_devinfo_-_1before.png (before patch) http://wstaw.org/m/2014/12/07/kcmshell5_devinfo_-_2after.png (after) http://wstaw.org/m/2014/12/07/kcmshell5_mouse_-_1before.png (before patch) http://wstaw.org/m/2014/12/07/kcmshell5_mouse_-_2after.png (after) Thanks, Gregor Mi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
