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

List:       kopete-devel
Subject:    Re: [Kopete-devel] Metacontacts
From:       Martijn Klingens <klingens () kde ! org>
Date:       2002-06-25 14:15:51
[Download RAW message or body]

On Tuesday 25 June 2002 14:49, Duncan Mac-Vicar Prett wrote:
> But we are using it outside, you can already get a pointer to the object
> protocol having the spec string...

Pointers are unsafe if you want to use them in comparisons, which is exactly 
what I want. That's why I wanted to introduce a QString/QCString/char* to 
store some unique key.

> isnt there a way to pass parameters when loading a library?

Sure. But how would you ensure they are properly passed on when subclasses are 
created? How many QObject subclasses hardcode the 'parent' argument to 0L for 
example?

This can all be checked for in the KopeteProtocol constructor, to ensure 
uniqueness, so be my guest to implement it. All I want to propose is a way to 
avoid human errors and make it impossible to use incorrect values.

If I am going to code it, it will be something automateable. If you are doing 
it, I won't object to string passing when done right, but then you'll also 
have to write all error checking and handling. Your call ;-)

> Well, I agree with you more than 3 minutes ago, but I still think the
> specfile is something usefull

Sure. Having e.g. the pathname of the specfile in the KopeteProtocol (or 
better: KopetePlugin) class is a good idea.

Hmm... Maybe the key should not be handled at protocol level, but at plugin 
level? And make it a double key (PluginType, PluginName).

That would make something like

KopeteProtocol : public KopetePlugin
{
  KopeteProtocol( QString name )
  : KopetePlugin( "Protocol", name )
  { }
}

Even more complex than your proposal, but also the most extensible of all.

And it makes me wonder if Matthias Kretz' plugin loader stuff for KView 
already does a mapping of that kind between the name and type stored in the 
desktop file and a QPtrList, or at least a Plugin*.

Matthias, any idea? I think the above is a bit hard for you to understand, but 
before I explain everything please let me know what exactly you want to have 
clarified.

-- 
Martijn

_______________________________________________
Kopete-devel mailing list
Kopete-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kopete-devel
[prev in list] [next in list] [prev in thread] [next in thread]