Don’t call it NewUI, as ist is not a complete UI but a collection if widgets (and pages?)
2 Likes
Cool! We welcome every help!
Thank you!
I am free about the name - just give me a tip how to call the thing and then I will create the GitHub Repo and open the new topic
@ all:
Next Proposal:
MFC-Design (Mobile First Collection)
1 Like
@Nic0205 I’m with @hmerk . This Project is actually an OH Page under current OH’s UI.
I’ll liked the “OpenPage” but they have used a lot out there…
Other possible names: HabWindow, OpenPlug, OpenPage or just Nic’s OpenHab Page.
Example:
Pal. Just pick the name you like and motivates you!
Let me know if you like to have a temp logo with the chosen name.
Cheers!
Warm Welcome!
… and it goes on…
One challenge managed - the next occurs.
@JustinG Do you have a hint for me how I could achieve the navbar “shrinking” like this?
… I think simplest way would be to use https://v5.framework7.io/docs/toolbar-tabbar#hide-on-scroll but it seems not to render the tabbar… Is there a clue?
It really depends on what method you wind up using for the “navbar”. For instance, if you’re using the segmental buttons approach or even just an array of buttons without the segmental structure, I could see a couple of likely options. The first would be to just use a widget variable to determine what the starting button button to display is and a repeater to show only that and the next two buttons. The major advantage to this approach would be that the < and > buttons would be easy because they would simply adjust the starting button variable.
Alternatively, a much more advanced method might be, to put the navbar in it’s own block, set that block overflow to hidden and then use the < and > to set some scrolling of the block. This would be significantly more complicated (including working some javascript into the widget) but likely much prettier and actually allow the buttons to scroll instead of just being rendered in place with each change.
@JustinG @hmerk @rubenfuser @Nic0205
Hey friends.
Again, I’m not a developer, so excuse any possible wrong thinking.
I want to restore one more time the idea to create a new type of page, based on OH tabbed page, but with more options. Why? Because OH have it all in that page: Navbar - Widgets area - tab bar, scrolling animations etc.
That we have is to -hardly- modify is the existing Nav bar: I mean the mechanism is there, it works perfectly and the end user will be modify the page following OH’s well-structured way.
Can you please find some time to review attached draft?
My question is why this approach is wrong -or why the approach we are following now is better? In my perspective, we have choose a way that consumes time, resources and new knowledge while it’s hard configured both for developer and end users.
I’m remaining extremely open to any feedback!
Thanks.
PS. JustinG informed that there is a process i think called “pull request” in order to create a new page like the above mentioned. Does any one know how this process works?
Create tabbed page with menuv1.pdf (658.2 KB)
- Create a GitHub account
- File an issue on the openhab-webuis repo explaining what you are doing (see How to file an Issue)
- After some discussion, hopefully with the maintainer(s) and concurrence with your approach fork the repo.
- In your fork of the repo, create a branch for your change, implement the changes to the code necessary and commit the changes.
- Submit a PR containing the changes.
- Wait for a review from the maintainer(s) and address any concerns they have with the code.
- Once the maintainer(s) are satisfied they will merge the change into baseline.
That’s a high level description of the process. If you are not a developer, you can take this to step 2 and parts of step 3. But you then will have to wait and see when/if someone volunteers to do steps 3-7. That’s often where things fall down. Good ideas are not worth much without someone volunteering to do the work to implement them.
I would say it’s not wrong or better but the approach being followed now is possible using the skills and interests of the people on this thread. I don’t know that many, if any, have the skills and interest in volunteering to pursue implementing this as part of the UI itself. It’s a somewhat different skill set to implement code that creates the code necessary to create a new type of page compared to what is being done here which is using the framework that already exists which is more configuration than coding new (that is not to diminish the work that is being done here which is impressive).
4 Likes
Just to add a little to what Rich said: ‘better’ can mean lots of things.
In this case, I would agree, that contributing code to the UI to create a new page type would be “better” for the end user. However, that is a much more coding intensive process. To do it this way you would have to know Vue (the language that builds the pages) and Javascript (the language that gives the pages much of their specific functonality), plus you would have to fully understand the OH restAPI (the link between OH core and MainUI), the current structure of the MainUI, and a smattering of other things besides (git, oh contribution guidelines, f7 framework, css, your IDE of choice, etc.). I’m sure you’re capable of this, but it would be a much longer road and doesn’t really fit with your initial requirement of being as low-coding as possible.
The process you are currently looking at it a “better” fit for those of you working on the project. You need to only really understand the widget/yaml system and some css.
Note that when I outlined some options for you, I did not suggest creating the entire thing in one widget. This is a good exercise for learning the pieces that you need, but not, I suspect, the best final form for your project. In the end, my guess (and it is only a guess) is that you will want separate widgets for many of the pieces: a top-bar widget, a bottom-bar widget, and a few different page widgets or some breakdown like that. Then you will want to provide some template(s) for how users should combine those on an oh-layout page to create the overall effect of the UI.
2 Likes
How to change CSS class st0 fill property to change colored icon so that this icon shows different colors for different color themes? I’ve added f7 vars to icon’s css, but that didn’t the trick:
style type="text/css">
.st0{fill=(--var-f7-text-color);stroke=(--var-f7-bars-bg-color);stroke-width:4;stroke-miterlimit:10;}
.st1{fill:#D42416;}
.st2{fill:#23C703;}
.st3{fill:#039BE5;}
.st4{fill=(--var-f7-bars-bg-color);}
</style>
<g>
<path class="st0" d="M115.6,230.9c-62.9,0-114-51.2-114-114.1s51.2-114,114-114s114,51.2,114,114S178.5,230.9,115.6,230.9z
M115.6,24.7c-50.8,0-92.1,41.3-92.1,92.1s41.3,92.1,92.1,92.1s92.1-41.3,92.1-92.1S166.4,24.7,115.6,24.7z"/>
</g>
Variables in css need to be called with the var() function.
1 Like
Still that doesn’t work. Element inspection shows correct classes, but they aren’t receiving values (variables greyed out).
Sorry, I just quickly cut and paste your original code into my reply. If you just put var(...) around your original variables, they are still not correct. The f7 variables to not start with the additional var so the properly formed value would be:
fill=(--f7-text-color)
Yes, i did exactly that, and icons seem to not to receive --f7-text-color value.
D’oh! How about fill: var(... instead of fill=var(.... Not sure how I missed that the first time (or first 3 times…).
fill:var(--f7-text-color)
Seems to be correct syntax, but the icon is not receiving values.
The var function can also take a second value which acts as a fallback value in case the variable cannot be found. Try adding some very distinct fallback color, something like:
fill:var(--f7-text-color, #00FFFF);
That will at least tell you if the fill property is being overridden by a different value (which is unlikely) or if the svg just isn’t is the right scope for the f7 variable.
This way icon becomes #00FFFF, not black or white.