wxIFM 1.0.5 - docking library for wxWidgets

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.
asp
Knows some wx things
Knows some wx things
Posts: 32
Joined: Sun Sep 12, 2004 4:35 pm

Post by asp » Wed Nov 09, 2005 10:53 am

Ok. Thanks! :)

SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am
Contact:

Redraw issues fixed and 1.0.5 coming soon!

Post by SnakeChomp » Sun Nov 20, 2005 3:15 am

Hello everybody! This is a mirrored of the post I made to the Docking Libraries thread in the C++ Development forum.

I am posting to notify everyone that the cause of the paint artifacts on slow systems has been identified! wxIFM connects to its parent's wxEVT_PAINT event. During processing, it creates a wxBufferedPaintDC on which to paint, paints, and then destroys it. Once it does this, it calls event.Skip().

It was mentioned to me just today that this event.Skip() call might be a problem. Turns out, it was! Removing this one line of code eliminates 99.9% of artifacting. I don't say 100%, because if I add debug output to my painting routines to make them unbelievably slow and try super duper duper hard I can make an artifact show up after about 30 seconds. This is infinitely many times better than the previous screenshots I have posted describing this problem.

This bugfix will be included in the 1.0.5 release which will be coming up shortly. Also coming up shortly should be wxIFM debut in the wxWidgets CVS tree. I will release 1.0.5 once this happens, or within the next few days if CVS integration does not occur soon enough.

There have been several fixes made for 1.0.5 so far. Heres a list:
  • DLL builds of wxIFM are now possible. wxIFM can also be built properly when you are using a DLL version of wxWidgets. In order to use a DLL build of wxIFM, you must be using a DLL build of wxWidgets.
  • wxInterfaceManager::SetStatusMessagePane now accepts which status bar you should use to display messages instead of assuming it should use the parents status bar if the parent is a frame.
  • All known cases where resize sashes were appearing incorrectly have been corrected
  • Cases where containers were not correctly calculating a minimum size of (0,0) when they had no visible children have been corrected.
  • Panel tabs will no longer be drawn if there is only one tab
  • Panels now generate a name for themselves based on the names of their tabs. This means that docking a panel as the tab of another panel no longer yields an empty tab, but a tab with the name of all of the nested panels tabs.
  • Use wxSYS_DRAG_X and wxSYS_DRAG_Y instead of xSYS_DRAG_X/2 and wxSYS_DRAG_Y/2 as the drag threshold values, so dragging is less sensitive now.
  • Resize sash positions and visibility states will no longer beecalculated everytime a component is hidden or shown unless the event is supposed to update the interface. This acts as both an optimization and a bug fix.
  • There is now a new compile time flag, IFM_ALLOW_NESTED_PANELS, to control whether or not nested panels are allowed to be created. It defaults to OFF, but wxIFM versions prior to 1.0.5 functioned as if this flag was set to ON. When OFF, docking a panel as a tab of another panel will remove all the tabs of the source panel and dock them as tabs of the destination panel. When ON, if a panel has only one tab, it behaves the same as if it was OFF, but if the panel has two or more tabs, the source panel will be docked as a tab of the destination panel which effectively creates multiple rows of tabs. This flag may be extened to a run time setting in the future.
  • Paint events for the window that wxIFM is managing are no longer skipped. This fixes redraw artifacts on Windows generated on slower computers.
Stay tuned for 1.0.5!

Jorg
Moderator
Moderator
Posts: 3971
Joined: Fri Aug 27, 2004 9:38 pm
Location: Delft, Netherlands
Contact:

Post by Jorg » Sun Nov 20, 2005 10:45 am

I can only say congratulations with your accomplishment SnakeChomp! You truely made a great docking library and the fact that the wx-devs want to incorporate it in the wx CVS, just acknowledges that it was sorely missed and it's robust !

Regards,
- Jorgen
Forensic Software Engineer
Netherlands Forensic Insitute
http://english.forensischinstituut.nl/
-------------------------------------
Jorg's WasteBucket
http://www.xs4all.nl/~jorgb/wb

Darjk
Earned a small fee
Earned a small fee
Posts: 12
Joined: Wed Nov 23, 2005 5:01 am
Location: Australia
Contact:

Post by Darjk » Sat Nov 26, 2005 5:22 am

G'day SnakeChomp.

