Appearance of Native GTK+2 Widgets

wxPython Users
1

If there is a more appropriate list for this question, please point me to
it.

   There are a couple of widget behaviors I see on my application using
wxPython-2.8.0.1 that do not seem proper. Specifically, on a notebook page
with a tree control, root's label is very faint until I click on it, and
when I click on the arrow button of a combo box, the list grows up to the
top of the screen instead of dropping down.

   I looked on the GTK+ web site but found no screenshots or other displays
of native widget behavior except for the Glade page that showed the tree
control (with no lines, which is OK) but with a highlight across the width
of the widget's window for the highlighted item.

   Are these the normal appearances now? The list growing up instead of down
I can get used to. But, the faint tree root label until it -- or another
item -- is clicked is distracting.

   Has anyone else seen this?

Rich

···

--
Richard B. Shepard, Ph.D. | The Environmental Permitting
Applied Ecosystem Services, Inc. | Accelerator(TM)
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

2

Welcome to the wonderful world of visually erratic/behaviourally erratic GTK+2
widgits.

A source of constant annoyance to me, no-one much else on the list seems to
find it a problem, maybe its our collective installation!

I find really weird stuff, I've posted many of my observations, some
acknowledged, some not eg

Static control not centering (a bug - Robin says will get fixed, I've yet to
post a request).

The wx.choice when used on my machine once you click on a row the text goes
white and stays invisible.

The combo popup is a mile high (up my screen for some reason).

Lists - as the font size decreases the row sizes do not, hence huge waste of
screen real-estate or funny looking lists. Maybe that one's been fixed.

Sizers continue to amaze/annoy/confound me.

Rich text control seems not to load rich text files.

No I'm not really complaining, just observing, as I know Robin and the crew
work tirelesslessy for our benefit, but I wonder just how many develop on
windows and not linux so they don't encounter these problems.

Probably the plethora of widgets makes up for these deficiencies.

Happy to share my experiences with you/questions if you mail me directly if
you wish.

Regards

Richard Terry
General Practitioner
NSW Australia.

···

On Sunday 28 January 2007 09:07, Rich Shepard wrote:

   If there is a more appropriate list for this question, please point me
to it.

   There are a couple of widget behaviors I see on my application using
wxPython-2.8.0.1 that do not seem proper. Specifically, on a notebook page
with a tree control, root's label is very faint until I click on it, and
when I click on the arrow button of a combo box, the list grows up to the
top of the screen instead of dropping down.

   I looked on the GTK+ web site but found no screenshots or other displays
of native widget behavior except for the Glade page that showed the tree
control (with no lines, which is OK) but with a highlight across the width
of the widget's window for the highlighted item.

   Are these the normal appearances now? The list growing up instead of
down I can get used to. But, the faint tree root label until it -- or
another item -- is clicked is distracting.

   Has anyone else seen this?

Rich

3

By the way I observe that DatePickerCtrl has some empty space under it on gtk2.

···

2007/1/28, Richard Terry <rterry@internode.on.net>:

Welcome to the wonderful world of visually erratic/behaviourally erratic GTK+2
widgits.

A source of constant annoyance to me, no-one much else on the list seems to
find it a problem, maybe its our collective installation!

I find really weird stuff, I've posted many of my observations, some
acknowledged, some not eg

Static control not centering (a bug - Robin says will get fixed, I've yet to
post a request).

The wx.choice when used on my machine once you click on a row the text goes
white and stays invisible.

The combo popup is a mile high (up my screen for some reason).

Lists - as the font size decreases the row sizes do not, hence huge waste of
screen real-estate or funny looking lists. Maybe that one's been fixed.

Sizers continue to amaze/annoy/confound me.

Rich text control seems not to load rich text files.

No I'm not really complaining, just observing, as I know Robin and the crew
work tirelesslessy for our benefit, but I wonder just how many develop on
windows and not linux so they don't encounter these problems.

Probably the plethora of widgets makes up for these deficiencies.

Happy to share my experiences with you/questions if you mail me directly if
you wish.

Regards

Richard Terry
General Practitioner
NSW Australia.

On Sunday 28 January 2007 09:07, Rich Shepard wrote:
> If there is a more appropriate list for this question, please point me
> to it.
>
> There are a couple of widget behaviors I see on my application using
> wxPython-2.8.0.1 that do not seem proper. Specifically, on a notebook page
> with a tree control, root's label is very faint until I click on it, and
> when I click on the arrow button of a combo box, the list grows up to the
> top of the screen instead of dropping down.
>
> I looked on the GTK+ web site but found no screenshots or other displays
> of native widget behavior except for the Glade page that showed the tree
> control (with no lines, which is OK) but with a highlight across the width
> of the widget's window for the highlighted item.
>
> Are these the normal appearances now? The list growing up instead of
> down I can get used to. But, the faint tree root label until it -- or
> another item -- is clicked is distracting.
>
> Has anyone else seen this?
>
> Rich

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

4

Rich Shepard wrote:

  If there is a more appropriate list for this question, please point me to
it.

  There are a couple of widget behaviors I see on my application using
wxPython-2.8.0.1 that do not seem proper. Specifically, on a notebook page
with a tree control, root's label is very faint until I click on it, and

I don't think I've seen this, unless it's just the unfocused/focused selection colors. That is normal for gtk widgets and can probably be controlled by changing system color settings somewhere. If that doesn't appear to be what is going on then can you send a small screen shot and a sample app?

