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

[Andreas Pakulat]

On 06.08.09 00:05:22, Friedrich W. H. Kossebau wrote:
> 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.

hmm, that might work yes. But of course we'd need to add that to all parts
in trunk/KDE at least...
 
> 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 ;)

Well, so far we're not guaranteeing any BC for our own code and creating a
new interface is BC too. Fortunately KPart's are dlopen'ed and as such
don't fall into the "have-to-keep-BC" category.

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

No I don't know, I didn't have too much contact with KParts so far, in
particular I don't know about such differences in behaviour between
readwrite and readonly parts..

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

I'll have to dig into the source to know for sure, but IMHO this should be
exactly the same as if I do a setReadWrite(false) on the readwrite part. It
can still remove actions from its collection at that point or simply use a
different xmlgui rc file. We're only adding it to the factory after that
call.

> Users angry about actions visible but unaccessable might be more pain than a 
> perhaps useless parameter?

Yes, if setReadWrite doesn't work as we'd like it then thats better indeed.

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

Yeah, we've had a similar runtime-dep in kdev3 on khexedit for using its
memoryviewer. If we can avoid a compile time dep that would be great, but
its not a big deal if we cannot.

Andreas 

-- 
Living your life is a task so difficult, it has never been attempted before.