kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #22940
Re: Release 5 road map
For the Object Properties and Introspection, I think it could be useful to add
not only name/type/value but context/namespace (or equivalent) too.
That could also be possible by using name as “<namespace>.<name>”.
I’m specifically thinking, of how could we separate properties related to different
things. For example, a parametric footprint derived from a footprint generator could
have all it’s “footprint parameters” in the footprint namespace.
* footprint-generator
- generator: PCB Antenna
- freq: 2.4GHz
- A: …
- B: ….
But, as I was saying, it could equally be:
* footprint-generator.generator: PCB Antenna
* footprint-generator.freq: 2.4GHz
* footprint-generator.A: …
* footprint-generator:B: …
> On 05 Feb 2016, at 01:00, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>
> I think this was originally meant to be a generic plugin object and
> plugin manager to be used as a base classes. I believe it was something
> I discussed with Tom a while back. It may or may not still be useful.
> I would be willing to bet most plugin managers and plugins have to do a
> lot of the same basic tasks for loading and unloading the plugins which
> could be unified in well designed base classes. It's the next level up
> that defines the actual plugin and plugin manager functionality. I
> agree with your assessment that a do it all plugin manager would be a
> bad idea.
>
> On 2/4/2016 4:18 PM, Cirilo Bernardo wrote:
>> For the section Dynamic Library Plugin, what is described would
>> not be a reasonable implementation. We cannot have a "do it all"
>> plugin - that would result in unnecessary complexity and also couple
>> code which should not be coupled. Perhaps we need a more refined
>> description of what people would like to do with these plugins?
>>
>> I have already created a simple plugin framework and a 3D Plugin
>> class which is responsible for loading and creating rendering data
>> for the 3D viewer. Next on my list is to develop a PCB Plugin which
>> can perform I/O on a BOARD class - this involves creating a
>> PCB Plugin API and a pcbnew API. The pcbnew API can be used
>> for just about anything - re-implement Python scripting interface,
>> implement various MCAD/ECAD Import/Export etc.
>>
>> - Cirilo
>>
>> On Fri, Feb 5, 2016 at 3:04 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>> wrote:
>>
>> I committed the release 5 road map yesterday and the developers
>> documentation[1] on the KiCad website has be updated. Please take a
>> look at it when you get a chance and let me know if you find anything I
>> missed that we discussed for the current development cycle or if you
>> find any errors. It's pretty ambitious already so I don't know if we
>> should be adding too much to it. If you find something in there that
>> interests you and you're willing to work on itplease let the dev team
>> know so we are not all working on the same thing. As of right now, I've
>> assigned myself the schematic object refactor (in progress), I/O
>> manager, and new schematic and component library file formats tasks.
>>
>> Thanks,
>>
>> Wayne
>>
>> [1]
>> http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/v5_road_map.html
>>
>> _______________________________________________
>> 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
>>
>>
>
>
> _______________________________________________
> 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