The road towards wxIFM2 - now on sourceforge! Topic is solved

Do you like to promote your wxWidgets based application or component!? Post it here and let's see what the critics have to say. Also, if you found that ONE wx component the world needs to know about, put it here for future reference.
Post Reply
SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am

The road towards wxIFM2 - now on sourceforge!

Post by SnakeChomp »

Due to the changes to my personal interests over the past year and half since wxIFM was originally released, I feel changes are necessary in order to further the development of wxIFM. As many of you probably know, I am writing my own cross platform GUI kit (OMGUI) to replace wxWidgets for my personal projects. wxIFM is one of those things I will be rewriting for this toolkit once it is ready to support it. As I still believe wxIFM to be the superior docking solution available to wxWidgets, it is a shame to see no progress being made and other less capable toolkits being given the spotlight (see wxAUI and its stickied thread atop the announcements forum). With 1500 downloads since January of 06, wxIFM 1.0.5 is popular enough that I would hate to see it die at the hands of stagnation. In an attempt to remidy this situation, I am beginning work on the next generation of wxIFM.
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)
The enhancements I plan on making are:
  • 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.
If there is a particular feature you would like me to incorporate into wxIFM2, feel free to tell me what they are. Now, its time for me to get to work.
Last edited by SnakeChomp on Sun Jul 23, 2006 6:11 am, edited 2 times in total.
priyank_bolia
wxWorld Domination!
wxWorld Domination!
Posts: 1339
Joined: Wed Aug 03, 2005 8:10 am
Location: BANGALORE, INDIA
Contact:

Post by priyank_bolia »

Though you looks angry, but you are a vaulable resource to wxWidget. I am eager to see the new wxIFM2. I guess one day I will find some wxLib for Visual studio type docking framework, as available for .NET
eranif
Moderator
Moderator
Posts: 610
Joined: Tue Nov 29, 2005 7:10 pm
Location: Israel

Post by eranif »

Hi,

First a quick question:
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)
Does it mean that you are going to re-write wxIFM from scratch?


Things I would like to see in wxIFM:

1. Hint rectangle (like wxAUI)
2. Gradient captions (maybe it exists, dont know)
3. The 'X' button on captions should be improved.
(for example, when the colour is too dark, hovering the 'X' makes it black which one cant see. Or when the 'X' button is pressed, there should be a animation to respond the MOUSE_DOWN event)
4. Tabs:
- When there are many tabs on a window, the drawing of the tabs exceeds the client area
- Maybe provide a scrolling buttons on the right?
- Allow users to react on pressing tabs (for poping up menu and such)
5. Double clicking on a floating window's caption - should restore it to its last docking position (as VS does)
6. There are cases when the content window is being hidden by other windows, this must not happen. to see what I mean, follow these steps:
- run the wxIFM demo
- resize the 'Console' window to capture almost the whole bottom area
- now drag the 'Console' window and dock it to the right of the screen
I think that there should be a minimum size for the content window, so it will not be hidden.

Eran
IDE: CodeLite + wxCrafter
OS: All
https://wxcrafter.codelite.org
https://codelite.org
SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am

Post by SnakeChomp »

eranif wrote:Hi,

Does it mean that you are going to re-write wxIFM from scratch?
No, wxIFM already contains the pieces of code I need to implement the important bits: sizing of stuff inside containers, laying out containers, resizing, dragging, etc. I just need to translate them from the older events based system to the newer one.
Jamie
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 205
Joined: Wed Mar 30, 2005 10:56 pm

Post by Jamie »

wxIFM2 - LGPL or wxWidgets License?

Finally some modern C++. wxWidgets biggest drawback is the "we support them all" mentality wrt compilers. Set some minimum required versions and don't compromise. Will you be using Boost?

The main reason why people would prefer wxAUI is the toolbar support. Is this a planned feature?

IIRC wxAUI makes use of the existing sizer code and is compatible with MDI. Neither of which is true for wxIFM1. Something about using one panel in the frame to take up the whole client area? Anyway, are you planning on making wxIFM2 work with MDI? I know, I know, MDI is evil :)

Thanks, and apologies if anything I said here is incorrect.
SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am

Post by SnakeChomp »

Jamie wrote:wxIFM2 - LGPL or wxWidgets License?
I don't know yet.
Will you be using Boost?
boost::shared_ptr is all I need to use from boost at this moment. I do not forsee anything else from boost being necessary.
The main reason why people would prefer wxAUI is the toolbar support. Is this a planned feature?
Sigh. Its not a priority.
IIRC wxAUI makes use of the existing sizer code and is compatible with MDI. Neither of which is true for wxIFM1.
Sorry but you are wrong here. wxIFM works fine with an MDI application provided you are not using wxFrame::CreateToolbar. wxIFM's sizing algorithms are way beyond anything sizers are capable of, so there is no need to use them.
Anyway, are you planning on making wxIFM2 work with MDI? I know, I know, MDI is evil :)
As a side effect from one of the implementation choices I made this time around, wxIFM2 will work fine with MDI apps that also use wxFrame::CreateToolbar. Each component will be accomanied by its own native widget, so there would be any offset problems as I'm no longer drawing on the DC for the parent window.
SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am

