[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