Version: 1.0 (using KDE 4.6.2) OS: Linux In KGpg in Settings >> Configure KGpg... The "Apply" button is always available to press. Even if you have not made any configuration changes it can still be pressed. And if you press it, it does not gray out, it remains pressable. Reproducible: Always Steps to Reproduce: Open KGpg In the Settings menu select "Configure KGpg..." Click the "Apply" button or alternatively: make a change to the config Click the "Apply" button Actual Results: Apply button is still pressable no matter what. Expected Results: When the Settings window opens, Apply should be grayed out. If you change something, it becomes available. Then if you want to apply the changes you made, you can press it, and after that it grays out. OS: Linux (i686) release 2.6.35-28-generic Compiler: cc I'm using Kubuntu 10.10 with KDE 4.6.2 The version of KGpg is 2.5.0
Confirmed in 4.6.2 (kubuntu 10.10) and master compiled from sources
SVN commit 1228398 by dakon: use proper method visibility Please test and see if this makes it any better. For me (openSUSE 11.3, KDE 4.6.2) it is working fine even without that change. CCBUG:270919 M +5 -4 kgpgoptions.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1228398
Tested with kgpgoptions.h r1228400 in trunk. The Apply button is still always enabled.
Can you please add a kDebug() into that hasChanged() implementation and check if it is called at all? Please run KGpg from a terminal and send the complete output.
Added kDebug(); at the beginning of kgpgOptions::hasChanged(), it is called everytime I press the Apply button. I have added a enableButtonApply(false); at the end of kgpgOptions::kgpgOptions in kgpg/kgpgoptions.cpp. Now the behaviour of the Apply button is correct for all options exceot the "The following widgets are managed manually." in kgpg/kgpgoptions.cpp.
Do those manually managed items work if you revert your change? For me it looks a bit as if the enable-thing somehow works reverted for you. Has *buntu somehow patched the kdelibs to get some special look&feel or something like that?
I can open a bug in ubuntu to track this in case the problem is a patch that ubuntu applied.
Just so that noone get's me wrong: I don't know _if_ it's a *buntu bug/patch/change. I only see both of you having some of those distros and the problem while I'm using openSUSE and don't see anything. And I have absolutely no idea what's going on.
Also, I've updated my system to Kubuntu 11.04 and KDE 4.6.3. The bug still exists (although KGpg has not changed version). I've opened a bug report there, and referenced this bug report, perhaps that will help. Maybe it is *buntu specific.
One last thing: I've encountered this in KMail. Perhaps it is related? The report for that one is: Bug 273896
Since those mainly works for me it definitely looks as if there is something wrong in the "lower levels". Please add the URL to the Ubuntu bug here.
https://bugs.launchpad.net/kdeutils/+bug/790801
(In reply to comment #8) > I only see both of you having some of those distros No, as i said in comment #1 and #3 also master compiled from sources
Checked again with a openSUSE 11.4 kde 4.6.0 in a virtual machine, the "Apply" button is always enabled, and never is greyed out even if I press it.
Sorry did not check this issue thorougly enough: Running kgpg for the first time (no kgpgrc file, skip key generation in assistant) on openSUSE 11.4 kde 4.6.0 in the virtual machine the apply button is always enabled. But once the Apply or OK button in the settings dialog is pressed - with or without a change - the Apply button behaves as expected, really strange. @ Eike: This is reproducable here, I just have to rm kgpgrc. Please mv your kgpgrc and you should be able to reproduce that as well.
What's the current state of this?
Still reproducible for me with KGpg 2.12.1 (KDE 4.13.1 on openSUSE 13.1).
Still reproducible for me with KGpg 2.17.0 (KDE 4.14.18 on openSUSE 42.1).
KGpg 2.17.40 4.14.16 in a VM Neon with Applications 16.08.1 not reproducible for me
Is this still a problem? I don't see it with version 23.08.3 on Gentoo Linux.