There's already an effort underway. LO has a fundamental classes when it comes to implementing the VCL: OutputDevice, SalGraphics, SalFrame and SalInstance. Mainly SalGraphics and OutputDevice though. The problem is it is so intertwined, the biggest issue being that classes don't follow the Single Responsibility Principle.

It's getting there, but I've only really done any real coding in anger in the last 5 months and this is a 25 year code base...

Please do it in D. C++ is horrible. But if you insist in C++, isn't nana an option?

Doing it in another language would probably require rewriting the entirety of LibreOffice, which is a very massive project with code spanning at least a decade, if not more. They recently switched away from a proprietary (in the sense that only they used it) build system to one of the more conventional ones (I forget from what to what), so anything IS possible, but the question is whether it would be worth it. I know LibreOffice has some Java interoperability, but I don't know how much, or whether that could be leveraged.

Oh... we are trying to get away from a dependency on Java :(

Nana looks interesting - I'm always looking at C++ toolkits to better understand how they work. I was looking at it's event system, seems pretty nice. gtkmm also has a nice signals system also.

But yes, rewriting in D would be more than complex. LO has over 7 million lines of code, the real issue is that there is still a lot of cruft (e.g. the Resource class, tools, etc) and we are progressively working on removing this and replacing with saner libraries, such as boost.

Interestingly, VCL actually works pretty much by itself. I recently resurrected some VCL demos and got them to work as standalone executables. VCL could actually be as clean to work with as nana, but the guts need a rewrite. And it would do it in a cross-platform way, but with largely native widgets.