Georg Baum wrote:
Abdelrazak Younes wrote:
- It is confusing that src/frontends/Gui.h defines lyx::Gui, and
src/frontends/qt3/Gui.h defines lyx::frontend::Gui.
But I asked multiple time if anyone had any objection (you also said
that it was fine with you ;-)).
At that time I did not see the practical implications, I only thought that
we had different namespaces (both in C++ and directory-wise), and that is
still OK with me.
Good.
What I also overlooked was the fact that src/frontends/Gui.h puts something
in lyx namespace, and src/frontends/qt3/Gui.h puts the same thing in
lyx::frontend namespace.
IMO, if Gui.h puts something in lyx namespace, it should go to src and not
to src/frontends. If it is wrong there then the namespace is wrong.
I think they are at a good place in frontends/ but I agree that the lyx
namespace is wrong. What about a new namespace in order to avoid
confusion? Multiple possibilities:
- gui
- gui_interface
- interface
- ui
- ui_communication
...
I followed Angus advice here I am
reluctant to go back again. I was thinking also to remove src/frontends
from the include patch in order to avoid problems.
Now that it is implemented I find it very clean: the kernel knows about
the interface classes. The frontend knows about the derived classes. In
principle (minus the include path problem) it should all be very clean.
That is clean indeed, but does not take into account the namespaces.
Right, see above.
- The existence of lyx::WorkArea and lyx::frontend::WorkArea does seems
to confuse compilers. I get a compile error in qt4/Application.C because
the wrong WorkArea.h is included.
I will check that.
I think it would help to always fully qualify the classes (at least in
header) files: lyx::WorkArea or lyx::frontend::WorkArea, not WorkArea. To
me it was not clear which one was meant to be used.
The rule says: What is the frontends/XXX/ shall use
frontends/XXX/WorkArea.[Ch] (so lyx::frontend::WorkArea). This was a
mistake from me.
It seems that MSvC and gcc disagree whether
I still use gcc here. I think the include path order is not the same
with scons and autotools. I thought that gcc would always give priority
to '.', wouldn't it?
If not, how can I modify the default include options for the frontend
compilation?
Relying on the include path order is fragile. I never do that in my own
projects, because I have been bitten by it too often already. The only
option IMHO is to remove src/frontends from the includepath everywhere.
Agreed. Will do that.
Yes. I think that's a good solution. The idea is that the core should
not know about the frontend, only about the interfaces. So we the only
potential problem could be in compiling the frontend.
Why should tgere be a problem?
I mean if you don't respect the rule and if frontends/ is in the include
path.
No, no, all your changes seem very reasonable. Please apply. So with the
patch, qt3, xforms and gtk performs like usual?
I don't know, I only compiled and did not test. BTW I won't be able to apply
during the next two days.
Do you wan't me to wait? It's OK for me. Not in a hurry.
Thanks,
Abdel.
