On Sun, Jul 8, 2018 at 4:51 PM, Greg Sheremeta <gshereme(a)redhat.com&gt; wrote: Right, whenever you need to add new UI bits (i.e. as part of implementing some feature) into WebAdmin - please do so via the ​ ovirt-engine-ui-extensions <https://gerrit.ovirt.org/gitweb?p=ovirt-engine-ui-extensions.git;a=tree> project if possible. It's an oVirt UI plugin <https://ovirt.org/develop/release-management/features/ux/uiplugins/> meant to contain various types of UI extensions, including the Dashboard (and effectively replacing the ovirt-engine-dashboard <https://gerrit.ovirt.org/gitweb?p=ovirt-engine-dashboard.git;a=tree> dependency in 4.3/master Engine). ​If you need to modify some existing WebAdmin dialog and the change is not trivial, please consider the possibility to re-implement bits of (or even the entire) dialog in React. We have already implemented a new version of "Migrate VM(s)" dialog within the ui-extensions project [1] - it will soon replace the corresponding GWT dialog code. What seems too complex in GWT/Java doesn't have to be that complex in React/JavaScript! [1] https://github.com/oVirt/ovirt-engine-ui-extensions/tree/master/src/compo... And if the given UI component is important/useful enough, we can ​contribute it to patternfly-react <https://github.com/patternfly/patternfly-react/> and use it in other projects as necessary. (For example, sharing common UI components with VM Portal <https://github.com/oVirt/ovirt-web-ui/>.) ​Currently, most WebAdmin CSS is baked into the GWT application - using ​<ui:style> scopes it to the given widget. As Greg wrote above, moving forward, we'd like to share the common styling between core UI and other projects - and we can do it via Engine branding infra. For example: http://localhost:8080/ovirt-engine/webadmin/theme/00-ovirt.brand/common.css contains all styles as declared in: ​/path/to/ovirt-engine/frontend/brands/ovirt-brand/src/main/sass/common.scss ​Note: ​"ovirt-brand" is the name of the default branding package. This is generally how we can facilitate CSS sharing, produced by core UI and consumed by others. As for the opposite direction (common CSS produced by others and consumed by core UI and/or others), we could add new branding package to contain the extra CSS.