----- Original Message -----
> From: "Greg Sheremeta" <gshereme@redhat.com>
> To: "Vojtech Szocs" <vszocs@redhat.com>
> Cc: "Martin Sivak" <msivak@redhat.com>, "Alexander Wels" <awels@redhat.com>, "engine-devel@ovirt.org"
> <devel@ovirt.org>
That's correct.> Sent: Wednesday, April 20, 2016 7:06:13 PM
> Subject: Re: [ovirt-devel] UI plugins - access to engine styles and libraries
>
> On Wed, Apr 20, 2016 at 12:51 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
>
> >
> >
> > ----- Original Message -----
> > > From: "Martin Sivak" <msivak@redhat.com>
> > > To: "Vojtech Szocs" <vszocs@redhat.com>
> > > Cc: "Greg Sheremeta" <gshereme@redhat.com>, "Alexander Wels" <
> > awels@redhat.com>, "engine-devel@ovirt.org"
> > > <devel@ovirt.org>
> > > Sent: Tuesday, April 19, 2016 5:07:52 PM
> > > Subject: Re: [ovirt-devel] UI plugins - access to engine styles and
> > libraries
> > >
> > > > With this (static linking) approach, you don't need those CSS
> > > > or JS resources at runtime; your webapp is self-contained and
> > > > optimized (containing only stuff it really uses).
> > >
> > > Right, but I won't get the same look and feel as the styles might be
> > > different.
> >
> > If `ovirt.brand` is RPM-packaged, you could depend on it
> > when building your webapp (UI plugin), but I don't think
> > we have such RPM.
> >
> > > I was looking for a way to use the same colors and styles
> > > to make the UI plugin look right in both RHEV and oVirt.
> >
> > Understood, just use the URL that exposes branding files,
> > it's perfectly fine to load CSS and other stuff at runtime.
> >
>
> But much of the CSS is obfuscated by GWT. There's no way to hook into it.
All I wanted to say is that we have some base CSS files
(see "webadmin_css" in ovirt.brand/branding.properties)
and some of them could be of use to Martin. For example,
vanilla PatternFly CSS:
- patternfly/css/styles.min.css
- patternfly-ovirt.css
>
> My idea is completely different. I wanted to stop using GWT for all CSS,
> and instead use LESS or SASS. Then any plugins could simply use the
> LESS/SASS files as needed.
I like that idea.
In general, we should extract *all* styling (including
<ui:style> in ui.xml templates) into separate CSS files
and access that through appropriate Java interfaces in
our GWT applications.
There should be no CSS styling outside of 'css' files.
The GWT build would involve an extra step, if needed:
take Less/Sass files and compile them into CSS files.
GWT Java interfaces would link to these CSS files and
GWT compiler could still do its obfuscate/minification
thing. We *could* disable CSS selector obfuscation if
we wanted to, using "@external" as we do for branding.
However, the main point is because we'd already have
CSS styling isolated into dedicated files, we could
simply expose those CSS files via HTTP/servlet.
So assuming we have everything in CSS files:
interface MyCss extends CssResource {
String className();
}
interface MyResources extends ClientBundle {
@Source("my.css")
MyCss css();
}
// inside ui.xml template
<ui:style type="org.ovirt.engine.ui.example.MyCss">
</style>
(Note that <ui:style> above is empty on purpose.)
>
> There's no way that could make 4.0 now, though.
>
>
> >
> > >
> > > Martin
> > >
> > > On Fri, Apr 15, 2016 at 5:37 PM, Vojtech Szocs <vszocs@redhat.com>
> > wrote:
> > > >
> > > >
> > > > ----- Original Message -----
> > > >> From: "Vojtech Szocs" <vszocs@redhat.com>
> > > >> To: "Martin Sivak" <msivak@redhat.com>, "Greg Sheremeta"
> > > >> <gshereme@redhat.com>, "Alexander Wels" <awels@redhat.com>
> > > >> Cc: "engine-devel@ovirt.org" <devel@ovirt.org>
> > > >> Sent: Friday, April 15, 2016 5:23:08 PM
> > > >> Subject: Re: [ovirt-devel] UI plugins - access to engine styles and
> > > >> libraries
> > > >>
> > > >> Hi Martin,
> > > >>
> > > >> (adding Greg and Alex in case they have any thoughts)
> > > >>
> > > >> if you build your UI plugin in a way that requires CSS styles,
> > > >> JS libraries etc. at runtime (dynamic linking), you can utilize
> > > >> oVirt branding servlet [a] to serve branding-related resources.
> > > >
> > > > Just a note - another way of building your UI plugin is to use
> > > > tools that take your CSS styles and JS sources (including 3rd
> > > > party ones) and produce a self-contained bundle for deployment.
> > > >
> > > > oVirt Dashboard, for example, follows this approach:
> > > >
> > > > https://github.com/vojtechszocs/ovirt-dashboard-ui-plugin
> > > >
> > > > (soon, we'll sync it with ovirt-engine-dashboard on our gerrit
> > > > and continue developing the project there)
> > > >
> > > > With this (static linking) approach, you don't need those CSS
> > > > or JS resources at runtime; your webapp is self-contained and
> > > > optimized (containing only stuff it really uses).
> > > >
> > > > We also have two RPM packages (initiated by Juan) for building
> > > > (oVirt) webapps that require a JS build step, utilizing tools
> > > > around the Node.js platform:
> > > >
> > > > ovirt-engine-nodejs [Node.js runtime]
> > > > ovirt-engine-nodejs-modules [all frontend dependencies]
> > > >
> > > > Regards,
> > > > Vojtech
> > > >
> > > >>
> > > >> [a] org.ovirt.engine.core.branding.BrandingServlet
> > > >>
> > > >> By default, oVirt Engine ships with single branding package:
> > > >>
> > > >> $ ls /etc/ovirt-engine/branding/
> > > >> 00-ovirt.brand
> > > >>
> > > >> That `00-ovirt.brand` directory symlinks to:
> > > >>
> > > >> /usr/share/ovirt-engine/branding/ovirt.brand
> > > >>
> > > >> containing all branding-related resources.
> > > >>
> > > >> To fetch them, use the following URL:
> > > >>
> > > >> http://example.com/ovirt-engine/webadmin/theme/<path_to_file>
> > > >>
> > > >> where <path_to_file> is relative to `ovirt.brand` directory.
> > > >>
> > > >> In your UI plugin, you can use the newly introduced API to
> > > >> construct this URL more easily [b]:
> > > >>
> > > >> var url = api.engineBaseUrl() + 'webadmin/theme/' + pathToFile
> > > >>
> > > >> [b] https://gerrit.ovirt.org/#/c/55694/
> > > >>
> > > >> WebAdmin UI itself loads following CSS styles (in this order):
> > > >>
> > > >> - web_admin.css
> > > >> - common.css
> > > >> - gwt_common.css
> > > >> - patternfly/css/styles.min.css
> > > >> - patternfly-ovirt.css
> > > >> - ovirt-patternfly-compat.css
> > > >> - ovirt.css
> > > >>
> > > >> For starters, you can load PatternFly-specific CSS only.
> > > >>
> > > >> As for JS libraries, these are typically provided through
> > > >> PatternFly RPM, to which `patternfly` directory symlinks.
> > > >>
> > > >> For starters, you can use stuff under `patternfly/js` and
> > > >> `patternfly/components` (these are PF's own dependencies).
> > > >>
> > > >> oVirt ships its own version of jQuery (v1.11) + Bootstrap
> > > >> (v3.3.6) -- please don't use them!! If you're wondering
> > > >> why we use custom jQuery and Bootstrap, see here:
> > > >>
> > > >> https://gerrit.ovirt.org/#/c/41228/
> > > >> https://gerrit.ovirt.org/#/c/55546/
> > > >>
> > > >> (@Greg, any plans for upgrading to PF-provided jQuery?)
> > > >>
> > > >> Regards,
> > > >> Vojtech
> > > >>
> > > >>
> > > >> ----- Original Message -----
> > > >> > From: "Martin Sivak" <msivak@redhat.com>
> > > >> > To: "engine-devel@ovirt.org" <devel@ovirt.org>
> > > >> > Cc: "Moran Goldboim" <mgoldboi@redhat.com>, "Vojtech Szocs"
> > > >> > <vszocs@redhat.com>, "Oved Ourfali" <oourfali@redhat.com>
> > > >> > Sent: Wednesday, April 13, 2016 5:30:49 PM
> > > >> > Subject: UI plugins - access to engine styles and libraries
> > > >> >
> > > >> > Hi everybody,
> > > >> >
> > > >> > there is one piece I always missed when developing my optimizer
> > plugin
> > > >> > and that is the access to the engine css styles.
> > > >> >
> > > >> > I feel it might be pretty easy and good for both bandwidth and
> > > >> > branding to expose them using some "well known" url from the engine.
> > > >> > All plugins would be then able to (re-)use the same styling
> > > >> > information and basic javascript libraries (jQuery, angular,
> > whatever
> > > >> > you decide the core engine will use).
> > > >> >
> > > >> > So far, each UI plugin has to link to its own version of libraries
> > and
> > > >> > define (and maintain) custom color theme.
> > > >> >
> > > >> > Do you think this would be doable for 4.0?
> > > >> >
> > > >> > Best regards
> > > >> >
> > > >> > --
> > > >> > Martin Sivak
> > > >> > SLA / oVirt
> > > >> >
> > > >> _______________________________________________
> > > >> Devel mailing list
> > > >> Devel@ovirt.org
> > > >> http://lists.ovirt.org/mailman/listinfo/devel
> > > >>
> > >
> >
>
>
>
> --
> Greg Sheremeta, MBA
> Red Hat, Inc.
> Sr. Software Engineer
> gshereme@redhat.com
> 919-741-4016
>