[Portland] Bonobo/KParts interoperability

Maxim Udushlivy maxim.udushlivy at gmail.com
Sat May 6 07:38:39 PDT 2006


Hi, Dmitry,
I'll try to show why I personally (and we all ;) need a shared component 
environment.

I work on a new GUI designer for GTK+ (Gideon, 
http://gideon.sourceforge.net). It is implemented as a widget in order 
to be easily embeddable into IDE's. Sounds good while we are inside GTK+ 
environment (Anjuta and MonoDevelop), but arises problems in other realms:
- Eclipse/gtk: embedding is probably possible via some SWT/GTK+ hacks
- Eclipse/windows: certainly even more hacks are needed (if possible)
- KDevelop: XEmbed with Qt/GTK+ hacks

Next problem: IDE's are written in different languages. What if I want 
to write a plugin for Eclipse in C#? Every IDE invents its own plugin 
system thus limiting its audience to one language/toolkit. New toolkit - 
new IDE. New language - new IDE. If the problem is not addressed we will 
have X*Y IDE's eventually, where X is a number of toolkits and Y is a 
number of languages :) (Wait, already have?!)

IDE problems are very important. IDE's will form the vision of new 
developers: not only how they program but how they treat other 
programming environments. By making development tools incompatible we 
stimulate unhealthy competition (toolkit vs toolkit, language vs 
language) and grow enemies. This is destructive for the future of the 
F/OSS community.

For example embedding Gideon (written in C++) into Eclipse I need to 
write a plugin in Java and an additional JNI library in C/C++ that 
actually links with gideon library. MonoDevelop situation is similar. 
And don't forget: all use different packaging and installation procedures.

Gideon itself needs a plugin system in order to extend its default 
widget set. Without a shared component environment Gideon is limited to 
GTK+ widgets written in C/C++. Mozilla, KDE and OpenOffice projects 
develop some valuable software components that are simply not accessible.

We must be brave and realize that toolkits and languages are tools for 
creating software components. These are the components that matter.

/Maxim

P.S. A question to anyone who knows the subject: is it possible to 
create an alternative KParts/DCOP  implementation using CORBA facilities 
(while preserving API for existing KDE applications)?



More information about the Portland mailing list