rgheck wrote:
> I think this is a different issue. If someone wants to Require a package
> we don't have listed in LaTeXFeatures, then, yes, we can't check for it,
> and so we ought to ignore it for that purpose. But that's different from
> saying they can't Require such a package at all. Actually, I'm not sure
> how this will work in practice, anyway. What does happen if I try to
> "Require foo"? Surely there's some fairly simple way to handle this.
> (Unfortunately, I have to go deal with graduate admissions applications
> and can't play with LyX right now.)

No, there's no simple way yet. For the moment, people can only require what is 
known to LyX (note that also the isAvailable() mechanism depends on this).
If not, they will have to use the Preamble tag with all the disadvantages.

What we can do, eventually, is to simply add a \usepackage call with all 
remaining "unknown" required packages at the very end. For this, though, we 
need to know which packages we know. And this is not possible yet (since it's 
done in different methods).

What I would prefer to the above, though, is a proper package manager.

For now, I'd just go with what I proposed.

> > Secondly, it seems like we ought for the same reason to have a Requires
> >
> > > tag in the TextClass itself.
> >
> >  
> >
> > done. Patch attached. I think we can get rid of the ugly optional
> > argument of DeclareLyXModule now. 
>
> OK, well, it's about to get new ones, anyway, so don't bother with
> configure.py. (It won't break right now, anyway.) I intend to implement
> Requires and Excludes arguments for the modules themselves as part of
> the modularization of the AMS classes. Thus, the "Theorems" module will
> exclude the "Theorems (AMS)" module, and it won't be possible to use
> them both. I also want to split the theorem modules themselves into
> basic and advanced parts, so that you don't have to overpopulate your
> layout box just to get the basic theorem constructs. Thus, "Theorems
> (Extra)" will require either "Theorems" or "Theorems (AMS)", since the
> basic definitions have to be in place already. I expect we'll find other
> uses for this, too.

I'm not sure I understand. Anyway, I'll leave the optional argument in place 
for now.

Jürgen

Reply via email to