From kdevelop-devel Thu Aug 06 10:15:50 2009 From: Andreas Pakulat Date: Thu, 06 Aug 2009 10:15:50 +0000 To: kdevelop-devel Subject: Re: Improving generic KPart support in KDevelop (by example of Okteta) Message-Id: <20090806101550.GC25780 () neo ! apaku ! dnsalias ! org> X-MARC-Message: https://marc.info/?l=kdevelop-devel&m=124955425211673 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. _______________________________________________ KDevelop-devel mailing list KDevelop-devel@kdevelop.org https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel