The information I can give you right now is that I will be dropping my plugin system in favor of a spedier development. The justification for this is that while having a plugin system extendable at run time is neat to talk (brag) about, it is hard to develop such a system, and honestly, no one will ever make use of the run time extension ability. The end result is that the plugin system is a waste of time.
The other primary piece of information I can give you is that wxWidgets integration is no longer important to me. This will allow me to code modern C++, use the C++ standard library, and generally make my life easier. Conveniently, this "modern C++" convention also fits nicely with OMGUI.
Lastly, I will be writing wxIFM2 to operate with wxWidgets as the backend for now, as OMGUI is not yet ready to host such a library. However, the interface for wxIFM2 will be written in such a way that swapping out wxWidgets backend for an OMGUI backend will not require changes to the front end itself (except for the changing of a few typedefs for the interface that programmers use). This will allow the library to be maintained and developed both for OMGUI and wxWidgets, making it both cross platform and cross library.
At first wxIFM2 will implement the existing wxIFM features before enhancing them. These features are:
- The same tabulated docking as seen in wxIFM1.
- The same docking system presently seen in wxIFM1 (The arrows you see when dragging windows around isntead of XOR rectangles)
- Support loading and saving of different layouts. Support for loading and saving will actually be added fairly early n the development cycle as it is so necessary for a docking toolkit to be useful.
- The ability to drag a component from one Frame and dock it into another Frame
- Adding realtime feedback to the docking system to show the user just where the window will end up when they dock it.