ANN: wxWidgets 2.9.0 preview release
Julian Smart
first release in the 2.9 development series.
wxWidgets 2.9.0 gives a flavour of what will be provided in the stable
wxWidgets 3.0 version next year, and we are interested in your feedback.
Enhancements in 2.9 include:
- removal of the distinction between ANSI and Unicode builds, so use of
the wxChar type and wxT macro is no longer necessary;
- a reworked Mac OS X architecture, supporting both 32-bit Carbon and
32-bit/64-bit Cocoa variants (wxOSX/Cocoa at alpha stage);
- addition of property grid classes;
- an enhanced data view control, with combined tree and list control
behaviour;
- improved non-GUI build mode supporting event loops, timers and sockets;
- events can now be connected to any functor, not necessarily a method
of wxEvtHandler-derived class;
- support for persistent objects;
- totally revised Doxygen-based documentation.
Please note that for production software, we recommend you use the
latest in the wxWidgets 2.8 series.
To get wxWidgets 2.8 or 2.9, please go to the download page at
http://www.wxwidgets.org/downloads/. The 2.9.0 release is available as a
single source archive for all platforms, and an optional Windows setup
program.
--
Julian Smart, Anthemion Software Ltd.
28/5 Gillespie Crescent, Edinburgh, Midlothian, EH10 4HU
www.anthemion.co.uk | +44 (0)131 229 5306
Tools for writers: www.writerscafe.co.uk
wxWidgets RAD: www.dialogblocks.com
Blog: www.juliansmart.com
Richard
In article <4AA66E4B...@anthemion.co.uk>,
Julian Smart <jul...@anthemion.co.uk> writes:
> - a reworked Mac OS X architecture, supporting both 32-bit Carbon and
> 32-bit/64-bit Cocoa variants (wxOSX/Cocoa at alpha stage);
Can you elaborate a little bit on what went into the rework?
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
Stefan Csomor
>> - a reworked Mac OS X architecture, supporting both 32-bit Carbon and
>> 32-bit/64-bit Cocoa variants (wxOSX/Cocoa at alpha stage);
>
> Can you elaborate a little bit on what went into the rework?
http://wiki.wxwidgets.org/Development:_wxMac
Best,
Stefan
David Connet
currently working on the trunk, last synced Sun morning)
I have a fairly complex doc/view structure (a frame, with a tabview,
within each of the (4) tabs there are either 1 view or a splitter
with 2 views - think something like windows explorer with the 2
panes, but I have 4 tabs of them)
Anyway, when the program first starts up, it opens the last document
and populates the various views. What I discovered is that the very
first time the program starts, wxTreeCtrl::DoGetBestSize() returns
the size the tree would take with all its items (which I've expanded
when loading the data). This is considerably more space than the
client area. And resizing the window does NOT fix it. Now, the odd
thing - when I open a new document (and all the
views/panels/sizers/etc) are destroyed and recreated, the tree now
behaves and correctly sizes itself into the client area.
I haven't gotten around to tracking down what the issue is exactly -
I did find a workaround - override DoGetBestSize and just return a
small number. (the tree's sizer will do the right thing since it's
set to wxEXPAND and proportion of 1)
This did not happen in 2.8, and does not happen with 2.9 on a Mac -
only Windows. I'll try to tweak a sample to see if I can reproduce it
in a simple form - just wanted to give a heads up in case this sounds
familiar...
Dave Connet
Vadim Zeitlin
DC> Anyway, when the program first starts up, it opens the last document
DC> and populates the various views. What I discovered is that the very
DC> first time the program starts, wxTreeCtrl::DoGetBestSize() returns
DC> the size the tree would take with all its items (which I've expanded
DC> when loading the data). This is considerably more space than the
DC> client area. And resizing the window does NOT fix it. Now, the odd
DC> thing - when I open a new document (and all the
DC> views/panels/sizers/etc) are destroyed and recreated, the tree now
DC> behaves and correctly sizes itself into the client area.
It seems like something called wxTreeCtrl::SetQuickBestSize() in the
meanwhile. OTOH looking at the code it's already true by default now so I
don't know why would it change anything.
DC> This did not happen in 2.8, and does not happen with 2.9 on a Mac -
DC> only Windows. I'll try to tweak a sample to see if I can reproduce it
DC> in a simple form - just wanted to give a heads up in case this sounds
DC> familiar...
Mac version uses generic wxTreeCtrl while Windows one uses the native
implementation so it's not totally unexpected that they behave differently.
But I'm at a loss to explain why do you see what you do under Windows,
sorry.
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
David Connet
> DC> Anyway, when the program first starts up, it opens the last document
> DC> and populates the various views. What I discovered is that the very
> DC> first time the program starts, wxTreeCtrl::DoGetBestSize() returns
> DC> the size the tree would take with all its items (which I've expanded
> DC> when loading the data). This is considerably more space than the
> DC> client area. And resizing the window does NOT fix it. Now, the odd
> DC> thing - when I open a new document (and all the
> DC> views/panels/sizers/etc) are destroyed and recreated, the tree now
> DC> behaves and correctly sizes itself into the client area.
>
> It seems like something called wxTreeCtrl::SetQuickBestSize() in the
> meanwhile. OTOH looking at the code it's already true by default now so I
> don't know why would it change anything.
I'll stick a break point on there tonight and see what happens...
> DC> This did not happen in 2.8, and does not happen with 2.9 on a Mac -
> DC> only Windows. I'll try to tweak a sample to see if I can reproduce it
> DC> in a simple form - just wanted to give a heads up in case this sounds
> DC> familiar...
>
> Mac version uses generic wxTreeCtrl while Windows one uses the native
> implementation so it's not totally unexpected that they behave differently.
> But I'm at a loss to explain why do you see what you do under Windows,
> sorry.
Thanks - I'll see what I can dig up - at least I have a decent workaround...
Dave
David Connet
>On Sun, 20 Sep 2009 20:20:18 -0700 David Connet
><dc...@agilityrecordbook.com> wrote:
>
>DC> Anyway, when the program first starts up, it opens the last document
>DC> and populates the various views. What I discovered is that the very
>DC> first time the program starts, wxTreeCtrl::DoGetBestSize() returns
>DC> the size the tree would take with all its items (which I've expanded
>DC> when loading the data). This is considerably more space than the
>DC> client area. And resizing the window does NOT fix it. Now, the odd
>DC> thing - when I open a new document (and all the
>DC> views/panels/sizers/etc) are destroyed and recreated, the tree now
>DC> behaves and correctly sizes itself into the client area.
>
> It seems like something called wxTreeCtrl::SetQuickBestSize() in the
>meanwhile. OTOH looking at the code it's already true by default now so I
>don't know why would it change anything.
I put a break point here - everything's cool. A little more digging
reveals the first time it calls wxTreeCtrl::GetBoundingRect, Windows
returns the offending number. The width/height are good - what's odd
is the y-value. I have a hidden root item, so the 1st call using
GetRootItem fails (expected), then it checks the last child of the
root - this item's bounding rect is returned as x=41, y=3312, cx=73,
cy=17. Which is actually correct - it's just out of window bounds.
And what I first mentioned about subsequent file opens was actually
wrong - it just happened those other ones I opened had short trees,
so the issue was hidden. Let me rephrase that, partially wrong (I'm
testing as I type). The tree is still messed up on what it thinks its
height is, but that doesn't seem to ripple to the other views as it
does in the initial doc open (the tree is one of the first controls created).
So it seems it's something related to sizers - the tree always thinks
it's too big (if it was initially created with a long expanded list).
Since I know how to work around this (override DoGetBestSize), I'm ok
for now... If there's anything you'd like me to poke around at, let
me know where to poke and I'll see what I can come up with!
>DC> This did not happen in 2.8, and does not happen with 2.9 on a Mac -
>DC> only Windows. I'll try to tweak a sample to see if I can reproduce it
>DC> in a simple form - just wanted to give a heads up in case this sounds
>DC> familiar...
>
> Mac version uses generic wxTreeCtrl while Windows one uses the native
>implementation so it's not totally unexpected that they behave differently.
>But I'm at a loss to explain why do you see what you do under Windows,
>sorry.
Since it's coming from Windows (above), this actually makes total sense...
Dave
Vadim Zeitlin
DC> I put a break point here - everything's cool. A little more digging
DC> reveals the first time it calls wxTreeCtrl::GetBoundingRect, Windows
DC> returns the offending number. The width/height are good - what's odd
DC> is the y-value. I have a hidden root item, so the 1st call using
DC> GetRootItem fails (expected), then it checks the last child of the
DC> root - this item's bounding rect is returned as x=41, y=3312, cx=73,
DC> cy=17. Which is actually correct - it's just out of window bounds.
Ok, I see, thanks. We definitely should consider putting some upper bound
on the window height here. wxSizer already limits the size of TLWs to the
(client) size of the display so we could use this as an absolute upper
bound but I am not sure if this is actually going to fix your problem as
there still won't be enough space for the tree if there any other windows
above/below it. Could you please test what happens if you return your
screen vertical size (e.g. 1200 or whatever) from your overridden
DoGetBestSize()?
Of course, another problem is that sizers should still work correctly even
if a window asks for a too huge size. And I don't really know why they
don't. I'm afraid I'd really need some simple way to reproduce the bug to
find this out though.
Regards,
David Connet
> Of course, another problem is that sizers should still
> work correctly even
> if a window asks for a too huge size. And I don't really
> know why they
> don't. I'm afraid I'd really need some simple way to
> reproduce the bug to
> find this out though.
I'll see what I can do here... (While my project is open source and on sourceforge, it's not exactly small or simple! http://sourceforge.net/projects/agilitybook/ if you're curious.) Of course the sample worked fine after I changed it to start with the items expanded... Hopefully I can come up with something by the weekend...
Dave
Vadim Zeitlin
DC> --- On Tue, 9/22/09, Vadim Zeitlin <va...@wxwidgets.org> wrote:
DC> > Of course, another problem is that sizers should still
DC> > work correctly even if a window asks for a too huge size. And I don't
DC> > really know why they don't. I'm afraid I'd really need some simple
DC> > way to reproduce the bug to find this out though.
DC>
DC> I'll see what I can do here...
Thanks in advance and please take your time, I'm very unlikely to be able
to look at it before the week-end anyhow.
[OT from now on]
DC> (While my project is open source and on sourceforge, it's not exactly
DC> small or simple! http://sourceforge.net/projects/agilitybook/ if you're
DC> curious.)
I always am, thanks for the link. I don't know nearly enough about dog
training to appreciate your program to its just value I'm afraid though.
Just one _completely_ unrelated advice: it should be "la version française"
instead of "le version français" on http://www.agilityrecordbook.com/.