User forums > General (but related to Code::Blocks)
Docking library
SnakeChomp:
Hi. I happened to do a random google search for wxIFM and the third hit happened to be a bounty thread on this forum for wxIFM testing. I browsed further and happened to notice that you seem to be using wxDockIt now for docking windows? I am curious as to why you made this mistake, I mean choice. :lol:
p.s. If you don't know who I am, I am the author of the wxIFM library.
mandrav:
--- Quote from: SnakeChomp on August 19, 2005, 11:37:41 am ---Hi. I happened to do a random google search for wxIFM and the third hit happened to be a bounty thread on this forum for wxIFM testing. I browsed further and happened to notice that you seem to be using wxDockIt now for docking windows? I am curious as to why you made this mistake, I mean choice. :lol:
p.s. If you don't know who I am, I am the author of the wxIFM library.
--- End quote ---
Hi there :)
Two reasons:
1) The demo would crash with some specific operations (sorry, can't remember more now)
2) I read in one of your posts at the wxwidgets forum, that you stopped development of wxIFM. That was not exactly encouraging ;)
Please, make me feel stupid for choosing wxDockIt ;) (IOW: make me understand that I was wrong).
Great work anyway :D
Yiannis.
SnakeChomp:
You must not have run a recent version of the demo. The recent code is rock solid as far as my testing goes. As for why wxDockIt is the wrong choice, have you ran the wxIFM demo program and run through the tutorial? That tutorial will let you experience the power of the docking wxIFM provides. Its not like wxDockIt, where you can only have a single row of windows on any side of the frame. This is full blown docking ala MS Visual Studio 2003 and 2005. You can have anything where ever you want it, including every single dockable window contained in the same floating window. (Pointless but fun!) You say that me not actively developing wxIFM is discouraging, but use wxDockIt which has not had a release in a year (this recent distribution of CVS doesn't count imo) and claim it is being developed? I personally say that wxDockIt has been long dead and I see no real evidence against that. I may not actively develop new features for wxIFM but I will actively maintain wxIFM for quite some time. If the wxWidgets devs ever get their act together and branch, wxIFM will finally move into its new home in the wxWidgets source. Once its there I will be its maintainer and will accept patches and what not. If I get bored I may add new things to it myself. I don't plan on it, but its not an impossibility. I will also assist anybody who wants to add new features but has questions.
Some more concrete reasons as to why wxIFM > wxDockIt (IMO)
* Based around a plugin architecture, wxIFM is easily extensible, allowing you to create new features which can be loaded and unloaded at run time, even from a dll!
* Forget XOR rectangles; wxIFM uses the vastly more intuitive drag'n'drop docking system seen in recent betas of MS Visual Studio 2005. As you drag a window, arrows pop up letting you know exactly where you need to place to mouse to dock a window in a specific location. No more blindly wiggling the mouse hoping that XOR rectangle goes where you want it to.
* Unlimitedly flexible docking mechanisms provide you the power to create absolutley any window layout you can imagine.
* Tear-able tabs let you have more than one window in the same spot saving space but still allowing flexability in your interface
* Put as many windows into the same floating window as you want
* Drag entire containers containing many child windows just like you were dragging any other dockable window
* Less important reasons but things I still consider to be important none the less
* wxIFM will have a home within wxWidgets source, so it will be supported indefinately
* The source is clean which aids maintainance and feature additions
*end salesman act*
mandrav:
--- Quote from: SnakeChomp on August 19, 2005, 12:26:59 pm ---*end salesman act*
--- End quote ---
Heheh, thanks for the info.
Since we have you here, would you mind answering the following?:
1) Does it only support wx2.6x or does it work with wx2.4.2 too?
2) Does it work under non-windows platforms?
3) The main problem I found with wxDockit (as well as other wx libs) is to build it for usage in C::B. C::B links to a dynamic wx dll (compiled with WXMAKINGDLL=1). Does your code allow for linking to wx DLL? Most wx-related libs I tried (wxDockit too), only build well when linked statically with wx. Notice that when C::B is compiled, it uses -DWXUSINGDLL.
Now point us to the newest wxIFM demo so we can get even more enlightened ;)
Yiannis.
SnakeChomp:
Win32 precompiled demo: www.snakesoft.net/wxifm/demo.zip
Official wxIFM thread: http://www.solidsteel.nl/users/wxwidgets/viewtopic.php?t=2153
My site with only a small bit of info: www.snakesoft.net/wxifm
I don't think there is anything specific preventing compiling wxIFM using a dynamic build of wxWidgets. The wxIFM project files are set up to only link against wxWidgets statically but that is easily correctable. wxIFM source itself needs a few changes to be compiled into a dll itself (exporting symbols is all).
wxIFM works on all the major platforms (windows, gtk, mac). Floating is not enabled on the mac because afaik wxWindow::Reparent is not implement for that platform. I don't have access to test this so I don't know if this is true. It can be tested easily by strictly enabling flloating support for a mac build and seeing if it works.
There is nothing stopping wxIFM from working on wxWidgets 2.4.2 except for the fact that wxIFM uses some wxWidgets #defines contained in the more recent events header, those being the new event declaration macros (wx__DECLARE_EVT0 or something) and the wxFooEventHandler() cast macros. You would have to change all of the event declarations, or copy / paste the wx_DECLARE_EVT_0 macro for things to compile in a 2.4.2 environment, as well as any wxFooEventHandler cast macros the source uses.
I feel I should mention that there are a few "heavy hitting" features I believe wxIFM still lacks: namely being able to have more than one interface state which you can switch to at any given moment and the ability to save / load these states. That being said, if wxIFM was used by a "heavy hitting" project like Code::Blocks I would be more inspired to add those features. :wink:
Navigation
[0] Message Index
[#] Next page
Go to full version