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