I don't think you can reasonably expect to code to the same API if you switch the underlying UI library, except by simplifying a lot, and that wouldn't benefit the good parts of either UI library.
Yes , these are the modifications i mention , but yes this would require a lot lot work ,when probably after TurboBadger integration the default UI would be obsolete anyway.So maybe it would be better just switching to TurboBadger as the UI (by using the existing UI unterface and expanding it).Maybe it worth a new branch for testing this.
This has been discussed before and I do think the ideal would be for the UI library to be wrapped so that you use e.g. Urho events and Urho resources instead of the UI library's native ones. However in practice it's a very difficult ideal, since either you have a lot of wrapping/adaptation work to do, or lose features. Compare to Bullet: Urho's physics components don't expose Bullet nearly completely so for a physics power user using Bullet directly could actually make more sense.
Well i would rather lose features than using api's directly.Thats the main reason i like Urho3d.It's clear and easily understandable interface.Once you learned the coding workflow you don't need extra tutorials to get into other features.By using apis directly you always have to learn the new library first...Which isn't really attractive for new users
here's a screen shot of my modified gui skin.I added some shadows , highlights to buttons and switched to monochrome style.I think it is more pleasant for the eyes than the deafult blue style.