It would be great to be able to choose alternative widget sets and css files, so that widgets don't have to replace the existing ones to get used.
It may be that Gene will be interested in doing this himself. Still, I'd like to offer to do it.
---TLDR Boundary---
I'd be interested in making a fork and working on it. G can take or leave what he likes, or tell me to do it a different way. I poked around this evening, and I see that defaulting to homegenie/generic/<type> is hardcoded in pages/control/_control.js, and I don't see a useful way to use the other ways widgets are matched to modules there.
I've also noticed that what ui-theme choices there are are provided in js/api/homegenie.inc.js. The lettered choices and the changes they make are fixed there.
Obviously I've only had a cursory look, and Gene will know instantly if this makes sense. My instinct is that the cleanest most useful way of changing this without major changes to the code would be to add the theme's widgets in the same way they are imported / exported now, but en masse. In the first level directory of the theme directory, place css and images subdirectories. Load theme css after existing css.
In the code, have the themes selectable, perhaps in the same place where the lettered themes are now. Then change the _control.js code so that themer.theme/generic/<type> is looked for before homegenie/generic/type.
In that way (I'm guessing, haven't got this far into it) the theme can use css to try to bully existing widgets to dimensions that won't destroy the theme's layout. Some things will get ugly, but that's between the themer and the user of the device / widget in question, hehe.
I realize saying all this is very forward of me, since I just got here and I'm just guessing. I hope I'm not offending. But I also hope to provoke Gene and others to tell me I'm wrong and why, and in that way point me in a better direction faster than I could get there myself.
Waddya think?