Abdelrazak Younes wrote:
> Georg Baum wrote:
>> I strongly disagree. In case you don't remember what we did please reread
>> the old mails. There was a lot of testing, and the outcome was that some
>> internal qt structures rely on the fact that the QApplication variable is
>> created at the very beginning of main() and destroyed at the end of
>> main(). Since we cannot do that (or maybe we can - make main() a thin
>> wrapper and move it to the frontends) we have to workaround it.
>
> Look at the present code. That's exactly what I am doing.
No. main() is still in main.C. In case you mean the workaround: Yes, you do
it almost, apart from the destruction of the Application object.
>> The old workaround was
>> a plain variable that was sitting in a function. This did not work on
>> windows for reasons we where not able to figure out, so the static trick
>> was used there.
>
> I know exactly the reason why it didn't work. That was because the
> QApplication creation was local to the lyx_gui::exec() function thus in
> principle invisible to the exec2() function; Qt structure make this
> instance visible even though part of it was still visible.
I don't understand the last sentence. Should I replace the first or the
second "visible" with "invisible"?
> The static
> trick made the QApplication instance persistent accross the lyx
> structure, that's all. Now that I moved the exec2() function out or
> lyx_gui, the LyX class can safely access this instance without being
> affraid that it disappeared.
The old code on non-windows that did not work on windows was:
lyx_gui::exec() {
// 1) create QApplication
// 2) call LyX::ref().exec2()
// 3) destroy QApplication
}
Therefore it was guaranteed that the QApplication object was valid during
the call of exec2.
The problem on windows was that 3) lead to some infinite loop/crash (I don't
remember which).
Your explanation above does not match this code.
>> Now you create the variable at the right time, but destruction is wrong.
>
> I think this is due to how we manage server and sockets. There's
> something fishy in there and I will fix it. If you look at the recent
> change, WRT linux, the only thing I did is to encapsulate the
> Application instance inside a scoped_ptr. It is weird that this simple
> change causes the crashes you are having on exit.
It is not weird at all. Destruction happens now from a destructor of the
static LyX singleton. Before it happend at the end of exec2.
>> I am sure that you will need the static thing again on windows if you fix
>> destruction time.
>
> I am sure of the opposite.
We will see.
>> I don't care at all about the old code, but I do care a lot about the
>> testing that was done and the results. Everybody loves clean code, but
>> working code is even more important. I prefer code that is a bit clumsy,
>> but works, a lot over code that is clean, but does only work partially.
>> And if new features require some reorganization, then it should be done
>> completely.
>
> Who said that I will not do it? Not me. I am just saying that at last
> resort, much before release time, I will revert to the old solution if
> it didn't work out.
This commit with only a short notification before in the context of your
recentr changes looked to me as if you where rushing through and where not
aware of any potential problems.
>> Please explain. AFAIK it was working.
>
> Not entirely. Every little exception or crash induced the infinite
> killtimer loop. It was very, very annoying to work under these conditions.
I did not know that.
> Once I put my multiple view support (which is already done). I will
> tackle that problem.
Thanks.
Georg
