kicad-developers team mailing list archive

[Maciej Sumiński <maciej.suminski@xxxxxxx>]

Hi Miles,

On 11/24/2017 10:19 AM, miles mccoo wrote:
> in reply to Wayne's request to run the footprint wizard
> 
> I run the footprint wizard; it seems to run fine.
> when I press the 3D view button, I get a popup complaining about not
> finding the wx gtk2 library
>   "10:14:11: libwx_gtk2u_core-3.0.so.0: cannot open shared object file: No
> such file or directory
>    10:14:11: libwx_gtk2u_core-3.0.so.0: cannot open shared object file: No
> such file or directory"
> 
> which is odd because I have the gtk3 version of wx on my system.
> 
> 
> 
> In the second half of the video below, I point out that after modifying
> module locations in python, the GAL screen doesn't seem to update, even
> with the refresh command from the menu.
> 
> After I recorded the video, I found that switching to legacy canvas and
> then back to GAL, seems to trigger the needed redraw. How to I initiate
> this redraw from python? (or even c. I could update the swig stuff to call
> it in the refresh method available to python). Previously, I'd just worked
> in legacy but that's acting weird for me.

There is a difference between the legacy and GAL way of drawing. In the
legacy canvas everything is redrawn on every screen refresh. To boost
performance in GAL, most of graphics data is stored in the video memory
and is only updated upon request. After an item is modified, you need to
call KIGFX::VIEW::Update() to refresh the graphics data.

There are more data structures that require updates (e.g. ratsnest). To
avoid tedious repetition there is a class called BOARD_COMMIT that
notifies all interested parties and additionally creates an undo entry.
Tom has already suggested that this class needs to be available in the
Python interface.

Regards,
Orson

> Miles
> 
> 
> 
> 
> On Thu, Nov 23, 2017 at 10:44 PM, Nick Østergaard <oe.nick@xxxxxxxxx> wrote:
> 
>> I guess this is the same idea as with https://github.com/KiCad/
>> kicad-python
>>
>> 2017-11-23 19:28 GMT+01:00 Greg Smith <ecomputerd@xxxxxxxxx>:
>>
>>> "I was simply afraid that we
>>> may spent a lot of time petting the SWIG interface, which we will nuke
>>> it and start from scratch because of inevitable switch to Phoenix."
>>>
>>> I agree. I would suggest that the Python API is not quite stable enough
>>> to freeze the API. If we desire a stable interface/API, one could be
>>> written in Python itself. I am on the edge of implementing such an
>>> interface with KiCommand.
>>>
>>> KiCommand, in addition to being a command line interface, is a set of
>>> function calls that *could* be considered an API / Python class when
>>> complete.
>>>
>>> I have reviewed the Python API unit tests and found them to be lacking in
>>> coverage. I am duplicating those tests in KiCommand, and plan to extend the
>>> KiCommand tests, which could potentially be applied to the current Python
>>> API.
>>>
>>> If a stable API is desired, there should also be a set of unit tests
>>> verifying that functionality.
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

Attachment: signature.asc
Description: OpenPGP digital signature