Font awesome

Font awesome

by Damyon Wiese -
Number of replies: 14

One of the things on the list of Moodle 3.3 is core support for font-awesome. I am working on the branch on https://tracker.moodle.org/browse/MDL-40759 and there is a prototype available here: http://prototype.moodle.net/fontawesome/

Some key things that we can do better by having font-awesome in core rather than just in a theme are:

* Fix all the places using image tags with pix_url (this was a big job)

* Allow plugins to implement a callback mapping their own icons from a Moodle icon name to a font-awesome one.

There are other icon fonts and other things than icon fonts (inline svg with "use" etc). This design allows the theme to specify which of the core icon_systems they want to support - and we can add more to core in future. Note: The javascript to get this to work from templates is very tricky - and no it's not possible to add a new icon system in a plugin.

Regards, Damyon



Average of ratings: Useful (4)
In reply to Damyon Wiese

Re: Font awesome

by Gareth J Barnard -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers

Hi Damyon,

This is excellent news!  Thanks for all of your efforts on this so far.

Will the problem with AJAX JS injecting the image rather than calling 'render_pix_icon' in the 'core_renderer' be fixed?

In the callback mechanism can themes specify another font with mapping instead of svg with mapping?

Do you need more than one peer reviewer?

Kind regards,

Gareth

Average of ratings: -
In reply to Gareth J Barnard

Re: Font awesome

by Damyon Wiese -

Hi Gareth,

Icons rendered with javascript are fine as long as they are using either the pix helper from mustach {{#pix}} or the new function in the core/templates module "renderIcon". I updated most places in core so they are fine (drag and drop, glossay filter, atto plugins etc). The ones I didn't do were filepicker/filebrowser as it would have broken backwards compatibility for repository plugins which are expected to return urls to icons and the code in there is very old and fragile so once I start making changes there it would lead to a rewrite (which we do need to do at some point - but not in this issue).


It would be possible (if a little tricky) to add a completely new icon system in a theme using this patch. You would need to implement a php class extending \core\output\icon_system and in that class return the name of a new javascript AMD module extending core/icon_system. The theme config value is the class name of the php class extending \core\output\icon_system - it does not have to be in core. 

I say tricky because it is tricky to implement the AMD module correctly as it has to pre-fetch anything it needs from the server in the init() in order to guarantee that calls to renderIcon are synchronous (which is required by the mustache library). This was fiddly to get right for me - but it's working now.

I did think about converting the font-awesome icons into a set of SVGs and they make an "inline-svg" icon system - but I tested the rendering of both and they were identical for both big and small icons (even on a retina screen). The downside would be that teachers could not embed font-awesome icons in their content easily so I didn't do it. 



Average of ratings: Useful (2)
In reply to Damyon Wiese

Re: Font awesome

by Gareth J Barnard -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers

Thanks Damyon,

Really helpful to know the class names so I can look at the specific code areas.  I'm wondering why with "new javascript AMD module extending core/icon_system" there is so much client side logic?  Am I missing something or would it not be simpler just to define server side icon definitions and have the client side AJAX JS call the server and get the class name back instead of the icon?  Then as font icon systems use CSS (and not being inline) then can use that method.  Then at the server have a 'mapping method' to map Moodle icon concept to font icon class which could be overridden in the theme.  That method could then be used when rendering the whole page (via Mustache too) and by AJAX calls.

Why so much pre-fetching?  Is it not the case that you render the page and then only need to get a new set when something like the Site Administration menu is opened - which only happens when it happens.

Cheers,

Gareth

Average of ratings: -
In reply to Gareth J Barnard

Re: Font awesome

by Damyon Wiese -

No it's more complicated than that. Client side JS can render a mustache template at any time - and in that template could be calls to the pix helper {{#pix}}{{/pix}}. Because of the mustache library we use in JS - those calls to the pix helper need to resolve synchronously - which means we need to know in JS the mapping of all core icon names to font awesome icon names. We only define these once - in PHP - but we have a webservice the JS calls to fetch the full list (including any ones added by the plugin callbacks). We cache this in local storage in the browser so it's only ever fetched once per user until the Moodle caches are purged.





Average of ratings: -
In reply to Damyon Wiese

Re: Font awesome

by Gareth J Barnard -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers

Hi Damyon,

Thank you for your reply.  This area of client server communication is fascinating.  I hope one day that JavaScript becomes multi-threaded and evolves to have better scope containment.

I wonder if Mustache could be enhanced to be asynchronous as most things are in a client server setup?

Kind regards,

Gareth

Average of ratings: -
In reply to Gareth J Barnard

Re: Font awesome

by Damyon Wiese -

Yes the mustache library could easily use promises - but it is third party code and we do not modify third party code and they have not been accepting of our previous upstream patches. 

See: https://github.com/janl/mustache.js/issues/544

Average of ratings: -
In reply to Damyon Wiese

Re: Font awesome

by Gareth J Barnard -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers

Thanks Damyon,

Out of curiosity is there an OO way to extend Mustache without actually changing their code but rather add Moodle code on top but separated?

And any idea why they are not accepting the patches?

Cheers,

Gareth

Average of ratings: -
In reply to Gareth J Barnard

Re: Font awesome

by Damyon Wiese -

No not really. It would be feasible for us to switch to another JS mustache implementation if that became a bigger issue.

Average of ratings: -
In reply to Damyon Wiese

Re: Font awesome

by Mary Evans -
Picture of Core developers Picture of Documentation writers Picture of Peer reviewers Picture of Plugin developers Picture of Testers

Hi Damyon,

Thanks for the link to the prototype site...however none of the login user ID /Password listed work.

Thanks

Mary

Average of ratings: -
In reply to Mary Evans

Re: Font awesome

by Damyon Wiese -
Yes when I set it up the first time the logins were broken - they should be fixed now. There was also a weird caching issue breaking the icons for Atto - but that should be sorted now too.



Average of ratings: -
In reply to Damyon Wiese

Re: Font awesome

by Jean-Roch Meurisse -
Picture of Core developers Picture of Plugin developers Picture of Testers

Hi Damyon,

It's very easy to add more mappings in plugins, that's really good !!!

But since the function calling the plugins callbacks makes a union of core map and pluginmap, there is no way to override a core mapping, am I right?

Regards, Jean-Roch

Average of ratings: -
In reply to Jean-Roch Meurisse

Re: Font awesome

by Damyon Wiese -

It would be possible in a theme (by subclassing the lib/classes/output/icon_system_fontawesome.php), but not a regular plugin. This is intended - and consistent with the inheritance model for all things output (templates / renderers etc).

 



Average of ratings: -
In reply to Damyon Wiese

Re: Font awesome

by Jean-Roch Meurisse -
Picture of Core developers Picture of Plugin developers Picture of Testers

Thanks for your answer,

I totally agree that regular plugins should not override mappings.

As for themes, may be it could be allowed without subclassing by testing plugintype in "get_icon_name_map" loop and running an array_merge for theme callbacks and union for other plugin types

Regards

Average of ratings: -