Nice work on wxIFM, recently just made the switch to it from wxDockIt and I must say, its a lot more elegant coding wise. Haven't had any problems except for not being able to 'hide single tabs' which wrote a patch for and is being added to 1.0.5. Also the other problem is I have a glCanvas as the content frame but from time to time it "glitches" whatever is being rendered, hard to describe. I read in your post that an event.skip() is responsible for some drawing artefacts so I went through and commented it out and rebuilt the lib but it still seems to be occuring. So I'm hoping I just missed something.

Either way, nice work and eaglery awaiting your 1.0.5 release.
Cheers.

SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am
Contact:

wxIFM - 1.0.5 Release!

Post by SnakeChomp » Thu Dec 01, 2005 5:19 am

I am anouncing the release of wxIFM 1.0.5. I cannot wait any longer for wxIFM to be integrated into the wxWidgets CVS, so I am finally releasing the many improvements that have been made to wxIFM. Here is a list of changes, with very important ones being marked with !!!:
  • General
  • !!!DLL builds of wxIFM are now possible. wxIFM can also be built properly when you are using a DLL version of wxWidgets. In order to use a DLL build of wxIFM, you must be using a DLL build of wxWidgets.
  • wxInterfaceManager::SetStatusMessagePane now accepts which status bar you should use to display messages instead of assuming it should use the parents status bar if the parent is a frame.
  • All known cases where resize sashes were appearing incorrectly have been corrected
  • Cases where containers were not correctly calculating a minimum size of (0,0) when they had no visible children have been corrected.
  • Panel tabs will no longer be drawn if there is only one tab
  • Panels now generate a name for themselves based on the names of their tabs. This means that docking a panel as the tab of another panel no longer yields an empty tab, but a tab with the name of all of the nested panels tabs.
  • Use wxSYS_DRAG_X and wxSYS_DRAG_Y instead of wxSYS_DRAG_X/2 and wxSYS_DRAG_Y/2 as the drag threshold values, so dragging is less sensitive now.
  • Resize sash positions and visibility states will no longer be recalculated everytime a component is hidden or shown unless the event is supposed to update the interface. This acts as both an optimization and a bug fix. Instead, the resize sash states are flagged as invalid and recalculated for all top level containers when processing the next wxEVT_IFM_UPDATE event.
  • !!!There is now a new compile time flag, IFM_ALLOW_NESTED_PANELS, to control whether or not nested panels are allowed to be created. It defaults to OFF, but wxIFM versions prior to 1.0.5 functioned as if this flag was set to ON. When OFF, docking a panel as a tab of another panel will remove all the tabs of the source panel and dock them as tabs of the destination panel. When ON, if a panel has only one tab, it behaves the same as if it was OFF, but if the panel has two or more tabs, the source panel will be docked as a tab of the destination panel which effectively creates multiple rows of tabs. This flag may be extened to a run time setting in the future.
  • !!!Paint events for the window that wxIFM is managing are no longer skipped. This fixes redraw artifacts on win32 generated on slower computers.
  • The change to docking in version 1.0.3 which would change a containers orientation instead of spawning a new container had the side effect of making users unable to create new top level containers by docking to the left/right of a vertical top level container with only one child or to the top/bottom of a horizontal one. This issue has been corrected.
  • When using the X button on a panel, only the active tab will be hidden, instead of the entire panel
  • A default implementation of wxEVT_IFM_SETCHILD has been added to the default plugin. The implementation present within wxIFMDefaultPanelPlugin has been removed.

    Floating
  • !!!Floating is now enabled for all WXMAC ports as well as WXMSW and WXGTK
  • Recursively convert from CLIENT to ABSOLUTE sizes while walking up the chain of parent windows when determining the ultimate size for the window of a component being floated.

    !!!Configuration - this whole section is important =)
  • It is now possible to configure some look and feel options of wxIFM.
  • The wxEVT_IFM_UPDATECONFIG event has been added to notify plugins that their configuration data has changed
  • wxInterfaceManager::UpdateConfiguration has been added. This function must be called after any configuration data has been modified.
  • wxIFMDefaultPanelPlugin provides access to its wxIFMCaptionConfig and wxIFMTabConfig through wxIFMDefaultPanelPlugin::GetCaptionConfig and GetTabConfig.
  • Members of wxIFMCaptionConfig and wxIFMTabConfig are now private with public accessors and mutators
  • Added the following styles controlling captions
    IFM_CAPTION_SOLID // draw a solid background color
    IFM_CAPTION_GRADIENT // draw a gradient backround color
    IFM_CAPTION_LEFT // left align the caption title
    IFM_CAPTION_CENTER // center align the caption title
    IFM_CAPTION_RIGHT // right align the caption title
    Note: IFM_CAPTION_CENTER and IFM_CAPTION_RIGHT are currently not implemented
  • For a list of the configurable options, please see the documentation for wxIFMCaptionConfig and wxIFMTabConfig
