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

[Friedrich W. H. Kossebau]

Mercredi, le 5 août 2009, à 21:53, Andreas Pakulat a écrit:
> On 05.08.09 17:55:56, Friedrich W. H. Kossebau wrote:
> > 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).

Yes, that's what I meant.

I wonder if the average user will welcome a  behaviour where all non-text 
documents have to be treated differently. I fear it just calls for accidents 
if the same file can be loaded/edited several times in the same program, 
especially if you have multiple tabs open and hardly an overview which tab is 
which.

IMHO KParts are simply failing here. KDev* classes/plugins are needed.
Or wait, there is the solution that was done for Konqueror with the 
Browser/Extension service type. There could be a type Editor/Extension 
(better name perhaps) derived from KPart/ReadWritePart, which would have 
support for a shared data/document object system per URL.

Ideally a solution would be as reusable as possible, so other IDE frameworks 
might be able to pick it up, too, even if Sublime/KDevelop is as great as it 
is ;) But as there is no other IDE to test the API and all solutions need new 
code the KDev* classes/plugins might be the best way for now. There is always 
KDE5 ;)

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

Because this is going to be a public API? Hm.
Just, until then the users may wonder why they see all the modification 
actions in the menu but can't use them. Because, as you might know, the 
classname parameter that is passed to the factory is used to tell the KPart 
how it is going to be used. And by this information it at least sets up it's 
actions and properties (e.g. as KPart/ReadOnlyPart all modifying actions are 
dropped, some use even a different ui.rc file).
Users angry about actions visible but unaccessable might be more pain than a 
perhaps useless parameter?

So far my 2 cents. :)

I am now rather going to do the Okteta extension for KDevelop by using the 
KDev* classes, as proposed, in one of the next weeks. A disadvantage is the 
dependencies both on kdeutils and kdevplatform, but that might be solved as 
for the Kompare stuff.

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