wxWidgets official release 2.6.3

[Michael]

Hello,

The wxWidgets official release 2.6.3 is about to see the daylight (in a week or so after Julian Smart). Now there is a RC1 available for download.

What is interesting (at least for me ) is that this new release will provide (within others):

Compilation fixes for (more strict) g++ 4.1

When the official release will come out, will C::B make use of it or wait sometime to know something more about the stability of this new release?

Best wishes,
Michael

[mandrav]

When the official release will come out, will C::B make use of it or wait sometime to know something more about the stability of this new release?

We 'll evaluate it first

[Michael]

Hello,

I have build C::B rev1998 with wxWidgets 2.6.3 RC1. The building was fine and it seems that C::B works fine. May be it is just an impression, but it seems that the dialogs in Settings open faster . Unfortunately there is a problem too . The toolbars main, compiler and debugger and not displayed correctly. The toolsbar are not collapsed and the debugger toolbar is not displayed. Anyway, the debugger is working.

You can see an image here below:



Best wishes,
Michael

[Game_Ender]

Don't trust the faster feel, usually its just a placebo effect.  One of the most recent example of this, is when Firefox released 1.5 after 1.5 RC2 and tons of people talked about how much faster 1.5 was compared to 1.5 RC2.  The 1.5 and 1.5 RC2 releases were the same, down to the byte.  Don't expect the much of speed improvement on the maintenance builds.

[Michael]

Don't expect the much of speed improvement on the maintenance builds.

No, I do not expect a lot of speed improvment. And probably as you said, the remarked improvement is just an illusion. I was just curious and wanted to try it. Anyway, until now, I am quite happy with this RC .

Michael

[Cybrid]

Hmmm, I have never coded using wxWidgets, but after reading a bit in wx website I find it very interesting to build Windows/Linux portable apps

[TDragon]

Once you've used it, you will never again build GUI apps without it. It's what MFC and Windows Forms should have been like from the beginning.

[Michael]

The toolbars main, compiler and debugger and not displayed correctly. The toolsbar are not collapsed and the debugger toolbar is not displayed.

I have also remarked that the TODO list plugin is not displayed, even if activated. This seems the same problem as discussed above.

Has someone else tried C::B with wxWidgets 2.6.3RC1?

Best wishes,
Michael

[Ceniza]

I gave it a try too, but faced the toolbars problem and even one with the Start here page, so I just gave up till things start being fixed.

[Michael]

I gave it a try too, but faced the toolbars problem and even one with the Start here page, so I just gave up till things start being fixed.

Takeshi Miya pointed out here that it could be wxAUI. I will give it a try ASAP.

Best wishes,
Michael

[MortenMacFly]

I may have made progress concerning this issue. If you compare the settings of two C::B compilations - one using wxWidgets 2.6.2 and the other using wxWidgets 2.6.3-RC2 then C::B saves the settings differently as following:
This is how it's done with wxWidgets 2.6.2:

Code Select Expand


<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocksConfig version="1">
<app>
<main_frame>
<layout>
<view1>
<DATA>
<str>layout1|name=MainToolbar;bestw=308;besth=23|name=CompilerToolbar;pos=319;bestw=342;besth=23|name=DebuggerToolbar;pos=672;bestw=215;besth=23|</str>
</DATA>
</view1>
</layout>
</main_frame>
</app>
</CodeBlocksConfig>

...and this how it's done with wxWidgets 2.6.3-RC2:

Code Select Expand


<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocksConfig version="1">
<app>
<main_frame>
<layout>
<view1>
<DATA>
<str>layout1|name=MainToolbar;bestw=792;besth=26|name=CompilerToolbar;pos=803;bestw=792;besth=26|name=DebuggerToolbar;pos=1606;bestw=792;besth=26</str>
</DATA>
</view1>
</layout>
</main_frame>
</app>
</CodeBlocksConfig>

As you can see the issue is that bestw is computed differently (wrong in the case of wxWidgets 2.6.3-RC2). This results in the toolbar being too wide. Now we have to dig into the source code of C::B first to see where this is calculated and whether there maybe a bug inside C::B...
I don't have the time to do this now, but I'll have a look into it tomorrow.
With regards, Morten.

[MortenMacFly]

I may have made progress concerning this issue. [...]

BTW: The bestw value is computed in manager.cpp which is part of wxAUI - So I agree with Takeshi Miya who in another topic (I forgot where) pointed to wxAUI, too.
With regards, Morten.
Edit: By now I realised that bestw is strangely always computed to the value 792. But why is beyond my knowledge (so far...)

[thomas]

By principle, I tend to always take the opposite of what Takeshi says for granted.

Look into main.cpp, lines 517 and 528. We are setting the main frame's width to 800 pixels and are using the clientsize (as it happens, 592 pixels ) to initialise the "best" size a couple of lines later. wxAUI is entirely innocent.

[MortenMacFly]

Look into main.cpp, lines 517 and 528. [...]

Alright, point taken.
By now I've also compiled the wxAUI samples which work fine with wxWidgets 2.6.3-RC(x), indeed.
You said the client size is 592 - so where are the 200 pixels difference to 792 are coming from? And where is the client size being actually set? Sorry, I didn't really get it. :oops:
With regards, Morten.

[thomas]

You said the client size is 592 - so where are the 200 pixels difference to 792 are coming from?

They come from me being tired...   They're 792 pixels, of course.