How to customize Classic UI?

[cau...@gmail.com]

Hello,

I'm currently using openHAB 1.5 with classic ui and I need to do some changes to the automatically generated ui from .items files (like changing widgets layout, adding columns, adding titles -h1, h2...-, customizing CSS...). Is this possible in an "easy way", or is it a completely automated process hard to change? I guess that this depends on the "items inflator" that creates the html from the defined items and this isn't a straightforward task...

In case this isn't possible, is there a more customizable webapp that can be used for this? Maybe GreenT? Or should I implement a custom UI from scratch (using Sencha touch could be an option) that would connect directly to the REST API?

Thanks.

[Ervin Sirk]

Hello!

I just wanted to add my (lack-of)experience. I've been playing with OpenHAB over past 7-8 months and I find mostly amazing but sometimes I've been stuck with small details that annoy me (like UI rendering).

For example, the way webview <iframe> is rendered: it has a frameborder and its height is static. I needed to remove the border and the width:height ratio to be 16:9 or 4:3 and change dynamically when device is rotated or window resized. 

I'm inexperienced, but I managed to setup developement environment for openhab and I edited some files like this:

1.WebView.html @ org.openhab.ui.webapp snippets folder:

ORIGINAL:

<p><center><iframe src="%url%" height="%height%" style="padding:10px;width:90%" /></center></p>

EDITED (removed frameborder and increased width, also added script call after frame is loaded):

<p><center><iframe src="%url%" height="%height%" scrolling="no" frameborder="0" onload="%script%" style="padding:0px;width:95%"></iframe></center></p>

2. WebViewRenderer.java @ org.openhab.org.ui.webapp:

ORIGINAL:

int height = webview.getHeight(); if(height==0) { height = 1; }                 snippet = snippet.replaceAll("%url%", webview.getUrl()); snippet = snippet.replaceAll("%height%", Integer.toString(height*36)); EDITED (i used the height=0 option for my automatic height): int height = webview.getHeight(); if(height==0) {       height = 1080; snippet = StringUtils.replace(snippet, "%script%", "javascript:resizeIframe(this);"); } else { height = height*36; snippet = StringUtils.replace(snippet, "%script%", "javascript:void();"); }                 snippet = StringUtils.replace(snippet, "%url%", webview.getUrl()); snippet = StringUtils.replace(snippet, "%height%", Integer.toString(height));

3. main.html  @ org.openhab.ui.webapp snippets folder:

Added function for iframe resize in <script> </script>

function resizeiFrame(obj)

{

}

Then I right-klicked on org.openhab.ui.webapp, chose "export" and Eclipse generated a new openhab.org.ui.webapp_1.5.0.jar file for me.

I copied and replaced the file in openhab server/plugins folder and it worked!

NOTE:

when I upgraded my runtime to openhab 1.5.1, then copying the above file to plugins folder did not work. Classic UI did not get loaded. I think I should rebuild it for 1.5.1. 

But for starters I removed the openhab.org.ui.webapp_1.5.1.jar from plugins folder and copied my _1.5.0 version to /addons folder (where the addon bindings go).

And it worked again. I think aslong as there are no core modifications that affect webapp behaviour, i'm safe.

I know this sort of solution is very non-standard approach and involves risks of malfunction but I just wanted to share it because I have had a lot help reading other peoples peculiar workarounds.

Regards,

Ervin

[Jens Kastensson]

Hello and Thanks for sharing this information!

If you have a one or two screenshots to elaborate the textual description , it'd be equally appreciated!

Jens

--

[Ervin Sirk]

Hi,

I must say that after my previous post I completely changed everything. 

I dont know if this is a good idea, but I'm going to post it here.

If not anything else, then someone more experienced can point out where and what can lead to total collapse..

or maybe some of these thoughts make their way to distribution version.

EDITED VERSION OF Openhab Classic UI:

