wxChoice looks different on 2.9 and 2.8

[Martin Papik]

wx: 2.9.4
OS: linux/ubuntu/xfce4

On wx-2.8, the dimensions of wxChoice are the same as wxTextCtrl, but on wx-2.9 wxChoice is bigger, looks wrong. Any idea why that might be? Is this a bug? Any way to influence this?

I'm attaching a screenshot and the source file (modified from the fullscreen bug, layout by wxformbuilder). I tried the packaged wx-2.8 and one compiled locally, just in case.

Martin

[Vadim Zeitlin]

On Sat, 10 Nov 2012 05:55:47 +0300 Martin Papik wrote:

MP> On wx-2.8, the dimensions of wxChoice are the same as wxTextCtrl, but on
MP> wx-2.9 wxChoice is bigger, looks wrong. Any idea why that might be? Is this
MP> a bug? Any way to influence this?

You should be able to set its size explicitly, of course, but it doesn't
really help with the question about the default size. I don't know if there
is anything wrong there though, AFAICS we get the natural control height
from GTK+ itself so it should be correct.

MP> I'm attaching a screenshot and the source file

As you can see on this screenshot, a different GTK control is actually
used in 2.8 and 2.9 (look at the drop down button). In 2.8 we used
GtkOptionMenu but it got deprecated long time ago (since GTK+ 2.4), so in
2.9 we use GtkComboBox.

Regards,
VZ

[Martin Papik]

Thank you Vadim for your reply, but I'm afraid I'm confused. Why is wx-2.9 drawing a different control? Can I make it draw the same one? Can I choose?

One more question, how do I set the size thought, I mean, how do I know the correct size, the font may differ from theme to theme.

So what is going to happen now? (no urgency, just curious)

Martin

[Vadim Zeitlin]

On Sat, 10 Nov 2012 20:05:08 +0300 Martin Papik wrote:

MP> Thank you Vadim for your reply, but I'm afraid I'm confused. Why is wx-2.9
MP> drawing a different control? Can I make it draw the same one? Can I choose?

Because, as I said, the old one was deprecated in GTK+, so we switched to
using the new one. And no, you can't choose.

MP> One more question, how do I set the size thought, I mean, how do I know the
MP> correct size, the font may differ from theme to theme.

You could use the size of an existing text control if you really want them
to be the same.

MP> So what is going to happen now? (no urgency, just curious)

Nothing, unless someone tries creating a GtkComboBox in pure GTK+ code and
shows that it really has a different size there from the size in wxGTK. I
don't believe this would be the case though, i.e. I think everything does
work as expected.

Regards,
VZ

[Martin Papik]

I disagree, and I'm sorry if I'm being difficult, but I don't think it's working as expected. I expect that generic controls have the same height. I understand what you mean though, you use a GTK widget that's meant for this purpose and it's functioning correctly. But please try to understand my point of view. I put a wxChoice and a wxComboBox next to each other, I don't want them to look like David and Goliath. The goal of a user interface is to function yes, but also to look comfortable, familiar, unobtrusive.

Are my expectations unreasonable?

I can understand that this might not be the highest priority, but I am convinced this is a bug.

Martin

[ardi]

On Monday, November 12, 2012 3:13:51 AM UTC+1, Martin Papik wrote:

[...] I put a wxChoice and a wxComboBox next to each other, I don't want them to look like David and Goliath. The goal of a user interface is to function yes, but also to look comfortable, familiar, unobtrusive.

Are my expectations unreasonable?

I'm not developing in GTK yet, but, looking at your screenshot, I see the 2.9.4 approach has a better style, more integrated with the native UI, because both controls use the same arrows style on 2.9.4, while they use a different style on 2.8.x. The only problem is the height of the combo and the choice. If you can manage to get the same height to the combo and the choice, it will look perfectly on 2.9.4. On the other hand, on 2.8.x it looks like you're mixing non-standard widgets from different vendors, because of the different arrows style.

HTH,

ardi

[Martin Papik]

Dear Ardi

I understand what you're saying. The 2.9 approach (using standard UI widgets) is the correct one, I'm only not liking the result. Have a look at the screenshot I attached where the widgets are in the same line (quite usual design). I think you'll agree that the 2.9 looks wrong. Maybe it can be fixed easily, some setting, border, size, I don't know. Maybe it's not so easy. But I don't think it's right, IMHO it's a bug. At the very least I would hope for some standard means of getting them to be the same size.

Martin

HTH,

ardi

