Re: Review Request: Use platform palette and fonts when running on other desktop environments
On July 2, 2011, 9:49 p.m., Oswald Buddenhagen wrote: hmm. but now things are still done twice in a kde session, no? what was wrong with the suggestion to notify qt that it should update stuff? Aurélien Gâteau wrote: createApplicationPalette() is indeed called twice when running on a KDE session, but it is not a regression introduced by this change so I think it is outside of the scope for now. I tried not doing anything in kdisplaySetPalette() and call qt_x11_apply_settings_in_all_apps() from the kcm as Olivier suggested, but that didn't work: the palette change was not propagated to the running application. What worries me right now is that the text area of KWrite does not get updated at runtime. I thought it was due to the widget being custom, but it correctly updates itself without the patch. Aurélien Gâteau wrote: Finally found time to do more testing. It turns out the behavior of KWrite text area is the same with or without the patch so it's not a regression. Therefore, I think the patch should go in. Thomas Lübking wrote: Sh*t - i forgot that I wanted to comment on that: kate keeps own color schemes for the text area, they're completely unrelated to he rest of the system. (since you need to configure syntax highlightning and don't want that to run into a conflict with the system palette de toujours) So yes, that's not a regression for sure, sorry. Dominik Haumann wrote: With regard to kwrite: It uses the system colors as long as they were never changed. Changed once, these system settings are overwritten. Hence, this is very likely a KatePart issue. Aurélien Gâteau wrote: Oh. Thanks Thomas and Dominik, it suddenly makes more sense! If there is no other objection I'd like to merge this patch this week. Anyone against that? Aurélien Gâteau wrote: I just merged the changes in. Unless I spot some obvious regressions, I plan to backport the patch in time for 4.7.1. Frank Reininghaus wrote: Could it be that your commit caused the recent kglobalsettingstest failures seen on CDash? http://my.cdash.org/testSummary.php?project=16name=kdeui-kglobalsettingstestdate=2011-07-25 On my machine (kongresszentrum), the kde-devel user runs the unit tests in a Konsole inside the regular user's KDE 4.6 session. That's quite possible indeed. Looking into it. - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/#review4333 --- On July 2, 2011, 9:19 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/ --- (Updated July 2, 2011, 9:19 p.m.) Review request for kdelibs and Olivier Goffart. Summary --- When a KDE application is running on GNOME it looks odd right now because it does not use the GNOME palette and fonts, contrary to Qt-only applications. Attached patch fixes this by relying on the platform plugin to set the correct palette and fonts if we are not running in a full KDE session. Patch was suggested by Olivier Goffart. Diffs - kdeui/kernel/kglobalsettings.cpp 1a497c7 Diff: http://git.reviewboard.kde.org/r/101805/diff Testing --- # On KDE - Run kwrite on KDE = KDE palette and fonts - Change palette and fonts from System Settings = kwrite updates itself correctly # On GNOME - Run kwrite on GNOME = GNOME palette and fonts - Change palette and fonts from GNOME Tweak Tool = palette gets applied, font does not for now Thanks, Aurélien
Re: Review Request: Use platform palette and fonts when running on other desktop environments
On July 2, 2011, 9:49 p.m., Oswald Buddenhagen wrote: hmm. but now things are still done twice in a kde session, no? what was wrong with the suggestion to notify qt that it should update stuff? Aurélien Gâteau wrote: createApplicationPalette() is indeed called twice when running on a KDE session, but it is not a regression introduced by this change so I think it is outside of the scope for now. I tried not doing anything in kdisplaySetPalette() and call qt_x11_apply_settings_in_all_apps() from the kcm as Olivier suggested, but that didn't work: the palette change was not propagated to the running application. What worries me right now is that the text area of KWrite does not get updated at runtime. I thought it was due to the widget being custom, but it correctly updates itself without the patch. Aurélien Gâteau wrote: Finally found time to do more testing. It turns out the behavior of KWrite text area is the same with or without the patch so it's not a regression. Therefore, I think the patch should go in. Thomas Lübking wrote: Sh*t - i forgot that I wanted to comment on that: kate keeps own color schemes for the text area, they're completely unrelated to he rest of the system. (since you need to configure syntax highlightning and don't want that to run into a conflict with the system palette de toujours) So yes, that's not a regression for sure, sorry. Dominik Haumann wrote: With regard to kwrite: It uses the system colors as long as they were never changed. Changed once, these system settings are overwritten. Hence, this is very likely a KatePart issue. Aurélien Gâteau wrote: Oh. Thanks Thomas and Dominik, it suddenly makes more sense! If there is no other objection I'd like to merge this patch this week. Anyone against that? Aurélien Gâteau wrote: I just merged the changes in. Unless I spot some obvious regressions, I plan to backport the patch in time for 4.7.1. Could it be that your commit caused the recent kglobalsettingstest failures seen on CDash? http://my.cdash.org/testSummary.php?project=16name=kdeui-kglobalsettingstestdate=2011-07-25 On my machine (kongresszentrum), the kde-devel user runs the unit tests in a Konsole inside the regular user's KDE 4.6 session. - Frank --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/#review4333 --- On July 2, 2011, 9:19 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/ --- (Updated July 2, 2011, 9:19 p.m.) Review request for kdelibs and Olivier Goffart. Summary --- When a KDE application is running on GNOME it looks odd right now because it does not use the GNOME palette and fonts, contrary to Qt-only applications. Attached patch fixes this by relying on the platform plugin to set the correct palette and fonts if we are not running in a full KDE session. Patch was suggested by Olivier Goffart. Diffs - kdeui/kernel/kglobalsettings.cpp 1a497c7 Diff: http://git.reviewboard.kde.org/r/101805/diff Testing --- # On KDE - Run kwrite on KDE = KDE palette and fonts - Change palette and fonts from System Settings = kwrite updates itself correctly # On GNOME - Run kwrite on GNOME = GNOME palette and fonts - Change palette and fonts from GNOME Tweak Tool = palette gets applied, font does not for now Thanks, Aurélien
Re: Review Request: Use platform palette and fonts when running on other desktop environments
On July 2, 2011, 9:49 p.m., Oswald Buddenhagen wrote: hmm. but now things are still done twice in a kde session, no? what was wrong with the suggestion to notify qt that it should update stuff? Aurélien Gâteau wrote: createApplicationPalette() is indeed called twice when running on a KDE session, but it is not a regression introduced by this change so I think it is outside of the scope for now. I tried not doing anything in kdisplaySetPalette() and call qt_x11_apply_settings_in_all_apps() from the kcm as Olivier suggested, but that didn't work: the palette change was not propagated to the running application. What worries me right now is that the text area of KWrite does not get updated at runtime. I thought it was due to the widget being custom, but it correctly updates itself without the patch. Aurélien Gâteau wrote: Finally found time to do more testing. It turns out the behavior of KWrite text area is the same with or without the patch so it's not a regression. Therefore, I think the patch should go in. Thomas Lübking wrote: Sh*t - i forgot that I wanted to comment on that: kate keeps own color schemes for the text area, they're completely unrelated to he rest of the system. (since you need to configure syntax highlightning and don't want that to run into a conflict with the system palette de toujours) So yes, that's not a regression for sure, sorry. Dominik Haumann wrote: With regard to kwrite: It uses the system colors as long as they were never changed. Changed once, these system settings are overwritten. Hence, this is very likely a KatePart issue. Aurélien Gâteau wrote: Oh. Thanks Thomas and Dominik, it suddenly makes more sense! If there is no other objection I'd like to merge this patch this week. Anyone against that? I just merged the changes in. Unless I spot some obvious regressions, I plan to backport the patch in time for 4.7.1. - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/#review4333 --- On July 2, 2011, 9:19 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/ --- (Updated July 2, 2011, 9:19 p.m.) Review request for kdelibs and Olivier Goffart. Summary --- When a KDE application is running on GNOME it looks odd right now because it does not use the GNOME palette and fonts, contrary to Qt-only applications. Attached patch fixes this by relying on the platform plugin to set the correct palette and fonts if we are not running in a full KDE session. Patch was suggested by Olivier Goffart. Diffs - kdeui/kernel/kglobalsettings.cpp 1a497c7 Diff: http://git.reviewboard.kde.org/r/101805/diff Testing --- # On KDE - Run kwrite on KDE = KDE palette and fonts - Change palette and fonts from System Settings = kwrite updates itself correctly # On GNOME - Run kwrite on GNOME = GNOME palette and fonts - Change palette and fonts from GNOME Tweak Tool = palette gets applied, font does not for now Thanks, Aurélien
Re: Review Request: Use platform palette and fonts when running on other desktop environments
On July 2, 2011, 9:49 p.m., Oswald Buddenhagen wrote: hmm. but now things are still done twice in a kde session, no? what was wrong with the suggestion to notify qt that it should update stuff? Aurélien Gâteau wrote: createApplicationPalette() is indeed called twice when running on a KDE session, but it is not a regression introduced by this change so I think it is outside of the scope for now. I tried not doing anything in kdisplaySetPalette() and call qt_x11_apply_settings_in_all_apps() from the kcm as Olivier suggested, but that didn't work: the palette change was not propagated to the running application. What worries me right now is that the text area of KWrite does not get updated at runtime. I thought it was due to the widget being custom, but it correctly updates itself without the patch. Aurélien Gâteau wrote: Finally found time to do more testing. It turns out the behavior of KWrite text area is the same with or without the patch so it's not a regression. Therefore, I think the patch should go in. Sh*t - i forgot that I wanted to comment on that: kate keeps own color schemes for the text area, they're completely unrelated to he rest of the system. (since you need to configure syntax highlightning and don't want that to run into a conflict with the system palette de toujours) So yes, that's not a regression for sure, sorry. - Thomas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/#review4333 --- On July 2, 2011, 9:19 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/ --- (Updated July 2, 2011, 9:19 p.m.) Review request for kdelibs and Olivier Goffart. Summary --- When a KDE application is running on GNOME it looks odd right now because it does not use the GNOME palette and fonts, contrary to Qt-only applications. Attached patch fixes this by relying on the platform plugin to set the correct palette and fonts if we are not running in a full KDE session. Patch was suggested by Olivier Goffart. Diffs - kdeui/kernel/kglobalsettings.cpp 1a497c7 Diff: http://git.reviewboard.kde.org/r/101805/diff Testing --- # On KDE - Run kwrite on KDE = KDE palette and fonts - Change palette and fonts from System Settings = kwrite updates itself correctly # On GNOME - Run kwrite on GNOME = GNOME palette and fonts - Change palette and fonts from GNOME Tweak Tool = palette gets applied, font does not for now Thanks, Aurélien
Re: Review Request: Use platform palette and fonts when running on other desktop environments
On July 2, 2011, 9:49 p.m., Oswald Buddenhagen wrote: hmm. but now things are still done twice in a kde session, no? what was wrong with the suggestion to notify qt that it should update stuff? Aurélien Gâteau wrote: createApplicationPalette() is indeed called twice when running on a KDE session, but it is not a regression introduced by this change so I think it is outside of the scope for now. I tried not doing anything in kdisplaySetPalette() and call qt_x11_apply_settings_in_all_apps() from the kcm as Olivier suggested, but that didn't work: the palette change was not propagated to the running application. What worries me right now is that the text area of KWrite does not get updated at runtime. I thought it was due to the widget being custom, but it correctly updates itself without the patch. Aurélien Gâteau wrote: Finally found time to do more testing. It turns out the behavior of KWrite text area is the same with or without the patch so it's not a regression. Therefore, I think the patch should go in. Thomas Lübking wrote: Sh*t - i forgot that I wanted to comment on that: kate keeps own color schemes for the text area, they're completely unrelated to he rest of the system. (since you need to configure syntax highlightning and don't want that to run into a conflict with the system palette de toujours) So yes, that's not a regression for sure, sorry. With regard to kwrite: It uses the system colors as long as they were never changed. Changed once, these system settings are overwritten. Hence, this is very likely a KatePart issue. - Dominik --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/#review4333 --- On July 2, 2011, 9:19 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/ --- (Updated July 2, 2011, 9:19 p.m.) Review request for kdelibs and Olivier Goffart. Summary --- When a KDE application is running on GNOME it looks odd right now because it does not use the GNOME palette and fonts, contrary to Qt-only applications. Attached patch fixes this by relying on the platform plugin to set the correct palette and fonts if we are not running in a full KDE session. Patch was suggested by Olivier Goffart. Diffs - kdeui/kernel/kglobalsettings.cpp 1a497c7 Diff: http://git.reviewboard.kde.org/r/101805/diff Testing --- # On KDE - Run kwrite on KDE = KDE palette and fonts - Change palette and fonts from System Settings = kwrite updates itself correctly # On GNOME - Run kwrite on GNOME = GNOME palette and fonts - Change palette and fonts from GNOME Tweak Tool = palette gets applied, font does not for now Thanks, Aurélien
Re: Review Request: Use platform palette and fonts when running on other desktop environments
On July 2, 2011, 9:49 p.m., Oswald Buddenhagen wrote: hmm. but now things are still done twice in a kde session, no? what was wrong with the suggestion to notify qt that it should update stuff? Aurélien Gâteau wrote: createApplicationPalette() is indeed called twice when running on a KDE session, but it is not a regression introduced by this change so I think it is outside of the scope for now. I tried not doing anything in kdisplaySetPalette() and call qt_x11_apply_settings_in_all_apps() from the kcm as Olivier suggested, but that didn't work: the palette change was not propagated to the running application. What worries me right now is that the text area of KWrite does not get updated at runtime. I thought it was due to the widget being custom, but it correctly updates itself without the patch. Aurélien Gâteau wrote: Finally found time to do more testing. It turns out the behavior of KWrite text area is the same with or without the patch so it's not a regression. Therefore, I think the patch should go in. Thomas Lübking wrote: Sh*t - i forgot that I wanted to comment on that: kate keeps own color schemes for the text area, they're completely unrelated to he rest of the system. (since you need to configure syntax highlightning and don't want that to run into a conflict with the system palette de toujours) So yes, that's not a regression for sure, sorry. Dominik Haumann wrote: With regard to kwrite: It uses the system colors as long as they were never changed. Changed once, these system settings are overwritten. Hence, this is very likely a KatePart issue. Oh. Thanks Thomas and Dominik, it suddenly makes more sense! If there is no other objection I'd like to merge this patch this week. Anyone against that? - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/#review4333 --- On July 2, 2011, 9:19 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/ --- (Updated July 2, 2011, 9:19 p.m.) Review request for kdelibs and Olivier Goffart. Summary --- When a KDE application is running on GNOME it looks odd right now because it does not use the GNOME palette and fonts, contrary to Qt-only applications. Attached patch fixes this by relying on the platform plugin to set the correct palette and fonts if we are not running in a full KDE session. Patch was suggested by Olivier Goffart. Diffs - kdeui/kernel/kglobalsettings.cpp 1a497c7 Diff: http://git.reviewboard.kde.org/r/101805/diff Testing --- # On KDE - Run kwrite on KDE = KDE palette and fonts - Change palette and fonts from System Settings = kwrite updates itself correctly # On GNOME - Run kwrite on GNOME = GNOME palette and fonts - Change palette and fonts from GNOME Tweak Tool = palette gets applied, font does not for now Thanks, Aurélien
Re: Review Request: Use platform palette and fonts when running on other desktop environments
On July 2, 2011, 9:49 p.m., Oswald Buddenhagen wrote: hmm. but now things are still done twice in a kde session, no? what was wrong with the suggestion to notify qt that it should update stuff? Aurélien Gâteau wrote: createApplicationPalette() is indeed called twice when running on a KDE session, but it is not a regression introduced by this change so I think it is outside of the scope for now. I tried not doing anything in kdisplaySetPalette() and call qt_x11_apply_settings_in_all_apps() from the kcm as Olivier suggested, but that didn't work: the palette change was not propagated to the running application. What worries me right now is that the text area of KWrite does not get updated at runtime. I thought it was due to the widget being custom, but it correctly updates itself without the patch. Finally found time to do more testing. It turns out the behavior of KWrite text area is the same with or without the patch so it's not a regression. Therefore, I think the patch should go in. - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/#review4333 --- On July 2, 2011, 9:19 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/ --- (Updated July 2, 2011, 9:19 p.m.) Review request for kdelibs and Olivier Goffart. Summary --- When a KDE application is running on GNOME it looks odd right now because it does not use the GNOME palette and fonts, contrary to Qt-only applications. Attached patch fixes this by relying on the platform plugin to set the correct palette and fonts if we are not running in a full KDE session. Patch was suggested by Olivier Goffart. Diffs - kdeui/kernel/kglobalsettings.cpp 1a497c7 Diff: http://git.reviewboard.kde.org/r/101805/diff Testing --- # On KDE - Run kwrite on KDE = KDE palette and fonts - Change palette and fonts from System Settings = kwrite updates itself correctly # On GNOME - Run kwrite on GNOME = GNOME palette and fonts - Change palette and fonts from GNOME Tweak Tool = palette gets applied, font does not for now Thanks, Aurélien
Re: Review Request: Use platform palette and fonts when running on other desktop environments
On July 2, 2011, 9:49 p.m., Oswald Buddenhagen wrote: hmm. but now things are still done twice in a kde session, no? what was wrong with the suggestion to notify qt that it should update stuff? createApplicationPalette() is indeed called twice when running on a KDE session, but it is not a regression introduced by this change so I think it is outside of the scope for now. I tried not doing anything in kdisplaySetPalette() and call qt_x11_apply_settings_in_all_apps() from the kcm as Olivier suggested, but that didn't work: the palette change was not propagated to the running application. What worries me right now is that the text area of KWrite does not get updated at runtime. I thought it was due to the widget being custom, but it correctly updates itself without the patch. - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/#review4333 --- On July 2, 2011, 9:19 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/ --- (Updated July 2, 2011, 9:19 p.m.) Review request for kdelibs and Olivier Goffart. Summary --- When a KDE application is running on GNOME it looks odd right now because it does not use the GNOME palette and fonts, contrary to Qt-only applications. Attached patch fixes this by relying on the platform plugin to set the correct palette and fonts if we are not running in a full KDE session. Patch was suggested by Olivier Goffart. Diffs - kdeui/kernel/kglobalsettings.cpp 1a497c7 Diff: http://git.reviewboard.kde.org/r/101805/diff Testing --- # On KDE - Run kwrite on KDE = KDE palette and fonts - Change palette and fonts from System Settings = kwrite updates itself correctly # On GNOME - Run kwrite on GNOME = GNOME palette and fonts - Change palette and fonts from GNOME Tweak Tool = palette gets applied, font does not for now Thanks, Aurélien
Re: Review Request: Use platform palette and fonts when running on other desktop environments
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/#review4333 --- hmm. but now things are still done twice in a kde session, no? what was wrong with the suggestion to notify qt that it should update stuff? - Oswald On July 2, 2011, 9:19 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/ --- (Updated July 2, 2011, 9:19 p.m.) Review request for kdelibs and Olivier Goffart. Summary --- When a KDE application is running on GNOME it looks odd right now because it does not use the GNOME palette and fonts, contrary to Qt-only applications. Attached patch fixes this by relying on the platform plugin to set the correct palette and fonts if we are not running in a full KDE session. Patch was suggested by Olivier Goffart. Diffs - kdeui/kernel/kglobalsettings.cpp 1a497c7 Diff: http://git.reviewboard.kde.org/r/101805/diff Testing --- # On KDE - Run kwrite on KDE = KDE palette and fonts - Change palette and fonts from System Settings = kwrite updates itself correctly # On GNOME - Run kwrite on GNOME = GNOME palette and fonts - Change palette and fonts from GNOME Tweak Tool = palette gets applied, font does not for now Thanks, Aurélien
