[evolution-patches] Seeking further opinions about the combo size problem
- From: Kidd Wang <kidd wang sun com>
- To: JP Rosevear <jpr ximian com>, Rodrigo Moya <rodrigo ximian com>, evolution-patches ximian com
- Subject: [evolution-patches] Seeking further opinions about the combo size problem
- Date: Mon, 08 Mar 2004 13:09:53 +0800
Rodrigo Moya wrote:
JP, I need your further opinions on this issue because I think it's up
to you to make the final decision, isn't it?
On Tue, 2004-03-02 at 15:18 +0800, Kidd Wang wrote:
JP Rosevear wrote:
Before I sent you the patch yesterday, I did have tried your second
option to call
some pango functions, such as pango_layout_get_pixel_size, to calculate
size of the box, but unfortunely it seems that these functions can only
On Mon, 2004-03-01 at 02:12, Kidd Wang wrote:
This patch is aimed for trunk. We have found a bug in calendar which can
be reproduced as follows:
1. Invoke evolution on Japanese locales.
2. Choose [File] -> [New] -> [Appointment].
3. Select [Appointment] tab.
4. Choose an arrow button in "Start time" or "End time".
Then Japanese "01:00 AM" is longer than the text box, so the string is
Enclosed is the snapshot and a patch to fix that. Would you like to
spend a little time to review it?
I suspect hardcoding a larger value is not the way to fix this. IIRC
this hard code is there because ages ago gtk did not properly size
allocate the combo box based on the child size. The hard coded size may
not even be necessary now, the other option would be to calculate the
size of the time strings and then set the size request to the maximal
size plus some padding.
an approximate value which is almost always much less than the text appears.
Enclosed is a patch conforming to your first option and snapshots are
also given below.
Does it look OK?
this will make the combo get the same size on every locale, so there
might cases, in some resolutions and locales where it is smaller than
the text. Do we want that? If we do, the patch looks ok.
] [Thread Prev