Re: Review Request 119092: Add sudo to the make install command in the README file
On July 3, 2014, 5:27 a.m., Martin Gräßlin wrote: this is a very bad suggestion. Given the README it will install into /usr in case of distro users. Don't do that, this can break installs. Adjust the cmake command to install to a local prefix. Okay, but what should/could the local prefix be ? - R.Harish --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119092/#review61519 --- On July 2, 2014, 10:53 p.m., R.Harish Navnit wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119092/ --- (Updated July 2, 2014, 10:53 p.m.) Review request for Plasma, Shantanu Tushar and Sinny Kumari. Repository: plasma-mediacenter Description --- Giving the command make install without sudo doesn't work. Has this gone un-noticed or is this how it is intended in the README ? Diffs - README 6f46cdf Diff: https://git.reviewboard.kde.org/r/119092/diff/ Testing --- Ran sudo make install and build succeeds. Thanks, R.Harish Navnit ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: new systemsettings categorization landed
Hi Vishesh all, I agree that it makes more sense to place it with the desktop stuff. Maybe we had application = file in mind? The only argument against desktop behavior is that this topic gets somewhat bulky. And I'm not sure that users will associate all the modules including file search with the caption. For balancing we should consider to split the topic perhaps like this Application Features * Accessibility * File Search * Activities Desktop Behavior * Global Workspace Options * Desktop Effects * Screen Edges * Virtual Desktops What do you think? Cheers, Heiko. Am 01.07.2014 17:09:31, schrieb Vishesh Handa: Hey guys. I don't understand why File Search (formerly Desktop Search) should go under Applications. Current application which can be used to search for files - Dolphin. Current workspace stuff which can be used to search - KRunner, Milou, Kickoff and Kicker. It seems rather odd for it to be under applications. Could someone please elaborate on the rationale behind it? I've tried reading the forums, but I haven't really found much. On Tue, Jul 1, 2014 at 1:11 PM, Sebastian Kügler se...@kde.org wrote: Hey, So as the subject suggests, I've just landed the new categorization for systemsettings. Changes are all over the place, so if you just update single repositories, your systemsettings will be quite empty. If you're re-running kdesrc-build, you'll find a mess with old and new categorized intermixed (is intermixed a word? If not, we should make it one.) A clean installation will give you the desired results, but you can also just delete all categories before running kdesrc-build: rm `kf5-config --prefix`/share/kservices5/settings* (Use at your own risk.) After that, running kde-src build should get you into the new systemsettings state. If you notice anything strange, please refer to this thread and discuss your issues there: http://forum.kde.org/viewtopic.php?f=285t=121053start=60 If you notice that I did something wrong when turning the huge graphic into changes to .desktop files, please let me know, and I'll fix it. Special thanks goes to our interaction and visual designers who did the research for this new categorization. I personally think it's a big improvement. Going forward, there's a lot of work ahead, and this is only the beginning. We need to overhaul KCMs, we need to simplify settings, modernize UIs, and we will likely also introduce a new shell (which we can do gradually with the different view plugins in systemsettings). For an experiment, try the sebas/quick branch in systemsettings. This new categorization is only the first step, and we decided to push this into 5.0, since it's a user-visible change, and we can keep things rather more stable from here on out. 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 -- Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: new systemsettings categorization landed
Heiko Tietze wrote: Hi Vishesh all, I agree that it makes more sense to place it with the desktop stuff. Maybe we had application = file in mind? The only argument against desktop behavior is that this topic gets somewhat bulky. And I'm not sure that users will associate all the modules including file search with the caption. For balancing we should consider to split the topic perhaps like this Application Features * Accessibility * File Search * Activities Desktop Behavior * Global Workspace Options * Desktop Effects * Screen Edges * Virtual Desktops What do you think? Maybe we are too stuck with the general category labels. You can always change that to one that is more inclusive and less specific. I would suggest Desktop Settings, rather than Behavior, because that word seems to exclude other kcms that could well fit the category. Cheers, Heiko. Am 01.07.2014 17:09:31, schrieb Vishesh Handa: Hey guys. I don't understand why File Search (formerly Desktop Search) should go under Applications. Current application which can be used to search for files - Dolphin. Current workspace stuff which can be used to search - KRunner, Milou, Kickoff and Kicker. It seems rather odd for it to be under applications. Could someone please elaborate on the rationale behind it? I've tried reading the forums, but I haven't really found much. On Tue, Jul 1, 2014 at 1:11 PM, Sebastian Kügler se...@kde.org mailto:se...@kde.org wrote: Hey, So as the subject suggests, I've just landed the new categorization for systemsettings. Changes are all over the place, so if you just update single repositories, your systemsettings will be quite empty. If you're re-running kdesrc-build, you'll find a mess with old and new categorized intermixed (is intermixed a word? If not, we should make it one.) A clean installation will give you the desired results, but you can also just delete all categories before running kdesrc-build: rm `kf5-config --prefix`/share/kservices5/settings* (Use at your own risk.) After that, running kde-src build should get you into the new systemsettings state. If you notice anything strange, please refer to this thread and discuss your issues there: http://forum.kde.org/viewtopic.php?f=285t=121053start=60 http://forum.kde.org/viewtopic.php?f=285t=121053start=60 If you notice that I did something wrong when turning the huge graphic into changes to .desktop files, please let me know, and I'll fix it. Special thanks goes to our interaction and visual designers who did the research for this new categorization. I personally think it's a big improvement. Going forward, there's a lot of work ahead, and this is only the beginning. We need to overhaul KCMs, we need to simplify settings, modernize UIs, and we will likely also introduce a new shell (which we can do gradually with the different view plugins in systemsettings). For an experiment, try the sebas/quick branch in systemsettings. This new categorization is only the first step, and we decided to push this into 5.0, since it's a user-visible change, and we can keep things rather more stable from here on out. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org mailto:Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 119103: Startkde: Remove KLOCALE_LANGUAGES
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119103/ --- Review request for Plasma. Repository: plasma-workspace Description --- Startkde: Remove KLOCALE_LANGUAGES KLOCALE_LANGUAGES was used by the kde4 ksplash in order to to know which language to show. This environment variable is no longer used by the qml based ksplash. It makes no sense to have it. Additionally, this means we can stop linking against kdelibs4support. This is important cause kdostartupconfig blocks the rest of the boot sequence. On my system it causes a good 0.3 - 0.4 seconds delay. By no longer linking to kdelibs4support it takes less than 0.1 seconds and no longer shows up in the bootchat logs. Diffs - startkde/kstartupconfig/CMakeLists.txt 6920fe5 startkde/kstartupconfig/kdostartupconfig.cpp d545f4f startkde/startkde.cmake 40e3377 Diff: https://git.reviewboard.kde.org/r/119103/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119103: Startkde: Remove KLOCALE_LANGUAGES
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119103/#review61543 --- Don't we still need to pass the language somehow? or now it will be enough with $LANG? - Aleix Pol Gonzalez On July 3, 2014, 11:25 a.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119103/ --- (Updated July 3, 2014, 11:25 a.m.) Review request for Plasma. Repository: plasma-workspace Description --- Startkde: Remove KLOCALE_LANGUAGES KLOCALE_LANGUAGES was used by the kde4 ksplash in order to to know which language to show. This environment variable is no longer used by the qml based ksplash. It makes no sense to have it. Additionally, this means we can stop linking against kdelibs4support. This is important cause kdostartupconfig blocks the rest of the boot sequence. On my system it causes a good 0.3 - 0.4 seconds delay. By no longer linking to kdelibs4support it takes less than 0.1 seconds and no longer shows up in the bootchat logs. Diffs - startkde/kstartupconfig/CMakeLists.txt 6920fe5 startkde/kstartupconfig/kdostartupconfig.cpp d545f4f startkde/startkde.cmake 40e3377 Diff: https://git.reviewboard.kde.org/r/119103/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119103: Startkde: Remove KLOCALE_LANGUAGES
On July 3, 2014, 11:41 a.m., Aleix Pol Gonzalez wrote: Don't we still need to pass the language somehow? or now it will be enough with $LANG? KLocale languages had a list of languages. The first one being the main one, and others being fallbacks. We no longer seem to support this multiple languages option in QLocale. I'm not familiar with KSplash internals and why we ever needed to pass the languages variable at all. - Vishesh --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119103/#review61543 --- On July 3, 2014, 11:25 a.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119103/ --- (Updated July 3, 2014, 11:25 a.m.) Review request for Plasma. Repository: plasma-workspace Description --- Startkde: Remove KLOCALE_LANGUAGES KLOCALE_LANGUAGES was used by the kde4 ksplash in order to to know which language to show. This environment variable is no longer used by the qml based ksplash. It makes no sense to have it. Additionally, this means we can stop linking against kdelibs4support. This is important cause kdostartupconfig blocks the rest of the boot sequence. On my system it causes a good 0.3 - 0.4 seconds delay. By no longer linking to kdelibs4support it takes less than 0.1 seconds and no longer shows up in the bootchat logs. Diffs - startkde/kstartupconfig/CMakeLists.txt 6920fe5 startkde/kstartupconfig/kdostartupconfig.cpp d545f4f startkde/startkde.cmake 40e3377 Diff: https://git.reviewboard.kde.org/r/119103/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
New repository will be needed for release: wallpapers
Hi all, As discussed, the wallpapers will be distributed in an svn server (so that will need to be released in tarballs and packages as well) it has been created and is http://websvn.kde.org/trunk/KDE/plasma-workspace-wallpapers/ -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Moving parts of kde-baseapps to plasma-workspace
On Tue, Jul 1, 2014 at 6:36 PM, Vishesh Handa m...@vhanda.in wrote: 1. kdepasswd - Contains the KCM for changing the real name and picture. This name is used by kickoff and is prominently displayed. It also contains an app called 'kpasswd' which doesn't really work. Let's move this into plasma-desktop/kcms and get rid of kpasswd. Ping If there are no objections I'll make the move tomorrow. -- Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119103: Startkde: Remove KLOCALE_LANGUAGES
On July 3, 2014, 11:41 a.m., Aleix Pol Gonzalez wrote: Don't we still need to pass the language somehow? or now it will be enough with $LANG? Vishesh Handa wrote: KLocale languages had a list of languages. The first one being the main one, and others being fallbacks. We no longer seem to support this multiple languages option in QLocale. I'm not familiar with KSplash internals and why we ever needed to pass the languages variable at all. We still support it, but it's now the $LANGUAGES variable (which in contrast to $LANG is a list of languages, preferred and fallback). In principle, this patch is fine, I'd go with let's kill KLOCALE_LANG and see what breaks, but on RC-tagging-day, this might not be the most prudent thing to do. I'm also not familiar with KSplash, but with the current design we ship, there's nothing translated there, anyway, so it's not like we're breaking the default setup. - Sebastian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119103/#review61543 --- On July 3, 2014, 11:25 a.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119103/ --- (Updated July 3, 2014, 11:25 a.m.) Review request for Plasma. Repository: plasma-workspace Description --- Startkde: Remove KLOCALE_LANGUAGES KLOCALE_LANGUAGES was used by the kde4 ksplash in order to to know which language to show. This environment variable is no longer used by the qml based ksplash. It makes no sense to have it. Additionally, this means we can stop linking against kdelibs4support. This is important cause kdostartupconfig blocks the rest of the boot sequence. On my system it causes a good 0.3 - 0.4 seconds delay. By no longer linking to kdelibs4support it takes less than 0.1 seconds and no longer shows up in the bootchat logs. Diffs - startkde/kstartupconfig/CMakeLists.txt 6920fe5 startkde/kstartupconfig/kdostartupconfig.cpp d545f4f startkde/startkde.cmake 40e3377 Diff: https://git.reviewboard.kde.org/r/119103/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 119104: Add a Search category under Workspace
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119104/ --- Review request for Plasma. Repository: systemsettings Description --- Maybe this should be going under Personalization? I don't know. We also need a better icon. Using the baloo icon for now. Diffs - categories/CMakeLists.txt 7a9c0ad categories/settings-workspace-search.desktop PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119104/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119103: Startkde: Remove KLOCALE_LANGUAGES
On July 3, 2014, 11:41 a.m., Aleix Pol Gonzalez wrote: Don't we still need to pass the language somehow? or now it will be enough with $LANG? Vishesh Handa wrote: KLocale languages had a list of languages. The first one being the main one, and others being fallbacks. We no longer seem to support this multiple languages option in QLocale. I'm not familiar with KSplash internals and why we ever needed to pass the languages variable at all. Sebastian Kügler wrote: We still support it, but it's now the $LANGUAGES variable (which in contrast to $LANG is a list of languages, preferred and fallback). In principle, this patch is fine, I'd go with let's kill KLOCALE_LANG and see what breaks, but on RC-tagging-day, this might not be the most prudent thing to do. I'm also not familiar with KSplash, but with the current design we ship, there's nothing translated there, anyway, so it's not like we're breaking the default setup. So, I ship this tomorrow after the tagging? - Vishesh --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119103/#review61543 --- On July 3, 2014, 11:25 a.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119103/ --- (Updated July 3, 2014, 11:25 a.m.) Review request for Plasma. Repository: plasma-workspace Description --- Startkde: Remove KLOCALE_LANGUAGES KLOCALE_LANGUAGES was used by the kde4 ksplash in order to to know which language to show. This environment variable is no longer used by the qml based ksplash. It makes no sense to have it. Additionally, this means we can stop linking against kdelibs4support. This is important cause kdostartupconfig blocks the rest of the boot sequence. On my system it causes a good 0.3 - 0.4 seconds delay. By no longer linking to kdelibs4support it takes less than 0.1 seconds and no longer shows up in the bootchat logs. Diffs - startkde/kstartupconfig/CMakeLists.txt 6920fe5 startkde/kstartupconfig/kdostartupconfig.cpp d545f4f startkde/startkde.cmake 40e3377 Diff: https://git.reviewboard.kde.org/r/119103/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119104: Add a Search category under Workspace
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119104/#review61556 --- Can you check with Thomas and Heiko about the location of this new category, or has this been OK'ed by them? categories/settings-workspace-search.desktop https://git.reviewboard.kde.org/r/119104/#comment42850 Wrong icon? - Sebastian Kügler On July 3, 2014, 1:35 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119104/ --- (Updated July 3, 2014, 1:35 p.m.) Review request for Plasma. Repository: systemsettings Description --- Maybe this should be going under Personalization? I don't know. We also need a better icon. Using the baloo icon for now. Diffs - categories/CMakeLists.txt 7a9c0ad categories/settings-workspace-search.desktop PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119104/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119103: Startkde: Remove KLOCALE_LANGUAGES
On July 3, 2014, 12:41 p.m., Aleix Pol Gonzalez wrote: Don't we still need to pass the language somehow? or now it will be enough with $LANG? Vishesh Handa wrote: KLocale languages had a list of languages. The first one being the main one, and others being fallbacks. We no longer seem to support this multiple languages option in QLocale. I'm not familiar with KSplash internals and why we ever needed to pass the languages variable at all. Sebastian Kügler wrote: We still support it, but it's now the $LANGUAGES variable (which in contrast to $LANG is a list of languages, preferred and fallback). In principle, this patch is fine, I'd go with let's kill KLOCALE_LANG and see what breaks, but on RC-tagging-day, this might not be the most prudent thing to do. I'm also not familiar with KSplash, but with the current design we ship, there's nothing translated there, anyway, so it's not like we're breaking the default setup. Vishesh Handa wrote: So, I ship this tomorrow after the tagging? A quick grep shows this is the *only* place that $KLOCALE_LANGUAGES gets used, and it gets unset immediately afterwards, so the entire process is redundant if KSPlash doesn't use it. I don't know why KSplash needed it before, but now it could use $LANGUAGES instead, or QLocale().uiLanguages() after $LANGUAGES is set. - John --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119103/#review61543 --- On July 3, 2014, 12:25 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119103/ --- (Updated July 3, 2014, 12:25 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- Startkde: Remove KLOCALE_LANGUAGES KLOCALE_LANGUAGES was used by the kde4 ksplash in order to to know which language to show. This environment variable is no longer used by the qml based ksplash. It makes no sense to have it. Additionally, this means we can stop linking against kdelibs4support. This is important cause kdostartupconfig blocks the rest of the boot sequence. On my system it causes a good 0.3 - 0.4 seconds delay. By no longer linking to kdelibs4support it takes less than 0.1 seconds and no longer shows up in the bootchat logs. Diffs - startkde/kstartupconfig/CMakeLists.txt 6920fe5 startkde/kstartupconfig/kdostartupconfig.cpp d545f4f startkde/startkde.cmake 40e3377 Diff: https://git.reviewboard.kde.org/r/119103/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119103: Startkde: Remove KLOCALE_LANGUAGES
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119103/#review61559 --- Ship it! Ship It! - Aleix Pol Gonzalez On July 3, 2014, 11:25 a.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119103/ --- (Updated July 3, 2014, 11:25 a.m.) Review request for Plasma. Repository: plasma-workspace Description --- Startkde: Remove KLOCALE_LANGUAGES KLOCALE_LANGUAGES was used by the kde4 ksplash in order to to know which language to show. This environment variable is no longer used by the qml based ksplash. It makes no sense to have it. Additionally, this means we can stop linking against kdelibs4support. This is important cause kdostartupconfig blocks the rest of the boot sequence. On my system it causes a good 0.3 - 0.4 seconds delay. By no longer linking to kdelibs4support it takes less than 0.1 seconds and no longer shows up in the bootchat logs. Diffs - startkde/kstartupconfig/CMakeLists.txt 6920fe5 startkde/kstartupconfig/kdostartupconfig.cpp d545f4f startkde/startkde.cmake 40e3377 Diff: https://git.reviewboard.kde.org/r/119103/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119103: Startkde: Remove KLOCALE_LANGUAGES
On July 3, 2014, 11:41 a.m., Aleix Pol Gonzalez wrote: Don't we still need to pass the language somehow? or now it will be enough with $LANG? Vishesh Handa wrote: KLocale languages had a list of languages. The first one being the main one, and others being fallbacks. We no longer seem to support this multiple languages option in QLocale. I'm not familiar with KSplash internals and why we ever needed to pass the languages variable at all. Sebastian Kügler wrote: We still support it, but it's now the $LANGUAGES variable (which in contrast to $LANG is a list of languages, preferred and fallback). In principle, this patch is fine, I'd go with let's kill KLOCALE_LANG and see what breaks, but on RC-tagging-day, this might not be the most prudent thing to do. I'm also not familiar with KSplash, but with the current design we ship, there's nothing translated there, anyway, so it's not like we're breaking the default setup. Vishesh Handa wrote: So, I ship this tomorrow after the tagging? John Layt wrote: A quick grep shows this is the *only* place that $KLOCALE_LANGUAGES gets used, and it gets unset immediately afterwards, so the entire process is redundant if KSPlash doesn't use it. I don't know why KSplash needed it before, but now it could use $LANGUAGES instead, or QLocale().uiLanguages() after $LANGUAGES is set. Then we probably want this in... - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119103/#review61543 --- On July 3, 2014, 11:25 a.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119103/ --- (Updated July 3, 2014, 11:25 a.m.) Review request for Plasma. Repository: plasma-workspace Description --- Startkde: Remove KLOCALE_LANGUAGES KLOCALE_LANGUAGES was used by the kde4 ksplash in order to to know which language to show. This environment variable is no longer used by the qml based ksplash. It makes no sense to have it. Additionally, this means we can stop linking against kdelibs4support. This is important cause kdostartupconfig blocks the rest of the boot sequence. On my system it causes a good 0.3 - 0.4 seconds delay. By no longer linking to kdelibs4support it takes less than 0.1 seconds and no longer shows up in the bootchat logs. Diffs - startkde/kstartupconfig/CMakeLists.txt 6920fe5 startkde/kstartupconfig/kdostartupconfig.cpp d545f4f startkde/startkde.cmake 40e3377 Diff: https://git.reviewboard.kde.org/r/119103/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119103: Startkde: Remove KLOCALE_LANGUAGES
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119103/#review61560 --- Ship it! Ship It! - Sebastian Kügler On July 3, 2014, 11:25 a.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119103/ --- (Updated July 3, 2014, 11:25 a.m.) Review request for Plasma. Repository: plasma-workspace Description --- Startkde: Remove KLOCALE_LANGUAGES KLOCALE_LANGUAGES was used by the kde4 ksplash in order to to know which language to show. This environment variable is no longer used by the qml based ksplash. It makes no sense to have it. Additionally, this means we can stop linking against kdelibs4support. This is important cause kdostartupconfig blocks the rest of the boot sequence. On my system it causes a good 0.3 - 0.4 seconds delay. By no longer linking to kdelibs4support it takes less than 0.1 seconds and no longer shows up in the bootchat logs. Diffs - startkde/kstartupconfig/CMakeLists.txt 6920fe5 startkde/kstartupconfig/kdostartupconfig.cpp d545f4f startkde/startkde.cmake 40e3377 Diff: https://git.reviewboard.kde.org/r/119103/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119062: Add a script to enforce window decorations for GTK windows
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119062/ --- (Updated July 3, 2014, 2:08 p.m.) Status -- This change has been marked as submitted. Review request for kwin, Plasma and Hugo Pereira Da Costa. Repository: kwin Description --- Add a script to enforce window decorations for GTK windows This is going to be a controversal change. It enforces KWin decorations on all client side decorated windows from GTK+. Unfortunately we are caught between a rock and a hard place. Keeping the status quo means having broken windows and a more or less broken window manager due to GTK+ including the shadow in the windows. This is no solution. Enforcing server side decorations visually breaks the windows. This is also no solution. So why do it? It's our task to provide the best possible user experience and KWin is a window manager which has always done great efforts to fix misbehaving windows. One can think of the focus stealing prevention, the window rules and lately the scripts. The best possible window management experience is our aim. This means we cannot leave the users with the broken windows from GTK. The issues we noticed were reported to GTK+ about 2 months ago and we are working on improving the situation. Unfortunately several issues are not yet addressed and others will only be addressed in the next GTK+ release. We are working on improving the NETWM spec (see [1]) to ensure that the client side decorated windows are not in a broken state. This means the enforcment is a temporary solution and will be re-evaluated with the next GTK release. I would prefer to not have to do such a change, if some of the bugs were fixed or GTK+ would not use client-side-decos on wms not yet supporting those all of this would be a no issue. For a complete list of the problems caused by GTK's decos see bug [2] and the linked bug reports from there. The change is done in a least inversive way in KWin. We just check for the property _GTK_FRAME_EXTENTS and create a Q_PROPERTY in Client for it. If we add support for the frame extents in future we would also need this. So it's not a change just for enforcing the decoration. The actual enforcing is done through a KWin script so users can still disable it. [1] https://mail.gnome.org/archives/wm-spec-list/2014-June/msg2.html [2] https://bugzilla.gnome.org/show_bug.cgi?id=729721 Diffs - atoms.h d52223504a78909efa7c18d7e96feebec8f3cb21 atoms.cpp 576e85f0c0e865721a1b513af9d1ad1bfdb580ea client.h 8e41e203d01b41fdd918c35fb3dc9353d7e41774 client.cpp 608e6a8435ad9bc7d86ff813038023648e6b7b1e events.cpp 514eecc69d81136d8975155e0fbb3fef39d3a346 manage.cpp fbdf19570418e412cdadb54f36cf94e5da24db4f scripts/CMakeLists.txt feeb288250407f5f2bd4b3ea878f21640ebb7d20 scripts/enforcedeco/contents/code/main.js PRE-CREATION scripts/enforcedeco/metadata.desktop PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119062/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 119062: Add a script to enforce window decorations for GTK windows
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119062/#review61562 --- This review has been submitted with commit f0e1e3187e4be7c09cbbbce1bb481fea3ffe7ce3 by Martin Gräßlin to branch master. - Commit Hook On July 1, 2014, 2:53 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119062/ --- (Updated July 1, 2014, 2:53 p.m.) Review request for kwin, Plasma and Hugo Pereira Da Costa. Repository: kwin Description --- Add a script to enforce window decorations for GTK windows This is going to be a controversal change. It enforces KWin decorations on all client side decorated windows from GTK+. Unfortunately we are caught between a rock and a hard place. Keeping the status quo means having broken windows and a more or less broken window manager due to GTK+ including the shadow in the windows. This is no solution. Enforcing server side decorations visually breaks the windows. This is also no solution. So why do it? It's our task to provide the best possible user experience and KWin is a window manager which has always done great efforts to fix misbehaving windows. One can think of the focus stealing prevention, the window rules and lately the scripts. The best possible window management experience is our aim. This means we cannot leave the users with the broken windows from GTK. The issues we noticed were reported to GTK+ about 2 months ago and we are working on improving the situation. Unfortunately several issues are not yet addressed and others will only be addressed in the next GTK+ release. We are working on improving the NETWM spec (see [1]) to ensure that the client side decorated windows are not in a broken state. This means the enforcment is a temporary solution and will be re-evaluated with the next GTK release. I would prefer to not have to do such a change, if some of the bugs were fixed or GTK+ would not use client-side-decos on wms not yet supporting those all of this would be a no issue. For a complete list of the problems caused by GTK's decos see bug [2] and the linked bug reports from there. The change is done in a least inversive way in KWin. We just check for the property _GTK_FRAME_EXTENTS and create a Q_PROPERTY in Client for it. If we add support for the frame extents in future we would also need this. So it's not a change just for enforcing the decoration. The actual enforcing is done through a KWin script so users can still disable it. [1] https://mail.gnome.org/archives/wm-spec-list/2014-June/msg2.html [2] https://bugzilla.gnome.org/show_bug.cgi?id=729721 Diffs - atoms.h d52223504a78909efa7c18d7e96feebec8f3cb21 atoms.cpp 576e85f0c0e865721a1b513af9d1ad1bfdb580ea client.h 8e41e203d01b41fdd918c35fb3dc9353d7e41774 client.cpp 608e6a8435ad9bc7d86ff813038023648e6b7b1e events.cpp 514eecc69d81136d8975155e0fbb3fef39d3a346 manage.cpp fbdf19570418e412cdadb54f36cf94e5da24db4f scripts/CMakeLists.txt feeb288250407f5f2bd4b3ea878f21640ebb7d20 scripts/enforcedeco/contents/code/main.js PRE-CREATION scripts/enforcedeco/metadata.desktop PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119062/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 119105: PlasmaShell: Disable Session Management
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119105/ --- Review request for Plasma. Repository: plasma-workspace Description --- PlasmaShell: Disable Session Management PlasmaShell should not be restored by the session manager. It will be started by klauncher because we install an autostart file. This also clears up the booting process to a certain extent, as plasmashell will now not be started twice (once via session restore, and once via autostart) Diffs - shell/main.cpp 0b96674 Diff: https://git.reviewboard.kde.org/r/119105/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119105: PlasmaShell: Disable Session Management
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119105/#review61564 --- Ship it! Ship It! - Martin Gräßlin On July 3, 2014, 5:42 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119105/ --- (Updated July 3, 2014, 5:42 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- PlasmaShell: Disable Session Management PlasmaShell should not be restored by the session manager. It will be started by klauncher because we install an autostart file. This also clears up the booting process to a certain extent, as plasmashell will now not be started twice (once via session restore, and once via autostart) Diffs - shell/main.cpp 0b96674 Diff: https://git.reviewboard.kde.org/r/119105/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma 5 RC
Release candidate tars for Plasma 5 appearing soon at depot.kde.org unstable/plasma/4.98.0 Also up at http://starsky.19inch.net/~jr/tmp/plasma-4.98.0/ Please check for sanity and let me know what's broken. Announce expected on Tuesday. Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Copying over kxmlrpcclient into plasma-workspace
Hi As it currently stands, Dr Konqi needs kxmlrpcclient ( which comes from kdepimlibs ) in order to talk with bugzilla to report crashes in Plasma 5. However, since kxmlrpcclient is not being split / released, would it be possible to ship a local copy of the code in plasma-workspace/drkonqi ? Cheers Rohan Garg ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5 RC
On Thursday 03 July 2014, Jonathan Riddell wrote: Release candidate tars for Plasma 5 appearing soon at depot.kde.org unstable/plasma/4.98.0 Also up at http://starsky.19inch.net/~jr/tmp/plasma-4.98.0/ Please check for sanity and let me know what's broken. Announce expected on Tuesday. to me they seem good (more eyeballs would always be nice tough) note thet in the final version there will be more wallpapers in the plasma- workspace-wallpapers repo, but unfortunately they are not ready yet (I don't think is a big deal tough?) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119105: PlasmaShell: Disable Session Management
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119105/#review61570 --- Ship it! We should have this for everything loaded by startkde, right? - Aleix Pol Gonzalez On July 3, 2014, 3:42 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119105/ --- (Updated July 3, 2014, 3:42 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- PlasmaShell: Disable Session Management PlasmaShell should not be restored by the session manager. It will be started by klauncher because we install an autostart file. This also clears up the booting process to a certain extent, as plasmashell will now not be started twice (once via session restore, and once via autostart) Diffs - shell/main.cpp 0b96674 Diff: https://git.reviewboard.kde.org/r/119105/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Runners KCM
On Monday 30 June 2014 11:25:09 Hans Chen wrote: Ah yes, just included it to have a complete list of widgets in the KCM. I have no problems with the list in the screenshot. I just noticed that in 4.X, the KRunner config had a second tab User Interface which allowed to change the positioning to free floating and the style to Task Oriented. What about those options? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Runners KCM
As far as I know the Task Oriented option got removed (unmaintained). Not sure about free floating. On Thu, Jul 3, 2014 at 2:03 PM, Thomas Pfeiffer colo...@autistici.org wrote: On Monday 30 June 2014 11:25:09 Hans Chen wrote: Ah yes, just included it to have a complete list of widgets in the KCM. I have no problems with the list in the screenshot. I just noticed that in 4.X, the KRunner config had a second tab User Interface which allowed to change the positioning to free floating and the style to Task Oriented. What about those options? ___ 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: Runners KCM
On Thursday 03 July 2014, Thomas Pfeiffer wrote: On Monday 30 June 2014 11:25:09 Hans Chen wrote: Ah yes, just included it to have a complete list of widgets in the KCM. I have no problems with the list in the screenshot. I just noticed that in 4.X, the KRunner config had a second tab User Interface which allowed to change the positioning to free floating and the style to Task Oriented. What about those options? task oriented is removed. in the future however by changing the global look and feel package, will be possible to give krunner too a different ui. the free floating option is supported by the configuration file and works, but since is not tested that much, would be fine too if it stays an hidden option until 5.1, I'm fine both if is decided to postpone or to rush in a checkbox more. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-packager] Plasma 5 RC
On Thu, Jul 03, 2014 at 06:29:33PM +0200, Jonathan Riddell wrote: Release candidate tars for Plasma 5 appearing soon at depot.kde.org unstable/plasma/4.98.0 Some updates now up on depot.. d58af08286e9d85ea6afa77831692c02efba9ba8ddebf57fd342854062425d39 kfilemetadata5-4.98.0.tar.xz 24f401be4beda474a386bd223390477ece9ab3329183d0f69b06ccb5859ecbba baloo5-4.98.0.tar.xz for some reason kdelibs4support contains a duplicate FindGettext which is incompatible with the ECM FindGettext so some of the tars fail when compiling po/. For now I recommend removing FindGettext.cmake from kdelibs4support packages. Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Runners KCM
Maybe what can be done here is to make the wrench still show in the krunner app but this time, it will open the kcm from within syse instead. I am working on a design for that right now that I will show you soon. On Thu, Jul 3, 2014 at 12:18 PM, Marco Martin notm...@gmail.com wrote: On Thursday 03 July 2014, Thomas Pfeiffer wrote: On Monday 30 June 2014 11:25:09 Hans Chen wrote: Ah yes, just included it to have a complete list of widgets in the KCM. I have no problems with the list in the screenshot. I just noticed that in 4.X, the KRunner config had a second tab User Interface which allowed to change the positioning to free floating and the style to Task Oriented. What about those options? task oriented is removed. in the future however by changing the global look and feel package, will be possible to give krunner too a different ui. the free floating option is supported by the configuration file and works, but since is not tested that much, would be fine too if it stays an hidden option until 5.1, I'm fine both if is decided to postpone or to rush in a checkbox more. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Andy (anditosan) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5 RC
On Thu, Jul 3, 2014 at 6:29 PM, Jonathan Riddell j...@jriddell.org wrote: Please check for sanity and let me know what's broken. Announce expected on Tuesday. I've noticed that a number of packages (baloo, milou, kfilemetadata) have empty doc folders. I'm not sure if it is a problem. -- Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
