Georg Baum wrote:
Am Freitag, 10. November 2006 21:14 schrieb Abdelrazak Younes:
Georg Baum wrote:
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.
Wrong, the TocItem class was in toc.h.
I concedes that but that's all ;-)
No, you misunderstood me. I do not question at all your new code, but I do
question how it is organized. I do not understand why you needed to move
TocItem inside the class TocBackend, that makes it impossible to forward
declare it.
Because the plan is to move toc.[Ch] altogether. We can then rename
TocBackend to something else if you want.
I do neither understand why TocBackend is not in namespace toc.
Could be indeed. But we decided that we will only do lyx and
lyx::support and lyx::frontend from now on, didn't we?
I do neither understand why you define several types in TocBackend that
then get typedefed again in toc. If I use that code, when should I use
toc::TocItem, and when TocBackend::Item?
TocBackend. The typedefs are just there because of API compatibility
issue; see my other mail.
Basically the relationship between src/toc.[Ch] and src/TocBackend.[Ch] is
unclear to me.
I can understand that. I will clean that up; you motivated me. In any
case, the global static variable is not adapted at all in a multi-view
context.
In order to demonstrate what I mean I changed my patch so
that everything is now in one file. The code did not change at all, I only
moved stuff around so that I could break up the circular include loop. I
prefer one file, because all this code belongs together IMO, but one could
as well do it in two files and only do the namespace/class reorganizations
and move TocItem back to toc.[Ch].
Please wait, I will cleanup all this and you will see that it will be
easy to do what you want.
Abdel.