I advise everybody to update to wxIFM 1.0.5 as soon as possible.

Notes for this release

To build a DLL version of wxIFM, you must define WXMAKINGDLL_IFM when building the library, and WXUSINGDLL in your applications. To use a DLL version of wxIFM, you must also use a DLL version of wxWidgets.

The Configuration API is in its infancy. There are not many configurable settings just yet. I will gladly accept patches which add more configurable options so long as they follow the format of the options that currently exist. It was important for me to add the configuration API to allow people to change certain "look and feel" options within wxIFM without having to modify their copy of the source. Such modifications would be lost during upgrades without this API. Now, new look and feel settings can be added to this API and then integrated into wxIFM, so they will not be lost.

This release is not a patch, it contains the entire wxIFM distribution as well as documentation.

It can be downloaded from here: www.snakesoft.net/wxifm/wxIFM-1.0.5.zip

The online documentation has been updated to reflect 1.0.5
The precompiled win32 demo available online has also been updated to 1.0.5: www.snakesoft.net/wxifm/demo.zip

Enjoy this version of wxIFM!

A fun fact for those that care
wxIFM 1.0.4 was downloaded a total of 511 times.

barr
In need of some credit
In need of some credit
Posts: 1
Joined: Wed Dec 07, 2005 1:18 am

Post by barr » Wed Dec 07, 2005 1:20 am

Very very nice! Thanks a lot for your hard work, it's a very nice library. I hope it will continue to progress. Congrats!

icStatic
Earned a small fee
Earned a small fee
Posts: 12
Joined: Thu Sep 08, 2005 6:41 pm
Location: Coventry, UK
Contact:

Post by icStatic » Sun Dec 11, 2005 6:03 pm

Thanks for the new version SnakeChomp, wxIFM is a seriously nice piece of work, keep up the great work!

icStatic
Earned a small fee
Earned a small fee
Posts: 12
Joined: Thu Sep 08, 2005 6:41 pm
Location: Coventry, UK
Contact:

Post by icStatic » Mon Dec 12, 2005 6:03 pm

I've got a minor bug to report. wxIFM 1.0.5 crashes when deleting the wxInterfaceManager object.

I say its minor because if you don't delete the object yourself and just leave it for wxWidgets to clean up itself (im assuming it does given its part of the window tree) then its fine. The crash did not happen in 1.0.4 using the same code.

The details of the error are at:
http://icstatic.uwcs.co.uk/ifmerror.txt

icStatic
Earned a small fee
Earned a small fee
Posts: 12
Joined: Thu Sep 08, 2005 6:41 pm
Location: Coventry, UK
Contact:

Post by icStatic » Sat Dec 17, 2005 10:57 am

I've got a minor bug to report. wxIFM 1.0.5 crashes when deleting the wxInterfaceManager object.
Ok scrap that, I found the problem. I was using an old version of the header files in my project. I was using "wx/ifm.h" which seemed to be the header used in previous versions. Now the sample uses "wx/ifm/ifm.h". Because I had simply copied them over the old one still existed and hence was giving me funny business. Changing the path solves the problem.

Lupus
Earned a small fee
Earned a small fee
Posts: 22
Joined: Wed Nov 17, 2004 7:49 pm
Location: Hamburg, Germany

Post by Lupus » Sat Mar 04, 2006 6:09 pm

@ SnakeChomp

Great work.

Exists any plans to make wxIFM like the Visual Studio dockable dialog, where you have the option to hide the dialog to the side of the window?
errare humanum est

wxWidgets 2.6.2
Visual Studio 2005

Vexator
I live to help wx-kind
I live to help wx-kind
Posts: 187
Joined: Sun Jan 30, 2005 2:50 pm
Location: Heidelberg, Germany

