From kwrite-devel Sat Dec 28 14:38:06 2013 From: "Michal Humpula" Date: Sat, 28 Dec 2013 14:38:06 +0000 To: kwrite-devel Subject: Re: Review Request 114619: frameworks: reenable the updateColorPalette slot Message-Id: <20131228143806.18782.49809 () probe ! kde ! org> X-MARC-Message: https://marc.info/?l=kwrite-devel&m=138824151009225 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============6125272679160630443==" --===============6125272679160630443== Content-Type: multipart/alternative; boundary="===============4313789519806768744==" --===============4313789519806768744== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114619/ ----------------------------------------------------------- (Updated Dec. 28, 2013, 2:38 p.m.) Status ------ This change has been marked as submitted. Review request for Kate. Repository: kate Description ------- This is a little bit hackish, so second opinion is welcomed (required). Back in KDE4 there was KGlobalSettings::kdisplayPaletteChanged() signal, which was generated, when DBus notification from kcontrol (?) arrived. Seems that with Qt5 QPA and its implementation in frameworks, this is gone. The recommended way is supossedly to * Note: If you derive from a QWidget-based class, a faster method is to * reimplement QWidget::changeEvent() and catch QEvent::PaletteChange. * This is the preferred way to get informed about palette updates. which doesn't work in a case of KateGlobal, which derives from QObject. So Loooking at the Qt5 kode, the QPA should send QEvent::ChangePallete to application object, which resends it to all widgets and to itself as QEvent::ApplicationChangePallete. So the solution simple taps to the event interface and listens for the right event. Diffs ----- part/utils/kateglobal.h 610be1d part/utils/kateglobal.cpp f13e9a7 Diff: https://git.reviewboard.kde.org/r/114619/diff/ Testing ------- none. `kcmshell5 colors` doesn't seems to change colors of running applications (at least for me and for now). Thanks, Michal Humpula --===============4313789519806768744== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit

This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114619/

This change has been marked as submitted.

Review request for Kate.

By Michal Humpula.

Updated Dec. 28, 2013, 2:38 p.m.

Repository: kate

Description

This is a little bit hackish, so second opinion is welcomed (required).

Back in KDE4 there was KGlobalSettings::kdisplayPaletteChanged() signal, which was generated, when DBus notification from kcontrol (?) arrived. Seems that with Qt5 QPA and its implementation in frameworks, this is gone. The recommended way is supossedly to

* Note: If you derive from a QWidget-based class, a faster method is to
*       reimplement QWidget::changeEvent() and catch QEvent::PaletteChange.
*       This is the preferred way to get informed about palette updates.

which doesn't work in a case of KateGlobal, which derives from QObject. So Loooking at the Qt5 kode, the QPA should send QEvent::ChangePallete to application object, which resends it to all widgets and to itself as QEvent::ApplicationChangePallete. So the solution simple taps to the event interface and listens for the right event.

Testing

none. `kcmshell5 colors` doesn't seems to change colors of running applications (at least for me and for now).

Diffs

part/utils/kateglobal.h (610be1d)
part/utils/kateglobal.cpp (f13e9a7)

--===============4313789519806768744==-- --===============6125272679160630443== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KWrite-Devel mailing list KWrite-Devel@kde.org https://mail.kde.org/mailman/listinfo/kwrite-devel --===============6125272679160630443==--