guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Jumper <mike.jum...@guac-dev.org>
Subject Re: Scripted Branding
Date Fri, 21 Oct 2016 19:01:50 GMT
On Mon, Oct 17, 2016 at 6:23 PM, Chris Cook <cookcj@jlsautomation.com>
wrote:

> Sorry about the brevity of my earlier response; my better-half and I were
> entertaining a new client - one who is very keen on implementing and
> experimenting with a Guac based tablet/mobile HMI infrastructure within his
> factory...
>
> The logos and the favicons, should both be fixed assets somewhere and
> should be fairly easy to copy over via script within a BASH environment,
> following the platform installation/build-out; something like the following
> should do the trick:
>
> Logo Copyover:
>  cp /media/installationID/logo.png /guacamole_fixed-asset_
> directory/logo_whatever.png
>
> Favicon Copyover:
>  cp /media/installationID/favicon.png /guacamole_fixed-asset_
> directory/favicon_whatever.png
>
> The issue with this scripting methodology is knowing where the fixed
> assets are located within the default file structure...  If you could
> provide some illumination as to the path of these static assets, that would
> be awesome.
>
>
The icons are overridden by branding extensions, with the paths being
specified within the extension manifest JSON. The properties for those seem
to be missing from the manual, but they are "smallIcon" and "largeIcon",
both pointing to an arbitrary PNG file within the extension.

Beware that testing changes to favicons can be tricky if you've already
visited the site in question. Chrome maintains a separate cache for
favicons which is not cleared even when you explicitly clear browser cache.
Other browsers may have similar issues.

Changing the webapp display name and the browser tab display names will be
> a little more complicated as they are both supposedly generated by a .css
> file somewhere.
>

Neither of these are specified via CSS.

The webapp name is defined within the translation strings, which are JSON.
Those can be overridden on a per-language basis via extensions, as well.
See the "translations" property of the extension manifest:

http://guacamole.incubator.apache.org/doc/gug/guacamole-ext.html#extension-format

The browser tab names are either the application name (defined via the
translations) or the name of the Guacamole connection (defined when the
connection was created).

If this .css file is a static asset, where is it located?  If this .css
> file is dynamically generated, what generates it and how can I edit it to
> accept a one-time user entry to establish an application name?
>
>
The CSS file is both static and dynamic. While you could technically modify
the static file, the best place to do that would be within the source of
the web application itself (such that your changes are included in the
build), and we would recommend against that. Doing so would require
re-patching the Guacamole source with each release.

The CSS can be augmented via extensions in the same way as translations.
CSS files which are to be appended to the existing styles are specified via
the "css" property of the extension manifest (see link above).

To be clear, the project I am working on is based upon a fixed/static and
> non-updating, configuration-fixed, and revision-controlled appliance build
> model - i.e. my company builds and installs the appliance within a system
> which will then be revision-fixed.  If requested/required, I or another
> engineer would update the core platform, fault test the new core platform,
> press a new distribution image, and then update/upgrade the production
> system as specifically requested/contracted.
>
> As such, I am not concerned about an end-client initiated update/upgrade
> event as my end-client user will not have the ability to independently
> perform such an operation without the involvement of either myself or one
> the engineers that works with/for me.
>

Even if the customers themselves will not be the ones performing the
upgrade, it will be beneficial to you to keep your changes as separate and
independent as possible, for the sake of maintainability. Having to rebase
patches and address conflicts each release will be a pain, and the branding
portion of the extension subsystem is designed with exactly this in mind.

My recommendation would be to have your script generate the extension JSON
and contents based on a few pre-defined configurables, the final output of
the script being a .jar containing the generated JSON and the provided
files.

- Mike

Mime
View raw message