It is kind of working using QtHelp now. If you could take a look we can discuss later how do we want it to behave.<br><br>I know there are issues, but well, it is known that some polishing is needed.<br><br>For now i think that the most important things are:<br>
- Auto raise of the view when doc is requested.<br>- Add a menu action + shortcut to make it easily reachable.<br>- Let it be used like the context browser (the documentation shown depends on the cursor). Not sure about that one.<br>
- History<br>- Use QTextBrowser instead of webkit? :P<br>- ... anything<br><br>Thanks,<br>Aleix<br><br><div class="gmail_quote">On Sun, Feb 1, 2009 at 3:26 PM, David nolden <span dir="ltr"><<a href="mailto:david.nolden.kdevelop@art-master.de">david.nolden.kdevelop@art-master.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Am Sonntag 01 Februar 2009 15:12:12 schrieb Andreas Pakulat:<br>
<div class="Ih2E3d">> Maybe I'm misunderstanding how this widget would be used, but isn't this<br>
> simply embedded "standalone" into a toolview?<br>
</div>For example it might be put into a tab-widget at a specific position.<br>
<div class="Ih2E3d"><br>
> Or are you expecting to have multiple widgets from different doc plugins<br>
> visible at the same time? How are you imagining that to work?<br>
</div>For example tabs within the code-browser, but I don't really think about such<br>
stuff atm.<br>
<div class="Ih2E3d"><br>
> Even if the latter I don't see why the function should have the parent<br>
> member,<br>
</div>Exactly ;-)<br>
<div class="Ih2E3d"><br>
> it makes it a lot easier for doc-plugin writers to use the right<br>
> parent for whatever widget they want to return. They don't need to think<br>
> about wether they should use "0" or mainwindow or something else, they<br>
> can simply take what is given to them via the API.<br>
</div>It's just a redundant parameter, making the API less pretty. The user will<br>
probably anyway call QTabWidget::addTab, QLayout::addWidget or whatever on the<br>
result. Just defining that the caller owns the widget would be enough.<br>
<br>
I think redundancy is not pretty. Btw. DUContext::createNavigationWidget also<br>
doesn't take or need a parent paremeter(Talking about consistency).<br>
<br>
But, I don't really care about this, it was just a sidenote.<br>
<br>
Greetings, David<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
_______________________________________________<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
</div></div></blockquote></div><br>