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

List:       kde-core-devel
Subject:    Re: Can we drop KWrite ?
From:       Simon Hausmann <sh () caldera ! de>
Date:       2001-03-13 15:38:43
[Download RAW message or body]

On Tue, Mar 13, 2001 at 01:24:16PM +0000, David Faure wrote:
> On Tuesday 13 March 2001 11:20, Simon Hausmann wrote:
> > On Tue, Mar 13, 2001 at 11:51:33AM +0100, Bernd Gehrmann wrote:
> > > On Tue, 13 Mar 2001, Simon Hausmann wrote:
> > > > What you describe is kparts? :-)
> > > 
> > > Except that kparts (more precisely, PartManager) 
> > > doesn't support multiple views of a document as 
> > > childs of the same toplevel window, because the 
> > > part activation is based on Part::widget(), 
> > > which does not exist in the case of multiple views 
> > > per document.
> >  
> > Oh, you can solve this by reimplementing KParts::Part::hitTest,
> > which was added for this very purpose (well, for koffice :)
> > You get a QWidget as argument and depend on whether it is a
> > view of your document you either return this, 0L or possibly
> > a reference to an embedded child document (one without widget
> > maybe, if using a non-widget embedding, like in koffice) .
> > 
> > I see your hidden point though :-) : We might want to provide a
> > class in KParts which one can use out-of-the-box for multiple
> > views, as reimplementing hitTest is not something really convenient.
> > 
> > Hm, looking at the source I see that you are right though when it
> > comes to non-mouse activation (read: focusin) . Here we in fact
> > use widget() .
> > 
> > David, what do you think about calling findPartFromWidget( w, QPoint( 0, 0 ) )
> > (or -1, -1 or something) here?
> 
> I'm glad you pointed out that this theorical "KDocument" class is exactly
> KParts::Part. It provides load, save, save as (all with network transparency),
> modified flag, etc. etc.
> 
> About FocusIn, hehe... it's always the one that caused us trouble ;-)

Hehe ;-)

> Hmm, why do you think that passing a dummy QPoint help here ?
> We'll call hitTest, but with bogus coordinates... and the app will have to
> reimplement hitTest - in a non-koffice environment this is a bit strange,
> since the QPoint doesn't matter, only the widget does.
> 
> So what about letting the app reimplement findPartFromWidget instead ?
> Argl, because it's private and non virtual. Ok, the ideal solution will have 
> to leave place to a more pragmatic one :(
> 
> Ok then, but hitTest should get a better documentation than "@internal" ;-)

Whoops, I'll add documentation :)

> Mention that the QPoint argument can be 0,0 in case of keyboard activation,
> and that apps should generally only care about the QWidget.
> 
> But isn't this going to break KOffice ? I don't know exactly how hitTest
> works in KOffice (but with 0,0 strange things will happen, no ?)

Hm, you're right, (0, 0) is probably not a sensible value for that. Hmm,
OTOH 0,0 has the advantage that we can utilize isNull() , which would
look good (or better than if ( blah = QPoint( -1, -1 ) ) ...) .

Hmrh mrhmmm, no, -1, -1 sounds better to me, as 0,0 could be a real value used
then the mouse is really at 0,0 (as relative coordinate) .


What do you think about having a class derived from Part (or ROP, or RWP) to
provide a default implementation of hitTest utilizing multiple views (and thus
having addView/removeView methods and the like) ?

Bye,
 Simon

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