Auto-closing all "clone X-Chat" wishes.

It was just a suggestion based on my experience writing plugins for various clients so far. You needn't attack my suggestions just because I happen to like certain API decisions made in X-Chat.

Konversation is the only major IRC client I know which lacks a plugin system. I'm all for individuality, but already we have enough "That lack of features is a feature" from the GNOME devs.

I'm just unhappy that has_GUI && uses_KDE && has_comfy_features = True but that && has_plugin_API = False.

> You needn't attack my suggestions just because I happen to like certain API decisions made in X-Chat. 

Then file a proper, useful report that argues for those API decisions on their own merit instead of filing a "clone X-Chat" along with the much-beloved "if you don't implement my pet feature, I'll stick to your competitor" routine. 

Quite frankly, the lack of a plugin API is an obvious enough omission in the application that we can afford not to rely on bug reports of that quality to track the issue of implementing one.

Fair enough, though to be honest, I didn't realize my suggestion could be mis-interpreted as a threat, no matter how mild. That's one of the dangers of reporting while sleep-deprived.

I'll file a thorough report, but it may take a while. When I argue in favor of things, I go into persuasive essay mode and I can't really spare the time for that right now... especially since in this case, I'd probably end up researching every IRC plugin API in existence and then proposing a complete design for the proposed Konversation plugin API, including point-by-point pros and cons.

That sounds great, though - that's definitely something we'd be very interested in.

I agree, I just have a bit of a history of failing courses because I did something more fun (like writing proposals for plugin APIs) instead... so I don't want to take the chance until I'm ahead in my courses, and that could take a month or two.

I was going to code a Blowfish encryption plugin for Konversation. But now I suddenly realize that Konversation doesn't have a plugin API (yet)! I'm not really looking forward to change the Konversation code itself though. A plugin system would be more flexible.

So because of this... I will help where I can. I might start writing a simple plugin API (based on the XChat plugin API) ... If anyone cares to help me, please do, because I'm not too advanced in C++ just yet.

But let's just start by lining out a simple plugin API. Because quality code requires quality analysis before a single line of code is written.

PS: This obviously isn't really the right way to talk about this new specification for Konversation. Can someone point me the right way for specification tracking for Konversation, please?

Please don't.

There are a lot of hidden flaws in the design of the X-Chat plugin API and it's always a huge pain to change a plugin API later.

Wait until I have time to write up my little report on the pros and cons of various designs first.

Okay. I will not write the Plugin API just yet. I agree. Like I said: First we need to outline the API before any programming is done. And you seem to be able to start with that. So go ahead and write a report so we can start defining the API.

> I was going to code a Blowfish encryption plugin for Konversation. 

Notably Konversation already has Blowfish support (see /setkey, /delkey), albeit lacking support for key exchange. I suggest you look into that.


> Can someone point me the right way for specification tracking for Konversation, please? 

Use the mailing list.

I'll try to make some time as quickly as possible. I can point out one example of the little X-Chat API gotchas I mentioned though.

The X-Chat plugin API makes it much more tricky than it should be to do things on a per-network basis. First, you have to filter through all the context handles for the network ones, and then you have to work around the fact that a lot of behaviours relevant to that are undefined in the docs. 

For example, there's no reliable way to handle multiple connections to the same network with different nicks unless you reimplement the nick manager in your plugin because there's no guarantee that you'll get == comparable handles (especially in things like the Python scripting plugin) and so you're forced to crazy things like keeping and manage (networkName, nick) tuples as network handle identifiers.

[Eike Hein]
> Notably Konversation already has Blowfish support (see /setkey, /delkey),
> albeit lacking support for key exchange. I suggest you look into that. 

That's interesting. I will try to add Diffie-Hellman Key Exchange.

[Eike Hein]
> Use the mailing list.

Okay. I registered on it yesterday and I will use it in the future.

[Stephan Sokolow]
> I'll try to make some time as quickly as possible.

That's great. But I'm probably a bit crazy for wanting to program the plugin API... I refuse to do it all on my own, because a reliable plugin API is very important from the beginning, and I'm not that advanced in Qt/C++. I did experiment with QPluginLoader before and I know more or less how to write a plugin system, but it's not something I dare creating from bottom up on my own. (But I will help where I can)

There are significant changes ahead for Konversation with the upcoming KDE4 port (which will involve rewriting much of the codebase) and our existing plans to readdress the architecture of the application, and improved extensibility has always been a part of that agenda, so any effort to contribute a plugin API should expect to come under much scrutinity with regard to how it fits into those schemes - i.e. no threat doing it alone.

"of doing it alone", rather.