Jürgen Spitzmüller wrote >Helge Hafting wrote: >> In this particular case, it looks like no extra GUI is needed at all, >> only programming. The GUI is present already: >> >> Currently, the running header paragraph types becomes available when the >> user selects the module. All we need then, is to remove the module >> from the module list, and tie it to "headings style == fancy" instead. > >IMHO, the header definition should not be done with paragraph styles (as the >module does), but rather in the document dialog.
Paragraph styles more flexible - because the user may want to change the running headers throughout the document. You don't get that with a definition in the document dialog. For example - different running headers in different parts, or blank headers in the preface. Also, the paragraph style (or a flex inset, if that is deemed better) automatically gives the user access to anything that LytX support. Want a logo or two? Insert->Graphics. An URL or even math? Simple. A weird latex construct? Possible if you want it. >Many people want automatic >headers (running headers), not some hardcoded strings. I do not think this can >be achieved elegantly with the paragraph style based approach. Furthermore, we Do you mean things like page numbers and \leftmark, \rightmark? Currently ERT, but insets for these shouldn't be hard to make. >should provide some customization possibilites. Also something we need the >dialog for. >Then, we should consider class specific issues (classes such as KOMA and >memoir ship their own header interfaces that should be used instead of >fancyhdr). I agree - fancyhdr is just one part of this. > >> For other cases, it seems that LyX is moving tovards modules so powerful >> that a lot of things might not need any other GUI. > >I really hope you're wrong. Seems I wrote that too fast. To be precise - styles are getting more powerful. And they can be used by modules and/or the core styles distributed with LyX. Any LaTeX command/environment that takes exactly one parameter - the text inside it - can already be implemented as a style. So there seem to be less need for separate code supporting "footnote" and similiar things. There seems to be work on styles that take arguments, that would allow more things to be specified as a style, for example things like boxes. Whether to separate such things out in modules or not is a separate question. Things go in a module if it isn't natural to have it available for every document of the same class. Otherwise, it'll be part of the document class. Possibly shared with other document classes through the include mechanism. Helge Hafting
