Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Could you perhaps at least add a variable_get with a default for the icon size in the widget?
Best would be of course to have an option in the field for that.
Currently we've hacked the module to make the icons larger.
Comments
Comment #2
thomas.frobieterOr simply add font-size:22px; or somtehing inside the iconpicker.module - ln. 122.
I don't think this needs to be configurable as it's only for the backend.
Comment #3
K3vin_nl CreditAttribution: K3vin_nl as a volunteer commentedAnybody, just curious as why you would want this? Are the icons too small to recognise? I always have a lot of icons available, so by making the icons larger the overview would get very long in my case.
Anyhow, I just made a new release in which the inline styles are in a variable, so you can override it now, without hacking the module!
Feel free to test and provide feedback.
Comment #4
AnybodyThank you very very much. Yes the icons were too small for our case. We don't have that many in this case and you could not see clear enough what the icons were looking like.
I'm happy to try the dev now :) Thank you very much!
Comment #5
AnybodyWell, if you're using styles for that wouldn't it then make sense to simply use an iconpicker.admin.css file and include that as form attachment?
This way the size can be cleanly overridden an you don't even need the variable anymore. Just as an idea...
As BUG: You're using "iconpicker_icon_inline_style" for $inline_icon_style and $inline_label_style. The second should be iconpicker_label_inline_style instead.
Comment #6
K3vin_nl CreditAttribution: K3vin_nl as a volunteer commentedThanks, for the bug report. I'll fix that.
The reason I don't use an admin.css file is because it doesn't work in all cases. The inline styles are (very) ugly, but reliable. But I agree that an external CSS file would be the preferable solution.
For example I am using icons in a panel style and as panel pane fields. In both cases ctools special form handling caused the CSS not to get attached.
Comment #7
AnybodyOkay thank you for that information. Then it would be enough perhaps to add a font-size variable. It's 22px for example in our case to have the icons a bit larger. That way we don't have to override the whole string.
Comment #8
K3vin_nl CreditAttribution: K3vin_nl as a volunteer commented@Anybody, I have just pushed a new alpha2 version in which the icon preview sizes are configurable per bundle. This nicer then overriding the whole inline CSS via a variable.
Let me know if you have any feedback!
Comment #9
AnybodyThank you very much. The setting now appears.
I think there is still an issue left: The options are just text, but the size should be an integer instead?
See:
<== I think it misses an integer index?
For example use:
?
Comment #10
AnybodyFurthermore the value doesn't seem to be saved. It's always 1 (default) for me after saving and reloading the form.
EDIT: Sorry it works correctly, the problem was FF+zoom, see below.
Comment #11
AnybodyOK finally... zoom is not supported in FF ("The zoom property in CSS allows you to scale your content. It is non-standard, and was originally implemented only in Internet Explorer. "), so we would suggest to use font-size instead.
What was the reason to use zoom? Non-font-based icons?
This is our suggestion:
plus
Comment #12
K3vin_nl CreditAttribution: K3vin_nl as a volunteer commented@Anybody,
Thanks for the feedback. Yes, I used zoom, as it seemed to be the most robust way of enlarging icons because icons can be font-based, image based or even SVG based.
I'll try to think of a solution that is as robust, but would also work in Firefox.