[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KPanel plug-ins...
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       1998-08-06 20:41:57
[Download RAW message or body]

   Hi!

On Thu, Aug 06, 1998 at 03:07:20PM +0000, Pietro Iglio wrote:
> > [... can the mico shlibs extension be used to enhance kpanel with
> >  a KPanelExtension interface ... ? ]
> 
> I agree with your proposal. You can use MICO to dynamically load C++
> shared libraries in the same address space of the client program.

Although I have not directly proposed that ;) ... this solution seems
the easiest and best, as far as I can see.

> The problem is the lack of a binary compatibility standard in the UNIX
> world
> (using MICO this way wouldn't solve the problem). If the plugin and
> KPanel are
> compiled with different C++ compiler, things don't work due to different
> name mangling.
> Until egcs, linux users were not really aware of this, as the gcc was
> the standard
> C++ compiler. Now you are in troubles if you mix code compiled with
> gcc and egcs (e.g. type info not found at linking time, etc.)
> 
> On other UNIX platforms using a compiler other than gcc is usual.
> 
> Therefore some possible solutions for KDE (not just KPanel) plugins are:
> 
> - we always use CORBA/MICO with out-of-process objects -> low
> performance;
> - we use a C interface for plugins -> no OO approach, fast, C++ objects
> cannot be
> 	exchanged b/ween client and plugins.
> - we define a binary compatibility standard (similar to M$ OLE) and
> modify MICO
>   to support it;
> - (the easy solution) we define a reference C++ compiler for each
> platform on 
>   which KDE runs: users can use other compilers, if they want, but
> binaries and
>   plugins will not probably work in this case (users have to recompile).
> 
> Probably the last one is the more reasonable short-term solution. 
> If KDE wants to reach non expert users, we must find a way to provide 
> binaries ready to use, without runtime linking problems and similar.

Sure, but I think the problem is not only mico-shlibs specific.

Even if you would use out-of-process - objects, the plugins would still
be linked to the mico-libraries (and most likely qt, kdecore kdeui and
some other libs). So if you want to use plugin 1 and 2, which have been
compiled with the compilers A and B, you need

  - statically linked plugins (which is overkill!)

  - one version of the mico(/qt/kde) libs compiled with compiler A
    and one version compiled with compiler B

  - plain C plugins, which do not directly access C++ libs in any
    way, that means they may not even create or modify any QString/
	QObject/QWidget

So I think there is no way to avoid that your linux installation is
consistent.

It would be good if we could offer an easy way for distributors to
create (automatically) all binaries of all kde programs and extensions.
Then the users could get the appropriate binaries from their linux
distributor.

   Cu... Stefan

PS: On the Gnome lists currently is a thread that they plan to start
  an object model like M$'s from scratch and will implement something
  like OLE. I don't know whether this could help us to solve the
  problems you mention.
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-

[prev in list] [next in list] [prev in thread] [next in thread]