I customized webview widget (iframe) - the version 1.5.0 jar-package is exported from Eclipse according to bindings tutorial.

1. if height=0 in sitemap, then <iframe> gets additional attributes:

1.1. added class="DynaiFrame" - this allows simpler access to iframe element to resize it in realtime

1.2. added onload="javascript:resizeiFrame(this)" - which resizes iframe when content has loaded.

1.3. used webview "label" attribute to pass additional customization parameters to iframe.

1.4. added few lines of code to UI main.html <SCRIPT> section, which loads custom.js from webapps/custom folder.

1.5. I'm thinking about adding a iframe-to-parent frame message proxy (maybe porthole.js) to pass messages between iframes and UI.. this requires some code in both, parent window and iframe content. custom.js makes this sort of work-arounding faster and simple imo. 

INSTALLING:

1. needs  ./openhab/webapps/custom folder and custom.js scriptfile which is dynamically loaded into page

scriptfile has functions for iframe resize and more functions can be added through that file.

2.1. on openhab runtime version 1.5.0 - org.openhab.ui.webapp_1.5.0.jar in ./openhab/server/plugins folder needs to be replaced with the new version

2.2. on openhab runtime version 1.5.1 (and possibly other versions before and after 1.5.0) - original file needs to be deleted and the new version goes to ./openhab/addons folder

3. remove the text in parenthesis (or the plugin will not load).

EDITED & ORIGINAL source files WebappRenderer.java, main.html & webapp.html are included just for reference to see what has been modified IN new version.

CONFIGURING SITEMAPS:

Webview url="test/hover.html" height=0 label="frameborder=no scrolling=no ratio=1"

Webview url="http://www.google.com/" height=0 label="frameborder=no scrolling=no ratio=16/9"

1. custom widgets can be saved in webapps subfolders or be located in the internet

2. if height=0, then automatic resizing is activated (both onload event of iframe AND window.resize event)

3. iframe can be further more customized in "label" section:

3.1. if "ratio" is defined and parses as number, then resize is done so that (iframe height) = (window width) / (ratio)

3.2. if no ratio is defined, then height is calculated with content.scrollheight

3.3. frameborder & scrolling are normal iframe tags to enable/disable frameborder and scrolling (I think resizing without ratio needs scrolling=yes)

3.4. any other valid iframe tag can be added (but html syntax must be observed)

3.5. I found it best to surround my automatically resized iframe with a frame:

Frame

{

Webview url="test/hover.html" height=3 label="frameborder=no scrolling=no ratio=0.5"

}

I Also made some screenshots of Chrome on PC and my Nexus 5 with different orientations and window sizes. 

Screenshots and everything else is gathered in the attatched zip-container.

Regards,

Ervin

[Steven Lazidis]

This seems good, I'll give it a try. It's one of the things I've been frustrated with as well.

[Jens Kastensson]

Ervin, great work!
​Maybe this article can be added to the openhab wiki page, what does the wiki responsible person think?

Jens

[Ervin Sirk]

I'm planning to consult with Kai. Since the discovery of openhab, I've started thinking about creating a branch of OH, which focuses on accomodation for security systems. This involves exposing some more of the UI aspects for ease of customization, expanding user authentication features (as far as version 1 limitations allow) and also finding other software that in conjuction with OH would add configuring flexibility and increase security. I have many thoughts, but I need to dig through OH 2 general specs first. Maybe I'm mistaken, but I think that it would be too much and confusing information for this topic to be handled on OH main branch.

Regards,
Ervin

--
You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/sUG20rsaXjQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
For more options, visit https://groups.google.com/d/optout.

[Kai Kreuzer]

Hi,

Maybe this article can be added to the openhab wiki page, what does the wiki responsible person think?

I didn’t look into all details, but it appears to me as if (at least most) of the changes make sense in general, so instead of documenting how to tweak the current Classic UI, wouldn’t a pull request with enhancements be a better idea?

