kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 04/01/2011 12:42 AM, jean-pierre charras wrote:
> Le 31/03/2011 21:38, Wayne Stambaugh a écrit :
>> On 3/30/2011 3:57 PM, jean-pierre charras wrote:
>>> Le 30/03/2011 19:49, Dick Hollenbeck a écrit :
>>>>>>> Seems Window specific (I did not see any problem under Linux Ubuntu 10.1).
>>>>>>> Tested with wxMSW 2.8.11 and 2.8.12
>>>>>>> But with wxWidgets 2.9.1, no problem.
>>>>>>> Unfortunately wxWidgets 2.9.1 creates other issues.
>>>> Jean-Pierre,
>>>>
>>>>
>>>> What are problems with 2.9.1, and are they MS Windows specific?
>>>>
>>>>
>>>> On Windows, if we do the full CMakeList.txt file build I have been
>>>> advocating, this would entail using External Project to build wxWidgets too,
>>>> we can apply patches to wxWidgets before building it.
>>>>
>>>>
>>>> Dick
>>>>
>>> In fact, there are very few and very minor issues, but one.
>>> The annoying one is related to floating point separator.
>>>
>>> When the floating point separator is a comma instead of a point, an annoying
>>> behavior happens.
>>>
>>> Gerbview displays always floating numbers (coordinates in status bar for
>>> instance) using a point.
>>> Pcbnew seems OK.
>>> The most annoying issue was seen with Eeschema.
>>> When starting Eeschema, the schematic editor displays floating number using a
>>> comma (this is OK)
>>> But depending on what dialog was opened (or after opening Libedit),
>>> sometimes schematic editor displays floating number using a point, after
>>> closing the dialog.
>>> This behavior depend on Eeschema version.
>>>
>>> For instance, previously, when opening and closing Libedit (nothing else is
>>> needed),
>>> eeschema revert to a point, but for now this behavior does not happen.
>>>
>>> And for users, this behavior is very inconsistent.
>>>
>>> And if your are entering (in a dialog) coordinates with the bad separator (that
>>> changes sometimes),
>>> floating numbers in the dialog are not correctly converted.
>>> (I must say I did not have a look to this issue, that should not occur,
>>>   because inside Kicad, users should use a comma or a point as separator,
>>>   whatever the current locale uses)
>>>
>>> I did not noticed this issue with wxGTK.
>>> I'll try to build Gerbview using latest svn wxWidget version (2.9.2) ASAP.
>>>
>> JP,
>>
>> Your fix doesn't isn't quite what I expecting.  I thought you found a solution
>> with the blitting or the scroll bar position to solve the problem.  Removing
>> the zoom factors that result in non integer scaling factors will likely
>> generate some complaints.  Your fix als has the unfortunate side effect of
>> calculating a best zoom value that causes the page to be truncated if the
>> window size is not an even ratio of the drawing size.  I'm sure someone will
>> file a bug report against this.
>>
>> Wayne
>>
> I was thinking this ugly workaround was working.
> But you are right, there are many zoom values that do not work (I did not noticed these values).
>
> I'll work on it these newt days.
> If you find a better fix before I find a working workaround, please commit it.

Require a wxWidgets version that works?  Seems especially do-able on MS
Windows, where the builder person can pick what wxWidgets version to compile
(the *required* version.)

So based on my limited information, a path to success on MS Windows is to
fix what else is wrong with wxWidgets 2.9.x, and get THIS zoom fix for free.

Since the MS Windows builder person has to compile the wxWidgets library, it
can be patched before compiling quite easily, as a means of fixing the other
issues.

My $ 0.02