Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

One theme(ing logic) to rule them all 🎨 #9939

Closed
pascalwengerter opened this issue Nov 14, 2023 · 3 comments
Closed

One theme(ing logic) to rule them all 🎨 #9939

pascalwengerter opened this issue Nov 14, 2023 · 3 comments
Assignees
Labels
Priority:p3-medium Normal priority Type:Story User Story

Comments

@pascalwengerter
Copy link
Contributor

Description

User Stories

As an admin, I want to have a consistent theming journey for my oCIS instance so that I can provide all my clients with custom themes.

What's currently available on https://github.com/owncloud/web/blob/master/packages/web-runtime/themes/owncloud/theme.json has historically grown, and with dropped support for oC10 and a breaking change incoming, we have a chance to streamline the structure and logic behind themes.

My currently favored suggestion has a shared common section, providing general info for the oCIS instance which can (and should) be used by all clients, thereby also limiting redundancy of e.g. name/slogan. It then accepts any number of themes for each client (android|ios|desktop|web) as array items, where the structure and then validating/typing/loading becomes responsibility of the respective client, since their needs vary. I've left an example web theme in there, for reference.

Here is an example:

{
  "common": {
    "name": "ownCloud",
    "slogan": "ownCloud – A safe home for all your data",
    "logo": "themes/owncloud/assets/logo.svg",
    "urls": {
      "accessDeniedHelp": "",
      "imprint": "",
      "privacy": ""
    }
  },
  "android": [],
  "ios": [],
  "desktop": [],
  "web": [
    {
      "isDark": false,
      "title": "Light Theme",
      "name": "ownCloud Light Theme",
      "appBanner": {
        "title": "ownCloud",
        "publisher": "ownCloud GmbH",
        "additionalInformation": "",
        "ctaText": "OPEN",
        "icon": "themes/owncloud/assets/owncloud-app-icon.png",
        "appScheme": "owncloud"
      },
      "logo": {
        "topbar": "themes/owncloud/assets/logo.svg",
        "favicon": "themes/owncloud/assets/favicon.jpg",
        "login": "themes/owncloud/assets/logo.svg"
      },
      "loginPage": {
        "autoRedirect": true,
        "backgroundImg": "themes/owncloud/assets/loginBackground.jpg"
      },
      "designTokens": {
        "colorPalette": {
          "background-accentuate": "rgba(255, 255, 5, 0.1)",
          "background-default": "#ffffff",
          ...
        }
      }
    },
    { ... }
  ]
}
@pascalwengerter pascalwengerter added the Type:Story User Story label Nov 14, 2023
@pascalwengerter pascalwengerter self-assigned this Nov 14, 2023
@michaelstingl
Copy link
Contributor

michaelstingl commented Nov 14, 2023

Previous discussion, when we had bigger plans:

Currently, I have no client requirement to request visual stuff (logo, color etc) from the ownCloud instance.

The only thing I currently need, is the privacy policy per-instance:

Where is it currently exposed?

@tbsbdr tbsbdr added the Priority:p3-medium Normal priority label Nov 27, 2023
@kulmann
Copy link
Member

kulmann commented Nov 27, 2023

@pascalwengerter what do you think about a common-section per client? E.g. loginPage or appBanner is always the same for all themes, so it would be nice to deduplicate those into web.common. Another approach could be to have web.defaults as object and web.themes as array, both with the same data structure, but the active theme would overwrite anything in web.defaults. In other words: define as much as possible in web.defaults and then overwrite only what's necessary in the respective theme. If 3 out of 4 themes use the same logo file, it could be defined in web.defaults.logo and then only the 1 theme that needs a different one defines it as well... requires some object merging at runtime, but that should be a no brainer if the interface is the same.

@kulmann
Copy link
Member

kulmann commented Dec 12, 2023

done via #9698

@kulmann kulmann closed this as completed Dec 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority:p3-medium Normal priority Type:Story User Story
Projects
None yet
Development

No branches or pull requests

4 participants