on documentation

[Aleix Pol]

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.

I know there are issues, but well, it is known that some polishing is
needed.

For now i think that the most important things are:
- Auto raise of the view when doc is requested.
- Add a menu action + shortcut to make it easily reachable.
- Let it be used like the context browser (the documentation shown depends
on the cursor). Not sure about that one.
- History
- Use QTextBrowser instead of webkit? :P
- ... anything

Thanks,
Aleix

On Sun, Feb 1, 2009 at 3:26 PM, David nolden <
david.nolden.kdevelop at art-master.de> wrote:

> Am Sonntag 01 Februar 2009 15:12:12 schrieb Andreas Pakulat:
> > Maybe I'm misunderstanding how this widget would be used, but isn't this
> > simply embedded "standalone" into a toolview?
> For example it might be put into a tab-widget at a specific position.
>
> > Or are you expecting to have multiple widgets from different doc plugins
> > visible at the same time? How are you imagining that to work?
> For example tabs within the code-browser, but I don't really think about
> such
> stuff atm.
>
> > Even if the latter I don't see why the function should have the parent
> > member,
> Exactly ;-)
>
> > it makes it a lot easier for doc-plugin writers to use the right
> > parent for whatever widget they want to return. They don't need to think
> > about wether they should use "0" or mainwindow or something else, they
> > can simply take what is given to them via the API.
> It's just a redundant parameter, making the API less pretty. The user will
> probably anyway call QTabWidget::addTab, QLayout::addWidget or whatever on
> the
> result. Just defining that the caller owns the widget would be enough.
>
> I think redundancy is not pretty. Btw. DUContext::createNavigationWidget
> also
> doesn't take or need a parent paremeter(Talking about consistency).
>
> But, I don't really care about this, it was just a sidenote.
>
> Greetings, David
>
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090202/6a9e6842/attachment.html>