On Tue, Apr 01, 2008 at 05:36:20PM -0400, rgheck wrote: > Bo Peng wrote: >>> > What is the key to this map? If it is biblio, not /path/to/biblio.bib, >>> > then you can make bibfiles_ a map, and the meta_ patch is no longer >>> > needed. >>> > >>> Yes. This is what I've been trying to say, more or less. But note that, >>> when we output latex, we iterate not over bibfiles_ but over params, and >>> we (quickly) look up the embedded file info in the map. We do it this >>> way because we should keep the order. This requires that bibfiles_ and >>> the params be in sync, but they have to be kept in sync anyway. We >>> resolved that issue a long time ago. >>> >> >> OK. We have agree upon at least a few things, >> >> 1. EmbeddedFileList (or map) has to be in sync with params, has to be >> valid, so it can not be separated from params. In this sense, who >> should be the core information (so that another one does not have to >> be updated) is a false problem. >> >> 2. EmbeddedFile needs this meta_, and your solution of map<meta_, >> EmbeddedFile> is acceptable to me. However, meta_ is a solution to a >> general problem, that may be needed anyway in, for example, >> InsetGraphics. I am not against the idea that you fix InsetBibtex now, >> and fix InsetGraphic later. >> >> > We won't know this until we look at fixing that. I'm inclined, actually, to > do something more general, namely, to try to bring InsetGraphic into the > InsetCommand hierarchy. I think this was intended all along as part of a > more general transition that was never finished.
Could you please elaborate on why having the InsetCommand hierarchy is useful at all? As far as I can tell the main benefit was to have a uniform means to pass "Parameters" through the Controller layer in the Old Days. This layer is gone now, and it feels a bit strange to pass around unrelated pieces of data from otherwise unrelated insets in a common structure. Wouldn't per-inset specific data with direct access from the GUI simplify overall structure and reduce conversion costs? [Note that I did not follow GUI development too closely then, so I might easily miss something very important here.] Andre'
