wxRendererGTK::DrawSplitterBorder()
John Dallaway
jld at ecoscentric.com
Tue Feb 12 02:39:13 PST 2008
Hi Vadim
Vadim Zeitlin wrote:
> On Mon, 11 Feb 2008 08:23:13 +0000 John Dallaway wrote:
>
> JD> > Again, it's still not clear at all to me what the problem really is. Does
> JD> > wxSplitterWindow appear differently from native GTK+ splitters? If so, in
> JD> > which theme?
> JD>
> JD> The problem is that on platforms such as GTK there is no border drawn at
> JD> all
>
> Sorry if I'm missing something obvious but it's still not clear to me why
> exactly is this a problem. I can only repeat my question above: does it
> look differently from the native controls? I don't see any difference here.
> Do you use some specific theme where the differences appear?
There are many situations when a wxSplitterWindow with no border of any
sort looks wrong under GTK. If you run the "splitter" sample with wxGTK,
I think you would agree that the wxSplitterWindow would look more native
with a border. With the current code, there is no way to force the
wxSplitterWindow to draw a border of any sort under wxGTK.
> JD> Per bug 1888733, I think the masking of style bits in
> JD> wxSplitterWindow::Create() should be eliminated so that the caller can
> JD> specify a border style such as wxSUNKEN_WINDOW for a wxSplitterWindow
> JD> when wxSP_3DBORDER is not appropriate or when
> JD> wxRenderer::DrawSplitterBorder() is empty. Do you agree?
>
> No. If I understand you correctly, you'd need to use #ifdef __WXGTK__ in
> the program and specify different styles for it and the other ports
> (notably wxMSW). This is clearly not the best way to fix the problem. But
> unfortunately I can't propose a better one without understanding first what
> the problem *is*.
Here's an example of why what you propose above does not work. For
wxGTK, the wxSUNKEN_BORDER style might look reasonable for a
wxSplitterWindow. So I might attempt to create the wxSplitterWindow as
follows:
#if defined(__WXGTK__)
x = new wxSplitterWindow(..., ..., ..., ..., wxSUNKEN_BORDER);
#elif defined(__WXMSW)
x = new wxSplitterWindow(..., ..., ..., ..., wxSP_3DBORDER);
#else
...
#endif
For the wxGTK case the following occurs:
* The wxSplitterWindow constructor calls wxSplitterWindow::Create()
with the wxSUNKEN_BORDER style as specified.
* wxSplitterWindow::Create() unconditionally removes all border style
bits and calls wxWindow::Create() with the wxBORDER_NONE style.
* The splitter window is therefore drawn without a border.
This is why I believe the unconditional removal of all border style bits
by wxSplitterWindow::Create() is incorrect. Do you agree?
John Dallaway
More information about the wx-dev
mailing list