Redmine

Marius BALTEANU wrote:

2. Only from css

Advantages:

• the views will not be modified

Disadvantages:

• The build-in rules must be reimplemented in the current CSS
• The icons will be defined using their unicode. For example, the fa-pencil icon (similar with the current images for icon-edit) has the unicode f040.

The "disadvantages" word should be after the first advantage. Like is in this comment.

Hi Marius, thanks for proposing this. I think replacing the current icon set with an icon font is a great idea. As you noticed, we're using Font Awesome for the new Planio design.

Marius BALTEANU wrote:

because there are at least two ways to implement them, we want some feedback

Before implementing our new design, we were discussing this intensively. We decided against using <i> tags and in favour of adding new CSS rules, for the following reasons:

• Changing all icons in Redmine to <i> tags would be a very large patch touching almost all views in Redmine (as you probably already noticed while preparing your demo patch).
• Using <i> tags would require all plugin developers to change plugins as well and there would be a (potentially long) period where plugins would still use the "old" icons while Redmine is already usig "new" icons making the overall user experience inconsistent.

Implementing new CSS rules for all icons using Font Awesome, however, would be less of a change to existing Redmine code (we would be able to leave views alone) and would apply to all existing plugins using standard Redmine icons (like edit, delete, etc.) at once, so plugin developers would have few things to change or nothing at all.

To respond to the disadvantages mentioned:

The build-in rules must be reimplemented in the current CSS

I actually see this as an advantage: implementing Icon style can be encapsulated in a defined place within the CSS and does not happen all over the place.

The icons will be defined using their unicode. For example, the fa-pencil icon (similar with the current images for icon-edit) has the unicode f040.

From our experience in working with Font Awesome in our new UI, it isn't much of a problem. The icons can be looked up easily via http://fontawesome.io/icons/ and we could use CSS comments to note the Font Awesome icon names next to the unicodes.

One sidenote: At Planio, we're using Rails' Asset Pipeline with Redmine and are thus using SCSS and the fontawesome-rails gem which is a tremendous help.

Jan from Planio www.plan.io wrote:

Hi Marius, thanks for proposing this. I think replacing the current icon set with an icon font is a great idea. As you noticed, we're using Font Awesome for the new Planio design.

Marius BALTEANU wrote:

because there are at least two ways to implement them, we want some feedback

Before implementing our new design, we were discussing this intensively. We decided against using <i> tags and in favour of adding new CSS rules, for the following reasons:

• Changing all icons in Redmine to <i> tags would be a very large patch touching almost all views in Redmine (as you probably already noticed while preparing your demo patch).
• Using <i> tags would require all plugin developers to change plugins as well and there would be a (potentially long) period where plugins would still use the "old" icons while Redmine is already usig "new" icons making the overall user experience inconsistent.

Implementing new CSS rules for all icons using Font Awesome, however, would be less of a change to existing Redmine code (we would be able to leave views alone) and would apply to all existing plugins using standard Redmine icons (like edit, delete, etc.) at once, so plugin developers would have few things to change or nothing at all.

To respond to the disadvantages mentioned:

The build-in rules must be reimplemented in the current CSS

I actually see this as an advantage: implementing Icon style can be encapsulated in a defined place within the CSS and does not happen all over the place.

The icons will be defined using their unicode. For example, the fa-pencil icon (similar with the current images for icon-edit) has the unicode f040.

From our experience in working with Font Awesome in our new UI, it isn't much of a problem. The icons can be looked up easily via http://fontawesome.io/icons/ and we could use CSS comments to note the Font Awesome icon names next to the unicodes.

Totally agree with you, I'll try to create a patch using only CSS.

One sidenote: At Planio, we're using Rails' Asset Pipeline with Redmine and are thus using SCSS and the fontawesome-rails gem which is a tremendous help.

I know that were some discussions about the Rails' Asset Pipeline (I can't find the ticket now) and enabling this feature is not an option because will add some complexity. If I'm wrong, I'll be very happy to use that gem.

Thanks for your feedback.

I would prefer the Font-Mfizz solution. It does not require much more server load using it (there are a lot less server requests compared to the background image solution). Main reason for this solutions is, that the usability and the user acceptance would be higher. A lot of technical teams are working with Redmine and SCM, and these people will be certainly happy to see file type specific icons.

