robertdown wrote on Tuesday, August 13, 2013:
Ok - noticed an issue, my work on the facilities page was also included in that commit, here’s the new URL with that code reverted back to regular implementation.
https://bitbucket.org/rdown/openemr/commits/e27aed20fef2017ce7dd9d499cf1e2a45180f981
bradymiller wrote on Tuesday, August 13, 2013:
Hi,
Here’s a tool built by Art to make a bunch of patients:
http://starfrontiers.org/khvcode/openemr/PrintaPatient.zip
See this thread for more details:
http://www.oemr.org/phpBB3/viewtopic.php?f=5&t=20
-brady
OpenEMR
bradymiller wrote on Tuesday, August 13, 2013:
Hi,
Just seeing mostly removal of \t\t\t characters on that commit. Guessing it’s just the wrong commit link.
-brady
OpenEMR
robertdown wrote on Tuesday, August 13, 2013:
https://bitbucket.org/rdown/openemr/commits/bcd6ba299e0ad87fa01a3fe58533803c8d45646f was the original commit, and I forgot to pull the \t’s so I did that and pushed, so https://bitbucket.org/rdown/openemr/commits/f441cad8eae98a6049bdcf08e077b3b2ce32e39a is correct. But Internet Explorer is breaking all the twitter bootstrap stuff (surprise, surprise, right?) I did some research and will be dropping in an html5.js file to support IE. That will be in a commit later today.
Work on the facilities page is probably 50% complete, hoping to get at least another 30% completed today.
robertdown wrote on Tuesday, August 13, 2013:
Here is the commit that fixes the IE issues. I’ve noticed if you’re using IE9 in compatibility mode it still doesn’t work right - solution: don’t use compatibility mode.
https://bitbucket.org/rdown/openemr/commits/bfe04d82a5129375f4c87338727d5b3c5f3f3a82
Commit message:
Merge branch ‘updated-ui-globals’ into updated-ui
robertdown wrote on Wednesday, August 14, 2013:
2 new screenshots representing the New/Edit Facility form.
bradymiller wrote on Wednesday, August 14, 2013:
Hi Robert,
Is IE9 compatibility mode commonly used?
-brady
OpenEMR
bradymiller wrote on Wednesday, August 14, 2013:
Also,
Regarding the submodule thing library/js/select2, how does this work? Would it be better to instead just bring it into the project and update it if needed (and test it) since it will be globally used(ie. if breaks things, will break a lot of things)?
-brady
OpenEMR
bradymiller wrote on Wednesday, August 14, 2013:
To follow up on above select2, wouldn’t it be better to use a production version:
http://ivaynberg.github.io/select2/
-brady
robertdown wrote on Wednesday, August 14, 2013:
I don’t think IE9 compatibility mode is commonly used, however, I avoid IE as much as possible so I’m not a great source to ask.
Regarding the submodule. All this does it add some info to .gitmodules. Then when you clone the repo you run git submodule update --init and it’ll go grab any submodules. A submodule is just a git repo inside of another git repo. We could just place the actual code in it, but using submodules makes updates easier, since you’re dealing with an actual git repo.
By production version do you mean a minified version?
mdsupport wrote on Wednesday, August 14, 2013:
What are server requirements for select2? This fiddle works at the given link but does not work when code runs from our server. The code looks as generic as it can get…
robertdown wrote on Thursday, August 15, 2013:
Hm. There shouldn’t be any server requirements since it’s all javascript.
3 questions:
What browser are you using?
What commit are you testing from?
Did you initialize the submodule by running “git submodule update --init”?
bradymiller wrote on Thursday, August 15, 2013:
Hi,
But the submodule thing is essentially pulling in screen2 development code. Should be using production releases:
Is it really that tough to just bring in a commit with the most current production release and update it with future production releases as necessary. As with jquery, it will likely need to be versioned also to avoid breaking everything when bringing in new versions.
-brady
OpenEMR
robertdown wrote on Thursday, August 15, 2013:
Ok, I’ll bring in the production code straight-away.
robertdown wrote on Thursday, August 15, 2013:
Brady, is there any kind of global header file that I can drop the bootstrap css and js files and select2 files that get applied to all the files.
If not, those files would have to be added to every files.
If that header file doesn’t exist, is it something I can add? I think there’s a lot of benefit to be gained by having 1 function that brings in all (or most) of the header information.
Thoughts?
s0skillz wrote on Thursday, August 15, 2013:
Hi Robert,
I really like what you are doing very clean. A year ago I posted a screenshot showing what I would like openemr look like and a few people like it, unfortunately none of us know how to code. Here is the screenshot https://lh5.googleusercontent.com/-e34Pw5Abnk8/TxocdkFgruI/AAAAAAAAD38/0WzQJtJH0_o/w958-h599-no/oemr+andres+style.jpeg I hope you continue with this project openemr really needs this.
bradymiller wrote on Friday, August 16, 2013:
Hi Robert,
There is not global UI header file. There is a global type file at interface/globals.php but this is used during every script call (including ajax where ui stuff not needed). You can always make one, though, which can use in your UI upgrade. Goal should be to get the stuff your working on well worked out(may be some minor internationalization things to work out in screen2, but since only a couple strings there’s a way to give control of these translations to OpenEMR). Then can commit that to codebase and then you can expand it throughout the codebase.
Also, when ready for a full review will be nice to get it all into a couple commits with each new external package as a commit in addition to your code as a commit (or even one big commit if easier) to make review process easier. Let us know if you need some help with doing this when the time comes.
-brady
OpenEMR
deschel wrote on Friday, August 16, 2013:
Hi Robert,
I am working on an improved demographics webpage. I too am not crazy about the current interface in OpenEMR and played with incorporating a different interface in the webpage. I saw twitter bootstrap and this inspired my interface. Like you, I wanted to change the tabs appearance. I realized that the visual interface is mostly in the bootstrap.css file. I studied this and realized that there was only a small part of this that really impacted what I was doing. Too make it easier to incorporate my themes into OpenEMR I copied the relevant css files from bootstrap to modify one of the OpenEMR theme files (style_oemr.css) and of course I renamed it. This css file was placed in the directory /interface/themes (with the other them files), and made it so that you can select this new theme file in globals. Any changes in this theme file were easily applied to all of OpenEMR. I not only copied what was in bootstrap, but I also made changes to the css code that I took from bootstrap to improve the look even more.
I suggest that you take this approach, because it will make your life soooo much easier, and also allow you to develop the interface that you take from the bootstrap.css file. There are some cool interface themes there, but there are some that could be customized/improved.
I am basically providing an in depth rationale and how to to what Brady hinted at in his previous posts to this discussion.
Since only your theme would use bootstrap.css and not anyone else’s, you don’t want to include bootstrap.css on every page of openemr. You want to only include it if your theme is being used. It sounds like your approach would include it everywhere.
If you look in the code of openemr the css file of the theme is called in the php code with:
$css_header is the path to the theme selected in globals. I guess that you can change this in every page that does this and call your “global style header”.
However, for the css aspect of your interface overhaul, it would be easier, more compatible with the existing OpenEMR code, and more customizable to create a css file that is derivative of style_oemr.css, incorporating the css code from bootstrap.css into this derivative. This way you don’t need to change the above code.
In your interface overhaul, you will probably only need to use a small subset of the css definitions in bootstrap.css. Therefore, you don’t really need to include the file as a whole.
Too bad, you can’t use “include” in css files. It would make life so much easier if you could.
I really do like what you are trying to do. I already did a little of what you are trying to do as a side track to my project. I like a lot of the css themes in twitter bootstrap.
Please consider my suggestion. Also, I’d like to hear from Brady to see if this approach is consistent with what he is suggesting.
David Eschelbacher MD
bradymiller wrote on Friday, August 16, 2013:
Hi David and Robert,
I’ll leave it up to the developer. For the css portion, David’s idea seems very smart and non-obtrusive(I think this is what Robert is planning for his modern theme). For the js parts though, I think Robert won’t be able to get away from including them on the scripts or making a global script to inlcude them (note it looks like Robert is planning to make these js parts work with the older themes per the screenshots).
Here’s the stuff regarding this project that Robert has placed on the Active Project page:
http://www.open-emr.org/wiki/index.php/Active_Projects#UI_Improvement
(I think the takehome is there are two different projects, the Modern Theme(css file) and then the UI Modernizations(bunch of js stuff))
-brady
OpenEMR
mdsupport wrote on Friday, August 16, 2013:
David, ‘c’ in css is ‘cascading’. That means not only can you ‘include’ (aka @import) other css files but as a good practice you should layer your UI by ‘including’ various UI elements in a flexible manner. For example, look at the simple tip we posted sometime ago.
Use of css does require basic discipline on developer side. When a new functionality is added, developers need to scrupulously declare the class of all UI elements but not the styling details. Unfortunately, the current code has hard declarations. This means if one wants a black and white theme with large font, there are many screens where developer/sponsor’s color and font choice will override the theme.
CSS design is a completely different skill than functional development. In future it will become even more important as new browsers support vastly superior functionality throughout the application with minimal effort.
