Missing the point guys. Any theme set has to have standard classes common to the theme set. Therefore, any custom classes that are common among the theme set then becomes standard and if bootstrap theme is going to be the base theme, it follows that the bootstrap classes are base standard to the theme set. Does that define standard in our case?
I believe it is safe to say that we are trying to use the standard bootstrap classes and approaches first and foremost because then a theme can be applied seamlessly.
Hi @Anthony_Porter , @sjpadgett , @MatthewVita and everybody else,
Just brought in some bootstrap/responsive work by @zbig01 into the codebase. Mostly used bootstrap classes. The buttons deserve some mention/documentation though since there were several preferences that were designer dependent, so moved these decisions to styling sheets:
position-override gives a hook for style to change placement of buttons. In light/manila style this is ignored and buttons go to left positioned under data entry field. Whereas in @zbig01 's styles this is used to center the buttons.
oe-opt-btn-group-pinch gives a hook for style to pinch the buttons (i think make them more rounded). Not used in light/manila, but used in @zbig01 ’ styles.
oe-opt-btn-separate-left gives a hook to place a space between the buttons. Not used in light/manila, but used in @zbig01 ’ styles.
(note there is also flexibility in how the Cancel links are shown. For example, in light, it’s simple a link (not a button). And in Manila and @zbig01 , some neat work is done to make it a button, but less accented than the Save buttons.)
So, when adding buttons to the bottom of forms, will be important to incorporate these classes.
-brady
1 Like
Perfect and I know this is ongoing process but once done and documented what a boon for consistency in look and feel in future development. @brady.miller Could I go ahead and add your post details to readme we spoke of or is another route being taken for ongoing documentation?
hi @sjpadgett , Go ahead and add this to the readme(I can also do this if you’re short on time). And I’ll put a link to it from the wiki.
thanks,
-brady
If you would, that would be great. I have about four things going on with the LBF bug foremost.
1 Like
Sure thing. Now go and crush that LBF bug 
1 Like
Here’s the link to the doc (just a starting point):
I’ve been going through some of the restyled themes and can’t help but notice how some are disjointed due to bootstrap overrides of theme styles. We really should rethink the load order of bootstrap and theme. It’s just intuitive that bootstrap should be loaded first then theme style sheet, otherwise the theme creator can’t be sure whether their style will have precedence or not. If changing load order upsets look and feel of existing, then we should go ahead and bite the bullet and fix now.
Btw: Light and radiant are my favorites so far (radiant has a problem with the encounter pull down style tho)
Radiant and Lightbwere built specifically for bootstrap. I’m hoping we retire the old themes.
Themes should really be developed using SCSS instead of overriding bootstrap using our current implementation.
It’s on my list of todo’s: convert Light to a fully SCSS based them as an example for other themes to use
To expand on my previous post a bit.
Bootstrap has a variables.scss file where everything gets defined. Those variables are referenced throughout their CSS.
In order to create a solid theme solution, we should create our own variables.scss where we only define the variables wanted for that theme. So if a theme wants a different background color for alternating table rows but leave everything else vanilla bootstrap, that file would only define 1 variable.
Then the developer would run a Gulp task which compiles the SCSS down to CSS (could also minify here as well). Then, the final CSS for the theme would have all the bootstrap stuff, with the theme changes baked right in.
This would allow us to only include the theme CSS and never import the vanilla bootstrap file (it’s already inside the theme CSS).
I use this workflow all the time. I’ll be spending some time on theming MedEx soon and can easily add this into my stuff, it’s just a matter of getting to it.
The biggest takeaway is to not add non-bootstrap classes unless absolutely required. And when doing so, defer to bootstrap to figure out how to best integrate any custom classes.
I’ll write up some documentation
Robert, I hope nobody thinks I’m being critical because far from it. Thanks to you and some others our U.I now is starting to reflect, to the user, the very good underlying architecture that is OpenEMR. I’m also confident you have the engineering well in hand and understand you can only do so much time wise. However, in the interim, I have one major concern, which is, the current order the theme is loaded. Eventually, those themes (all twenty or so) will be used to help create the variables and currently the theme is loaded, then bootstrap css. This causes the theme to not appear as intended. All i’m saying is that until you get the theme structure in final order, we should allow zigbe and others the benefit of knowing that the themes will have the correct precedence i.e change header to load bootstrap then style. I’ve tested this on a couple themes and the difference is fairly noticeable and more consistent thus, while folks are adjusting these themes for next release, now is the time to make the loading order change.
Again, thanks for tackling this tedious process that needed to get done. You can know, I appreciate it.
btw- would you not want to have the one variable which then is changed to reflect a new value for say a color change of a given class? Also, i’ll go back through and change the stuff I’ve restyled recently and also fix any I find while i’m going through code now for the new bootstrap based modal dialog. Any documentation of normal styles is greatly appreciated.
Agree that @robert.down 's plans will not impact the next OpenEMR 5.0.1 release(we can shoot for this in 5.0.2), which should be going out in 6-10 weeks.
For fixing the ordering of themes, lets get a PR out there so we can assess the damage
(And if possible, I would not couple this with your modal work, or then one may drag down the other)
-brady
I’d like to echo @sjpadgett’s point… I am also confident in @robert.down’s abilities here as well. It’s a massive project and it has been fun to watch! The system is very nice looking now.
Will hopefully get a PR out either tonight or tomorrow with the theme ordering switch.
Great thanks. I’ve switch them and have been watching as I work on other stuff. Maybe I should open another thread for anyone to report issues after switch.
I’ll prioritize this along with getting a better solution in place.
Robert, I’d be more than happy to help if you task me with something.