On Fri, Mar 31, 2006 at 05:36:44AM +0200, QnD [Joachim Staib] wrote: > It all started some days ago when I tried to include GPG-support in icqnd (a > gtk-gui for Licq). Because I don't have any knowledge about GPG I wanted to > take a look at the qt-gui first to see how it works. I was more than > disappointed seeing, that this thing crashes everywhere AND doesn't work > without putting lines into an EMPTY config file. Putting my anger aside I > checked out the new things in licq-1.3.2 (the official release) ... what I > saw were new windows and new crashes. Together with my knowledge of the > Licq-API I really started to worry if Licq goes the right way.
Hmm. I guess the reason that this hasn't been fixed is that it works for me, and no one really complained about it being a big problem. If you have GPGME setup and working correctly, it works pretty easily. In 1.3.2, what are the new windows and new crashes? > - In my eyes the windows of the qt-gui are quite bad designed. Maybe good Basically it was recreated 6 years ago and hasn't changed much other than additions. And now always carefuly done additions either. > for a programmer but bad for a normal user (and believe it or not - most > Linux users are even afraid of the terminal). Things are not intuitive, > sometimes in submenus they really don't belong and sometimes don't work > properly. Also the program doesn't seem to follow a guide-line and uses > different GUI styles at once - it is missing a certain "ergonomy". A good overhaul would be nice. The biggest sore is the options dialog. I'd love to have a new one. And a correct plugins dialog. > Why does one have to click right for going online on the status information > field? Why is there no information about connecting? Why are users in so > many groups at once? Why are contacts sorted so wrong after downloading them > from the server? These are just the questions a new licq user would ask > himself after 5 minutes of using the program (and the tip of the iceberg) Again, the old code has survived mixed with the new code. I haven't had much time to work on Licq so for awhiel I've seen some improvements as progress instead of fixing the minor things that are wrong with it. The contacts being in more than one group was a feature. It worked nicely until server side lists were added. The server allows a user to be in one and only group, so we have a hack going on to keep the old feature (which I now consider to be a royal pain in the ass) around so it can work with the new feature (server side lists). What would be correct, is to allow a user to be in one and only oen group... but then that will break people's Licq or have complaints about the "feature" gone away. > - Things seem to be so unorganized. There are big steps to do, for example > better plugin integration, video support, bug hunting .... and what comes > in? A new error source: a third method of encryption (this is NO "attack" of > the programmer of OTR. It is propably a good thing and important, but is it > really the right time?), messing up the source more and more by making it > bigger and bigger (and for the points below). It is really nice to be able to support other forms of encryption. But as you can see, I'm holding off on integrating the patch. I'd like to implement it "properly"... working with a nice GUI and interfaces well with the source. Of course the patch writer cannot interface it well with the source, because the source is a mess and needs to be re-ordered. Have you ever added new features to icqd-srv.cpp? It is over 4000 lines which is too big to manage. I spend more time searching for the part to modify than modifying the code. Also, the ICQ protocol has changed, so we have unused code in many files. I have been thinkign of reorganizing the source files, but that will take time and has no immediate results. > - The API is just outdated and too highleveled. I have some experience now > with it and what I discovered was highleveling for ICQ everywhere. Sure, > regarding Licq's history this is more than logic, but times have changed, > for some reason every instant messager must have multi-protocol support to > have a chance (which is a good thing). But the API is missing a flexibility, > the ability to be extended through plugins - just outdated. Everyone who has > programmed with it knows what I mean. The plugins were originally designed to use one plugin at a time. Then a few plugins that came in that made it flexible to use a few at a time (RMS, OSD, etc). The actual plugin API relies on a pipe to send receive signals. The plugins can then do whatever. IMHO, an API should be more like a DLL that has set functions to call. And it would be nice for plugins to talk with each other. For example, a spell checking plugin that checks the messages right before they are sent from a GUI. This integreation of plugins is lacking and makes you wonder why we call them plugins. > - I always thought open-source also means "community-developed". In the case > of licq this doesn't seem to be the case. Really nothing is documented (So > much patience was neccessary to crawl through the qt-gui source to get a > hint of the API). This, kind of, averts a really community-based project but > packs all the work on one main developer (which is Jon). And because of a lack of documentation, there aren't many people willing to help out. It's like a vicious circle. > - The new web site is not bad from an ergonomic and stylistic standpoint but > the content is (for someone like me who really likes licq and always gets > butterflies in his stomach when a new version comes out) somehow > embarrassing ... half of the plugins arn't working anymore, the themes are > unorganized, just listed, and so on and so on I have spent some time working on the website, I created a blog to try and get more opinions and see what people were interested in. And then I created the Wiki to try and get documentation for end users working. But like most other things, I am diong most of the work. There have been some user contributions, thank you! > The question is what to do? > - create a REAL roadmap which is not based on sticky notes on Jons desktop > but on a real serious list on the licq page Yes, I created the Wiki with hopes of doing this. But then, I'm the only programmer it seems... > - think about the api, it must be more flexible, which means that it should > be able to load extension plugins (other plugins may ask the host for the > existence of certain plugins and then use their features), plugins must be > able to influence plugins. Yes, see above ;) > - start documentating everything! We have some doxygen comments created, but it is far from complete. The last time I was on an airplane I had my laptop and just worked on some documentation. > - REALLY do everything together with a community, plan areas, plan dead > lines (which still can cope with the "spare time project"-factor) Hmm.. not to be sarcastic, but who is together? I'd love to have other people helping out with the daemon or qt-gui.. but no ne has really stepped up. Recently Martin has sent a few patches though. > - tidy the site, ditch everytihng that isn't working If anyone wants access to the modify the site, let me know. > - try to KEEP the good call of Licq, follow guidelines, integrate it more, > get icons be done, short: get the thing ergonomic > - get ICQ out of the core and make it a plugin Ahh, you said what I've been wanting to do but putting it off. > - don't do the same mistake nearly every multi-instant-messager application > is doing - don't only support the least common denominator... Sorry, but what do you mean by the least common denominator? > Sounds easy but is hard, I know too well. But (to say it again) Licq ran the > wrong way. The code is in some parts too messed up. Do a rework, at lease > 40% can still be used. Perhaps reorganization is a better phrase. Doing a rework sounds a bit too much ;) ... and can be discouraging. > In fact my motivation regarding licq has sunken with this thoughts. I really > hope there will be some constructive answers pushing my motivation up again > :) Well, if you want to help it out, it would make things much better. Perhaps we should start co-ordinating to get the reset button pressed. There are many things to do, below is my list of things that I think should be done first: * Create a better plugin API First we have to decide what information needs to be passed to plugins and how the information is passed. Currently we use CICQSignal and ICQEvent classes and pass them through a pipe to the listening plugins. Perhaps having the plugin export a function, and then we call the function with specified parameters is a better way. That way the same object won't be used for _all_ different types of information. If that structure isn't enough, we create a new member to the class and then all events require that extra member (even if we don't use, it is taking up memory). * Create a better API for the protocol plugins See above... * Strip out ICQ and make it be a protocol plugin * Cleanup the new ICQ plugin's structure by: * Removing unused code * Organizing the source code layout in a logical way Of course this is just a basic idea to start getting people talking and things organized so we can clean the mess up and work on making an IM client to be proud of. Jon -- ________________________________________________________ Jon Keating ICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.org GPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
pgppklcQqXzRh.pgp
Description: PGP signature
