port plasma to imx6 device (cubox-i)
Dear plasma team, ive seen a review about the new plasma 5. i really like the design - it looks really nice. my question is - if anybody is interested in porting the new plasma to the cubox-i? the cubox i is a small arm device (freescale imx6) http://www.solid-run.com/wiki/CuBox-i_Hardware the communnity currently tries to get the cubox into the mainline kernel. few operation systems already work on the cubox (debian,fedora,opensuse,arch linux...) I look forward to hearing from you shortly best Malte ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
systemtray initial configuration
Hello,
I'm trying to alter default configuration of systemtray applet. I want to
remove device notifier (notifier) from there, but keep
org.kde.notifications and others. The problem is that whenever I touch
systemtray configuration (even simple reloadConfig call),
org.kde.notifications widget isn't added to it. I've tried many different
approaches:
1. place the script in updates to remove notifier widget
2. place the script in init, set DefaultAppletsAdded=true and add applets
manually (skipping notifier)
The later approach was working for some time, but stopped, I believe, after
upgrading to kde-workspace 4.11 (the exact version is 4.11.10-2-fc20.x86_64).
That script called manually correctly adds the widgets, which should be there
from the beginning.
Any idea what is wrong?
BTW How can I get debug messages? I can't find where that print is logged
when script is called at KDE startup.
The script:
for (var i in panelIds) {
var panel = panelById(panelIds[i]);
for (var j in panel.widgetIds) {
var widget = panel.widgetById(panel.widgetIds[j]);
if (widget.type == systemtray) {
//widget.writeConfig('hidden', 'notifier');
widget.writeConfig('DefaultAppletsAdded', 'true')
widget.currentConfigGroup = new Array('Applets');
max = 0;
for (k = 0; k widget.configGroups.length; ++k)
if (parseInt(widget.configGroups[k]) max)
max = parseInt(widget.configGroups[k]);
widget.currentConfigGroup = new Array('Applets', max + 1);
widget.writeConfig('plugin', 'org.kde.notifications');
widget.currentConfigGroup = new Array('Applets', max + 2);
widget.writeConfig('plugin', 'battery');
print(qubes: Applets added as + max)
widget.reloadConfig();
break;
}
}
}
=
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
signature.asc
Description: OpenPGP digital signature
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119465: Have separate texture hashes for each window
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119465/#review63313 --- src/declarativeimports/core/framesvgitem.cpp https://git.reviewboard.kde.org/r/119465/#comment44130 This must have been already happening; otherwise it would have been exploding in 5.0 QQuickItem.cpp:2687 resets the paintNode to 0. - David Edmundson On July 25, 2014, 2:28 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119465/ --- (Updated July 25, 2014, 2:28 p.m.) Review request for Plasma. Repository: plasma-framework Description --- Apparently in nvidia we get corruptions when a texture created for a window is used in another one. With this patch we tell the texture has changed when we move it from a window to another, so it's re-created and we keep textures for all windows separately. This way we ensure they don't mix. Diffs - src/declarativeimports/core/framesvgitem.h 0b39c70 src/declarativeimports/core/framesvgitem.cpp ebac29f Diff: https://git.reviewboard.kde.org/r/119465/diff/ Testing --- Still works here, I hope Marco can confirm it fixes the problem. Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Minutes Monday Plasma Hangout
Minutes Plasma Hangout week 31, 28th July 2014 Present: Antonis, Marco, David, Ivan, Jonathan, Vishesh, Sebastian, Aleix, Aleix: - worked on texture sharing in FrameSvg Antonis: - Worked on widgetexplorer in Active shell - Worked on main containment for Active - both need more work David: - Worked on porting SDDM's KCM - Fixing KAuth in frameworks Ivan: - Activity switcher is almost complete - Merging it bit by bit now - Kickoff favorites model which takes activities into account to land in RB shortly - Next up: pinned apps Jonathan: - Reminds of schedule: - Thursday tagging Frameworks - Monday Plasma 5.0.1 - Plasma 5.0 ISO is there (non-Neon5) Marco: - Merged Applet alternatives feature - started to move some PlasmaComponents to QQuickControls - Button is done merged) - Started mechanism to load stuff from Look and Feel packages would like comment on https://git.reviewboard.kde.org/r/119451/ Vishesh: - Worked on enabling preview support in Milou (not enabled yet) - Worked on removable media support - Improved unicode support - Worked on better xattr support - Looked at kdeplasma-addons Sebastian - Moving KUser QML bindings into kdeclarative / coreaddons - Working on KScreen backend using QScreen -- 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 119513: reintroduce containmentForScreen(int screen, const QString defaultPluginIfNonExistent, args)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119513/ --- Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- reintroduces an api call from plasma1: its the only way to solve https://bugs.kde.org/show_bug.cgi?id=337200 basically to avoid a crash when plasma starts with missing containments in the appletsrc and a locked corona, or a screen added with locked widgets. it's the only entry point that allows a creation of a containment when widgets are locked Diffs - src/plasma/corona.h f60fd74 src/plasma/corona.cpp c6bd949 Diff: https://git.reviewboard.kde.org/r/119513/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119513: reintroduce containmentForScreen(int screen, const QString defaultPluginIfNonExistent, args)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119513/#review63318 --- Ship it! Ship It! - Sebastian Kügler On July 28, 2014, 11:13 a.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119513/ --- (Updated July 28, 2014, 11:13 a.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- reintroduces an api call from plasma1: its the only way to solve https://bugs.kde.org/show_bug.cgi?id=337200 basically to avoid a crash when plasma starts with missing containments in the appletsrc and a locked corona, or a screen added with locked widgets. it's the only entry point that allows a creation of a containment when widgets are locked Diffs - src/plasma/corona.h f60fd74 src/plasma/corona.cpp c6bd949 Diff: https://git.reviewboard.kde.org/r/119513/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119513: reintroduce containmentForScreen(int screen, const QString defaultPluginIfNonExistent, args)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119513/ --- (Updated July 28, 2014, 11:46 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- reintroduces an api call from plasma1: its the only way to solve https://bugs.kde.org/show_bug.cgi?id=337200 basically to avoid a crash when plasma starts with missing containments in the appletsrc and a locked corona, or a screen added with locked widgets. it's the only entry point that allows a creation of a containment when widgets are locked Diffs - src/plasma/corona.h f60fd74 src/plasma/corona.cpp c6bd949 Diff: https://git.reviewboard.kde.org/r/119513/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 119515: Support per-activity favourites
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119515/ --- Review request for Plasma, Eike Hein, Marco Martin, and Sebastian Kügler. Repository: plasma-desktop Description --- This patch adds the support to have favourites linked to activities. It uses org.kde.activities.ResourceModel to show favorites. It supports: - adding a favourite to all activities (the previous behaviour) - adding a favourite to the current activity - moving a favourite between 'all activities' and 'current activity' modes (it does not affect non-current activities) - drag-and-drop reordering of items (like the previous one) - sorting A-Z, Z-A (like the previous one) - transitions previously defined favourites to the new system* Context menu item captions could maybe use some improvement. Screenshot available at: http://ivan.fomentgroup.org/blog/2014/07/27/per-activity-favourites-in-kickoff/#/comments * this can also be used for defining the default favourites in a global kickoffrc file - instead of them being hard-coded like they currently are. Diffs - applets/kickoff/CMakeLists.txt 28e7029 applets/kickoff/core/favoritesmodel.h 27a0626 applets/kickoff/core/favoritesmodel.cpp f05588b applets/kickoff/core/kickoffplugin.cpp f549981 applets/kickoff/core/krunnermodel.h 3916829 applets/kickoff/core/krunnermodel.cpp db2adab applets/kickoff/package/contents/ui/ContextMenu.qml 6a67874 applets/kickoff/package/contents/ui/FavoritesView.qml 6c2d5d4 applets/kickoff/package/contents/ui/FullRepresentation.qml 6291b7c Diff: https://git.reviewboard.kde.org/r/119515/diff/ Testing --- Yes Thanks, Ivan Čukić ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119515: Support per-activity favourites
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119515/#review63321 --- +1 from me, would like toknow from Eike if this provides all is needed for use cases outside kickoff - Marco Martin On July 28, 2014, 11:49 a.m., Ivan Čukić wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119515/ --- (Updated July 28, 2014, 11:49 a.m.) Review request for Plasma, Eike Hein, Marco Martin, and Sebastian Kügler. Repository: plasma-desktop Description --- This patch adds the support to have favourites linked to activities. It uses org.kde.activities.ResourceModel to show favorites. It supports: - adding a favourite to all activities (the previous behaviour) - adding a favourite to the current activity - moving a favourite between 'all activities' and 'current activity' modes (it does not affect non-current activities) - drag-and-drop reordering of items (like the previous one) - sorting A-Z, Z-A (like the previous one) - transitions previously defined favourites to the new system* Context menu item captions could maybe use some improvement. Screenshot available at: http://ivan.fomentgroup.org/blog/2014/07/27/per-activity-favourites-in-kickoff/#/comments * this can also be used for defining the default favourites in a global kickoffrc file - instead of them being hard-coded like they currently are. Diffs - applets/kickoff/CMakeLists.txt 28e7029 applets/kickoff/core/favoritesmodel.h 27a0626 applets/kickoff/core/favoritesmodel.cpp f05588b applets/kickoff/core/kickoffplugin.cpp f549981 applets/kickoff/core/krunnermodel.h 3916829 applets/kickoff/core/krunnermodel.cpp db2adab applets/kickoff/package/contents/ui/ContextMenu.qml 6a67874 applets/kickoff/package/contents/ui/FavoritesView.qml 6c2d5d4 applets/kickoff/package/contents/ui/FullRepresentation.qml 6291b7c Diff: https://git.reviewboard.kde.org/r/119515/diff/ Testing --- Yes Thanks, Ivan Čukić ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Minutes Monday Plasma Hangout
On Monday 28 July 2014, Sebastian Kügler wrote: - Started mechanism to load stuff from Look and Feel packages would like comment on https://git.reviewboard.kde.org/r/119451/ Based on the discussion with David in the hangout, i would still do: - the look and feel package provides qml files for some parts of the shell - most theme elements (icons, plasma theme, widget style etc) are usually provided only referred in a config file - if a theme wants to phisically provide something, like a plasma theme, icon theme etc, it can, bout would be task of the kcm to either copy or make a link of say, the icon theme in the proper directory where an icon theme would be expected. - or in alternative, the theme could be specified in the config file as a full path, so for icons if you are using the foo look and feel package, you could have in kdeglobals [Icons] Theme=~/.share/plasma/lookandfeel/foo/icons -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119515: Support per-activity favourites
On July 28, 2014, 12:03 p.m., Marco Martin wrote: +1 from me, would like toknow from Eike if this provides all is needed for use cases outside kickoff Kicker doesn't use Kickoff's models, i.e. activity support has to be implemented in Kicker's own favorites model. - Eike --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119515/#review63321 --- On July 28, 2014, 11:49 a.m., Ivan Čukić wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119515/ --- (Updated July 28, 2014, 11:49 a.m.) Review request for Plasma, Eike Hein, Marco Martin, and Sebastian Kügler. Repository: plasma-desktop Description --- This patch adds the support to have favourites linked to activities. It uses org.kde.activities.ResourceModel to show favorites. It supports: - adding a favourite to all activities (the previous behaviour) - adding a favourite to the current activity - moving a favourite between 'all activities' and 'current activity' modes (it does not affect non-current activities) - drag-and-drop reordering of items (like the previous one) - sorting A-Z, Z-A (like the previous one) - transitions previously defined favourites to the new system* Context menu item captions could maybe use some improvement. Screenshot available at: http://ivan.fomentgroup.org/blog/2014/07/27/per-activity-favourites-in-kickoff/#/comments * this can also be used for defining the default favourites in a global kickoffrc file - instead of them being hard-coded like they currently are. Diffs - applets/kickoff/CMakeLists.txt 28e7029 applets/kickoff/core/favoritesmodel.h 27a0626 applets/kickoff/core/favoritesmodel.cpp f05588b applets/kickoff/core/kickoffplugin.cpp f549981 applets/kickoff/core/krunnermodel.h 3916829 applets/kickoff/core/krunnermodel.cpp db2adab applets/kickoff/package/contents/ui/ContextMenu.qml 6a67874 applets/kickoff/package/contents/ui/FavoritesView.qml 6c2d5d4 applets/kickoff/package/contents/ui/FullRepresentation.qml 6291b7c Diff: https://git.reviewboard.kde.org/r/119515/diff/ Testing --- Yes Thanks, Ivan Čukić ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Using more of our CI, Coverage and cppcheck
On Sun, Jul 27, 2014 at 11:59 PM, Àlex Fiestas afies...@kde.org wrote: Hi there! During this weekend Ben and I have enabled the code-coverage in plasma- framework, my personal idea is to enable it in most projects. We should not go loco with code coverage, we stand where we stand and adding test non-stop will not fix anything. What we can do though is use this tool to make sure we don't make the situation worse, and to check which parts might need special love. http://build.kde.org/job/plasma-framework_master_qt5/665/Variation=All,label=LINBUILDER/cobertura/ Also, most projects have cppcheck enabled, this thing is usually right so we want to to make it happy: http://build.kde.org/job/plasma-framework_master_qt5/665/Variation=All,label=LINBUILDER/cppcheckResult/ If you want to enable it in more projects, look at: https://techbase.kde.org/Development/Tutorials/Unittests#Coverage_tools_and_CI Cheers! Looks interesting, lots of work to be done :). From the wiki: [1] Do we need special powers to change these? Aleix [1] And add this option in the configuraiotn of your CI build: http://quickgit.kde.org/?p=websites%2Fbuild-kde-org. [DEFAULT] configureExtraArgs=-DBUILD_COVERAGE=ON ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: port plasma to imx6 device (cubox-i)
On Mon, Jul 21, 2014 at 2:32 PM, Malte Grosse malte.gro...@googlemail.com wrote: Dear plasma team, ive seen a review about the new plasma 5. i really like the design - it looks really nice. my question is - if anybody is interested in porting the new plasma to the cubox-i? the cubox i is a small arm device (freescale imx6) http://www.solid-run.com/wiki/CuBox-i_Hardware the communnity currently tries to get the cubox into the mainline kernel. few operation systems already work on the cubox (debian,fedora,opensuse,arch linux...) I look forward to hearing from you shortly best Malte Hi Malte, If some OS already works it should mean KDE already works there, right? What kind of port do you expect from the Plasma team? Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119025: Actually pass IBUS_DEFINITIONS when compiling ibus-panel
On July 19, 2014, 12:17 a.m., Vadim Zhukov wrote: (As a general note, for build system related stuff like this you can also try including the buildsystem group, which can be more responsive at times) The ibus-panel can't build on OpenBSD because some required definitions obtained from pkgconfig file are not used. 1. IBUS_DEFINITIONS is not used in ibus-panel/CMakeLists.txt Can you post the error you get here? I've tried building kimtoy here on FreeBSD expecting to hit the same issue(s), but it all went along just fine. 2. IBUS_DEFINITIONS is not saved in cache, and thus isn't available at compile time This doesn't make much sense; all values found at configuration time in CMake are then used to generate your make/ninja/whatever files, regardless of whether they are cached or not. Vadim Zhukov wrote: Raphael, thank you for your input! The issue was caused by the fact that X includes are placed in the /usr/X11R6/include directory on OpenBSD. This catalog is mentioned in PC_IBUS_DEFINITIONS variable but isn't propagated to the caller of find_package(IBus). Yes, I was wrong: the CACHE part may and should be omitted. This patch was added by me a long time ago (7 Feb 2012 according to git log; guess the KDE version used then), when I was much less expirienced in CMake... I've started a massive push of OpenBSD local patches upstream recently during OpenBSD hackathon, when I got time for such cleanup. At the present time, the /usr/X11R6/include gets to the include_directories() from another place, so the patch isn't required at all. But, still, the PC_IBUS_DEFINITIONS should be respected, IMHO. What do you think? Please note that FreeBSD and OpenBSD and quiet different. So you can't test on one OS instead of another. The issue was caused by the fact that X includes are placed in the /usr/X11R6/include directory on OpenBSD. This catalog is mentioned in PC_IBUS_DEFINITIONS variable but isn't propagated to the caller of find_package(IBus). [...] At the present time, the /usr/X11R6/include gets to the include_directories() from another place, so the patch isn't required at all. But, still, the PC_IBUS_DEFINITIONS should be respected, IMHO. What do you think? While that is not wrong, the approach we normally take with CMake is that pkg-config's presence is optional, and we don't depend on its output to be able to build a module. In practice, this means one should look for IBus and X11 separately, as well as add their compiler flags/link against them independently. If kimtoy already does that, I just wouldn't make any change. Please note that FreeBSD and OpenBSD and quiet different. So you can't test on one OS instead of another. You don't need to preach to the choir :-) I'm well aware of the differences between them, my point is that in many cases packaging problems in one also impact the other (missing includes because people assume all software is in `/usr`, reliance on non-POSIX features without checking for their availability etc). - Raphael --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119025/#review62669 --- On July 19, 2014, 9:43 p.m., Vadim Zhukov wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119025/ --- (Updated July 19, 2014, 9:43 p.m.) Review request for kde-workspace, Plasma and Hui Ni. Repository: kimtoy Description --- The ibus-panel can't build on OpenBSD because some required definitions obtained from pkgconfig file are not used. This happens due to the following reasons: 1. IBUS_DEFINITIONS is not used in ibus-panel/CMakeLists.txt 2. IBUS_DEFINITIONS is not saved in cache, and thus isn't available at compile time This patch resolves both issues and makes ibus-panel compile on OpenBSD. (I found no suitable review group and therefore used plasma instead, as it was in plasma-addons previously; please, feel free to correct me if I'm wrong and sorry for any possible inconvenience) ((as there was no feedback for more than a week, I've added kde-workspace group to list of reviewers, too)) Diffs - ibus-panel/CMakeLists.txt 3a1ee49 Diff: https://git.reviewboard.kde.org/r/119025/diff/ Testing --- OpenBSD/i386-CURRENT, KDE 4.13 (it doesn't have kimtoy package, of course, but the code is same) Thanks, Vadim Zhukov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119464: port ToolButton to QtControls
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119464/#review63337 --- Ship it! Ship It! - David Edmundson On July 25, 2014, 4:52 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119464/ --- (Updated July 25, 2014, 4:52 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- this ports ToolButton. It's a different style than Button since it's way more complicated. The ugly thing here is that QtControls ToolButton doesn't have a flat property, it should probably be upstreamed, at least for compatibility with the qwidgets ToolButton Diffs - src/declarativeimports/plasmacomponents/qml/styles/ComboBoxStyle.qml 20caef6 src/declarativeimports/plasmacomponents/qml/ToolButton.qml 6dcbf7b src/declarativeimports/plasmacomponents/qml/styles/ToolButtonStyle.qml PRE-CREATION src/declarativeimports/plasmacomponents/qml/styles/ButtonStyle.qml d92a662 Diff: https://git.reviewboard.kde.org/r/119464/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119464: port ToolButton to QtControls
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119464/ --- (Updated July 28, 2014, 3:50 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- this ports ToolButton. It's a different style than Button since it's way more complicated. The ugly thing here is that QtControls ToolButton doesn't have a flat property, it should probably be upstreamed, at least for compatibility with the qwidgets ToolButton Diffs - src/declarativeimports/plasmacomponents/qml/styles/ComboBoxStyle.qml 20caef6 src/declarativeimports/plasmacomponents/qml/ToolButton.qml 6dcbf7b src/declarativeimports/plasmacomponents/qml/styles/ToolButtonStyle.qml PRE-CREATION src/declarativeimports/plasmacomponents/qml/styles/ButtonStyle.qml d92a662 Diff: https://git.reviewboard.kde.org/r/119464/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Minutes Monday Plasma Hangout
On Monday 28 July 2014, Marco Martin wrote: On Monday 28 July 2014, Sebastian Kügler wrote: - Started mechanism to load stuff from Look and Feel packages would like comment on https://git.reviewboard.kde.org/r/119451/ Based on the discussion with David in the hangout, i would still do: - the look and feel package provides qml files for some parts of the shell - most theme elements (icons, plasma theme, widget style etc) are usually provided only referred in a config file - if a theme wants to phisically provide something, like a plasma theme, icon theme etc, it can, bout would be task of the kcm to either copy or make a link of say, the icon theme in the proper directory where an icon theme would be expected. - or in alternative, the theme could be specified in the config file as a full path, so for icons if you are using the foo look and feel package, you could have in kdeglobals [Icons] Theme=~/.share/plasma/lookandfeel/foo/icons comments on that? furthermore, how would you prefer to use it? as a standalone library? static in plasma-workspace stuff? in libplasmaquick? other? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
qml controls and documentation
Hi all, right now the plasma qml components are documented not bad, like: http://api.kde.org/frameworks-api/frameworks5-apidocs/plasma-framework/html/classorg_1_1kde_1_1plasma_1_1components_1_1TextField.html however, porting them to QtControls, has the sideeffect of pretty much killing the documentation of those that will inherit from a qtcontrol. like, button became: http://api.kde.org/frameworks-api/frameworks5-apidocs/plasma-framework/html/classorg_1_1kde_1_1plasma_1_1components_1_1Button.html even tough one can just say just use the documentation of controls, since there isn't an exact 100% correspondence, i would like to still have that doc usable. does somebody knows if is possible with the markup used now for extracting documentation to still have comments to document all the properties, even those *not* defined in the qml file in question? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: qml controls and documentation
On Mon, Jul 28, 2014 at 6:11 PM, Marco Martin notm...@gmail.com wrote: Hi all, right now the plasma qml components are documented not bad, like: http://api.kde.org/frameworks-api/frameworks5-apidocs/plasma-framework/html/classorg_1_1kde_1_1plasma_1_1components_1_1TextField.html however, porting them to QtControls, has the sideeffect of pretty much killing the documentation of those that will inherit from a qtcontrol. like, button became: http://api.kde.org/frameworks-api/frameworks5-apidocs/plasma-framework/html/classorg_1_1kde_1_1plasma_1_1components_1_1Button.html even tough one can just say just use the documentation of controls, since there isn't an exact 100% correspondence, i would like to still have that doc usable. does somebody knows if is possible with the markup used now for extracting documentation to still have comments to document all the properties, even those *not* defined in the qml file in question? It should probably look more or less like KPushButton [1], properly showing inheritance. Anybody knows how this is implemented in doxygen? Aleix [1] http://api.kde.org/4.12-api/kdelibs-apidocs/kdeui/html/classKPushButton.html ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119464: port ToolButton to QtControls
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119464/#review63340 --- The ugly thing here is that QtControls ToolButton doesn't have a flat property, it should probably be upstreamed, at least for compatibility with the qwidgets ToolButton I can't see a flat property on the widget's toolbutton. http://qt-project.org/doc/qt-5/qtoolbutton.html, which property are you thinking of? - David Edmundson On July 28, 2014, 3:50 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119464/ --- (Updated July 28, 2014, 3:50 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- this ports ToolButton. It's a different style than Button since it's way more complicated. The ugly thing here is that QtControls ToolButton doesn't have a flat property, it should probably be upstreamed, at least for compatibility with the qwidgets ToolButton Diffs - src/declarativeimports/plasmacomponents/qml/styles/ComboBoxStyle.qml 20caef6 src/declarativeimports/plasmacomponents/qml/ToolButton.qml 6dcbf7b src/declarativeimports/plasmacomponents/qml/styles/ToolButtonStyle.qml PRE-CREATION src/declarativeimports/plasmacomponents/qml/styles/ButtonStyle.qml d92a662 Diff: https://git.reviewboard.kde.org/r/119464/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Running Plasma on Qt 5.4
Hi, Just in case somebody has the magic idea of trying Qt 5.4, bear in mind that it's currently not working (or, well, working very bad). Here's a patch if you really feel like trying it [1] which seems to work. Cheers! Aleix [1] https://codereview.qt-project.org/#/c/90811/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119464: port ToolButton to QtControls
On July 28, 2014, 4:40 p.m., David Edmundson wrote: The ugly thing here is that QtControls ToolButton doesn't have a flat property, it should probably be upstreamed, at least for compatibility with the qwidgets ToolButton I can't see a flat property on the widget's toolbutton. http://qt-project.org/doc/qt-5/qtoolbutton.html, which property are you thinking of? right. it's called autoRaise there, and it's the negation of flat - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119464/#review63340 --- On July 28, 2014, 3:50 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119464/ --- (Updated July 28, 2014, 3:50 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- this ports ToolButton. It's a different style than Button since it's way more complicated. The ugly thing here is that QtControls ToolButton doesn't have a flat property, it should probably be upstreamed, at least for compatibility with the qwidgets ToolButton Diffs - src/declarativeimports/plasmacomponents/qml/styles/ComboBoxStyle.qml 20caef6 src/declarativeimports/plasmacomponents/qml/ToolButton.qml 6dcbf7b src/declarativeimports/plasmacomponents/qml/styles/ToolButtonStyle.qml PRE-CREATION src/declarativeimports/plasmacomponents/qml/styles/ButtonStyle.qml d92a662 Diff: https://git.reviewboard.kde.org/r/119464/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119515: Support per-activity favourites
On July 28, 2014, 12:03 p.m., Marco Martin wrote: +1 from me, would like toknow from Eike if this provides all is needed for use cases outside kickoff Eike Hein wrote: Kicker doesn't use Kickoff's models, i.e. activity support has to be implemented in Kicker's own favorites model. So, what is the decision for the kickoff patch? - Ivan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119515/#review63321 --- On July 28, 2014, 11:49 a.m., Ivan Čukić wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119515/ --- (Updated July 28, 2014, 11:49 a.m.) Review request for Plasma, Eike Hein, Marco Martin, and Sebastian Kügler. Repository: plasma-desktop Description --- This patch adds the support to have favourites linked to activities. It uses org.kde.activities.ResourceModel to show favorites. It supports: - adding a favourite to all activities (the previous behaviour) - adding a favourite to the current activity - moving a favourite between 'all activities' and 'current activity' modes (it does not affect non-current activities) - drag-and-drop reordering of items (like the previous one) - sorting A-Z, Z-A (like the previous one) - transitions previously defined favourites to the new system* Context menu item captions could maybe use some improvement. Screenshot available at: http://ivan.fomentgroup.org/blog/2014/07/27/per-activity-favourites-in-kickoff/#/comments * this can also be used for defining the default favourites in a global kickoffrc file - instead of them being hard-coded like they currently are. Diffs - applets/kickoff/CMakeLists.txt 28e7029 applets/kickoff/core/favoritesmodel.h 27a0626 applets/kickoff/core/favoritesmodel.cpp f05588b applets/kickoff/core/kickoffplugin.cpp f549981 applets/kickoff/core/krunnermodel.h 3916829 applets/kickoff/core/krunnermodel.cpp db2adab applets/kickoff/package/contents/ui/ContextMenu.qml 6a67874 applets/kickoff/package/contents/ui/FavoritesView.qml 6c2d5d4 applets/kickoff/package/contents/ui/FullRepresentation.qml 6291b7c Diff: https://git.reviewboard.kde.org/r/119515/diff/ Testing --- Yes Thanks, Ivan Čukić ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 119522: readlink fails whens the folder does not exist.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119522/
---
Review request for Plasma and Àlex Fiestas.
Repository: plasma-workspace
Description
---
https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/f01badb5aa3f76b27955f4fee2cb7281dd490353
introduced a regression in startkde whereby if ~/.config does not exist
readlink will not output the right path.
This leads to startkde trying to write to /startupconfigkeys or /kdeglobals
which obviously won't work.
Since the original commit mentions that relative paths weren't working, I've
taken a alternative approach of using ${HOME} instead.
Diffs
-
startkde/startkde.cmake 281bd43
Diff: https://git.reviewboard.kde.org/r/119522/diff/
Testing
---
Kubuntu Plasma 5 ISO's did not have the right cursor theme before this patch,
after editing startkde by hand, the right files were being correctly written,
and the cursor theme worked as expected.
Thanks,
Rohan Garg
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119515: Support per-activity favourites
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119515/#review63347 --- Ship it! for kickoff, for what i'm concerned is good to go - Marco Martin On July 28, 2014, 11:49 a.m., Ivan Čukić wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119515/ --- (Updated July 28, 2014, 11:49 a.m.) Review request for Plasma, Eike Hein, Marco Martin, and Sebastian Kügler. Repository: plasma-desktop Description --- This patch adds the support to have favourites linked to activities. It uses org.kde.activities.ResourceModel to show favorites. It supports: - adding a favourite to all activities (the previous behaviour) - adding a favourite to the current activity - moving a favourite between 'all activities' and 'current activity' modes (it does not affect non-current activities) - drag-and-drop reordering of items (like the previous one) - sorting A-Z, Z-A (like the previous one) - transitions previously defined favourites to the new system* Context menu item captions could maybe use some improvement. Screenshot available at: http://ivan.fomentgroup.org/blog/2014/07/27/per-activity-favourites-in-kickoff/#/comments * this can also be used for defining the default favourites in a global kickoffrc file - instead of them being hard-coded like they currently are. Diffs - applets/kickoff/CMakeLists.txt 28e7029 applets/kickoff/core/favoritesmodel.h 27a0626 applets/kickoff/core/favoritesmodel.cpp f05588b applets/kickoff/core/kickoffplugin.cpp f549981 applets/kickoff/core/krunnermodel.h 3916829 applets/kickoff/core/krunnermodel.cpp db2adab applets/kickoff/package/contents/ui/ContextMenu.qml 6a67874 applets/kickoff/package/contents/ui/FavoritesView.qml 6c2d5d4 applets/kickoff/package/contents/ui/FullRepresentation.qml 6291b7c Diff: https://git.reviewboard.kde.org/r/119515/diff/ Testing --- Yes Thanks, Ivan Čukić ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119515: Support per-activity favourites
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119515/#review63349 --- applets/kickoff/package/contents/ui/ContextMenu.qml https://git.reviewboard.kde.org/r/119515/#comment44158 addToGlobalFavorites sounds better applets/kickoff/package/contents/ui/ContextMenu.qml https://git.reviewboard.kde.org/r/119515/#comment44159 same here addToActivityFavorites - Thomas Braxton On July 28, 2014, 11:49 a.m., Ivan Čukić wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119515/ --- (Updated July 28, 2014, 11:49 a.m.) Review request for Plasma, Eike Hein, Marco Martin, and Sebastian Kügler. Repository: plasma-desktop Description --- This patch adds the support to have favourites linked to activities. It uses org.kde.activities.ResourceModel to show favorites. It supports: - adding a favourite to all activities (the previous behaviour) - adding a favourite to the current activity - moving a favourite between 'all activities' and 'current activity' modes (it does not affect non-current activities) - drag-and-drop reordering of items (like the previous one) - sorting A-Z, Z-A (like the previous one) - transitions previously defined favourites to the new system* Context menu item captions could maybe use some improvement. Screenshot available at: http://ivan.fomentgroup.org/blog/2014/07/27/per-activity-favourites-in-kickoff/#/comments * this can also be used for defining the default favourites in a global kickoffrc file - instead of them being hard-coded like they currently are. Diffs - applets/kickoff/CMakeLists.txt 28e7029 applets/kickoff/core/favoritesmodel.h 27a0626 applets/kickoff/core/favoritesmodel.cpp f05588b applets/kickoff/core/kickoffplugin.cpp f549981 applets/kickoff/core/krunnermodel.h 3916829 applets/kickoff/core/krunnermodel.cpp db2adab applets/kickoff/package/contents/ui/ContextMenu.qml 6a67874 applets/kickoff/package/contents/ui/FavoritesView.qml 6c2d5d4 applets/kickoff/package/contents/ui/FullRepresentation.qml 6291b7c Diff: https://git.reviewboard.kde.org/r/119515/diff/ Testing --- Yes Thanks, Ivan Čukić ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119522: readlink fails whens the folder does not exist.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119522/#review63351
---
So does it still work if it's a link, after this patch?
- Aleix Pol Gonzalez
On July 28, 2014, 5:17 p.m., Rohan Garg wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119522/
---
(Updated July 28, 2014, 5:17 p.m.)
Review request for Plasma and Àlex Fiestas.
Repository: plasma-workspace
Description
---
https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/f01badb5aa3f76b27955f4fee2cb7281dd490353
introduced a regression in startkde whereby if ~/.config does not exist
readlink will not output the right path.
This leads to startkde trying to write to /startupconfigkeys or /kdeglobals
which obviously won't work.
Since the original commit mentions that relative paths weren't working, I've
taken a alternative approach of using ${HOME} instead.
Diffs
-
startkde/startkde.cmake 281bd43
Diff: https://git.reviewboard.kde.org/r/119522/diff/
Testing
---
Kubuntu Plasma 5 ISO's did not have the right cursor theme before this patch,
after editing startkde by hand, the right files were being correctly written,
and the cursor theme worked as expected.
Thanks,
Rohan Garg
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119515: Support per-activity favourites
On July 28, 2014, 5:31 p.m., Thomas Braxton wrote: applets/kickoff/package/contents/ui/ContextMenu.qml, line 62 https://git.reviewboard.kde.org/r/119515/diff/1/?file=293832#file293832line62 addToGlobalFavorites sounds better Agreed. - Ivan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119515/#review63349 --- On July 28, 2014, 11:49 a.m., Ivan Čukić wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119515/ --- (Updated July 28, 2014, 11:49 a.m.) Review request for Plasma, Eike Hein, Marco Martin, and Sebastian Kügler. Repository: plasma-desktop Description --- This patch adds the support to have favourites linked to activities. It uses org.kde.activities.ResourceModel to show favorites. It supports: - adding a favourite to all activities (the previous behaviour) - adding a favourite to the current activity - moving a favourite between 'all activities' and 'current activity' modes (it does not affect non-current activities) - drag-and-drop reordering of items (like the previous one) - sorting A-Z, Z-A (like the previous one) - transitions previously defined favourites to the new system* Context menu item captions could maybe use some improvement. Screenshot available at: http://ivan.fomentgroup.org/blog/2014/07/27/per-activity-favourites-in-kickoff/#/comments * this can also be used for defining the default favourites in a global kickoffrc file - instead of them being hard-coded like they currently are. Diffs - applets/kickoff/CMakeLists.txt 28e7029 applets/kickoff/core/favoritesmodel.h 27a0626 applets/kickoff/core/favoritesmodel.cpp f05588b applets/kickoff/core/kickoffplugin.cpp f549981 applets/kickoff/core/krunnermodel.h 3916829 applets/kickoff/core/krunnermodel.cpp db2adab applets/kickoff/package/contents/ui/ContextMenu.qml 6a67874 applets/kickoff/package/contents/ui/FavoritesView.qml 6c2d5d4 applets/kickoff/package/contents/ui/FullRepresentation.qml 6291b7c Diff: https://git.reviewboard.kde.org/r/119515/diff/ Testing --- Yes Thanks, Ivan Čukić ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119522: readlink fails whens the folder does not exist.
On July 28, 2014, 11:14 p.m., Aleix Pol Gonzalez wrote:
So does it still work if it's a link, after this patch?
Yep, works when my ~/.config is a symlink.
- Rohan
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119522/#review63351
---
On July 28, 2014, 10:47 p.m., Rohan Garg wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119522/
---
(Updated July 28, 2014, 10:47 p.m.)
Review request for Plasma and Àlex Fiestas.
Repository: plasma-workspace
Description
---
https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/f01badb5aa3f76b27955f4fee2cb7281dd490353
introduced a regression in startkde whereby if ~/.config does not exist
readlink will not output the right path.
This leads to startkde trying to write to /startupconfigkeys or /kdeglobals
which obviously won't work.
Since the original commit mentions that relative paths weren't working, I've
taken a alternative approach of using ${HOME} instead.
Diffs
-
startkde/startkde.cmake 281bd43
Diff: https://git.reviewboard.kde.org/r/119522/diff/
Testing
---
Kubuntu Plasma 5 ISO's did not have the right cursor theme before this patch,
after editing startkde by hand, the right files were being correctly written,
and the cursor theme worked as expected.
Thanks,
Rohan Garg
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119465: Have separate texture hashes for each window
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119465/ --- (Updated July 28, 2014, 5:48 p.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-framework Description --- Apparently in nvidia we get corruptions when a texture created for a window is used in another one. With this patch we tell the texture has changed when we move it from a window to another, so it's re-created and we keep textures for all windows separately. This way we ensure they don't mix. Diffs - src/declarativeimports/core/framesvgitem.h 0b39c70 src/declarativeimports/core/framesvgitem.cpp ebac29f Diff: https://git.reviewboard.kde.org/r/119465/diff/ Testing --- Still works here, I hope Marco can confirm it fixes the problem. Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119515: Support per-activity favourites
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119515/ --- (Updated July 28, 2014, 5:50 p.m.) Status -- This change has been marked as submitted. Review request for Plasma, Eike Hein, Marco Martin, and Sebastian Kügler. Repository: plasma-desktop Description --- This patch adds the support to have favourites linked to activities. It uses org.kde.activities.ResourceModel to show favorites. It supports: - adding a favourite to all activities (the previous behaviour) - adding a favourite to the current activity - moving a favourite between 'all activities' and 'current activity' modes (it does not affect non-current activities) - drag-and-drop reordering of items (like the previous one) - sorting A-Z, Z-A (like the previous one) - transitions previously defined favourites to the new system* Context menu item captions could maybe use some improvement. Screenshot available at: http://ivan.fomentgroup.org/blog/2014/07/27/per-activity-favourites-in-kickoff/#/comments * this can also be used for defining the default favourites in a global kickoffrc file - instead of them being hard-coded like they currently are. Diffs - applets/kickoff/CMakeLists.txt 28e7029 applets/kickoff/core/favoritesmodel.h 27a0626 applets/kickoff/core/favoritesmodel.cpp f05588b applets/kickoff/core/kickoffplugin.cpp f549981 applets/kickoff/core/krunnermodel.h 3916829 applets/kickoff/core/krunnermodel.cpp db2adab applets/kickoff/package/contents/ui/ContextMenu.qml 6a67874 applets/kickoff/package/contents/ui/FavoritesView.qml 6c2d5d4 applets/kickoff/package/contents/ui/FullRepresentation.qml 6291b7c Diff: https://git.reviewboard.kde.org/r/119515/diff/ Testing --- Yes Thanks, Ivan Čukić ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: qml controls and documentation
On Monday 28 July 2014, Aleix Pol wrote: does somebody knows if is possible with the markup used now for extracting documentation to still have comments to document all the properties, even those *not* defined in the qml file in question? It should probably look more or less like KPushButton [1], properly showing inheritance. Anybody knows how this is implemented in doxygen? Aleix [1] http://api.kde.org/4.12-api/kdelibs-apidocs/kdeui/html/classKPushButton.htm l I think the support for Qml is way more basic. doxygen didn't use to support qml at all iirc the support was added by Aurelien some time ago, but doesn't do for sure the x methods inherited from foo part. but i wouldn't know how to make it go to fetch the documentation from the corresponfing qtcontrol. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 119524: Force OpenGLES if on Qt 5.4
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119524/ --- Review request for Plasma. Repository: plasma-workspace Description --- When trying to reduce memory usage in plasma shell, we realized that one of the reasons we got such big memory footprint was actually the intel driver (on intel systems, that is). After some investigation, David found out we were going through some memory-consuming path [1]. A way to workaround it is by using only OpenGLES. Everything still works here after this patch, so it seems to be a good change to get in. This change needs Qt 5.4, to get the new API that lets us enforce a QSurfaceFormat, hence having it ifdef'd. I'm quite unaware of problems we might find. Knowing we probably want to work in different embedded devices, suggests that OpenGLES on all platforms sounds like a safe bet. [1] http://comments.gmane.org/gmane.comp.video.mesa3d.devel/60848 Diffs - shell/main.cpp e34578d Diff: https://git.reviewboard.kde.org/r/119524/diff/ Testing --- I'm using it now, without visible problems. Now we see no trace of i915 in the massif reports. File Attachments before https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/5a6beb4f-24c0-4cee-a7a2-038385e35119__plasma-massif-opengl.png after https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/fc301ff5-cb1d-4654-a57f-82990220c8e3__plasma-massif-opengles.png Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 119523: port TextField to QtControls
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119523/ --- Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- this ports TextField to Qt Controls. Not sure if is really meargeable tough, because the old one used to export several properties and functions more, but they are not possible anymore, because in order for them to work is needed the access to the internal TextInput, and we don't have that, so some api should have to be dropped, breaking the compatibility promise. (another option would be to still use an own implementation, but use a compatible style anyways) Diffs - src/declarativeimports/plasmacomponents/qml/TextField.qml 5bc6b58 src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119523/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119524: Force OpenGLES if on Qt 5.4
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119524/#review63360 --- I still don't have 5.4 to test for now.. but, are you sure this works on the other drivers? such changes should get a test also at least on nvidia catalyst radeonhd (or whatever they're called nowdays) - Marco Martin On July 28, 2014, 6:09 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119524/ --- (Updated July 28, 2014, 6:09 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- When trying to reduce memory usage in plasma shell, we realized that one of the reasons we got such big memory footprint was actually the intel driver (on intel systems, that is). After some investigation, David found out we were going through some memory-consuming path [1]. A way to workaround it is by using only OpenGLES. Everything still works here after this patch, so it seems to be a good change to get in. This change needs Qt 5.4, to get the new API that lets us enforce a QSurfaceFormat, hence having it ifdef'd. I'm quite unaware of problems we might find. Knowing we probably want to work in different embedded devices, suggests that OpenGLES on all platforms sounds like a safe bet. [1] http://comments.gmane.org/gmane.comp.video.mesa3d.devel/60848 Diffs - shell/main.cpp e34578d Diff: https://git.reviewboard.kde.org/r/119524/diff/ Testing --- I'm using it now, without visible problems. Now we see no trace of i915 in the massif reports. File Attachments before https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/5a6beb4f-24c0-4cee-a7a2-038385e35119__plasma-massif-opengl.png after https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/fc301ff5-cb1d-4654-a57f-82990220c8e3__plasma-massif-opengles.png Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119523: port TextField to QtControls
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119523/#review63363 --- Even if we fix the methods it's too close to 5.1 to merge right now. Definitely wait till after that so we have some time to find problems. src/declarativeimports/plasmacomponents/qml/TextField.qml https://git.reviewboard.kde.org/r/119523/#comment44165 This is going to overlap with the text I think. It might be worth trying to upstream the concept of a clear button rather than working round it here. It'll be less work in the long term. I filed a bug report on this once, they're ok with the concept but want to make it so you can add any random button on the left/right, not just clear. src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml https://git.reviewboard.kde.org/r/119523/#comment44164 RAndon capitals Which methods do we need the inner control for? I saw positionAtPos and positionToRectangle, any others? - David Edmundson On July 28, 2014, 6:10 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119523/ --- (Updated July 28, 2014, 6:10 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- this ports TextField to Qt Controls. Not sure if is really meargeable tough, because the old one used to export several properties and functions more, but they are not possible anymore, because in order for them to work is needed the access to the internal TextInput, and we don't have that, so some api should have to be dropped, breaking the compatibility promise. (another option would be to still use an own implementation, but use a compatible style anyways) Diffs - src/declarativeimports/plasmacomponents/qml/TextField.qml 5bc6b58 src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119523/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119523: port TextField to QtControls
On July 28, 2014, 6:54 p.m., David Edmundson wrote:
src/declarativeimports/plasmacomponents/qml/TextField.qml, line 366
https://git.reviewboard.kde.org/r/119523/diff/1/?file=293985#file293985line366
This is going to overlap with the text I think.
It might be worth trying to upstream the concept of a clear button
rather than working round it here. It'll be less work in the long term.
I filed a bug report on this once, they're ok with the concept but want
to make it so you can add any random button on the left/right, not just
clear.
yes, it does overlap, i don't have much ways to avoid it.
maybe worth it upstreaming yeah, I guess they would like something
TextField {
property Item ActionButton
}
and actionButton would be a whatever item that gets anchored on the right area,
or would that be restricted to a button? (so just being able to set text,
tooltip and a signal handler?)
On July 28, 2014, 6:54 p.m., Marco Martin wrote:
Which methods do we need the inner control for? I saw positionAtPos and
positionToRectangle, any others?
those two and passwordCharacter
- Marco
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119523/#review63363
---
On July 28, 2014, 6:10 p.m., Marco Martin wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119523/
---
(Updated July 28, 2014, 6:10 p.m.)
Review request for KDE Frameworks and Plasma.
Repository: plasma-framework
Description
---
this ports TextField to Qt Controls.
Not sure if is really meargeable tough, because the old one used to export
several properties and functions more, but they are not possible anymore,
because in order for them to work is needed the access to the internal
TextInput, and we don't have that, so some api should have to be dropped,
breaking the compatibility promise.
(another option would be to still use an own implementation, but use a
compatible style anyways)
Diffs
-
src/declarativeimports/plasmacomponents/qml/TextField.qml 5bc6b58
src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml
PRE-CREATION
Diff: https://git.reviewboard.kde.org/r/119523/diff/
Testing
---
Thanks,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119523: port TextField to QtControls
On July 28, 2014, 6:54 p.m., Marco Martin wrote: Which methods do we need the inner control for? I saw positionAtPos and positionToRectangle, any others? Marco Martin wrote: those two and passwordCharacter and missing properties are: passwordCharacter errorHighlight - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119523/#review63363 --- On July 28, 2014, 6:10 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119523/ --- (Updated July 28, 2014, 6:10 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- this ports TextField to Qt Controls. Not sure if is really meargeable tough, because the old one used to export several properties and functions more, but they are not possible anymore, because in order for them to work is needed the access to the internal TextInput, and we don't have that, so some api should have to be dropped, breaking the compatibility promise. (another option would be to still use an own implementation, but use a compatible style anyways) Diffs - src/declarativeimports/plasmacomponents/qml/TextField.qml 5bc6b58 src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119523/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119524: Force OpenGLES if on Qt 5.4
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119524/#review63366 --- If there is one hardware combination that works best on linux, it's OpenGL + Intel. I find it hard to believe that GLES is better and in all cases. That must be a driver/mesa bug that should be investigated and fixed. If this would've been a fix to workaround crappy AMD drivers, then this patch would be understandable. AMD is just slacking. But switching to OpenGL ES on all platforms because intel supposedly performs better is a bit weird. Can't the plasma graphics stack (OpenGL or OpenGL ES) be chosen at runtime like it can with KWin? Perhaps you can even re-use KWin's GL setting in plasma? - Mark Gaiser On jul 28, 2014, 6:09 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119524/ --- (Updated jul 28, 2014, 6:09 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- When trying to reduce memory usage in plasma shell, we realized that one of the reasons we got such big memory footprint was actually the intel driver (on intel systems, that is). After some investigation, David found out we were going through some memory-consuming path [1]. A way to workaround it is by using only OpenGLES. Everything still works here after this patch, so it seems to be a good change to get in. This change needs Qt 5.4, to get the new API that lets us enforce a QSurfaceFormat, hence having it ifdef'd. I'm quite unaware of problems we might find. Knowing we probably want to work in different embedded devices, suggests that OpenGLES on all platforms sounds like a safe bet. [1] http://comments.gmane.org/gmane.comp.video.mesa3d.devel/60848 Diffs - shell/main.cpp e34578d Diff: https://git.reviewboard.kde.org/r/119524/diff/ Testing --- I'm using it now, without visible problems. Now we see no trace of i915 in the massif reports. File Attachments before https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/5a6beb4f-24c0-4cee-a7a2-038385e35119__plasma-massif-opengl.png after https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/fc301ff5-cb1d-4654-a57f-82990220c8e3__plasma-massif-opengles.png Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119523: port TextField to QtControls
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119523/#review63367 --- src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml https://git.reviewboard.kde.org/r/119523/#comment44168 Why no binding? src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml https://git.reviewboard.kde.org/r/119523/#comment44169 Can't you account for the clear button width here? - Kai Uwe Broulik On Juli 28, 2014, 6:10 nachm., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119523/ --- (Updated Juli 28, 2014, 6:10 nachm.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- this ports TextField to Qt Controls. Not sure if is really meargeable tough, because the old one used to export several properties and functions more, but they are not possible anymore, because in order for them to work is needed the access to the internal TextInput, and we don't have that, so some api should have to be dropped, breaking the compatibility promise. (another option would be to still use an own implementation, but use a compatible style anyways) Diffs - src/declarativeimports/plasmacomponents/qml/TextField.qml 5bc6b58 src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119523/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119523: port TextField to QtControls
On July 28, 2014, 7:09 p.m., Kai Uwe Broulik wrote:
src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml, line
52
https://git.reviewboard.kde.org/r/119523/diff/1/?file=293986#file293986line52
Can't you account for the clear button width here?
probably
On July 28, 2014, 7:09 p.m., Kai Uwe Broulik wrote:
src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml, line
49
https://git.reviewboard.kde.org/r/119523/diff/1/?file=293986#file293986line49
Why no binding?
I can't access the framesvg from the level of the root.
could probably use a Binding {} tough
- Marco
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119523/#review63367
---
On July 28, 2014, 6:10 p.m., Marco Martin wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119523/
---
(Updated July 28, 2014, 6:10 p.m.)
Review request for KDE Frameworks and Plasma.
Repository: plasma-framework
Description
---
this ports TextField to Qt Controls.
Not sure if is really meargeable tough, because the old one used to export
several properties and functions more, but they are not possible anymore,
because in order for them to work is needed the access to the internal
TextInput, and we don't have that, so some api should have to be dropped,
breaking the compatibility promise.
(another option would be to still use an own implementation, but use a
compatible style anyways)
Diffs
-
src/declarativeimports/plasmacomponents/qml/TextField.qml 5bc6b58
src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml
PRE-CREATION
Diff: https://git.reviewboard.kde.org/r/119523/diff/
Testing
---
Thanks,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119523: port TextField to QtControls
On July 28, 2014, 6:54 p.m., David Edmundson wrote:
src/declarativeimports/plasmacomponents/qml/TextField.qml, line 366
https://git.reviewboard.kde.org/r/119523/diff/1/?file=293985#file293985line366
This is going to overlap with the text I think.
It might be worth trying to upstream the concept of a clear button
rather than working round it here. It'll be less work in the long term.
I filed a bug report on this once, they're ok with the concept but want
to make it so you can add any random button on the left/right, not just
clear.
Marco Martin wrote:
yes, it does overlap, i don't have much ways to avoid it.
maybe worth it upstreaming yeah, I guess they would like something
TextField {
property Item ActionButton
}
and actionButton would be a whatever item that gets anchored on the right
area, or would that be restricted to a button? (so just being able to set
text, tooltip and a signal handler?)
EDIT: I didn't file a bug, Martin G did. I get the two of us confused sometimes.
https://bugreports.qt-project.org/browse/QTBUG-37373
- David
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119523/#review63363
---
On July 28, 2014, 6:10 p.m., Marco Martin wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119523/
---
(Updated July 28, 2014, 6:10 p.m.)
Review request for KDE Frameworks and Plasma.
Repository: plasma-framework
Description
---
this ports TextField to Qt Controls.
Not sure if is really meargeable tough, because the old one used to export
several properties and functions more, but they are not possible anymore,
because in order for them to work is needed the access to the internal
TextInput, and we don't have that, so some api should have to be dropped,
breaking the compatibility promise.
(another option would be to still use an own implementation, but use a
compatible style anyways)
Diffs
-
src/declarativeimports/plasmacomponents/qml/TextField.qml 5bc6b58
src/declarativeimports/plasmacomponents/qml/styles/TextFieldStyle.qml
PRE-CREATION
Diff: https://git.reviewboard.kde.org/r/119523/diff/
Testing
---
Thanks,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Minutes Monday Plasma Hangout
On Monday 28 July 2014, Marco Martin wrote: [Icons] Theme=~/.share/plasma/lookandfeel/foo/icons comments on that? furthermore, how would you prefer to use it? as a standalone library? static in plasma-workspace stuff? in libplasmaquick? other? next on that, the lookandfeel package should somehowinfluence khintsettings in the frameworkintegration framework (that of course couldn't depend from a package) khintsettings should do something along the lines: * with some heuristics access the lookandfeel package (it's only a folder after all, wouldn't be very difficult) and open a config file with default icons/widget style etc * read the default if available, fallback to an hardcoded internal one if fail -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: qml controls and documentation
On Mon, Jul 28, 2014 at 8:07 PM, Marco Martin notm...@gmail.com wrote: On Monday 28 July 2014, Aleix Pol wrote: does somebody knows if is possible with the markup used now for extracting documentation to still have comments to document all the properties, even those *not* defined in the qml file in question? It should probably look more or less like KPushButton [1], properly showing inheritance. Anybody knows how this is implemented in doxygen? Aleix [1] http://api.kde.org/4.12-api/kdelibs-apidocs/kdeui/html/classKPushButton.htm l I think the support for Qml is way more basic. doxygen didn't use to support qml at all iirc the support was added by Aurelien some time ago, but doesn't do for sure the x methods inherited from foo part. but i wouldn't know how to make it go to fetch the documentation from the corresponfing qtcontrol. Well, maybe it should stop being basic :D. /me invokes an Aurélien. Hey, do you know where can we find the code that generates the documentation for QML modules? Do you know how hard would it be to implement inheritance and inheritance graphs like in C++? Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119524: Force OpenGLES if on Qt 5.4
On July 28, 2014, 6:25 p.m., Eike Hein wrote: Can you recompile plasma-desktop with OpenGL ES and test if the drag pixmap for Folder icons works? I wrote the code in a way that ought to work on both desktop GL and ES, but it's worth testing. I have it running with OpenGLES at the moment, it seems to work fine the Folder View. If there's anything specific you want me to try, don't hesitate to tell me (here or in IRC, etc.). - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119524/#review63362 --- On July 28, 2014, 6:09 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119524/ --- (Updated July 28, 2014, 6:09 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- When trying to reduce memory usage in plasma shell, we realized that one of the reasons we got such big memory footprint was actually the intel driver (on intel systems, that is). After some investigation, David found out we were going through some memory-consuming path [1]. A way to workaround it is by using only OpenGLES. Everything still works here after this patch, so it seems to be a good change to get in. This change needs Qt 5.4, to get the new API that lets us enforce a QSurfaceFormat, hence having it ifdef'd. I'm quite unaware of problems we might find. Knowing we probably want to work in different embedded devices, suggests that OpenGLES on all platforms sounds like a safe bet. [1] http://comments.gmane.org/gmane.comp.video.mesa3d.devel/60848 Diffs - shell/main.cpp e34578d Diff: https://git.reviewboard.kde.org/r/119524/diff/ Testing --- I'm using it now, without visible problems. Now we see no trace of i915 in the massif reports. File Attachments before https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/5a6beb4f-24c0-4cee-a7a2-038385e35119__plasma-massif-opengl.png after https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/fc301ff5-cb1d-4654-a57f-82990220c8e3__plasma-massif-opengles.png Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119524: Force OpenGLES if on Qt 5.4
On July 28, 2014, 7:03 p.m., Mark Gaiser wrote: If there is one hardware combination that works best on linux, it's OpenGL + Intel. I find it hard to believe that GLES is better and in all cases. That must be a driver/mesa bug that should be investigated and fixed. If this would've been a fix to workaround crappy AMD drivers, then this patch would be understandable. AMD is just slacking. But switching to OpenGL ES on all platforms because intel supposedly performs better is a bit weird. Can't the plasma graphics stack (OpenGL or OpenGL ES) be chosen at runtime like it can with KWin? Perhaps you can even re-use KWin's GL setting in plasma? Well, OpenGL ES is a subset of OpenGL, so less things will be available but I'd say it's better to use the small thing until we need the big one rather than the other way around. Especially if we want to think about devices, some day. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119524/#review63366 --- On July 28, 2014, 6:09 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119524/ --- (Updated July 28, 2014, 6:09 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- When trying to reduce memory usage in plasma shell, we realized that one of the reasons we got such big memory footprint was actually the intel driver (on intel systems, that is). After some investigation, David found out we were going through some memory-consuming path [1]. A way to workaround it is by using only OpenGLES. Everything still works here after this patch, so it seems to be a good change to get in. This change needs Qt 5.4, to get the new API that lets us enforce a QSurfaceFormat, hence having it ifdef'd. I'm quite unaware of problems we might find. Knowing we probably want to work in different embedded devices, suggests that OpenGLES on all platforms sounds like a safe bet. [1] http://comments.gmane.org/gmane.comp.video.mesa3d.devel/60848 Diffs - shell/main.cpp e34578d Diff: https://git.reviewboard.kde.org/r/119524/diff/ Testing --- I'm using it now, without visible problems. Now we see no trace of i915 in the massif reports. File Attachments before https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/5a6beb4f-24c0-4cee-a7a2-038385e35119__plasma-massif-opengl.png after https://git.reviewboard.kde.org/media/uploaded/files/2014/07/28/fc301ff5-cb1d-4654-a57f-82990220c8e3__plasma-massif-opengles.png Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Minutes Monday Plasma Hangout
On Mon, Jul 28, 2014 at 9:36 PM, Marco Martin notm...@gmail.com wrote: On Monday 28 July 2014, Marco Martin wrote: [Icons] Theme=~/.share/plasma/lookandfeel/foo/icons comments on that? furthermore, how would you prefer to use it? as a standalone library? static in plasma-workspace stuff? in libplasmaquick? other? next on that, the lookandfeel package should somehowinfluence khintsettings in the frameworkintegration framework (that of course couldn't depend from a package) khintsettings should do something along the lines: * with some heuristics access the lookandfeel package (it's only a folder after all, wouldn't be very difficult) and open a config file with default icons/widget style etc * read the default if available, fallback to an hardcoded internal one if fail Agreed, also fonts could have a place there. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Minutes Monday Plasma Hangout
On Mon, Jul 28, 2014 at 5:56 PM, Marco Martin notm...@gmail.com wrote: On Monday 28 July 2014, Marco Martin wrote: On Monday 28 July 2014, Sebastian Kügler wrote: - Started mechanism to load stuff from Look and Feel packages would like comment on https://git.reviewboard.kde.org/r/119451/ Based on the discussion with David in the hangout, i would still do: - the look and feel package provides qml files for some parts of the shell - most theme elements (icons, plasma theme, widget style etc) are usually provided only referred in a config file - if a theme wants to phisically provide something, like a plasma theme, icon theme etc, it can, bout would be task of the kcm to either copy or make a link of say, the icon theme in the proper directory where an icon theme would be expected. - or in alternative, the theme could be specified in the config file as a full path, so for icons if you are using the foo look and feel package, you could have in kdeglobals [Icons] Theme=~/.share/plasma/lookandfeel/foo/icons comments on that? furthermore, how would you prefer to use it? as a standalone library? static in plasma-workspace stuff? in libplasmaquick? other? Maybe we should have a library for accessing lookfeel packages? I don't think it belongs to libplasma, since libplasma is about applets and containments management. We could have a library within plasma-workspace that does this? If we need to expose it further we could consider at some point, but I don't think it will be needed. About how to tell what icon theme the lookfeel package suggests to use, I think that rather than specifying a path, it should be specifying a unique identifier so that we know how to get it. Something like Themes=default:/breeze or Themes=kns:/diamond or Themes=bodega:/awesomefuturisticrainbows or Themes=http://... Does that make sense? Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
