Re: Review Request 119330: Convert FrameSvgItem to use 9 tiles instead of a big texture.
On July 18, 2014, 11:58 a.m., Marco Martin wrote: framesvgitem part starting to look good! I would still like to have all of framesvg private again tough Aleix Pol Gonzalez wrote: Can you ellaborate on what don't you like about the approach? We're not installing headers, so we don't need to maintain ABI there. All of the data taken from FrameData is obtainable from Svg public api, with code no more complex, even. Even if Qt is doing it I don't care (there they have a level of complexity that actually justifies that, plus they have to access things that do not have any alternate way to accessing, unlike this), no private parts exported as symbols is a policy I'm quite serious to enforce in that library. - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/#review62651 --- On July 18, 2014, 10:54 a.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/ --- (Updated July 18, 2014, 10:54 a.m.) Review request for Plasma. Repository: plasma-framework Description --- Use FrameSVG as 9 tiles instead of uploading a big texture of the finished frame each time. This also saves the cache being populated with full created frames in different sizes; which end up taking up space in the disk and shared memory cache as well as the GPU memory. A code path falls back to the original uploading the entire texture if obscure settings are used, i.e overlay. Benchmarks: - apitrace when resizing a frame goes from an average of 7.6ms per frame of *CPU* time just for the swizzling and uploading to 1.4ms - GPU time also drops from 40us to 10us Themes will need to remove stretch-borders (when we gain nothing from stretching; i.e Breeze) to get the most out of it. Diffs - src/plasma/private/framesvg_p.h 8aceef2 tests/dialog.qml PRE-CREATION tests/testborders.qml PRE-CREATION src/declarativeimports/core/framesvgitem.h e155f6a src/declarativeimports/core/framesvgitem.cpp 8320212 src/declarativeimports/core/svgitem.cpp 1ed0631 src/plasma/framesvg.h dd6d8da src/plasma/framesvg.cpp fcc6809 Diff: https://git.reviewboard.kde.org/r/119330/diff/ Testing --- Tested oxygen + breeze + some random (and ugly) themes from kde-look. Theme changes work. Everything looks the same; including the borders on oxygen. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Assign plasmoid global shortcut to custom action
On Sunday 20 July 2014, Simone Gaiarin wrote: Hi all, I'm trying to use the global shortcut that the user can configure from the Shortcut configuration page of a plasma applet, to trigger a KAction and let the plasmoid do something. I've done this //Setup the action m_toggleAction = new KAction(ToggleAction, this); //Add action to the plasmoid action collection addAction(ToggleAction, m_toggleAction); m_toggleAction-setGlobalShortcut(globalShortcut()); connect(m_toggleAction, SIGNAL(triggered(bool)), this, SLOT(toggle())); but nothing happens when I trigger the shortcut. Do anyone know what I'm missing? Is there any plasmoid that is using the global shortcut feature? Thanks hmm, that's kde4, right? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119379: Lockscreen accessibility
On Lug. 20, 2014, 4:11 p.m., David Edmundson wrote: lookandfeel/contents/components/LogoutOptions.qml, line 64 https://git.reviewboard.kde.org/r/119379/diff/1/?file=291353#file291353line64 I think this may need to be i18ncd; unless someone is setting the catalog on the c++ side. Current code has a mix, so Im not sure. Frederik Gladhorn wrote: That was actually the main reason for the review request - I dunno how the catalog stuff works these days. It would be great if someone could shed some light on this :) not sure if who loads the lockscreen qml sets a default domain. If not, it needs a domain set explicitly (like the same as the package name may work) - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119379/#review62741 --- On Lug. 20, 2014, 4:05 p.m., Frederik Gladhorn wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119379/ --- (Updated Lug. 20, 2014, 4:05 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- Make lockscreen buttons say something and let shutdown/lock/reboot buttons get focus. Diffs - lookandfeel/contents/components/LogoutOptions.qml d3ccea0 lookandfeel/contents/components/UserDelegate.qml 2221368 Diff: https://git.reviewboard.kde.org/r/119379/diff/ Testing --- Tested with Orca. Thanks, Frederik Gladhorn ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Fallbacks for packages
Hi all, I have been thinking about the problem of the look and feel and shell packages: we want them to be easily customizable for distributions without forcing to copy and paste the mayority of the qml in the package (and also having things like providing only a spashscreen and nothing else) so when a different look and feel package is configured, when a file is not found there, it should be checked for in the default one instead. some different scenarios/ideas popped in mind: Completely generic: in the package desktop file there is the name of another one used as fallback Pros: * very flexible, easy way to share code between plasmoids (like various taskbars) Cons: * all packages become public api, maintainace nightmare * possibility of circular dependencies One partial solution would be limiting the allowed fallbacks only to packages that start with org.kde.* , but seems quite ineffective, in reality. Another solution is to have a single one default package to fallback, (defined in the packagestructure) so in case of lookandfeel the base org.kde.lookandfeel would be the fallback and no other one could be used. It's limited, but (for this very reason) i very much prefer this. The drawback is that it could be used for lookandfeel and for the shell packages, but *not* for plasmoids. And a last one, would be to just use two packages in the client code. It would be the solution i would normally prefer, but since the look and feel package is accessed by too many different processes, entry points, it would mean a lot of duplication of error prone code. opinions? comments? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Wayland planning meeting
On Wednesday, July 16, 2014 15:49:42 Sebastian Kügler wrote: Hey, During the planning meeting for 5.1, it became evident that we need a planning meeting for our Wayland efforts. Here's a doodle, that, if you will work on Wayland support or can help otherwise, you'll want to fill in: http://doodle.com/t7y73vzhxxn5x9bp Cheers, We're aiming for 16:00 CEST today, on IRC #plasma. -- 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 119384: Plasma-Active: Make widget explorer more friendly on touch devices.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119384/#review62773 --- Ship it! You should also center it horizontally activeshellpackage/package/contents/explorer/AppletDelegate.qml https://git.reviewboard.kde.org/r/119384/#comment43520 I'm not sure it it should add it immediately or add it to a list and then mass-add on ok pressed, let's try to see what happens with immediate add+close of the window activeshellpackage/package/contents/views/Desktop.qml https://git.reviewboard.kde.org/r/119384/#comment43517 in this case we want focus and to close it when the focus gets lost (clicked outside) activeshellpackage/package/contents/views/Desktop.qml https://git.reviewboard.kde.org/r/119384/#comment43518 don't hardcode, use a good margin based on units.gridUnit (that makes it remain a couple of centimeters at left, right and top) - Marco Martin On Lug. 21, 2014, 11:48 a.m., Antonis Tsiapaliokas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119384/ --- (Updated Lug. 21, 2014, 11:48 a.m.) Review request for Plasma and Marco Martin. Repository: plasma-mobile Description --- This patch make the widget explorer more friendly on touch devices. Diffs - activeshellpackage/package/contents/explorer/AppletDelegate.qml 35c62fc activeshellpackage/package/contents/explorer/Tooltip.qml 0eafa19 activeshellpackage/package/contents/explorer/WidgetExplorer.qml 9ad9b88 activeshellpackage/package/contents/views/Desktop.qml 6582fd7 Diff: https://git.reviewboard.kde.org/r/119384/diff/ Testing --- File Attachments widget exploer https://git.reviewboard.kde.org/media/uploaded/files/2014/07/21/522038d2-b4da-4c34-9d9c-11aa5666fe8d__widgetexplorer.png Thanks, Antonis Tsiapaliokas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118180: slideshow BUG patch fix
On June 5, 2014, 10:12 a.m., Christoph Feck wrote: Please add Plasma developers to the group of reviewers. Btw, you cannot give Ship It to yourself, others have to approve it. TOM Harrison wrote: that just a wrong click :) TOM Harrison wrote: thanks for reminding for the missing reviewers. I guess nobody looked at it yet because in the list it appears as already approved. I will ping plasma developers. - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118180/#review59300 --- On June 5, 2014, 10:32 a.m., TOM Harrison wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118180/ --- (Updated June 5, 2014, 10:32 a.m.) Review request for kde-workspace and Plasma. Bugs: 327580 http://bugs.kde.org/show_bug.cgi?id=327580 Repository: kde-workspace Description --- bug patch for slideshow dir list missing Diffs - libs/plasmagenericshell/backgrounddialog.cpp 645de3f Diff: https://git.reviewboard.kde.org/r/118180/diff/ Testing --- Thanks, TOM Harrison ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118180: slideshow BUG patch fix
On 六月 5, 2014, 10:12 a.m., Christoph Feck wrote: Please add Plasma developers to the group of reviewers. Btw, you cannot give Ship It to yourself, others have to approve it. TOM Harrison wrote: that just a wrong click :) TOM Harrison wrote: thanks for reminding for the missing reviewers. Christoph Feck wrote: I guess nobody looked at it yet because in the list it appears as already approved. I will ping plasma developers. I am still waiting the plasma reviewer to approve :(, though I am using this path already. - TOM --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118180/#review59300 --- On 六月 5, 2014, 10:32 a.m., TOM Harrison wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118180/ --- (Updated 六月 5, 2014, 10:32 a.m.) Review request for kde-workspace and Plasma. Bugs: 327580 http://bugs.kde.org/show_bug.cgi?id=327580 Repository: kde-workspace Description --- bug patch for slideshow dir list missing Diffs - libs/plasmagenericshell/backgrounddialog.cpp 645de3f Diff: https://git.reviewboard.kde.org/r/118180/diff/ Testing --- Thanks, TOM Harrison ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118180: slideshow BUG patch fix
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118180/#review62779 --- libs/plasmagenericshell/backgrounddialog.cpp https://git.reviewboard.kde.org/r/118180/#comment43523 here the coding style looks wrong - Martin Gräßlin On June 5, 2014, 12:32 p.m., TOM Harrison wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118180/ --- (Updated June 5, 2014, 12:32 p.m.) Review request for kde-workspace and Plasma. Bugs: 327580 http://bugs.kde.org/show_bug.cgi?id=327580 Repository: kde-workspace Description --- bug patch for slideshow dir list missing Diffs - libs/plasmagenericshell/backgrounddialog.cpp 645de3f Diff: https://git.reviewboard.kde.org/r/118180/diff/ Testing --- Thanks, TOM Harrison ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118180: slideshow BUG patch fix
On 七月 21, 2014, 12:39 p.m., Martin Gräßlin wrote: what kind of issue? tab and space different ? - TOM --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118180/#review62779 --- On 六月 5, 2014, 10:32 a.m., TOM Harrison wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118180/ --- (Updated 六月 5, 2014, 10:32 a.m.) Review request for kde-workspace and Plasma. Bugs: 327580 http://bugs.kde.org/show_bug.cgi?id=327580 Repository: kde-workspace Description --- bug patch for slideshow dir list missing Diffs - libs/plasmagenericshell/backgrounddialog.cpp 645de3f Diff: https://git.reviewboard.kde.org/r/118180/diff/ Testing --- Thanks, TOM Harrison ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118180: slideshow BUG patch fix
On July 21, 2014, 12:39 p.m., Martin Gräßlin wrote: TOM Harrison wrote: what kind of issue? tab and space different ? Yes, don't use tabs at all for code indentation, use 4 spaces. It should look consistent with the surrounding code after that. - Sebastian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118180/#review62779 --- On June 5, 2014, 10:32 a.m., TOM Harrison wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118180/ --- (Updated June 5, 2014, 10:32 a.m.) Review request for kde-workspace and Plasma. Bugs: 327580 http://bugs.kde.org/show_bug.cgi?id=327580 Repository: kde-workspace Description --- bug patch for slideshow dir list missing Diffs - libs/plasmagenericshell/backgrounddialog.cpp 645de3f Diff: https://git.reviewboard.kde.org/r/118180/diff/ Testing --- Thanks, TOM Harrison ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Wayland plasnning meeting notes
This is hopefully a synopsis of what has been said in the wayland planning meeting. If I got something wrong, please reply in the thread the correction ;) mgraesslin: * will give a talk on the current state at akademy * it probably does not make any sense to start working on other parts before at least the basics are ready in KWin * Weston as a development target will not give us much to work on Plasma plfiorini: * would like to write the plasmashell and test it in another compositor (not weston) at the same time you can wrok on kwin * is pushing for QtWayland release together with Qt 4.4, let's see if that happens Sho asks if couldn't we write a kwindowsystem backend that speaks xdg_shell to the compositor? Mgraesslin: wouldn't help, because xdg_shell is for taking with other windows - no need to have that in KWindowSystem as QtWayland needs to speak it. This is an implementation detail, and should not be public api. The idea is to get the Wayland backend into KWin and map all relevant information to an X11 window. Wayland windows would still be valid X11 windows. Libtaskmanager would then still work and will make possible a step by step transition, and would allow to reuse a lot of current code in KWin. Also part of the same plan, libtaskmanager should be plugin based. If we go that road we could implement the required plugin in libtaskmanager first without having to go all public directly. Discussion then gone a bit over Dialog: it needs to position itself with global coordinates and know the screen geometry. some changes in wayland, or the plasmashell-kwin protocol will need to allow global coordinates for windows. plfiorini: seems decision is leaning towards not having a system compositor. mgraesslin: kwin needs one:for 2 reasons: we can't have hardware specific code (like rendering on raspberry codepath) and kwin should not be privileged. So KWin may use the fullscreen shell of Weston as system compositor, different from the old concept of system compositor. mgraesslin: the wayland part of KWin will be quite standalone and isolated, so can be used as an integrated Wayland server, usable for integration tests Plasmashell relies heavily on KScreen that may pose a problem: it will need either to have KScreen supporting Wayland internally or to be ported again back to QScreen, needing QScreen to be fixed on both X11 and Wayland. Shadows should still have a protocol similar to now, to be painted by kwin and not by the window. In the same way output only windows should have a protocol for that instead of playing with masks, the general direction is to have protocols shell-kwin instead of windows working around problems. plfiorini says he may have a draft of the palsmashell-kwin protocol spec open for comment around middle of August. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118180: slideshow BUG patch fix
On 七月 21, 2014, 12:39 p.m., Martin Gräßlin wrote: TOM Harrison wrote: what kind of issue? tab and space different ? Sebastian Kügler wrote: Yes, don't use tabs at all for code indentation, use 4 spaces. It should look consistent with the surrounding code after that. OK, I have fix in the patch. I will upload later, if it could detect as a patch.. - TOM --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118180/#review62779 --- On 六月 5, 2014, 10:32 a.m., TOM Harrison wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118180/ --- (Updated 六月 5, 2014, 10:32 a.m.) Review request for kde-workspace and Plasma. Bugs: 327580 http://bugs.kde.org/show_bug.cgi?id=327580 Repository: kde-workspace Description --- bug patch for slideshow dir list missing Diffs - libs/plasmagenericshell/backgrounddialog.cpp 645de3f Diff: https://git.reviewboard.kde.org/r/118180/diff/ Testing --- Thanks, TOM Harrison ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118180: slideshow BUG patch fix
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118180/#review62784 --- modulo the indentation, it should be ok - Marco Martin On Giu. 5, 2014, 10:32 a.m., TOM Harrison wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118180/ --- (Updated Giu. 5, 2014, 10:32 a.m.) Review request for kde-workspace and Plasma. Bugs: 327580 http://bugs.kde.org/show_bug.cgi?id=327580 Repository: kde-workspace Description --- bug patch for slideshow dir list missing Diffs - libs/plasmagenericshell/backgrounddialog.cpp 645de3f Diff: https://git.reviewboard.kde.org/r/118180/diff/ Testing --- Thanks, TOM Harrison ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118180: slideshow BUG patch fix
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118180/ --- (Updated 七月 21, 2014, 1:12 p.m.) Review request for kde-workspace and Plasma. Bugs: 327580 http://bugs.kde.org/show_bug.cgi?id=327580 Repository: kde-workspace Description --- bug patch for slideshow dir list missing Diffs (updated) - libs/plasmagenericshell/backgrounddialog.cpp 645de3f Diff: https://git.reviewboard.kde.org/r/118180/diff/ Testing --- Thanks, TOM Harrison ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Assign plasmoid global shortcut to custom action
Yes. It's kde4. 2014-07-21 10:29 GMT+02:00 Marco Martin notm...@gmail.com: On Sunday 20 July 2014, Simone Gaiarin wrote: Hi all, I'm trying to use the global shortcut that the user can configure from the Shortcut configuration page of a plasma applet, to trigger a KAction and let the plasmoid do something. I've done this //Setup the action m_toggleAction = new KAction(ToggleAction, this); //Add action to the plasmoid action collection addAction(ToggleAction, m_toggleAction); m_toggleAction-setGlobalShortcut(globalShortcut()); connect(m_toggleAction, SIGNAL(triggered(bool)), this, SLOT(toggle())); but nothing happens when I trigger the shortcut. Do anyone know what I'm missing? Is there any plasmoid that is using the global shortcut feature? Thanks hmm, that's kde4, right? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Wayland plasnning meeting notes
On Mon, Jul 21, 2014 at 3:06 PM, Marco Martin notm...@gmail.com wrote: This is hopefully a synopsis of what has been said in the wayland planning meeting. If I got something wrong, please reply in the thread the correction ;) mgraesslin: * will give a talk on the current state at akademy * it probably does not make any sense to start working on other parts before at least the basics are ready in KWin * Weston as a development target will not give us much to work on Plasma plfiorini: * would like to write the plasmashell and test it in another compositor (not weston) at the same time you can wrok on kwin * is pushing for QtWayland release together with Qt 4.4, let's see if that happens Sho asks if couldn't we write a kwindowsystem backend that speaks xdg_shell to the compositor? Mgraesslin: wouldn't help, because xdg_shell is for taking with other windows - no need to have that in KWindowSystem as QtWayland needs to speak it. This is an implementation detail, and should not be public api. The idea is to get the Wayland backend into KWin and map all relevant information to an X11 window. Wayland windows would still be valid X11 windows. Libtaskmanager would then still work and will make possible a step by step transition, and would allow to reuse a lot of current code in KWin. Also part of the same plan, libtaskmanager should be plugin based. If we go that road we could implement the required plugin in libtaskmanager first without having to go all public directly. Discussion then gone a bit over Dialog: it needs to position itself with global coordinates and know the screen geometry. some changes in wayland, or the plasmashell-kwin protocol will need to allow global coordinates for windows. plfiorini: seems decision is leaning towards not having a system compositor. mgraesslin: kwin needs one:for 2 reasons: we can't have hardware specific code (like rendering on raspberry codepath) and kwin should not be privileged. So KWin may use the fullscreen shell of Weston as system compositor, different from the old concept of system compositor. mgraesslin: the wayland part of KWin will be quite standalone and isolated, so can be used as an integrated Wayland server, usable for integration tests Plasmashell relies heavily on KScreen that may pose a problem: it will need either to have KScreen supporting Wayland internally or to be ported again back to QScreen, needing QScreen to be fixed on both X11 and Wayland. Shadows should still have a protocol similar to now, to be painted by kwin and not by the window. In the same way output only windows should have a protocol for that instead of playing with masks, the general direction is to have protocols shell-kwin instead of windows working around problems. plfiorini says he may have a draft of the palsmashell-kwin protocol spec open for comment around middle of August. Regarding KScreen, it really should be ported, at the moment QScreen doesn't provide the information we need. I introduced one of the big missings for 5.4, which was screenRemoved, but we'll still need at least a primaryChanged signal. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119330: Convert FrameSvgItem to use 9 tiles instead of a big texture.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/ --- (Updated July 21, 2014, 1:51 p.m.) Review request for Plasma. Repository: plasma-framework Description --- Use FrameSVG as 9 tiles instead of uploading a big texture of the finished frame each time. This also saves the cache being populated with full created frames in different sizes; which end up taking up space in the disk and shared memory cache as well as the GPU memory. A code path falls back to the original uploading the entire texture if obscure settings are used, i.e overlay. Benchmarks: - apitrace when resizing a frame goes from an average of 7.6ms per frame of *CPU* time just for the swizzling and uploading to 1.4ms - GPU time also drops from 40us to 10us Themes will need to remove stretch-borders (when we gain nothing from stretching; i.e Breeze) to get the most out of it. Diffs (updated) - src/declarativeimports/core/svgitem.cpp 1ed0631 src/declarativeimports/core/tooltipdialog.cpp e62ed6e src/plasma/framesvg.h dd6d8da src/plasma/framesvg.cpp fcc6809 src/plasma/private/framesvg_p.h 8aceef2 tests/dialog.qml PRE-CREATION tests/testborders.qml PRE-CREATION src/declarativeimports/core/framesvgitem.cpp 8320212 src/declarativeimports/core/framesvgitem.h e155f6a Diff: https://git.reviewboard.kde.org/r/119330/diff/ Testing --- Tested oxygen + breeze + some random (and ugly) themes from kde-look. Theme changes work. Everything looks the same; including the borders on oxygen. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119330: Convert FrameSvgItem to use 9 tiles instead of a big texture.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/#review62788 --- It is possible to have neither private objects exported, neither public api added. Yes, it duplicates a bit of the implementation, but I rather prefer it a lot than either adding api or exporting private symbols. src/plasma/framesvg.h https://git.reviewboard.kde.org/r/119330/#comment43529 err, it's not really how I intended in the previous review.. adding public api is even worse... those 3 really don't give any extra information compared to what you can obtain with just the plain Svg api. src/plasma/framesvg.h https://git.reviewboard.kde.org/r/119330/#comment43528 private: src/plasma/framesvg.cpp https://git.reviewboard.kde.org/r/119330/#comment43527 this doesn't use framesvg internal data at all, it doesn't really have to be in framesvg - Marco Martin On July 21, 2014, 1:51 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/ --- (Updated July 21, 2014, 1:51 p.m.) Review request for Plasma. Repository: plasma-framework Description --- Use FrameSVG as 9 tiles instead of uploading a big texture of the finished frame each time. This also saves the cache being populated with full created frames in different sizes; which end up taking up space in the disk and shared memory cache as well as the GPU memory. A code path falls back to the original uploading the entire texture if obscure settings are used, i.e overlay. Benchmarks: - apitrace when resizing a frame goes from an average of 7.6ms per frame of *CPU* time just for the swizzling and uploading to 1.4ms - GPU time also drops from 40us to 10us Themes will need to remove stretch-borders (when we gain nothing from stretching; i.e Breeze) to get the most out of it. Diffs - src/declarativeimports/core/svgitem.cpp 1ed0631 src/declarativeimports/core/tooltipdialog.cpp e62ed6e src/plasma/framesvg.h dd6d8da src/plasma/framesvg.cpp fcc6809 src/plasma/private/framesvg_p.h 8aceef2 tests/dialog.qml PRE-CREATION tests/testborders.qml PRE-CREATION src/declarativeimports/core/framesvgitem.cpp 8320212 src/declarativeimports/core/framesvgitem.h e155f6a Diff: https://git.reviewboard.kde.org/r/119330/diff/ Testing --- Tested oxygen + breeze + some random (and ugly) themes from kde-look. Theme changes work. Everything looks the same; including the borders on oxygen. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119330: Convert FrameSvgItem to use 9 tiles instead of a big texture.
On July 21, 2014, 2:09 p.m., Marco Martin wrote: src/plasma/framesvg.h, line 290 https://git.reviewboard.kde.org/r/119330/diff/4/?file=291452#file291452line290 err, it's not really how I intended in the previous review.. adding public api is even worse... those 3 really don't give any extra information compared to what you can obtain with just the plain Svg api. Well, then we'll have the exact same function in FrameSvgItem and FrameSvg. I'm unsure this is any better. On July 21, 2014, 2:09 p.m., Marco Martin wrote: src/plasma/framesvg.cpp, line 834 https://git.reviewboard.kde.org/r/119330/diff/4/?file=291453#file291453line834 this doesn't use framesvg internal data at all, it doesn't really have to be in framesvg It doesn't use internal data, but FrameSvg uses it for painting the full frame. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/#review62788 --- On July 21, 2014, 1:51 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/ --- (Updated July 21, 2014, 1:51 p.m.) Review request for Plasma. Repository: plasma-framework Description --- Use FrameSVG as 9 tiles instead of uploading a big texture of the finished frame each time. This also saves the cache being populated with full created frames in different sizes; which end up taking up space in the disk and shared memory cache as well as the GPU memory. A code path falls back to the original uploading the entire texture if obscure settings are used, i.e overlay. Benchmarks: - apitrace when resizing a frame goes from an average of 7.6ms per frame of *CPU* time just for the swizzling and uploading to 1.4ms - GPU time also drops from 40us to 10us Themes will need to remove stretch-borders (when we gain nothing from stretching; i.e Breeze) to get the most out of it. Diffs - src/declarativeimports/core/svgitem.cpp 1ed0631 src/declarativeimports/core/tooltipdialog.cpp e62ed6e src/plasma/framesvg.h dd6d8da src/plasma/framesvg.cpp fcc6809 src/plasma/private/framesvg_p.h 8aceef2 tests/dialog.qml PRE-CREATION tests/testborders.qml PRE-CREATION src/declarativeimports/core/framesvgitem.cpp 8320212 src/declarativeimports/core/framesvgitem.h e155f6a Diff: https://git.reviewboard.kde.org/r/119330/diff/ Testing --- Tested oxygen + breeze + some random (and ugly) themes from kde-look. Theme changes work. Everything looks the same; including the borders on oxygen. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119330: Convert FrameSvgItem to use 9 tiles instead of a big texture.
On July 21, 2014, 2:09 p.m., Marco Martin wrote: It is possible to have neither private objects exported, neither public api added. Yes, it duplicates a bit of the implementation, but I rather prefer it a lot than either adding api or exporting private symbols. It's possible to do it without duplicating code, therefore we should do that. On July 21, 2014, 2:09 p.m., Marco Martin wrote: src/plasma/framesvg.h, line 290 https://git.reviewboard.kde.org/r/119330/diff/4/?file=291452#file291452line290 err, it's not really how I intended in the previous review.. adding public api is even worse... those 3 really don't give any extra information compared to what you can obtain with just the plain Svg api. Aleix Pol Gonzalez wrote: Well, then we'll have the exact same function in FrameSvgItem and FrameSvg. I'm unsure this is any better. If it's worse we can use the previous version of this patch. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/#review62788 --- On July 21, 2014, 1:51 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/ --- (Updated July 21, 2014, 1:51 p.m.) Review request for Plasma. Repository: plasma-framework Description --- Use FrameSVG as 9 tiles instead of uploading a big texture of the finished frame each time. This also saves the cache being populated with full created frames in different sizes; which end up taking up space in the disk and shared memory cache as well as the GPU memory. A code path falls back to the original uploading the entire texture if obscure settings are used, i.e overlay. Benchmarks: - apitrace when resizing a frame goes from an average of 7.6ms per frame of *CPU* time just for the swizzling and uploading to 1.4ms - GPU time also drops from 40us to 10us Themes will need to remove stretch-borders (when we gain nothing from stretching; i.e Breeze) to get the most out of it. Diffs - src/declarativeimports/core/svgitem.cpp 1ed0631 src/declarativeimports/core/tooltipdialog.cpp e62ed6e src/plasma/framesvg.h dd6d8da src/plasma/framesvg.cpp fcc6809 src/plasma/private/framesvg_p.h 8aceef2 tests/dialog.qml PRE-CREATION tests/testborders.qml PRE-CREATION src/declarativeimports/core/framesvgitem.cpp 8320212 src/declarativeimports/core/framesvgitem.h e155f6a Diff: https://git.reviewboard.kde.org/r/119330/diff/ Testing --- Tested oxygen + breeze + some random (and ugly) themes from kde-look. Theme changes work. Everything looks the same; including the borders on oxygen. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119330: Convert FrameSvgItem to use 9 tiles instead of a big texture.
On July 21, 2014, 2:09 p.m., Marco Martin wrote: src/plasma/framesvg.h, line 290 https://git.reviewboard.kde.org/r/119330/diff/4/?file=291452#file291452line290 err, it's not really how I intended in the previous review.. adding public api is even worse... those 3 really don't give any extra information compared to what you can obtain with just the plain Svg api. Aleix Pol Gonzalez wrote: Well, then we'll have the exact same function in FrameSvgItem and FrameSvg. I'm unsure this is any better. David Edmundson wrote: If it's worse we can use the previous version of this patch. yes, i know that having the same function in the two places is not particularly good. But between all the options I would really prefer it. I'm not excluding that a public api for the topology of the pieces may even be a good idea in the future, not sure. In the meantime, if they are well separed, even if means a bit of duplication of code, leaves more room for future modifications rather than a piece going public - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/#review62788 --- On July 21, 2014, 1:51 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/ --- (Updated July 21, 2014, 1:51 p.m.) Review request for Plasma. Repository: plasma-framework Description --- Use FrameSVG as 9 tiles instead of uploading a big texture of the finished frame each time. This also saves the cache being populated with full created frames in different sizes; which end up taking up space in the disk and shared memory cache as well as the GPU memory. A code path falls back to the original uploading the entire texture if obscure settings are used, i.e overlay. Benchmarks: - apitrace when resizing a frame goes from an average of 7.6ms per frame of *CPU* time just for the swizzling and uploading to 1.4ms - GPU time also drops from 40us to 10us Themes will need to remove stretch-borders (when we gain nothing from stretching; i.e Breeze) to get the most out of it. Diffs - src/declarativeimports/core/svgitem.cpp 1ed0631 src/declarativeimports/core/tooltipdialog.cpp e62ed6e src/plasma/framesvg.h dd6d8da src/plasma/framesvg.cpp fcc6809 src/plasma/private/framesvg_p.h 8aceef2 tests/dialog.qml PRE-CREATION tests/testborders.qml PRE-CREATION src/declarativeimports/core/framesvgitem.cpp 8320212 src/declarativeimports/core/framesvgitem.h e155f6a Diff: https://git.reviewboard.kde.org/r/119330/diff/ Testing --- Tested oxygen + breeze + some random (and ugly) themes from kde-look. Theme changes work. Everything looks the same; including the borders on oxygen. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Minutes Monday Plasma Hangout
I mentioned in the meeting that I was poking around in the Intel graphics driver with Aleix. That's now in a Qt bug report here: https://bugreports.qt-project.org/browse/QTBUG-40341 The short version of it is: Qt defaults to a loading an OpenGL context with comparability for a super super old version of OpenGL (from 2004). This compatibility layer uses /lots/ of memory. QtQuick2.0 won't even work on something that old (I think) so we may as well not request these old features. This saves us up to 15Mb per QtQuick application. I can set the surfaceFormats in PlasmaShell, but I'd rather get a proper fix into Qt on the defaults where we have more knowledgeable people than me making sure we don't break anything. David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
org.kde.notifications settings via qtscript
Hi, i was pointed here with my plasma/desktop configuration issue. I want to set a certain configuration item for the notifications via qtscript. I tried to access the systemtray widget and access from there the applet for org.kde.notifications. But this did not work. Any idea how to set configuration-parameters for org.kde.notification? I did read the PlasmaDesktopScripting Tutorial, but it didn't help. Thanks, Dennis ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Wayland plasnning meeting notes
2014-07-21 15:51 GMT+02:00 Aleix Pol aleix...@kde.org: On Mon, Jul 21, 2014 at 3:06 PM, Marco Martin notm...@gmail.com wrote: This is hopefully a synopsis of what has been said in the wayland planning meeting. Plasmashell relies heavily on KScreen that may pose a problem: it will need either to have KScreen supporting Wayland internally or to be ported again back to QScreen, needing QScreen to be fixed on both X11 and Wayland. Shadows should still have a protocol similar to now, to be painted by kwin and not by the window. In the same way output only windows should have a protocol for that instead of playing with masks, the general direction is to have protocols shell-kwin instead of windows working around problems. plfiorini says he may have a draft of the palsmashell-kwin protocol spec open for comment around middle of August. Regarding KScreen, it really should be ported, at the moment QScreen doesn't provide the information we need. I introduced one of the big missings for 5.4, which was screenRemoved, but we'll still need at least a primaryChanged signal. Aleix This task doesn't require KWin basics to be ready, could be done before so we have some work already done. -- Out of the box experience http://www.maui-project.org/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119330: Convert FrameSvgItem to use 9 tiles instead of a big texture.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/ --- (Updated July 21, 2014, 4:04 p.m.) Review request for Plasma. Changes --- Don't add members to public API, in a way that doesn't duplicate things either. Repository: plasma-framework Description --- Use FrameSVG as 9 tiles instead of uploading a big texture of the finished frame each time. This also saves the cache being populated with full created frames in different sizes; which end up taking up space in the disk and shared memory cache as well as the GPU memory. A code path falls back to the original uploading the entire texture if obscure settings are used, i.e overlay. Benchmarks: - apitrace when resizing a frame goes from an average of 7.6ms per frame of *CPU* time just for the swizzling and uploading to 1.4ms - GPU time also drops from 40us to 10us Themes will need to remove stretch-borders (when we gain nothing from stretching; i.e Breeze) to get the most out of it. Diffs (updated) - src/declarativeimports/core/framesvgitem.h e155f6a src/declarativeimports/core/framesvgitem.cpp 8320212 src/declarativeimports/core/svgitem.cpp 1ed0631 src/declarativeimports/core/tooltipdialog.cpp e62ed6e src/plasma/framesvg.h dd6d8da src/plasma/framesvg.cpp fcc6809 src/plasma/private/framesvg_helpers.h PRE-CREATION src/plasma/private/framesvg_p.h 8aceef2 tests/dialog.qml PRE-CREATION tests/testborders.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119330/diff/ Testing --- Tested oxygen + breeze + some random (and ugly) themes from kde-look. Theme changes work. Everything looks the same; including the borders on oxygen. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119330: Convert FrameSvgItem to use 9 tiles instead of a big texture.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/#review62799 --- Ship it! yes, that :p still an issue below I'm unsure of. src/plasma/framesvg.cpp https://git.reviewboard.kde.org/r/119330/#comment43549 are you sure about this one? doesn't contentGeometry returns the rectangle adjusted only by frame topHeight/RightHeight etc? the semantics of the function is supposed to return the rect adjust by visual margins for layout purposes (so the margin hints elements if present wins against the actual margin graphics, just like marginSize()). - Marco Martin On July 21, 2014, 4:04 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/ --- (Updated July 21, 2014, 4:04 p.m.) Review request for Plasma. Repository: plasma-framework Description --- Use FrameSVG as 9 tiles instead of uploading a big texture of the finished frame each time. This also saves the cache being populated with full created frames in different sizes; which end up taking up space in the disk and shared memory cache as well as the GPU memory. A code path falls back to the original uploading the entire texture if obscure settings are used, i.e overlay. Benchmarks: - apitrace when resizing a frame goes from an average of 7.6ms per frame of *CPU* time just for the swizzling and uploading to 1.4ms - GPU time also drops from 40us to 10us Themes will need to remove stretch-borders (when we gain nothing from stretching; i.e Breeze) to get the most out of it. Diffs - src/declarativeimports/core/framesvgitem.h e155f6a src/declarativeimports/core/framesvgitem.cpp 8320212 src/declarativeimports/core/svgitem.cpp 1ed0631 src/declarativeimports/core/tooltipdialog.cpp e62ed6e src/plasma/framesvg.h dd6d8da src/plasma/framesvg.cpp fcc6809 src/plasma/private/framesvg_helpers.h PRE-CREATION src/plasma/private/framesvg_p.h 8aceef2 tests/dialog.qml PRE-CREATION tests/testborders.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119330/diff/ Testing --- Tested oxygen + breeze + some random (and ugly) themes from kde-look. Theme changes work. Everything looks the same; including the borders on oxygen. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119330: Convert FrameSvgItem to use 9 tiles instead of a big texture.
On July 21, 2014, 4:26 p.m., Marco Martin wrote: src/plasma/framesvg.cpp, line 480 https://git.reviewboard.kde.org/r/119330/diff/5/?file=291470#file291470line480 are you sure about this one? doesn't contentGeometry returns the rectangle adjusted only by frame topHeight/RightHeight etc? the semantics of the function is supposed to return the rect adjust by visual margins for layout purposes (so the margin hints elements if present wins against the actual margin graphics, just like marginSize()). FrameSvgPrivate::contentGeometry takes them into account, because this one does use the values in FrameData. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/#review62799 --- On July 21, 2014, 4:04 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/ --- (Updated July 21, 2014, 4:04 p.m.) Review request for Plasma. Repository: plasma-framework Description --- Use FrameSVG as 9 tiles instead of uploading a big texture of the finished frame each time. This also saves the cache being populated with full created frames in different sizes; which end up taking up space in the disk and shared memory cache as well as the GPU memory. A code path falls back to the original uploading the entire texture if obscure settings are used, i.e overlay. Benchmarks: - apitrace when resizing a frame goes from an average of 7.6ms per frame of *CPU* time just for the swizzling and uploading to 1.4ms - GPU time also drops from 40us to 10us Themes will need to remove stretch-borders (when we gain nothing from stretching; i.e Breeze) to get the most out of it. Diffs - src/declarativeimports/core/framesvgitem.h e155f6a src/declarativeimports/core/framesvgitem.cpp 8320212 src/declarativeimports/core/svgitem.cpp 1ed0631 src/declarativeimports/core/tooltipdialog.cpp e62ed6e src/plasma/framesvg.h dd6d8da src/plasma/framesvg.cpp fcc6809 src/plasma/private/framesvg_helpers.h PRE-CREATION src/plasma/private/framesvg_p.h 8aceef2 tests/dialog.qml PRE-CREATION tests/testborders.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119330/diff/ Testing --- Tested oxygen + breeze + some random (and ugly) themes from kde-look. Theme changes work. Everything looks the same; including the borders on oxygen. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119330: Convert FrameSvgItem to use 9 tiles instead of a big texture.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/ --- (Updated July 21, 2014, 4:40 p.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-framework Description --- Use FrameSVG as 9 tiles instead of uploading a big texture of the finished frame each time. This also saves the cache being populated with full created frames in different sizes; which end up taking up space in the disk and shared memory cache as well as the GPU memory. A code path falls back to the original uploading the entire texture if obscure settings are used, i.e overlay. Benchmarks: - apitrace when resizing a frame goes from an average of 7.6ms per frame of *CPU* time just for the swizzling and uploading to 1.4ms - GPU time also drops from 40us to 10us Themes will need to remove stretch-borders (when we gain nothing from stretching; i.e Breeze) to get the most out of it. Diffs - src/declarativeimports/core/framesvgitem.h e155f6a src/declarativeimports/core/framesvgitem.cpp 8320212 src/declarativeimports/core/svgitem.cpp 1ed0631 src/declarativeimports/core/tooltipdialog.cpp e62ed6e src/plasma/framesvg.h dd6d8da src/plasma/framesvg.cpp fcc6809 src/plasma/private/framesvg_helpers.h PRE-CREATION src/plasma/private/framesvg_p.h 8aceef2 tests/dialog.qml PRE-CREATION tests/testborders.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119330/diff/ Testing --- Tested oxygen + breeze + some random (and ugly) themes from kde-look. Theme changes work. Everything looks the same; including the borders on oxygen. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119330: Convert FrameSvgItem to use 9 tiles instead of a big texture.
On July 21, 2014, 4:26 p.m., Marco Martin wrote: src/plasma/framesvg.cpp, line 480 https://git.reviewboard.kde.org/r/119330/diff/5/?file=291470#file291470line480 are you sure about this one? doesn't contentGeometry returns the rectangle adjusted only by frame topHeight/RightHeight etc? the semantics of the function is supposed to return the rect adjust by visual margins for layout purposes (so the margin hints elements if present wins against the actual margin graphics, just like marginSize()). Aleix Pol Gonzalez wrote: FrameSvgPrivate::contentGeometry takes them into account, because this one does use the values in FrameData. yeah, but I see from FrameData it's using frame-leftWidth, while in this case it should use frame-leftMargin (leftMargin being the same of leftWidth if there is no hint, the size of the hint instead) - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/#review62799 --- On July 21, 2014, 4:40 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/ --- (Updated July 21, 2014, 4:40 p.m.) Review request for Plasma. Repository: plasma-framework Description --- Use FrameSVG as 9 tiles instead of uploading a big texture of the finished frame each time. This also saves the cache being populated with full created frames in different sizes; which end up taking up space in the disk and shared memory cache as well as the GPU memory. A code path falls back to the original uploading the entire texture if obscure settings are used, i.e overlay. Benchmarks: - apitrace when resizing a frame goes from an average of 7.6ms per frame of *CPU* time just for the swizzling and uploading to 1.4ms - GPU time also drops from 40us to 10us Themes will need to remove stretch-borders (when we gain nothing from stretching; i.e Breeze) to get the most out of it. Diffs - src/declarativeimports/core/framesvgitem.h e155f6a src/declarativeimports/core/framesvgitem.cpp 8320212 src/declarativeimports/core/svgitem.cpp 1ed0631 src/declarativeimports/core/tooltipdialog.cpp e62ed6e src/plasma/framesvg.h dd6d8da src/plasma/framesvg.cpp fcc6809 src/plasma/private/framesvg_helpers.h PRE-CREATION src/plasma/private/framesvg_p.h 8aceef2 tests/dialog.qml PRE-CREATION tests/testborders.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119330/diff/ Testing --- Tested oxygen + breeze + some random (and ugly) themes from kde-look. Theme changes work. Everything looks the same; including the borders on oxygen. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118180: slideshow BUG patch fix
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118180/#review62810 --- seems the patch doesn't apply anymore, at least reviewboard complains about it - Marco Martin On Lug. 21, 2014, 1:12 p.m., TOM Harrison wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118180/ --- (Updated Lug. 21, 2014, 1:12 p.m.) Review request for kde-workspace and Plasma. Bugs: 327580 http://bugs.kde.org/show_bug.cgi?id=327580 Repository: kde-workspace Description --- bug patch for slideshow dir list missing Diffs - libs/plasmagenericshell/backgrounddialog.cpp 645de3f Diff: https://git.reviewboard.kde.org/r/118180/diff/ Testing --- Thanks, TOM Harrison ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119330: Convert FrameSvgItem to use 9 tiles instead of a big texture.
On July 21, 2014, 4:26 p.m., Marco Martin wrote: src/plasma/framesvg.cpp, line 480 https://git.reviewboard.kde.org/r/119330/diff/5/?file=291470#file291470line480 are you sure about this one? doesn't contentGeometry returns the rectangle adjusted only by frame topHeight/RightHeight etc? the semantics of the function is supposed to return the rect adjust by visual margins for layout purposes (so the margin hints elements if present wins against the actual margin graphics, just like marginSize()). Aleix Pol Gonzalez wrote: FrameSvgPrivate::contentGeometry takes them into account, because this one does use the values in FrameData. Marco Martin wrote: yeah, but I see from FrameData it's using frame-leftWidth, while in this case it should use frame-leftMargin (leftMargin being the same of leftWidth if there is no hint, the size of the hint instead) Can you create a small test where I can reproduce the issue? - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/#review62799 --- On July 21, 2014, 4:40 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/ --- (Updated July 21, 2014, 4:40 p.m.) Review request for Plasma. Repository: plasma-framework Description --- Use FrameSVG as 9 tiles instead of uploading a big texture of the finished frame each time. This also saves the cache being populated with full created frames in different sizes; which end up taking up space in the disk and shared memory cache as well as the GPU memory. A code path falls back to the original uploading the entire texture if obscure settings are used, i.e overlay. Benchmarks: - apitrace when resizing a frame goes from an average of 7.6ms per frame of *CPU* time just for the swizzling and uploading to 1.4ms - GPU time also drops from 40us to 10us Themes will need to remove stretch-borders (when we gain nothing from stretching; i.e Breeze) to get the most out of it. Diffs - src/declarativeimports/core/framesvgitem.h e155f6a src/declarativeimports/core/framesvgitem.cpp 8320212 src/declarativeimports/core/svgitem.cpp 1ed0631 src/declarativeimports/core/tooltipdialog.cpp e62ed6e src/plasma/framesvg.h dd6d8da src/plasma/framesvg.cpp fcc6809 src/plasma/private/framesvg_helpers.h PRE-CREATION src/plasma/private/framesvg_p.h 8aceef2 tests/dialog.qml PRE-CREATION tests/testborders.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119330/diff/ Testing --- Tested oxygen + breeze + some random (and ugly) themes from kde-look. Theme changes work. Everything looks the same; including the borders on oxygen. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119330: Convert FrameSvgItem to use 9 tiles instead of a big texture.
On July 21, 2014, 4:26 p.m., Marco Martin wrote: src/plasma/framesvg.cpp, line 480 https://git.reviewboard.kde.org/r/119330/diff/5/?file=291470#file291470line480 are you sure about this one? doesn't contentGeometry returns the rectangle adjusted only by frame topHeight/RightHeight etc? the semantics of the function is supposed to return the rect adjust by visual margins for layout purposes (so the margin hints elements if present wins against the actual margin graphics, just like marginSize()). Aleix Pol Gonzalez wrote: FrameSvgPrivate::contentGeometry takes them into account, because this one does use the values in FrameData. Marco Martin wrote: yeah, but I see from FrameData it's using frame-leftWidth, while in this case it should use frame-leftMargin (leftMargin being the same of leftWidth if there is no hint, the size of the hint instead) Aleix Pol Gonzalez wrote: Can you create a small test where I can reproduce the issue? I think for at least measures should be possible to do an autotest.. I'll give it a try - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/#review62799 --- On July 21, 2014, 4:40 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/ --- (Updated July 21, 2014, 4:40 p.m.) Review request for Plasma. Repository: plasma-framework Description --- Use FrameSVG as 9 tiles instead of uploading a big texture of the finished frame each time. This also saves the cache being populated with full created frames in different sizes; which end up taking up space in the disk and shared memory cache as well as the GPU memory. A code path falls back to the original uploading the entire texture if obscure settings are used, i.e overlay. Benchmarks: - apitrace when resizing a frame goes from an average of 7.6ms per frame of *CPU* time just for the swizzling and uploading to 1.4ms - GPU time also drops from 40us to 10us Themes will need to remove stretch-borders (when we gain nothing from stretching; i.e Breeze) to get the most out of it. Diffs - src/declarativeimports/core/framesvgitem.h e155f6a src/declarativeimports/core/framesvgitem.cpp 8320212 src/declarativeimports/core/svgitem.cpp 1ed0631 src/declarativeimports/core/tooltipdialog.cpp e62ed6e src/plasma/framesvg.h dd6d8da src/plasma/framesvg.cpp fcc6809 src/plasma/private/framesvg_helpers.h PRE-CREATION src/plasma/private/framesvg_p.h 8aceef2 tests/dialog.qml PRE-CREATION tests/testborders.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119330/diff/ Testing --- Tested oxygen + breeze + some random (and ugly) themes from kde-look. Theme changes work. Everything looks the same; including the borders on oxygen. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Review Request 119330: Convert FrameSvgItem to use 9 tiles instead of a big texture.
On Monday 21 July 2014 16:40:48 David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/ --- (Updated July 21, 2014, 4:40 p.m.) Status -- This change has been marked as submitted. congrats! And thanks to everyone involved to be patient about it. Cheers Martin 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
Re: Review Request 119330: Convert FrameSvgItem to use 9 tiles instead of a big texture.
On July 21, 2014, 4:26 p.m., Marco Martin wrote: src/plasma/framesvg.cpp, line 480 https://git.reviewboard.kde.org/r/119330/diff/5/?file=291470#file291470line480 are you sure about this one? doesn't contentGeometry returns the rectangle adjusted only by frame topHeight/RightHeight etc? the semantics of the function is supposed to return the rect adjust by visual margins for layout purposes (so the margin hints elements if present wins against the actual margin graphics, just like marginSize()). Aleix Pol Gonzalez wrote: FrameSvgPrivate::contentGeometry takes them into account, because this one does use the values in FrameData. Marco Martin wrote: yeah, but I see from FrameData it's using frame-leftWidth, while in this case it should use frame-leftMargin (leftMargin being the same of leftWidth if there is no hint, the size of the hint instead) Aleix Pol Gonzalez wrote: Can you create a small test where I can reproduce the issue? Marco Martin wrote: I think for at least measures should be possible to do an autotest.. I'll give it a try Here you go, in master there is an autotest that fails(QEXPECT_FAIL) comparing contentsRect - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/#review62799 --- On July 21, 2014, 4:40 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119330/ --- (Updated July 21, 2014, 4:40 p.m.) Review request for Plasma. Repository: plasma-framework Description --- Use FrameSVG as 9 tiles instead of uploading a big texture of the finished frame each time. This also saves the cache being populated with full created frames in different sizes; which end up taking up space in the disk and shared memory cache as well as the GPU memory. A code path falls back to the original uploading the entire texture if obscure settings are used, i.e overlay. Benchmarks: - apitrace when resizing a frame goes from an average of 7.6ms per frame of *CPU* time just for the swizzling and uploading to 1.4ms - GPU time also drops from 40us to 10us Themes will need to remove stretch-borders (when we gain nothing from stretching; i.e Breeze) to get the most out of it. Diffs - src/declarativeimports/core/framesvgitem.h e155f6a src/declarativeimports/core/framesvgitem.cpp 8320212 src/declarativeimports/core/svgitem.cpp 1ed0631 src/declarativeimports/core/tooltipdialog.cpp e62ed6e src/plasma/framesvg.h dd6d8da src/plasma/framesvg.cpp fcc6809 src/plasma/private/framesvg_helpers.h PRE-CREATION src/plasma/private/framesvg_p.h 8aceef2 tests/dialog.qml PRE-CREATION tests/testborders.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119330/diff/ Testing --- Tested oxygen + breeze + some random (and ugly) themes from kde-look. Theme changes work. Everything looks the same; including the borders on oxygen. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 4.x transition blockage - workspace libs
On 07/18/2014 06:54 PM, Harald Sitter wrote: On Thu, Jul 17, 2014 at 1:37 PM, Michael Palimaka kensing...@gentoo.org wrote: I just discused this with mgraesslin on IRC and he's fine with adding a compatibility build flag to 4.x that makes it only install the necessary libraries to avoid file conflicts with plasma-workspace 5. Does that sounds suitable for gentoo and if so, do you guys want to come up with a patch? :) I'm very interested in this, but what did you have in mind - a collision is a collision, right? As far as I can tell the colliding bits are: a) certain binaries/data/nonesense b) all libfoo.so files c) the include directories (assuming neither plasma5 nor kde-workspace were put in an explicit subdir) So, to get the first collision out of the way kde-workspace needs a flag to not build or install those bits (i.e. build in a library compatibility mode). The latter two could be addressed by renaming the libraries in plasma5 to libkworkspace5.so etc. and respective include directory names. What I am not sure about here is whether there are more suitable distro-level solutions to this. Surely libfoo.so (libfoo.so.0) and libfoo.so (libfoo.so.1) conflicting cannot be a new issue, so I do wonder how this would be resolved in general. HS I'm very interested in renaming libkworkspace in Plasma5 at a minimum. What do you suggest for the include directory - just kworkspace - kworkspace5 or go further and make the whole thing KF5Workspace? I'm happy to provide patches, but didn't so far since there was resistance to the idea last time it was brought up. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: 4.x transition blockage - workspace libs
On Tuesday 22 July 2014 05:28:36 Michael Palimaka wrote: On 07/18/2014 06:54 PM, Harald Sitter wrote: On Thu, Jul 17, 2014 at 1:37 PM, Michael Palimaka kensing...@gentoo.org wrote: I just discused this with mgraesslin on IRC and he's fine with adding a compatibility build flag to 4.x that makes it only install the necessary libraries to avoid file conflicts with plasma-workspace 5. Does that sounds suitable for gentoo and if so, do you guys want to come up with a patch? :) I'm very interested in this, but what did you have in mind - a collision is a collision, right? As far as I can tell the colliding bits are: a) certain binaries/data/nonesense b) all libfoo.so files c) the include directories (assuming neither plasma5 nor kde-workspace were put in an explicit subdir) So, to get the first collision out of the way kde-workspace needs a flag to not build or install those bits (i.e. build in a library compatibility mode). The latter two could be addressed by renaming the libraries in plasma5 to libkworkspace5.so etc. and respective include directory names. What I am not sure about here is whether there are more suitable distro-level solutions to this. Surely libfoo.so (libfoo.so.0) and libfoo.so (libfoo.so.1) conflicting cannot be a new issue, so I do wonder how this would be resolved in general. HS I'm very interested in renaming libkworkspace in Plasma5 at a minimum. What do you suggest for the include directory - just kworkspace - kworkspace5 or go further and make the whole thing KF5Workspace? I'm happy to provide patches, but didn't so far since there was resistance to the idea last time it was brought up. Personally I'm very reluctant to the idea of changing the includes. The risk of us having to hunt down breakage for weeks is IMHO way too high for the possible benefits. We just had it too often during the frameworks transition that a header file got renamed, missed in one place and it starts to randomly break to compile on some systems because a kde4 header is picked. Then we easily waste huge amounts of work power on people trying to fix their build. That's also the reason why I decided against renaming the headers for KWin. Just my humble opinion. Cheers Martin 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
Re: Review Request 119352: missing fclose - Resource leaking
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119352/ --- (Updated July 21, 2014, 11:09 p.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-workspace Description --- config resource already opened but forgotten to close Diffs - startkde/kstartupconfig/kstartupconfig.cpp f0b902a Diff: https://git.reviewboard.kde.org/r/119352/diff/ Testing --- Thanks, Ömer Fadıl Usta ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
