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

List:       kdevelop-devel
Subject:    Re: Improving generic KPart support in KDevelop (by example of Okteta)
From:       "Friedrich W. H. Kossebau" <kossebau () kde ! org>
Date:       2009-08-05 15:55:56
Message-ID: 200908051755.57333.kossebau () kde ! org
[Download RAW message or body]

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.

In fact, most non-Kate KParts have their own data copy per view, as there is 
no MVC in the KParts design (one of the reasons why I started the Kasten 
framework BTW).

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. 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 ) ?

Cheers
Friedrich
-- 
Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta

_______________________________________________
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel

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