Re: [Kde-hardware-devel] Proposal: have Solid::beginSuppressingScreenPowerManagement inhibit screensaver as well
On Tuesday, January 17, 2012 05:17:25 Dario Freddi wrote: this mail comes after a certain discussion on how to handle screen inhibition. At the moment, the aforementioned function leads to an inhibition of DPMS features and brightness handling - I propose to change that to include also Screensaver inhibition, to provide a full hassle-free experience screen-wise. What do you think? Anything against/in favor of that? Absolutely in favor. :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Proposal: have Solid::beginSuppressingScreenPowerManagement inhibit screensaver as well
On 01/17/2012 05:17 AM, Dario Freddi wrote: Howdy, this mail comes after a certain discussion on how to handle screen inhibition. At the moment, the aforementioned function leads to an inhibition of DPMS features and brightness handling - I propose to change that to include also Screensaver inhibition, to provide a full hassle-free experience screen-wise. What do you think? Anything against/in favor of that? Totally in favor, I can't see a reason why somebody would want to inhibit DPMS and not screensaver.
Re: Proposal: have Solid::beginSuppressingScreenPowerManagement inhibit screensaver as well
Cool :) If no objections arise within the next hours, I'll commit the change 2012/1/17 Alex Fiestas afies...@kde.org: On 01/17/2012 05:17 AM, Dario Freddi wrote: Howdy, this mail comes after a certain discussion on how to handle screen inhibition. At the moment, the aforementioned function leads to an inhibition of DPMS features and brightness handling - I propose to change that to include also Screensaver inhibition, to provide a full hassle-free experience screen-wise. What do you think? Anything against/in favor of that? Totally in favor, I can't see a reason why somebody would want to inhibit DPMS and not screensaver.
Re: Review Request: Port shutdown dialog to QML
On Friday 06 January 2012, Alexander Neundorf wrote:
On Friday 06 January 2012, Lamarque V. Souza wrote:
Em Thursday 05 January 2012, Alexander Neundorf escreveu:
On Thursday 05 January 2012, Lamarque V. Souza wrote:
Em Wednesday 04 January 2012, Alexander Neundorf escreveu:
On Wednesday 04 January 2012, Lamarque Vieira Souza wrote:
On Jan. 3, 2012, 9:38 p.m., Albert Astals Cid wrote:
ksmserver/CMakeLists.txt, line 57
http://git.reviewboard.kde.org/r/103621/diff/1/?file=45363#f
il e4 53 63 li ne57
no variable for kdeclarative?
Lamarque Vieira Souza wrote:
There is one in shutdowndlg.cpp, in KSMShutdownDlg's
constructor.
Albert Astals Cid wrote:
I mean cmake variable like ${SOMETHING_SOMETHING}
I do not think so. All CMakeLists.txt throughout kde-workspace,
kde-runtime and plasma-mobile add the library name directly.
libkdeclarative is from kdelibs/experimental/, right ?
Yes.
So, it is not from within the same project.
And I didn't find a place where libkdeclarative would install a
KDeclarativeConfig.cmake file. Did I miss this somewhere ?
If not, is there a FindKDeclarative.cmake somewhere ?
If not, this is seriously messed up.
It would mean that simply using kdeclarative means that cmake
interprets this as name of a library and simply adds -lkdeclarative
to the command line, without checking whether it actually exists
nor in which directory.
I guest that is indeed what happens now.
So, is there a FindKDeclarative.cmake or a KDeclarativeConfig.cmake
file somewhere ?
locate /*Declarative*.cmake returned nothing here, so there is
none
in
my notebook.
So, quick solution: write a simply FindKDeclarative.cmake file (mostly
find_library(), find_path() and a find_package_handle_standard_args()
call) and use this (but don't install it).
Good solution: kdeclarative should install a KDeclarativeConfig.cmake
file, so it will be found automatically. But this has to be done
carefully.
I think the person to talk about this is Marco Martin.
Still, if you are a user of kdeclarative, you have an interest in having a
FindKDeclarative.cmake file.
Have a look at some of the simpler find-files, e.g. FindJPEG.cmake coming
with cmake, and write a FindKDeclarative.cmake file similar to it.
This won't take you long.
Any progress ?
Alex
Re: Review Request: Port shutdown dialog to QML
Em Tuesday 17 January 2012, Alexander Neundorf escreveu:
On Friday 06 January 2012, Alexander Neundorf wrote:
On Friday 06 January 2012, Lamarque V. Souza wrote:
Em Thursday 05 January 2012, Alexander Neundorf escreveu:
On Thursday 05 January 2012, Lamarque V. Souza wrote:
Em Wednesday 04 January 2012, Alexander Neundorf escreveu:
On Wednesday 04 January 2012, Lamarque Vieira Souza wrote:
On Jan. 3, 2012, 9:38 p.m., Albert Astals Cid wrote:
ksmserver/CMakeLists.txt, line 57
http://git.reviewboard.kde.org/r/103621/diff/1/?file=45363
#f il e4 53 63 li ne57
no variable for kdeclarative?
Lamarque Vieira Souza wrote:
There is one in shutdowndlg.cpp, in KSMShutdownDlg's
constructor.
Albert Astals Cid wrote:
I mean cmake variable like ${SOMETHING_SOMETHING}
I do not think so. All CMakeLists.txt throughout kde-workspace,
kde-runtime and plasma-mobile add the library name directly.
libkdeclarative is from kdelibs/experimental/, right ?
Yes.
So, it is not from within the same project.
And I didn't find a place where libkdeclarative would install a
KDeclarativeConfig.cmake file. Did I miss this somewhere ?
If not, is there a FindKDeclarative.cmake somewhere ?
If not, this is seriously messed up.
It would mean that simply using kdeclarative means that cmake
interprets this as name of a library and simply adds
-lkdeclarative to the command line, without checking whether it
actually exists nor in which directory.
I guest that is indeed what happens now.
So, is there a FindKDeclarative.cmake or a
KDeclarativeConfig.cmake file somewhere ?
locate /*Declarative*.cmake returned nothing here, so there is
none
in
my notebook.
So, quick solution: write a simply FindKDeclarative.cmake file
(mostly find_library(), find_path() and a
find_package_handle_standard_args() call) and use this (but don't
install it).
Good solution: kdeclarative should install a KDeclarativeConfig.cmake
file, so it will be found automatically. But this has to be done
carefully.
I think the person to talk about this is Marco Martin.
Still, if you are a user of kdeclarative, you have an interest in having
a FindKDeclarative.cmake file.
Have a look at some of the simpler find-files, e.g. FindJPEG.cmake coming
with cmake, and write a FindKDeclarative.cmake file similar to it.
This won't take you long.
Any progress ?
No, I am too busy with other implemenations in Plasma Active and I am
going to be even busier until next month (at least) :-/ If nobody takes this
task it will be postponed indefinitely. All my work in Plasma NM is already
postponed too :-/
--
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
Re: Review Request: Replicate the existing KConfigDialog constructor and change one argument type
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103716/#review9903 --- The kdeui module is unlikely welcome on mobile platforms Why is this review about adding stuff to kdeui, then? I don't get it. Either you're using it or you're not using it -- or the real reason is core/gui split in your libs/apps, which would be a valid point. - David Faure On Jan. 17, 2012, 3:54 p.m., Laszlo Papp wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103716/ --- (Updated Jan. 17, 2012, 3:54 p.m.) Review request for kdelibs and Jeremy Paul Whiting. Description --- Use case: there are applications like kanagram which would be nice to have running on several platforms, like handsets; for instance Harmattan on N9. It would be nice to use the same settings code generation in certain cases for all the platforms since the additions of KConfigSkeleton on the top of KCoreConfigSkeleton are the font and color settings. These are currently not used in many KDE applications. Hence, it should not be mandatory. The kdeui module is unlikely welcome on mobile platforms, especially in appstores with its sizes and complexity for no real need. KConfigDialogManager has apparently already two constructors; one with KConfigSkeleton argument type, and yet another with KCoreConfigSkeleton. It looks like a situation where the KCoreConfigSkeleton version was added later. KConfigDialog does not have a constructor yet with KCoreConfigSkeleton argument type yet; it has probably somehow been missed so far. Changing the current constructor to KCoreConfigSkeleton usage is not possible in the 4.X major version because of the consequences (ABI breakage). Thereby, the freshly replacated constructor. The proper fix can be filed against frameworks where there is only one, and properly working constructor. Diffs - kdeui/dialogs/kconfigdialog.h 2ac0eda kdeui/dialogs/kconfigdialog.cpp e815e54 Diff: http://git.reviewboard.kde.org/r/103716/diff/diff Testing --- On Archlinux (build test only) Thanks, Laszlo Papp
Re: Review Request: Replicate the existing KConfigDialog constructor and change one argument type
On Jan. 17, 2012, 10:28 p.m., David Faure wrote: The kdeui module is unlikely welcome on mobile platforms Why is this review about adding stuff to kdeui, then? I don't get it. Either you're using it or you're not using it -- or the real reason is core/gui split in your libs/apps, which would be a valid point. The desktop application uses kdeui. KConfigDialog (QWidget *parent, const QString name, KConfigSkeleton *config) - It is now impossible to generate only one settings class inheriting KCoreConfigSkeleton, and use that in each frontend. I would not like to generate distinct settings classes without no real reasons. Also, I discarded this patch because it is possible to make this API addition to 4.X. See my patch in frameworks. - Laszlo --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103716/#review9903 --- On Jan. 17, 2012, 3:54 p.m., Laszlo Papp wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103716/ --- (Updated Jan. 17, 2012, 3:54 p.m.) Review request for kdelibs and Jeremy Paul Whiting. Description --- Use case: there are applications like kanagram which would be nice to have running on several platforms, like handsets; for instance Harmattan on N9. It would be nice to use the same settings code generation in certain cases for all the platforms since the additions of KConfigSkeleton on the top of KCoreConfigSkeleton are the font and color settings. These are currently not used in many KDE applications. Hence, it should not be mandatory. The kdeui module is unlikely welcome on mobile platforms, especially in appstores with its sizes and complexity for no real need. KConfigDialogManager has apparently already two constructors; one with KConfigSkeleton argument type, and yet another with KCoreConfigSkeleton. It looks like a situation where the KCoreConfigSkeleton version was added later. KConfigDialog does not have a constructor yet with KCoreConfigSkeleton argument type yet; it has probably somehow been missed so far. Changing the current constructor to KCoreConfigSkeleton usage is not possible in the 4.X major version because of the consequences (ABI breakage). Thereby, the freshly replacated constructor. The proper fix can be filed against frameworks where there is only one, and properly working constructor. Diffs - kdeui/dialogs/kconfigdialog.h 2ac0eda kdeui/dialogs/kconfigdialog.cpp e815e54 Diff: http://git.reviewboard.kde.org/r/103716/diff/diff Testing --- On Archlinux (build test only) Thanks, Laszlo Papp
Re: Review Request: Replicate the existing KConfigDialog constructor and change one argument type
On Jan. 17, 2012, 10:28 p.m., David Faure wrote: The kdeui module is unlikely welcome on mobile platforms Why is this review about adding stuff to kdeui, then? I don't get it. Either you're using it or you're not using it -- or the real reason is core/gui split in your libs/apps, which would be a valid point. Laszlo Papp wrote: The desktop application uses kdeui. KConfigDialog (QWidget *parent, const QString name, KConfigSkeleton *config) - It is now impossible to generate only one settings class inheriting KCoreConfigSkeleton, and use that in each frontend. I would not like to generate distinct settings classes without no real reasons. Also, I discarded this patch because it is possible to make this API addition to 4.X. See my patch in frameworks. It is impossible to make this API addition to 4.X* - Laszlo --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103716/#review9903 --- On Jan. 17, 2012, 3:54 p.m., Laszlo Papp wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103716/ --- (Updated Jan. 17, 2012, 3:54 p.m.) Review request for kdelibs and Jeremy Paul Whiting. Description --- Use case: there are applications like kanagram which would be nice to have running on several platforms, like handsets; for instance Harmattan on N9. It would be nice to use the same settings code generation in certain cases for all the platforms since the additions of KConfigSkeleton on the top of KCoreConfigSkeleton are the font and color settings. These are currently not used in many KDE applications. Hence, it should not be mandatory. The kdeui module is unlikely welcome on mobile platforms, especially in appstores with its sizes and complexity for no real need. KConfigDialogManager has apparently already two constructors; one with KConfigSkeleton argument type, and yet another with KCoreConfigSkeleton. It looks like a situation where the KCoreConfigSkeleton version was added later. KConfigDialog does not have a constructor yet with KCoreConfigSkeleton argument type yet; it has probably somehow been missed so far. Changing the current constructor to KCoreConfigSkeleton usage is not possible in the 4.X major version because of the consequences (ABI breakage). Thereby, the freshly replacated constructor. The proper fix can be filed against frameworks where there is only one, and properly working constructor. Diffs - kdeui/dialogs/kconfigdialog.h 2ac0eda kdeui/dialogs/kconfigdialog.cpp e815e54 Diff: http://git.reviewboard.kde.org/r/103716/diff/diff Testing --- On Archlinux (build test only) Thanks, Laszlo Papp
Re: hard-dep for Qt 4.8
On Wednesday 18 January 2012 06.35.57 Martin Gräßlin wrote: I didn't say that this is a reason. I wanted to highlight the problem of not depending on 4.8 and everybody using 4.8. I'm not going to start reviewing code for is this a Qt 4.8 change. Martin, if you remember there are a lot of people using KDE that are not 'core' developers. Typically they are one-time developers, they are artists, they are translators etc. I just wanted to point this out since your attitude can easily be mistaken as not caring about the people that are not able to do the Qt upgrade. I do believe you care, and thats why I think its important to indeed put in that little bit of extra time to make sure we don't use Qt4.8 APIs. Or just respond fast to a person noticing the compilation issue. Its not a whole lot of effort, as far as I can tell, but it does have a pretty big influence on our community members that may not have the computer power or computer savy or just the time you have. thanks :) -- Thomas Zander
