Step 13: Update documentation for skinning

README.md

@@ -264,9 +264,6 @@ top of the underlying `matrix-react-sdk`. `matrix-react-sdk` provides both the
 higher and lower level React components useful for building Matrix communication
 apps using React.
 
-After creating a new component you must run `yarn reskindex` to regenerate
-the `component-index.js` for the app (used in future for skinning).
-
 Please note that Element is intended to run correctly without access to the public
 internet.  So please don't depend on resources (JS libs, CSS, images, fonts)
 hosted by external CDNs or servers but instead please package all dependencies
@@ -313,7 +310,6 @@ cd element-web
 yarn link matrix-js-sdk
 yarn link matrix-react-sdk
 yarn install
-yarn reskindex
 yarn start
 ```
 
@@ -364,9 +360,6 @@ ___
 When you make changes to `matrix-react-sdk` or `matrix-js-sdk` they should be
 automatically picked up by webpack and built.
 
-If you add or remove any components from the Element skin, you will need to rebuild
-the skin's index by running, `yarn reskindex`.
-
 If any of these steps error with, `file table overflow`, you are probably on a mac
 which has a very low limit on max open files. Run `ulimit -Sn 1024` and try again.
 You'll need to do this in each new terminal you open before building Element.

docs/app-load.md

@@ -1,5 +1,8 @@
 # App load order
 
+**Dev note**: As of March 2022, the skin is no longer part of the app load order at all. The document's graphs have
+been kept untouched for posterity.
+
 Old slow flow:
 ![image](https://user-images.githubusercontent.com/2403652/73848963-00a2a080-4821-11ea-97d4-1200fc2638f3.png)
 

docs/customisations.md

@@ -34,9 +34,9 @@ default, Element Web does *not* ship with this file to prevent conflicts.
 
 ### Custom components
 
-Instead of implementing skinning from the react-sdk, maintainers can use the above system to override components
-if they wish. Maintenance and API surface compatibility are left as a responsibility for the project - the layering
-in Element Web (including the react-sdk) do not make guarantees that properties/state machines won't change.
+Maintainers can use the above system to override components if they wish. Maintenance and API surface compatibility are
+left as a responsibility for the project - the layering in Element Web (including the react-sdk) do not make guarantees
+that properties/state machines won't change.
 
 ### Component visibility customisation
 

docs/skinning thoughts.md

@@ -1,68 +0,0 @@
-== Skinning refactor ==
-
-matrix-react-sdk
-  - base images
-  - base CSS
-  - all the components needed to build a workable app (including the top layer)
-
-element-web: the Element skin
-  - Element-specific classes (e.g. login header/footer)
-  - Element-specific themes
-    - light
-    - dark
-
-i.e. the only things which should go into element-web are bits which apply vector-specific skinning
-specifically "Stuff that any other brand would not want to use. (e.g. Element logos, links, T&Cs)"
- - Questions:
-   - Electron app?  (should probably be a separate repo in its own right?  but might as well go here for now)
-   - index.html & index.js?  (should be in matrix-react-sdk, given the SDK is useless without them?)
-
-ideally matrix-react-sdk itself should ship with a default skin which actually works built in.
-
-status skin (can go in the same app for now)
-  - has status theme
-    - which inherits from Element light theme
-    - how do we share graphics between skins?
-      - shove them into react-sdk, or...
-      - guess we do ../../vector/img 
-      - this means keeping the skin name in the images (unless /img is a shortcut to the right skin's images)
-
-out of scope:
-  - making the components more independent, so they can be used in isolation.
-  - that said, the bits which should probably be used by being embeded into a different app:
-    - login/reg
-    - RoomView + RoomSettings
-    - MessageComposer
-    - RoomList
-    - MemberList
-    - MemberInfo
-    - Voip UI
-    - UserSettings
-  - sharing different js-sdks between the different isolated modules
-
-other changes:
-  - how do we handle i18n?
-    - each skin should really be its own i18n project.  As long as all the commonality stuff is in matrix-react-sdk this shouldn't be too bad.
-  - ability to associate components with a given skin
-    - skins/vector/src <-- components
-    - skins/vector/css
-    - skins/vector/img
-    - skins/vector/fonts
-  - gather together themes (per skin) into a single place too
-    - skins/vector/themes/foo/css
-    - skins/vector/themes/foo/img
-    - skins/vector/themes/foo/fonts
-  - ideally element-web would contain almost nothing but skins/vector directory. 
-  - ability to entirely replace CSS rather than override it for a given theme
-    - e.g. if we replace `Login.js` with `StatusLogin.js`, then we should similarly be able to replace `_Login.scss` with `_StatusLogin.scss`.
-
-random thoughts;
-   - should we be able to change the entire skin at runtime (more like wordpress) - to the extent of replacing entire components?
-     - might pose security issues if a theme can be swapped out to replace MatrixChat or other fundamental functionality at runtime
-   - if so, perhaps skins & themes should converge...
-
------------------
-
-Immediate plan for Status:
- * Implement it as a theme for the Element skin
- * Ideally move skins to a sensible level (possibly even including src?)

docs/theming.md

@@ -6,7 +6,7 @@ Element app via CSS & custom imagery.
 
 They are *NOT* co be confused with 'skins', which describe apps which sit on top
 of matrix-react-sdk - e.g. in theory Element itself is a react-sdk skin.
-As of Jan 2017, skins are not fully supported; Element is the only available skin.
+As of March 2022, skins are not fully supported; Element is the only available skin.
 
 To define a theme for Element: