Why lazy initialization of Text Views breaks the context menu

[Andreas Pakulat]

Hi,

On Sat, Dec 15, 2012 at 3:29 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> Hi,
>
> I've been debugging the problem of why no context menu is shown on
> newly opened files or the one initially visible when delaying the kate
> view intialization using a queued-invocation. The reason is that
> apparently in these cases the xmlgui merging does not happen. In
> particular kate's view looks for a container in the top-most
> parentClient with the object name "ktexteditor_popup", see
> https://projects.kde.org/projects/kde/kde-baseapps/kate/repository/revisions/master/entry/part/view/kateview.cpp#L2680.
> When the initialization of the KateView is not done in the consturctor
> of TextEditorWidget this menu is not available, instead one only sees
> stuff from kdevelop's xmlgui file like:

I think I found the reason and I have a proof of concept for a fix.
The reason is that MainWindowPrivate::mergeView() adds the
newly-created XMLGUIClient from the TextView::createWidget to its
XMLGUIFactory and this code is being executed before the KateView has
been created when doing the creation lazily. This is useless for the
case of TextView/TextEditorWidget since the latter is not really an
XMLGUIClient it just subclasses it to fulfil the requirement of the
caller side (this is already bad API design but lets ignore that for
now). Once TextEditorWidget creates KateView it correctly adds it as a
child XMLGUIClient, but the factory never notices this since the
XMLGUI framework does not seem to have any kind of notification
mechanisms. So the fix is to delay the execution of mergeView until
the corresponding widget is initialized.

A quick hack/proof of concept can be found in the
wip/delay_view_initialization branch, it adds initialized signal and
API on top of Sublime View. I don't like this at all, but it seems to
work. I'm also not sure if this still fixes the problem that was
supposed to be fixed by lazily initializing the kate view, anybody can
fill me in on how to test that?

For a correct fix I think its needed that Sublime::View returns a new
class/interface from createWidget instead of a plain QWidget which
allows to be lazily initialized, at least that would better match what
is actually wanted here since the TextView instance is fully
initialized, just its widget is not yet done. Thoughts/Ideas?

Andreas