Improve ThemeList and Portal styles make more visual for users

[FerranMart]

Pull Request Description

This pull request includes significant visual improvements to the portal, as well as the creation of additional CSS files for greater customization.

Changes Made

1. General Visual Improvements:

   • Adjustments have been made to the styles of ThemeList and Portal to enhance the user visual experience.
   • The size of the cards and elements has been increased for better readability and appearance.

2. Additional CSS Files:

   • Two new CSS files have been created: ThemeListPortal.css and ThemeListSidebar.css.
   • These files allow for greater customization of the portal and sidebar styles, separating specific style rules and facilitating future modifications.

Files Modified

• ThemeList.jsx: Updated to include new CSS classes and improve the structure of elements.
• Portal.jsx: Adjusted to integrate visual improvements and new CSS files.
• ThemeSwitcher.jsx: Adapted to work with the new styles.
• ThemeListPortal.css: New file for portal styles.
• ThemeListSidebar.css: New file for sidebar styles.
• Portal.css: Updated to reflect visual changes.

Purpose of the Changes

• Improve the user experience through a clearer and more attractive interface.
• Facilitate CSS customization and maintenance by separating specific styles into dedicated files.

Result Images

To illustrate the changes made, here are before and after screenshots:
Before:

After:

Additional Comments

Any feedback is welcome. I am willing to make additional adjustments if necessary to ensure these changes meet the project's expectations and standards.

[manisandro]

I'm afraid this is probably a no-go, since styles are subjective and we cannot impose a style change on all users just like that. In particular this PR also breaks color schemes as it replaces color variables with hardcoded values. What is acceptable is introducing additional CSS classes if required to enable further customization in the user specific stylesheet. But not significant style changes itself.

[FerranMart]

Could it be accepted if I leave the style the same but create two CSS files for future divided customizations?

[tpo]

@manisandro - I think it'd be interesting to have one or more "example" or "demo" styles to chose from. Would it be possible to place them somewhere in the repo and to be able to easily switch them by changing one line somewhere (use style=foo). This is just a wild idea. I have not looked at the technical ways to achieve this or how it is done now at all. So if my idea is nonsense then please excuse and ignore me :-)

[manisandro]

@tpo So far the official theming support is limited to configurable color schemes, the rest is left to the user in the form of specific CSS overrides. One could extend this to include more variables (say certain border radius etc), but generally I'd expect it to be difficult to cover all customization needs through say CSS variables. We can however certainly provide some examples of customization via overrides in qwc2.css.

@FerranMart What advantage do you get in spitting up the CSS in two files? As far as the final application bundle is concerned, it does not really make a difference. Or am I missing something?

[Guts]

Hey @FerranMart ,

I'm just popping in here by chance to find out how to make QWC more modern by default in terms of ergonomics and interface, and I come across your PR.

Great work, I really hope it can give the project a new lease of life in terms of look & feel, although as @manisandro says it's obviously a matter of customization. But if we're going to be subjective, we might as well go for a more contemporary style?

[softark]

I'm a bit skeptical to the built-in Portal itself, mainly because it doesn't provide significant functionalities:

• You can use the ThemeSwitcher in Portal, but it's also accessible in Viewer.
• External links might be the main usage of Portal, but you can't place them in the main canvas - you have to place them in the menu.
• It does't have good functionalities to fill up the large blank space in the main canvas except for ThemeSwitcher.

Although many GIS sites would want to have their own portals with varieties of styles and use cases, it's very difficult for a package to satisfy their needs. It's a reasonable solution to leave Portal outside the package, not only for package developers but also for users. Constructing a portal outside QWC2 or qwc-services is not so difficult a task, provided that you can use the authentication and authorization mechanism.

As a matter of fact, qwc-docker doesn't use Portal by default, and I believe it's the right decision.