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 694831 - GtkEntry provides no visual feedback when editable=FALSE
GtkEntry provides no visual feedback when editable=FALSE
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkEntry
3.6.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2013-02-28 00:57 UTC by David Trowbridge
Modified: 2013-09-18 13:41 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Patch (1.95 KB, patch)
2013-02-28 00:57 UTC, David Trowbridge 		needs-work Details | Review
Screenshot of results (15.92 KB, image/png)
2013-02-28 01:04 UTC, David Trowbridge 		  Details
Implementation which uses a read-only class in the style. (2.68 KB, patch)
2013-03-21 23:31 UTC, David Trowbridge 		needs-work Details | Review
Patch v3 (2.83 KB, patch)
2013-05-30 19:29 UTC, David Trowbridge 		committed Details | Review

Description David Trowbridge 2013-02-28 00:57:13 UTC 
Created attachment 237574 [details] [review]
Patch

GtkEntry currently draws exactly the same no matter what the state of the 'editable' property. This is pretty confusing for users because there's no visual feedback at all, it just seems like their keyboard is broken.

Until now, we've solved this problem with the "DeadEntry" widget in libview. I don't know why nobody ever thought to just fix the issue upstream. Here's a patch to do that.
Comment 1 David Trowbridge 2013-02-28 01:04:17 UTC 
Created attachment 237575 [details]
Screenshot of results
Comment 2 Matthias Clasen 2013-02-28 12:15:05 UTC 
It makes a lot of sense to me, visually. Maybe we can implement this in a better way. Benjamin ?
Comment 3 Cosimo Cecchi 2013-02-28 14:05:26 UTC 
I agree it would be nice to be able to detect that case from the theme and style it differently.
I don't think (ab)using the insensitive state for this is a good idea though. I think for how other similar states are implemented in GTK, the best way forward is applying an extra style class (e.g. "read-only" or "inert").
Comment 4 Matthias Clasen 2013-03-05 01:59:34 UTC 
Review of attachment 237574 [details] [review]:

make as needswork, accordingly
Comment 5 David Trowbridge 2013-03-21 23:31:30 UTC 
Created attachment 239505 [details] [review]
Implementation which uses a read-only class in the style.
Comment 6 David Trowbridge 2013-04-05 23:39:28 UTC 
Any feedback on the new implementation?
Comment 7 Matthias Clasen 2013-05-13 01:31:57 UTC 
Review of attachment 239505 [details] [review]:

Rather than using style_context_save/restore in draw(), we should add/remove the style class when the editable property is set/unset.
Other than that, looks good
Comment 8 David Trowbridge 2013-05-30 19:29:55 UTC 
Created attachment 245671 [details] [review]
Patch v3

OK, the new patch modifies the style context when the property is changed.
Comment 9 David Trowbridge 2013-06-28 23:00:28 UTC 
Ping?
Comment 10 Matthias Clasen 2013-08-10 14:23:33 UTC 
sorry for the delay, put on my review queue now
Comment 11 Matthias Clasen 2013-08-19 17:37:41 UTC 
Review of attachment 245671 [details] [review]:

looks fine
Comment 12 Andrés G. Aragoneses (IRC: knocte) 2013-08-31 11:45:22 UTC 
Given that widget states normally map to CSS pseudoclasses (not classes), shouldn't this patch use a pseudoclass as well?
Comment 13 Andrés G. Aragoneses (IRC: knocte) 2013-09-18 13:41:05 UTC 
FYI I contributed a fix for Ubuntu's default theme regarding this change: https://bugs.launchpad.net/bugs/1219205

Still, it would be great if I could get some feedback about comment#12 :) Thanks