Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Patches to compile and link C::B against wxWidgets 2.8.0
killerbot:
first of all, let's see what wx 2.8 brings . Will it fix some of the bugs we are suffering from the 2.6, if yes, then it light be interesting to use 2.8. If not, then might be best to wait.
David Perfors:
I think it is possible to get wx2.8 support in 1.0 we are even still waiting for RC3....
kai:
on linux wxwidgets2.8 has a few bug fixes and i already use it successfully with code::blocks (except for a bug concerning debugging).
the most important fix: the drag and drop xserver freeze bug has been fixed.
selections in tree or list views don't look ugly on ubuntu anymore (before they had a saturated ugly orange colour)
wxaui also looks better - the mouse cursor changes now when it's above the sash.
stahta01:
--- Quote from: afb on November 23, 2006, 10:14:10 pm ---
--- Quote from: stahta01 on November 23, 2006, 09:45:16 pm ---I was thinking that C::B 1.5 could support both wxWidgets 2.6 and 2.8 with WXWIN_COMPATIBILITY_2_4 turned off for both.
--- End quote ---
This might be a problem for 2.6, which has it "on" by default. (can't we work around it ?)
--- End quote ---
We can just turn it on for just 2.6; 2.8 has it off by default. I think it will require more work if we don't turn it off for 2.6 but the amount of work won't be that much. Just some #ifdef blocks in codeblocks.
From a user point of view having it on for 2.6 and off for 2.8 will be the simplest way. I will work on a patch to fix code::blocks so it works both with WXWIN_COMPATIBILITY_2_4 on or off.
From a coder point of view having WXWIN_COMPATIBILITY_2_4 set the same, either 1 or 0, would be the simplest way.
Note: I tried just defining WXWIN_COMPATIBILITY_2_4 as 0 and wxHIDE_READONLY as 0,but C::B crashed too much.
Tim S
sethjackson:
Why do we need WXWIN_COMPATIBILITY_2_4? C::B won't even compile with that version of wx........
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version