There is some basic documentation covering the layout of extensions with respect to theming here, though please beware this should be considered a draft until the IPMC vote regarding 0.9.10-incubating (hopefully) passes:
http://guacamole.incubator.apache.org/doc/0.9.10-incubating/gug/guacamole-ext.html#ext-file-format A Guacamole extension is just a .jar file containing a guac-manifest.json along with anything else your extension uses (see above). In the case of an extension which does nothing more than theming/branding, the only other things within the .jar will be the CSS, HTML, images, etc. you need. - Mike On Thu, Dec 29, 2016 at 7:50 AM, Chris Cook <coo...@jlsautomation.com> wrote: > Is there any guidance anywhere that I can refer to on this? Still looking > for the answer… > > > > From: Chris Cook > Sent: Friday, October 21, 2016 2:14 PM > To: 'user@guacamole.incubator.apache.org'; 'mike.jum...@guac-dev.org' > Subject: RE: Scripted Branding > > > > Anything? > > > > From: Chris Cook [mailto:coo...@jlsautomation.com] > Sent: Monday, October 17, 2016 9:24 PM > To: user@guacamole.incubator.apache.org > Subject: RE: Scripted Branding > > > > 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. > > 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. 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? > > 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. > > ________________________________ > > From: Chris Cook [coo...@jlsautomation.com] > Sent: Monday, October 17, 2016 7:14 PM > To: user@guacamole.incubator.apache.org > Subject: Re: Scripted Branding > > Mike, > > > > Thanks for your response. If I am understanding you correctly, I can use a > BASH script that includes functions like CAT or an ECHO pipe to write out an > installation specific .jar to the guacamole-home folder? > > Sent from my iPhone > > > On Oct 17, 2016, at 18:56, Mike Jumper <mike.jum...@guac-dev.org> wrote: > > On Mon, Oct 10, 2016 at 10:12 AM, Chris Cook <coo...@jlsautomation.com> > wrote: > > Greetings, > > I am currently reviewing Guacamole for inclusion in an IIoT platform for > industrial equipment - to allow for operator interface access via webpage. > > Both I and my team LOVE the default Guac 0.9.9 webapp! > > > > Thanks! > > > > However, we have one hurtle that we need some help overcoming... We are > estimating approx. 100 uniquely branded deployments every year. As such, > generating a deployment specific branding extension for each and every > deployment would become rather cumbersome very quickly. > > > > Branding extensions are the intended way to achieve this. The idea was that > by encapsulating such changes within an extension, branding changes could > remain stable across upgrades, thus making things more convenient and doing > away with the need to patch the webapp itself. > > > > Is there a way to change the application name, the logo, and the favicon of > the default web-client without having to generate and deploy a new .war > archive? > > > > There's no need to deploy a whole new .war each time (though, since you > mentioned branding extensions earlier, perhaps you meant .jar). > > > > It should be possible to script the generation of a branding extension if > the specifics are predictable (logo, icon, changes to the strings). Have you > given writing such a script a shot? > > > > - Mike > > > > THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF THE > INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION > THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE > LAW. If the reader of this message is not the intended recipient or the > employee or agent responsible for delivering the message to the intended > recipient, you are hereby notified any dissemination, distribution or > copying of this communication is strictly prohibited. If you have received > this communication in error, please notify us immediately by replying to > this message or by sending an e-mail to i...@jlsautomation.com and destroy > all copies of this message and any attachments. Thank you. > > THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF THE > INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION > THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE > LAW. If the reader of this message is not the intended recipient or the > employee or agent responsible for delivering the message to the intended > recipient, you are hereby notified any dissemination, distribution or > copying of this communication is strictly prohibited. If you have received > this communication in error, please notify us immediately by replying to > this message or by sending an e-mail to i...@jlsautomation.com and destroy > all copies of this message and any attachments. Thank you. > > THIS E-MAIL MESSAGE AND ANY ATTACHMENTS ARE INTENDED FOR THE USE OF THE > INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION > THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE > LAW. If the reader of this message is not the intended recipient or the > employee or agent responsible for delivering the message to the intended > recipient, you are hereby notified any dissemination, distribution or > copying of this communication is strictly prohibited. If you have received > this communication in error, please notify us immediately by replying to > this message or by sending an e-mail to i...@jlsautomation.com and destroy > all copies of this message and any attachments. Thank you.
