summaryrefslogtreecommitdiff
path: root/addons/web_editor/static/src/scss/secondary_variables.scss
AgeCommit message (Collapse)Author
2020-09-28[IMP] web_editor, *: automatically increase default link color contrastqsm-odoo
*: website Inside a color combination (or outside, as considered the same as inside color combination number 1), the link color can be configured. It is set by themes to one of the 5 theme colors. Sometimes, no color of those 5 colors contrast enough with the color combination's background and we accepted that before, relying on the fact the user can change the link color if he wants too. Now we automatically increase the contrast of those link colors, except if the user overrides it. This system might be extended to all foreground colors in the future but the system has to be improved for that. closes odoo/odoo#58538 Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
2020-07-09[REF] website, *: review how available fonts are defined in scssqsm-odoo
*: web, web_editor Instead of three lists + one map to define font information and user choices saved as the index of the related fonts in those lists, the fonts are now stored in an unique map <font-name> -> <data> and the user choices are saved as the font name. This allow to have a visually better definition of the fonts and allows to reorder fonts in the UI without losing user customization (and actually simplify some code). Unfortunately any user font customization < 14.0 will be lost, but this is a small price to pay (users can still rechoose the same font in the editor UI where they will go anyway to discover all the new shiny features we are introducing there). Part of https://github.com/odoo/odoo/pull/54065 task-2291398 closes odoo/odoo#54065 Related: odoo/design-themes#269 Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
2020-06-02[IMP] website, *: define 17 generic color palettesstefanorigano (SRI)
*: web_editor Those will be shared by all themes. Part of https://github.com/odoo/odoo/pull/52224 task-2197038 closes odoo/odoo#52224 Related: odoo/design-themes#290 Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
2020-06-02[IMP] web_editor, website, *: use new color namesqsm-odoo
*: mass_mailing, website_blog, website_forum, website_hr_recruitment Deprecate alpha, beta, gamma, delta and espilon color names and now use a new color system: o-color-x, with x from 1 to 5. This will allow to review the colors of all themes to have nice visuals for the new color combinations classes, without breaking the current uses of bg-alpha, alert-delta, etc in current websites of customers (by keeping the old color and classes for compatibility). This will also allow to uniformize all themes under the same conventions to enforce BS color override: - o-color-1 used as primary (as before, for alpha) - o-color-2 used as secondary (as before, for beta) Before, some themes were not following the 2 guidelines. The users using those themes will simply have the possibility to choose o-color-1 and o-color-2 colors accordingly to restore their website without breaking the new system features. Another change is that those colors are defined through color palettes and not theme color palettes. This will avoid them to generate automatic bootstrap classes which we don't want (alert, btn) and generate the one we want by ourself. Note: for mass mailing, the colors and classes also have been renamed but the system stays unchanged. Part of https://github.com/odoo/odoo/pull/45856 task-2197038
2020-06-02[IMP] web_editor: allow color combinations specific override and accessqsm-odoo
Now, the colors used in a color combination are accessible and possible to override through the BS $colors map, with a specific prefix (o-cc for "color combination"). So, to access the 'headings' color of the color combination 3, use: color('o-cc3-headings'); If you don't need to completely override a color combinations preset, you can override what you want through a color palette: $o-color-palettes: ( ( 'text': red, 'o-cc4-btn-primary': 'alpha', // ... ) ); As our current system allows the user to customize colors of the color palette (like for menu, default text, etc), this will allow to easily give them the possibility to override combinations colors in a future update. Part of https://github.com/odoo/odoo/pull/45856 task-2197038
2020-06-02[IMP] website, *: introduce new classes to color snippetsqsm-odoo
*: web, web_editor, website_blog, website_event New o_cc${xxx} classes where ${xxx} is a number [1-5] to style snippets: they come with a background color, a text color, headings colors, a link color, primary button colors and secondary button colors which will later be possible to customize by the user. The classes are made so that they are working on two levels. So if a column receives a color class and the snippet too, everything will work fine. More than 2 levels are not supported and the editor is made so those cases should not appear. See o_colored_level class. Part of https://github.com/odoo/odoo/pull/45856 task-2197038
2020-03-07[FIX] web_editor, website: review default palette systemqsm-odoo
Before this commit, this was done: 1) Primary variables (app order): (a) web_editor: define palettes (color + theme + gray), only 1 empty one. Mark the first ones as the selected ones. (b) website: fill all defined palettes with the website-related color key and values (body, menu, logo-height, etc). + define "website values" palette. 2) Secondary variables (reverse app order): (c) website: merge the user palettes on top of the selected palettes (so user values overriding values added in (a) and (b)), the resulting palettes are added in palettes lists and the selected palette numbers are set to select those ones. + final selection of "website values" palette. (d) web_editor: final selection of the selected color palette amongst the color palettes. -- The problem with all of this is that the definition of palettes in themes (occuring between step (b) and (c)) never received the website-related color key and values of step (b) and were thus forced to redefine all of those by themself even if they wanted to use the default website one. This commit changes the system so that step (a) and (b) now define "base" palettes (color, theme, gray, website values) and step (c) and (d) now merge the final selected palettes with those "base" palettes. This is in fact theoratically more efficient and allows to not force themes to define every possible palette value we might introduce. closes odoo/odoo#47097 Related: odoo/design-themes#216 Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
2019-01-04[FIX] web_editor: restore backend colorsqsm-odoo
Commit https://github.com/odoo/odoo/commit/52ec536cef2ec84af0b36746f19a8cdf9f23fe2a made a mistake which made the backend use the website colors. This is because the web_editor app adds its bootstrap_overridden.scss file in both backend and frontend assets as the backend needs the editor colors (alpha, beta, ...). However, the 'primary', 'secondary', etc that the backend customizes should not be overridden by the web_editor. Therefore the file contained a hack to determine if it is the backend or not... hack which did not work anymore with the new system the mentioned commit implements. Also some comments were not adapted correctly by the mentioned commit. closes odoo/odoo#29935
2018-12-26[REF] *: make stronger bootstrap assetsqsm-odoo
* portal, theme_bootswatch, web, web_editor, website With less2sass and bs3tobs4 tasks, the assets structure was reviewed to handle the specificities of both framework and to prepare for our next odoo tasks. In particular, the assets_helpers and bootstrap overrides were basically split into 4 parts: utils, primary variables, secondary variables and bootstrap variables. (see https://github.com/odoo/odoo/commit/6e4db7d13a926845bf82f5b035afede42d6d5a89) Using the !default system for the bootstrap variables parts seems now a good improvement. This is part of what this commit does: adding the default flag for all bootstrap variables overrides and inverting the order of the files in the _assets_backend_helpers and _assets_frontend_helpers templates. This allows to avoid code like this: portal: ``` $body-bg: white; ``` website: ``` @​if $var != null { $body-bg: $var; } ``` This code makes the body white with portal or equal to $var with website if $var has a value. The same behavior in the new file order is achieved with: website: ``` $body-bg: $var !default; ``` portal: ``` $body-bg: white !default; ``` This order is now also followed for the _assets_secondary_variables templates (there are only a few). This commit also make better assets hierarchy by making website inherit from portal assets (instead of web) and portal inherit from web_editor assets (instead of web) (thus relying on strong dependencies instead of installation order which is not always right for migrated databases). closes odoo/odoo#29757