Re: Review Request 118886: Add paintedWidth and paintedHeight properties to WindowThumbnail
On June 22, 2014, 11:29 p.m., David Edmundson wrote: src/declarativeimports/core/windowthumbnail.h, line 93 https://git.reviewboard.kde.org/r/118886/diff/1/?file=283725#file283725line93 I would just have the one signal, paintedSizeChanged. Otherwise we potentially end up re-evaluating loads of bindings twice. (Qt does this for the Text item) Kai Uwe Broulik wrote: I can have the same changed signal for multiple properties? yes - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118886/#review60735 --- On June 22, 2014, 9:54 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118886/ --- (Updated June 22, 2014, 9:54 p.m.) Review request for Plasma and Martin Gräßlin. Repository: plasma-framework Description --- This adds paintedWidth and paintedHeight properties to PlasmaCore.WindowThumbnail which tells as how large the thumbnail, which is scaled keeping aspect ratio, actually is, similar to what QML Image does. This is will eventually allow the taskmanager to size its tooltips more appropriately. (Is it better to store m_paintedWidth and m_paintedHeight separately, or is the QSize thing I used ok?) Diffs - src/declarativeimports/core/windowthumbnail.h 14fc44a src/declarativeimports/core/windowthumbnail.cpp b10f030 Diff: https://git.reviewboard.kde.org/r/118886/diff/ Testing --- Works, reports the actual size Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118812: [plasmashell] Show a warning if there are no Shaders and exit
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118812/#review60745 --- This review has been submitted with commit 0a040bc49837e49f9cd4a1780ac926156f1430d6 by Martin Gräßlin to branch master. - Commit Hook On June 18, 2014, 1:27 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118812/ --- (Updated June 18, 2014, 1:27 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- [plasmashell] Show a warning if there are no Shaders and exit If there are no Shaders Plasma doesn't work. If we detect this we show a warning (without GL) and exit. This doesn't really work as Qt has a bug which doesn't allow to detect whether Shaders are supported and the exit just doesn't work. Diffs - shell/shellcorona.h f500e837b5957e14e70ac4b24da0cdf7970a7171 shell/shellcorona.cpp 4abe3432f30a8c4eb90806893f15c7c50f0e1ac2 Diff: https://git.reviewboard.kde.org/r/118812/diff/ Testing --- With Mesa drivers: LIBGL_ALWAYS_INDIRECT=1 plasmashell Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118812: [plasmashell] Show a warning if there are no Shaders and exit
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118812/ --- (Updated June 23, 2014, 6:11 a.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-workspace Description --- [plasmashell] Show a warning if there are no Shaders and exit If there are no Shaders Plasma doesn't work. If we detect this we show a warning (without GL) and exit. This doesn't really work as Qt has a bug which doesn't allow to detect whether Shaders are supported and the exit just doesn't work. Diffs - shell/shellcorona.h f500e837b5957e14e70ac4b24da0cdf7970a7171 shell/shellcorona.cpp 4abe3432f30a8c4eb90806893f15c7c50f0e1ac2 Diff: https://git.reviewboard.kde.org/r/118812/diff/ Testing --- With Mesa drivers: LIBGL_ALWAYS_INDIRECT=1 plasmashell Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118695: Don't set -DHAVE_X11 through target properties
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118695/#review60750 --- This review has been submitted with commit ca9be41cb8d4f459f9a31c92c1cc200b34e94f8e by Martin Gräßlin to branch master. - Commit Hook On June 12, 2014, 11:46 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118695/ --- (Updated June 12, 2014, 11:46 a.m.) Review request for Plasma. Repository: plasma-desktop Description --- Don't set -DHAVE_X11 through target properties Include config-X11.h instead. Diffs - kcms/colors/CMakeLists.txt 8f75d1dcee6f23c5c8378884a20befdc1139ea97 kcms/fonts/CMakeLists.txt b4c237c8fd9a2acd89b1755b62dbadfafa239302 kcms/fonts/fonts.cpp e57d745996925790123e716e47674c34801e02e0 kcms/input/CMakeLists.txt 0baed093d2996a61ab8b02570ae072753368a697 kcms/krdb/krdb.cpp cddfe24d0eed9d5e031b36b68a949601fc564131 kcms/style/CMakeLists.txt 423241b8127491853d8afa75bb8b5d78c9009dca Diff: https://git.reviewboard.kde.org/r/118695/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118695: Don't set -DHAVE_X11 through target properties
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118695/ --- (Updated June 23, 2014, 6:33 a.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-desktop Description --- Don't set -DHAVE_X11 through target properties Include config-X11.h instead. Diffs - kcms/colors/CMakeLists.txt 8f75d1dcee6f23c5c8378884a20befdc1139ea97 kcms/fonts/CMakeLists.txt b4c237c8fd9a2acd89b1755b62dbadfafa239302 kcms/fonts/fonts.cpp e57d745996925790123e716e47674c34801e02e0 kcms/input/CMakeLists.txt 0baed093d2996a61ab8b02570ae072753368a697 kcms/krdb/krdb.cpp cddfe24d0eed9d5e031b36b68a949601fc564131 kcms/style/CMakeLists.txt 423241b8127491853d8afa75bb8b5d78c9009dca Diff: https://git.reviewboard.kde.org/r/118695/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118637: [klipper] Port from XLib to XCB
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118637/#review60751 --- This review has been submitted with commit 951af7b491d3ad02d64031870b7bb8da1d69a18d by Martin Gräßlin to branch master. - Commit Hook On June 10, 2014, 1:40 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118637/ --- (Updated June 10, 2014, 1:40 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- [klipper] Port from XLib to XCB This ports the workarounds using query pointer from XLib to XCB. At the same time the build system is adjusted to only link against XCB and Qt5::X11Extras if we are building for X11 and the define is taken from config-X11.h instead of setting a define through CMakeLists.txt. [klipper] Update apptime only on platform X11 [klipper] Use KWindowSystem for URLGrabber::isAvoidedWindow() It had custom (and incorrect) code for reading the window class of the active window. That's provided by KWindowSystem in a better way without the need of having windowing system dependent code. Diffs - klipper/CMakeLists.txt 999be53c5332048c90b98cbbd9b23fad72be2a4b klipper/klipper.cpp 5e60a5ab0a31567545876888309b287ac9b4be35 klipper/urlgrabber.cpp 61425e0f88731575699429a5263b1306269d5ae1 Diff: https://git.reviewboard.kde.org/r/118637/diff/ Testing --- * URL copied with actions enabled for normal window and browser * selected word without lmb * not tested: the OOo test case. Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118637: [klipper] Port from XLib to XCB
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118637/ --- (Updated June 23, 2014, 6:35 a.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-workspace Description --- [klipper] Port from XLib to XCB This ports the workarounds using query pointer from XLib to XCB. At the same time the build system is adjusted to only link against XCB and Qt5::X11Extras if we are building for X11 and the define is taken from config-X11.h instead of setting a define through CMakeLists.txt. [klipper] Update apptime only on platform X11 [klipper] Use KWindowSystem for URLGrabber::isAvoidedWindow() It had custom (and incorrect) code for reading the window class of the active window. That's provided by KWindowSystem in a better way without the need of having windowing system dependent code. Diffs - klipper/CMakeLists.txt 999be53c5332048c90b98cbbd9b23fad72be2a4b klipper/klipper.cpp 5e60a5ab0a31567545876888309b287ac9b4be35 klipper/urlgrabber.cpp 61425e0f88731575699429a5263b1306269d5ae1 Diff: https://git.reviewboard.kde.org/r/118637/diff/ Testing --- * URL copied with actions enabled for normal window and browser * selected word without lmb * not tested: the OOo test case. Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Background for login, splash, and lockscreen
Ok so I have to ask (because my mum once told me as a child, slow people ask a lot of questions - but only complete idiots don't) :) Place be nice. Wouldn't it be possible to have the wallpaper picker pick the login wallpaper as well? I mean say I choose a wallpaper with a photo of a dog or something - can't the wallpaper picker, blur it with gaussian blur at the time of picking, saving it in a special folder and at the same time deleting the past blurred wallpaper? So that when you log in you have your current wallpaper, blured as background? /Jens On Sunday 22 June 2014 20.57.11 Martin Graesslin wrote: On Saturday 21 June 2014 16:18:10 Kai Uwe Broulik wrote: Can't we just use QtGraphicalEffects and just blur (and/or desaturate and/or darken) whatever picture the user has chosen? The overall performance of these is great (at least on Android which is slow in any other QtQuick respect) but their instantiation takes ages, so might not be suitable for lockscreen which needs to start quickly or splash which shouldn't unnecessarily delay startup. So, umm, while writing this I figured it's not that good of an idea as I initially thought :-) so you suggest that on millions of devices we blur the window fullscreen every time the user logs in (lots of more important stuff to do) and locks the screen? Compared to preparing it once and just installing it? That sounds like a very bad memory-time tradeoff [1]. Cheers Martin [1] https://en.wikipedia.org/wiki/Time-memory_tradeoff ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Background for login, splash, and lockscreen
(Im really really tired - please let me rephrase) Ok so you have the default blurred wallpaper for the login, based on the default wallpaper. But then you pick a new wallpaper, and instead of having it get blurred during login (which would make it really heavy and annoying) the wallpaper picker blurs at the time of choosing, saving it (and the default one) in some folder to be used as background for the login. When you pick a new wallpaper the picker deletes the current one and replaces it with the blurred image of your current choice. The PNG of the blurred wallpaper can even be smaller in resolution (to save on space I guess) since, using gaussian blur removes all detail anyway and the resolution becomes almost meaningless. (Granted I know close to nothing about the subject - just wondering why that wouldn't work) On Monday 23 June 2014 08.42.27 Jens Reuterberg wrote: Ok so I have to ask (because my mum once told me as a child, slow people ask a lot of questions - but only complete idiots don't) :) Place be nice. Wouldn't it be possible to have the wallpaper picker pick the login wallpaper as well? I mean say I choose a wallpaper with a photo of a dog or something - can't the wallpaper picker, blur it with gaussian blur at the time of picking, saving it in a special folder and at the same time deleting the past blurred wallpaper? So that when you log in you have your current wallpaper, blured as background? /Jens On Sunday 22 June 2014 20.57.11 Martin Graesslin wrote: On Saturday 21 June 2014 16:18:10 Kai Uwe Broulik wrote: Can't we just use QtGraphicalEffects and just blur (and/or desaturate and/or darken) whatever picture the user has chosen? The overall performance of these is great (at least on Android which is slow in any other QtQuick respect) but their instantiation takes ages, so might not be suitable for lockscreen which needs to start quickly or splash which shouldn't unnecessarily delay startup. So, umm, while writing this I figured it's not that good of an idea as I initially thought :-) so you suggest that on millions of devices we blur the window fullscreen every time the user logs in (lots of more important stuff to do) and locks the screen? Compared to preparing it once and just installing it? That sounds like a very bad memory-time tradeoff [1]. Cheers Martin [1] https://en.wikipedia.org/wiki/Time-memory_tradeoff ___ 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: Re: Background for login, splash, and lockscreen
On Monday 23 June 2014 08:49:21 Jens Reuterberg wrote: (Im really really tired - please let me rephrase) Ok so you have the default blurred wallpaper for the login, based on the default wallpaper. But then you pick a new wallpaper, and instead of having it get blurred during login (which would make it really heavy and annoying) the wallpaper picker blurs at the time of choosing, saving it (and the default one) in some folder to be used as background for the login. When you pick a new wallpaper the picker deletes the current one and replaces it with the blurred image of your current choice. The PNG of the blurred wallpaper can even be smaller in resolution (to save on space I guess) since, using gaussian blur removes all detail anyway and the resolution becomes almost meaningless. Yes that would work and would be a good solution. There are just a few technical issues with getting the wallpaper to the lock screen, thus it's not something we can do for 5.0. 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
Review Request 118896: Fix 2 data races in runnercontext, mention another one.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118896/ --- Review request for Plasma and Aaron J. Seigo. Repository: kdelibs Description --- Fix 2 data races in runnercontext, mention another one. Found by helgrinding krunner. Turns out helgrind lacks support for QReadWriteLock, but reading the code still made me found these. Diffs - plasma/private/runnerjobs.cpp 6a8a7710f95adba38cc56c2d59393bfa3b123185 plasma/runnercontext.cpp abd6a4bc7fca2a0d05f27c6601b658ff552307b3 Diff: https://git.reviewboard.kde.org/r/118896/diff/ Testing --- Typing various things into krunner. The main crash is still there though: baloo or xapian isn't reentrant; but that's separate. Thanks, David Faure ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[kdeplasma-addons/KDE/4.13] applets/fuzzy-clock: initialize m_configUpdated
Git commit 6b1736447555e3242b97aca2e7d6ab542a482ea8 by Andre Woebbeking. Committed on 22/06/2014 at 12:58. Pushed by woebbe into branch 'KDE/4.13'. initialize m_configUpdated CCMAIL:plasma-devel@kde.org Could anyone please merge this in master or frameworks? M +1-0applets/fuzzy-clock/fuzzyClock.cpp http://commits.kde.org/kdeplasma-addons/6b1736447555e3242b97aca2e7d6ab542a482ea8 diff --git a/applets/fuzzy-clock/fuzzyClock.cpp b/applets/fuzzy-clock/fuzzyClock.cpp index 2cd189d..06afdc3 100644 --- a/applets/fuzzy-clock/fuzzyClock.cpp +++ b/applets/fuzzy-clock/fuzzyClock.cpp @@ -37,6 +37,7 @@ Clock::Clock(QObject *parent, const QVariantList args) m_oldContentSize(QSizeF (0,0)), m_adjustToHeight(1), m_useCustomFontColor(false), + m_configUpdated(false), m_fontColor(Qt::white), m_fontTimeBold(false), m_fontTimeItalic(false), ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Background for login, splash, and lockscreen
blurred wallpaper can even be smaller in resolution (to save on space I guess) since, using gaussian blur removes all detail anyway and the resolution becomes almost meaningless. Yes that would work and would be a good solution. There The question is *which* wallpaper. From which activity / or which virtual desktop. I would love to see this implemented, but it will not be as trivial as this. We might tell plasma to symlink the last shown wallpaper to a predefined location (analogous to .face.icon) or something. Blurring would be problematic for that case. Cheerio, Ivan KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/ gpg key id: 850B6F76, keyserver.pgp.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Background for login, splash, and lockscreen
On 23.06.2014 10:16, Ivan Čukić wrote: blurred wallpaper can even be smaller in resolution (to save on space I guess) since, using gaussian blur removes all detail anyway and the resolution becomes almost meaningless. Yes that would work and would be a good solution. There The question is *which* wallpaper. From which activity / or which virtual desktop. I would love to see this implemented, but it will not be as trivial as this. How about when selecting a wallpaper for anything, users can tick a checkbox Use this wallpaper for login, which then blurs and symlinks it? Con: There would not be a smooth transition if a different wallpaper is shown after login Pro: The user would be in control ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Background for login, splash, and lockscreen
On Monday 23 June 2014 10:26:26 Thomas Pfeiffer wrote: On 23.06.2014 10:16, Ivan Čukić wrote: blurred wallpaper can even be smaller in resolution (to save on space I guess) since, using gaussian blur removes all detail anyway and the resolution becomes almost meaningless. Yes that would work and would be a good solution. There The question is *which* wallpaper. From which activity / or which virtual desktop. I would love to see this implemented, but it will not be as trivial as this. How about when selecting a wallpaper for anything, users can tick a checkbox Use this wallpaper for login, which then blurs and symlinks it? Con: There would not be a smooth transition if a different wallpaper is shown after login Pro: The user would be in control How about we implement proper configuration for the login screen including support for animated wallpapers (screen saver replacement), plasmoids and so on? That way we don't need to link anything from the desktop shell to the lock screen. 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: Background for login, splash, and lockscreen
Right... Ok so if I pick a wallpaper for my start activity that wallpaper should be the wallpaper used. If a user on the other hand have created several activities with different set-ups and deleted the first activity then the last wallpaper edited should be the wallpaper used and the user can in that way control which it is. OR we can do what gnome does, essentially set it up as its own wallpaper picker. You pick one for login and then one for wallpaper. But that seems kinda redundant. I think adding things to the wallpaper picked might be counterproductive since adding options isn't really adding to usability, just complexity. Now I don't know how hard proper configuration for the login screen including support for animated wallpapers is to implement and make so it doesn't add to boot-up time, I just assumed that if it was easy it had already been done. ... and if it isn't wouldn't this serve as a better option? I mean if it doesn't add on boot-up time, if it isn't a massive project to create and it solves the issue wouldn't the method be better to have now instead of hoping for the the perfect solution in the future? (Again, to have that said, I know close to zero about this issue - so please take whatever that plops out of my mouth with a pinch and a bucket full of salt. I just thought it made sense in my brain - which may not be true in reality) On Monday 23 June 2014 10.29.41 Martin Gräßlin wrote: On Monday 23 June 2014 10:26:26 Thomas Pfeiffer wrote: On 23.06.2014 10:16, Ivan Čukić wrote: blurred wallpaper can even be smaller in resolution (to save on space I guess) since, using gaussian blur removes all detail anyway and the resolution becomes almost meaningless. Yes that would work and would be a good solution. There The question is *which* wallpaper. From which activity / or which virtual desktop. I would love to see this implemented, but it will not be as trivial as this. How about when selecting a wallpaper for anything, users can tick a checkbox Use this wallpaper for login, which then blurs and symlinks it? Con: There would not be a smooth transition if a different wallpaper is shown after login Pro: The user would be in control How about we implement proper configuration for the login screen including support for animated wallpapers (screen saver replacement), plasmoids and so on? That way we don't need to link anything from the desktop shell to the lock screen. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Background for login, splash, and lockscreen
On Monday 23 June 2014, Ivan Čukić wrote: blurred wallpaper can even be smaller in resolution (to save on space I guess) since, using gaussian blur removes all detail anyway and the resolution becomes almost meaningless. Yes that would work and would be a good solution. There The question is *which* wallpaper. From which activity / or which virtual desktop. I would love to see this implemented, but it will not be as trivial as this. * and in case of the bootsplash/login manager, which user -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Background for login, splash, and lockscreen
Well the user selected? Oh wouldn't that be cool!? Ok so say me and Andrew and you (Marco) share a computer (against all geographical difficulties) when I select my user the wallpaper I picked would be displayed with my photo. When we select YOUR user your wallpaper get displayed as background instead... I mean if someone HAVEN'T picked one its the standard, default, wallpaper. If you have several activities - then the first default one OR the last one picked. Which would mean 1 wallpaper per user, per activity plus the default one though... On Monday 23 June 2014 10.50.23 Marco Martin wrote: On Monday 23 June 2014, Ivan Čukić wrote: blurred wallpaper can even be smaller in resolution (to save on space I guess) since, using gaussian blur removes all detail anyway and the resolution becomes almost meaningless. Yes that would work and would be a good solution. There The question is *which* wallpaper. From which activity / or which virtual desktop. I would love to see this implemented, but it will not be as trivial as this. * and in case of the bootsplash/login manager, which user ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118891: Folder view icon text background
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118891/#review60755 --- I'm basically willing to follow the VDG's lead here in the end, although I think this approach has some problems: - It's a fairly heavy deco for the containment case, which does make it feel a lot like a selection deco. This is reinforced by the fact that other file item delegates in the system (Dolphin, KFileDialog) behave similarly on selection. - I can't quite make my mind up on whether it's a good thing or a bad thing that the deco on narrow single-line text items extends over the entire line width instead of bounding to the text. It's different from Dolphin/KFileDialog behavior, though. containments/folder/package/contents/ui/ItemDelegate.qml https://git.reviewboard.kde.org/r/118891/#comment42354 Are you sure you wanted to hard-code pixel values here instead of using hidpi scaling-aware margins? units.smallSpacing is effectively 2px right now at 'standard DPI'. containments/folder/package/contents/ui/ItemDelegate.qml https://git.reviewboard.kde.org/r/118891/#comment42355 This causes a subtle brightly-colored rectangle in popups from the containment Folder View and in the widget case which I think looks fairly awkward to me. The dialog and widget backgrounds are designed to host theme.textColor already contrast-wise, so I think it'd be better to just not show this rectangle there. - Eike Hein On June 23, 2014, 12:41 a.m., Andrew Lake wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118891/ --- (Updated June 23, 2014, 12:41 a.m.) Review request for Plasma. Bugs: 335070 https://bugs.kde.org/show_bug.cgi?id=335070 Repository: plasma-desktop Description --- Addresses lack of contrast of folderview containment icon text on certain backgrounds: Bug 335070 The color of the text background is just the complement of the icon label text with a 0.6 opacity applied. Diffs - containments/folder/package/contents/ui/ConfigIcons.qml 9f57900 containments/folder/package/contents/ui/ItemDelegate.qml 4f95f04 Diff: https://git.reviewboard.kde.org/r/118891/diff/ Testing --- File Attachments Icon text background https://git.reviewboard.kde.org/media/uploaded/files/2014/06/23/421aaadc-1b16-4d80-8929-694ac9b669b5__icontextbackground1.png Thanks, Andrew Lake ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Background for login, splash, and lockscreen
On Monday 23 June 2014 10:55:07 Jens wrote: Well the user selected? Oh wouldn't that be cool!? no it wouldn't because of privacy and security. A wallpaper can both expose very private information one wouldn't want on the login screen (think of picture of naked girlfriend category) and is also security relevant. In fact it might not be possible to get the information at all as the home partition might be encrypted. There are things which call for a default wallpaper. The login screen is one of them :-) 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: Background for login, splash, and lockscreen
On Monday 23 June 2014, Martin Gräßlin wrote: On Monday 23 June 2014 10:55:07 Jens wrote: Well the user selected? Oh wouldn't that be cool!? no it wouldn't because of privacy and security. A wallpaper can both expose very private information one wouldn't want on the login screen (think of picture of naked girlfriend category) and is also security relevant. In fact it might not be possible to get the information at all as the home partition might be encrypted. There are things which call for a default wallpaper. The login screen is one of them :-) may be set either with a separate kcm, or whith an option in the contaiment wallpaper setting (with the appropriate warning message on the neutral nature the wallpaper should be) Then It would ask the password with polkit and then copy it somewhere global -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Background for login, splash, and lockscreen
Martin G: Who has an image of their naked better half as wallpaper? :) (this is so going into my usability report btw Now you can have a photo of your naked partner as wallpaper without it showing in the login! ;) ) But yeah point taken :D On Monday 23 June 2014 11.09.19 Marco Martin wrote: may be set either with a separate kcm, or whith an option in the contaiment wallpaper setting (with the appropriate warning message on the neutral nature the wallpaper should be) Then It would ask the password with polkit and then copy it somewhere global +1+1! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118851: Kde-baseapps- KF5 replace generic soversion.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118851/#review60757 --- Hmm, now we seem to have a strange situation between KDE4 and KF5/PN. The latest version of libkonq with KDE4 is 5.14.0 (libkonq.so.5.14.0) with libkonq.so.5 pointing to it. With this change libkonq has a lower version (4.97.0; libkonq.so.4.97.0) with libkonq.so.5 pointing to it. This would mean that libkonq is no longer co-installable with its KDE4 version due to both using libkonq.so.5. Given that there must have been a reason in the past to use libkonq.so.5.14.0, I would suggest to move libkonq version to 5.97.0 and use libkonq.so.6. This would ensure co-instability and consistency in version numbering. - Raymond Wooninck On June 20, 2014, 8:14 p.m., Scarlett Clark wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118851/ --- (Updated June 20, 2014, 8:14 p.m.) Review request for Dolphin, KDE Base Apps, Plasma, and Jonathan Riddell. Repository: kde-baseapps Description --- I was ending up with so.SOVERSION when building this, so through some research I have come up with this patch to correct the issue. If there is a better way, please let me know. Diffs - CMakeLists.txt a5588ea dolphin/src/CMakeLists.txt ce629fb lib/konq/CMakeLists.txt 6857e19 Diff: https://git.reviewboard.kde.org/r/118851/diff/ Testing --- Builds fine on Kubuntu Utopic frameworks chroot. Results in the expected: libdolphinprivate.so libdolphinprivate.so.4.97.0 libdolphinprivate.so.5 libkdeinit5_dolphin.so libkonq.so libkonq.so.4.97.0 libkonq.so.5 Thanks, Scarlett Clark ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118891: Folder view icon text background
On June 22, 2014, 11:29 p.m., Mark Gaiser wrote: Not a +1 or -1. Just my preference for this. - No background (aka, fully transparent) when nothing is selected. - Selected items should show the background as in your screenshot. Just my preference though :) Andrew Lake wrote: This change is for readability when nothing is selected. The normal icon selection background is unaffected. I know, that's why i said: - No background (aka, fully transparent) when nothing is selected. as my own preference. + it is consistent between other apps like dolphin which also doesn't have a default background color for deselected items. - Mark --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118891/#review60739 --- On June 23, 2014, 12:41 a.m., Andrew Lake wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118891/ --- (Updated June 23, 2014, 12:41 a.m.) Review request for Plasma. Bugs: 335070 https://bugs.kde.org/show_bug.cgi?id=335070 Repository: plasma-desktop Description --- Addresses lack of contrast of folderview containment icon text on certain backgrounds: Bug 335070 The color of the text background is just the complement of the icon label text with a 0.6 opacity applied. Diffs - containments/folder/package/contents/ui/ConfigIcons.qml 9f57900 containments/folder/package/contents/ui/ItemDelegate.qml 4f95f04 Diff: https://git.reviewboard.kde.org/r/118891/diff/ Testing --- File Attachments Icon text background https://git.reviewboard.kde.org/media/uploaded/files/2014/06/23/421aaadc-1b16-4d80-8929-694ac9b669b5__icontextbackground1.png Thanks, Andrew Lake ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118891: Folder view icon text background
On June 22, 2014, 11:29 p.m., Mark Gaiser wrote: Not a +1 or -1. Just my preference for this. - No background (aka, fully transparent) when nothing is selected. - Selected items should show the background as in your screenshot. Just my preference though :) Andrew Lake wrote: This change is for readability when nothing is selected. The normal icon selection background is unaffected. Mark Gaiser wrote: I know, that's why i said: - No background (aka, fully transparent) when nothing is selected. as my own preference. + it is consistent between other apps like dolphin which also doesn't have a default background color for deselected items. What Andrew was trying to say is that this change is specifically designed to add a background that is guaranteed to contrast with the text, behind the text. Not showing it when the item is not selected breaks this guarantee and makes the change pointless. Cf. https://bugs.kde.org/show_bug.cgi?id=335070 for an extended discussion of this. - Eike --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118891/#review60739 --- On June 23, 2014, 12:41 a.m., Andrew Lake wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118891/ --- (Updated June 23, 2014, 12:41 a.m.) Review request for Plasma. Bugs: 335070 https://bugs.kde.org/show_bug.cgi?id=335070 Repository: plasma-desktop Description --- Addresses lack of contrast of folderview containment icon text on certain backgrounds: Bug 335070 The color of the text background is just the complement of the icon label text with a 0.6 opacity applied. Diffs - containments/folder/package/contents/ui/ConfigIcons.qml 9f57900 containments/folder/package/contents/ui/ItemDelegate.qml 4f95f04 Diff: https://git.reviewboard.kde.org/r/118891/diff/ Testing --- File Attachments Icon text background https://git.reviewboard.kde.org/media/uploaded/files/2014/06/23/421aaadc-1b16-4d80-8929-694ac9b669b5__icontextbackground1.png Thanks, Andrew Lake ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118891: Folder view icon text background
On June 22, 2014, 11:29 p.m., Mark Gaiser wrote: Not a +1 or -1. Just my preference for this. - No background (aka, fully transparent) when nothing is selected. - Selected items should show the background as in your screenshot. Just my preference though :) Andrew Lake wrote: This change is for readability when nothing is selected. The normal icon selection background is unaffected. Mark Gaiser wrote: I know, that's why i said: - No background (aka, fully transparent) when nothing is selected. as my own preference. + it is consistent between other apps like dolphin which also doesn't have a default background color for deselected items. Eike Hein wrote: What Andrew was trying to say is that this change is specifically designed to add a background that is guaranteed to contrast with the text, behind the text. Not showing it when the item is not selected breaks this guarantee and makes the change pointless. Cf. https://bugs.kde.org/show_bug.cgi?id=335070 for an extended discussion of this. Dolphin has a fixed color background, folderview on the desktop wallpaper doesn't. Therefore, you can't compare it to Dolphin. The patch is not about personal preference, but about a contrast problem. Please refer to the bugreport when judging whether or not a patch is useful, I like it doesn't really add a lot. IMO, this changes looks reasonably nice, it's technically correct color use. I'll let Eike handle / decide further. - Sebastian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118891/#review60739 --- On June 23, 2014, 12:41 a.m., Andrew Lake wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118891/ --- (Updated June 23, 2014, 12:41 a.m.) Review request for Plasma. Bugs: 335070 https://bugs.kde.org/show_bug.cgi?id=335070 Repository: plasma-desktop Description --- Addresses lack of contrast of folderview containment icon text on certain backgrounds: Bug 335070 The color of the text background is just the complement of the icon label text with a 0.6 opacity applied. Diffs - containments/folder/package/contents/ui/ConfigIcons.qml 9f57900 containments/folder/package/contents/ui/ItemDelegate.qml 4f95f04 Diff: https://git.reviewboard.kde.org/r/118891/diff/ Testing --- File Attachments Icon text background https://git.reviewboard.kde.org/media/uploaded/files/2014/06/23/421aaadc-1b16-4d80-8929-694ac9b669b5__icontextbackground1.png Thanks, Andrew Lake ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118891: Folder view icon text background
On June 23, 2014, 9 a.m., Eike Hein wrote: containments/folder/package/contents/ui/ItemDelegate.qml, line 121 https://git.reviewboard.kde.org/r/118891/diff/2/?file=283777#file283777line121 Are you sure you wanted to hard-code pixel values here instead of using hidpi scaling-aware margins? units.smallSpacing is effectively 2px right now at 'standard DPI'. Yes, units.smallSpacing is the API to use here. I've recently changed it (last week), to be a bit bigger on higher DPI screens, so perhaps that helps? - Sebastian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118891/#review60755 --- On June 23, 2014, 12:41 a.m., Andrew Lake wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118891/ --- (Updated June 23, 2014, 12:41 a.m.) Review request for Plasma. Bugs: 335070 https://bugs.kde.org/show_bug.cgi?id=335070 Repository: plasma-desktop Description --- Addresses lack of contrast of folderview containment icon text on certain backgrounds: Bug 335070 The color of the text background is just the complement of the icon label text with a 0.6 opacity applied. Diffs - containments/folder/package/contents/ui/ConfigIcons.qml 9f57900 containments/folder/package/contents/ui/ItemDelegate.qml 4f95f04 Diff: https://git.reviewboard.kde.org/r/118891/diff/ Testing --- File Attachments Icon text background https://git.reviewboard.kde.org/media/uploaded/files/2014/06/23/421aaadc-1b16-4d80-8929-694ac9b669b5__icontextbackground1.png Thanks, Andrew Lake ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118869: Use QElapsedTimer for data engines
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118869/#review60764 --- Ship it! Code-wise the patch makes sense to me. I'm also running it since a while with some different plasmoids that stress it (clocks, system-monitor related plasmoids) and seems to work fine. One thing, the same patch should be pushed in plasma-framework as well. - Marco Martin On June 22, 2014, 11:34 a.m., Christoph Feck wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118869/ --- (Updated June 22, 2014, 11:34 a.m.) Review request for Plasma and Aaron J. Seigo. Bugs: 336551 http://bugs.kde.org/show_bug.cgi?id=336551 Repository: kdelibs Description --- As described in bug 336551, plasma data engines use QTime to find out about elapsed time. The problem is that QTime handles time zones, and therefore reads /etc/localtime on each call. Instead, it should use QElapsedTimer. This fixes both the performance issue, as well as the FIXME from the comment about not handled 24-h wraps and timezone changes. There are probably more places where this can be changed. Diffs - plasma/datacontainer.cpp d19b1a5 plasma/dataengine.cpp 9612574 plasma/private/datacontainer_p.h a3e1f00 plasma/private/dataengine_p.h 74a61e2 Diff: https://git.reviewboard.kde.org/r/118869/diff/ Testing --- Thanks, Christoph Feck ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118896: Fix 2 data races in runnercontext, mention another one.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118896/#review60766 --- Ship it! Ship It! - Marco Martin On June 23, 2014, 7:45 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118896/ --- (Updated June 23, 2014, 7:45 a.m.) Review request for Plasma and Aaron J. Seigo. Repository: kdelibs Description --- Fix 2 data races in runnercontext, mention another one. Found by helgrinding krunner. Turns out helgrind lacks support for QReadWriteLock, but reading the code still made me found these. Diffs - plasma/private/runnerjobs.cpp 6a8a7710f95adba38cc56c2d59393bfa3b123185 plasma/runnercontext.cpp abd6a4bc7fca2a0d05f27c6601b658ff552307b3 Diff: https://git.reviewboard.kde.org/r/118896/diff/ Testing --- Typing various things into krunner. The main crash is still there though: baloo or xapian isn't reentrant; but that's separate. Thanks, David Faure ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118865: [startkde from plasma next] create ~/.kde directory if it doesn't exist
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118865/#review60767
---
In Plasma Next we're following XDG standard, therefore KDEHOME is not required.
This error indicates there's a problem somewhere else looking for a deprecated
.kde directory.
Please report it on bugs.kde.org. :)
- Aleix Pol Gonzalez
On June 21, 2014, 2:26 p.m., José Manuel Santamaría Lema wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118865/
---
(Updated June 21, 2014, 2:26 p.m.)
Review request for Plasma.
Repository: plasma-workspace
Description
---
Hi,
I have been working a bit in kubuntu's plasma packaging, when I started
plasma from a fresh new account I noticed I couldn't see most icons in the
GUI's except for a few ones.
So I checked the starkde output to try to find out what was wrong, I found a
line like this one:
static QPlatformTheme* QKdeTheme::createKdeTheme(): Unable to determine
KDEHOME
Digging a bit more into the issue I also found out where this message comes
from.
File src/platformsupport/themes/genericunix/qgenericunixthemes.cpp (Qt 5.3.0)
lines 446-468:
QPlatformTheme *QKdeTheme::createKdeTheme()
{
// Check for version = 4 and determine home folder from environment,
// defaulting to ~/.kdeversion, ~/.kde
const QByteArray kdeVersionBA = qgetenv(KDE_SESSION_VERSION);
const int kdeVersion = kdeVersionBA.toInt();
if (kdeVersion 4)
return 0;
const QString kdeHomePathVar = QString::fromLocal8Bit(qgetenv(KDEHOME));
if (!kdeHomePathVar.isEmpty())
return new QKdeTheme(kdeHomePathVar, kdeVersion);
const QString kdeVersionHomePath = QDir::homePath() +
QStringLiteral(/.kde) + QLatin1String(kdeVersionBA);
if (QFileInfo(kdeVersionHomePath).isDir())
return new QKdeTheme(kdeVersionHomePath, kdeVersion);
const QString kdeHomePath = QDir::homePath() + QStringLiteral(/.kde);
if (QFileInfo(kdeHomePath).isDir())
return new QKdeTheme(kdeHomePath, kdeVersion);
qWarning(%s: Unable to determine KDEHOME, Q_FUNC_INFO);
return 0;
}
So I'm inclined to think the ~/.kde directory should be created if it doesn't
exist, thats what the patch does. What do you think?
Diffs
-
startkde/startkde.cmake ea0bdfe
Diff: https://git.reviewboard.kde.org/r/118865/diff/
Testing
---
Applied a similar patch in a customized kubuntu package. With the patch the
~/.kde directory is created and the icons can be seen.
Thanks,
José Manuel Santamaría Lema
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Background for login, splash, and lockscreen
On Mon, Jun 23, 2014 at 11:13 AM, Jens j...@ohyran.se wrote: Martin G: Who has an image of their naked better half as wallpaper? :) (this is so going into my usability report btw Now you can have a photo of your naked partner as wallpaper without it showing in the login! ;) ) But yeah point taken :D On Monday 23 June 2014 11.09.19 Marco Martin wrote: may be set either with a separate kcm, or whith an option in the contaiment wallpaper setting (with the appropriate warning message on the neutral nature the wallpaper should be) Then It would ask the password with polkit and then copy it somewhere global +1+1! +1, OTOH, I think it's acceptable to assume the lookfeel theme provides the background and that it's part of the decision of the used look and feel package what the lock screen will have as a background. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118869: Use QElapsedTimer for data engines
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118869/#review60768 --- plasma/private/dataengine_p.h https://git.reviewboard.kde.org/r/118869/#comment42358 rename this variable; it's not a timestamp - David Edmundson On June 22, 2014, 11:34 a.m., Christoph Feck wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118869/ --- (Updated June 22, 2014, 11:34 a.m.) Review request for Plasma and Aaron J. Seigo. Bugs: 336551 http://bugs.kde.org/show_bug.cgi?id=336551 Repository: kdelibs Description --- As described in bug 336551, plasma data engines use QTime to find out about elapsed time. The problem is that QTime handles time zones, and therefore reads /etc/localtime on each call. Instead, it should use QElapsedTimer. This fixes both the performance issue, as well as the FIXME from the comment about not handled 24-h wraps and timezone changes. There are probably more places where this can be changed. Diffs - plasma/datacontainer.cpp d19b1a5 plasma/dataengine.cpp 9612574 plasma/private/datacontainer_p.h a3e1f00 plasma/private/dataengine_p.h 74a61e2 Diff: https://git.reviewboard.kde.org/r/118869/diff/ Testing --- Thanks, Christoph Feck ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118869: Use QElapsedTimer for data engines
On June 23, 2014, 9:59 a.m., David Edmundson wrote: plasma/private/dataengine_p.h, line 110 https://git.reviewboard.kde.org/r/118869/diff/2/?file=282933#file282933line110 rename this variable; it's not a timestamp (adding since i did already shipit'd it) Good point, updateTimer (or updateElapsedTimer for extra verbosity) should be fine - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118869/#review60768 --- On June 22, 2014, 11:34 a.m., Christoph Feck wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118869/ --- (Updated June 22, 2014, 11:34 a.m.) Review request for Plasma and Aaron J. Seigo. Bugs: 336551 http://bugs.kde.org/show_bug.cgi?id=336551 Repository: kdelibs Description --- As described in bug 336551, plasma data engines use QTime to find out about elapsed time. The problem is that QTime handles time zones, and therefore reads /etc/localtime on each call. Instead, it should use QElapsedTimer. This fixes both the performance issue, as well as the FIXME from the comment about not handled 24-h wraps and timezone changes. There are probably more places where this can be changed. Diffs - plasma/datacontainer.cpp d19b1a5 plasma/dataengine.cpp 9612574 plasma/private/datacontainer_p.h a3e1f00 plasma/private/dataengine_p.h 74a61e2 Diff: https://git.reviewboard.kde.org/r/118869/diff/ Testing --- Thanks, Christoph Feck ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118851: Kde-baseapps- KF5 replace generic soversion.
On June 23, 2014, 9:16 a.m., Raymond Wooninck wrote: Hmm, now we seem to have a strange situation between KDE4 and KF5/PN. The latest version of libkonq with KDE4 is 5.14.0 (libkonq.so.5.14.0) with libkonq.so.5 pointing to it. With this change libkonq has a lower version (4.97.0; libkonq.so.4.97.0) with libkonq.so.5 pointing to it. This would mean that libkonq is no longer co-installable with its KDE4 version due to both using libkonq.so.5. Given that there must have been a reason in the past to use libkonq.so.5.14.0, I would suggest to move libkonq version to 5.97.0 and use libkonq.so.6. This would ensure co-instability and consistency in version numbering. Another idea is to rename the library to KF5 naming conventions. Maybe even drop the konq name, and use something which better describes it. - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118851/#review60757 --- On June 20, 2014, 8:14 p.m., Scarlett Clark wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118851/ --- (Updated June 20, 2014, 8:14 p.m.) Review request for Dolphin, KDE Base Apps, Plasma, and Jonathan Riddell. Repository: kde-baseapps Description --- I was ending up with so.SOVERSION when building this, so through some research I have come up with this patch to correct the issue. If there is a better way, please let me know. Diffs - CMakeLists.txt a5588ea dolphin/src/CMakeLists.txt ce629fb lib/konq/CMakeLists.txt 6857e19 Diff: https://git.reviewboard.kde.org/r/118851/diff/ Testing --- Builds fine on Kubuntu Utopic frameworks chroot. Results in the expected: libdolphinprivate.so libdolphinprivate.so.4.97.0 libdolphinprivate.so.5 libkdeinit5_dolphin.so libkonq.so libkonq.so.4.97.0 libkonq.so.5 Thanks, Scarlett Clark ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118889: Use new Konqui in the about Dialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118889/#review60771 --- Ship it! Ship It! - David Edmundson On June 22, 2014, 8:13 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118889/ --- (Updated June 22, 2014, 8:13 p.m.) Review request for KDE Frameworks and Plasma. Repository: kxmlgui Description --- This (actually no code, just a new png) replaces the current image in About KDE from the old 3d rendered Konqui to an image using the New official one, done by the author for the purpose Diffs - Diff: https://git.reviewboard.kde.org/r/118889/diff/ Testing --- File Attachments aboutkde.png https://git.reviewboard.kde.org/media/uploaded/files/2014/06/22/cf0875f5-52c0-429f-b852-54ea2b6f87fd__aboutkde.png Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118889: Use new Konqui in the about Dialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118889/#review60772 --- What about bringing this to VdG? They can come up with a more integrated new design for the about dialog. For the moment, I'm good with just changing the picture, but I wouldn't like to leave it there. - Aleix Pol Gonzalez On June 22, 2014, 8:13 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118889/ --- (Updated June 22, 2014, 8:13 p.m.) Review request for KDE Frameworks and Plasma. Repository: kxmlgui Description --- This (actually no code, just a new png) replaces the current image in About KDE from the old 3d rendered Konqui to an image using the New official one, done by the author for the purpose Diffs - Diff: https://git.reviewboard.kde.org/r/118889/diff/ Testing --- File Attachments aboutkde.png https://git.reviewboard.kde.org/media/uploaded/files/2014/06/22/cf0875f5-52c0-429f-b852-54ea2b6f87fd__aboutkde.png Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118889: Use new Konqui in the about Dialog
On June 23, 2014, 10:34 a.m., Aleix Pol Gonzalez wrote: What about bringing this to VdG? They can come up with a more integrated new design for the about dialog. For the moment, I'm good with just changing the picture, but I wouldn't like to leave it there. this comes *from* the VDG - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118889/#review60772 --- On June 22, 2014, 8:13 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118889/ --- (Updated June 22, 2014, 8:13 p.m.) Review request for KDE Frameworks and Plasma. Repository: kxmlgui Description --- This (actually no code, just a new png) replaces the current image in About KDE from the old 3d rendered Konqui to an image using the New official one, done by the author for the purpose Diffs - Diff: https://git.reviewboard.kde.org/r/118889/diff/ Testing --- File Attachments aboutkde.png https://git.reviewboard.kde.org/media/uploaded/files/2014/06/22/cf0875f5-52c0-429f-b852-54ea2b6f87fd__aboutkde.png Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118889: Use new Konqui in the about Dialog
On June 23, 2014, 10:34 a.m., Aleix Pol Gonzalez wrote: What about bringing this to VdG? They can come up with a more integrated new design for the about dialog. For the moment, I'm good with just changing the picture, but I wouldn't like to leave it there. Marco Martin wrote: this comes *from* the VDG discussion here https://forum.kde.org/viewtopic.php?f=285t=121267start=15 - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118889/#review60772 --- On June 22, 2014, 8:13 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118889/ --- (Updated June 22, 2014, 8:13 p.m.) Review request for KDE Frameworks and Plasma. Repository: kxmlgui Description --- This (actually no code, just a new png) replaces the current image in About KDE from the old 3d rendered Konqui to an image using the New official one, done by the author for the purpose Diffs - Diff: https://git.reviewboard.kde.org/r/118889/diff/ Testing --- File Attachments aboutkde.png https://git.reviewboard.kde.org/media/uploaded/files/2014/06/22/cf0875f5-52c0-429f-b852-54ea2b6f87fd__aboutkde.png Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118851: Kde-baseapps- KF5 replace generic soversion.
On June 23, 2014, 9:16 a.m., Raymond Wooninck wrote: Hmm, now we seem to have a strange situation between KDE4 and KF5/PN. The latest version of libkonq with KDE4 is 5.14.0 (libkonq.so.5.14.0) with libkonq.so.5 pointing to it. With this change libkonq has a lower version (4.97.0; libkonq.so.4.97.0) with libkonq.so.5 pointing to it. This would mean that libkonq is no longer co-installable with its KDE4 version due to both using libkonq.so.5. Given that there must have been a reason in the past to use libkonq.so.5.14.0, I would suggest to move libkonq version to 5.97.0 and use libkonq.so.6. This would ensure co-instability and consistency in version numbering. Christoph Feck wrote: Another idea is to rename the library to KF5 naming conventions. Maybe even drop the konq name, and use something which better describes it. pushed a change to set it to 6.0.0 - Jonathan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118851/#review60757 --- On June 20, 2014, 8:14 p.m., Scarlett Clark wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118851/ --- (Updated June 20, 2014, 8:14 p.m.) Review request for Dolphin, KDE Base Apps, Plasma, and Jonathan Riddell. Repository: kde-baseapps Description --- I was ending up with so.SOVERSION when building this, so through some research I have come up with this patch to correct the issue. If there is a better way, please let me know. Diffs - CMakeLists.txt a5588ea dolphin/src/CMakeLists.txt ce629fb lib/konq/CMakeLists.txt 6857e19 Diff: https://git.reviewboard.kde.org/r/118851/diff/ Testing --- Builds fine on Kubuntu Utopic frameworks chroot. Results in the expected: libdolphinprivate.so libdolphinprivate.so.4.97.0 libdolphinprivate.so.5 libkdeinit5_dolphin.so libkonq.so libkonq.so.4.97.0 libkonq.so.5 Thanks, Scarlett Clark ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Minutes Monday Plasma hangout
Here are the minutes of the mondaily hangout meeting from 23rd of June, 2014 Present: David, Ivan, Jonathan, Marco, Martin G., Sebastian David: - General bugfixing - Plans more general bugfixing Ivan - activity switcher is faster now - locks up when it's not preloaded (bug!) - focused / current activity is not very clear, will take it up with VDG - Jonathan - Plasma 5 in pretty good shape - KF5 planning to tag final early next week - Push to get artwork in (e.g. wallpaper) - Plasma RC due to tag next week -- Everybody, Get stuff in final shape!! Marco - General bugfixing - Changes in Plasma::Theme to support ColorScope, influences color scheme for its children - wants to merge new Konqi logo into About KDE - some discussion around KDE logo going on Martin - Bugfixing - Making no shaders available case more robust - Load of bugfixes in Aurorae theme - Started writing unittests for Klipper so it can move to a plasmoid for 5.1 Sebastian - Discussing with designers the KCM structure, was some delay, still hoping to get it done shortly - Translations KCM merged -- testing welcome - Fixed a number of random bugs, triaged more - Plans to start work on 5.0 release promo this week - systemsettings categorization work incoming Cheers, -- 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 118869: Use QElapsedTimer for data engines
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118869/ --- (Updated June 23, 2014, 10:47 a.m.) Review request for Plasma and Aaron J. Seigo. Changes --- Change variable names (Timestamp - Timer) Bugs: 336551 http://bugs.kde.org/show_bug.cgi?id=336551 Repository: kdelibs Description --- As described in bug 336551, plasma data engines use QTime to find out about elapsed time. The problem is that QTime handles time zones, and therefore reads /etc/localtime on each call. Instead, it should use QElapsedTimer. This fixes both the performance issue, as well as the FIXME from the comment about not handled 24-h wraps and timezone changes. There are probably more places where this can be changed. Diffs (updated) - plasma/datacontainer.cpp d19b1a5 plasma/dataengine.cpp 9612574 plasma/private/datacontainer_p.h a3e1f00 plasma/private/dataengine_p.h 74a61e2 Diff: https://git.reviewboard.kde.org/r/118869/diff/ Testing --- Thanks, Christoph Feck ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118869: Use QElapsedTimer for data engines
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118869/#review60777 --- Ship it! Ship It! - Marco Martin On June 23, 2014, 10:47 a.m., Christoph Feck wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118869/ --- (Updated June 23, 2014, 10:47 a.m.) Review request for Plasma and Aaron J. Seigo. Bugs: 336551 http://bugs.kde.org/show_bug.cgi?id=336551 Repository: kdelibs Description --- As described in bug 336551, plasma data engines use QTime to find out about elapsed time. The problem is that QTime handles time zones, and therefore reads /etc/localtime on each call. Instead, it should use QElapsedTimer. This fixes both the performance issue, as well as the FIXME from the comment about not handled 24-h wraps and timezone changes. There are probably more places where this can be changed. Diffs - plasma/datacontainer.cpp d19b1a5 plasma/dataengine.cpp 9612574 plasma/private/datacontainer_p.h a3e1f00 plasma/private/dataengine_p.h 74a61e2 Diff: https://git.reviewboard.kde.org/r/118869/diff/ Testing --- Thanks, Christoph Feck ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118869: Use QElapsedTimer for data engines
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118869/#review60778 --- Ship it! Ship It! - David Edmundson On June 23, 2014, 10:47 a.m., Christoph Feck wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118869/ --- (Updated June 23, 2014, 10:47 a.m.) Review request for Plasma and Aaron J. Seigo. Bugs: 336551 http://bugs.kde.org/show_bug.cgi?id=336551 Repository: kdelibs Description --- As described in bug 336551, plasma data engines use QTime to find out about elapsed time. The problem is that QTime handles time zones, and therefore reads /etc/localtime on each call. Instead, it should use QElapsedTimer. This fixes both the performance issue, as well as the FIXME from the comment about not handled 24-h wraps and timezone changes. There are probably more places where this can be changed. Diffs - plasma/datacontainer.cpp d19b1a5 plasma/dataengine.cpp 9612574 plasma/private/datacontainer_p.h a3e1f00 plasma/private/dataengine_p.h 74a61e2 Diff: https://git.reviewboard.kde.org/r/118869/diff/ Testing --- Thanks, Christoph Feck ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Minutes Monday Plasma hangout
On Mon, Jun 23, 2014 at 4:11 PM, Sebastian Kügler se...@kde.org wrote: Present: David, Ivan, Jonathan, Marco, Martin G., Sebastian Bhushan - Want review on https://git.reviewboard.kde.org/r/118876/ - Bux fixing and triage -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Minutes Monday Plasma hangout
On Mon, Jun 23, 2014 at 12:41 PM, Sebastian Kügler se...@kde.org wrote: Here are the minutes of the mondaily hangout meeting from 23rd of June, 2014 Present: David, Ivan, Jonathan, Marco, Martin G., Sebastian David: - General bugfixing - Plans more general bugfixing Ivan - activity switcher is faster now - locks up when it's not preloaded (bug!) - focused / current activity is not very clear, will take it up with VDG - Jonathan - Plasma 5 in pretty good shape - KF5 planning to tag final early next week - Push to get artwork in (e.g. wallpaper) - Plasma RC due to tag next week -- Everybody, Get stuff in final shape!! Marco - General bugfixing - Changes in Plasma::Theme to support ColorScope, influences color scheme for its children - wants to merge new Konqi logo into About KDE - some discussion around KDE logo going on Martin - Bugfixing - Making no shaders available case more robust - Load of bugfixes in Aurorae theme - Started writing unittests for Klipper so it can move to a plasmoid for 5.1 Sebastian - Discussing with designers the KCM structure, was some delay, still hoping to get it done shortly - Translations KCM merged -- testing welcome - Fixed a number of random bugs, triaged more - Plans to start work on 5.0 release promo this week - systemsettings categorization work incoming Cheers, Hi, My excuses for not attending the meeting, last week I dedicated it to: - hunting some problems in the panel and fixed some visual glitches. - hunting multi-screen issues, apparently there's another important bug in Qt xcb plugin. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118876: Remove start in systemtray option from the kmenuedit.
On June 22, 2014, 6:58 p.m., Martin Gräßlin wrote: I think the suggestion to port ksystemtraycmd to SNI is wrong: we don't want applications in the system tray. Removing X11 support from system tray is one part of the story for that. We do want to allow apps in the systemtray in principle, but be able to move them elsewhere. So a ksystemtraycmd using SNI would accomplish that (since it attaches enough metadata, category for example). Not supporting X11/FDO systray spec is a technical thing (it's almost impossible to do well in a scenegraph world). Therefore, porting ksystemtraycmd to SNI makes sense. - Sebastian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118876/#review60725 --- On June 22, 2014, 12:36 p.m., Bhushan Shah wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118876/ --- (Updated June 22, 2014, 12:36 p.m.) Review request for Plasma and Àlex Fiestas. Repository: kmenuedit Description --- This option uses ksystraycmd tool which is removed long ago http://commits.kde.org/kde-workspace/38fddebe00a271436c17120a0adffeb0f52a1af7 Diffs - basictab.h 9aa4c18 basictab.cpp 6e3e086 Diff: https://git.reviewboard.kde.org/r/118876/diff/ Testing --- Thanks, Bhushan Shah ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118869: Use QElapsedTimer for data engines
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118869/ --- (Updated June 23, 2014, 11:03 a.m.) Status -- This change has been marked as submitted. Review request for Plasma and Aaron J. Seigo. Bugs: 336551 http://bugs.kde.org/show_bug.cgi?id=336551 Repository: kdelibs Description --- As described in bug 336551, plasma data engines use QTime to find out about elapsed time. The problem is that QTime handles time zones, and therefore reads /etc/localtime on each call. Instead, it should use QElapsedTimer. This fixes both the performance issue, as well as the FIXME from the comment about not handled 24-h wraps and timezone changes. There are probably more places where this can be changed. Diffs - plasma/datacontainer.cpp d19b1a5 plasma/dataengine.cpp 9612574 plasma/private/datacontainer_p.h a3e1f00 plasma/private/dataengine_p.h 74a61e2 Diff: https://git.reviewboard.kde.org/r/118869/diff/ Testing --- Thanks, Christoph Feck ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118869: Use QElapsedTimer for data engines
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118869/#review60780 --- This review has been submitted with commit ac5d3d2f916c0a461121d4d033642227bd743edb by Christoph Feck to branch master. - Commit Hook On June 23, 2014, 10:47 a.m., Christoph Feck wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118869/ --- (Updated June 23, 2014, 10:47 a.m.) Review request for Plasma and Aaron J. Seigo. Bugs: 336551 http://bugs.kde.org/show_bug.cgi?id=336551 Repository: kdelibs Description --- As described in bug 336551, plasma data engines use QTime to find out about elapsed time. The problem is that QTime handles time zones, and therefore reads /etc/localtime on each call. Instead, it should use QElapsedTimer. This fixes both the performance issue, as well as the FIXME from the comment about not handled 24-h wraps and timezone changes. There are probably more places where this can be changed. Diffs - plasma/datacontainer.cpp d19b1a5 plasma/dataengine.cpp 9612574 plasma/private/datacontainer_p.h a3e1f00 plasma/private/dataengine_p.h 74a61e2 Diff: https://git.reviewboard.kde.org/r/118869/diff/ Testing --- Thanks, Christoph Feck ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118869: Use QElapsedTimer for data engines
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118869/#review60781 --- This review has been submitted with commit fec57bdaa2622efbab88061e3d84fda03a806376 by Christoph Feck to branch master. - Commit Hook On June 23, 2014, 11:03 a.m., Christoph Feck wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118869/ --- (Updated June 23, 2014, 11:03 a.m.) Review request for Plasma and Aaron J. Seigo. Bugs: 336551 http://bugs.kde.org/show_bug.cgi?id=336551 Repository: kdelibs Description --- As described in bug 336551, plasma data engines use QTime to find out about elapsed time. The problem is that QTime handles time zones, and therefore reads /etc/localtime on each call. Instead, it should use QElapsedTimer. This fixes both the performance issue, as well as the FIXME from the comment about not handled 24-h wraps and timezone changes. There are probably more places where this can be changed. Diffs - plasma/datacontainer.cpp d19b1a5 plasma/dataengine.cpp 9612574 plasma/private/datacontainer_p.h a3e1f00 plasma/private/dataengine_p.h 74a61e2 Diff: https://git.reviewboard.kde.org/r/118869/diff/ Testing --- Thanks, Christoph Feck ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118889: Use new Konqui in the about Dialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118889/#review60783 --- Sorry for hijacking this review, but I think we need the plush version for each of those. ASAP. Just saying. :) /ot - Luigi Toscano On June 22, 2014, 10:13 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118889/ --- (Updated June 22, 2014, 10:13 p.m.) Review request for KDE Frameworks and Plasma. Repository: kxmlgui Description --- This (actually no code, just a new png) replaces the current image in About KDE from the old 3d rendered Konqui to an image using the New official one, done by the author for the purpose Diffs - Diff: https://git.reviewboard.kde.org/r/118889/diff/ Testing --- File Attachments aboutkde.png https://git.reviewboard.kde.org/media/uploaded/files/2014/06/22/cf0875f5-52c0-429f-b852-54ea2b6f87fd__aboutkde.png Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118889: Use new Konqui in the about Dialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118889/#review60784 --- Ship it! Ship It! - Sebastian Kügler On June 22, 2014, 8:13 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118889/ --- (Updated June 22, 2014, 8:13 p.m.) Review request for KDE Frameworks and Plasma. Repository: kxmlgui Description --- This (actually no code, just a new png) replaces the current image in About KDE from the old 3d rendered Konqui to an image using the New official one, done by the author for the purpose Diffs - Diff: https://git.reviewboard.kde.org/r/118889/diff/ Testing --- File Attachments aboutkde.png https://git.reviewboard.kde.org/media/uploaded/files/2014/06/22/cf0875f5-52c0-429f-b852-54ea2b6f87fd__aboutkde.png Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118889: Use new Konqui in the about Dialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118889/#review60786 --- This review has been submitted with commit 09fc14eda3fa7f378fe2252d6556786183f7472e by Marco Martin to branch master. - Commit Hook On June 22, 2014, 8:13 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118889/ --- (Updated June 22, 2014, 8:13 p.m.) Review request for KDE Frameworks and Plasma. Repository: kxmlgui Description --- This (actually no code, just a new png) replaces the current image in About KDE from the old 3d rendered Konqui to an image using the New official one, done by the author for the purpose Diffs - Diff: https://git.reviewboard.kde.org/r/118889/diff/ Testing --- File Attachments aboutkde.png https://git.reviewboard.kde.org/media/uploaded/files/2014/06/22/cf0875f5-52c0-429f-b852-54ea2b6f87fd__aboutkde.png Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118889: Use new Konqui in the about Dialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118889/ --- (Updated June 23, 2014, 11:33 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Plasma. Repository: kxmlgui Description --- This (actually no code, just a new png) replaces the current image in About KDE from the old 3d rendered Konqui to an image using the New official one, done by the author for the purpose Diffs - Diff: https://git.reviewboard.kde.org/r/118889/diff/ Testing --- File Attachments aboutkde.png https://git.reviewboard.kde.org/media/uploaded/files/2014/06/22/cf0875f5-52c0-429f-b852-54ea2b6f87fd__aboutkde.png Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118889: Use new Konqui in the about Dialog
On June 23, 2014, 10:34 a.m., Aleix Pol Gonzalez wrote: What about bringing this to VdG? They can come up with a more integrated new design for the about dialog. For the moment, I'm good with just changing the picture, but I wouldn't like to leave it there. Marco Martin wrote: this comes *from* the VDG Marco Martin wrote: discussion here https://forum.kde.org/viewtopic.php?f=285t=121267start=15 so, for now and 5.0 is pushed, future versions can have incremental improvements, like color palette, dragons # etc - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118889/#review60772 --- On June 23, 2014, 11:33 a.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118889/ --- (Updated June 23, 2014, 11:33 a.m.) Review request for KDE Frameworks and Plasma. Repository: kxmlgui Description --- This (actually no code, just a new png) replaces the current image in About KDE from the old 3d rendered Konqui to an image using the New official one, done by the author for the purpose Diffs - Diff: https://git.reviewboard.kde.org/r/118889/diff/ Testing --- File Attachments aboutkde.png https://git.reviewboard.kde.org/media/uploaded/files/2014/06/22/cf0875f5-52c0-429f-b852-54ea2b6f87fd__aboutkde.png Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Jenkins build became unstable: plasma-workspace_master_qt5 #528
See http://build.kde.org/job/plasma-workspace_master_qt5/528/changes ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 118898: KGamma: Apply user setting at login/startup
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118898/
---
Review request for kde-workspace, Plasma and Marcel Wiesweg.
Bugs: 218668
http://bugs.kde.org/show_bug.cgi?id=218668
Repository: kgamma
Description
---
KGamma's saved user settings are not applied on startup/login. The user has to
enter the KCM to apply them.
This makes it rather useless, as not even saving the settings system-wide
really works any more. (this requires an xorg.conf which normally doesn't exist
nowadays)
This patch factors out the function init_kgamma() into its own source file
(init_kgamma.cpp), adds a small executable (applykgammasettings) that just
applies those settings by calling that function, and installs
applykgammasettings.desktop to ${AUTOSTART_INSTALL_DIR} that runs
applykgammasettings on login.
PS: As there seems to be no kgamma group and this is desktop-related, I decided
to add the kde-workspace and plasma groups for review. I hope that's ok... ;)
Diffs
-
kcmkgamma/CMakeLists.txt 3980023
kcmkgamma/applykgammasettings.cpp PRE-CREATION
kcmkgamma/applykgammasettings.desktop PRE-CREATION
kcmkgamma/init_kgamma.cpp PRE-CREATION
kcmkgamma/kgamma.cpp 890ba99
Diff: https://git.reviewboard.kde.org/r/118898/diff/
Testing
---
Set a gamma value in the KGamma KCM, logout/login (or reboot), Gamma value
gets set correctly.
If there's no kgammarc file (or it contains no actual gamma settings), the
Gamma value is not changed. It stays at what is configured for X (or its
default).
Thanks,
Wolfgang Bauer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118898: KGamma: Apply user setting at login/startup
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118898/#review60795
---
I think there's a couple of problems with this approach:
- This slows down startup for everybody, not just those who changed the
setting. I'm not super-familiar with this, but isn't kcminit for this use-case?
- Changing startup procedure this late in the game (Plasma 4.x has been on LTS
for almost a year, feature frozen for much longer)
- This particular KCM is dead in Plasma 5 (not really a reason to not fix it
in 4.x, but the feature will be lost again
Again, not super-privvy of the whole picture, but isn't color correction the
correct solution here?
- Sebastian Kügler
On June 23, 2014, 1:06 p.m., Wolfgang Bauer wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118898/
---
(Updated June 23, 2014, 1:06 p.m.)
Review request for kde-workspace, Plasma and Marcel Wiesweg.
Bugs: 218668
http://bugs.kde.org/show_bug.cgi?id=218668
Repository: kgamma
Description
---
KGamma's saved user settings are not applied on startup/login. The user has
to enter the KCM to apply them.
This makes it rather useless, as not even saving the settings system-wide
really works any more. (this requires an xorg.conf which normally doesn't
exist nowadays)
This patch factors out the function init_kgamma() into its own source file
(init_kgamma.cpp), adds a small executable (applykgammasettings) that just
applies those settings by calling that function, and installs
applykgammasettings.desktop to ${AUTOSTART_INSTALL_DIR} that runs
applykgammasettings on login.
PS: As there seems to be no kgamma group and this is desktop-related, I
decided to add the kde-workspace and plasma groups for review. I hope that's
ok... ;)
Diffs
-
kcmkgamma/CMakeLists.txt 3980023
kcmkgamma/applykgammasettings.cpp PRE-CREATION
kcmkgamma/applykgammasettings.desktop PRE-CREATION
kcmkgamma/init_kgamma.cpp PRE-CREATION
kcmkgamma/kgamma.cpp 890ba99
Diff: https://git.reviewboard.kde.org/r/118898/diff/
Testing
---
Set a gamma value in the KGamma KCM, logout/login (or reboot), Gamma value
gets set correctly.
If there's no kgammarc file (or it contains no actual gamma settings), the
Gamma value is not changed. It stays at what is configured for X (or its
default).
Thanks,
Wolfgang Bauer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118366: Porting keyboard module to Framework5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118366/ --- (Updated June 23, 2014, 1:45 p.m.) Review request for Plasma and Andriy Rysin. Changes --- added proper diff with no intermediate changes ! Repository: plasma-desktop Description --- Removed deprecated statements and ported keyboard module to framework 5. Diffs (updated) - kcms/keyboard/bindings.h c5764556d97e06ebad4f1737ffbbea2981ff32ca kcms/keyboard/bindings.cpp 21541e095da0b8d6ea1f789644f6e09d577c298b kcms/keyboard/flags.cpp b768586cc644fc5750245a8b1c3db4c55a43c16e kcms/keyboard/iso_codes.h 6a337392e958546e9f36423d7e3fd10d9e12c6f8 kcms/keyboard/iso_codes.cpp 3e3b210b9f0f89c71a04535e74bd43b6b3b243e9 kcms/keyboard/kcm_keyboard.cpp 42b7fe4df5fddd9ae738cde62d0c9e8a3dcad103 kcms/keyboard/kcm_keyboard.ui 0062d1c53877f13d0036c0220691347434a9d47f kcms/keyboard/kcm_keyboard_widget.h 657ddda3bc1d75a632a6ddbd1a9ec690b6244909 kcms/keyboard/kcm_keyboard_widget.cpp 21685eb527b7fd1d8a322d0e17ae2c0ae291ce41 kcms/keyboard/kcmmisc.h 411bdd2b0f61257b4382fe35be4b8fa4ea2ecba6 kcms/keyboard/kcmmisc.cpp 6f787ea3723f223537252b9581c15db203f4764c kcms/keyboard/kcmmiscwidget.ui 37fbaf4b9c9af9a62713bb9b5444cc04320e8d53 kcms/keyboard/keyboard_config.h b86418de47a83e75eb85e723cc8eb24071e1f43d kcms/keyboard/keyboard_config.cpp f3ff97ca84d444acfb215a32bb900815318aefd9 kcms/keyboard/keyboard_daemon.h 4edb968bb071445c52332c695e7978d26363ad09 kcms/keyboard/keyboard_daemon.cpp 25673b073e104357cb3d56b13688ef7d790ee8cd kcms/keyboard/keyboard_hardware.cpp dca49b674083dbae6398e8ba0e524c647a36e47a kcms/keyboard/layout_memory.h df8568c2bdb82f0be713424e1cf6404761312ea5 kcms/keyboard/layout_memory.cpp 9e723612b75b82fb04ac1fd5c2271e58e3c1aaf7 kcms/keyboard/layout_memory_persister.h 8c4b3c5f60277c319b4d94ad3d40b1a65b706b8d kcms/keyboard/layout_memory_persister.cpp 8a6118aad9edea5c6a4a627144c3fd3bf837fe0e kcms/keyboard/layout_widget.cpp e67b2d77d32b87339003285712b6ef98fc292bd3 kcms/keyboard/layouts_menu.h db2f3ff5844e16340ad3ca6102e6b1c4866ad8db kcms/keyboard/layouts_menu.cpp fd436c406671dcbb859dcb7367b9c83fba99da0c kcms/keyboard/x11_helper.h 719b13fec63265e0c0fed01c21e197349305928e kcms/keyboard/x11_helper.cpp 0e2806eeb55e4987c2b8f528d026ec5864d2dd9c kcms/keyboard/xinput_helper.h 343d7ed2a0528459069b0b2e3a3d4aa4d8ce43d8 kcms/keyboard/xinput_helper.cpp b311579d1b65f3068d0c25b180bc1dd88fe7ba65 kcms/keyboard/xkb_helper.cpp 967399ebca42e3cd18b441152a0cf3a31e28b131 kcms/keyboard/xkb_rules.h 2be856246cc150abb24775c6d56b8af2a07df94f kcms/keyboard/xkb_rules.cpp f09e6750130799d6e0cdc380a6dbaa834c43aa43 Diff: https://git.reviewboard.kde.org/r/118366/diff/ Testing --- Thanks, shivam makkar ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118891: Folder view icon text background
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118891/ --- (Updated June 23, 2014, 2:19 p.m.) Review request for Plasma. Changes --- Use units.smallspacing for text background margins. Don't show text background on popups or widget view. Also decreased opacity to 0.4 to reduce heavy feel. See attached screen capture. Bugs: 335070 https://bugs.kde.org/show_bug.cgi?id=335070 Repository: plasma-desktop Description --- Addresses lack of contrast of folderview containment icon text on certain backgrounds: Bug 335070 The color of the text background is just the complement of the icon label text with a 0.6 opacity applied. Diffs (updated) - containments/folder/package/contents/ui/ConfigIcons.qml 9f57900 containments/folder/package/contents/ui/ItemDelegate.qml 4f95f04 Diff: https://git.reviewboard.kde.org/r/118891/diff/ Testing --- File Attachments (updated) with latest changes showing it with selection background https://git.reviewboard.kde.org/media/uploaded/files/2014/06/23/58f07e42-08b4-480a-9c05-40195514edbf__icontextbackground2.png Thanks, Andrew Lake ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118898: KGamma: Apply user setting at login/startup
On June 23, 2014, 3:21 p.m., Sebastian Kügler wrote:
I think there's a couple of problems with this approach:
- This slows down startup for everybody, not just those who changed the
setting. I'm not super-familiar with this, but isn't kcminit for this
use-case?
- Changing startup procedure this late in the game (Plasma 4.x has been on
LTS for almost a year, feature frozen for much longer)
- This particular KCM is dead in Plasma 5 (not really a reason to not fix
it in 4.x, but the feature will be lost again
Again, not super-privvy of the whole picture, but isn't color correction
the correct solution here?
applykgammasettings is only called on login for people actually installing
kgamma (it's a separate tarball and separate package on openSUSE at least).
There is no change to plasma's own startup procedure, and no change at all when
kgamma is not installed.
kcminit is actually used by kgamma right now (it calls the same function), but
that only applies when the user enters the KCM. But the point of this setting
is to be applied automatically on login/startup.
- Wolfgang
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118898/#review60795
---
On June 23, 2014, 3:06 p.m., Wolfgang Bauer wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118898/
---
(Updated June 23, 2014, 3:06 p.m.)
Review request for kde-workspace, Plasma and Marcel Wiesweg.
Bugs: 218668
http://bugs.kde.org/show_bug.cgi?id=218668
Repository: kgamma
Description
---
KGamma's saved user settings are not applied on startup/login. The user has
to enter the KCM to apply them.
This makes it rather useless, as not even saving the settings system-wide
really works any more. (this requires an xorg.conf which normally doesn't
exist nowadays)
This patch factors out the function init_kgamma() into its own source file
(init_kgamma.cpp), adds a small executable (applykgammasettings) that just
applies those settings by calling that function, and installs
applykgammasettings.desktop to ${AUTOSTART_INSTALL_DIR} that runs
applykgammasettings on login.
PS: As there seems to be no kgamma group and this is desktop-related, I
decided to add the kde-workspace and plasma groups for review. I hope that's
ok... ;)
Diffs
-
kcmkgamma/CMakeLists.txt 3980023
kcmkgamma/applykgammasettings.cpp PRE-CREATION
kcmkgamma/applykgammasettings.desktop PRE-CREATION
kcmkgamma/init_kgamma.cpp PRE-CREATION
kcmkgamma/kgamma.cpp 890ba99
Diff: https://git.reviewboard.kde.org/r/118898/diff/
Testing
---
Set a gamma value in the KGamma KCM, logout/login (or reboot), Gamma value
gets set correctly.
If there's no kgammarc file (or it contains no actual gamma settings), the
Gamma value is not changed. It stays at what is configured for X (or its
default).
Thanks,
Wolfgang Bauer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118898: KGamma: Apply user setting at login/startup
On June 23, 2014, 3:21 p.m., Sebastian Kügler wrote:
I think there's a couple of problems with this approach:
- This slows down startup for everybody, not just those who changed the
setting. I'm not super-familiar with this, but isn't kcminit for this
use-case?
- Changing startup procedure this late in the game (Plasma 4.x has been on
LTS for almost a year, feature frozen for much longer)
- This particular KCM is dead in Plasma 5 (not really a reason to not fix
it in 4.x, but the feature will be lost again
Again, not super-privvy of the whole picture, but isn't color correction
the correct solution here?
Wolfgang Bauer wrote:
applykgammasettings is only called on login for people actually
installing kgamma (it's a separate tarball and separate package on openSUSE
at least).
There is no change to plasma's own startup procedure, and no change at
all when kgamma is not installed.
kcminit is actually used by kgamma right now (it calls the same
function), but that only applies when the user enters the KCM. But the point
of this setting is to be applied automatically on login/startup.
PS: Sorry, kcminit does seem to be able to apply settings on login. I seem to
have confused it with something else...
I will have a look at this then.
- Wolfgang
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118898/#review60795
---
On June 23, 2014, 3:06 p.m., Wolfgang Bauer wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118898/
---
(Updated June 23, 2014, 3:06 p.m.)
Review request for kde-workspace, Plasma and Marcel Wiesweg.
Bugs: 218668
http://bugs.kde.org/show_bug.cgi?id=218668
Repository: kgamma
Description
---
KGamma's saved user settings are not applied on startup/login. The user has
to enter the KCM to apply them.
This makes it rather useless, as not even saving the settings system-wide
really works any more. (this requires an xorg.conf which normally doesn't
exist nowadays)
This patch factors out the function init_kgamma() into its own source file
(init_kgamma.cpp), adds a small executable (applykgammasettings) that just
applies those settings by calling that function, and installs
applykgammasettings.desktop to ${AUTOSTART_INSTALL_DIR} that runs
applykgammasettings on login.
PS: As there seems to be no kgamma group and this is desktop-related, I
decided to add the kde-workspace and plasma groups for review. I hope that's
ok... ;)
Diffs
-
kcmkgamma/CMakeLists.txt 3980023
kcmkgamma/applykgammasettings.cpp PRE-CREATION
kcmkgamma/applykgammasettings.desktop PRE-CREATION
kcmkgamma/init_kgamma.cpp PRE-CREATION
kcmkgamma/kgamma.cpp 890ba99
Diff: https://git.reviewboard.kde.org/r/118898/diff/
Testing
---
Set a gamma value in the KGamma KCM, logout/login (or reboot), Gamma value
gets set correctly.
If there's no kgammarc file (or it contains no actual gamma settings), the
Gamma value is not changed. It stays at what is configured for X (or its
default).
Thanks,
Wolfgang Bauer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 118899: Remove unused dependencies.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118899/ --- Review request for Plasma. Repository: plasma-workspace Description --- Threadweaver is unused. Akonadi, Boost, KdepimLibs, and QImageBlitz are used only by commented-out stuff so there's no point trying to find and report about it. Diffs - CMakeLists.txt 4bfa2e93abfc6f8087693c363e5982fa862cf0fa wallpapers/image/CMakeLists.txt 32dbf310ce7c243a62e042c71f8b9de420048cd8 Diff: https://git.reviewboard.kde.org/r/118899/diff/ Testing --- Inspected source. Builds. Thanks, Michael Palimaka ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma 5: Roadmap post 5.0
Hi everyone I was wondering, has there been any discussions on whether or not bug fix releases for Plasma 5 will be provided after the 5.0 release? Or will users simply have to wait for the next 5.1 release to get bug fixes? There also doesn't seem to be any indication of what the time frame will be between Plasma 5 releases ( I was told 3 months by some people, this doesn't seem to be written down in a wiki page). Would be awesome if someone could indicate what the roadmap is after the Plasma 5.0 release :) Cheers Rohan Garg ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5: Roadmap post 5.0
On Monday 23 June 2014, Rohan Garg wrote: Hi everyone I was wondering, has there been any discussions on whether or not bug fix releases for Plasma 5 will be provided after the 5.0 release? Or will users simply have to wait for the next 5.1 release to get bug fixes? There also doesn't seem to be any indication of what the time frame will be between Plasma 5 releases ( I was told 3 months by some people, this doesn't seem to be written down in a wiki page). Would be awesome if someone could indicate what the roadmap is after the Plasma 5.0 release :) I assumed there would have been monthly bugfix releases as in 4.x? frameworks (so plasma-framework as well) would have if i understood correctly montly releases (with minimal feature additions and bugfixes) the workspace part I think could have a multiple of that? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Jenkins build is back to stable : plasma-workspace_master_qt5 #529
See http://build.kde.org/job/plasma-workspace_master_qt5/529/changes ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5: Roadmap post 5.0
On Mon, Jun 23, 2014 at 4:56 PM, Marco Martin notm...@gmail.com wrote: On Monday 23 June 2014, Rohan Garg wrote: Hi everyone I was wondering, has there been any discussions on whether or not bug fix releases for Plasma 5 will be provided after the 5.0 release? Or will users simply have to wait for the next 5.1 release to get bug fixes? There also doesn't seem to be any indication of what the time frame will be between Plasma 5 releases ( I was told 3 months by some people, this doesn't seem to be written down in a wiki page). Would be awesome if someone could indicate what the roadmap is after the Plasma 5.0 release :) I assumed there would have been monthly bugfix releases as in 4.x? frameworks (so plasma-framework as well) would have if i understood correctly montly releases (with minimal feature additions and bugfixes) the workspace part I think could have a multiple of that? I think that plasma releases can follow KF5, we could get at least 5.0.1 in August 15th and 5.0.2 in September 15th. About Plasma 5.1, did we agree on a 3-month schedule? Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 118900: Improve dependencies.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118900/ --- Review request for Plasma. Repository: plasma-workspace Description --- KF5WebKit is only used if drkonqi is built with (optional) KF5XmlRpcClient. Qt5Concurrent is only required for tests. Diffs - CMakeLists.txt 4bfa2e93abfc6f8087693c363e5982fa862cf0fa drkonqi/CMakeLists.txt 8224900e633c18f57ac3fbc7e5a77a8f5a34edb0 Diff: https://git.reviewboard.kde.org/r/118900/diff/ Testing --- Inspected source, builds, tests pass. Thanks, Michael Palimaka ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118900: Improve dependencies.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118900/#review60808 --- CMakeLists.txt https://git.reviewboard.kde.org/r/118900/#comment42378 If you want these to be optional, you can pass them in OPTIONAL_COMPONENTS, from the top find_package. - Aleix Pol Gonzalez On June 23, 2014, 3:07 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118900/ --- (Updated June 23, 2014, 3:07 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- KF5WebKit is only used if drkonqi is built with (optional) KF5XmlRpcClient. Qt5Concurrent is only required for tests. Diffs - CMakeLists.txt 4bfa2e93abfc6f8087693c363e5982fa862cf0fa drkonqi/CMakeLists.txt 8224900e633c18f57ac3fbc7e5a77a8f5a34edb0 Diff: https://git.reviewboard.kde.org/r/118900/diff/ Testing --- Inspected source, builds, tests pass. Thanks, Michael Palimaka ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5: Roadmap post 5.0
I think that plasma releases can follow KF5, we could get at least 5.0.1 in August 15th and 5.0.2 in September 15th. About Plasma 5.1, did we agree on a 3-month schedule? +1 to that. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118898: KGamma: Apply user setting at login/startup
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118898/#review60809
---
kcmkgamma/init_kgamma.cpp
https://git.reviewboard.kde.org/r/118898/#comment42380
please use a copyright header as in
http://techbase.kde.org/Policies/Licensing_Policy#GPL_Header
kcmkgamma/init_kgamma.cpp
https://git.reviewboard.kde.org/r/118898/#comment42381
why delete config? I would just use a KSharedConfig::openConfig
- Martin Gräßlin
On June 23, 2014, 3:06 p.m., Wolfgang Bauer wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118898/
---
(Updated June 23, 2014, 3:06 p.m.)
Review request for kde-workspace, Plasma and Marcel Wiesweg.
Bugs: 218668
http://bugs.kde.org/show_bug.cgi?id=218668
Repository: kgamma
Description
---
KGamma's saved user settings are not applied on startup/login. The user has
to enter the KCM to apply them.
This makes it rather useless, as not even saving the settings system-wide
really works any more. (this requires an xorg.conf which normally doesn't
exist nowadays)
This patch factors out the function init_kgamma() into its own source file
(init_kgamma.cpp), adds a small executable (applykgammasettings) that just
applies those settings by calling that function, and installs
applykgammasettings.desktop to ${AUTOSTART_INSTALL_DIR} that runs
applykgammasettings on login.
PS: As there seems to be no kgamma group and this is desktop-related, I
decided to add the kde-workspace and plasma groups for review. I hope that's
ok... ;)
Diffs
-
kcmkgamma/CMakeLists.txt 3980023
kcmkgamma/applykgammasettings.cpp PRE-CREATION
kcmkgamma/applykgammasettings.desktop PRE-CREATION
kcmkgamma/init_kgamma.cpp PRE-CREATION
kcmkgamma/kgamma.cpp 890ba99
Diff: https://git.reviewboard.kde.org/r/118898/diff/
Testing
---
Set a gamma value in the KGamma KCM, logout/login (or reboot), Gamma value
gets set correctly.
If there's no kgammarc file (or it contains no actual gamma settings), the
Gamma value is not changed. It stays at what is configured for X (or its
default).
Thanks,
Wolfgang Bauer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5: Roadmap post 5.0
I think that plasma releases can follow KF5, we could get at least 5.0.1 in August 15th and 5.0.2 in September 15th. As downstream, I would very much appreciate monthly bug fix releases :) Cheers Rohan Garg ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118900: Improve dependencies.
On June 23, 2014, 3:10 p.m., Aleix Pol Gonzalez wrote: CMakeLists.txt, line 28 https://git.reviewboard.kde.org/r/118900/diff/1/?file=284116#file284116line28 If you want these to be optional, you can pass them in OPTIONAL_COMPONENTS, from the top find_package. It looks like the REQUIRED statement takes precedence over any subsequent OPTIONAL_COMPONENTS; it's still treated as required. - Michael --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118900/#review60808 --- On June 23, 2014, 3:07 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118900/ --- (Updated June 23, 2014, 3:07 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- KF5WebKit is only used if drkonqi is built with (optional) KF5XmlRpcClient. Qt5Concurrent is only required for tests. Diffs - CMakeLists.txt 4bfa2e93abfc6f8087693c363e5982fa862cf0fa drkonqi/CMakeLists.txt 8224900e633c18f57ac3fbc7e5a77a8f5a34edb0 Diff: https://git.reviewboard.kde.org/r/118900/diff/ Testing --- Inspected source, builds, tests pass. Thanks, Michael Palimaka ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5: Roadmap post 5.0
On Monday 23 June 2014 16:56:55 Marco Martin wrote: On Monday 23 June 2014, Rohan Garg wrote: Hi everyone I was wondering, has there been any discussions on whether or not bug fix releases for Plasma 5 will be provided after the 5.0 release? Or will users simply have to wait for the next 5.1 release to get bug fixes? There also doesn't seem to be any indication of what the time frame will be between Plasma 5 releases ( I was told 3 months by some people, this doesn't seem to be written down in a wiki page). Would be awesome if someone could indicate what the roadmap is after the Plasma 5.0 release :) I assumed there would have been monthly bugfix releases as in 4.x? +1 on monthly bug fixes. Concerning feature release: for KWin I would like to get to a six week schedule (for Wayland porting) and a synced with bug fixes release together with plasma. For Plasma I could imagine anything between 3 months and 6 months. 3 months might be a good idea to bring important features back as soon as possible. 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: Plasma 5: Roadmap post 5.0
On Monday, June 23, 2014 17:27:50 Martin Graesslin wrote: On Monday 23 June 2014 16:56:55 Marco Martin wrote: On Monday 23 June 2014, Rohan Garg wrote: Hi everyone I was wondering, has there been any discussions on whether or not bug fix releases for Plasma 5 will be provided after the 5.0 release? Or will users simply have to wait for the next 5.1 release to get bug fixes? There also doesn't seem to be any indication of what the time frame will be between Plasma 5 releases ( I was told 3 months by some people, this doesn't seem to be written down in a wiki page). Would be awesome if someone could indicate what the roadmap is after the Plasma 5.0 release I assumed there would have been monthly bugfix releases as in 4.x? +1 on monthly bug fixes. Concerning feature release: for KWin I would like to get to a six week schedule (for Wayland porting) and a synced with bug fixes release together with plasma. For Plasma I could imagine anything between 3 months and 6 months. 3 months might be a good idea to bring important features back as soon as possible. Sounds sensible to me, as well. -- 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: Plasma 5: Roadmap post 5.0
I assumed there would have been monthly bugfix releases as in 4.x? frameworks (so plasma-framework as well) would have if i understood correctly montly releases (with minimal feature additions and bugfixes) the workspace part I think could have a multiple of that? There are two questions here: - release schedule in general - release schedule of 5.0 For the former, I think we'll need to differentiate string-freeze feature- releases and non-string-freeze feature-releases so that the i18n teams can keep up. As for 5.0, I'd really love to see no bug-fix releases, with the message being 'this is not for general population, not for production systems'. Cheerio, Ivan KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/ gpg key id: 850B6F76, keyserver.pgp.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5: Roadmap post 5.0
As for 5.0, I'd really love to see no bug-fix releases, with the message being 'this is not for general population, not for production systems'. If we did that if someone had a fatal crash they wouldn't be able to contribute to testing for 3 months, which would be a shame. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5: Roadmap post 5.0
On Mon, Jun 23, 2014 at 5:54 PM, Ivan Čukić ivan.cu...@kde.org wrote: I assumed there would have been monthly bugfix releases as in 4.x? frameworks (so plasma-framework as well) would have if i understood correctly montly releases (with minimal feature additions and bugfixes) the workspace part I think could have a multiple of that? There are two questions here: - release schedule in general - release schedule of 5.0 For the former, I think we'll need to differentiate string-freeze feature- releases and non-string-freeze feature-releases so that the i18n teams can keep up. As for 5.0, I'd really love to see no bug-fix releases, with the message being 'this is not for general population, not for production systems'. Cheerio, Ivan I thought we agreed that this message doesn't work and we want people to trust our release as much as possible. One thing that is very important is to warn users that newer Qt versions might fix their workflows. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5: Roadmap post 5.0
On Monday 23 June 2014, Aleix Pol wrote: Cheerio, Ivan I thought we agreed that this message doesn't work and we want people to trust our release as much as possible. One thing that is very important is to warn users that newer Qt versions might fix their workflows. I still think this message is absolutely necessary. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5: Roadmap post 5.0
I thought we agreed that this message doesn't work and we want people to trust our release as much as possible. One thing that is very important is to warn users that newer Qt versions might fix their workflows. and newer mesa versions. Aleix ___ 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: Plasma 5: Roadmap post 5.0
David Edmundson wrote: If we did that if someone had a fatal crash they wouldn't be able to contribute to testing for 3 months, which would be a shame. Good point. Though, those do not need to be bugfix-only releases then. But ok. Aleix Pol wrote: I thought we agreed that this message doesn't work and we want people to trust our release as much as possible. One thing that is very important is to warn users that newer Qt versions might fix their workflows. Well, it might be my pessimism, but I don't want us to repeat the history with this one. Is Plasma 5 really ready for a day-to-day replacement of 4.x for an average user? Are the distributions up to the task this time? trust our release is what we did before, and it backfired. Hugely. Cheerio, Ivan KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/ gpg key id: 850B6F76, keyserver.pgp.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5: Roadmap post 5.0
Well, it might be my pessimism, but I don't want us to repeat the history with this one. Is Plasma 5 really ready for a day-to-day replacement of 4.x for an average user? Are the distributions up to the task this time? trust our release is what we did before, and it backfired. Hugely. We're better. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5: Roadmap post 5.0
On Mon, Jun 23, 2014 at 6:13 PM, Ivan Čukić ivan.cu...@kde.org wrote: David Edmundson wrote: If we did that if someone had a fatal crash they wouldn't be able to contribute to testing for 3 months, which would be a shame. Good point. Though, those do not need to be bugfix-only releases then. But ok. Aleix Pol wrote: I thought we agreed that this message doesn't work and we want people to trust our release as much as possible. One thing that is very important is to warn users that newer Qt versions might fix their workflows. Well, it might be my pessimism, but I don't want us to repeat the history with this one. Is Plasma 5 really ready for a day-to-day replacement of 4.x for an average user? Are the distributions up to the task this time? trust our release is what we did before, and it backfired. Hugely. Cheerio, Ivan I don't really think the problem is the distributions there. Actually if 5.1 is going to be any stabler, it will be because of the testing we get by the users. If you look at the bug tracker, there's not that much bug reports open that will render your life miserable. We want distros to package it, we just don't want people using 5.0 when 5.1 is released, it's not very hard to understand that 5.1 will be stabler. Aleix PS: The 4.x argument is becoming KDE's own Godwin's Law. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5: Roadmap post 5.0
On Monday 23 June 2014, Aleix Pol wrote: I don't really think the problem is the distributions there. Actually if 5.1 is going to be any stabler, it will be because of the testing we get by the users. If you look at the bug tracker, there's not that much bug reports open that will render your life miserable. We want distros to package it, we just don't want people using 5.0 when 5.1 is released, it's not very hard to understand that 5.1 will be stabler. It's a bit different, we want distros to package it, but not them to make it the default desktop, at least for a while (and that was the main problem of 4.0) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5: Roadmap post 5.0
Aleix Pol wrote: reports open that will render your life miserable. And this is the sentence for which I think we need the message. We have no bugs that will make your life miserable. :) We want distros to package it, we just don't want people using 5.0 when 5.1 is released, it's not very hard to understand that 5.1 will be stabler. Agreed with all. The distributions should package it. It should be an option for the people who want to install it and experiment with it. It should not be the default at this point in time. And yes, this *is* a part of the 'distribution problem' we had (apart from screwed up installations by a few of those), and a part of the message to the public. PS: The 4.x argument is becoming KDE's own Godwin's Law. I haven't referred to 4.x as the problem. It is just easily recognizable. :P David Edmundson wrote: We're better. Yes... we thought the same back in the day. We all used Plasma in our day-to- day workflow for everything, not only for kde development, and it was perfectly stable (for me and I guess everybody else in Plasma team) long before the release. Cheerio, Ivan KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/ gpg key id: 850B6F76, keyserver.pgp.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118898: KGamma: Apply user setting at login/startup
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118898/ --- (Updated June 23, 2014, 7:01 p.m.) Review request for kde-workspace, Plasma and Marcel Wiesweg. Changes --- Use kcminit instead of creating a separate executable and starting it via an autostart .desktop file Bugs: 218668 http://bugs.kde.org/show_bug.cgi?id=218668 Repository: kgamma Description (updated) --- KGamma's saved user settings are not applied on startup/login. The user has to enter the KCM to apply them. This makes it rather useless, as not even saving the settings system-wide really works any more. (this requires an xorg.conf which normally doesn't exist nowadays) This patch uses kcminit to apply these settings again on login. Apparently this has been forgotten when moving/porting kgamma to KDE4. PS: As there seems to be no kgamma group and this is desktop-related, I decided to add the kde-workspace and plasma groups for review. I hope that's ok... ;) Diffs (updated) - kcmkgamma/kgamma.cpp 890ba99 kcmkgamma/kgamma.desktop 3d87513 Diff: https://git.reviewboard.kde.org/r/118898/diff/ Testing --- Set a gamma value in the KGamma KCM, logout/login (or reboot), Gamma value gets set correctly. If there's no kgammarc file (or it contains no actual gamma settings), the Gamma value is not changed. It stays at what is configured for X (or its default). Thanks, Wolfgang Bauer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118898: KGamma: Apply user setting at login/startup
On June 23, 2014, 3:21 p.m., Sebastian Kügler wrote: I think there's a couple of problems with this approach: - This slows down startup for everybody, not just those who changed the setting. I'm not super-familiar with this, but isn't kcminit for this use-case? - Changing startup procedure this late in the game (Plasma 4.x has been on LTS for almost a year, feature frozen for much longer) - This particular KCM is dead in Plasma 5 (not really a reason to not fix it in 4.x, but the feature will be lost again Again, not super-privvy of the whole picture, but isn't color correction the correct solution here? Wolfgang Bauer wrote: applykgammasettings is only called on login for people actually installing kgamma (it's a separate tarball and separate package on openSUSE at least). There is no change to plasma's own startup procedure, and no change at all when kgamma is not installed. kcminit is actually used by kgamma right now (it calls the same function), but that only applies when the user enters the KCM. But the point of this setting is to be applied automatically on login/startup. Wolfgang Bauer wrote: PS: Sorry, kcminit does seem to be able to apply settings on login. I seem to have confused it with something else... I will have a look at this then. Thanks for the hint! Kcminit works just fine. I just had to add some stuff to the .desktop file and rename/export the init function, so the patch is much simpler now. Apparently it worked the way it is in KDE3 and has been forgotten to be changed when porting/moving kgamma to KDE4? - Wolfgang --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118898/#review60795 --- On June 23, 2014, 7:01 p.m., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118898/ --- (Updated June 23, 2014, 7:01 p.m.) Review request for kde-workspace, Plasma and Marcel Wiesweg. Bugs: 218668 http://bugs.kde.org/show_bug.cgi?id=218668 Repository: kgamma Description --- KGamma's saved user settings are not applied on startup/login. The user has to enter the KCM to apply them. This makes it rather useless, as not even saving the settings system-wide really works any more. (this requires an xorg.conf which normally doesn't exist nowadays) This patch uses kcminit to apply these settings again on login. Apparently this has been forgotten when moving/porting kgamma to KDE4. PS: As there seems to be no kgamma group and this is desktop-related, I decided to add the kde-workspace and plasma groups for review. I hope that's ok... ;) Diffs - kcmkgamma/kgamma.cpp 890ba99 kcmkgamma/kgamma.desktop 3d87513 Diff: https://git.reviewboard.kde.org/r/118898/diff/ Testing --- Set a gamma value in the KGamma KCM, logout/login (or reboot), Gamma value gets set correctly. If there's no kgammarc file (or it contains no actual gamma settings), the Gamma value is not changed. It stays at what is configured for X (or its default). Thanks, Wolfgang Bauer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118898: KGamma: Apply user setting at login/startup
On June 23, 2014, 5:13 p.m., Martin Gräßlin wrote: kcmkgamma/init_kgamma.cpp, lines 1-8 https://git.reviewboard.kde.org/r/118898/diff/1/?file=283881#file283881line1 please use a copyright header as in http://techbase.kde.org/Policies/Licensing_Policy#GPL_Header I just copied the license from the original source file (kgamma.cpp). But the new source file (init_kgamma.cpp) doesn't exist any more in the updated patch. On June 23, 2014, 5:13 p.m., Martin Gräßlin wrote: kcmkgamma/init_kgamma.cpp, line 39 https://git.reviewboard.kde.org/r/118898/diff/1/?file=283881#file283881line39 why delete config? I would just use a KSharedConfig::openConfig I just copy/pasted the original code. That is reverted as well now. Should I change this anyway? But that's not really related to this bugfix, I'd say... - Wolfgang --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118898/#review60809 --- On June 23, 2014, 7:01 p.m., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118898/ --- (Updated June 23, 2014, 7:01 p.m.) Review request for kde-workspace, Plasma and Marcel Wiesweg. Bugs: 218668 http://bugs.kde.org/show_bug.cgi?id=218668 Repository: kgamma Description --- KGamma's saved user settings are not applied on startup/login. The user has to enter the KCM to apply them. This makes it rather useless, as not even saving the settings system-wide really works any more. (this requires an xorg.conf which normally doesn't exist nowadays) This patch uses kcminit to apply these settings again on login. Apparently this has been forgotten when moving/porting kgamma to KDE4. PS: As there seems to be no kgamma group and this is desktop-related, I decided to add the kde-workspace and plasma groups for review. I hope that's ok... ;) Diffs - kcmkgamma/kgamma.cpp 890ba99 kcmkgamma/kgamma.desktop 3d87513 Diff: https://git.reviewboard.kde.org/r/118898/diff/ Testing --- Set a gamma value in the KGamma KCM, logout/login (or reboot), Gamma value gets set correctly. If there's no kgammarc file (or it contains no actual gamma settings), the Gamma value is not changed. It stays at what is configured for X (or its default). Thanks, Wolfgang Bauer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118898: KGamma: Apply user setting at login/startup
On June 23, 2014, 5:13 p.m., Martin Gräßlin wrote: kcmkgamma/init_kgamma.cpp, line 39 https://git.reviewboard.kde.org/r/118898/diff/1/?file=283881#file283881line39 why delete config? I would just use a KSharedConfig::openConfig Wolfgang Bauer wrote: I just copy/pasted the original code. That is reverted as well now. Should I change this anyway? But that's not really related to this bugfix, I'd say... But that's not really related to this bugfix, I'd say... no, it isn't. It just highlights how bad reviewboard is for copied content - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118898/#review60809 --- On June 23, 2014, 7:01 p.m., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118898/ --- (Updated June 23, 2014, 7:01 p.m.) Review request for kde-workspace, Plasma and Marcel Wiesweg. Bugs: 218668 http://bugs.kde.org/show_bug.cgi?id=218668 Repository: kgamma Description --- KGamma's saved user settings are not applied on startup/login. The user has to enter the KCM to apply them. This makes it rather useless, as not even saving the settings system-wide really works any more. (this requires an xorg.conf which normally doesn't exist nowadays) This patch uses kcminit to apply these settings again on login. Apparently this has been forgotten when moving/porting kgamma to KDE4. PS: As there seems to be no kgamma group and this is desktop-related, I decided to add the kde-workspace and plasma groups for review. I hope that's ok... ;) Diffs - kcmkgamma/kgamma.cpp 890ba99 kcmkgamma/kgamma.desktop 3d87513 Diff: https://git.reviewboard.kde.org/r/118898/diff/ Testing --- Set a gamma value in the KGamma KCM, logout/login (or reboot), Gamma value gets set correctly. If there's no kgammarc file (or it contains no actual gamma settings), the Gamma value is not changed. It stays at what is configured for X (or its default). Thanks, Wolfgang Bauer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 118906: Fix dialog's check for isTooltip
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118906/ --- Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Fix dialog's check for isTooltip Qt::Tooltip is a mix of other flags (0x0001101) using a simple is not correct as any Window will have (0x001) set and the bitwise operation will return a non-zero value Diffs - src/plasmaquick/dialog.cpp ab56ccc Diff: https://git.reviewboard.kde.org/r/118906/diff/ Testing --- Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118886: Add paintedWidth and paintedHeight properties to WindowThumbnail
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118886/ --- (Updated June 23, 2014, 5:39 p.m.) Review request for Plasma and Martin Gräßlin. Changes --- Use QSizeF and a single notify signal Repository: plasma-framework Description --- This adds paintedWidth and paintedHeight properties to PlasmaCore.WindowThumbnail which tells as how large the thumbnail, which is scaled keeping aspect ratio, actually is, similar to what QML Image does. This is will eventually allow the taskmanager to size its tooltips more appropriately. (Is it better to store m_paintedWidth and m_paintedHeight separately, or is the QSize thing I used ok?) Diffs (updated) - src/declarativeimports/core/windowthumbnail.h 14fc44a src/declarativeimports/core/windowthumbnail.cpp b10f030 Diff: https://git.reviewboard.kde.org/r/118886/diff/ Testing --- Works, reports the actual size Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118886: Add paintedWidth and paintedHeight properties to WindowThumbnail
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118886/#review60827 --- Ship it! Ship It! - David Edmundson On June 23, 2014, 5:39 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118886/ --- (Updated June 23, 2014, 5:39 p.m.) Review request for Plasma and Martin Gräßlin. Repository: plasma-framework Description --- This adds paintedWidth and paintedHeight properties to PlasmaCore.WindowThumbnail which tells as how large the thumbnail, which is scaled keeping aspect ratio, actually is, similar to what QML Image does. This is will eventually allow the taskmanager to size its tooltips more appropriately. (Is it better to store m_paintedWidth and m_paintedHeight separately, or is the QSize thing I used ok?) Diffs - src/declarativeimports/core/windowthumbnail.h 14fc44a src/declarativeimports/core/windowthumbnail.cpp b10f030 Diff: https://git.reviewboard.kde.org/r/118886/diff/ Testing --- Works, reports the actual size Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118898: KGamma: Apply user setting at login/startup
On June 23, 2014, 5:13 p.m., Martin Gräßlin wrote: kcmkgamma/init_kgamma.cpp, line 39 https://git.reviewboard.kde.org/r/118898/diff/1/?file=283881#file283881line39 why delete config? I would just use a KSharedConfig::openConfig Wolfgang Bauer wrote: I just copy/pasted the original code. That is reverted as well now. Should I change this anyway? But that's not really related to this bugfix, I'd say... Martin Gräßlin wrote: But that's not really related to this bugfix, I'd say... no, it isn't. It just highlights how bad reviewboard is for copied content OK. I dropped this issue then. - Wolfgang --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118898/#review60809 --- On June 23, 2014, 7:01 p.m., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118898/ --- (Updated June 23, 2014, 7:01 p.m.) Review request for kde-workspace, Plasma and Marcel Wiesweg. Bugs: 218668 http://bugs.kde.org/show_bug.cgi?id=218668 Repository: kgamma Description --- KGamma's saved user settings are not applied on startup/login. The user has to enter the KCM to apply them. This makes it rather useless, as not even saving the settings system-wide really works any more. (this requires an xorg.conf which normally doesn't exist nowadays) This patch uses kcminit to apply these settings again on login. Apparently this has been forgotten when moving/porting kgamma to KDE4. PS: As there seems to be no kgamma group and this is desktop-related, I decided to add the kde-workspace and plasma groups for review. I hope that's ok... ;) Diffs - kcmkgamma/kgamma.cpp 890ba99 kcmkgamma/kgamma.desktop 3d87513 Diff: https://git.reviewboard.kde.org/r/118898/diff/ Testing --- Set a gamma value in the KGamma KCM, logout/login (or reboot), Gamma value gets set correctly. If there's no kgammarc file (or it contains no actual gamma settings), the Gamma value is not changed. It stays at what is configured for X (or its default). Thanks, Wolfgang Bauer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118886: Add paintedWidth and paintedHeight properties to WindowThumbnail
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118886/ --- (Updated June 23, 2014, 5:59 p.m.) Status -- This change has been marked as submitted. Review request for Plasma and Martin Gräßlin. Repository: plasma-framework Description --- This adds paintedWidth and paintedHeight properties to PlasmaCore.WindowThumbnail which tells as how large the thumbnail, which is scaled keeping aspect ratio, actually is, similar to what QML Image does. This is will eventually allow the taskmanager to size its tooltips more appropriately. (Is it better to store m_paintedWidth and m_paintedHeight separately, or is the QSize thing I used ok?) Diffs - src/declarativeimports/core/windowthumbnail.h 14fc44a src/declarativeimports/core/windowthumbnail.cpp b10f030 Diff: https://git.reviewboard.kde.org/r/118886/diff/ Testing --- Works, reports the actual size Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118886: Add paintedWidth and paintedHeight properties to WindowThumbnail
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118886/#review60829 --- This review has been submitted with commit 347e073df39429bf1be804a2c3d32aad09b7f0ab by Kai Uwe Broulik to branch master. - Commit Hook On June 23, 2014, 5:39 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118886/ --- (Updated June 23, 2014, 5:39 p.m.) Review request for Plasma and Martin Gräßlin. Repository: plasma-framework Description --- This adds paintedWidth and paintedHeight properties to PlasmaCore.WindowThumbnail which tells as how large the thumbnail, which is scaled keeping aspect ratio, actually is, similar to what QML Image does. This is will eventually allow the taskmanager to size its tooltips more appropriately. (Is it better to store m_paintedWidth and m_paintedHeight separately, or is the QSize thing I used ok?) Diffs - src/declarativeimports/core/windowthumbnail.h 14fc44a src/declarativeimports/core/windowthumbnail.cpp b10f030 Diff: https://git.reviewboard.kde.org/r/118886/diff/ Testing --- Works, reports the actual size Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118891: Folder view icon text background
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118891/#review60832 --- Ship it! Thanks for addressing those issues. I'd say let's commit it now. I'm still not sure that it might not be too heavy visually, but to find out we need broader feedback I think. So let's put it in and monitor responses :). - Eike Hein On June 23, 2014, 2:19 p.m., Andrew Lake wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118891/ --- (Updated June 23, 2014, 2:19 p.m.) Review request for Plasma. Bugs: 335070 https://bugs.kde.org/show_bug.cgi?id=335070 Repository: plasma-desktop Description --- Addresses lack of contrast of folderview containment icon text on certain backgrounds: Bug 335070 The color of the text background is just the complement of the icon label text with a 0.6 opacity applied. Diffs - containments/folder/package/contents/ui/ConfigIcons.qml 9f57900 containments/folder/package/contents/ui/ItemDelegate.qml 4f95f04 Diff: https://git.reviewboard.kde.org/r/118891/diff/ Testing --- File Attachments with latest changes showing it with selection background https://git.reviewboard.kde.org/media/uploaded/files/2014/06/23/58f07e42-08b4-480a-9c05-40195514edbf__icontextbackground2.png Thanks, Andrew Lake ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118891: Folder view icon text background
On June 23, 2014, 6:09 p.m., Eike Hein wrote: Thanks for addressing those issues. I'd say let's commit it now. I'm still not sure that it might not be too heavy visually, but to find out we need broader feedback I think. So let's put it in and monitor responses :). I think visually is just fine, at least, a solid rectangle to me will always feel lighter than any blur/shadow stuff - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118891/#review60832 --- On June 23, 2014, 2:19 p.m., Andrew Lake wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118891/ --- (Updated June 23, 2014, 2:19 p.m.) Review request for Plasma. Bugs: 335070 https://bugs.kde.org/show_bug.cgi?id=335070 Repository: plasma-desktop Description --- Addresses lack of contrast of folderview containment icon text on certain backgrounds: Bug 335070 The color of the text background is just the complement of the icon label text with a 0.6 opacity applied. Diffs - containments/folder/package/contents/ui/ConfigIcons.qml 9f57900 containments/folder/package/contents/ui/ItemDelegate.qml 4f95f04 Diff: https://git.reviewboard.kde.org/r/118891/diff/ Testing --- File Attachments with latest changes showing it with selection background https://git.reviewboard.kde.org/media/uploaded/files/2014/06/23/58f07e42-08b4-480a-9c05-40195514edbf__icontextbackground2.png Thanks, Andrew Lake ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5: Roadmap post 5.0
In data lunedì 23 giugno 2014 18:29:21, Marco Martin ha scritto: It's a bit different, we want distros to package it, but not them to make it the default desktop, at least for a while (and that was the main problem of 4.0) Speaking for openSUSE: P5 will not be default for the next upcoming version (13.2). -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 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: Re: Re: which product to use for bugreport?
Martin GräßlinOn Friday 20 June 2014 10:17:50 wrote: On Friday 20 June 2014 11:17:41 Damian Ivanov wrote: Given the high regression potential (windows which used to be included aren't shown any more - yes the one user's bug is the other user's feature) I would highly recommend to not change the behavior in 4.11. Sure. I notice because for example xfce desktop and panel do not set SkipTaskbar, they rely on the taskbar also omitting depending on the type. (Though I guess no one out there uses Plasma panel and xfce desktop or some weird combination like that in conjunction) For KF5 and Plasma Workspace I would suggest to adjust KWindowSystem framework to imply SkipTaskbar and SkipPager for some window types. If I see it correctly only Dialog or Normal should be shown in taskbar and pager. The proper fix would be the taskbar also omitting depending on the type as some applications out there will rely on only setting the type no, if KWindowSystem implies SkipTaskbar if the window type is e.g. Splash the taskbar does not need any adjustments. Review Request for this change created: https://git.reviewboard.kde.org/r/118909/ 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 118908: Adjust taskmanager tooltip size to window thumbnail
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118908/#review60837 --- This causes the tooltips to no longer be uniform in size, which causes extra visual busyness when moving between tasks. Tooltip resize performance also isn't stellar right now, and size changes are especially deadly for right-aligned tooltips (i.e. vertical panel on the right screen edge), causing odd dancing. So conceptually it's a -1 for me. Additionally on the first screenshot the left/right margins also aren't uniform for icon and text label. - Eike Hein On June 23, 2014, 6:39 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118908/ --- (Updated June 23, 2014, 6:39 p.m.) Review request for Plasma and Eike Hein. Repository: plasma-desktop Description --- Now that we can know the exact geometry of the window thumbnail the tooltip is adjusted to respect that. Diffs - applets/taskmanager/package/contents/ui/ToolTipDelegate.qml ca5f95b Diff: https://git.reviewboard.kde.org/r/118908/diff/ Testing --- Tested with single window, grouped window as well as minimized window (icon). Looks fine although there still is excess padding left and right of the thumbnail I don't know where that comes. Needs a bit of spacing adjustments as well. File Attachments Narrow window https://git.reviewboard.kde.org/media/uploaded/files/2014/06/23/7773a10d-7ee9-4a06-b5b4-bd03b7ce8566__taskmanagertooltip.png Wide window https://git.reviewboard.kde.org/media/uploaded/files/2014/06/23/8e29f459-af59-43c1-b171-8b7aacd237af__taskmanagertooltip1.png Grouped https://git.reviewboard.kde.org/media/uploaded/files/2014/06/23/f1df0096-271c-4229-8466-8374ef56492a__taskmanagertooltip2.png Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118908: Adjust taskmanager tooltip size to window thumbnail
On June 23, 2014, 7:16 p.m., Eike Hein wrote: This causes the tooltips to no longer be uniform in size, which causes extra visual busyness when moving between tasks. Tooltip resize performance also isn't stellar right now, and size changes are especially deadly for right-aligned tooltips (i.e. vertical panel on the right screen edge), causing odd dancing. So conceptually it's a -1 for me. Additionally on the first screenshot the left/right margins also aren't uniform for icon and text label. True, didn't test with vertical panel :/ What a pity. - Kai Uwe --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118908/#review60837 --- On June 23, 2014, 6:39 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118908/ --- (Updated June 23, 2014, 6:39 p.m.) Review request for Plasma and Eike Hein. Repository: plasma-desktop Description --- Now that we can know the exact geometry of the window thumbnail the tooltip is adjusted to respect that. Diffs - applets/taskmanager/package/contents/ui/ToolTipDelegate.qml ca5f95b Diff: https://git.reviewboard.kde.org/r/118908/diff/ Testing --- Tested with single window, grouped window as well as minimized window (icon). Looks fine although there still is excess padding left and right of the thumbnail I don't know where that comes. Needs a bit of spacing adjustments as well. File Attachments Narrow window https://git.reviewboard.kde.org/media/uploaded/files/2014/06/23/7773a10d-7ee9-4a06-b5b4-bd03b7ce8566__taskmanagertooltip.png Wide window https://git.reviewboard.kde.org/media/uploaded/files/2014/06/23/8e29f459-af59-43c1-b171-8b7aacd237af__taskmanagertooltip1.png Grouped https://git.reviewboard.kde.org/media/uploaded/files/2014/06/23/f1df0096-271c-4229-8466-8374ef56492a__taskmanagertooltip2.png Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
