Rubik is a great theme, and I understand the space-saving benefits of the pop-ups, but in practice they make the theme unusable for me. My problem is that many field descriptions can contain really critical information, and I feel that the pop-ups make that information too hard to see.
I'm proposing that this feature be made optional. The pop-ups would still be enabled by default, but it would be possible to switch them off and display the descriptions inline, if people wished to do that.
(For cross-referencing, this is related to #928890: Popups for long description text falls off-screen; however that was raised for 6.x-3.x, and I didn't want to change those versions).
Comment | File | Size | Author |
---|---|---|---|
#10 | rubik_inline_field_desc-1730844-10.patch | 2.49 KB | jweowu |
#8 | rubik_inline_field_desc-1730844-06.patch | 2.52 KB | sylus |
#5 | rubik-inline_field_descriptions-1730844-05.patch | 2.52 KB | sylus |
#4 | inline_field_descriptions-1730844-4.patch | 2.43 KB | sylus |
#1 | inline_field_descriptions-1730844-1.patch | 2.44 KB | jweowu |
Comments
Comment #1
jweowu CreditAttribution: jweowu commentedComment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedI agree, this feature should be optional. Applied the patch and it seems to work. Thank you!
Comment #3
Poieo CreditAttribution: Poieo commented+1 to add this feature. Some descriptions, such as those containing token information, are unusable in a popup.
Comment #4
sylus CreditAttribution: sylus commentedAttaching an updated patch for latest dev
Comment #5
sylus CreditAttribution: sylus commentedPatch without whitespaces
Comment #6
Anonymous (not verified) CreditAttribution: Anonymous commentedHey there. Thanks for the patch. I applied and it worked. But the state of the checkbox doesn't get saved, meaning, when I check the checkbox and save the settings, the setting is being saved in the database, but the checkbox appears unchecked. Descriptions are being displayed inline tho.
Comment #7
jweowu CreditAttribution: jweowu commentedgenox: Both cases call
theme_get_setting()
to determine whether the setting is enabled. The only difference is that in the settings form it specifies the name of the theme explicitly (as Rubik may not be the current admin theme).You're not using some kind of renamed copy of Rubik, or a sub-theme or some such?
Comment #8
sylus CreditAttribution: sylus commentedFor some reason last patch wasn't applying in Travis. Trying this one
Comment #9
pioterkoper CreditAttribution: pioterkoper commentedsylus! great patch
Comment #10
jweowu CreditAttribution: jweowu commented#8 introduces an indentation oddity into the patch, so I'm re-rolling to clean that up.
Comment #11
jweowu CreditAttribution: jweowu commentedJust bumping this, as Rubik seems to have some current maintainer activity (which is excellent).
I'd appreciate review from anyone who has been using this, as we're still in a "needs review" state. I've certainly used this with no apparent issues in multiple projects since writing it, and it seems that others are using it happily as well.
If you'd like to see it committed, now would seem like a good time to help it happen.
Comment #12
haydeniv CreditAttribution: haydeniv commentedThis looks pretty sane to me.
Committed: 91e1a47
Thanks!
Comment #13
jweowu CreditAttribution: jweowu commentedExcellent; thank you haydeniv.
p.s. Since the move to Git it's become pretty common for contrib commits to differentiate the author of a patch from the maintainer who committed it. That way committed patches get associated with the author internally and appear in their "Your Commits" dashboard list, etc, which is nice.
The Drupal docs for this are: https://drupal.org/node/1146430
Comment #15
R-H CreditAttribution: R-H commentedThanks for fixing this!