Georg Baum wrote:
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
"Georg" == Georg Baum
<[EMAIL PROTECTED]>
writes:
Georg> It is already ugly, adding one more special test to 3 existing
Georg> ones is only a little bit uglier :-)
FYI, most of the ugliness was due to the support of qt3 and gtk (I
didn't want to break the toc controller at the time). Now that these are
out, I guess there's some code that can go.
Above I was talking about the code that calls the addtoToc methods of those
insets that have one. The uglyness of that code has nothing to do with
frontends, but with the fact that addToToc is no virtual method of
InsetBase.
I guess that you answered to my earlier statement that toc.h and
TocBackend.h are not exactly clean, but even that has nothing to do with
frontends. ControlToc and the frontends know about toc::TocIterator,
toc::TocItem and toc::Toc. The frontends have nothing to do with the
strange interweaving of toc and TocBackend. Basically I don't understand
why we need a TocBackend at all. 1.4 (with 3 frontends) does not need it.
Why was it not possible to extend the classes in toc.h with the new
functionality?
Because there was no class in toc.h, only global functions that were
called each time the navigate menu or an item of Toc dialog was clicked.
The Toc list was recreated on each update of the menu or the Toc
dialog and that was slow on windows. Thanks to the TocBackend you now
have synchronised Toc dialog and document contents. Try it.
toc.h is just there to keep the interface with MenuBackend. I didn't
feel like cleaning this at the time. I may have cleaned up ControlToc at
the time, I don't remember.
Now, it you tell me that you prefer 1.4 toc.h over 1.5 TocBackend I
don't understand anything.
The TocBackend as well as the different updateLabels() functions should
disappear once we tracks labels correctly on paragraph
creation/deletion. I have planned to do that when I get some time.
Abdel.
