kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

Yeah, I can’t believe g_RootSheet hasn’t gotten us into more trouble.  I guess most of the issues I’ve seen to-date with the globals have been between edit frames, and since only SCH_EDIT_FRAME uses sheets we’ve been OK.  (That being said, the last one was SCH_EDIT_FRAME and PLOTTER getting in a fight over a single instance of default line width.)

Multiple projects open at once would be really nice, though….

Cheers,
Jeff.

> On 12 Apr 2020, at 01:38, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
> 
> My definition:
> 
> I like to abstract the definition a little more than some designers, and include things
> like singletons because a singleton intends to limit the number of instances to one.  I
> would think you still have a global variable if you wrapped it into a class with a single
> static instance.  You still only have one global instance.  That to me is still a global
> variable with a fancy accessor, and that might even be worse.
> 
> If you can instantiate multiple instances, and the pointers to those instances are in
> client user objects or on the stack, then you are probably not using a global.
> 
> Think of the world as being the *one* globe that we live on.  We have a global air supply,
> and it spans all countries.  It is global because we cannot instantiate another instance
> of the world's air supply, not because of how we spell its name, or where it exits.
> 
> 
> The purpose of the PROJECT class was to create a place to store project specific objects,
> with full intention of supporting more than one open project at some point in time.  You
> can see this vision laid out in kiway.h.  Not a KiCad day goes by when I don't have
> multiple KiCad projects open at the same time.  Currently, I typically am working on one
> project under the project manager, but then load eeschema or pcbnew in singletop mode to
> "view only" the other project data.
> 
> And even if multiple projects is not currently on the todo list, I think it is a mistake
> to put road blocks in the path of supporting multiple projects at the same time.  It is
> trivial to avoid those road blocks in most cases: avoid globals, including singletons
> where one instance would not satisfy all projects. Instead, just use PROJECT and stuff
> your PROJECT specific stuff into a PROJECT::_ELEM.
> 
> I recently got rid of g_RootSheet by using PROJECT.  It evolved through a can of worms,
> but the worms are now all dead.  And the result is better than the formerly closed can of
> worms.
> 
> One of the coolest features of PROJECT is the "data on demand" paradigm, or some might
> call it lazy loading.  For python clients and what not, and any type of window client of
> the PROJECT, it leaves the loading code out of sight and in a common place.
> 
> The main danger is the use of the virtual destructors in PROJECT::_ELEM.  That takes some
> getting used to.  You must destroy any PROJECT elements that you own before your DSO gets
> kicked out of process. This means as you exit EESCHEMA, that DSO might get unloaded from
> ram, particularly if all windows in eeschema are closed.  I don't know that this unloading
> happens, but because it could happen, it is best to design for it.  And mostly that means
> calling
>  SetElem( ELEMTYPE, nullptr );
> 
> in your clients' last destructor.
> 
> 
> 
> 
> 
> _______________________________________________
> 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