kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 03/05/2012 07:23 AM, Miguel Angel Ajo Pelayo wrote:
> Well, I managed to wrap the DLIST<xxx> templates after fixing some strange inheritance
> behaviour in swig (via %ignore directives).
>
> And everything seems to start working with the lists from BOARD object.

Congratulations!  Thanks for your work.

>
> I found that there is a lot of dependencies with wxPoint and wxString, which are quite
> complicated  to handle (without using the .i files from wxPython project or building
> equivalent ones).
>
> Would it make sense for the project to remove dependencies with wx*** were we are not at
> UI level?,

That question is too general.  If asked that way, then no.

> I mean, internal objects and structures, passing names to open or save files, etc. ?,
> main dendencies go to wxString, wxPoint, wxSize and wxRect, another option could be
> adding extra LoadFile, SaveFile methods receiving plain char *const string, which
> internally converted the strings.

A discussion of "char*" is insufficient in itself, without being supplemented with a
description of the encoding scheme used to represent the full international character set.
Sometimes that encoding scheme is one thing and in another place it is another.  For
example, we have tried to achieve UTF8 encoding for all KiCad file content. 

Yet filenames on on disk in a disk directory, are encoded using the local encoding scheme
for that operating system and country.

wxFopen( wxStrring... ) takes care of this for us.


> For swig wrappers, it's not the same a wxPoint from our wrappers that a wxPoint from the
> wx standard wrappers
> in python.

That was an unclear sentence, please rephrase the question.

(wxPoint is about as simple of a class that you can write for holding two datapoints, but
I don't know what question I am being asked here.)


> (see the picture). That will make it complicated if we want to pass wx objects to our
> calls, or wx objects from our calls to wx python made dialogs. At least, until I'm not
> able to find a way to synchronize that (which in the end it could be possible).

Not following you, maybe an example would help, more specific.

>
>
> I will keep working on it, and keep you updated, my "roadmap" may look like this: 
>
> 1) End the wrapper for BOARD objects, and all the objects inside a board.
> 1.b) Add wrappers to basic objects like wxString, wxPoint, etc...
> 1.c) Clean up the GetBoard() implementation I did now (just for test)
> 2) Wrap the KICAD_PLUGIN + BOARD objects, to make "kicad/pcbnew" modules importable from
> scripts.
> 3) Make some QA tests to check the our new scripting classes

Are you saying BOARD_ACTIONs is something you need help with?  Splitting into DLL/DSO's?
It is not a problem to ask for help, but please let's be clear.  Your roadmap is missing a
couple of items that I mentioned.


>
> Stepping up for this job it seems more and more feasible to me, as I solve the little
> problems that I'm finding around it
> should be something easy to do and maintain

We appreciate your help.  If the implementation is clear, the files are well organized and
described, then I would not over estimate YOUR burden in maintaining them.  They would
become part of the KiCad source base and there would be help from other developers in
maintenance.  Ease of maintenance IS a concern, but this is influenced largely by choices
made during implementation.


Sorry I have not had time to look at your work yet.  I am finding little free time at the
moment.

Again, thanks very much.

Dick