RFC: editor part restriction

Jens Dagerbo jens.dagerbo at swipnet.se
Thu Mar 11 20:49:03 UTC 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Abstract: I suggest restricting KDevelop to only allow one type of editorpart 
loaded at one time.


It might not be immeditely obvious, but KDevelop currently allows the user to 
have more than one type of editorpart loaded at one time. 

This has the following drawbacks:

#1. Editorpart instantiation is slower than it needs to be.

Every call to PartController::editDocument() that is a request to open a 
previously not open document will:

* look up the "what editor to use" setting
* query the KTrader for corresponding parts
* load the corresponding factory
* instantiate the part

This isn't a particularly slow process, but for almost 100% of the cases, all 
steps except the last are unnecessary. When a project is loaded, and we open 
up a dozen files at the same time, all this extra work is noticeable - at 
least on old systems.


#2. We spend an awful lot of code and effort to make absolutely sure the 
interface we just used for that other editorpart is actually available for 
this one too. 

If we disallow the simultaneous usage of multiple editor types we could get 
rid of all those dynamic_cast() tests, and maybe finally devise a wrapper 
type (hopefully in tandem with a proper "document manager") to do the 
necessary interface resolution for us in one place, instead of forcing it 
into the "client code" like we do now.

We could add a test to the editorpart chooser process, where all the editor 
interfaces we depend on are queried. If the editor doesn't fullfill the 
"KDevelop editor contract", we don't allow it's usage in KDevelop. This way 
we can do the testing once, and once only.


Benefits of current system:

Um.. I dunno, to be honest. Geek value?


I have an improvment to #1 already implemented on my system, along with a few 
other speedups, cleanups and (I hope) improvments to the mimetype detection, 
and I promise to work on #2 if it becomes possible.. :)

So, what do you say, anyone against?

jd



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAUMKS6meJzsUuplQRAqliAJkBOTj5gi5q82OR3C/so5KABIy7JACfZqow
s7Q02Y+U8g6vls2ArYiWOPA=
=r8vy
-----END PGP SIGNATURE-----




More information about the KDevelop-devel mailing list