Re: [Kicad-developers] What is a global variable, and why we don't need them.
On 4/13/20 7:39 AM, Dick Hollenbeck wrote: > Individual > PROJECT clients view their libraries through the lens of their own > FP_LIB_TABLE. > > If at that point shared pointers were introduced, it might be too bad to get > to shared > libraries. If something is in the way of this, then maybe you remove it. Of course I meant in the FP_LIB_TABLE goes the shared pointers, and you'd have to track which have been opened already in a name map. Also, to help the guy who deletes a library part in Eeschema from one project that is not using it, and just so happens to have another schematic open that is still using it, you might give that guy some more shared pointers too. This is when pointing to the library part instead of including it. Pcbnew is perhaps an easier implementation in this regard, since it uses inclusion (=duplication) rather than pointer to footprints in a library. In any case, other issues may be invisible from where we stand now. But where there is a will, there is a way. ___ 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
Re: [Kicad-developers] What is a global variable, and why we don't need them.
On 4/12/20 8:50 AM, Brian wrote: > Just out of curiosity, what’s an example use case for multiple projects open > at once, that > isn’t served by multiple instances of KiCAD? I admit I haven’t run into many > reasons to > have more than one open at a time in my own usage other than occasionally > referring to an > old project as a reference for a new one. > > Cheers, > -Brian > > > >> Multiple projects open at once would be /really/ nice, though…. >> >> Cheers, >> Jeff. When you open more than one copy of KiCad, you open more than one copy of the libraries. This is like having the same document open in more than one text editor. The last guy wins, meaning there can be competition between the two editors for the state of the data files, depending on who writes or saves last. In the multiple projects under one process model, you would have to identify libraries that are common among the two projects, and share them. This overlap is a subset, not a full duplication because of the "project specific" libraries can be different. Individual PROJECT clients view their libraries through the lens of their own FP_LIB_TABLE. If at that point shared pointers were introduced, it might be too bad to get to shared libraries. If something is in the way of this, then maybe you remove it. Features like this, along with all the file conversions from foreign tools are great attractors to the KiCad solution. KiCad is uniquely positioned to continue to attract users. Being written in a relatively high level language means it has a powerful gas pedal, and having a design that people can get their minds around, with clearly readable code, all serve to encourage people into thinking that this is the way to go. Also, being able to see that the design anticipates features not already implemented is no small thing. Dick ___ 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
Re: [Kicad-developers] What is a global variable, and why we don't need them.
This is indeed my particular problem. But copy/paste only recently started using the system clipboard, so that would have been an issue too. I can’t remember if the fixes for that are in 5.1 or 6.0…. > On 13 Apr 2020, at 04:23, Andy Peters wrote: > > > >> On Apr 12, 2020, at 6:50 AM, Brian wrote: >> >> Just out of curiosity, what’s an example use case for multiple projects open >> at once, that isn’t served by multiple instances of KiCAD? I admit I >> haven’t run into many reasons to have more than one open at a time in my own >> usage other than occasionally referring to an old project as a reference for >> a new one. > > For starters, you can’t have multiple instances of Kicad running on macOS. > > -a > ___ > 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
Re: [Kicad-developers] What is a global variable, and why we don't need them.
> On Apr 12, 2020, at 6:50 AM, Brian wrote: > > Just out of curiosity, what’s an example use case for multiple projects open > at once, that isn’t served by multiple instances of KiCAD? I admit I haven’t > run into many reasons to have more than one open at a time in my own usage > other than occasionally referring to an old project as a reference for a new > one. For starters, you can’t have multiple instances of Kicad running on macOS. -a ___ 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
Re: [Kicad-developers] What is a global variable, and why we don't need them.
Just out of curiosity, what’s an example use case for multiple projects open at once, that isn’t served by multiple instances of KiCAD? I admit I haven’t run into many reasons to have more than one open at a time in my own usage other than occasionally referring to an old project as a reference for a new one. Cheers, -Brian > Multiple projects open at once would be really nice, though…. > > Cheers, > Jeff. >> ___ 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
Re: [Kicad-developers] What is a global variable, and why we don't need them.
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 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
[Kicad-developers] What is a global variable, and why we don't need them.
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