Some specifcs about Panels & Containers

Post by SnakeChomp »

Having just written the docs for how Panels will behave in wxIFM2, I want to share this information, as it is actually a feature which has been requested a few times before.

Panels in wxIFM2
Panels are a component which hold child widgets (wxWindows). Panels are constructed with the ID of their child widget. If the ID does not exist at the time of construction, the Panel will be hidden within the interface layout. When a widget with the given ID is created, the Panel will automatically be shown and will contain the Widget as its child. If that widget is later destroyed, the Panel will automatically be hidden again.

This feature makes it very easy to destroy a wxWindow in response to a user clicking the "X" for that Panel to save resources, allowing you to create the wxWindow again only once it is needed.

The other thing I want to mention has to do with Containers.

Containers in wxIFM2
Containers are Components which serve as parents for other Components. They typically will hold TabbedContainers, which are Containers that hold Panels and display one tab per Panel. Containers can be assigned ID values upon creation. These ID values must be unique amongst all other Containers. Giving a container an ID value will prevent the Container from being destroyed when all its children have been undocked. This allows for the addition of new children to this container later on, and the children will show up where they should.

When adding a new wxWindow to the layout, you can specify the ID of the Container which should contain this window. Because Containers with an ID will never be destroyed, you can always add new wxWindows to them, and they will always show up in the right place. This allows for easy grouping of wxWindows that have a similar purpose, like build output windows.

These two features (okay, mainly the container one) should make wxIFM much more usable in dynamic applications like Code::Blocks where plugins are allowed to create their own windows which need to be added somewhere into the interface. Instead of having these new windows show up in random locations, they will always show up in a consistant location.
SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am

Post by SnakeChomp »

You know how almost every single person who used the wxIFM demo mentioned that if you resized the window to be too small things would start to overlap and the content window could disapear and all that stuff? Well, my reply to those comments up to now has always been "I can't figure out the algorithm to calculate minimum sizes." Well, I finally figured it out.

Start with the minimum size for the content window. Then iterate in reverse order through the list of top level containers. For containers to on the left or right side, min_width = min_width + container_min_width, and min_height = max(min_height, container_min_height). Containers on the top and bottom are the opposite, max for width and sum for the height. Once you are done you have the minimum size for the interface.

Now that I can properly calculate the minimum size, components won't start to overlap themselves because you made the window too small.
SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am

Important information this time...

Post by SnakeChomp »

Okay, so maybe the last post didn't really contain any exciting information. I trust this post will be more worthwhile reading.

wxIFM2 has a home...

And that home happens to be on a certain place called sourceforge.net. I will admit, the recent comotion in the wxAUI thread got me working again, and moving to sourceforge will be an important step for exposure and building interest.

...and a license too

I previously said I don't know what license I would use. Well, I do now: the BSD license.

You can find the svn repository for wxIFM2 on sourceforge.
Last edited by SnakeChomp on Mon Jul 24, 2006 11:40 pm, edited 1 time in total.
SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am

wxIFM 2 demo

Post by SnakeChomp »

I have implemented the new layout algorithms that I described earlier and figured that I should release a demo showcasing the new algorithms to prove that they do infact work. The number 1 comment that everybody had about wxIFM 1 was that components would overlap eachother and could cover up the content window. Well, no longer!

Win32 demo: http://www.snakesoft.net/ifm/demo.zip
Normal size: http://www.snakesoft.net/ifm/images/alg ... normal.gif
Minimum size: http://www.snakesoft.net/ifm/images/alg ... inimum.gif

In the demo, the conent window has a minimum size of (200,200) and each textbox has a minimum size of (100,50).
SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am

Getting Started documentation available

Post by SnakeChomp »

I have completed the initial version of the "Getting Started" documentation, which is a tutorial style introduction to the library. For those interested in seeing what the new api will look like, you can find it here: http://ifm.sourceforge.net/docs/getting_started.html

Also, the current documentation for IFM's full API can be found here: http://ifm.sourceforge.net/docs
lester
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 211
Joined: Sat Sep 02, 2006 7:24 pm
Location: Ukraine

Post by lester »

I have try wxIFM - it`s great!!! But I understand that work on it has been stopped? :(
Last edited by lester on Fri Feb 16, 2007 2:01 am, edited 1 time in total.
lester
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 211
Joined: Sat Sep 02, 2006 7:24 pm
Location: Ukraine

Post by lester »

Where I can find last version of wxIFM2 that`s builded like IFM1.05 with vc projects and without boost, or please write how to build wxIFM2
Post Reply