Some screens do not fit well to narrower screens than 1920 pixels about luci-theme-material

[Ranger-Z]

I think the scale makes it great on a cell phone, First GUI I can see on my phone

[LuttyYang]

@hnyman I adjusted the some size. Is it much better now?

[hnyman]

I applied manually your patches and it seems a bit better now. It is still wide, but not quite 1920 px. Maybe 1650 px now. The zone boxes (wan, wan6 ...) look better.

The theme design makes it probably hard to decrease size much more, so I am not sure how much effort you should spend on this.

But one possible idea for you: could the zone boxes (interfaces included in a zone: wan, wan6, sixxs, ...) be arranged vertically inside the box instead of horizontal? I haven't checked the Luci source, if the placement comes from the source, but if that can be arranged in style, that could decrease the horizontal space.

Ps. One additional notion: was it really intentional to hardcode 0.2.9 version to header.htm and footer.htm in commit 74c2313 ?
It still says 0.2.9 there, also in the 0.2.10 release... Earlier there was no version specification.

[LuttyYang]

@hnyman Ohhhh... Is there any other automated way to solve this problem?

[hnyman]

Sorry, I am not sure to which problem you refer. (the firewall screen or the probably accidental 0.2.9 spec in https://github.com/LuttyYang/luci-theme-material/blob/master/files/templates/footer.htm#L45 and header.htm)

[LuttyYang]

@hnyman
How to automatically add the current version number to header.htm and footer.htm files.

Is there any other automated way to solve this problem?
thanks

[hnyman]

Ahh, that question.

On the Openwrt side there is no need to set a version number for the theme, as the luci package version number gets automatically created from the date, time and hash of the last commit in the Luci repo: https://github.com/openwrt/luci/blob/master/luci.mk#L52
e.g. "git-15.278.60928-3289e13"
(logic explained in openwrt/luci@0856030 )

That variable is set during the make process and is then used for all the components. There is usually no separate revision IDs for components like modules, applications or themes.

When the buildbot builds the packages automatically every 1-2 days, the version gets set each time according to that last commit. The same also happens if somebody builds his own firmware including the theme. The version is the date/time/hash based one.

Regarding your own 0.2.9 and 0.2.10 etc. builds published at your own site, I do not know any better way to do it. The PKG_VERSION that you define in the Makefile should get applied, I think. But the end-users will probably still see the main luci version in the footer.

In general, I think that most users will either download the most recent theme from the snapshot repo (e.g. https://downloads.openwrt.org/snapshots/trunk/ar71xx/generic/packages/luci/ ) as firmware's opkg will fetch it from there or alternatively they include the theme in their build (using luci feed from github/luci). I don't believe that many people will directly download the 0.2.9 etc. revisions from your site. I may be wrong, but that is my hunch.

[LuttyYang]

@hnyman I think you misunderstood my point. I just want to prevent caching problems...

[hnyman]

Yeah, I got your purpose wrong.

Would it be possible to include the version variable in a similar fashion as the hard-coded version string? (Not say absolute 0.2.9 there, but instead reference to the variable's value, which would be something like the ver.luciversion is used on line #31:
https://github.com/LuttyYang/luci-theme-material/blob/master/files/templates/footer.htm#L31

<a href="https://github.com/openwrt/luci">Powered by <%= ver.luciname %> (<%= ver.luciversion %>)</a> /

If similar things works, that would force the cache to refresh at least when a new Luci version gets installed.

(But your original idea of changing it manually when you change the footer file, may be enough, too.)

[LuttyYang]

@hnyman OK, thank you very much.

[hnyman]

I compiled the material theme after your PR openwrt/luci#513 with 0.2.11 and noticed something negative:

I think that the idea of forcing the browser to update style.css and script.js after the theme is updated, is ok on principle, but the effect of the changes in openwrt/luci#513 make style.css and scripts.js to never cache (at least in Firefox). They are always reloaded from the server, for each Luci page refresh (as the link contains the query element "?git...").

That was probably not quite the intention. It overshoots the purpose of forcing an update for the theme.

From performance perspective, loading these style files again and again for each page is unnecessary. I am not sure if forcing the cache-refresh is really needed. It might be better to revert to the original situation, where it is up to the user to force a cache cleanup / style reload, if he notices something rendering wrongly.

[LuttyYang]

I fix it in version 0.2.13

[hnyman]

I return to the screen width / text size issue:

After the most recent fixes (menu system etc.), I see much too small text for the detail items on two pages:
network / firewall
network / switch

Below are two images from Firefox and one from IE11, where the text is even smaller...

Everything fits now to the screen, but is rather unusable on those two screens :-(

[LuttyYang]

Okey...

[LuttyYang]

@hnyman I fix it in version 0.2.15

[hnyman]

Thanks, looks better now.