Willow Theme - New responsive variant of Wilma theme

[milospp]

GitHub issue 3910

What does this pull request do?

Created new thene based on Wilma. CSS is modified to leverage its responsive design feature and enhance the overall layout.

What's new?

Mobile optimized design
Avoided horizontal scroll

How should this be tested?

Change theme in site information and config theme to Willow
Open every page and test by resizing up to around 400px in width (Mobile device toolbar can be used in google chrome to simulate phone display)

Additional Notes:

Here is the video example

• The Left window is VIVO with an old Wilma theme
• The middle window is a new, Willow theme
• The right window is Tenderfoot theme (just for comparison)

https://youtu.be/9B0_cevrEeE

[litvinovg]

@milospp It is hardly possible to distinguish what parts of this PR were copied from wilma theme and what are the improvements as the first commit Created the willow as copy of the wilma obviously doesn't only contain copy of wilma files, but also contain modifications related to boostrap5.
It would be much easier if the code was split into commits where it is obvious what was simply copied and what was modified and has higher chances to contain errors than copied parts.
@chenejac if it is expected to review all the styles, freemarker templates and js including the code that is part of wilma theme it could take much more time than just reviewing responsiveness modifications. I think we need clear steps of what should be reviewed and tested in this PR.
I added some comments about parts that should still be renamed from wilma to willow and a question about modifications for capability map, which created small rendering issue on other themes.
Also some menu buttons in willow theme don't work for some reason.

[litvinovg]

What is the purpose of changing capability map styles and javascript?
It created some artifacts on other themes.
Also I suggest to remove disabled styles and code (not disable it), it could be taken later from git history if needed.

[milospp]

In graph.css is a lot of already commented CSS, so I lost track if that was mine or somebody else old code. I removed this one.

[milospp]

These components are utilized in every theme, so the simplest way to adapt the Willow theme responsively is to modify the root capability map CSS.

[litvinovg]

I suppose it should be Willow, not wilma (names and text in all txt files)

[milospp]

Renamed, and searched for more, and i think there are no more Wilma words inside the Willow theme

[litvinovg]

willow?

[milospp]

Fixed, I updated the personPublicationCountDynamicActivator like this, hope this will be good solution

VIVO/webapp/src/main/webapp/templates/freemarker/visualization/publication/personPublicationCountDynamicActivator.ftl

Line 14 in 0bc8f43

<#if requestingTemplate == "foaf-person-wilma" || requestingTemplate == "foaf-person-willow">

---

also, the Nemo theme has the same issue

VIVO/webapp/src/main/webapp/themes/nemo/templates/individual--foaf-person.ftl

Line 17 in dc5b706

<#assign visRequestingTemplate = "foaf-person-wilma">

[litvinovg]

willow?

[milospp]

Resolved

[milospp]

@milospp It is hardly possible to distinguish what parts of this PR were copied from wilma theme and what are the improvements as the first commit Created the willow as copy of the wilma obviously doesn't only contain copy of wilma files, but also contain modifications related to boostrap5. It would be much easier if the code was split into commits where it is obvious what was simply copied and what was modified and has higher chances to contain errors than copied parts. @chenejac if it is expected to review all the styles, freemarker templates and js including the code that is part of wilma theme it could take much more time than just reviewing responsiveness modifications. I think we need clear steps of what should be reviewed and tested in this PR. I added some comments about parts that should still be renamed from wilma to willow and a question about modifications for capability map, which created small rendering issue on other themes. Also some menu buttons in willow theme don't work for some reason.

I will check what happened to first commit and I will rebase so that it will be easier to compare.

If you would like I can make two pull requests like this
Main branch -> Branch A -> Branch B

Branch A - will have only copied the Wilma theme and nothing else.
Branch B - will have all other changes

I will create PR branch A <- B so that the file changed section for review contains only the changed part. after this is resolved we can create PR Main <- B

If you think this approach would be easier please confirm

[litvinovg]

@milospp It is hardly possible to distinguish what parts of this PR were copied from wilma theme and what are the improvements as the first commit Created the willow as copy of the wilma obviously doesn't only contain copy of wilma files, but also contain modifications related to boostrap5. It would be much easier if the code was split into commits where it is obvious what was simply copied and what was modified and has higher chances to contain errors than copied parts. @chenejac if it is expected to review all the styles, freemarker templates and js including the code that is part of wilma theme it could take much more time than just reviewing responsiveness modifications. I think we need clear steps of what should be reviewed and tested in this PR. I added some comments about parts that should still be renamed from wilma to willow and a question about modifications for capability map, which created small rendering issue on other themes. Also some menu buttons in willow theme don't work for some reason.

I will check what happened to first commit and I will rebase so that it will be easier to compare.

If you would like I can make two pull requests like this Main branch -> Branch A -> Branch B

Branch A - will have only copied the Wilma theme and nothing else. Branch B - will have all other changes

I will create PR branch A <- B so that the file changed section for review contains only the changed part. after this is resolved we can create PR Main <- B

If you think this approach would be easier please confirm

To review splitting code into commits seems enough. Splitting into multiple PRs looks like an overkill. But I think it is up to @chenejac .