Post by Vexator » Sun Mar 05, 2006 10:21 am

what's the difference to wxaui?
Windows 7 Pro
Visual Studio 2010
wxWidgets 2.9.3

Chr
Earned some good credits
Earned some good credits
Posts: 115
Joined: Tue May 31, 2005 2:17 pm

Post by Chr » Sun Mar 05, 2006 12:10 pm

wxifm has a plugin-architecture, wxaui hasn't. wxAUI has some features which wxIFM hasn't and wxIFM has features which wxAUI hasn't. But wxAUI is still under active developpement, and big features are planned, look at the roadmap: http://www.kirix.com/en/community/opens ... admap.html
wxWidgets is nice

eranif
Moderator
Moderator
Posts: 607
Joined: Tue Nov 29, 2005 7:10 pm
Location: Israel

Post by eranif » Sun Mar 05, 2006 1:40 pm

One more note, wxIFM - looks better (espcially with the docking buttons) while wxAUI has the docking hint rectangle.

However, and this is a big however, here are the reasons why I choose wxAUI over wxIFM:

1. Good support - wxAUI author is very responsive and kind

2. wxIFM flickers like hell! If for example the conent window contains a text control dervied from wxScintilla, you simply cant drag any window over it, since you will leftovres of the dragged window all over ... while on wxAUI the same code is working perfect. The response I got from SnakeChomp:
You are seeing the artifacts when dragging over your editor windows because you are most likely in debug mode, and wxScintilla is drawing very slowly. It is not my fault that wxSTC is slow, and there really isn't any advice I can give you there other than trying a release build.
- this is not serious response - especially that under wxAUI the same code works perfect.

or try to resize the frame of your application you will notice heavy flickering.

3. wxAUI gives you support for docking toolbars - while in IFM you need to do workaround (having all windows placed on wxPanel and let the wxIFM manager to manage the panel)

But hey, Thats my opinion.

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
Contact:

Post by SnakeChomp » Sun Mar 05, 2006 5:20 pm

eranif wrote:2. wxIFM flickers like hell!
Here is my serious if rude response to this issue. wxIFM does not flicker at all. All painting performed by wxIFM itself it done on one single wxBufferedPaintDC, and therefore, nothing wxIFM ever draws will flicker. The problem you are experiencing is that another control is flickering when dragging a window ontop of it. Is that wxIFMs fault? No. Is it the controls fault? Yes. I've never used wxSTC personally so I cannot say anything about it performance wise. If wxSTC is not properly repainting itself when you drag another window over it, that is definately wxSTCs problem, and not mine. If I recall correctly, wxAUI does not immediately float things and drag them in real time like wxIFM does, nor does it allow already floating windows to move in real time. In doing this, there is no window being dragged over wxSTC, therefore there is no refreshing of wxSTC to be done incorrectly, and you will not see the issue. This does not mean that wxAUI is right while wxIFM does something wrong. It means wxSTC is wrong but wxAUI doesn't do anything that lets you notice it.
or try to resize the frame of your application you will notice heavy flickering.
Under any recent version of wxIFM (1.0.4 or later) a wxBufferedPanitDC is always used and hence wxIFM will never flicker. Other windows in your application may flicker, but as I have already said, thats not wxIFM's fault.

eranif
Moderator
Moderator
Posts: 607
Joined: Tue Nov 29, 2005 7:10 pm
Location: Israel

Post by eranif » Sun Mar 05, 2006 6:17 pm

SnakeChomp:

Please accept an applogoise from me, I did not meant to offend you - maybe I choose wrong words, english is not my native language.

But:

- wxIFM flickers (the caption of windows) when resizing the entire frame - while the SAME code managed by wxAUI it is not flickering at all ( I did not changed a single code line, only replaced the docking library)

- I dont see any different in draggin windows - wxAUI also provides you real time dragging (unlesss I misunderstood the term 'real time dragging'), and more, it also provides you transparent drag under windows.

- When dragging a window over wxSTC or any other wxScintilla derived class, the dragged window leaves trail of it, while it is not leaving any trail using wxAUI.

Eran
IDE: CodeLite + wxCrafter
OS: All
https://wxcrafter.codelite.org
https://codelite.org

Post Reply