wxIFM 1.0.5 - docking library for wxWidgets
Posted: Wed Dec 15, 2004 8:45 am
If you are looking for information about 1.0.5, please jump to this post: http://forums.wxwidgets.org/viewtopic.php?p=24321#24321
If you are not looking for informationa bout 1.0.5, you can find a history of wxIFM anouncements within this thread.
Hello all. I am making this post to basically raise awareness in regards to the project I am working on. I call it...
wxIFM
wxIFM? What the heck is that?
wxIFM is what I call an "Interface Management System", or IFM for short. Its basically a docking library. Think wxFL, only bigger (and better)
wxIFM is really comprised of two elements: an interface management framework, and an implementation which programs can use. The framework is a set of events and base classes used for plugins whih implement the interface functionality.
General overview of wxIFM
At its core, wxIFM revolves around the framework it defines. This framework is based around a plugin architecture in which functionality is implemented in event handlers. The framework defines many events which are used to actually implement functionality within an interface. Being a plugin based system allows for layers of functionality without having to override virtual functions or derive countless classes. It also allows two different plugins which implement two different things to be used in the same application without changing any code within either plugin, or the wxIFM library. It also provides for run time connecting and disconnecting of plugins to switch features on and off. It would be nice to eventually see plugin from DLL support, but I hear c++ dll's are a pain to deal with. DLLs are the goal however.
wxIFM strives to be easy to use and relatively transparent to the application programmer. Similar to wxFL, all the program needs to do is create a wxInterfaceManager object (congruent to wxFrameLayout), optionally tell it what (extra) plugins you wish to use, and tell it what children it should manage. The rest is taken care of by the wxInterfaceManager object and the interface plugins.
One word, why?
Short version: wxFL sucks, so I'm replacing it.
Longer version: I wanted a cool interface for my html editor that supported docking and all that fun stuff you see in many modern IDE's, but I was unhappy with wxFL. The code was a mess, it was slightly glitchy, and hadn't been worked on in a while. I wanted something better, and I wanted something that I made myself (of course ). So I began work on this system. Almost three months later, and after having started over twice, I am ready to present a pre-release for the community to see what I have been doing.
The current state of wxIFM
While I may be posting to anounce the fact that wxIFM exists, I am not posting the fact that wxIFM is ready to replace wxFL. In fact, it is not. Currently, resizing and moving of children after they have been added to an interface is not implemented. You can hide and show them however.
This does not mean that I am having trouble implementing this, or that I won't be. I just haven't started work on it yet. I fully expect that at least resizing will be ready within a week. The main purpose of this announcement is to simply let people know that this exists, and give them a chance to view the API.
For those of you who are curious, below are links to the current code of wxIFM, including a demo application, and a screenshot of said demo application. Note that I do not have makefiles, because I am a win32 person, and have never used makefiles. If anybody would be so kind as to make some, please contact me. The MSVC6 project is included for both wxIFM and the demo app.
Some random notes
wxIFM is currently built against the 2.5.3 snapshot.
Compilation under any port other than win32 is untested. If you can't compile it on a particular port, please let me know, or better yet try to fix it.
The current interface implementation will eventually be an almost complete clone of the interface of Microsoft Visual C++ 8 beta.
The code provided in the zip file is to be considered beta. Future releases of the wxIFM system may not remain backwards compatible with this code. Use it in real applications at your own risk. Although I highly doubt I would change anything so drastically as to create a serious incompatability, I will be adding on as I develop wxIFM and some things may be tweaked in the process.
Most of the code is documented with doxygen docs, check the header files.
While doxygen comments exist, documentation does not (yet). The library will be documented in its entirity before release.
Check changes.txt and todo.txt if you care about how things have progressed.
Feel free to find any bugs in the frame work and let me know. I try to think of as much as I can, but I can't think of everything. Also please feel free to comment on the current implementation. If something works one way but you think it should work another, tell me!
Compiling notes
Building the wxIFM project will generate wxmsw25d_ifm.lib and wxmsw25_ifm.lib in debug and release modes within "lib/vc_lib/" if compiling using the provided MSVC6 project.
There are two MSVC specific #pragma's contained within ifm.h. You might want to comment them out if not compiling in MSVC. (I tried a quick #ifdef __VISUALC__ but it didn't seem to work so I am not changing the zip file)
[some edits to fix grammar]
[edit to remove old downlink link]
If you are not looking for informationa bout 1.0.5, you can find a history of wxIFM anouncements within this thread.
Hello all. I am making this post to basically raise awareness in regards to the project I am working on. I call it...
wxIFM
wxIFM? What the heck is that?
wxIFM is what I call an "Interface Management System", or IFM for short. Its basically a docking library. Think wxFL, only bigger (and better)
wxIFM is really comprised of two elements: an interface management framework, and an implementation which programs can use. The framework is a set of events and base classes used for plugins whih implement the interface functionality.
General overview of wxIFM
At its core, wxIFM revolves around the framework it defines. This framework is based around a plugin architecture in which functionality is implemented in event handlers. The framework defines many events which are used to actually implement functionality within an interface. Being a plugin based system allows for layers of functionality without having to override virtual functions or derive countless classes. It also allows two different plugins which implement two different things to be used in the same application without changing any code within either plugin, or the wxIFM library. It also provides for run time connecting and disconnecting of plugins to switch features on and off. It would be nice to eventually see plugin from DLL support, but I hear c++ dll's are a pain to deal with. DLLs are the goal however.
wxIFM strives to be easy to use and relatively transparent to the application programmer. Similar to wxFL, all the program needs to do is create a wxInterfaceManager object (congruent to wxFrameLayout), optionally tell it what (extra) plugins you wish to use, and tell it what children it should manage. The rest is taken care of by the wxInterfaceManager object and the interface plugins.
One word, why?
Short version: wxFL sucks, so I'm replacing it.
Longer version: I wanted a cool interface for my html editor that supported docking and all that fun stuff you see in many modern IDE's, but I was unhappy with wxFL. The code was a mess, it was slightly glitchy, and hadn't been worked on in a while. I wanted something better, and I wanted something that I made myself (of course ). So I began work on this system. Almost three months later, and after having started over twice, I am ready to present a pre-release for the community to see what I have been doing.
The current state of wxIFM
While I may be posting to anounce the fact that wxIFM exists, I am not posting the fact that wxIFM is ready to replace wxFL. In fact, it is not. Currently, resizing and moving of children after they have been added to an interface is not implemented. You can hide and show them however.
This does not mean that I am having trouble implementing this, or that I won't be. I just haven't started work on it yet. I fully expect that at least resizing will be ready within a week. The main purpose of this announcement is to simply let people know that this exists, and give them a chance to view the API.
For those of you who are curious, below are links to the current code of wxIFM, including a demo application, and a screenshot of said demo application. Note that I do not have makefiles, because I am a win32 person, and have never used makefiles. If anybody would be so kind as to make some, please contact me. The MSVC6 project is included for both wxIFM and the demo app.
Some random notes
wxIFM is currently built against the 2.5.3 snapshot.
Compilation under any port other than win32 is untested. If you can't compile it on a particular port, please let me know, or better yet try to fix it.
The current interface implementation will eventually be an almost complete clone of the interface of Microsoft Visual C++ 8 beta.
The code provided in the zip file is to be considered beta. Future releases of the wxIFM system may not remain backwards compatible with this code. Use it in real applications at your own risk. Although I highly doubt I would change anything so drastically as to create a serious incompatability, I will be adding on as I develop wxIFM and some things may be tweaked in the process.
Most of the code is documented with doxygen docs, check the header files.
While doxygen comments exist, documentation does not (yet). The library will be documented in its entirity before release.
Check changes.txt and todo.txt if you care about how things have progressed.
Feel free to find any bugs in the frame work and let me know. I try to think of as much as I can, but I can't think of everything. Also please feel free to comment on the current implementation. If something works one way but you think it should work another, tell me!
Compiling notes
Building the wxIFM project will generate wxmsw25d_ifm.lib and wxmsw25_ifm.lib in debug and release modes within "lib/vc_lib/" if compiling using the provided MSVC6 project.
There are two MSVC specific #pragma's contained within ifm.h. You might want to comment them out if not compiling in MSVC. (I tried a quick #ifdef __VISUALC__ but it didn't seem to work so I am not changing the zip file)
[some edits to fix grammar]
[edit to remove old downlink link]