Page 4 of 7
Posted: Wed Jul 27, 2005 11:43 pm
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.
Posted: Thu Jul 28, 2005 1:00 am
SnakeChomp wrote:Actively maintain? Yes. Actively develop? No.
Then how exactly is this different from wxFL? The only difference now is that the wx devs will be less familiar with the code...
You really should consider putting it on wxCode, maybe then someone will actively develop it
Posted: Thu Jul 28, 2005 5:03 pm
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.
wxIFM 1.0.3 patch
Posted: Tue Aug 02, 2005 10:12 pm
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.
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...
wxIFM - 1.0.4 released
Posted: Sat Aug 27, 2005 8:47 am
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.
This is a full distribution release, not a patch. You don't need to have any previous versions of wxIFM to use this release.
Grab it here: www.snakesoft.net/wxifm/wxIFM-1.0.4.zip
<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>
Posted: Sat Aug 27, 2005 1:14 pm
Very eye-candy! Just a question: are draggable toolbars supported? If so, they many be added to the sample.
Posted: Sun Aug 28, 2005 1:15 am
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.
Posted: Sun Aug 28, 2005 11:38 pm
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.
Posted: Mon Aug 29, 2005 12:33 am
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.
Posted: Mon Aug 29, 2005 1:10 pm
if wxifm is in the codebase, you will stop supporting it??
(-toolbar support would be nice-
Posted: Mon Aug 29, 2005 5:20 pm
wow, Snake, that looks way too sexy
Posted: Mon Aug 29, 2005 5:45 pm
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.
Thank you for your great work, Snake!
Posted: Mon Aug 29, 2005 5:58 pm
there are alot of "overdraws" if you only take the demo and resize the window as small as possible!
Posted: Mon Aug 29, 2005 6:10 pm
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
Posted: Mon Aug 29, 2005 10:15 pm
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.
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.