Improving generic KPart support in KDevelop (by example of Okteta)

[Andreas Pakulat]

On 05.08.09 17:55:56, Friedrich W. H. Kossebau wrote:
> Mercredi. le 5 août 2009, à 14:42, Friedrich W. H. Kossebau a écrit:
> > Mardi, le 4 août 2009, à 14:54, Andreas Pakulat a écrit:
> > > On 04.08.09 14:35:20, Friedrich W. H. Kossebau wrote:
> > > > Bug: Save/Revert for ReadWriteParts
> > > > -----------------------------------
> > > > Are there any reasons save/revert actions are not offered out of the
> > > > box for ReadWriteParts in KDevelop?
> > > > A KPart::ReadWritePart implements both a "save()" and a "saveAs(const
> > > > KUrl&)" method. So I would have expected that KDevelop itself sets up
> > > > these actions. But it doesn't. And it also doesn't include them in the
> > > > actions "Save All" and "Revert All". Not what is expected :)
> > >
> > > We don't support read/write parts currently, thats all. PartDocument
> > > would need to be extended to support both read/write as well as read-only
> > > parts.
> >
> > I will see what can be done. Looks like the basic infrastructure is all in
> > place, just needs some wiring up. But then I haven't yet looked under all
> > stones.
> 
> And the next stone I lifted showed me what stops ReadWriteParts in KDevelop:
> 
> While a PartDocument collects all KParts for the same url, there is no 
> guarantee that these KParts share the same data object, so a change in one 
> KPart would be synchronized with the others -> so on a save it is unclear 
> from what KPart to take the data to save back to the url.

I'm not sure what you mean here. We're creating a new part for each
widget (and hence each view) as far as I can see. So yes this poses the
problem of opening two views from the same URL and saving changes in one
and afterwards in the other. However thats something thats ok IMHO if we
really want read-write-parts in kdevelop. In worst case the user can go
to the first document again, do a small change, save, revert it and save
again. The KPart API doesn't allow anything else, unless you put a new
API on top of that (like the KTextEditor API).
 
> Solutions:
> a) make all but the first one readonly if it is a ReadWritePart
> b) allow only one ReadWritePart loaded per URL
> c) just skip any support for ReadWrite modus of KParts
> 
> I would go for option c), keeping the status-quo.

I'd opt for that too for now. We can easily change this later on if
there's demand for a read-write part and then worry about wether/how we
handle the above mentioned problem.

> It would just need a fix to 
> set any ReadWrite part to readonly, which isn't done currently. This would be 
> done by passing "KParts/ReadOnlyPart" to the factory as classname from 
> PartDocument. Should I try to prepare a patch which adds the classname as 
> optional argument to PartController::createPart( const KUrl& url ) ?

Hmm, how about doing it inside PartDocument itself by simply checking if
we can cast the KPart* to a ReadWritePart and then call
setReadWrite(false) on it before adding the part to the partcontroller?
That would allow to change our minds later on without having to carry on
the then-useless extra parameter...

Andreas

-- 
Your love life will be... interesting.