> Maybe another thing is to split it complete from the kicad core. So > create a real library written in ISO C++ so people who want to write > plugins and language bindings will be more happy than the hacked code > to read and write files in the current codebase. Because if you find > some software which can do something with the kicad file formats they > all write their own parsers/handlers and that is a bit of a pain to > keep the other people updated for the new upcomming file format(s). > Also if you dont use any existing library be used in your library like > wxwidgets it is portable to everywhere and also for people who want > something different than wxwidgets like Qt/Gtkmm etcetera. Than you > will see much more tools and utilities than now. > > Maybe you should have a look how dxflib and podofo pdf library. Then > are very powerfull libraries and very consistent with names and > classes. In my opionion this is a pre for a new file format > reader/writer. > > Kind regards, > Jerry Jacobs > >
I have also favored this idea for years, and it goes like this: PLAN A: ====== Ideally, long term, the file 1) reading, 2) writing and 3) ram data-tree, could be done in a *.DLL/*.so file that is then dynamically linked to from upper UI code, even for the eeschema executable. The shared foundation code (*.DLL/*.so) would avoid all UI code. In fact if you had to link it against wxwidgets for anything but wxString, you probably missed the described design target. Any need to communicate errors up to a UI layer could be done with exceptions, and those could be caught and dealt with in the main executable. To enforce this during the coding phase, I would probaby not even use wxString, just to avoid linking to wxWidgets at all. Then at the end switch over to wxString once the DLL was known to be free of any UI code. The transition would be done by a reassigned typedef or mapping class back to wxString. I think to handle text in a way compatible between the two coding realms (UI-less library, and upper application), you have to have a common string class. There are a number of questions with this plan: 1) Written in C++, can you create a layer for each language binding to the languages that you want? (I would not help write it in C, nor would I ever want anything to do with it if it were written in C.) 2) Does this expand the API to the point of huge, because you have to expose models of all objects contained in the data-tree for all supported languages. 3) Can you avoid C for the most part and still do the language bindings, limiting C's presence to very few source modules? On balance I think the problems that this PLAN A solves are getting smaller, and so we have to look back at the original problems and re-measure them in the face of the new file formats. So let's talk about PLAN B. PLAN B: ====== We recognize that with a new set of DSN grammars, we might as well be talking about something very analogous to XML, but nicer looking and with no distinction between elements and attributes. Most languages deal best with XML on their own terms, they have parsers and data trees in the language, optimized for the language. It would not be very hard to duplicate the generic functionality of DSNLEXER in say python or Java or Perl or Groovy. In fact there will be a number of *.keywords files laying around that could be directly imported into a generic DSN lexer/parser written in a target scripting language. In summary, plan B is to push the work into each target scripting language, but with full recognition that with the new file formats this work is now *significantly* reduced and subject to much code sharing across the various grammars. In some cases a common parser could be used to parse any DSN grammar, in the same way that an XML parser can parse any XML file without knowing the grammar. It just creates a tree of named elements. An element needs to hold a list of other elements and also of name value pairs. This is all made possible by gravitating to the DSN file format (with unique grammar per file purpose). ============ In summary, my current thinking is that the problem that PLAN A would have solved is now smaller with the new DSN formats. So small in fact, that it is not worth the work to do PLAN A. PLAN B becomes the path of lessor resistance and greater ultimate usability within the target scripting language. Having said that, there are some ideas under PLAN A above that could be used to write (rewrite?) the C++ classes, speaking now of the separation of UI code, without going all the way of creating a shared library out of them. Dick _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
