By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 926 - kcontrol -> Peripherals -> Mouse -> General -> Double-click (Does NOT require TDE restart)
Summary: kcontrol -> Peripherals -> Mouse -> General -> Double-click (Does NOT require...
Status: NEEDINFO
Alias: None
Product: TDE
Classification: Unclassified
Component: tdelibs (show other bugs)
Version: R14.0.x [Trinity]
Hardware: All Linux
: P5 minor
Assignee: Timothy Pearson
URL:
Depends on:
Blocks:
 
Reported: 2012-03-22 11:38 CDT by David C. Rankin
Modified: 2018-05-27 11:00 CDT (History)
3 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David C. Rankin 2012-03-22 11:38:05 CDT
Interesting bug,

  When setting the single-click/double-click mouse behavior, you receive the dialog noting that this feature does not take effect until KDE is restarted (or something to that effect) with the [ ] do not show this dialog next time checkbox. That isn't correct at all. The mouse click selection is effective immediately. The dialog should not be displayed for this change.

  Not a biggie, but the dialog display as well as the KDE->TDE change to this dialog should be fixed.
Comment 1 Darrell 2012-03-22 11:44:54 CDT
I'm guessing the dialog appears globally for any mouse module change. One dialog to rule them all....
Comment 2 Darrell 2012-03-24 15:41:03 CDT
Have tested which options do require restarting the session? I am sure that changing the mouse pointer theme requires a restart. If we can populate a list then that will help whoever writes a patch.
Comment 3 Darrell 2013-04-07 12:44:15 CDT
Regarding the comment about updating the dialog for TDE rebranding, this was done some time ago. :)
Comment 4 Darrell 2013-04-07 13:01:56 CDT
Note: the underlying rc setting is in kcontrolrc -> [Notification Messages] -> CursorSettingsChanged.
Comment 5 Michele Calgaro 2014-03-05 03:16:48 CST
David, Darrell,
is this bug still valid?
I tried on my system and I don't have that dialog popping out. I don't know/don't remember if in the past I checked the "do not show this dialog again" checkbox.
Could you give it a try on your system as well?
Comment 6 Darrell 2014-03-05 14:31:23 CST
This particular dialog does not appear after being disabled. While some apps have a GUI config option for toggling [Notification Messages], many apps do not. To restore this specific dialog requires manually editing the appropriate rc file.

To test this specific dialog requires starting Trinity with a new profile --- the dialog still appears. In this instance the dialog is technically incorrect because restarting is not required.

Likewise, toggling the Button Order results in the same dialog and again is technically incorrect because restarting is not required.

As mentioned in comment 1, apparently changing any option in the mouse module triggers the dialog, whether or not the dialog is true, which most often is not because a restart is not required. To my knowledge, the dialog should rarely appear, if at all. Bug 1437 addresses the issue that changing the mouse cursor requires a TDE restart, but other desktop environments do not require a restart. That bug report remains unresolved.

That said, there seems to be a new bug associated with the dialog of this bug report.

With a new profile, after acknowledging the dialog, and NOT enabling "Do not show this message again," the dialog never again appears. The new bug appears to be related to whether the contents of kcminputrc is read. Seems the moment kcminputrc is populated the dialog appears once and only once. My guess is kcminputrc is parsed and then the code never continues thereafter. I tested deleting kcminputrc and the dialog again appears once but only once.

To my recollection, whether to show this specific dialog was determined in kcontrolrc [Notification Messages] CursorSettingsChanged=true. I now notice that with a new profile this value is never set. Manually adding the key and value does not change anything --- the dialog never again reappears after the first showing.

To resolve this bug report:

* Determine why the dialog now incorrectly appears only once.

* Determine which mouse module options truly require restarting Trinity and show the dialog only for those options.
Comment 7 Darrell 2014-03-06 15:19:01 CST
I now suspect the warning dialog never worked correctly. I tested in 3.5.10 and 3.5.13.2 with a new profile. The dialog never reappears after the first instance, even when not enabling the check box to not show again.

When I enable the check box, which I am able to do only during the first instance, then a CursorSettingsChanged=false entry is made in konctrolrc. Manually editing kcontrolrc to true has no effect.
Comment 8 Darrell 2014-03-06 16:28:08 CST
Forget my previous comment. I believe I understand what is happening.

If I understand the gist of the dialog code, this dialog should appear only when making changes to the mouse theme and not for any other section of the mouse module. Refer to tdebase/kcontrol/input/xcursor/themepage.cpp and tdebase/kcontrol/input/core/themepage.cpp. This expected behavior is also how this discussion has unfolded. That is, the dialog is neither expected nor desired unless restarting TDE is truly required.

(Note: Bug 1437 addresses the issue of needing to restart TDE when changing the mouse theme. Other environments do not require restarting to change the mouse theme.)

In short, the expected and desired behavior is the dialog appears only when modifying the mouse cursor theme.

The actual behavior is the dialog always appears the very first time a user makes ANY mouse module change, but then behaves as expected and desired thereafter.

To test this, when I edited kcontrolrc [Notification Messages] CursorSettingsChanged=true, and then changed the cursor theme, the dialog appears repeatedly, as expected.

That the dialog appears the very first time the user opens the mouse module is the only bug to be resolved for this report. The dialog should not appear at all unless the user makes changes to the mouse theme.

I suspect the cause of the dialog appearing the very first time is kcminputrc does not yet exist. Specifically, the kcminputrc [Mouse] cursorTheme key does not exist. Having a value is irrelevant.

Upon the very first usage of the mouse module, I suspect the code tries to parse [Mouse] cursorTheme, finds no key, and that incorrectly triggers the dialog, despite the user not accessing the mouse theme tab. When the user selects the Apply button, then kcminputrc [Mouse] cursorTheme is created for the first time, although with no value. The code is responding to the non-existence of [Mouse] cursorTheme rather than ignoring that non-existence.

To test that theory, I started Trinity with a new profile. I did not immediately open kcontrol or the mouse module. I then manually created kcminputrc and [Mouse] cursorTheme. I assigned no value to [Mouse] cursorTheme. I only created the key. I did not create a CursorSettingsChanged key in kcontrolrc. Then I opened the mouse module for the first time. The dialog did not appear when I made changes other than theme changes. The dialog did appear as expected each time I changed the cursor theme.

Resolution:

Any of the following will suffice.

Fix the code to not show the dialog when the [Mouse] cursorTheme key does not exist --- unless the user actually changes the cursor theme. Non-existence of the cursorTheme key should be treated the same as the key existing with no value.

Modify the starttde script to create a base kcminputrc when starting TDE the very first time, to include [Mouse] cursorTheme. No value is needed --- just the empty key.

Create a default kcminputrc that contains [Mouse] cursorTheme with no value.