Improving tabbar context menus

Andreas Pakulat apaku at gmx.de
Fri Sep 11 05:07:10 UTC 2009


On 11.09.09 01:48:15, Milian Wolff wrote:
> Hey guys!
> 
> First up: It looks like sublime/switcher.{cpp,h} is not used anywhere, can it 
> be removed? The container uses a KTabBar.

Thats the old combobox thing right? Yes, definetly a removal-candidate.
 
> Currently I just implemented the two features in the context menu that are 
> directly dependent on KTabBar features. Anything else I want to see in that 
> context menu is - as far as I can see it - not accessible to me:
> 
> A "new tab" feature would require something like
> ICore::self()->documentController()->openDocumentFromText(QString());
> But sublime is detached from kdevplatform, hence I could only link to that 
> from inside shell. Which leads us to the real problem:
> 
> How can I access the TabBar from inside shell? It's stored in a d-pointer of 
> the container... And other than that the container is created in the 
> mainwindow d-pointer of sublime, i.e. sublime/mainwindow_p.cpp:230

You don't. But what you could do is do what Kate or the KDirOperator
does: Emit a signal before showing the context menu and pass a pointer
to the menu as parameter. Then any interested client can connect to the
signal and add his actions. Eventually we might also need to pass in the
currently selected tab/url/document/... Not sure whats needed there
exactly.

> Or what about a generic signal that the container emits, lets call it 
> contextMenuRequested(QPointer globalPos, QWidget* widget);
> The widget would be the widget that the tab contains, i.e. the document in 
> most cases.

Exactly, plus you also want the menu to pass around, as I said above.

Andreas

-- 
You will gain money by a speculation or lottery.




More information about the KDevelop-devel mailing list