I'm planning to consult with Kai. Since the discovery of openhab, I've started thinking about creating a branch of OH, which focuses on accomodation for security systems. 

Branching is in general not a good idea. We should rather see how to design extension mechanisms that your specific requirements can be acomplished by an optional extension.

 I have many thoughts, but I need to dig through OH 2 general specs first.

Please note that I plan to release a first alpha version of openHAB 2 on November 24 - I will try to document some of its main new ideas and btw, it will come with a completely new UI, which will replace the Classic UI on the long run. So my suggestion is to wait for a week and then pick up the discussion again!

Best regards,

Kai

You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.

[Ervin Sirk]

Hello Kai,

Thank you for the information. I hope I have not been rude by altering the Classic UI and making it public this way. It's just that I've read so many discussions about the current UI limitations and they have always ended with the same conclusion: currently UI is not in the main focus, basic features are implemented and if more is needed, then Greent or CometVisu are suggested. But writing a completely new UI is too complicated for me now. The Classic UI is really good actually. And no matter which UI one chooses, there is always something to tweak. That's why I thought it's best not to push any modifications into current work. But making an optional extension seems like a great idea. 

I'm really looking forward to the OH2 updated specs and first release. And after that, I think there is still going to be quite some time before the new version is mature enough to be used for my application.

I don't not want to waste your valuable time on small talks like Classic UI's tweaking. But now that the topic is up, I just wanted to say about this "Extended Classic UI". In my opinion it would be something that is by default exactly like Classic UI, but everything in the web content that does not have to be hardcoded is user accessible. By that I mean exposing the UI header and footer sections for customization and also accessing navigational features (transfer from one submenu to any other). This means in todays context, that the UI scripts that are in main.html would also be moved into custom scripts area. And the more or less static parts of header and footer also. And it would be great to have something like "options" attribute that travels unmodified as-is all the way down from sitemaps-file to UI (as I did now with webview "label" attribute to configure iframes properties). This only asks for minor additives on other core elements. 

Have I got it right? It is okay for me to play around and tweak the webapp experiementally? If so, should I do it privately or is it okay to share it here for comments and consulting? And there is one more question that not many people can answer. What difference does it make if I load openhab.org.ui.webapp.jar from addons folder instead of its original /server/plugins folder. It works for the moment and allows one webapp version to be used with other core versions, but could it lead to any problems that you can see? I'm currently running Eclipse with version 1.5.0 project loaded, but I will upgrade it to 1.5.1 before soon. 

Best Regards,

Ervin

[Kai Kreuzer]

Hi Ervin,

Have I got it right? It is okay for me to play around and tweak the webapp experiementally? If so, should I do it privately or is it okay to share it here for comments and consulting? 

openHAB is open source, so YES, it is very ok if you play around with it and tweak it to your needs. And if there is any chance that you think is valuable to others (and does not break anything for existing users), you are encouraged to create a pull request for it!

Please note that the code is now also available at Eclipse SmartHome: https://github.com/eclipse/smarthome/tree/master/bundles/ui/org.eclipse.smarthome.ui.classic

And this is the version that will go into the openHAB 2 runtime. So when considering a PR, you might directly do it against this repository as per my blogpost earlier this week (http://kaikreuzer.blogspot.de/2014/11/openhab-16-and-20-alpha-release.html), I would hope that we can discontinue the 1.x runtime in a while.

Actually one pull request that I would wish very much from any Javascript/CSS developer is an update of the Classic UI from iOS 6 to iOS 8 look&feel - this would tremendously improve the lifespan of this UI :-) Any volunteers?

What difference does it make if I load openhab.org.ui.webapp.jar from addons folder instead of its original /server/plugins folder. 

Well, the server/plugin folder contains everything that is part of the core runtime - and the Classic UI is part of it. All bundles in the addons folder are dynamically installed. So yes, if you place another Classic UI in the addons folder, this will be started.

Best regards,

Kai