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 <[email protected] >>> <mailto:[email protected]>>: >>> >>> >>> 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 >>> <[email protected] >>> <mailto:[email protected]> >>> > <mailto:[email protected] <mailto:[email protected]>>> >>> 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 >>> <[email protected] >>> <mailto:[email protected]> >>> > <mailto:[email protected] <mailto:[email protected]>>> >>> wrote: >>> > >>> > Ok I'm starting to work to meet window 1). >>> > >>> > >>> > 2014-03-31 17:01 GMT+02:00 Dick Hollenbeck <[email protected] >>> <mailto:[email protected]> >>> > <mailto:[email protected] <mailto:[email protected]>>>: >>> > >>> > 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 : [email protected] >>> <mailto:[email protected]> >>> > <mailto:[email protected] >>> <mailto:[email protected]>> >>> > 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 : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
