← Back to team overview

kicad-developers team mailing list archive

Re: floating point issue ( from Strange eeschema behavior at zoom 0.7) in wxWidgets 2.9.1


Le 11/04/2011 20:51, Wayne Stambaugh a écrit :
On 4/11/2011 2:31 PM, jean-pierre charras wrote:
Le 11/04/2011 17:31, Wayne Stambaugh a écrit :
On 4/11/2011 11:24 AM, Dick Hollenbeck wrote:
On 04/06/2011 11:41 AM, Dick Hollenbeck wrote:
On 04/06/2011 11:38 AM, Dick Hollenbeck wrote:
So did we go back and fix the zoom steps?  I remember one step was commented
out:  0.7.

It needs to be enabled now, and absolutely so on Linux.

I am afraid at least one mail about this topic was lost!

About zoom changes, *only Eeschema was modified*, and only under Windows.
Changes are conditionally compiled, and are *only for windows and wxMSW version
<  2.9*
- zoom page (BestZoom ) always>= 1 (in fact some zoom levels<  1 create very
noticeable artifacts)
- Removed zoom 0.7 (does not exist in Pcbnew)
(Note: Pcnew did not have zoom level 0.7,
and due to internal units 10 time smaller, best zoom<  1 is in fact never used
even for small SMD footprints)
These ugly changes in Eeschema do not fix this zoom issue, but artifacts that
can happen are acceptable.

wxWidgets version 2.8.12 seems the last 2.8 version before the 2.9.2 and the
3.0 wxWidgets version,
so I hope wxWidgets 2.9.2 will fix all annoying issues found in Kicad,
but currently this version is under development and has some (minor) issues.
Currently the floating point issue is fixed.
But because changes are committed every day, this version is hard to use for
the Kicad stable version.

Currently on Linux, if you start eeschema without loading a schematic, the
sheet border is off screen on top and bottom, suggesting the initial zoom is
not optimal for viewing the border.

Is this intentional?

Would filing a bug report help get this fixed?

Don't bother filing a bug report.  I thought JP might roll the changes back
over the weekend.  It was too nice here over the weekend to sit inside behind a
keyboard.  I'll do it tonight.  It may not get committed until tomorrow morning


Obviously, Is this intentional.

I do not have this problem (neither under Windows, nor under Linux Ubuntu 10.1)
So i am unable to fix it.


If we are making 2.9 the required version for Windows, I will remove the
conditional compilation zoom code and restore the old behavior which will work
properly with 2.8 on Linux and OSX.  At some point when I get some extra time,
I'll write a CMake macro that will complain if the version of wxWidgets isn't
correct which will put this issue to rest once and for all.


OK. No problem.

Jean-Pierre CHARRAS