kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #05692
Re: Improving usability of KiCad
> I would have no issue if you wanted to provide SQL import and export of BOMS
> and other tabular data structures in Kicad. I do have an issue with actually
> using a database to store this information within Kicad. Plain text files
> provide so many advantages over a database for the way Kicad saves and loads
> it's data structures.
I'm actually not talking about the way kicad stores data from and to disk.
The database structure may (IMMO) be an extremey optimized (user
oriented) way to lay out volatile memory structures.
An embeddable database where different "modules" can read, write and
interrogate data (the db is loaded from actual files and saved by main
application into file) could create a step of virtualization between
object data containers and handler functions.
I think that, if BOM generator, DRC and other parts of the application
that do not access the GUI are separated from the main application
(accessing database instead of object structures), this could make
things better.
This is nothinig more that my opinion; however I have no doubt: a
solid internal data structure is one of the success points of this
kind of applications.
> you should fall back and clean up the low level object
> code first then add your new implementation. This has the added benefit of
> making it easier for the next person who comes along. I know this is not the
> most glamorous way to contribute to Kicad, but it is probably more important
> than the next feature that adds to the complexity. Maybe you can be like me
> and have negative number of lines of code contributed because you've delete
> more lines of code then you have added :).
I completely agree with you. In the mean time, you should consider
that this is also one of hardest tasks.
It involves a complete knowledge of the code, and usually "better"
implementations need to move files, create folders, change their name,
move code sections, and so on...
The new implementation I wrote seemed to me the best way to start
something. I hope you understand why I did not try to clean up the
code. It generally involves a strong knowledge in the code and a good
position within developers (I cannot expect that my messages will be
considered important until I will do something useful). I'll consider
if I can do something in this way.
I ask you to consider again if internal db structure could be a good
idea (in long term...).
Best regards,
Lorenzo
References