On Wed, 21 Aug 2002, Martin Vermeer wrote: > On Wed, Aug 21, 2002 at 06:25:32PM +0200, Lars Gullik Bjønnes wrote: > > > Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > > ... > > > | Martin> Sorry, I give up. If it's only as little as 10%, and you > > | Martin> actually know how to, why don't *you* do it? > > | > > | Don't pay too much attention to what Allan says. Nobody does :)
Thanks JMarc you really know how to make a fellow feel welcome ;-) > Actually I think he is right... only I don't think it is nearly as easy > as he implies. The first 90% takes 90% of the time and the last 10% takes the remaining 90% of the time.... Something like that perhaps? > And my C++ skills being what they are, see my tail droop. How can you say this after all you've done so far with counters and this inset? You've come a long way in the last a few months and said similar things along the way only to prove yourself capable. > I'd *love* him to take up the challenge... I'd love to accept but at present I barely have time to keep up with emails let alone some simple cleanups of the code that I know needs doing. It doesn't help that I don't have room on my drive anymore for two compiled trees. > > I won't say "no", but I do agree with Allan. > > > > I really think that a proper InsetSectioning is the right way to go, > > Perhaps... but don't you thinks it's too heavy guns? I kind of like the > \layout Section, but somehow we should get a *clean* way of having an > inset hardwired to the start of a paragraph (and yes, it ought to have > been the section number... I just didn't manage that. Allan if you do, > I would love to see it.) I will have to update my devel tree (for the first time this month) and find your patches (and read them and try them -- so I've been relying on screenshots and others feedback) > A dirty fix for now would be to put code on the menu emitting a sequence > "begin-paragraph; option-insert;" (pseudocode). Not so nice. > > but I also realize that we will not be able to get anyone to do that > > work now. So I will go with the patch "as-is". Sure we might get some > > compability problems later, but we have handled a lot more severe > > compability stuff earlier (pextra stuff.../ ert ...) Trouble is we make it even more complicated by having to filter an arbitrary number of these things out of a paragraph and rewrite the paragraph with all these moved into some new structure. > > On a side one... one of the huge problems with LyXText today is all > > the hardcoded "labels", to be able to generalize that code at put it > > into layout files would be really, really great. > > Hmmm tell me about it :-( Well if we are going to have to clean this stuff up anyway as a very rough first approximation we could switch the hardcoded labels into hardcoded insertions of a InsetBizzo which contains a counter and as many InsetOptArgs as specified by Lars' suggested OptArguments layout parameter. This falls short of the much desired InsetSection (which allows for simple outlining) but shouldn't be too hard to create. Environments are a lot harder to provide opt args for than commands so don't worry too much about them for now. It should be possible to reuse InsetBizzo for other things that use counters and take opt args like enumerated list items. An InsetBizzo2 that displays a small pixmap could be used for itemized list items for a more WYSIWYG bullet point and so on... But I'm getting ahead of myself. The first step that could start the cleanup is to create a fairly simple inset that contains a fixed number of opt arg insets (InsetOptArgContainer(layout.OptArgsCount) for example) -- and then make the hardcoded section labelling insert one of these of the appropriate size at the head of the label. No insertions or deletions allowed in the container only editing of the individual InsetOptArgs. As work progresses then the section counter³ and InsetSection² can be added¹ cleaning up LyXText but with minimal problems for future conversions and allowing a stable version to be released at almost anytime. Note that my plan doesn't allow opt args to be available for everything at once. This is deliberate. It should be impossible for a user to insert an InsetOptArg or even insert an InsetOptArgContainer. These are constructed as the document is read in. They needn't always be visible -- empty opt args can exist and be invisible ¹ Deciding when an inset section begins and ends in a document marked up with "\layout Section" etc. really needs a table of layout hierarchy (a DTD of sorts really) which would also help when switching layouts. I'm sure we've all read those threads before. However, we then wouldn't really need to change the document format... ² InsetSection can then contain an InsetCounter, an InsetOptArgsContainer and an InsetText (to hold the paragraphs). Again no insertions or deletions in this container, just editing of whats in the insets it contains. ³ We could also use the InsetCounters hard-coded until the InsetSection is completed. So that's three steps. The InsetSection left for last as it can be used to replace the hard-coding in LyXText but that could be done in 1.4.0 or even 1.5.0 (one step per release). Whatever happens we shouldn't try to offer opt args for everything at once -- commands should be okay but environments will be a tiny bit trickier since they don't generally don't have a screen presense so the problem there will be one more of the UI variety than coding. Anyway, the main things people seem to want opt args for is short titles for things so just target that for now but with an eye to the future. Allan. (ARRae)
