kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 04/02/2014 12:39 PM, Dick Hollenbeck wrote:
> Here is more info, which will help you create some low level mock up classes.
> 
> Class KIWAY_MGR:
> (temporarily in kicad/kicad.cpp) will get swigged, creating a python class implemented
> fully in C++.  It is a collection of PROJECTs/KIWAYs.  The constructor of this class may
> take a wxFrame*, so we have the option of hooking child frames into that parent.  Possible
> functions:
>   createProject( full_path_to_pro_file )
>   openProject( full_path_to_pro_file )
>   listProjects()
> 
> 
> Class KIWAY:
> will get swigged, creating a python class implemented fully in C++.  Possible functions:
>   openSchematic()  no args required, schematic's name is in the *.pro file.
>   openBoard() no args required, board's name is in the *.pro file.
> 
> 
> Just with this sketch, you should be able to mock enough both of these classes, enough to
> work magic at in the UI layer.  If you want to open dummy child frames, that would be ok
> from openSchematic and openBoard().
> 
> 
> Feel free to add functions as you find needs for them.  This will give us an aspect of top
> down design.
> 
> 
> HTH,
> 
> Dick
> 
> 
> 
> 
> 
> On 04/02/2014 11:58 AM, Dick Hollenbeck wrote:
>> Hi Jean-Samuel,
>>
>> Thanks very much for your willingness to help!
>>
>> In answer to your question:
>>
>> The wxPython project manager sketch up should concentrate on the user interface, not the
>> actual loading of the sub programs.  In fact, if it did not load the subprograms at all,
>> that would be acceptable.  The screen real-estate usage, and the icons and whatnot are
>> what's important for now.  You could create scaffolding to mark a project and a kiface as
>> being loaded, and test your UI code against that scaffolding, without ever loading any
>> projects or opening any child frames.
>>
>> In milestone B) we are putting a top C++ API into the KIWAY, this is not designed yet.
>> You should not use the KIFACE from python, that was never intended.  Python will use the
>> KIWAY API, which in turn will manage the KIFACE's and projects using C++.
>>
>> If you really really want to launch something, then encapsulate that python code into
>> something which will be replaced later, and simply load pcbnew.exe for now from that
>> disposable code.  This code will get swapped out later, in favor of the KIWAY API, which
>> will do the actuall loading of the *.kiface, again from C++.  This is necessary so that
>> the KIFACE to KIFACE 

oops, meant not "KIFACE to KIFACE", but rather

"project specific KIWAY_PLAYER to KIWAY_PLAYER"


