Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

On Tue, Apr 01, 2008 at 06:49:25PM -0400, rgheck wrote: Andre Poenitz wrote: 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

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

Bo Peng [EMAIL PROTECTED] writes: Could you elaborate? Is that a pure-text tar-like format? I think you are suggesting a tar-like format that is not compressed so that it can be svned. I do not know how binary files such as jpg would be represented in such a file. No, a mac osx bundle is a

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

Could you elaborate? Is that a pure-text tar-like format? I think you are suggesting a tar-like format that is not compressed so that it can be svned. I do not know how binary files such as jpg would be represented in such a file. No, a mac osx bundle is a directory with files inside

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

I am fairly sure that per-inset code using a few common helper function would end up rather in the 20-30 lines range, and be more flexible in the end as we do not have to stick to yet another framework. I would happy to see this as well. There will be no conversion between params and

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

Andre Poenitz wrote: That said, I also agree with Abdel that we shouldn't bind ourselves to doing that if it makes things overly complex, and I don't really care that much how things are passed back and forth from the GUI. But that's really a separate issue from how ICP works. You can build

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

On Wed, Apr 02, 2008 at 12:25:35PM -0400, Richard Heck wrote: Andre Poenitz wrote: I understand that. But all such parameters are bound to a specific Inset instance, so why is this not InsetBibFoo::setBibFiles(whatever); ? Actually, the parameters need not be bound to a specific

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

Andre Poenitz wrote: On Wed, Apr 02, 2008 at 12:25:35PM -0400, Richard Heck wrote: Andre Poenitz wrote: I understand that. But all such parameters are bound to a specific Inset instance, so why is this not InsetBibFoo::setBibFiles(whatever); ? Actually, the parameters

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

On Tue, Apr 01, 2008 at 06:49:25PM -0400, rgheck wrote: > Andre Poenitz wrote: >> > 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

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

"Bo Peng" <[EMAIL PROTECTED]> writes: > Could you elaborate? Is that a pure-text tar-like format? I think you > are suggesting a tar-like format that is not compressed so that it can > be svned. I do not know how binary files such as jpg would be > represented in such a file. No, a mac osx

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

> > Could you elaborate? Is that a pure-text tar-like format? I think you > > are suggesting a tar-like format that is not compressed so that it can > > be svned. I do not know how binary files such as jpg would be > > represented in such a file. > > No, a mac osx bundle is a directory with

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

> I am fairly sure that per-inset code using a few common helper function > would end up rather in the 20-30 lines range, and be more flexible in > the end as we do not have to stick to yet another framework. I would happy to see this as well. There will be no conversion between params and

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

Andre Poenitz wrote: That said, I also agree with Abdel that we shouldn't bind ourselves to doing that if it makes things overly complex, and I don't really care that much how things are passed back and forth from the GUI. But that's really a separate issue from how ICP works. You can build

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

On Wed, Apr 02, 2008 at 12:25:35PM -0400, Richard Heck wrote: > Andre Poenitz wrote: >> I understand that. But all such parameters are bound to a specific Inset >> instance, so why is this not >> >> InsetBibFoo::setBibFiles(whatever); >> ? > > Actually, the parameters need not be bound to a

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

Andre Poenitz wrote: On Wed, Apr 02, 2008 at 12:25:35PM -0400, Richard Heck wrote: Andre Poenitz wrote: I understand that. But all such parameters are bound to a specific Inset instance, so why is this not InsetBibFoo::setBibFiles(whatever); ? Actually, the parameters

Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

Bo Peng wrote: Yes, I understand that we need to look up that information. But what I'm saying is that I want to use the EmbeddedFileList, which we're keeping in sync with the params, ONLY to look that information up if and when it's needed, and not use it in other ways. Yes, this is a minor

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

I wasn't trying to argue. I was trying to collaborate. But you are so protective of your code that you won't even let me fix the bugs YOU created. protective?? right. Note that your patch came before you understood how embedding works. The example wasn't idle. Using a map in InsetBibtex is

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

Bo Peng [EMAIL PROTECTED] writes: It is lucky that you are not supposed to svn an embedded .lyx file. Actually, it is rather a shortcoming of the implementation. If we allowed for a osx bundle-like representation (which would just have to be zipped to be a proper embedded file), this could go

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

Actually, it is rather a shortcoming of the implementation. If we allowed for a osx bundle-like representation (which would just have to be zipped to be a proper embedded file), this could go seemlessly into an svn archive. I understand this may not be doable immediately, but it is

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

Jean-Marc Lasgouttes wrote: Bo Peng [EMAIL PROTECTED] writes: It is lucky that you are not supposed to svn an embedded .lyx file. Actually, it is rather a shortcoming of the implementation. As I say elsewhere, the current implementation can guarantee that the order of the

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

Bo Peng wrote: I wasn't trying to argue. I was trying to collaborate. But you are so protective of your code that you won't even let me fix the bugs YOU created. protective?? right. Note that your patch came before you understood how embedding works. That was several patches ago.

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

