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.
frm wrote:However, reading some previous posts I do not understand a thing: will wxIFM actively maintained or SnakeChomp wants to abandon it?
Actively maintain? Yes. Actively develop? No. I have moved on to developing new projects but I will not be abandoning the many months of work I have put into wxIFM. All of the issues that have been raised since the 1.0 release have been corrected and a patch released within 24-48 hours.
Speaking of patches...
A 1.0.3 patch might be making its way into this thread soon. That nasty little habit that wxIFM has of creating _way_ too many containers, each with its own gray bar, and not getting rid of them when they aren't needed has been corrected. I will wait to see if anything else comes up before releasing this patch. This is more of a cosmetic fix as compared to a serious crash bug that needed immediate fixing, so I will wait to see if there is more I can add to it before releasing it.
Ryan Norton wrote:Then how exactly is this different from wxFL?
Completely different because NOBODY maintains wxFL? There was a call for a wxFL maintainer on the wx-dev list a long time ago which was when I first mentioned (demanded ) that wxIFM replace wxFL outright. I offered to submit wxIFM to wxWidgets source under the condition I am given cvs access to maintain it. That is not changing.
When wxIFM is in wxWidgets source, anybody using wxWidgets will be exposed to wxIFM, which is far more than know about a wxCode site. The chances of someone deciding to do some work on it and submitting a patch are far greater here than anywhere else.
This patch corrects the bad habit that wxIFM has of creating way too many containers (and vertical gray bars) and then not getting rid of the containers that are no longer needed. The result of this correction is that far less extraneous containers are created. Just extract this over your wxIFM directory.
Pssst
A little birdy tells me that wxIFM might be distributed with another popular item on this forum that happens to start with a "w" and end with "p" or two...
I'd like to announce the release of wxIFM 1.0.4. Thanks to a contribution by a wxIFM user, wxIFM got a whole lot sexier this release. See for yourself.
Some Details
<ul><li>wxIFM looks a whole lot sexier now thanks to rounded tabs and nicer color choices for backgrounds and borders</li><li>Painting has been optimized greatly to improve performance</li><li>Two captions aren't displayed anymore if there is only one panel in a floating window! You can stop moaning about that now. Note: This only works on windows because the wxGTK implementation doesn't let you remove the caption from a frame.</li><li>wxInterfaceManager::IsChildVisible can be used to determine wether or not a child is visible within the interface. This is intended for use with updating menu checkmarks.</li></ul>
They are supported per say, but not in a matter which makes any sense at all so I have not bothered adding them to the sample. If I ever support draggable toolbars, it will be MSOffice style.
wxIFM should immediately be integrated into the wxWidgets code-base and picked up and further developed by the developers. I think the main thing wxWidgets is missing is a robust docking-panel system allowing for customizable user interfaces.
RealityMage wrote:wxIFM should immediately be integrated into the wxWidgets code-base and picked up and further developed by the developers. I think the main thing wxWidgets is missing is a robust docking-panel system allowing for customizable user interfaces.
I will use your post as a reference after wxWidgets branches and wxIFM integration is brought up on the mailing lists for discussion. I won't rest until wxIFM is within the wxWidgets source anyhow, so you need not worry.
Looks great now, but there are still some paint bugs:
1. undock "build window"
2. dock it again under Console window (not as its tab). Looks like Files window paints partially over Console window.
Another one, very similar to the first one:
1. undock "build window"
2. dock it again as the very right window
3. resize window horizontally to make Console and Classes overlap and you can see it again.
Tested with 1.0.4+MSW
Sorry if this is not the right place to post bugs or the bugs are already reported.
after a little experimenting i found out, that you can get easily windows with no content or tabs:
1.just drag the right console window as a tab to the left build window
2.undock the just created window
3.click at the "build"-tab and make it a child of the inner window
4.now drag the inner window away
5.you will see a clear win with nothing
There will always be paint bugs if you purposfully resize the main window below the minimum acceptible amount. Unfortunately, this minimum amount is very hard to calculate, at least I haven't figured out how to calculate it so far. The solution is to simply not resize the window that small, or to not specify minimum sizes for windows managed by wxIFM. The sample defines some minimum sizes so that I can make sure minimum sizes are still respected.
Chr:
Interesting issue. You can simply close the "blank" window that was created and no real harm is done. I may look into why it does this later.
Last edited by SnakeChomp on Mon Aug 29, 2005 10:23 pm, edited 1 time in total.