We discussed internally in Zitec and we are going to implement the solution with Font-Mfizz but for the moment we are waiting for some feedback on issue #24313 because having that ticket commited, it will be much easier for us to implement this one.

Go MAEDA wrote:

#24313 has been implemented.
I am looking forward to seeing this feature in 3.4.0. Setting target version to "Candidate for next major release".

The patch that replaces the images with fa icons is ready, but I want to take some feedback from our users regarding the icons color. Now all the icons have the same color (# 169). Please let me know if you want to test it as it is now.

Any feedback on this patch? FTR, I tried to create a single patch with all the changes with Subversion too but it didn't work.

Jean-Philippe, do you have any feedback on this?

This patch is a great improvement to Redmine. It extends the variety of icons available to developers of plugins and Redmine itself. It's a pitty that there hasn't been more discussion about this improvement for a year now.

Unfortunately this patch doesn't work anymore.
Marius Ionescu BALTEANU is it possible to update this patch to a recent revision of Redmine? I would really love to see this patch applied in 4.0.0 or 4.1.0.

+1 for this!

Bernhard Rohloff wrote:

Marius Ionescu BALTEANU is it possible to update this patch to a recent revision of Redmine? I would really love to see this patch applied in 4.0.0 or 4.1.0.

Sure, I'll try to do it this month (including the update to Font Awesome 5).

GitHub changed from Icon fonts to SVG icons.
Icon fonts is not bad, but I think it will be better if you change to SVG icons.

Taiki IKEGAME wrote:

GitHub changed from Icon fonts to SVG icons.
Icon fonts is not bad, but I think it will be better if you change to SVG icons.

This also sounds very interesting to me and seems to be more versatile than icon fonts. It could be nice to load custom icons in a plugin and use them with the same helper method as the core icons. Or just to install a custom icon pack as a plugin. Just a few thoughts. I'm not so well informed about this topic right now. So are there some other opinions about preferring SVG icons over icon fonts?

Fontawesome 5 recommends JS with SVG.
Sorry for not checking well.

Yey! This asap pls!
+1

Max Johansson wrote:

Yey! This asap pls!
+1

Max, I'll be very happy to update my patch if Jean-Philippe agrees to replace the current icons with FA icons.

Marius,
Jean-Philippe, could you please let us know your opinion about this?

Marius, maybe it will be easier to update the patch and sneak-commit it with help of Go? Then we could cross fingers and hope that Jean-Philippe might not notice it :D

Max Johansson wrote:

Marius, maybe it will be easier to update the patch and sneak-commit it with help of Go?

I will not commit such a big change without Jean-Philippe's consent. I never forget that he is the owner of this software and we can use Redmine thanks to him and his many years of efforts.

Go MAEDA wrote:

I will not commit such a big change without Jean-Philippe's consent. I never forget that he is the owner of this software and we can use Redmine thanks to him and his many years of efforts.

Absolutely agree!

Basically I agree with Go and Jan. It's not an option to make decisions behind JP's back. As much as I share this opinion I can understand Max's intention. This issue is nearly three years old and no decisions are made. So has anybody a better idea on how to get at least a yes, no, maybe from Redmine's kahuna?

So has anybody a better idea on how to get at least a yes, no, maybe from Redmine's kahuna?

I guess the only way I could come up with is to bump this ticket with a message mentioning JPL and urgent to be visible in the activity log of Redmine.org next time a commit streak from JPL will occur. And it can be detected with help of #redmine-commits channel on our Discord, but if RSS tracker bot will not logout again (Discord been having problems with bots logging out lately, but they are working on fixing it afaik) and there will be anyone available or online to bump this message in that perfect moment :)

Bump! Jean-Philippe, this ticket is ultra-urgent to many, please share your consent.

Max Johansson wrote:

Bump! Jean-Philippe, this ticket is ultra-urgent to many, please share your consent.

Max, let be honest, it is not so ultra-urgent, it is just a nice UI improvement for the core and for the theme developers. I'll update my patch to Font Awesome 5 and then I'll share my thoughts regarding this feature.

But I partially agree, a feedback from Jean-Philippe could be useful to not work in the wrong direction.

Marius BALTEANU wrote:

Here is an updated version of my patch.

Since the page requires authentication, I could not get the patch.

Go MAEDA wrote:

Marius BALTEANU wrote:

Here is an updated version of my patch.

Since the page requires authentication, I could not get the patch.

Sorry, I didn't know that the project is private. I made it public now, you should have access.

+1

I hope this feature will be released as soon as possible.
The current icon is hard to see due to its small size and is not kind to the user.

I've started to look again on this and I think it's better to move from icon fonts to svgs if we really do this step. Most of the major apps that I use did this and Github wrote a very nice article about this (https://github.blog/2016-02-22-delivering-octicons-with-svg/).

I will post in a few days a PoC for this change which allows easy customisation by plugin developers or to keep the existing functionality.

Marius BALTEANU wrote:

I made a demo patch that adds SVGs instead of icon fonts for issue page: ​

Marius I've tested your patch. IMHO it looks really nice. I would love to see this landing in v5.0.0.

Marius BALTEANU wrote:

I made a demo patch that adds SVGs instead of icon fonts for issue page

That looks very good.

I know of a few themes that replace icon images with icon fonts.
For those themes, you can continue to use your own icons without making any major changes by applying the following CSS.

.icon-svg svg {display: none;}

Marius BĂLTEANU Go MAEDA
I think that modernizing the graphic aspect of redmine is a way to increase its diffusion. This ticket has been stalled since version 3.4. The default theme icons are really outdated. Is it possible in your opinion to foresee a release in version 6.0?

I've uploaded inline-svg-demo-from-sprite.patch which demonstrate how the approach using inline SVG from a sprite will look like. There are still some minor improvements to do and to extend to all the icons, but I think it should be enough for a first version.

I will add the code that generates the sprite later on.

I deployed a branch with "mask-image" to render.com.
The advantage of this aproach is that there is no need to modify erb or helpers.

https://redmine-zp9p.onrender.com/projects/sample-project/issues

The difference is here.

https://github.com/redmine/redmine/compare/master...tohosaku:redmine:render

I think application.css needs a little more organization

I've committed the first patch that replaces a part of the icons with SVG icons from a sprite file. I will continue with the rest of the work in the following days, but if you have any feedback, please let me know.

I've replaced most of the icons with SVG icons based on the mapping made by Takashi Kato.

• Replace the icons in Administration menu
• Replace the icons in Gantt tab
• Replace the icons in JS Toolbar
• Double check if I miss any icon to replace
• Allow plugins to easily render icons from their own sprite file
• Review / improve the icons

Any feedback / help on this is welcome!

Marius BĂLTEANU wrote in #note-64:

I've replaced most of the icons with SVG icons based on the mapping made by Takashi Kato.

I still have to:

• Replace the icons in Administration menu
• Replace the icons in Gantt tab
• Replace the icons in JS Toolbar

Done. Regarding JS Toolbar icons, I've preferred to use the icons provided by Material Design v3 except for inline code and pre code for which I didn't find any similar icon with what we had and I chose text.

Marius BĂLTEANU wrote in #note-65:

Done. Regarding JS Toolbar icons, I've preferred to use the icons provided by Material Design v3 except for inline code and pre code for which I didn't find any similar icon with what we had and I chose text.

Also, I preferred to set them from CSS as background image for now and for wiki link I made a custom icon by combining two icons.

• gantt subject expand / collapse
• toggle plus / minus
• select

Beside these icons, there is still some work to do: CSS fixes and optimisations, support for plugins developers.

Also, I would like to propose to move completely to Material Design Icons v3 which offers more options and all of them are open source / free (for ex: bookmark-add, bookmark-remove). Font Awesome in Free version has certain limitations. Another icon set option could be https://heroicons.com/.

Mizuki ISHIKAWA wrote in #note-69:

I have written a patch to replace the icon for toggle_checkboxes_link into an SVG.

Thanks, committed, nice refactor!

Minoru Maeda wrote in #note-71:

I wrote a patch to fix the issue where the progress line on the Gantt chart and the revision graph in the repository were hidden.

I have committed the fix in r23063. Thank you.

I've switched the icons from Font Awesome to Material Symbols, please let me know what do you think.

Also, I've included multiple fixes.

Mizuki ISHIKAWA wrote in #note-74:

Thank you all for your efforts on this issue.

I attached is a fix-some-icons-color.patch to fix the icon-issue-edit not changing color.
This is due to fill="none" and fill="#1C1B1F" being set in icons.svg, so remove those settings.

Thanks for catching this, I've committed the fix. In the following days, I will commit also these 2 icons that are custom created (based on the Material Symbols icons) together with the script to download the Material Symbols icons (inspired from Takashi Kato work).

Marius BĂLTEANU

The Material Symbols license is the Apache License v2, which seems to be incompatible with GPLv2. I'm not very familiar with licensing, so is it okay to use Material Symbols in Redmine? Alternatively, would adding a license notice make it possible to use them?

• https://developers.google.com/fonts/docs/material_symbols?hl=en#licensing
• https://github.com/redmine/redmine/blob/master/LICENSE.txt#L5
• https://en.wikipedia.org/wiki/Apache_License#Compatibility

Mizuki ISHIKAWA wrote in #note-76:

Marius BĂLTEANU

The Material Symbols license is the Apache License v2, which seems to be incompatible with GPLv2. I'm not very familiar with licensing, so is it okay to use Material Symbols in Redmine? Alternatively, would adding a license notice make it possible to use them?

reference:

• https://developers.google.com/fonts/docs/material_symbols?hl=en#licensing
• https://github.com/redmine/redmine/blob/master/LICENSE.txt#L5
• https://en.wikipedia.org/wiki/Apache_License#Compatibility

The LICENSE.txt file in the repository states following:

Redmine - project management software
Copyright (C) Jean-Philippe Lang

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
...

The any later version part, so my understanding, makes it possible to relicense the code under the GPLv3 which seems to be compatible with the Apache Licene v2.
I'm not sure if it's necessary to consequently change the license of Redmine to GPLv3 in this case.
https://joinup.ec.europa.eu/licence/gnu-general-public-license-v20-or-later

Bernhard Rohloff wrote in #note-77:

The any later version part, so my understanding, makes it possible to relicense the code under the GPLv3 which seems to be compatible with the Apache Licene v2.
I'm not sure if it's necessary to consequently change the license of Redmine to GPLv3 in this case.
https://joinup.ec.europa.eu/licence/gnu-general-public-license-v20-or-later

Forcing GPLv3 "just for some icons" would be an incredible overkill which will result in a lot of pain. Many organisations actively reject GPLv3 due to its stricter rules (which may or may not actually hold any merit, but that's the wrong place to discuss this).

In any case: if we ship any Apache2 licensed code or data with Redmine, we have to ship the entirety of Redmine under a compatible license (which would be GPLv3 in that case). I'm not 100% sure about other direct dependencies which are not directly shipped with Redmine itself. As such, we should refrain from using Apache-2-licensed icons (or other code/data) to still retain the choice of using GPLv2.

When in-lining external assets (such as icons) into Redmine, we should also make sure to follow the attribution rules of their respective source licenses.

Thanks everyone for the discussions related to licenses compatibility. It was my mistake as well that I didn't check this before migrating the icons from Font Awesome to Material Symbols.

I agree with Holger, is not worth it to change the license just for some icons so this icon set is not longer an option.

1. Revert to Font Awesome which I don't really like it because of the mix between solid and regular icons, but this is just more a personal taste. I can revert to this icon set based on your feedback.
2. Find another icon set released on an compatible license (ex: GPUv2, MIT). Tabler Icons is an option, Heroicons another option.

Marius BĂLTEANU wrote in #note-80:

[CUT]

1. Find another icon set released on an compatible license (ex: GPUv2, MIT). Tabler Icons is an option, Heroicons another option.

+1 for me.

"Tabler Icons" screenshot in #note-78 looks good

Tabler Icons looks very nice as well, I think it is the best option for us because of the wide range of icons, which will cover all our needs. I'm going to commit the new set of icons these days.

Does anyone have any objections?

Marius BĂLTEANU wrote in #note-83:

Does anyone have any objections?

I completely agree!

The Tabler icons look gorgeous!
+1 from my side and a huge thanks for pushing this topic for so long.

Yeah, they look great. Thanks for taking care, Marius!

I've migrated the icons in r23084 to Tabler Icons and in r23085 I've referenced the source and the MIT license in doc/README_FOR_APP. Is this enough in terms of license?

There are still some fixes to do.

Marius BĂLTEANU wrote in #note-83:

Tabler Icons looks very nice as well, I think it is the best option for us because of the wide range of icons, which will cover all our needs. I'm going to commit the new set of icons these days.

Does anyone have any objections?

They look very nice!