when I click on the arrow button of a combo box, the list grows up to the
top of the screen instead of dropping down.

This is normal. If there isn't room on the screen below to show all of the drop-down list then it will toss it up instead :wink:

  I looked on the GTK+ web site but found no screenshots or other displays
of native widget behavior except for the Glade page that showed the tree
control (with no lines, which is OK) but with a highlight across the width
of the widget's window for the highlighted item.

That is an option that can be selected with a style flag, wx.TR_FULL_ROW_HIGHLIGHT.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

5

I don't think I've seen this, unless it's just the unfocused/focused
selection colors. That is normal for gtk widgets and can probably be
controlled by changing system color settings somewhere. If that doesn't
appear to be what is going on then can you send a small screen shot and a
sample app?

Robin,

   If it was the unfocused/focused selection colors, I don't think it would
behave the way it now does. It looks 'unfocused' until I click on it or
another item, then it becomes 'focused' and stays that way.

   I'll send a screenshot and the code when I get the application running
again. I'm making major changes on a notebook page and it's currently in an
unstable state.

This is normal. If there isn't room on the screen below to show all of the drop-down list then it will toss it up instead :wink:

   Oh. With the same number of items in the list it used to go down. Now it
goes up. The application window is in the same position on the screen. Oh,
well.

  I looked on the GTK+ web site but found no screenshots or other
displays of native widget behavior except for the Glade page that showed
the tree control (with no lines, which is OK) but with a highlight across
the width of the widget's window for the highlighted item.

That is an option that can be selected with a style flag,
wx.TR_FULL_ROW_HIGHLIGHT.

   Thank you. That will probably make it easier to see where we are. It may
also resolve the first issue above. Need to wait for the app to pass syntax
check before testing these fixes.

Rich

···

On Mon, 29 Jan 2007, Robin Dunn wrote:

--
Richard B. Shepard, Ph.D. | The Environmental Permitting
Applied Ecosystem Services, Inc. | Accelerator(TM)
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

6

Robin,

   Two examples (as it first displays and after clicking on a sub-item) are
attached. I don't know that I could extract the code into a _small_ app
since it's pulling data from the database.

Rich

policy_page_before.png
policy_page_before.png340×191 3.69 KB

policy_page_after.png
policy_page_after.png349×203 3.99 KB

···

On Mon, 29 Jan 2007, Robin Dunn wrote:

I don't think I've seen this, unless it's just the unfocused/focused selection colors. That is normal for gtk widgets and can probably be controlled by changing system color settings somewhere. If that doesn't appear to be what is going on then can you send a small screen shot and a sample app?

--
Richard B. Shepard, Ph.D. | The Environmental Permitting
Applied Ecosystem Services, Inc. | Accelerator(TM)
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

7

Use .SetFocus() to focus on the widget.

- Josiah

···

Rich Shepard <rshepard@appl-ecosys.com> wrote:

On Mon, 29 Jan 2007, Robin Dunn wrote:

> I don't think I've seen this, unless it's just the unfocused/focused
> selection colors. That is normal for gtk widgets and can probably be
> controlled by changing system color settings somewhere. If that doesn't
> appear to be what is going on then can you send a small screen shot and a
> sample app?

Robin,

   Two examples (as it first displays and after clicking on a sub-item) are
attached. I don't know that I could extract the code into a _small_ app
since it's pulling data from the database.

Rich

--
Richard B. Shepard, Ph.D. | The Environmental Permitting
Applied Ecosystem Services, Inc. | Accelerator(TM)
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

8

Rich Shepard wrote:

···

On Mon, 29 Jan 2007, Robin Dunn wrote:

I don't think I've seen this, unless it's just the unfocused/focused
selection colors. That is normal for gtk widgets and can probably be
controlled by changing system color settings somewhere. If that doesn't
appear to be what is going on then can you send a small screen shot and a
sample app?

Robin,

  If it was the unfocused/focused selection colors, I don't think it would
behave the way it now does. It looks 'unfocused' until I click on it or
another item, then it becomes 'focused' and stays that way.

Even when the keyboard focus goes to another widget or another app? Do you catch focus events for the tree ctrl and not call Skip()?

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

9

Rich Shepard wrote:

I don't think I've seen this, unless it's just the unfocused/focused selection colors. That is normal for gtk widgets and can probably be controlled by changing system color settings somewhere. If that doesn't appear to be what is going on then can you send a small screen shot and a sample app?

Robin,

  Two examples (as it first displays and after clicking on a sub-item) are
attached. I don't know that I could extract the code into a _small_ app
since it's pulling data from the database.

It really isn't that hard: http://wiki.wxpython.org/index.cgi/MakingSampleApps

It does look like it is an unfocused highlight issue. Check your system settings for to see if you can set better colors. A quick peek at the code shows that it is using wxSYS_COLOUR_HIGHLIGHT for the highlight brush when it has the focus, and wxSYS_COLOUR_BTNSHADOW for when it doesn't have the focus, (kind of an odd choice, but it's been that way forever...) The foreground is always wxSYS_COLOUR_HIGHLIGHTTEXT, so you probably just need something for the shadow color that has better contrast with white foreground, or maybe changing your highlight text color to black would be best.

···

On Mon, 29 Jan 2007, Robin Dunn wrote:

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!