[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kdewebkit moved to kdereview
From:       "Dawit A." <adawit () kde ! org>
Date:       2009-10-29 18:37:38
Message-ID: 200910291437.38245.adawit () kde ! org
[Download RAW message or body]

On Thursday 29 October 2009 12:55:45 Aaron J. Seigo wrote:
> On October 29, 2009, Dawit A. wrote:
> > On Wednesday 28 October 2009 10:07:55 Marco Martin wrote:
> > > On Wednesday 28 October 2009, Dawit A. wrote:
> > > > On Tuesday 27 October 2009 22:02:10 Chani wrote:
> > > > > > > i ask because there is now a QGraphicsWebView included with
> > > > > > > QtWebkit which Plasma eventually will be using instead of our
> > > > > > > own QWebPage-behind-a- QGraphicsWidget implementation that we
> > > > > > > currently use; being able to set the KWebPage on a
> > > > > > > QGraphicsWebView and get everything, including KWallet
> > > > > > > integration, would be optimal.
> > > > > >
> > > > > > That is exactly the kind of thing KWebPage is actually designed
> > > > > > to solve. You use it in place of its Qt counter part to get all
> > > > > > of the KDE integration for free...
> > > > >
> > > > > yes but in plasma we need a *graphics*widget, not a widget. are you
> > > > > going to provide that?
> > > >
> > > > Well if you mean are we going to provide a KDE re-implementaion of
> > > > QGraphicsWebView, then there is no plan to do that at this point.
> > >
> > > nope, because we can't use a QWidget at all, too overhead for a thing
> > > like that
> >
> > Unlike QWebView QGraphicsWebView inherits from QGraphicsWidget not
> >  QWidget...
> 
> i think you're both saying the same thing. regardless, i think we really
>  ought to have a KGraphicsWebView subclass of QGrahpicsWebView that is an
>  analog for KWebView. this will make it easier to track changes in KWebKit.
>  if you're cool with that, i'd be happy to add such a thing to KWebKit. it
>  would include the same add-on features as in KWebView:
> 
> * consistent mouse button keyboard modifiers
> 
> * external content access control
> 
> in fact, i'd probably put all the logic for this in a share private class
>  and then have the private classes subclass from that. this would prevent
>  code duplication from creeping in over time.
> 
> would you be cool with that? (i'm already nearly done, hoping you'll say
>  yes, in fact ;)

Great... Please go ahead and add that...

[prev in list] [next in list] [prev in thread] [next in thread]