You STILL don't understand the point. This isn't about Buffer::embeddedFile(), which is what is used to save the zip file. It's about the bibfilesCache_, which is a totally separate thing. I though that you are changing EmbeddedFileList from vectorEmbeddedFile to mapdocstring, EmbeddedFile.

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

Bo Peng wrote: Look, I want to make bibfilesCache_ a map. I have very good reasons to want to do this. I therefore want InsetBibtex::getBibFilesCache() to return such a map. (I suppose it could return something else, and then I could do some conversion, but why?) Back in InsetBibtex, I can

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

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

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

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_

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

There are then some minor problems left, such as 1. In functions such as addDatabase, should we update params first and update EmbeddedFileList/Map; or another way around? or encapsulate it in overridden setParam methods, so you can't forget to do it. I disliked your

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

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

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

Andre Poenitz wrote: 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

Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

Bo Peng wrote: Yes, I understand that we need to look up that information. But what I'm saying is that I want to use the EmbeddedFileList, which we're keeping in sync with the params, ONLY to look that information up if and when it's needed, and not use it in other ways. Yes, this is a minor

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

> I wasn't trying to argue. I was trying to collaborate. But you are so > protective of your code that you won't even let me fix the bugs YOU created. protective?? right. Note that your patch came before you understood how embedding works. > The example wasn't idle. Using a map in InsetBibtex

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

"Bo Peng" <[EMAIL PROTECTED]> writes: > It is lucky that you are not supposed to svn an embedded .lyx file. Actually, it is rather a shortcoming of the implementation. If we allowed for a osx bundle-like representation (which would just have to be zipped to be a proper embedded file), this could

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

> Actually, it is rather a shortcoming of the implementation. If we > allowed for a osx bundle-like representation (which would just have to > be zipped to be a proper embedded file), this could go seemlessly into > an svn archive. I understand this may not be doable immediately, but > it is

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

Jean-Marc Lasgouttes wrote: "Bo Peng" <[EMAIL PROTECTED]> writes: It is lucky that you are not supposed to svn an embedded .lyx file. Actually, it is rather a shortcoming of the implementation. As I say elsewhere, the current implementation can guarantee that the order of the

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

Bo Peng wrote: I wasn't trying to argue. I was trying to collaborate. But you are so protective of your code that you won't even let me fix the bugs YOU created. protective?? right. Note that your patch came before you understood how embedding works. That was several patches ago.

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

> You STILL don't understand the point. This isn't about > Buffer::embeddedFile(), which is what is used to save the zip file. It's > about the bibfilesCache_, which is a totally separate thing. I though that you are changing EmbeddedFileList from vector to map. This

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

Bo Peng wrote: Look, I want to make bibfilesCache_ a map. I have very good reasons to want to do this. I therefore want InsetBibtex::getBibFilesCache() to return such a map. (I suppose it could return something else, and then I could do some conversion, but why?) Back in InsetBibtex, I can

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

> > 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_

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

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

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

> > There are then some minor problems left, such as 1. In functions such > > as addDatabase, should we update params first and update > > EmbeddedFileList/Map; or another way around? > > > or encapsulate it in overridden setParam methods, so you can't forget to > do it. I disliked your

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

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,

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

Andre Poenitz wrote: > 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

Re: InsetBibtex Design Issue

On Sun, Mar 30, 2008 at 9:39 AM, Bo Peng [EMAIL PROTECTED] wrote: Well, that's my case. Bo, you want to state yours? Hi, Richard, Can we settle down on the meta_ solution, at least for now? This debate has lasted for a week and I do not see a clear end. Let us focus on bug fixing, and seek

Re: InsetBibtex Design Issue

Andre Poenitz wrote: On Sun, Mar 30, 2008 at 05:51:24AM -0400, rgheck wrote: The issue is not how the parameters are represented. The issue is *how an InsetCommand interacts with its parameters*. The design is that the parameters are stored in InsetCommandParams, and the inset interacts

Re: InsetBibtex Design Issue

Abdelrazak Younes wrote: No matter what he says I wonder whether the dispute is on the right level. I question I see is whether InsetCommandParams is the right thing to use (a) in this case, and (b) in general. Note that it original structure was just a convenient way to pass two or three data

Re: InsetBibtex Design Issue

Right, but as I said in the reply to Andre, my point was supposed to be just that we should have a simple, consistent interface. I don't myself care whether it is the current one or a new one, though it's an argument in favor of the current one that (a) it works just fine and (b)

Re: InsetBibtex Design Issue

Bo Peng wrote: Right, but as I said in the reply to Andre, my point was supposed to be just that we should have a simple, consistent interface. I don't myself care whether it is the current one or a new one, though it's an argument in favor of the current one that (a) it works just fine and

Re: InsetBibtex Design Issue

but as I have said, params is not enough to make InsetBibtex run smoothly, reconstructing EmbeddedFileList each time from param is likely to lead to crashes. But your original code DID reconstruct EmbeddedFileList: LFUN_INSET_MODIFY called createBibFiles(), which deleted the old

Re: InsetBibtex Design Issue

