|
Bugzilla – Full Text Bug Listing |
| Summary: | desktop B/G capplet race ... | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Michael Meeks <mmeeks> |
| Component: | GNOME | Assignee: | E-mail List <gnome-bugs> |
| Status: | RESOLVED WORKSFORME | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | ||
| Version: | Beta 3 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | inconsistent setting ... | ||
|
Description
Michael Meeks
2005-08-25 15:37:24 UTC
Created attachment 47637 [details]
inconsistent setting ...
I am unable to reproduce the issue on 9.3 or a source build of upstream 2.11 tarballs. I was also unable to see this problem on Mark's SL10 test laptop. I would presume that if the g_source_remove () is not working, then perhaps something changed in glib with regards to timeout API? The timeout is slightly longer than the keyboard repeat timeout, so that if you hold down the arrow key, the capplet does not cycle through all of the images and their settings, passing them all off to gconf. Even if you somehow managed to select a new image immediately after the timeout went past its bounds and started to do the commit to gconf, the timeout would get removed with the new selection, which would get a new timeout, and then would update gconf for the new image. I'm resolving this as WORKSFORME since I have no idea what the two extra fields next to NEEDINFO are for. I'm running the stock GNOME build in Beta3, I'm using the mouse to select the backgrounds, often selecting A, B, C, B in quick succession; although possible just some Large, Small pattern. Reopening - "doesn't work for me" ;-) I've been trying to replicate this as well, and can't either. I can't see it either anymore; closed. |