1) Protocol support
I've looked a bit at the libpurple code and I'm still not sure about the
full lib but at least the protocol plugins looks usable. However it
would require implementing part of the libpurple interface in Licq (not
sure how big parts though) and it's written in C, not C++, so it might
not be too pretty in the Licq code.
I'm not sure whether this is a good option for us but I think it's an
option to keep in mind.
Kevin Krammer wrote:
Some of the other clients are either being rebased on or getting support for
protocol implementations provided through Telepathy [1] services.
I haven't looked very much at Telepathy but it definitely looks interesting.
Even if we don't jump on any of these implementations right away I think
we should have them in mind when designing the new protocol plugin
interface so there won't be any major problems if we make a telepathy
plugin or a purple plugin in the future. The obvious thing I see right
away is that one plugin must be able to provide multiple protocols.
2) Daemon and plugin API (Licq 2)
Erik Johansson wrote:
> The current version can load and start plugins, do basic message
> (events) passing and unload plugins. There is a logging mechanism,
> wrappers for pthread types (thread, mutex, condition) and an eventloop
> that supports timers and file descriptors.
>
> Some ground work has been laid but a lot work remains to get it in the
> same shape as licq 1. What is needed is more eyes on the code so that
> we can come up with a good way to solve all the different problems.
>
> There are some documents on the wiki, but I don't know how up to date
> they are. The best thing is to look at the source for licq and the
> simple plugin.
>
> I hope I'll be able to start helping out again in the coming months.
> Not as much as previous, but at least a little here and there.
It's great to hear that you're still with us. I was starting to think
that you had left us completely.
Please feel free to join us on IRC again when you get the time. Even if
you won't get much time to work on Licq 2, I guess much of the work will
require discussions on which designs and strategies to use and since
you're the one who's worked the most on it so far so it would be great
to have you in the discussions as well.
Of course, that goes for everyone else as well. I believe many of the
Licq 2 discussions will be done in #licq so anyone who's interested in
what the new design will include should join, even if you won't actually
work with the code.
I will try and look into Licq 2 soon and I think I could spend some time
on it this year to get it going.
I have a few ideas as well on how things should work but I want to
discuss them first before they become part of Licq 2. But I guess I
should look at what we actually got before trying to make too many ideas
of my own.
3) GUI
Kevin Krammer wrote:
At the Qt Dev Days 2008 Qt Software (formerly Trolltech) indicated that they
would increase work on platform integration, i.e. detecting which environment
they are running in and dynamically loading specific backend implementations
for certains aspects, e.g. dialogs.
So the need to a KDE GUI variant will probably become less relevant as Qt
progresses on that mission.
That's good information, so it's probably not worth doing any fancy
KDE-specific stuff in the GUI. But with the current KDE4-usage in our
dev team I don't think that'll happen anyway.
Currently the KDE code is mostly just using KDE-widgets where available
(i.e. KMenuBar instead of QMenuBar) and in several cases we reimplement
some of the KDE features ourselves when we compile without KDE support
so currently it's rather the Qt4-Gui (without KDE) that does extra
stuff. Although these are features I won't be surprised to see in Qt
class in the future.
Additionally quite some KDE features are actually provided by desktop session
services and KDE Libs only provide convenience API for accessing them, i.e. a
Qt-only GUI could potentially still access the same features through the
services' D-Bus APIs.
As for spellchecking: KDE's spell checking API is mainly an abstraction over
the handful of spell checking libraries, i.e. using one of them as a hard
dependency might be viable instead.
I had a look at the spell checking code for KTextEdit and it wasn't as
small and easily reused/copied as I had hoped. The spell checking and
highlighting for it is several classes and big enough to have a separate
namespace (Sonnet) in the KDE code. However, I know that it's a plugin
based implementation that supports multiple spell checkers so hopefully
implementing just one of them in Licq won't be that advanced.
Does anyone have any good opinions on which spell checking
implementation that would be a good candidate to use in Licq? Or is
there even some nice library that will use what it finds so we can
support multiple spell checkers with just one api?
4) Tickets
I've gone through the list and tried to find tickets to close, using 3
months as a rule for waiting for answers.
I found some tickets to close (for various reasons) and I got the list
down to 162 tickets left with the following distribution:
5 tasks (mostly Licq 2 stuff)
52 enhancements
105 defects
I've mostly looked at the defects now as these are easier to close, but
there are many of them waiting for us to do investigate or fix.
How should we all handle the enhancements? Should we close anything
that's unlikely to be implemented or should they be kept open as idea
input for anyone who's looking for something to do in the future?
/Anders
