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

List:       kde-core-devel
Subject:    Re: Can we drop KWrite ?
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-03-13 13:24:16
[Download RAW message or body]

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 ;-)
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" ;-)
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 ?)

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://perso.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today

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