Bo Peng wrote: The issue is just whether, when we need to access the parameters, we should do so by looking at InsetCommandParams, which is the way most of the code works, or whether we should look at the EmbeddedFileList. As I have repeated several times, when we look at params, we do

Re: InsetBibtex Design Issue

Yes, I understand that we need to look up that information. But what I'm saying is that I want to use the EmbeddedFileList, which we're keeping in sync with the params, ONLY to look that information up if and when it's needed, and not use it in other ways. Yes, this is a minor dispute

Re: InsetBibtex Design Issue

On Sun, Mar 30, 2008 at 9:39 AM, Bo Peng <[EMAIL PROTECTED]> wrote: > > Well, that's my case. Bo, you want to state yours? Hi, Richard, Can we settle down on the meta_ solution, at least for now? This debate has lasted for a week and I do not see a clear end. Let us focus on bug fixing, and

Re: InsetBibtex Design Issue

Andre Poenitz wrote: On Sun, Mar 30, 2008 at 05:51:24AM -0400, rgheck wrote: The issue is not how the parameters are represented. The issue is *how an InsetCommand interacts with its parameters*. The design is that the parameters are stored in InsetCommandParams, and the inset interacts

Re: InsetBibtex Design Issue

Abdelrazak Younes wrote: No matter what he says I wonder whether the dispute is on the right level. I question I see is whether InsetCommandParams is the right thing to use (a) in this case, and (b) in general. Note that it original structure was just a convenient way to pass two or three data

Re: InsetBibtex Design Issue

> Right, but as I said in the reply to Andre, my point was supposed to be > just that we should have a simple, consistent interface. I don't myself > care whether it is the current one or a new one, though it's an argument > in favor of the current one that (a) it works just fine and (b) >

Re: InsetBibtex Design Issue

Bo Peng wrote: Right, but as I said in the reply to Andre, my point was supposed to be just that we should have a simple, consistent interface. I don't myself care whether it is the current one or a new one, though it's an argument in favor of the current one that (a) it works just fine and

Re: InsetBibtex Design Issue

> > but as I have said, > > params is not enough to make InsetBibtex run smoothly, reconstructing > > EmbeddedFileList each time from param is likely to lead to crashes. > > > > > But your original code DID reconstruct EmbeddedFileList: > LFUN_INSET_MODIFY called createBibFiles(), which

Re: InsetBibtex Design Issue

Bo Peng wrote: The issue is just whether, when we need to access the parameters, we should do so by looking at InsetCommandParams, which is the way most of the code works, or whether we should look at the EmbeddedFileList. As I have repeated several times, when we look at params, we do

Re: InsetBibtex Design Issue

> Yes, I understand that we need to look up that information. But what I'm > saying is that I want to use the EmbeddedFileList, which we're keeping > in sync with the params, ONLY to look that information up if and when > it's needed, and not use it in other ways. Yes, this is a minor dispute

InsetBibtex Design Issue

So, to get everyone up to speed, Bo and I disagree about a question concerning the design of InsetBibtex and, in particular, about how the parameters of the inset should be handled. The original code, written (I believe) by Georg back when the new InsetCommandParams structure was conceived,

Re: InsetBibtex Design Issue

On Sun, Mar 30, 2008 at 05:51:24AM -0400, rgheck wrote: So, to get everyone up to speed, Bo and I disagree about a question concerning the design of InsetBibtex and, in particular, about how the parameters of the inset should be handled. The original code, written (I believe) by Georg back

Re: InsetBibtex Design Issue

Andre Poenitz wrote: And right now I start to get the impression that we a close to one of our good old attempts to abstract where abstraction isn't called for. To play the devil's advocate: What would be wrong with virtual string InsetCommand::parametersToString() const; and virtual

Re: InsetBibtex Design Issue

Well, that's my case. Bo, you want to state yours? You have stated the problems clear enough. It seems to me that your solution will not work because params, by its nature, does not hold enough information to reconstruct EmbeddedFileList, so a lot of complexity will have to be introduced to

InsetBibtex Design Issue

So, to get everyone up to speed, Bo and I disagree about a question concerning the design of InsetBibtex and, in particular, about how the parameters of the inset should be handled. The original code, written (I believe) by Georg back when the new InsetCommandParams structure was conceived,

Re: InsetBibtex Design Issue

On Sun, Mar 30, 2008 at 05:51:24AM -0400, rgheck wrote: > > So, to get everyone up to speed, Bo and I disagree about a question > concerning the design of InsetBibtex and, in particular, about how the > parameters of the inset should be handled. The original code, written (I > believe) by Georg

Re: InsetBibtex Design Issue

Andre Poenitz wrote: And right now I start to get the impression that we a close to one of our good old attempts to abstract where abstraction isn't called for. To play the devil's advocate: What would be wrong with virtual string InsetCommand::parametersToString() const; and virtual

Re: InsetBibtex Design Issue

> Well, that's my case. Bo, you want to state yours? You have stated the problems clear enough. It seems to me that your solution will not work because params, by its nature, does not hold enough information to reconstruct EmbeddedFileList, so a lot of complexity will have to be introduced to