Review Request 119965: rely on shell package to create the interactive console interface
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119965/ --- Review request for Plasma. Repository: plasma-workspace Description --- This move the KTextEditor dependency out of plasmashell and into a QML component which uses it. This allows plasmashell to carry fewer dependencies while at *runtime* be able to appropriately address different form factors. It also moves the responsibility for showing the interactive scripting console to the shell package which can elect not to provide such a thing, allowing the shell to determine whether there is a console or not and what form it takes. This relies on a one-liner patch to plasma-framework adding the interactive console QML file key to the shell package structure. I'm not going to bother with a review request for that, but will push it before pushing this. Diffs - CMakeLists.txt 6642d780aabe1777cb0457bb9b04e42c72358c9f components/BatteryIcon.qml components/CMakeLists.txt 07c48745652d7ec02147c2314ca08766a386f6b2 components/qmldir components/shellprivate/CMakeLists.txt PRE-CREATION components/shellprivate/Messages.sh PRE-CREATION shell/CMakeLists.txt 4b1dd664c4eae6dbb1832c54411140ce7c11038d shell/interactiveconsole.h d3af64bf456de60140f8a8efd4a4655ba5c6b6dd shell/interactiveconsole.cpp 7096033a3076472a969b9bb19c43053d5e9977f8 shell/scripting/desktopscriptengine.h dd097d228b3982910346fe6f07412fd0137fc372 shell/scripting/desktopscriptengine.cpp 37d138744dd2b56e6b34cdd20f1eef5c79361a40 shell/scripting/scriptengine.h ffb0cbfb435d224f48cd715b66e94449114642db shell/widgetexplorer/kcategorizeditemsviewmodels_p.h shell/widgetexplorer/openwidgetassistant.cpp shell/widgetexplorer/openwidgetassistant_p.h shell/widgetexplorer/plasmaappletitemmodel.cpp shell/widgetexplorer/plasmaappletitemmodel_p.h shell/widgetexplorer/plasmoids.knsrc shell/widgetexplorer/qmldir d808b18cfea863d6910df0cb922eb8e6e1c2bda9 shell/widgetexplorer/widgetexplorer.h shell/widgetexplorer/widgetexplorer.cpp shell/widgetexplorer/widgetexplorerplugin.h 3ee262e52d16feab35999c7963fc06b8653347a0 shell/widgetexplorer/widgetexplorerplugin.cpp f21178beb7279a851c4637fdc66d382d97f1bab9 shell/scripting/scriptengine.cpp 4db966f81d2cdaade21b07165ce6bfdd411c2366 shell/shellcorona.h b032803fe7286ba007a47a80065c6fbbb40a9709 shell/shellcorona.cpp c5447c24a2de5f42cda978e5690a210e15d80b76 shell/widgetexplorer/CMakeLists.txt dd0ea97045417245ac0b2c1a870147f2ff34e4ec shell/widgetexplorer/Messages.sh 3beeea4b3eae941ad88b66ec9af667915b66e950 shell/widgetexplorer/kcategorizeditemsviewmodels.cpp Diff: https://git.reviewboard.kde.org/r/119965/diff/ Testing --- Run with a shell package with InteractiveConsole.qml, used the console to run scripts, opened and closed it, etc. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 119967: Fix systemloadviewer monitorType settings
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119967/ --- Review request for Plasma. Repository: kdeplasma-addons Description --- Fix systemloadviewer monitorType settings The third revision of the port broke the changing of monitor type through settings, it slipped past me because the setting worked when restarting plasmashell. Diffs - applets/systemloadviewer/package/contents/ui/ConditionallyLoadedMonitors.qml 403c01cb93d350e341babb6830277eedd7f06a6c Diff: https://git.reviewboard.kde.org/r/119967/diff/ Testing --- Changing between Bar and Circular monitor types in the plasmoid settings works now as expected. Thanks, Martin Yrjölä ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Request: better override functionality in locale settings
On Wed, Aug 27, 2014 at 11:34 AM, Sebastian Kügler se...@kde.org wrote:
There's more than just metric and imperial. This page gives you a slight
impression of the complexity:
http://en.wikipedia.org/wiki/Imperial_units#Current_use_of_imperial_units
A binary combobox is just not enough to portray this correctly.
I'm actually quite curious what does QLocale do with this complexity. Do
they really do
if (en_GB) {
beer_unit = pint;
milk_unit = liter;
etc...
}
That would be quite strange. I'll investigate and post back.
Cheers
--
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Request: better override functionality in locale settings
On Thu, Aug 28, 2014 at 3:49 AM, Matthew Ruffalo mm...@case.edu wrote: I still strongly, *strongly* disagree that it's acceptable for a user to choose an appropriate locale for override settings. Perhaps I am leaning myself way out the window but I think there is one very portable solution to this problem: writing an own locale defintion [1] and installingconfiguring that. And I do not mean by hand, but through a GUI. This not only allows customization of stuff but also makes every application on the system respect whatever was configured in our KCM. Also it doesn't actually tie into the existing KCM, it would be a standalone 'locale editor' basically. Alas, I have not ever done anything like this so I really very much have no clue whether this would be too much work or even possible. It's just a thought I'd like to put out there :) [1] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html#tag_07_03 HS ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Request: better override functionality in locale settings
On 28 August 2014 09:31, Harald Sitter sit...@kde.org wrote: On Thu, Aug 28, 2014 at 3:49 AM, Matthew Ruffalo mm...@case.edu wrote: Perhaps I am leaning myself way out the window but I think there is one very portable solution to this problem: writing an own locale defintion [1] and installingconfiguring that. And I do not mean by hand, but through a GUI. This not only allows customization of stuff but also makes every application on the system respect whatever was configured in our KCM. Also it doesn't actually tie into the existing KCM, it would be a standalone 'locale editor' basically. That is indeed The Plan, at least for non-Qt POSIX / glibc using apps :-) John. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Request: better override functionality in locale settings
On 28 August 2014 09:28, Martin Klapetek martin.klape...@gmail.com wrote:
On Wed, Aug 27, 2014 at 11:34 AM, Sebastian Kügler se...@kde.org wrote:
There's more than just metric and imperial. This page gives you a slight
impression of the complexity:
http://en.wikipedia.org/wiki/Imperial_units#Current_use_of_imperial_units
A binary combobox is just not enough to portray this correctly.
I'm actually quite curious what does QLocale do with this complexity. Do
they really do
if (en_GB) {
beer_unit = pint;
milk_unit = liter;
etc...
}
That would be quite strange. I'll investigate and post back.
Yes, the locale code for each each category does determine what
translations will get used for that category. While Qt doesn't (yet)
have that level of complexity, other toolkits may, such as glibc or
gtk or Java or ICU. We're setting a desktop-wide setting here, not
just something for KDE/Qt apps only to use.
John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119965: rely on shell package to create the interactive console interface
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119965/#review65399 --- Ship it! I was definitely bothered by the dependency from ktexteditor, +1 shell/interactiveconsole.h https://git.reviewboard.kde.org/r/119965/#comment45694 Could this be an enum? - Marco Martin On Aug. 28, 2014, 8:17 a.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119965/ --- (Updated Aug. 28, 2014, 8:17 a.m.) Review request for Plasma. Repository: plasma-workspace Description --- This move the KTextEditor dependency out of plasmashell and into a QML component which uses it. This allows plasmashell to carry fewer dependencies while at *runtime* be able to appropriately address different form factors. It also moves the responsibility for showing the interactive scripting console to the shell package which can elect not to provide such a thing, allowing the shell to determine whether there is a console or not and what form it takes. Note that this also moves the widgetexplorer into a common components directory where both it and the interactive console are put into a single plugin. This may want to be changed in future to allow separate plugins to be shipped, but this is better for performance and until shown necessary may as well be this way. This relies on a one-liner patch to plasma-framework adding the interactive console QML file key to the shell package structure. I'm not going to bother with a review request for that, but will push it before pushing this. Diffs - CMakeLists.txt 6642d780aabe1777cb0457bb9b04e42c72358c9f components/BatteryIcon.qml components/CMakeLists.txt 07c48745652d7ec02147c2314ca08766a386f6b2 components/qmldir components/shellprivate/CMakeLists.txt PRE-CREATION components/shellprivate/Messages.sh PRE-CREATION shell/CMakeLists.txt 4b1dd664c4eae6dbb1832c54411140ce7c11038d shell/interactiveconsole.h d3af64bf456de60140f8a8efd4a4655ba5c6b6dd shell/interactiveconsole.cpp 7096033a3076472a969b9bb19c43053d5e9977f8 shell/scripting/desktopscriptengine.h dd097d228b3982910346fe6f07412fd0137fc372 shell/scripting/desktopscriptengine.cpp 37d138744dd2b56e6b34cdd20f1eef5c79361a40 shell/scripting/scriptengine.h ffb0cbfb435d224f48cd715b66e94449114642db shell/widgetexplorer/kcategorizeditemsviewmodels_p.h shell/widgetexplorer/openwidgetassistant.cpp shell/widgetexplorer/openwidgetassistant_p.h shell/widgetexplorer/plasmaappletitemmodel.cpp shell/widgetexplorer/plasmaappletitemmodel_p.h shell/widgetexplorer/plasmoids.knsrc shell/widgetexplorer/qmldir d808b18cfea863d6910df0cb922eb8e6e1c2bda9 shell/widgetexplorer/widgetexplorer.h shell/widgetexplorer/widgetexplorer.cpp shell/widgetexplorer/widgetexplorerplugin.h 3ee262e52d16feab35999c7963fc06b8653347a0 shell/widgetexplorer/widgetexplorerplugin.cpp f21178beb7279a851c4637fdc66d382d97f1bab9 shell/scripting/scriptengine.cpp 4db966f81d2cdaade21b07165ce6bfdd411c2366 shell/shellcorona.h b032803fe7286ba007a47a80065c6fbbb40a9709 shell/shellcorona.cpp c5447c24a2de5f42cda978e5690a210e15d80b76 shell/widgetexplorer/CMakeLists.txt dd0ea97045417245ac0b2c1a870147f2ff34e4ec shell/widgetexplorer/Messages.sh 3beeea4b3eae941ad88b66ec9af667915b66e950 shell/widgetexplorer/kcategorizeditemsviewmodels.cpp Diff: https://git.reviewboard.kde.org/r/119965/diff/ Testing --- Run with a shell package with InteractiveConsole.qml, used the console to run scripts, opened and closed it, etc. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119965: rely on shell package to create the interactive console interface
On Aug. 28, 2014, 8:48 a.m., Marco Martin wrote: shell/interactiveconsole.h, line 158 https://git.reviewboard.kde.org/r/119965/diff/1/?file=307929#file307929line158 Could this be an enum? It could, yes. It means importing an enum into the QML runtime, though, and that means exposing a piece of C++ API somewhere. Currently the QML API is pretty generic and has no bias to a specific C++ implementation. (See https://notes.kde.org/p/Plasma_Shell_Features) In contrast, strings are nice and decoupled from the C++. Documenting the API, something that is currently lacking but which I'm starting to build up in that notes.kde.org page as I go, is necessary in any case. - Aaron J. --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119965/#review65399 --- On Aug. 28, 2014, 8:17 a.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119965/ --- (Updated Aug. 28, 2014, 8:17 a.m.) Review request for Plasma. Repository: plasma-workspace Description --- This move the KTextEditor dependency out of plasmashell and into a QML component which uses it. This allows plasmashell to carry fewer dependencies while at *runtime* be able to appropriately address different form factors. It also moves the responsibility for showing the interactive scripting console to the shell package which can elect not to provide such a thing, allowing the shell to determine whether there is a console or not and what form it takes. Note that this also moves the widgetexplorer into a common components directory where both it and the interactive console are put into a single plugin. This may want to be changed in future to allow separate plugins to be shipped, but this is better for performance and until shown necessary may as well be this way. This relies on a one-liner patch to plasma-framework adding the interactive console QML file key to the shell package structure. I'm not going to bother with a review request for that, but will push it before pushing this. Diffs - CMakeLists.txt 6642d780aabe1777cb0457bb9b04e42c72358c9f components/BatteryIcon.qml components/CMakeLists.txt 07c48745652d7ec02147c2314ca08766a386f6b2 components/qmldir components/shellprivate/CMakeLists.txt PRE-CREATION components/shellprivate/Messages.sh PRE-CREATION shell/CMakeLists.txt 4b1dd664c4eae6dbb1832c54411140ce7c11038d shell/interactiveconsole.h d3af64bf456de60140f8a8efd4a4655ba5c6b6dd shell/interactiveconsole.cpp 7096033a3076472a969b9bb19c43053d5e9977f8 shell/scripting/desktopscriptengine.h dd097d228b3982910346fe6f07412fd0137fc372 shell/scripting/desktopscriptengine.cpp 37d138744dd2b56e6b34cdd20f1eef5c79361a40 shell/scripting/scriptengine.h ffb0cbfb435d224f48cd715b66e94449114642db shell/widgetexplorer/kcategorizeditemsviewmodels_p.h shell/widgetexplorer/openwidgetassistant.cpp shell/widgetexplorer/openwidgetassistant_p.h shell/widgetexplorer/plasmaappletitemmodel.cpp shell/widgetexplorer/plasmaappletitemmodel_p.h shell/widgetexplorer/plasmoids.knsrc shell/widgetexplorer/qmldir d808b18cfea863d6910df0cb922eb8e6e1c2bda9 shell/widgetexplorer/widgetexplorer.h shell/widgetexplorer/widgetexplorer.cpp shell/widgetexplorer/widgetexplorerplugin.h 3ee262e52d16feab35999c7963fc06b8653347a0 shell/widgetexplorer/widgetexplorerplugin.cpp f21178beb7279a851c4637fdc66d382d97f1bab9 shell/scripting/scriptengine.cpp 4db966f81d2cdaade21b07165ce6bfdd411c2366 shell/shellcorona.h b032803fe7286ba007a47a80065c6fbbb40a9709 shell/shellcorona.cpp c5447c24a2de5f42cda978e5690a210e15d80b76 shell/widgetexplorer/CMakeLists.txt dd0ea97045417245ac0b2c1a870147f2ff34e4ec shell/widgetexplorer/Messages.sh 3beeea4b3eae941ad88b66ec9af667915b66e950 shell/widgetexplorer/kcategorizeditemsviewmodels.cpp Diff: https://git.reviewboard.kde.org/r/119965/diff/ Testing --- Run with a shell package with InteractiveConsole.qml, used the console to run scripts, opened and closed it, etc. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Request: better override functionality in locale settings
Hi, Just to add to the background (and seeing as I'm the primary culprit in the death of KLocale and the slow pace of improvements to QLocale), there's 2 very big reasons for removing it (and the consequent loss of the customization feature): 1) It was very big and a maintenance burden, especially when Qt provides good-enough facilities for most purposes. The size stopped people using KDE libraries and reduced the number of potential KDE apps, and adding new features like proper collation and spell-out formatting would have taken a lot of duplicated work. 2) It was a walled garden, only KDE apps used the settings, all other apps ignored them, and KDE apps running on other desktops/platforms ignored their host settings, leaving an inconsistent user experience. Just setting the standard POSIX codes has one very big advantage in being universal: all apps running under Plasma will respect them, rather than just KDE apps. If we implement a Qt-only solution then any POSIX/glibc/Java/Firefox/Chrome/etc apps will look out-of-place again, as they did under KDE4. Any solution needs to apply to everything (even if not everything is implemented at once). We do want the configurability back, I use it myself, but there's a series of technical steps we need to achieve first. The first is removing Qt's own locale system which has the same size/maintenance problems and has hard-coded locale data that cannot be changed, as well as being short on some features. I've written 3 different solutions so far over the last 2 years and none have been accepted. We do now have a fourth design that has come out of these efforts, and I have some code towards it, but I estimate it as a 6 month full-time effort to get it implemented, tested and integrated, as it is nothing less than a complete rewrite of all of QLocale for every platform Qt supports without breaking any previous behaviour or api. That is time I don't have to give right now, and no-one in the Qt world seems interested in paying for it in spite of many people wanting it (just like printing really). The design is basically to wrap the host services on each platform in a common api, with ICU as the chosen backend on Linux due to POSIX/glibc localization being totally useless. Unfortunately that means we end up catering for some lowest common denominator feature set, in this case Windows XP. If we ignore XP (and we will) then it's better but still not what we really want, and the current debate is whether we have an advanced api in QtCore that degrades gracefully on Windows, or if the advanced features go in a new QtLocale add-on module. Even once this full rewrite of QLocale is completed, that still doesn't give us the ability to edit individual settings on Linux (only Win and Mac), but it does set the precedent that QLocale should respect the users override settings and so make it acceptable to add some 'hacks' into Qt on Linux to make it work. For Qt the mechanism will probably be a small json file that stores the custom overrides that QLocale loads and then applies as overrides when calling in to ICU. But even once Qt reads and uses our custom settings, that still doesn't apply those settings to POSIX / glibc / gtk apps, we need an extra step there as well. There is a hack we could use, which is that the System Settings module could save a POSIX format locale file with the custom settings and set the LC_* envvar to point directly to the file, but that would require all toolkits to correctly implement the POSIX standard and I'm not convinced they do. Alternatively we could ask the user for the root password and install the locale file globally, but I'm not keen on that. It also doesn't solve things for apps that use ICU directly, like Chrome, where we have no possible solution. All that is besides the point with the System Settings module. We did say at the time that a drop-down with 200+ entries was probably not the best solution, but it was an interim implementation for 5.0. I'm sure with a little thought we can come up with a better way of managing such long lists, for example with a pop-up selector which includes filters by language or region, or something like that. Perhaps for metric/imperial we could be a little smarter and use the users chosen language or default locale to guess at a suitable locale match to use. For date/time format overrides, well that I'm afraid belongs in individual apps and plasmoids for now. John. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Request: better override functionality in locale settings
Hi, Just to add to the background (and seeing as I'm the primary culprit in the death of KLocale and the slow pace of improvements to QLocale), there's 2 very big reasons for removing it (and the consequent loss of the customization feature): 1) It was very big and a maintenance burden, especially when Qt provides good-enough facilities for most purposes. The size stopped people using KDE libraries and reduced the number of potential KDE apps, and adding new features like proper collation and spell-out formatting would have taken a lot of duplicated work. 2) It was a walled garden, only KDE apps used the settings, all other apps ignored them, and KDE apps running on other desktops/platforms ignored their host settings, leaving an inconsistent user experience. Just setting the standard POSIX codes has one very big advantage in being universal: all apps running under Plasma will respect them, rather than just KDE apps. If we implement a Qt-only solution then any POSIX/glibc/Java/Firefox/ Chrome/etc apps will look out-of-place again, as they did under KDE4. Any solution needs to apply to everything (even if not everything is implemented at once). We do want the configurability back, I use it myself, but there's a series of technical steps we need to achieve first. The first is removing Qt's own locale system which has the same size/maintenance problems and has hard-coded locale data that cannot be changed, as well as being short on some features. I've written 3 different solutions so far over the last 2 years and none have been accepted. We do now have a fourth design that has come out of these efforts, and I have some code towards it, but I estimate it as a 6 month full-time effort to get it implemented, tested and integrated, as it is nothing less than a complete rewrite of all of QLocale for every platform Qt supports without breaking any previous behaviour or api. That is time I don't have to give right now, and no-one in the Qt world seems interested in paying for it in spite of many people wanting it (just like printing really). The design is basically to wrap the host services on each platform in a common api, with ICU as the chosen backend on Linux due to POSIX/glibc localization being totally useless. Unfortunately that means we end up catering for some lowest common denominator feature set, in this case Windows XP. If we ignore XP (and we will) then it's better but still not what we really want, and the current debate is whether we have an advanced api in QtCore that degrades gracefully on Windows, or if the advanced features go in a new QtLocale add-on module. Even once this full rewrite of QLocale is completed, that still doesn't give us the ability to edit individual settings on Linux (only Win and Mac), but it does set the precedent that QLocale should respect the users override settings and so make it acceptable to add some 'hacks' into Qt on Linux to make it work. For Qt the mechanism will probably be a small json file that stores the custom overrides that QLocale loads and then applies as overrides when calling in to ICU. But even once Qt reads and uses our custom settings, that still doesn't apply those settings to POSIX / glibc / gtk apps, we need an extra step there as well. There is a hack we could use, which is that the System Settings module could save a POSIX format locale file with the custom settings and set the LC_* envvar to point directly to the file, but that would require all toolkits to correctly implement the POSIX standard and I'm not convinced they do. Alternatively we could ask the user for the root password and install the locale file globally, but I'm not keen on that. It also doesn't solve things for apps that use ICU directly, like Chrome, where we have no possible solution. All that is besides the point with the System Settings module. We did say at the time that a drop-down with 200+ entries was probably not the best solution, but it was an interim implementation for 5.0. I'm sure with a little thought we can come up with a better way of managing such long lists, for example with a pop-up selector which includes filters by language or region, or something like that. Perhaps for metric/imperial we could be a little smarter and use the users chosen language or default locale to guess at a suitable locale match to use. For date/time format overrides, well that I'm afraid belongs in individual apps and plasmoids for now. John. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119965: rely on shell package to create the interactive console interface
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119965/ --- (Updated Aug. 28, 2014, 9:53 a.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-workspace Description --- This move the KTextEditor dependency out of plasmashell and into a QML component which uses it. This allows plasmashell to carry fewer dependencies while at *runtime* be able to appropriately address different form factors. It also moves the responsibility for showing the interactive scripting console to the shell package which can elect not to provide such a thing, allowing the shell to determine whether there is a console or not and what form it takes. Note that this also moves the widgetexplorer into a common components directory where both it and the interactive console are put into a single plugin. This may want to be changed in future to allow separate plugins to be shipped, but this is better for performance and until shown necessary may as well be this way. This relies on a one-liner patch to plasma-framework adding the interactive console QML file key to the shell package structure. I'm not going to bother with a review request for that, but will push it before pushing this. Diffs - CMakeLists.txt 6642d780aabe1777cb0457bb9b04e42c72358c9f components/BatteryIcon.qml components/CMakeLists.txt 07c48745652d7ec02147c2314ca08766a386f6b2 components/qmldir components/shellprivate/CMakeLists.txt PRE-CREATION components/shellprivate/Messages.sh PRE-CREATION shell/CMakeLists.txt 4b1dd664c4eae6dbb1832c54411140ce7c11038d shell/interactiveconsole.h d3af64bf456de60140f8a8efd4a4655ba5c6b6dd shell/interactiveconsole.cpp 7096033a3076472a969b9bb19c43053d5e9977f8 shell/scripting/desktopscriptengine.h dd097d228b3982910346fe6f07412fd0137fc372 shell/scripting/desktopscriptengine.cpp 37d138744dd2b56e6b34cdd20f1eef5c79361a40 shell/scripting/scriptengine.h ffb0cbfb435d224f48cd715b66e94449114642db shell/widgetexplorer/kcategorizeditemsviewmodels_p.h shell/widgetexplorer/openwidgetassistant.cpp shell/widgetexplorer/openwidgetassistant_p.h shell/widgetexplorer/plasmaappletitemmodel.cpp shell/widgetexplorer/plasmaappletitemmodel_p.h shell/widgetexplorer/plasmoids.knsrc shell/widgetexplorer/qmldir d808b18cfea863d6910df0cb922eb8e6e1c2bda9 shell/widgetexplorer/widgetexplorer.h shell/widgetexplorer/widgetexplorer.cpp shell/widgetexplorer/widgetexplorerplugin.h 3ee262e52d16feab35999c7963fc06b8653347a0 shell/widgetexplorer/widgetexplorerplugin.cpp f21178beb7279a851c4637fdc66d382d97f1bab9 shell/scripting/scriptengine.cpp 4db966f81d2cdaade21b07165ce6bfdd411c2366 shell/shellcorona.h b032803fe7286ba007a47a80065c6fbbb40a9709 shell/shellcorona.cpp c5447c24a2de5f42cda978e5690a210e15d80b76 shell/widgetexplorer/CMakeLists.txt dd0ea97045417245ac0b2c1a870147f2ff34e4ec shell/widgetexplorer/Messages.sh 3beeea4b3eae941ad88b66ec9af667915b66e950 shell/widgetexplorer/kcategorizeditemsviewmodels.cpp Diff: https://git.reviewboard.kde.org/r/119965/diff/ Testing --- Run with a shell package with InteractiveConsole.qml, used the console to run scripts, opened and closed it, etc. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119966: add an InteractiveConsole.qml
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119966/ --- (Updated Aug. 28, 2014, 9:54 a.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-desktop Description --- This adds an InteractiveConsole.qml file to go along with Review Request #119965. The main discussion point is what the name of the QML file should be and its location in the shell package. I have no particular opinion one way or the other, so I'll be looking to whoever maintains that particular design to say either that's fine where it is in the patch or give a different location that I will move it to. Diffs - desktoppackage/contents/InteractiveConsole.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119966/diff/ Testing --- Tested in plasmashell. Thanks, Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Tuesday, August 26, 2014 22:00:54 Eike Hein wrote: Hiding passive status notifier items robs the user of an entire tier of organization when deciding how near/far they want to place a running app. This may also encourage more abuse: i.e. not setting the status to hidden, ever. Remember that we're often dealing with apps who want to forego being shown in the taskbar (presumably to save space). Effectively, this means that apps will set their status to always be active, leading to more clutter in the panel. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Wednesday, August 27, 2014 10:12:54 Ivan Čukić wrote: I'm not going to chime in regarding the applications - I tend to agree with both parties - that not everything needs to be shown, yet that people like some of their applications minimized to tray (myself included - I even hide those applications from the task bar). One thing where I fully support the proposal is for plasmoids in the tray - it is a really a bad thing to have so many empty panels in - no devices, no notifications, no batteries etc. I think for batteries, we're doing that already (at least in Plasma 4 we didn't add the battery plasmoid to the panel for desktop systems). For notifications and storage devices, I quite like the idea. Maybe worth a try to hide them completely and gauge the user reaction? (I can imagine nobody would miss it.) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Thursday, August 28, 2014 12:08:04 Martin Klapetek wrote: On Thu, Aug 28, 2014 at 12:02 PM, Sebastian Kügler se...@kde.org wrote: On Tuesday, August 26, 2014 22:00:54 Eike Hein wrote: Hiding passive status notifier items robs the user of an entire tier of organization when deciding how near/far they want to place a running app. This may also encourage more abuse: i.e. not setting the status to hidden, ever. Remember that we're often dealing with apps who want to forego being shown in the taskbar (presumably to save space). Effectively, this means that apps will set their status to always be active, leading to more clutter in the panel. On the other hand, it's how Unity (and maybe others?) work for years. Let's find out if it was a real problem for them and about how many apps are they aware of abusing this? Ah, yes, thought about that, too. I agree that it could be tried, but I wouldn't be surprised if for Plasma, we come to a different conclusion. There's a certain difference in the audiences between Unity and Plasma, and that might very well manifest itself in apps having problems with this behaviour in Plasma (those that don't care about Unity). On the other hand, more consistent behaviour between statusnotifier implementations is probably a good thing. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Thursday 28 August 2014 12:02:04 Sebastian Kügler wrote: For notifications and storage devices, I quite like the idea. Maybe worth a try to hide them completely and gauge the user reaction? (I can imagine nobody would miss it.) +1. If people just want to access the configuration for them, they can go via System Settings. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
Hi, I think for batteries, we're doing that already (at least in Plasma 4 we didn't add the battery plasmoid to the panel for desktop systems). I am not sure whether distributions with their custom layout.js picked that up (I'm not even sure if I changed that in our default layout) but battery monitor is supposed to be added to the panel regardless since 4.11. It provides the handy PM switch and shows peripheral device batteries too. However, battery monitor goes passive when: - The AC is plugged in and the battery is fully charged (since 4.8 or so already) - There are no power supply batteries (desktop case, if you want to have it present nonetheless you can force it active) Cheers, Kai Uwe For notifications and storage devices, I quite like the idea +1 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Thursday 28 August 2014 12:02:04 Sebastian Kügler wrote: On Wednesday, August 27, 2014 10:12:54 Ivan Čukić wrote: I'm not going to chime in regarding the applications - I tend to agree with both parties - that not everything needs to be shown, yet that people like some of their applications minimized to tray (myself included - I even hide those applications from the task bar). One thing where I fully support the proposal is for plasmoids in the tray - it is a really a bad thing to have so many empty panels in - no devices, no notifications, no batteries etc. I think for batteries, we're doing that already (at least in Plasma 4 we didn't add the battery plasmoid to the panel for desktop systems). For notifications and storage devices, I quite like the idea. Maybe worth a try to hide them completely and gauge the user reaction? (I can imagine nobody would miss it.) one thing i would love, is to expand what we are doing with dbus activation of plasmoids, even tough for things like not having any removable storage device attached would require some more complex rules -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119967: Fix systemloadviewer monitorType settings
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119967/#review65420 --- Ship it! Ship It! - David Edmundson On Aug. 28, 2014, 8:23 a.m., Martin Yrjölä wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119967/ --- (Updated Aug. 28, 2014, 8:23 a.m.) Review request for Plasma. Repository: kdeplasma-addons Description --- Fix systemloadviewer monitorType settings The third revision of the port broke the changing of monitor type through settings, it slipped past me because the setting worked when restarting plasmashell. Diffs - applets/systemloadviewer/package/contents/ui/ConditionallyLoadedMonitors.qml 403c01cb93d350e341babb6830277eedd7f06a6c Diff: https://git.reviewboard.kde.org/r/119967/diff/ Testing --- Changing between Bar and Circular monitor types in the plasmoid settings works now as expected. Thanks, Martin Yrjölä ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 119974: port Slider to QtControls
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119974/ --- Review request for Plasma. Summary (updated) - port Slider to QtControls Repository: plasma-framework Description (updated) --- this ports slider to qtcontrols and adds a style as well. unfortunately the inverted property is not accessible anymore so becomes deprecated and noop Diffs (updated) - src/declarativeimports/plasmacomponents/qml/Slider.qml c532590 src/declarativeimports/plasmacomponents/qml/styles/SliderStyle.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119974/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119964: Avoid dlopening plasmaadapter's devel symlink
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119964/#review65427 --- Ship it! Ship It! - Bhushan Shah On Aug. 28, 2014, 11:09 a.m., Hrvoje Senjan wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119964/ --- (Updated Aug. 28, 2014, 11:09 a.m.) Review request for Plasma. Bugs: 335904 http://bugs.kde.org/show_bug.cgi?id=335904 Repository: plasma-mediacenter Description --- Some distro's have PMC splitted to main and devel subpackage, in that case the lib to dlopen was not available to users w/o devel package installed, and made the bug exposed to them. Diffs - CMakeLists.txt 0f8138a config-plasma-mediacenter.h.cmake PRE-CREATION libs/mediacenter/CMakeLists.txt 76578fc libs/plasmaadapter/CMakeLists.txt 18059ce shells/newshell/CMakeLists.txt 287d780 shells/newshell/mainwindow.cpp 9350f5c Diff: https://git.reviewboard.kde.org/r/119964/diff/ Testing --- builds + resolves the bug Thanks, Hrvoje Senjan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Thursday, August 28, 2014 13:38:49 Marco Martin wrote: it is a really a bad thing to have so many empty panels in - no devices, no notifications, no batteries etc. I think for batteries, we're doing that already (at least in Plasma 4 we didn't add the battery plasmoid to the panel for desktop systems). For notifications and storage devices, I quite like the idea. Maybe worth a try to hide them completely and gauge the user reaction? (I can imagine nobody would miss it.) one thing i would love, is to expand what we are doing with dbus activation of plasmoids, even tough for things like not having any removable storage device attached would require some more complex rules I'd think that dbus-activated plasmoids don't need this, since they come and go already (makes them essentially hidden). For the devicenotifier, it has to stay, since it could be configured to show non-removable devices as well, so the logic currently in there is fine, and we can rely on the status. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119964: Avoid dlopening plasmaadapter's devel symlink
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119964/ --- (Updated Aug. 28, 2014, 12:42 p.m.) Status -- This change has been marked as submitted. Review request for Plasma. Bugs: 335904 http://bugs.kde.org/show_bug.cgi?id=335904 Repository: plasma-mediacenter Description --- Some distro's have PMC splitted to main and devel subpackage, in that case the lib to dlopen was not available to users w/o devel package installed, and made the bug exposed to them. Diffs - CMakeLists.txt 0f8138a config-plasma-mediacenter.h.cmake PRE-CREATION libs/mediacenter/CMakeLists.txt 76578fc libs/plasmaadapter/CMakeLists.txt 18059ce shells/newshell/CMakeLists.txt 287d780 shells/newshell/mainwindow.cpp 9350f5c Diff: https://git.reviewboard.kde.org/r/119964/diff/ Testing --- builds + resolves the bug Thanks, Hrvoje Senjan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Thursday 28 August 2014 14:32:38 Sebastian Kügler wrote: I'd think that dbus-activated plasmoids don't need this, since they come and go already (makes them essentially hidden). For the devicenotifier, it has to stay, since it could be configured to show non-removable devices as well, so the logic currently in there is fine, and we can rely on the status. for plasmoids we can safely add an additional status, (as opposed to kstatusnotifieritems where i don't feel it can be added safely and still play nice with other implementations) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119974: port Slider to QtControls
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119974/#review65430 --- src/declarativeimports/plasmacomponents/qml/Slider.qml https://git.reviewboard.kde.org/r/119974/#comment45711 Is that still needed? - Kai Uwe Broulik On Aug. 28, 2014, 12:30 nachm., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119974/ --- (Updated Aug. 28, 2014, 12:30 nachm.) Review request for Plasma. Repository: plasma-framework Description --- this ports slider to qtcontrols and adds a style as well. unfortunately the inverted property is not accessible anymore so becomes deprecated and noop Diffs - src/declarativeimports/plasmacomponents/qml/Slider.qml c532590 src/declarativeimports/plasmacomponents/qml/styles/SliderStyle.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119974/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119974: port Slider to QtControls
On Aug. 28, 2014, 1:31 p.m., Kai Uwe Broulik wrote: src/declarativeimports/plasmacomponents/qml/Slider.qml, lines 125-126 https://git.reviewboard.kde.org/r/119974/diff/1/?file=307981#file307981line125 Is that still needed? I don't know, but the base component doesn't have it. Maybe Frederik knows? - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119974/#review65430 --- On Aug. 28, 2014, 12:30 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119974/ --- (Updated Aug. 28, 2014, 12:30 p.m.) Review request for Plasma. Repository: plasma-framework Description --- this ports slider to qtcontrols and adds a style as well. unfortunately the inverted property is not accessible anymore so becomes deprecated and noop Diffs - src/declarativeimports/plasmacomponents/qml/Slider.qml c532590 src/declarativeimports/plasmacomponents/qml/styles/SliderStyle.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119974/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119974: port Slider to QtControls
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119974/#review65431
---
src/declarativeimports/plasmacomponents/qml/Slider.qml
https://git.reviewboard.kde.org/r/119974/#comment45716
QtQuick.Controls.Button
src/declarativeimports/plasmacomponents/qml/styles/SliderStyle.qml
https://git.reviewboard.kde.org/r/119974/#comment45719
in the last review we explicilty set panel to Item {}
if it's needed there, it's needed here.
src/declarativeimports/plasmacomponents/qml/styles/SliderStyle.qml
https://git.reviewboard.kde.org/r/119974/#comment45717
Have you tried in vertical mode.
We don't seem to handling orientation anywhere?
(maybe it's done for us, I haven't looked)
src/declarativeimports/plasmacomponents/qml/styles/SliderStyle.qml
https://git.reviewboard.kde.org/r/119974/#comment45720
where is styleData defined?
Seems we're accidentally relying on private API.
src/declarativeimports/plasmacomponents/qml/styles/SliderStyle.qml
https://git.reviewboard.kde.org/r/119974/#comment45712
redundant
src/declarativeimports/plasmacomponents/qml/styles/SliderStyle.qml
https://git.reviewboard.kde.org/r/119974/#comment45721
Won't this position them outside the repeater?
src/declarativeimports/plasmacomponents/qml/styles/SliderStyle.qml
https://git.reviewboard.kde.org/r/119974/#comment45722
can you describe this in a comment (I'm a bit lost)
There's a potential divide by 0 is the model size is 1.
- David Edmundson
On Aug. 28, 2014, 12:30 p.m., Marco Martin wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119974/
---
(Updated Aug. 28, 2014, 12:30 p.m.)
Review request for Plasma.
Repository: plasma-framework
Description
---
this ports slider to qtcontrols and adds a style as well.
unfortunately the inverted property is not accessible anymore so becomes
deprecated and noop
Diffs
-
src/declarativeimports/plasmacomponents/qml/Slider.qml c532590
src/declarativeimports/plasmacomponents/qml/styles/SliderStyle.qml
PRE-CREATION
Diff: https://git.reviewboard.kde.org/r/119974/diff/
Testing
---
Thanks,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119974: port Slider to QtControls
On Aug. 28, 2014, 1:31 p.m., Kai Uwe Broulik wrote: src/declarativeimports/plasmacomponents/qml/Slider.qml, lines 125-126 https://git.reviewboard.kde.org/r/119974/diff/1/?file=307981#file307981line125 Is that still needed? Marco Martin wrote: I don't know, but the base component doesn't have it. Maybe Frederik knows? ok, so it's still needed because upstream is in 5.4 but not 5.3 - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119974/#review65430 --- On Aug. 28, 2014, 12:30 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119974/ --- (Updated Aug. 28, 2014, 12:30 p.m.) Review request for Plasma. Repository: plasma-framework Description --- this ports slider to qtcontrols and adds a style as well. unfortunately the inverted property is not accessible anymore so becomes deprecated and noop Diffs - src/declarativeimports/plasmacomponents/qml/Slider.qml c532590 src/declarativeimports/plasmacomponents/qml/styles/SliderStyle.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119974/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119974: port Slider to QtControls
On Aug. 28, 2014, 1:46 p.m., David Edmundson wrote:
src/declarativeimports/plasmacomponents/qml/styles/SliderStyle.qml, line 35
https://git.reviewboard.kde.org/r/119974/diff/1/?file=307982#file307982line35
in the last review we explicilty set panel to Item {}
if it's needed there, it's needed here.
no, that was background, that slider doesn't have it.
panel is the internal piece that actually loads the other components, so
shouldn't be reimplemented usually
On Aug. 28, 2014, 1:46 p.m., David Edmundson wrote:
src/declarativeimports/plasmacomponents/qml/styles/SliderStyle.qml, line 40
https://git.reviewboard.kde.org/r/119974/diff/1/?file=307982#file307982line40
Have you tried in vertical mode.
We don't seem to handling orientation anywhere?
(maybe it's done for us, I haven't looked)
yes, vertical works
it's done internally just brutally rotating the whole thing
On Aug. 28, 2014, 1:46 p.m., David Edmundson wrote:
src/declarativeimports/plasmacomponents/qml/styles/SliderStyle.qml, line 71
https://git.reviewboard.kde.org/r/119974/diff/1/?file=307982#file307982line71
where is styleData defined?
Seems we're accidentally relying on private API.
it's internal but it's documented, so should be guaranteed to stay.
http://qt-project.org/doc/qt-5/qml-qtquick-controls-styles-sliderstyle.html#groove-prop
it's the only way to have the colored part properly sized
On Aug. 28, 2014, 1:46 p.m., David Edmundson wrote:
src/declarativeimports/plasmacomponents/qml/styles/SliderStyle.qml, line 86
https://git.reviewboard.kde.org/r/119974/diff/1/?file=307982#file307982line86
Won't this position them outside the repeater?
i think so, but seems the wanted way since they gets correctly positioned.
it's just an 1:1 copy of the one in the Base style, just with the proper colors
- Marco
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119974/#review65431
---
On Aug. 28, 2014, 12:30 p.m., Marco Martin wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119974/
---
(Updated Aug. 28, 2014, 12:30 p.m.)
Review request for Plasma.
Repository: plasma-framework
Description
---
this ports slider to qtcontrols and adds a style as well.
unfortunately the inverted property is not accessible anymore so becomes
deprecated and noop
Diffs
-
src/declarativeimports/plasmacomponents/qml/Slider.qml c532590
src/declarativeimports/plasmacomponents/qml/styles/SliderStyle.qml
PRE-CREATION
Diff: https://git.reviewboard.kde.org/r/119974/diff/
Testing
---
Thanks,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119974: port Slider to QtControls
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119974/ --- (Updated Aug. 28, 2014, 2:09 p.m.) Review request for Plasma. Repository: plasma-framework Description --- this ports slider to qtcontrols and adds a style as well. unfortunately the inverted property is not accessible anymore so becomes deprecated and noop Diffs (updated) - src/declarativeimports/plasmacomponents/qml/styles/SliderStyle.qml PRE-CREATION src/declarativeimports/plasmacomponents/qml/Slider.qml c532590 Diff: https://git.reviewboard.kde.org/r/119974/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119974: port Slider to QtControls
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119974/#review65440 --- Ship it! src/declarativeimports/plasmacomponents/qml/Slider.qml https://git.reviewboard.kde.org/r/119974/#comment45730 still needs to be QtQuick.Controls.Button - David Edmundson On Aug. 28, 2014, 2:09 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119974/ --- (Updated Aug. 28, 2014, 2:09 p.m.) Review request for Plasma. Repository: plasma-framework Description --- this ports slider to qtcontrols and adds a style as well. unfortunately the inverted property is not accessible anymore so becomes deprecated and noop Diffs - src/declarativeimports/plasmacomponents/qml/styles/SliderStyle.qml PRE-CREATION src/declarativeimports/plasmacomponents/qml/Slider.qml c532590 Diff: https://git.reviewboard.kde.org/r/119974/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119974: port Slider to QtControls
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119974/ --- (Updated Aug. 28, 2014, 2:14 p.m.) Review request for Plasma. Repository: plasma-framework Description --- this ports slider to qtcontrols and adds a style as well. unfortunately the inverted property is not accessible anymore so becomes deprecated and noop Diffs (updated) - src/declarativeimports/plasmacomponents/qml/styles/SliderStyle.qml PRE-CREATION examples/applets/widgetgallery/contents/ui/Sliders.qml 135ee3e src/declarativeimports/plasmacomponents/qml/Slider.qml c532590 Diff: https://git.reviewboard.kde.org/r/119974/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119974: port Slider to QtControls
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119974/ --- (Updated Aug. 28, 2014, 2:17 p.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-framework Description --- this ports slider to qtcontrols and adds a style as well. unfortunately the inverted property is not accessible anymore so becomes deprecated and noop Diffs - src/declarativeimports/plasmacomponents/qml/styles/SliderStyle.qml PRE-CREATION examples/applets/widgetgallery/contents/ui/Sliders.qml 135ee3e src/declarativeimports/plasmacomponents/qml/Slider.qml c532590 Diff: https://git.reviewboard.kde.org/r/119974/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119945: Dialog: Simplify handling of min/max width/height changed
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119945/ --- (Updated Aug. 28, 2014, 2:39 p.m.) Status -- This change has been discarded. Review request for Plasma. Repository: plasma-framework Description --- When the minimumWidth/Height of the attached Layout of the mainItem would change. The following events would happen - - updateMinimumWidth is called -- results in resizeEvent being called -- results in syncMainItemToSize -- results in slots connected to mainItem widthChanged --- syncMainItemToSize + syncToMainItemSize being called a few more times. It's not entirely apparent why at thist point. This kind of logic is quite hard to follow and more importantly because of the timers in the middle, an extra paint event is called. This means the user can first see the window resize and then the item getting resized. This patch introduces a little bit of code duplication (can be fixed in future commits) to clearly establish what updateMinimumWidth should be doing - * disconnect signals to make sure mainItem's widthChange is not triggered * update window size + item size + borders * reposition if required The repositioning is useful as currently if a dialog becomes wider if will not reposition itself and will overflow. With this patch we always make sure the entire dialog is shown. Minor Point: On testing without the patch the dialog does reposition itself if it is not already overflowing. I suspect this is kwin moving the window. A test called dialog_minWidthHeighRepositioning.qml can be used to see how the change occurs before and after. Diffs - src/plasmaquick/dialog.h f207f88 src/plasmaquick/dialog.cpp 02271e4 Diff: https://git.reviewboard.kde.org/r/119945/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119913: Force creation of a OpenGL core context
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119913/ --- (Updated Aug. 28, 2014, 5:35 nachm.) Status -- This change has been discarded. Review request for Plasma. Repository: plasma-workspace Description --- This was suggested by Martin Gräßlin in review 119524 and also fixes the build with Qt 5.4, since QQuickWindow::setDefaultFormat no longer exists REVIEW: 119913 Diffs - krunner/main.cpp 4d8cc31ff4d78c2daa0f9a6af247b3bd1c317ffa Diff: https://git.reviewboard.kde.org/r/119913/diff/ Testing --- compiles Thanks, Alexander Richardson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Tuesday 26 August 2014 21:26:42 Philipp Stefan wrote: Hello everyone, the VDG told me to take a look at the system tray after the 5.0 releases, because even though it's a huge step forward, we felt that there are some inconsistencies in how it behaves. My task was to identify these issues and come up with possible solutions. We talked about them already and think it is now time to come forwards with our suggestions. If these ideas are accepted we'll deliver guidelines on how to integrate an application nicely into the system tray. so ,as a conclusion, I want to try to do a very bare bone recap: * there seems to be too many icons in the popup, especially some that don't really do much * completely hiding icons of statusnotifiers of applications gives problems, because makes those applications unreachable for all intents and purposes * however should be pretty safe to hide plasmoids: with a possible state more, things like the device notifier can be completely hidden when empty * an extra state for statusnotifiers may cause problems for unity and the two gtk clients. * completely hide vs an extra layer of show/collapse what's better? * As a first action item, completely hide really empty plasmoids (it would be up to the plasmoid logic to decide that with setting the proper state on itself) * Still open problem: less crowded popup, but still being able to access applications that are accessible only by their systray icon -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
I think for batteries, we're doing that already (at least in Plasma 4 we didn't add the battery plasmoid to the panel for desktop systems). It does not work for me. Source install on the desktop system, but I do have the battery indicator. Cheerio ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Thursday 28 August 2014 18:09:49 Ivan Čukić wrote: I think for batteries, we're doing that already (at least in Plasma 4 we didn't add the battery plasmoid to the panel for desktop systems). It does not work for me. Source install on the desktop system, but I do have the battery indicator. yeah, the function to check from the scripting engine is there and ported, but the systray doesn't use it and just adds it by default, i guess because there are brightness controls as well now -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
yeah, the function to check from the scripting engine is there and ported, but the systray doesn't use it and just adds it by default, i guess because there are brightness controls as well now And the PM checkbox which is handy on desktop too. And it shows your mouse battery, if any. So battery should he added all the time, passive if no batteries. (Which is what it does atm) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Request: better override functionality in locale settings
On Thursday 28 August 2014 12:21:21 Sebastian Kügler wrote: Actually, while the fact that choosing formats and units by locale instead of directly isn't necessarily a usability problem, presenting all locales in a single drop-down _is_ . Surely, and almost every bugreport has some relation to usability, that doesn't mean that anything someone runs into is bad usability, I'm against conflating issues and muddening our terminology. Agreed: Usability problem is definitely not the same as I don't like the way it works. In this case, the best approach would have been to file a bug about the actual usability problem (i.e. the 200-item-dropdowns) which would have been acted upon, and maybe a wishlist item asking for the ability to directly set formats, which would probably have been closed as won't fix with the arguments presented in this thread. See also the HIG for drop-down lists [1] which says For a single selection out of a large number of items (n20), use a list view. This is because, as Matthew stated, scrolling through a huge list inside a drop-down is very very cumbersome. I've just filed a bug about this issue [1]. [1] https://bugs.kde.org/show_bug.cgi?id=338599 We have 6 comboboxes which are all too big. This needs a serious design concept, we can't just replace them all with lists + filters, because people don't have 6000px height displays. I've posted the same comment to the bugreport, let's move this discussion over there. Yes, will reply over there. The above being said, I do understand that people who e.g. prefer the metric system though they live in a region that uses the imperial system by default might find it unnecessarily intricate to find out which region uses their preferred system first. The benefits of using the POSIX-compliant locale system instead of custom formats selection still outweigh the costs from my point of view, but maybe we can find a way for people to make it easier for them to switch to common formats? Could we maybe put a hint somewhere that e.g. en_DK might give people what they need at least for the date and time formats? There's the Examples section which shows exactly what one can expect, whenever the combo value changes. Not good enough? Otherwise, I'm out of ideas (for now). The problem is that people still have to guess which locale might give them exactly the things they want before selecting one. I think the idea John presented about allowing users to edit their own custom locale file and then use that could be worth pursuing for the mid/long term, since that would then still be used by all applications, not just KDE ones. Cheers, Thomas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Thu, Aug 28, 2014 at 5:52 PM, Marco Martin notm...@gmail.com wrote: On Tuesday 26 August 2014 21:26:42 Philipp Stefan wrote: Hello everyone, the VDG told me to take a look at the system tray after the 5.0 releases, because even though it's a huge step forward, we felt that there are some inconsistencies in how it behaves. My task was to identify these issues and come up with possible solutions. We talked about them already and think it is now time to come forwards with our suggestions. If these ideas are accepted we'll deliver guidelines on how to integrate an application nicely into the system tray. so ,as a conclusion, I want to try to do a very bare bone recap: Thanks for doing that. * there seems to be too many icons in the popup, especially some that don't really do much * completely hiding icons of statusnotifiers of applications gives problems, because makes those applications unreachable for all intents and purposes * however should be pretty safe to hide plasmoids: with a possible state more, things like the device notifier can be completely hidden when empty * an extra state for statusnotifiers may cause problems for unity and the two gtk clients. I don't understand why we would have an extra state. If one wants to completely hide a status notifier, don't create a status notifier in the first place. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Thursday 28 August 2014 19:06:45 David Edmundson wrote: I don't understand why we would have an extra state. If one wants to completely hide a status notifier, don't create a status notifier in the first place. yes, if an application doesn't need it and is visible, it should just not create/delete it however if the main window is hidden already and is accessible only via statusnotifieritem, it shouldn't delete it, again from the thread discussion, there is the unfortunately common case of applications that use them as little taskbar entry replacement -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On 28.08.2014 14:32, Sebastian Kügler wrote: On Thursday, August 28, 2014 13:38:49 Marco Martin wrote: it is a really a bad thing to have so many empty panels in - no devices, no notifications, no batteries etc. I think for batteries, we're doing that already (at least in Plasma 4 we didn't add the battery plasmoid to the panel for desktop systems). For notifications and storage devices, I quite like the idea. Maybe worth a try to hide them completely and gauge the user reaction? (I can imagine nobody would miss it.) one thing i would love, is to expand what we are doing with dbus activation of plasmoids, even tough for things like not having any removable storage device attached would require some more complex rules I'd think that dbus-activated plasmoids don't need this, since they come and go already (makes them essentially hidden). For the devicenotifier, it has to stay, since it could be configured to show non-removable devices as well, so the logic currently in there is fine, and we can rely on the status. For this case, to allow to configure this basic functionality we came up with greying them out if the plasmoid is not configured to show non-removable devices. This way it's clear that it currently does not hold any information, however the configuration dialogue is still available. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On 28.08.2014 17:52, Marco Martin wrote: On Tuesday 26 August 2014 21:26:42 Philipp Stefan wrote: Hello everyone, the VDG told me to take a look at the system tray after the 5.0 releases, because even though it's a huge step forward, we felt that there are some inconsistencies in how it behaves. My task was to identify these issues and come up with possible solutions. We talked about them already and think it is now time to come forwards with our suggestions. If these ideas are accepted we'll deliver guidelines on how to integrate an application nicely into the system tray. so ,as a conclusion, I want to try to do a very bare bone recap: * there seems to be too many icons in the popup, especially some that don't really do much * completely hiding icons of statusnotifiers of applications gives problems, because makes those applications unreachable for all intents and purposes * however should be pretty safe to hide plasmoids: with a possible state more, things like the device notifier can be completely hidden when empty * an extra state for statusnotifiers may cause problems for unity and the two gtk clients. * completely hide vs an extra layer of show/collapse what's better? * As a first action item, completely hide really empty plasmoids (it would be up to the plasmoid logic to decide that with setting the proper state on itself) * Still open problem: less crowded popup, but still being able to access applications that are accessible only by their systray icon I'd also add that Unity's and Plasma's interpretation of the spec are currently not compatible. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
For this case, to allow to configure this basic functionality we came up with greying them out if the plasmoid is not configured to show non-removable devices. This way it's clear that it currently does not hold any information, however the configuration dialogue is still available. The icons are monochrome already? You can't grey them out further ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Thursday, August 28, 2014 19:54:53 David Edmundson wrote: For this case, to allow to configure this basic functionality we came up with greying them out if the plasmoid is not configured to show non-removable devices. This way it's clear that it currently does not hold any information, however the configuration dialogue is still available. The icons are monochrome already? You can't grey them out further We can reduce the opacity, which is what we're doing in other cases as well, when there's no suitable highlight. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 119983: Use font metrics to scale icons for high dpi outputs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119983/ --- Review request for Plasma, Kai Uwe Broulik, David Edmundson, and Vishesh Handa. Bugs: 337712 and 338308 http://bugs.kde.org/show_bug.cgi?id=337712 http://bugs.kde.org/show_bug.cgi?id=338308 Repository: plasma-framework Description --- Use font metrics to scale icons for high dpi outputs QScreen, through EDID reports bogus values for physicalDotsPerInch*(). This leads to oversized icons on monitors with bogus edid information. This patch changes the ratio underlying to the icon sizing for displays with a DPI 96 * 1.5 to use the ratio between the font as rendered (its effective pixelSize, essentially) to scale the icon sizes up. As we rely on proper font metrics throughout already, this should bring sizing in line with the font, which is something that makes sense as it means we're sharing the underlying mechanism (font metrics) for sizing in different areas. The downside of this patch is that we're essentially working around an issue that should be fixed in the hardware, the monitor's edid. Unrealistic. print dpi / sizing in dpitest Print out some useful information to deduce dpi and pixel sizing. David, and Kai Uwe, Vishesh (since I know you have a high DPI displays), could you run this patch for a bit and check if it works for you, too? I've pushed it to plasma-framework[sebas/dpi] for your git convenience. Diffs - src/declarativeimports/core/units.h ba481781a04a54cb77f99048d3d400fdae617b38 src/declarativeimports/core/units.cpp 56c0b55427c128beff5f8d18c37847a435f194c0 tests/dpi/dpitest.cpp c3d2c3e6821fd79fc8b5ed0b3559a5870f88aa36 Diff: https://git.reviewboard.kde.org/r/119983/diff/ Testing --- Ran Plasma Desktop, no apparent problems (on this hardware, which worked, anyway). Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119983: Use font metrics to scale icons for high dpi outputs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119983/#review65459 --- src/declarativeimports/core/units.cpp https://git.reviewboard.kde.org/r/119983/#comment45732 I'm confused. gridUnit is based on QGuiApplication::font() and we generate a ratio comparing it against QGuiApplication::font() won't that always result in the same constant? - David Edmundson On Aug. 28, 2014, 11:03 p.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119983/ --- (Updated Aug. 28, 2014, 11:03 p.m.) Review request for Plasma, Kai Uwe Broulik, David Edmundson, and Vishesh Handa. Bugs: 337712 and 338308 http://bugs.kde.org/show_bug.cgi?id=337712 http://bugs.kde.org/show_bug.cgi?id=338308 Repository: plasma-framework Description --- Use font metrics to scale icons for high dpi outputs QScreen, through EDID reports bogus values for physicalDotsPerInch*(). This leads to oversized icons on monitors with bogus edid information. This patch changes the ratio underlying to the icon sizing for displays with a DPI 96 * 1.5 to use the ratio between the font as rendered (its effective pixelSize, essentially) to scale the icon sizes up. As we rely on proper font metrics throughout already, this should bring sizing in line with the font, which is something that makes sense as it means we're sharing the underlying mechanism (font metrics) for sizing in different areas. The downside of this patch is that we're essentially working around an issue that should be fixed in the hardware, the monitor's edid. Unrealistic. print dpi / sizing in dpitest Print out some useful information to deduce dpi and pixel sizing. David, and Kai Uwe, Vishesh (since I know you have a high DPI displays), could you run this patch for a bit and check if it works for you, too? I've pushed it to plasma-framework[sebas/dpi] for your git convenience. Diffs - src/declarativeimports/core/units.h ba481781a04a54cb77f99048d3d400fdae617b38 src/declarativeimports/core/units.cpp 56c0b55427c128beff5f8d18c37847a435f194c0 tests/dpi/dpitest.cpp c3d2c3e6821fd79fc8b5ed0b3559a5870f88aa36 Diff: https://git.reviewboard.kde.org/r/119983/diff/ Testing --- Ran Plasma Desktop, no apparent problems (on this hardware, which worked, anyway). Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Thursday 28 August 2014 12:14:28 Sebastian Kügler wrote: I agree that it could be tried, but I wouldn't be surprised if for Plasma, we come to a different conclusion. There's a certain difference in the audiences between Unity and Plasma Is there? I don't really know what is our audience, even less what is theirs. I honestly thought we were competing for more or less the same audience, at least I am. signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Jenkins build is back to normal : plasma-desktop_master_qt5 #593
See http://build.kde.org/job/plasma-desktop_master_qt5/593/changes ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
