On Mon, Aug 13, 2007 at 01:18:52AM -0400, Richard Heck wrote:
>  Martin Vermeer wrote:
> > The attached patch is the beginning of trying to make the
> > insets as configurable through the layout files as currently
> > paragrapshs are. It tries to more generally do what only
> > CharStyles are doing now. So Richard won't have to abuse CS
> > in the future...
> >
> > The idea is that this will in the long run replace the
> > CS functionality. Currently only foot- and marginal notes
> > and note insets are done, sort-of. It's only a demonstration of princple 
> > offered here for review, but once in, it can be
> > easily extended.
> >   
>  I've studied this a bit, and I think I understand where it's supposed to be 
>  going. I'm still not sure if it's trying to do what I was trying to do 
>  before, or if it's more or less orthogonal to that. So let me say what I was 
>  trying to do.
> 
>  Here's what I wanted to do: Make it possible for USERS to define collapsable 
>  insets, just as USERS can now define inline insets---which we call character 
>  styles and modify a bit from their most basic form. (I think it'd also be 
>  great for users to be able to define command insets, though this poses 
>  somewhat different issues.) So far as I can see, what's here doesn't do 
>  this, or really move us much in that direction---at least so far. Maybe it's 
>  intended to do so, though, and I'm missing the application. Otherwise, I'm 
>  not sure why LatexName is being defined in these InsetLayouts. It doesn't 
>  seem to be used anywhere in the code.

Not yet, yes.
 
>  That said, even if this doesn't help with my problem, it's still very 
>  useful: Users can now customize the appearance of the predefined insets. And 
>  the patch looks good to me, in general. One question, though: What happens 
>  if no InsetLayout has been defined for Foot? Then it seems we're calling 
>  getLayout() for an undefined key.

Then the button label will be empty (should be an error message)and the other 
attributes some default values, probably ;-)

> > Lots of help from Jean-Marc on this.
> >   
>  You, too, eh?
> 
>  Regarding what I wanted, here's what seems to me a plausible plan:
> 
>  1. Derive InsetCollapsableCustom as a subclass of InsetCollapsable. This 
>  will do all the general "customized inset" stuff shared between 
>  InsetCharStyle and the new thing: e.g, setDefined() and the like would 
>  appear here. Then InsetCharStyle could inherit from this, too. Another 
>  option would be to make InsetCustom a mixin, so that some of this could be 
>  used by a hypothetical InsetCommandCustom.

Thanks, InsetCustom sounds good.
My plan was to modify InsetCharStyle to InsetCustom. Then,
some of the custom insets may have an attribute that defines
them as being actually charstyles. (The menu system may put
these in a different place).

Note that currently a charstyle object may contain
an instance of layout_ (from collapsable) and a charstyle
parameters type member param_, containing pretty much the
same stuff. I wss planning to move over everything to layout_.
Not quite clear on the details though.

You would then have a user defined inset Custom:Endnote
with attribute CharStyle false. No C++ required.

>  2. Other modifications:
>  *TextClass will need a list of customized collapsable insets, which now 
>  would be defined not using CharStyle but in some other way, say, via: 
>  InsetCollapsable. These will be read in read(), of course.
>  *MenuBackend will have a routine to add the defined Collapsible inset to the 
>  menu, and their location will be set in stdmenus.inc, as usual, we'll need a 
>  "CollapsableInsets" menu entry, with corresponding changes in read(). We 
>  will also need something similar to expandCharStyleInsert(), and will need a 
>  similar bit in expand(). Need to add something to MenuItem, in 
>  MenuBackend.h, as well.
>  *LaTeXFeatures::getTClassPreamble(): needs a corresponding bit for these 
>  things.
>  *Need a new LFUN instead of LFUN_CHARSTYLE_INSERT, so this involves changes 
>  to factory.cpp, lfuns.h, LyXAction.cpp, Text3.cpp, insets/InsetERT.cpp, and 
>  insets/InsetTabular.cpp: Basically, we can mirror a lot of what happens with 
>  CharStyles in these files.
> 
>  Comments on the plan?
> 
>  Richard

Yes, I want those things too, but without almost duplicating
CharStyle. We should have predefined and (generic) user
defined insets being configurable through the same mechanism.

Perhaps button-style insets also by the same mechanism, though
they are rather different.

I hope to get this into a state during or shortly after the
meeting where others can build on it.

Regards Martin

Reply via email to