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 <d...@softplc.com> 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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp