← Back to team overview

kicad-developers team mailing list archive

Re: Standalone mode.

 

On Sun, Mar 05, 2017 at 12:36:20PM -0500, Wayne Stambaugh wrote:
> On 3/4/2017 8:11 PM, Cirilo Bernardo wrote:
> > On Sun, Mar 5, 2017 at 10:29 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
> >> On 2/27/2017 11:28 AM, Chris Pavlina wrote:
> >>> Hi,
> >>>
> >>> There are a few problems with "standalone mode" that I see. One of the
> >>> biggest is demonstrated [1] - kiway services aren't available. In my
> >>> opinion this really is detrimental to the function of the software -
> >>> e.g. eeschema shouldn't be missing features just because it was started
> >>> in standalone.
> >>>
> >>> Another problem is the awkwardness of packaging/install on systems that
> >>> expect applications to be discrete units, like macOS. There's some
> >>> foreshadowing on the bug tracker of trouble wrt. signed packages, which
> >>> I couldn't immediately dig up.
> >>>
> >>> I'd really like if we could change this. I don't think standalone mode
> >>> the way we implement it is necessary. It is necessary that one can open
> >>> a pure schematic file, or a pure PCB file, outside of the context of a
> >>> project -- but I do NOT think this should require starting the
> >>> individual application separately from the project manager.
> >>>
> >>> What if the project manager simply understood the concept of single
> >>> files as well as projects?
> >>
> >> I honestly don't know how this will work out.  Regardless of how the
> >> editors are launched, the project configuration is very much in play and
> >> there is currently no support for multiple projects open simultaneously.
> >>  I don't know how you will open a single schematic in a manner which
> >> will wreak havoc on the symbol library lists.  Boards are a different
> >> story since their footprints are embedded so it's probably less of an
> >> issue.  Once the new schematic file format is in play than the symbol
> >> library issue is no longer in play.  I'm not opposed to you trying but I
> >> don't think we are any where near ready to attempt to head down that
> >> path any time soon.
> >>
> > 
> > I think the idea is to have a single executable which can act as the
> > standalone launcher for all the kiway blobs rather than have N
> > installed versions of what is essentially the same launcher. Kicad
> > should still work as expected: if it opens a *.pro file then eeschema
> > and pcbnew can talk to eachother and if it opens a *.sch/*.kicad_pcb
> > file or what not then the program invoked acts like the standalone.
> > 
> > Although it would be nice to have standalone instances of eeschema,
> > pcbnew and so on magically talk to eachother, we all know that would
> > require a well-planned IPC based mechanism and that's not what's
> > being proposed here.
> 
> This should be transparent unless someone changed it.  When launched in
> stand alone mode, the kiway messaging falls back to the legacy sockets
> implementation for message passing.  The problem becomes how to handle
> the IPC when you open the schematic from one project and the board from
> a different project in stand alone mode.

You don't.

What's wrong with just not having IPC between standalone instances? They
shouldn't need to pass anything amongst themselves.

At some point it would be nice to be able to pass clipboard items
between instances, but this can be handled by wxClipboard.

> 
> > 
> > - Cirilo
> > 
> >>>
> >>> [1] https://bugs.launchpad.net/kicad/+bug/1668157
> >>>
> >>
> >>
> >> _______________________________________________
> >> 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


Follow ups

References