After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 545244 - Setting some *-set properties to FALSE in GtkCellRendererText causes loosing a corresponding property value
Setting some *-set properties to FALSE in GtkCellRendererText causes loosing ...
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: Other
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2008-07-29 01:42 UTC by Pavel Kostyuchenko
Modified: 2011-12-30 06:04 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Patch (6.59 KB, patch)
2008-07-29 01:43 UTC, Pavel Kostyuchenko 		none Details | Review

Description Pavel Kostyuchenko 2008-07-29 01:42:26 UTC 
So some software, that uses *-set properties to control reflection of data in a tree view, fails to do that correctly
Comment 1 Pavel Kostyuchenko 2008-07-29 01:43:06 UTC 
Created attachment 115465 [details] [review]
Patch
Comment 2 Matthias Clasen 2008-08-01 19:00:15 UTC 
I'm pretty sure that was an intentional change; the -set properties are not meant to be used like that. Kris, correct me if I'm wrong.
Comment 3 Pavel Kostyuchenko 2008-08-01 20:06:24 UTC 
(In reply to comment #2)
> I'm pretty sure that was an intentional change; the -set properties are not
> meant to be used like that

All other *-set properties seems to work as I expect.
Comment 4 Owen Taylor 2008-08-01 20:21:11 UTC 
It was certainly never intended that setting a *-set property to TRUE
would give you a predictable result.

The whole point of them is to be able to set them to FALSE to reset
back to the default unset state.
Comment 5 Pavel Kostyuchenko 2008-08-09 16:44:24 UTC 
(In reply to comment #4)
> It was certainly never intended that setting a *-set property to TRUE
> would give you a predictable result.
> 
> The whole point of them is to be able to set them to FALSE to reset
> back to the default unset state.

If the result of setting that property to TRUE is undefined, why don't you define it? That will not break API, but will give more consistency.