[BUG] Thematize match events

[akasolace]

Describe the bug Icons in match reports are not adapted to dark themes ...

Roadmap

• [ ] Support loading of SVG for match events (including fallback to png when files are not found)
• [ ] Thematize svg file with linear gradiant addition
• [ ] Compose SVG (manually ? using tool like svg_utils (example
• [ ] build a standalone tool facilitating thematization of icons. For example simple panel loading the different background of themes and one icon. The load would parse the variable and offer user the possibility to change them (manually, color picker) before exporting the value. Such tool could hel getting participation from HO users

[akasolace]

https://gigabaseorgigabyte.wordpress.com/2017/11/15/resizing-and-combining-multiple-svg-images/ https://github.com/btel/svg_utils

[akasolace]

@weisJ this might be a very stupid question but is darklaf compatible with JavaFX. I would like to know if creating a JavaFX panel within HO would be a possibility.

[weisJ]

Darklaf is not compatible. JavaFx is a completely different UI framework and not based on Swing. I might port darklaf to JavaFX in the future but this will be a big undertaking. However mixing Swing and JavaFX is generally a bad idea and needs to done very carefully (see this blog post).

[akasolace]

@weisJ I would like a tool to test icons versus the different install themes. The idea is to have a dedicated popup window, where one could choose an icon name using let say a combobox and the selected icon will be displayed against all backgroud colors. Something like:

for themeName in ["Darcula", "Solarized", ....]: label.setBackground(XXX(themeName).getColor(HOColorName.TABLEENTRY_BG));

I could not find the XXX function that does it. Is it even possible ?

The final aim is to let the user select variable color and see how the icon render on the fly. Once it looks ok, he should be able to push back that information to us (not sure yet how this will be done for easy integration in our codebase) but I imagine eventually I want a text file where we map icons, themes and gradiant color that will be loaded when HO starts.

The idea is to facilitate contribution from some of our user for thematizing our icons (there are far too many for us to customize them all)

Have you ever had to do something similar for your project ?

[weisJ]

I'm not quite sure I understand what this XXX function should return? What I understand is that (correct me here if I am wrong):

• You want to access the background colour of all themes, without changing the LaF,
• to display icons on top of the different backgrounds (side by side).

Should the icon also adapt to the colour of the respective theme?

Sidenote: There are predefined colours which can be used for icons (all internal icons of darklaf use those) to ensure consitency (where appropriate). A list with all colour names can be found here for example.

[akasolace]

Yes what you describe is correct. The idea is to include in HO! a tool allowing user to help customize our icons (we have ~100).

I imagine the tool something like a window, where user can select an icon using a dropbox which will list all our icons. Let say user select Icon1.

In the window there would be on panel per available theme, and each panel would:

• have a label e.g. "Darkula", "Solarized", ....
• have the associated default background (function XXX)
• display the selected icon
• display the variables of the icon (I imagine I will have to parse the SVG to get available gradiantColor variable)
• have one color picker per variable variables

Hence, the user, will be able to test and adjust the icon against all available themes and export the results when satisfied. I did not think about it yet but I imagine something like a json file that would be send to our server:

{
  "icon1": [
    {
      "theme": "Darcula",
      "color1": "#FF0000",
      "color2": "#125653"
    },
    {
      "theme": "Solarized",
      "color1": "#FF2230",
      "color2": "#FF1228"
    }
  ]
}

Then I will need to aggregate the json files and parse them at theme initialization.

@weisJ do you see what I am trying to achieve? Does it make sense or maybe I am missing something as I am really not familiar with this kind of topic.

[weisJ]

have the associated default background (function XXX)

The easiest (and most memory efficient) approach would be the following:

Theme theme = ...
Properties props = new Properties();
theme.loadDefaults(props, new UIDefaults());
Color bg = props.get("background");

The "background" property is guaranteed to be present in each theme. However this approach assumes that "background" doesn't change at a later stage of theme loading (e.g. when applying accent colours etc.). However this is very unlikely.

---

I'll have to see what the best strategy would be for something like this. The probably are some parts that need a dedicated on the darklaf side e.g.

• display the variables of the icon (I imagine I will have to parse the SVG to get available gradiantColor variable)

How icons are loaded through the IconLoader is an implementation detail and I wouldn't want users to cast the returned icon for introspection (This is specifically relevant for the caching mechanism).

One way to solve this would be to introduce methods the likes of IconLoader#isThemed and IconLoader#getThemedColorNames. I'm not 100% satisfied with this approach though. Maybe I'll add an own component for icon editing.

I'll get back to you after I have investigated this a bit more.

[akasolace]

thank you @weisJ, I will use the approach you suggested to get the background color.

If I understand correctly, getting the available variable for a given svg and changing them on the fly might not be as easy as I thought and you will come back to me with a viable approach (with maybe new method in Darklaf), is that correct?

[weisJ]

If I understand correctly, getting the available variable for a given svg and changing them on the fly might not be as easy as I thought and you will come back to me with a viable approach (with maybe new method in Darklaf), is that correct?

Yes.

[weisJ]

Ok as promised I am back with a solution. After some evaluation I decided that creating an api which allows creating an icon editor would be very complex and would still need some information about implementation details. Instead I'm offering an own implementation of such an editor which handles all the pitfalls one would encounter while doing so themselves. Notably I still had to add some extensive amount of api to do so.

There are two components provided (available using the snapshot version):

• IconEditorPanel: The basic editor. It extracts all properties from the icon and displays editors for them. It also offers default values from themes to choose from. Note that the editor doesn't work in place and won't change the passed icon. The changed properties can be exported using IconEditorPanel#exportProperties .
• IconEditor: This builds on top of IconEditorPanel and offers to choose an icon from a list of icons displaying multiple editors side by side. The user can manually add/remove editors (this can be disabled in favour of specific editors). Here again the properties can be exported by theme using IconEditor#exportProperties.

General note: The exported properties can be of type Color, Integer and String (will never be a valid hex string). Which should be considered when serializing/deserializing them.

Lastly I should say that those components can't be used outside darklaf as they won't work correctly.

[akasolace]

Hi @weisJ, I am working on another issue at the moment but next week I will give this is a try ! Thank you !

[weisJ]

Update: The editor can now be used with other lafs than darklaf. However the experience won't be as good as with darklaf itself.