On Thu, Jan 1, 2009 at 8:36 PM, Anders Olofsson <[email protected]> wrote: > Firstly, Licq 2.0: > I think we can all agree that Licq needs a make over on many levels and a > redesign is needed. However, with the current activity, it will take ages > before we have Licq 2 as a replacement for Licq 1. > So I think we should instead focus on Licq 1 and change it one bit at a > time. This way we can get a redesign done over time but still work with a > product that's usable and deliverable along the way. I know this will > require more work, take longer time and probably break the API between every > release we make, but I can see this happening whereas Licq 2 would require > more dedication, organization and planning than we currently have.
Licq 2 is planned to make up for all the deficiencies that are present in Licq 1. And some of these deficiencies are in the base architecture, which make a simple and slow merge over from Licq 1 a bit difficult. Erik has created some of a code base, from what I remember it is a good start. I am not advocating a start from scratch approach, nor am I advocating a use the current code base. What I would prefer to see is a start from the current base, and rewrite the needed parts (Plugins, Signals, Events, Users). Yes, the needed parts make up for a large part of Licq, but there are qutie a few parts that don't, and time has gone into them to make them what they are now. At times, this would make the code base unusuable, so that is why I'm not advocating a slow approach as Anders proposed. But I don't think we should throw away the code that is fine and still reusable. > 1) Protocol support > The ICQ support in Licq covers a lot, but unfortunately it has gone a few > years since it was last up to date. Getting ICQ/AIM support for the latest > protocol will give Licq more of the functionallity available in the > protocol. > I would also like to see a more complete MSN support, there are a lot of > holes in the protocol implementation and I think here also we're using a > protocol version that's a few years old. > Will anyone maintain and update the protocol support we have or is it maybe > time to start looking at libraries for the protocols instead of having our > own implementations? I would to maintain the protocols, but I don't think I can commit that much time to it in 2009. Perhaps it is time to look into libraries. Just a few comments... Licq has a few features that most implemenations don't have, such as SSL connections. I still think SSL is a good way to get secure communications without the user doing much work, so it is still relevant. Also, there may be some features that got removed from the official client, but still are supported on the server. We would have to see what features an implementation can give us, and then see what features we will lose. Also, we need to consider the future. If we decide to use a library, how we do implement new features in the protocol? We can write patches and submit them upstream, but what if they don't get accepted? What if the library goes unmaintained? I think we would need to branch from the library, to provide our own code when necessary, plus we can sync up with the master branch to upgrade to a newer version. > 2) Daemon and plugin API > It would be nice to get all the ICQ code moved from the daemon to a separate > ICQ plugin as this would make the daemon cleaner and easier to work with. > Doing this would also force additions to the protocol plugin API for > everything it's currently missing. > The plugin API could also do with some major changes to make way for > supporting more protocols, make it easier to use, etc. > Most of the plans and ideas for Licq 2 will of course also fit into this > category. A part of the Licq 2 plan was to move the protocol code out of the daemon. Licq was built for ICQ, so any new protocols (MSN) have been hacked into it with a sloppy protocol plugin code (Yes, I take the blame for that). Removing ICQ from the daemon will provide a bit more of a challenge, as there are many places where it is closely tied together. As I said before, this can be done, but I think it is best to do it in a different SVN branch where we can break it and not affect Licq 1. The actual plugin API for Licq 2 will be more simple, so I think the actual extraction of the ICQ code should be for Licq 2 only. It will only provide more work in Licq 1, and then it will have to be changed once again for Licq 2. > 3) GUI > We have Qt4-Gui which I think works fine, even the old Qt-Gui is still > usable. However I think we need to start look at appearance and usability. > The one thing I would like most for Qt4-Gui is new skins, the existing skins > work but they are old. The desktop systems have evolved over the years so > our look and feel probably should too. Maybe we should look at making other > dialogs skinnable as well. Yes, the skins we have now are quite old and do show their age. Especially looking at the skins provided for other applications. Even if we do make other dialogs skinnable, if we don't have some artists to create modern skins, it won't be very useful. So we should consider this: What do we need to provide to the artists for making Licq pretty? > The second thing here would be KDE support for Qt4-Gui. There are still some > things to fix before we can release a Kde4-Gui that has all the KDE > integration of Kde3-Gui. I was excited when Qt4-GUI was being worked on and even started on a Kde4-Gui, but was so disappointed with KDE4, that I removed it and am not interested in it anymore. Yes, this is just an opinion, but I felt that KDE4 was such a downgrade due to the fact that I couldn't use my XWindows in an efficient manner anymore. > 4) Tickets > There are currently 185 open tickets. Many of these are old and probably not > reproducable or has too little information for troubleshooting. > The list needs to be reduced. I think we need to define a guideline for how > long we wait for an answer to a problem before we close a ticket that needs > more information. I think 3 months without any response, or a way to reproduce it is more than enough to mark it is "Invalid" or something. > Also, I've seen several tickets which ends with something like "I'll take a > look at this later" and then nothing more has happened. I understand that > everyone here has other things in their lives than Licq but please avoid > taking on work that you won't actually do. I guess I'm guilty of this :) I'll try not to do this anymore.. > I think we at least should start to look at ticket assignments, so if you > have tickets assigned to you I would like you to either try to find the time > take care of them, or remove yourselves as owner to mark that you're not > working with it. OK. > 5) Other UIs > The old console plugin needs to be updated, probably even replaced entirely. > The console plugin has an IRC feeling to it with the command input at the > bottom. Maybe a more windowed approach would be better if redesigning. > The web plugin I haven't even looked at but I know it's had no commits for > at least two years so it probably could do with some freshening up as well. Both are low priorites I think. > To get things done, someone also needs to do it, so here is what I feel that > I can contribute with to the above work: > 1) I'm not very home with protocol implementations so this is probably not > for me, at least not by myself. But I'll be happy to help if someone else > takes the lead. > 2) I have some ideas on what to do with the API that I'm working on and I'll > be happy to discuss these with anyone interested. However I don't think I'll > move the ICQ implementation by myself. Well, first lets decide what we want to do before anyone starts working on something. > 3) I've looked a bit at the Kde4-Gui but I'm stuck, and I'm not one for > making skins, but I have planned to make all shortcut keys user configurable > and I'm always looking for other improvements to throw in. Can we get someone who would create skins? And then find out what we need to offer to them to make it easier/better? > 4) I go through the list sometimes and try to find tickets to close but I > don't know how to handle many of them. Guidelines for ticket handling would > help. 3 months without activity, or a way to reproduce it and close it? If it has an owner and inactive, contact the owner to find out the current status? > 5) I could probably do a new console plugin, but right now It's more likely > that I'll spend my time with the daemon and API work. Perhaps Philip will be willing to help with this if he has time? Jon
