Last modified by Ecaterina Moraru (Valica) on 2018/04/26 17:46

Show last authors
1 == Related Proposals ==
2
3 * [[Panels Improvements for Flamingo Skin>>Proposal.PanelsImprovements]]
4 * [[Application Presentation>>Proposal.ApplicationPresentation]]
5
6 == Color Themes ==
7
8 Currently, we have the ability to create different color themes for Colibri.
9
10 [[image:Capture du 2014-04-15 10:47:05.png||width="60%"]]
11
12 But the pre-visualisation of the theme is clearly based on Colibri and it does not reflect the results on Flamingo.
13
14 == Ideas ==
15
16 1. We can modify the existing Color Theme Application to display an other previsualisation if Flamingo is used.
17 1. We can create a new Color Theme Application dedicated to Flamingo, as the current one is dedicated to Colibri.
18
19 == Scope ==
20
21 Flamingo is based on Bootstrap, which defines a lot of [[customizable variables>>url:https://github.com/twbs/bootstrap/blob/master/less/variables.less]], more than we have for colibri (such as font size, font family, etc...). A lot of applications already exists
22 on the web to help users to fill these variables to create their own themes:
23
24 * http://bootswatchr.com/create#!/edit/3217e159
25 * http://stylebootstrap.info/
26 * http://www.bootstrapthemeroller.com/
27 * http://pikock.github.io/bootstrap-magic/
28 * and a lot of more...
29
30 Maybe we could integrate one of them in XWiki, or taking inspiration from them.
31
32 Question: should we propose to set all these variables in our Color Theme Application or only some of them?
33
34 == Previsualisation ==
35
36 === Idea ===
37
38 Since we are using LESS to build Flamingo, and since there is an [[Client-Side LESS compiler>>url:http://lesscss.org/#client-side-usage]], we can use it to refresh all the XWiki UI instead of the previsualisaton area. In any way, we need to propose a kind a previsuliasation because refreshing the current UI will not show all the use-cases.
39
40
41 == Skin Implementation ==
42
43 Currently, we use LESS to generate the CSS file during the build via a maven plugin, not during the runtime.
44
45 === Implementation using velocity variables (LESS compiler called BEFORE velocity engine) ===
46
47 It is possible to use Velocity variables in the LESS files:
48
49 {{code language="shell"}}
50 @body-bg: $theme.pageBackgroundColor;
51 // when @body-bg is used in a CSS class, LESS will just replace it by the string "$theme.pageBackgroundColor"
52 {{/code}}
53
54 Then, the velocity variables will be interpreted at the runtime, as usual.
55
56 But this approach is limited, it makes impossible to use some bootstrap mixins like {{code}}darken(){{/code}} (used to generate a darken color from a parameter) because LESS cannot compute a value from the string "$theme.pageBackgroundColor". It means that we have to change such calls in the **bootstrap sources**.
57
58 ==== Pros : ====
59
60 * quite easy to implement
61
62 ==== Cons : ====
63
64 * needs to modify the bootstrap sources (not good for upgrades)
65
66 === Implementation using LESS at the runtime (LESS compiler called AFTER velocity engine) ===
67
68 The idea is to call the velocity engine BEFORE the LESS compiler, so any reference to a velocity variables is replaced by the proper value and the bootstrap mixins work without any problem.
69
70 ==== Pros : ====
71
72 * more powerful, we can use the bootstrap mixins
73 * we do not modify the bootstrap sources, we just provide our variables.less file
74 * a good step into the direction of proposing LESS features to our users
75
76 ==== Cons : ====
77
78 * need to use LESS at the runtime
79 ** what about performances? we should probably cache the result
80 ** how to implement the @import feature?
81 ** we need to add both flamingo & bootstrap sources in our instances
82 * much harder to implement. Overkill?
83
84 {{info}}
85 I have started to work on a prototype and I have good results.
86 {{/info}}
87
88 === Alternative: rewrite some bootstrap mixins with velocity macros ===
89
90 We can, for example, write our own version of darken(), executed by velocity at the runtime.
91
92 === Pros : ===
93
94 * no need to have the LESS compiler at the runtime
95
96 === Cons : ===
97
98 * we still have to modify the bootstrap sources to use our velocity macros instead of their mixins, but it could probably be done automatically
99 * we have to maintain our own version of the bootstrap mixins as velocity macros
100
101 = UI =
102
103 The UI to create/edit a Color Theme should be split in two sections:
104
105 1. a WYSIWYG section, with some bootstrap variables and a color picker, that refreshes in real-time the CSS of the page
106 1. a textarea where users can directly write some LESS code
107
108 1) is for the regular users.
109 2) is for people who wants to integrate a bootstrap kit found on the web
110
111 == Implementation ==
112
113 === UI ===
114
115 The "WYSIWIG" editor could be something like this [[Bootstrap fancyboot>>http://fancyboot.designspebam.com/]] or a modified version of the current one.
116 {{image reference="fancyboot.png" width="60%"/}}
117
118 === Storage ===
119
120 2 options
121
122 1. we do not offer more variables that the current editor does, we just change the way it is displayed in the editor (for the rest, there is the textarea field). Then we could use the existing [[ColorThemes.ColorThemeClass>>ColorThemes.ColorThemeClass]].
123 1. we offer a completely different set of variables and we need an other, incompatible with colibri, ColorTheme class.
124
125 == Problems ==
126
127 === A lot of customs CSS uses the color theme variables ===
128
129 These variables (such as $theme.textSecondaryColor) does not always have an equivalent in Bootstrap. However, it is easy to add some code in ##colorThemeInit.vm## to do a mapping between the variables of the new color theme and the variables of the old one. But if some variables have been set in the text-area, we need to parse the LESS code to know what is the final value of a bootstrap variable.
130
131 Idea: Parse the generated CSS to get the computed variables, with some CSS classes specific to that purpose.
132
133 === Should a color theme be specific to a skin? ===
134
135 In this case, we need a mechanism to express if a color theme is compatible with a skin.

Get Connected