kicad-developers team mailing list archive

[dileep kushwaha <dilzverykool@xxxxxxxxx>]

Hi,
      I'm going through your last 4 mails and trying to plan out things. I
will clear some of my doubt first and then ask you if i face trouble. I was
trying to make a replica of existing GUI without understanding the whole
project(includiing Kiway). It seeme the exact replica of existing GUI would
be a waste. I ll mail you shortly.


On Thu, Apr 3, 2014 at 3:02 AM, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:

> 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
> >
>
>
> _______________________________________________
> 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
>



-- 
Dileep Kumar
M.Tech(VLSI Design)
Mob:9891455965