--
To unsubscribe, send email to wx-dev+un...@googlegroups.com
or visit http://groups.google.com/group/wx-dev

[Vadim Zeitlin]

On Mon, 12 Nov 2012 05:13:49 +0300 Martin Papik wrote:

MP> I disagree, and I'm sorry if I'm being difficult, but I don't think it's
MP> working as expected. I expect that generic controls have the same height.

There is no guarantee of this being the case under all platforms.

MP> understand what you mean though, you use a GTK widget that's meant for this
MP> purpose and it's functioning correctly. But please try to understand my
MP> point of view. I put a wxChoice and a wxComboBox next to each other, I
MP> don't want them to look like David and Goliath. The goal of a user
MP> interface is to function yes, but also to look comfortable, familiar,
MP> unobtrusive.

FWIW I agree but it doesn't mean anything. We do what GTK+ does. Again, if
the choices in wxGTK don't behave the same as in GTK+ itself, then we have
a problem which we need to fix. But by default we should do the same thing
as GTK+ does and if it (or, rather, some of the themes, I'd guess) give
different heights to these controls there is nothing to do about it.

Of course, if you put a combobox and a choice next to each other you
can still perfectly well add them in a horizontal box sizer using
wxSizerFlags().Expand() to force them to have the same height.

Regards,
VZ

[Manolo]

Hi
Looking at your screen shot I see different arrows for wxChoice and
wxComboBox. That tells me you use Gtk+2 for 2.9.4. With Gtk+3 you'd
get the same look for both.

In my Ubuntu OS, Gtk+2 gives 31 pixels to wxComboBox and 29 to
wxComboBox. Gtk+3 gives 33 and 29.
As Vadim told, the height is decided by the OS (this is a priority
in wx, the native look), although you can force the size you wish.

The bigger differences you have... there's something strange there.
I made my test with current SVN, not with 2.9.4. Could you test your
app with the last SVN?

Regards,
Manolo

[Manolo]

> In my Ubuntu OS, Gtk+2 gives 31 pixels to wxComboBox and 29 to
> wxComboBox. Gtk+3 gives 33 and 29.

Sorry, it's wxChoice and wxComboBox (not two wxComboBox)

Manolo

[Martin Papik]

On Mon, Nov 12, 2012 at 2:36 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:

On Mon, 12 Nov 2012 05:13:49 +0300 Martin Papik wrote:

MP> I disagree, and I'm sorry if I'm being difficult, but I don't think it's
MP> working as expected. I expect that generic controls have the same height.

 There is no guarantee of this being the case under all platforms.

MP> understand what you mean though, you use a GTK widget that's meant for this
MP> purpose and it's functioning correctly. But please try to understand my
MP> point of view. I put a wxChoice and a wxComboBox next to each other, I
MP> don't want them to look like David and Goliath. The goal of a user
MP> interface is to function yes, but also to look comfortable, familiar,
MP> unobtrusive.

 FWIW I agree but it doesn't mean anything. We do what GTK+ does. Again, if
the choices in wxGTK don't behave the same as in GTK+ itself, then we have
a problem which we need to fix. But by default we should do the same thing
as GTK+ does and if it (or, rather, some of the themes, I'd guess) give
different heights to these controls there is nothing to do about it.

I tried different themes, but it didn't appear to work. Until after hours of trying to tweak the theme config file I accidentally realized that although some aspects of the theme were applied immediately, others were not. This gave me the faulty impression that the theme is being applied correctly, while preventing me from seeing it's not getting me anywhere. I figured out that if I restart my application the theme is applied and all is well. My bad, sorry. I checked the sample app, which didn't compile (see below). The sample app refreshed correctly. Ergo, I made a mistake somehow, which prevents the new theme from being applied correctly (the colors change, arrow styles change, but the height doesn't).

With the Xfce-dawn theme it has the ugly results from my screenshots. With Clearlooks-compat it works fine.

I sincerely apologize for wasting time.
 

 Of course, if you put a combobox and a choice next to each other you
can still perfectly well add them in a horizontal box sizer using
wxSizerFlags().Expand() to force them to have the same height.

 
I tried wxEXPAND and it gave me an OK look even on the xfce theme. Thanks.
 

 Regards,
VZ

Compilation error of the dialog sample. I just removed the missing widget code so it compiles anyway. A missing ./configure option perhaps? I'm using '--enable-utf8' '--enable-ipv6' '--enable-debug_gdb' '--enable-debug_info' '--enable-debug' '--disable-shared' '--prefix=/my/wx-2.9.4'

martin@lennie:~/W/wxw/example/x/samples/dialogs$ PATH=/my/wx-2.9.4/bin/:$PATH make -f makefile.unx
`wx-config --cxx` -c -o dialogs_dialogs.o -I. `wx-config --cxxflags --unicode=yes --static=yes --toolkit=gtk2 --version=2.9`   -MTdialogs_dialogs.o -MF`echo dialogs_dialogs.o | sed -e 's,\.o$,.d,'` -MD -MP dialogs.cpp
dialogs.cpp:112:37: fatal error: wx/generic/filedlgg.h: No such file or directory
compilation terminated.
make: *** [dialogs_dialogs.o] Error 1
martin@lennie:~/W/wxw/example/x/samples/dialogs$ find /home/martin/W/wxw/ -name filedlgg.h
/home/martin/W/wxw/wxWidgets-2.8.12/include/wx/generic/filedlgg.h
/home/martin/W/wxw/wxWidgets/include/wx/generic/filedlgg.h
/home/martin/W/wxw/wxWidgets-2.9.4-mod/include/wx/generic/filedlgg.h
/home/martin/W/wxw/wxWidgets-2.9.3/include/wx/generic/filedlgg.h
/home/martin/W/wxw/wxWidgets-2.9.4/include/wx/generic/filedlgg.h
martin@lennie:~/W/wxw/example/x/samples/dialogs$ find /my/ -name filedlgg.h
/my/wx-2.8.12/include/wx-2.8/wx/generic/filedlgg.h
martin@lennie:~/W/wxw/example/x/samples/dialogs$

[Martin Papik]

Addendum, the attached sample (fullscreen-bug.cpp) doesn't refresh correctly either. Meaning when the theme is applied, but the wxChoice doesn't change its size. Is there anything wrong with the code? The code is very simple, mostly pasted from wxFormBuilder.

I'm attaching the screenshots, one is when the ./test-2.9 is stared with xfce-dawn, the second after the theme is changed (see the wxChoice size). The third is when the app is started up with clearlooks classic theme, also please notice that the button outline didn't redraw after resize, but the height of wxChoice is correct.

Am I missing something? Is this a bug? Is this because of the theme?

Martin

[Vadim Zeitlin]

On Tue, 13 Nov 2012 10:00:37 +0300 Martin Papik wrote:

MP> Compilation error of the dialog sample. I just removed the missing widget
MP> code so it compiles anyway. A missing ./configure option perhaps? I'm using
MP> '--enable-utf8' '--enable-ipv6' '--enable-debug_gdb' '--enable-debug_info'
MP> '--enable-debug' '--disable-shared' '--prefix=/my/wx-2.9.4'
MP>
MP> martin@lennie:~/W/wxw/example/x/samples/dialogs$
MP> PATH=/my/wx-2.9.4/bin/:$PATH make -f makefile.unx

You're not using the right makefile, in spite of its name this one should
be used with gcc under Windows. Use the one in build directory (you do
build in a separate directly, don't you?), i.e. just Makefile.

Regards,
VZ

[Vadim Zeitlin]

On Tue, 13 Nov 2012 10:24:14 +0300 Martin Papik wrote:

MP> Addendum, the attached sample (fullscreen-bug.cpp) doesn't refresh
MP> correctly either. Meaning when the theme is applied, but the wxChoice
MP> doesn't change its size.

This is not surprising, I don't think there is any code in wx to relayout
everything when the theme changes. We should catch style-set at wxTLW level
and perform the relayout, I guess...

Regards,
VZ

[Martin Papik]

I do build in a separate build directory, but not the samples, not in this case. I've copied the samples to a separate directory. Sorry for the confusion, I was thinking of the samples as separate little self-contained applications that just need compiling. Somehow that made more sense to me. My bad. .. I tried compiling it in one of my build directories, it works fine. Sorry and thanks. :-)
 

 Regards,
VZ

[Vadim Zeitlin]

On Tue, 13 Nov 2012 18:54:21 +0300 Martin Papik wrote:

MP> I do build in a separate build directory, but not the samples,

Just to be clear: if you run configure in a separate build directory, it
generates you makefiles for the samples there too, there is no need to copy
anything.

Regards,
VZ

[Martin Papik]

I know Vadim, I understand the situation. I was just thinking the samples were self-contained examples, not part of the build, compilable separately without configure, and most of them worked with the *.unx makefile. Thank you for your clarification.

Martin