comms can work for things like back annotation, and pcbnew<->eeschema
>> cross-probing, per project.
>>
>>
>> There's actually little value in loading executables or kiface's right now.  Folks will
>> use the C++ project manager until the user interface in the python project manager is
>> superior.  So please focus on the user interface, that's the value added stuff.
>>
>> After milestone B) that's when we start to worry about loading the submodules (kifaces).
>>
>>
>> Thanks,
>>
>> Dick
>>
>>
>>
>> On 04/02/2014 11:23 AM, Jean-Samuel Reynaud wrote:
>>> Hi
>>>
>>> As I understand, one of the feature of this new interface is to load directly from python
>>> the kiface interface (instead of just launch the program aka pcbnew/cvpcb for example).
>>> Is it right ?
>>> As I see, the function KIFACE_1 return a struct with inside all function to use (one of
>>> them is createwindow).
>>> Could you confirm it's the way you think about ?
>>> If yes, ctypes from python will help me and I think I'll fight with the structure
>>> definition inside python...
>>>
>>>
>>> Regards
>>>
>>>
>>>
>>> 2014-04-01 15:47 GMT+02:00 Dick Hollenbeck <dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>:
>>>
>>>
>>>     In English there is a saying: "Competition breeds success."
>>>
>>>     I would consider it a luxury to be able to choose [pieces] from multiple implementations.
>>>      Competition in this case is not exactly cruel and unusual punishment.  In fact it could
>>>     be an *awful lot of fun*, since wxPython is such a high level language and so much can be
>>>     done in so few lines of code.
>>>
>>>
>>>     You may either compete or collaborate.   I think we'll get more ideas if there is
>>>     competition.  After choices are made, you can continue to compete, improving, innovating
>>>     and serving your own needs, even if your code is not merged up to that point in time.
>>>     Repeat that last sentence.
>>>
>>>
>>>     Any implementation which does not meet the primary objective: "showing which projects are
>>>     open, among a larger set of project possibilities" will lose the competition.  (Even if
>>>     there is only one entry into the competition, *multiple* open projects is a mandate.)
>>>     Using screen real estate for a permanently visible directory tree may not be an optimal
>>>     pathway to achieving the objective.
>>>
>>>     Some tips:
>>>
>>>     a) the directory tree does not give sufficient emphasis on what constitutes a project.
>>>
>>>     b) the directory tree does not give the ability to show several open projects without a
>>>     sea of rows of actual files in between.
>>>
>>>     c) we need to be more project centric, less file centric.
>>>
>>>     d) once projects have been defined, the user interface procedure to opening the schematic
>>>     or layout tools on any of those projects needs to be lean.
>>>
>>>     e) I'm thinking the set of files that constitute a project can continue to reside in the
>>>     *.pro file.
>>>
>>>
>>>
>>>
>>>
>>>     On 04/01/2014 07:24 AM, dileep kushwaha wrote:
>>>     > Hi,
>>>     >      I have so far made the menubar for the wxPython. I now want to integrate the
>>>     > mainmenu.py to KiCAD instead of .cpp codes. I little hint and guidence will be great. I
>>>     > can send the code. Its ugly right now. i'll modify it according to guidlines after
>>>     > completing significant portion...(i see three .cpp files that will have to changed)
>>>     >
>>>     >
>>>     > On Tue, Apr 1, 2014 at 9:14 AM, dileep kushwaha <dilzverykool@xxxxxxxxx
>>>     <mailto:dilzverykool@xxxxxxxxx>
>>>     > <mailto:dilzverykool@xxxxxxxxx <mailto:dilzverykool@xxxxxxxxx>>> wrote:
>>>     >
>>>     >     Hi,
>>>     >          Please accept my apology for the delay from my side. I can give you few results
>>>     >     in maximum one week's time. I am able to make an exact replica of KiCAD window
>>>     that we
>>>     >     have right now. I was carried away and wanted the GUI to look pretty innovative.
>>>     I was
>>>     >     looking into the feasibility of an idea. The idea comes from a member who
>>>     proposed it
>>>     >     to have a game like GUI. I was thinking if right click would give list of options
>>>     >     surrounding it in circle. I think I will have to wait a little more to get
>>>     expertise.
>>>     >
>>>     >     I was shying away from showing my work. Apparently I will start uploading on the
>>>     >     branch by evening 6PM IST(Indian Standard Time)
>>>     >
>>>     >
>>>     >
>>>     >     On Tue, Apr 1, 2014 at 2:27 AM, Jean-Samuel Reynaud <js.reynaud@xxxxxxxxx
>>>     <mailto:js.reynaud@xxxxxxxxx>
>>>     >     <mailto:js.reynaud@xxxxxxxxx <mailto:js.reynaud@xxxxxxxxx>>> wrote:
>>>     >
>>>     >         Ok I'm starting to work to meet window 1).
>>>     >
>>>     >
>>>     >         2014-03-31 17:01 GMT+02:00 Dick Hollenbeck <dick@xxxxxxxxxxx
>>>     <mailto:dick@xxxxxxxxxxx>
>>>     >         <mailto:dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>>:
>>>     >
>>>     >             On 03/24/2014 10:19 AM, Jean-Samuel Reynaud wrote:
>>>     >             > Hi,
>>>     >             >
>>>     >             > I can help too on this project. Tell me if you need more help.
>>>     >
>>>     >
>>>     >
>>>     >             https://code.launchpad.net/~kicad-developers/kicad/prj-mgr
>>>     >
>>>     >             is still empty, so therefore I need help.
>>>     >
>>>     >
>>>     >             There are two windows of opportunity here, with a middle section where the
>>>     >             window is not open:
>>>     >
>>>     >
>>>     >             1) Now, before I get to milestone C)
>>>     >
>>>     >
>>>     >             2) Me doing milestone C), where collisions of effort are so likely its most
>>>     >             sensible to
>>>     >             consider python contributions in this time un-helpful.  Plus I don't
>>>     know what
>>>     >             I'll have
>>>     >             to work with at this point.  And I won't be waiting for it.
>>>     >
>>>     >
>>>     >             3) After the C++ layer and framework are in place, then collisions of effort
>>>     >             will not
>>>     >             concern me, the python project manager can and should be expanded into a
>>>     number of
>>>     >             directions, and I don't expect to play a role in that.
>>>     >
>>>     >
>>>     >             I want to be clear about these two windows of opportunity, 1) & 3), and the
>>>     >             approximate
>>>     >             timing, at least the sequencing.
>>>     >
>>>     >             The contributions that I would value most are in the window described by 1).
>>>     >
>>>     >
>>>     >
>>>     >
>>>     >         _______________________________________________
>>>     >         Mailing list: https://launchpad.net/~kicad-developers
>>>     >         Post to    : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>     >         <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>>     >         Unsubscribe: https://launchpad.net/~kicad-developers
>>>     >         More help  : https://help.launchpad.net/ListHelp
>>>     >
>>>     >
>>>     >
>>>     >
>>>     >
>>>     >
>>>     >
>>>     >
>>>     > --
>>>     > Dileep Kumar
>>>     > M.Tech(VLSI Design)
>>>     > Mob:9891455965
>>>
>>>
>>
>>
>> _______________________________________________
>> 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
>