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 nee
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
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 an
> 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 Embe
> > 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 fil
"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
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
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 finis
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, mor
> > 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 impl
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 bibfile
> > 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_ bu
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
> 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 will of
course change buffe
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. God
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 em
> 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 s
"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
> 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
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
> 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
>
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
> > 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 dele
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 (
> 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-
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 i
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 with
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
> 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 mak
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
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
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, h
32 matches
Mail list logo
