Re: [Licq-devel] So long and thanks for all the bits
Thanks for all the work and continuation of the project! I hope you enjoy what you work on next (or not work on, if that is the case too). Jon On Sat, Aug 1, 2015 at 9:17 AM, Erik Johansson e...@ejohansson.se wrote: Hi all, After ~9 years as a Licq developer I'm sad to announce that it is time for me to move along and step down as an active developer. Since development has been rather limited the last year or so for all of us, the question is if there is anyone else out there that is eager to continue the development of Licq? The code base is mostly C++ which means a great deal of fun hacking on it. So if anyone is interested, now is the time to speak up. Best regards, // Erik -- Erik Johansson Home Page: http://ejohansson.se/ PGP Key: http://ejohansson.se/erik.asc -- --- You received this message because you are subscribed to the Google Groups Licq Development group. To unsubscribe from this group and stop receiving emails from it, send an email to licq-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups Licq Development group. To unsubscribe from this group and stop receiving emails from it, send an email to licq-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Licq-devel] Update DNS for licq.org
Sure, it looks like I need to update the apex domain to use an ALIAS to licq-im.github.io... correct? Jon On Thu, Jan 9, 2014 at 2:01 AM, Erik Johansson e...@ejohansson.se wrote: Hi, As described on https://github.com/blog/1715-faster-more-awesome-github-pages we need to update the DNS for licq.org. How can do this? Jon? / Erik -- --- You received this message because you are subscribed to the Google Groups Licq Development group. To unsubscribe from this group and stop receiving emails from it, send an email to licq-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- --- You received this message because you are subscribed to the Google Groups Licq Development group. To unsubscribe from this group and stop receiving emails from it, send an email to licq-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Licq-devel] Migrating trac tickets [help needed]
On Mon, Aug 8, 2011 at 12:04 AM, Anders Olofsson fl...@licq.org wrote: 741 [icq] Checking if a user is invisible doesn't work From the title is sounds like something that once worked but that have since been fixed in the ICQ protocol (on the server side). Yes, there is even a comment The server has been fixed, so this feature no longer works. from Jon 2005-07-01 so I guess we can just drop it unless he can tell why he left it open. I left it open as a TODO to investigate if it could be done using a different method. I believe it can be closed and if desired, opened as a new ticket. 1428 [icq] Invalid login sequence being performed = Reported by Jon but not sure what it's referring to. Licq was sending packets in a different order than the official client. It could have been used to detect non-official clients and block them. But it looks like that never happened, so it is irrelevant. 1445 [icq] Licq does not receive messages from icq 5.1 = Long discussion with several patches from Jon and it looks like it got partially better (messages working but not file transfers). Did these patches get committed or did they just exist as attachments to this ticket? I do not recall, you would have to use git grep to see if the changes are in or not. 1530 [icq] Server side contactlist damaged after moving users between groups = Confirmed as a known problem / Eugene 2007-08-16 = Cause of problem probably found and will fix them next / Jon 2008-04-21 Don't remember this either, looking at gig log for my commits after that day should reveal if it was done or not. Jon
Re: [Licq-devel] Trac server
Sorry for the delay, here is the Trac SQL dump: https://licq-backup.s3.amazonaws.com/trac.sql.bz2 Jon On Tue, Apr 19, 2011 at 4:04 AM, Erik Johansson e...@ejohansson.se wrote: On Sun, Apr 17, 2011 at 11:09, Anders Olofsson fl...@licq.org wrote: I might have missed a few details since I haven't been very active the last months, but do we have a replacement bug handling somewhere or did we just loose all our tickets? I assume we'll use the issue system on github: https://github.com/licq-im/licq/issues Regarding importing all the old bugs, perhaps we can manually add those that have at least some hope of getting fixed? Also, is there a guide somewhere to how the new web page works? e.g. is there a way to test what I'm doing before I push my changes to github? Yes there is. See http://pages.github.com/ and https://github.com/mojombo/jekyll/wiki/usage for instructions. // Erik -- Erik Johansson Home Page: http://ejohansson.se/ PGP Key: http://ejohansson.se/erik.asc
Re: [Licq-devel] Trac server
Everyone but admins had read-only permissions. I will share the SQL backup when I get back home on Thursday night. Jon On Apr 17, 2011 6:39 PM, Anders Olofsson fl...@licq.org wrote: On 2011-04-07 21:07, Erik Johansson wrote: On Wed, Apr 6, 2011 at 01:40, Jon Keatingj...@licq.org wrote: I have kept the Trac server in a read-only state for awhile, is it ready to be taken offline yet? It's ok by me. But could you put a dump of the database somewhere? I would like to download it and keep it if for reference. // Erik I might have missed a few details since I haven't been very active the last months, but do we have a replacement bug handling somewhere or did we just loose all our tickets? and what about the trac pages, is there a dump somewhere so grab pages from if we want to move to the new page (I was thinking of getting the coding style migrated). Also, is there a guide somewhere to how the new web page works? e.g. is there a way to test what I'm doing before I push my changes to github? Btw, in which way was trac read-only? I had no problemes closing a ticket last week in trac. And the user list had gotten a lot of spam accounts that I could delete. /Anders
[Licq-devel] Trac server
Hey guys, I have kept the Trac server in a read-only state for awhile, is it ready to be taken offline yet? Jon
Re: [Licq-devel] Licq domains
No idea why I changed that. It is back now. Still not in read-only mode, but I'll get around to that today. Jon On Thu, Nov 11, 2010 at 3:36 PM, Erik Johansson e...@ejohansson.se wrote: On Wed, Nov 10, 2010 at 22:21, Jon Keating jonkeat...@gmail.com wrote: That would be, just updated it. Excellent, thanks. Could you change trac.licq.org to point to the old site so that we still can access it? // Erik -- Erik Johansson Home Page: http://ejohansson.se/ PGP Key: http://ejohansson.se/erik.asc
Re: [Licq-devel] Licq domains
That would be, just updated it. Jon On Thu, Nov 11, 2010 at 4:40 AM, Erik Johansson e...@ejohansson.se wrote: On Mon, Nov 8, 2010 at 23:01, Jon Keating jonkeat...@gmail.com wrote: On Tue, Nov 9, 2010 at 6:23 AM, Erik Johansson e...@ejohansson.se wrote: licq.org and www.licq.org Change these to point to http://licq-im.github.com/ in the way described on http://pages.github.com/ under Custom Domains. I have created the CNAME file so the only thing left to do is change the DNS. That sounds good to me. Who is DNS admin and can do this? // Erik -- Erik Johansson Home Page: http://ejohansson.se/ PGP Key: http://ejohansson.se/erik.asc
Re: [Licq-devel] Licq domains
I just made the SVN repository read-only as of now. Anyone who tries to commit should get an error. I also meant about Trac, do you want to make that read-only now as well? I think there should be some way to let the users know that they will have to register issues at github instead of trac. Let me know what you want to do. Jon On Tue, Nov 9, 2010 at 3:37 PM, Erik Johansson e...@ejohansson.se wrote: On Mon, Nov 8, 2010 at 23:22, Jon Keating jonkeat...@gmail.com wrote: On Tue, Nov 9, 2010 at 7:19 AM, Erik Johansson e...@ejohansson.se wrote: Will you host this? When do you want to start putting it read-only mode? Now. The git repo is now the main. // Erik -- Erik Johansson Home Page: http://ejohansson.se/ PGP Key: http://ejohansson.se/erik.asc
Re: [Licq-devel] Licq domains
On Tue, Nov 9, 2010 at 6:23 AM, Erik Johansson e...@ejohansson.se wrote: licq.org and www.licq.org Change these to point to http://licq-im.github.com/ in the way described on http://pages.github.com/ under Custom Domains. I have created the CNAME file so the only thing left to do is change the DNS. That sounds good to me. trac.licq.org It would be very good if this could stay accessible for some time (months?) to give us time to move stuff to GitHub. Would you want to make this read-only? svn.licq.org I would like this to always stay up and serve the svn repo in a read-only mode. Agreed. Did I miss any domain? There is mail.licq.org, start.licq.org, calendar.licq.org but they are just CNAMEs for gmail. But that is all that we use. Jon, since you are the admin of trac and svn, what do you say? If you can't host them anymore maybe someone else can? If we are putting Trac in read-only mode, I can host it on my other server. Another thing we can do, is use EC2 free for one year, if no one else has a server they want to put it on. http://aws.amazon.com/free Perhaps me moving it to EC2 temporary would be best actually. Jon
Re: [Licq-devel] Licq domains
On Tue, Nov 9, 2010 at 7:19 AM, Erik Johansson e...@ejohansson.se wrote: Will you host this? When do you want to start putting it read-only mode? Jon
Re: [Licq-devel] Move to launchpad?
Hey Guys, I'm bringing this thread back to life after almost a year. The service has not moved, but I will need to shut down that instance licq.org is running on. My personal server is now being used as a critical server for another project, so I won't be able to host it on my server. So the question is, where would you guys like to see Licq? My suggestions are: - github - Launchpad - Google Code - SF Jon On Thu, Dec 3, 2009 at 9:23 AM, Jon Keating jonkeat...@gmail.com wrote: We moved away from SF due to poor reliability and their bug tracker was very unproductive, at the time. Personnaly, I have no issues with svn, in fact I like it. I use git for most projects now and git-svn makes things even better. The main issue is how heavy trac is. It spends a lot of time in the DB. What I am willing to do is move it to my personal server and see how things go. If I cannot make it better, then we will have to see what options we have. At this point I am leaning towards launchpad because they seem to have a good tracker and collaboration system. I have to make the move by Dec 14th, so I will send out a notice when I can schedule some time to do the work. Most likely it will be dec 12 or 13. Jon -- Sent from my phone, please excuse brevity and typos On Dec 2, 2009 6:36 PM, Arne Schmitz arne.schm...@gmx.net wrote: Am 30.11.2009 um 11:30 schrieb Erik Johansson: We want something that can host code and has a bug tracker. The alternatives I know of are: sou... We started out at sf.net and moved away. Don't know the reasons anymore, but there were some. :) Google code looks ok and has a wiki. Launchpad does not have a wiki, but web interface for doin... I have neither used Google Code nor Launchpad myself, so I cannot comment on their quality. My suggestion: Move bug tracker and code to launchpad. Keep a wiki somewhere that licq.org ca... What's with the move away from subversion that you talked about in your email? I am still mainly using svn, but also trying out git. Launchpad seems to use Bazaar -- whatever that is! So what are the advantages of Launchpad? One thing I can see is the Ubuntu build service, which would of course be nice. Cheers, Arne -- Dipl.-Inform. Arne Schmitz Phone +49 (0)241 80-21817 Computer Graphics Group Mobile +49 (0)162 7278759 RWTH Aachen University Fax +49 (0)241 80-22899 Ahornstrasse 55, 52074 Aachen, Germany http://www.rwth-graphics.de
Re: [Licq-devel] Move to launchpad?
We moved away from SF due to poor reliability and their bug tracker was very unproductive, at the time. Personnaly, I have no issues with svn, in fact I like it. I use git for most projects now and git-svn makes things even better. The main issue is how heavy trac is. It spends a lot of time in the DB. What I am willing to do is move it to my personal server and see how things go. If I cannot make it better, then we will have to see what options we have. At this point I am leaning towards launchpad because they seem to have a good tracker and collaboration system. I have to make the move by Dec 14th, so I will send out a notice when I can schedule some time to do the work. Most likely it will be dec 12 or 13. Jon -- Sent from my phone, please excuse brevity and typos On Dec 2, 2009 6:36 PM, Arne Schmitz arne.schm...@gmx.net wrote: Am 30.11.2009 um 11:30 schrieb Erik Johansson: We want something that can host code and has a bug tracker. The alternatives I know of are: sou... We started out at sf.net and moved away. Don't know the reasons anymore, but there were some. :) Google code looks ok and has a wiki. Launchpad does not have a wiki, but web interface for doin... I have neither used Google Code nor Launchpad myself, so I cannot comment on their quality. My suggestion: Move bug tracker and code to launchpad. Keep a wiki somewhere that licq.org ca... What's with the move away from subversion that you talked about in your email? I am still mainly using svn, but also trying out git. Launchpad seems to use Bazaar -- whatever that is! So what are the advantages of Launchpad? One thing I can see is the Ubuntu build service, which would of course be nice. Cheers, Arne -- Dipl.-Inform. Arne Schmitz Phone +49 (0)241 80-21817 Computer Graphics Group Mobile +49 (0)162 7278759 RWTH Aachen University Fax +49 (0)241 80-22899 Ahornstrasse 55, 52074 Aachen, Germany http://www.rwth-graphics.de
[Licq-devel] Re: www.licq.org down?
I restarted python and lighttpd, and it is up and running now.. just going a bit slow. It is getting hammered by search engine crawlers though. I need to make a robots.txt that limits how many queries they can send. Jon On Fri, Nov 6, 2009 at 3:13 AM, Erik Johansson e...@ejohansson.se wrote: Hi, I can't access licq.org (ssh works, but not http). Is it down or is it just me? // Erik -- Erik Johansson Home Page: http://ejohansson.se/ PGP Key: http://ejohansson.se/erik.asc
[Licq-devel] Re: web and svn access
Philipp, Sorry about that, I'm not sure when it went down, but it is back up now. I should see about getting some server monitoring setup so I get notified as soon as it has some kind of a problem. Jon On Thu, May 14, 2009 at 1:49 AM, Philipp Kolmann phil...@kolmann.at wrote: Hi, I wanted to update licq src today, but I can't access svn or www.licq.org. any downtime known? thanks Philipp
[Licq-devel] Re: Commit mails
Seems to be related to this: https://bugs.launchpad.net/ubuntu/+source/svnmailer/+bug/88769 Added that config, will wait till the next commit to see hwo things go.. Jon On Fri, Jan 16, 2009 at 4:12 AM, Erik Johansson e...@ejohansson.se wrote: Hi, Something must be wrong with the commit mails. E.g. all = are replaced with =3D making it a bit hard to read. Looks like the mails are ascii encoded but not marked as such or something. The web interface also shows this problem: http://groups.google.com/group/licq-commits // Erik -- Erik Johansson Home Page: http://ejohansson.se/ PGP Key: http://ejohansson.se/erik.asc
[Licq-devel] Re: What will happen with Licq in 2009?
On Thu, Jan 1, 2009 at 8:36 PM, Anders Olofsson fl...@licq.org 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
[Licq-devel] Re: Time for a new release?
I'm all for a new release as well, since 1.3.5 is no longer able to login without a path or svn update. The 1.4.0 release should occur when there is a major release for the daemon. Past releases: 1.2.0 Added support for OSCAR protocol 1.3.0 Added support for (half-assed) protocol plugins 1.4.0 Added ... ? And don't forget to send out an e-mail to licq-announce, and update freshmeat. I have a script for that somewhere and will commit it once I find it. Jon On Wed, Sep 10, 2008 at 4:17 AM, Erik Johansson [EMAIL PROTECTED] wrote: 2008/9/9 Anders Olofsson [EMAIL PROTECTED]: So what do you say? Is it time for a release or does anyone have a good reason for waiting? +1 for doing a release. I could do it if someone tells me how it's done. (I couldn't find any page in trac how to do it so it might be an idea to write one.) The procedure goes something like this: 1. Update/verify http://licq.org/wiki/DeveloperArea/ReleaseNotes/1.3.6 2. Get http://svn.licq.org/svn/trunk/scripts/create-licq-tarball.sh 3. Run ./create-licq-tarball.sh -n licq-1.3.6-rc1 -g -b -s -r rev where rev is the revision that should become rc1. This will create a gz and bz2 tarball and sign them. 4. Get http://svn.licq.org/svn/trunk/scripts/tag-licq-release.sh 5. Run ./tag-licq-release.sh -v 1.3.6-rc1 -r rev. This will create a tag in svn. 6. Upload the tarballs somewhere and ask Jon to upload them to sf.net. 7. Update http://licq.org/wiki/LicqDownload 8. Send mail to licq-dev, licq-users and licq-announce 9. Write news entry on http://licq.org/ All taken from memory, so I hope I haven't forgotten anything. Also, should the new release be version 1.3.6? I know I've done some changes to the plugin API that are not be 100% backwards compatible, would that be reason enough to call it 1.4.0 instead? Don't know our rules for this, but 1.4.0 might be the right thing to do. /Erik -- Erik Johansson Home Page: http://ejohansson.se/ PGP Key: http://ejohansson.se/erik.asc
[Licq-devel] Re: SVN commit messages
On Friday 18 July 2008, Arne Schmitz wrote: Am Freitag, 11. Juli 2008 13:58:54 schrieb Jon Keating: On Friday 11 July 2008, Arne Schmitz wrote: Who is responsible for the SVN server? The commit messages are not coming through anymore for the last week. That would be me. The mail server queue is full, I'll try and get it cleared out. Have you tried that yet? Still no commit messages here yet. Do you need help with that? Looks like the queue got cleared out, but e-mails errored out. I resent all the old e-mails now. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Tokyo, Japan
[Licq-devel] Re: SSBI for Licq, new version
Sergey, Sorry for the long delay, but I finally got your SSBI patch merged into SVN. There were a few things I changed: * Changed the name of SSBI to BART (Buddy Art) * Fixed a few memory leaks * Made use of boost in a few places (would like to see more actually...) * Changed the saving of pictures from using %lu as the name to %s, so it works with AIM users (not all cases though) * Added constants for the BART Types * Added support for the qt4-gui. The oscarservice file seems to replicate a lot of code from icqd-srv.cpp, such as the the way it processes packets. It would have been nice to get that simplified down, but I commited as is. As for the memory leaks, there was a case of new being called and no delete. I changed it to using boost::scoped_array, so there is no need to remember to call delete. And when reading the buddy icon hash from the user's config file, the string never got free'd in the user's destructor. So if the user got deleted, their would be a leak. I'll be addind a few more fixes to get it working with all AIM users soon. Thanks, Jon On Tuesday 22 January 2008, Sergey Kononenko wrote: Hello, This is new version of patch that add SSBI (server side buddy icon (or user picture)) support to licq. Changes from prior versions: 1. Fixed handling of icq direct client to client communication which was completely broken in previous versions of patch. 2. Fixed crash on exit when UseSSBI is off. With best regards, Sergey Kononenko. -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Tokyo, Japan
[Licq-devel] Re: Security hole and possible DOS attack in Licq client.
Ladislav,
Thanks for the information. We were already aware of this and fixed it
in SVN last week.
Jon
On Fri, Apr 18, 2008 at 6:14 PM, Ladislav Michnovič
[EMAIL PROTECTED] wrote:
Hello.
Licq has a vulnerability and possible security hole. The problem is
described here http://securityvulns.ru/docs7669.html.
quoting from bugtraq
[... in case of licq there is no check for socket() number to be below
FD_SETSIZE and it leads to potentially exploitable situation very
similar to off-by-one overflow in icqd-filetransfer.cpp, where one
(easy) of few (harder) bits on the stack may be controlled by attacker,
in this situation:
void *FileTransferManager_tep(void *arg)
{
CFileTransferManager *ftman = (CFileTransferManager *)arg;
fd_set f_recv, f_send;
nSocketsAvailable = select(l, f_recv, f_send, NULL, tv);
attacker can partially control ftman pointer (and may be even saved
ebp/eip), code execution is not something absolutely impossible.]
HOW TO REPRODUCE:
compile the attached expolit.
Run licq and discover which port is licq listening on:
lsof |grep licq |grep LISTEN
licq 29181 lmichnovic 11u IPv44595400
TCP *:24500 (LISTEN)
run compiled exploit:
./a.out 127.0.0.1 24500
(the last number is the port number)
You have to wait till approx 1020 sockets are opened and then licq
crashes (tested on licq from svn 20080410):
Licq Segmentation Violation Detected.
licq(licq_handle_sigabrt+0x2c5) [0x4b0ab5]
/lib64/libc.so.6 [0x2b58b791abd0]
/lib64/libc.so.6(gsignal+0x35) [0x2b58b791ab45]
/lib64/libc.so.6(abort+0x110) [0x2b58b791c0e0]
licq [0x4b0d4a]
/lib64/libc.so.6 [0x2b58b791abd0]
licq(_ZN10CSocketSet3SetEi+0x39) [0x4599f9]
licq(_Z18MonitorSockets_tepPv+0x506) [0x4850a6]
/lib64/libpthread.so.0 [0x2b58b6926020]
/lib64/libc.so.6(clone+0x6d) [0x2b58b79aef8d]
Attempting to generate core file.
*** glibc detected *** licq: free(): invalid pointer: 0x0080b790 ***
=== Backtrace: =
/lib64/libc.so.6[0x2b58b795821d]
/lib64/libc.so.6(cfree+0x76)[0x2b58b7959f76]
licq(_ZN10CPluginLog8ClearLogEv+0x34)[0x49c174]
/usr/lib64/licq/licq_qt-gui.so(_ZN12CQtLogWindow8slot_logEi+0x95)[0x2b58b7f684c5]
/usr/lib64/licq/licq_qt-gui.so(_ZN12CQtLogWindow9qt_invokeEiP8QUObject+0x6b)[0x2b58b7f6865b]
/usr/lib/qt3/lib64/libqt-mt.so.3(_ZN7QObject15activate_signalEP15QConnectionListP8QUObject+0x14c)[0x2b58b87dfe9c]
/usr/lib/qt3/lib64/libqt-mt.so.3(_ZN7QObject15activate_signalEii+0x134)[0x2b58b87e0554]
/usr/lib/qt3/lib64/libqt-mt.so.3(_ZN15QSocketNotifier5eventEP6QEvent+0x3b)[0x2b58b87f9f7b]
/usr/lib/qt3/lib64/libqt-mt.so.3(_ZN12QApplication14internalNotifyEP7QObjectP6QEvent+0xcd)[0x2b58b878970d]
/usr/lib/qt3/lib64/libqt-mt.so.3(_ZN12QApplication6notifyEP7QObjectP6QEvent+0x98)[0x2b58b878a428]
/usr/lib/qt3/lib64/libqt-mt.so.3(_ZN10QEventLoop23activateSocketNotifiersEv+0xe3)[0x2b58b877f4d3]
/usr/lib/qt3/lib64/libqt-mt.so.3(_ZN10QEventLoop13processEventsEj+0x644)[0x2b58b873f884]
Canceled
Regards Ladislav.
--
Jon Keating ICQ: 16325723
[EMAIL PROTECTED] MSN: [EMAIL PROTECTED]
http://www.licq.org GPG: 2290A71F
http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Qt4-GUI application icon
On Saturday 17 November 2007, Eugene Paskevich wrote: Here they are: http://nestsite.selfip.net/~eugene/licq/icon1.xpm http://nestsite.selfip.net/~eugene/licq/icon2.xpm I would like to hear your thoughts about them, or you might suggest your variant. I would definitely go with icon2.xpm. icon1.xpm's font will be unreadable if the background is the same color as the font. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Emoticons License question
On Thursday 18 October 2007, Erik Johansson wrote: Done. FeltTip4 is now in svn and will be included in 1.3.5. I would appreciate if someone with more smiley expertise than I could check it out. Everything seems fine with them. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: to flynd: QSystemTrayIcon
On Tuesday 17 July 2007 18:57, Anders Olofsson wrote: The QSystemTrayIcon will never appears a window so for those WMs (I saw it in WindowMaker and IceWM) there is no status icon at all. So I see the following options: 1) Use the behavior from Eugene's patch and hope that nobody misses the small status icon on the simpler WMs. Just a quick question. Are there any modern WMs that do not support the KDE docking. QSystemTrayIcon is using the freedesktop.org standard, right? If it is, I think we can just not worry about the larger dock icon. If a user is running a WM that doesn not have the dock icon support, but they are using Qt4, I think it is safe to say they don't care about dock icons. As you said above, WindowsMaker and IceWM support it. I know that fluxbox does, and I imagine blackbox does as well. Gnome and KDE are a given... so the question is, do we really care? Jon As the current wharf classes do a lot more than is needed by the QSystemTrayIcon I would like to not implement it like them but instead make it a separate class (or perhaps just add it to mainwin if the code is small). My vote is therefor on #5 but it would still be possible to have the behavior of #4 if that is preferred. Or just go with #1 and drop the current wharf code, as it does a lot of low level X calls that we shouldn't really need anymore. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Commit e-mails
I have changed the commit e-mails to have the e-mail address shown as @licq.org for the following users: jon erijo flynd If any other commiters want an @licq.org e-mail address (provided by Google for Apps) let me know. You can change the settings (forwarding, pop3, etc...) by yourself, so let me know. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Commit 5026
On Wednesday 18 July 2007 18:07, Erik Johansson wrote: If it crashes when using a reference, something must serious wrong with his compiler. After all, the string is copied (again) when it is added to the map. Yes, that is right. I need to get a backtrace to find out what is going on. I'll switch it back to const std::string in the morning. Perhaps you should add that to the coding style? if (pending.length()) = If has some length if (pending.size()) = If has some size if (!pending.empty()) = If not empty All seem the same to me... It's all about intent, and I guessed that you wanted to check if the string was non-empty, not that the length was non-zero. It's a tiny tiny difference, but I'm a bit pedantic from time to time... (If you disagree I hope that you ignore me or scream at me loudly :)) Well, C++ is a language, and like most languages (Computer and Human) there are multiple ways to express the same intent. People can argue about which one is the most correct, but in the end everyone that is fluent understands them. If nothing else, empty() may actually (in some strange, badly implemented, probably non-existing) implementations be faster than length(). Think not storing the length, only a char pointer... We can always run g++ -S and take a look at the assembly, but with -O2, I bet it all comes out the same... If there are any implementations out there, I bet they will have much bigger problems than a few extra instructions. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: DNS and Email
On Tuesday 17 July 2007 22:00, Sebastian Renzi wrote: Also, the website www.licq.org doesn't seem to work, I get a 404 from sourceforge. I fixed the CNAME record to point to vhost.sourceforge.net (It wasn't like that last time I set the CNAME recored, as I recall). So it should be working shortly. Thanks for the pointing this out. Which reminds me, is it about time we move [www.]licq.org to go to trac.licq.org ? Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Commit 5026
On Tuesday 17 July 2007 21:50, Erik Johansson wrote: addToModifyUsers() should take a const std::string reference as second arg to avoid unnecessary copies. The point is to force a copy. One of the users, Crazy_Hopper on IRC was reporting a crash and it was fixed by not using a reference as the parameter. Something may be strange with his STL version. I'll try and confirm with him about that. Additionally, I think that function declarations should include the name for all parameters. Added. line 4305: I think if (pending.length()) should be if (!pending.empty()). Perhaps you should add that to the coding style? if (pending.length()) = If has some length if (pending.size()) = If has some size if (!pending.empty()) = If not empty All seem the same to me... Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Crashing licq on strange message when getting online.
On Tuesday 17 July 2007 17:29, Ladislav Michnovič wrote: Hello. My Licq 1.3.4 is crashing when I log in and receive strange message (unfortunately) from spammer. The message is visible when I run Licq again and I'm offline. But the message is still on the server and when I change status to online the message comes again so Licq crashes again and again. I tried another client erased the message so I can't reproduce the crash again. Next time you have this happen, can you provide the message dump? It can be obtained with licq -d31 from an xterm window. What would be best is running licq in gdb and providing the backtrace (assuming you have debug symbols compiled). Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] DNS and Email
I got the DNS working I believe. If there are any hosts that are still not responding, please let me know. Also, I have moved the e-mail to Google Apps, so you can use licq.org e-mail with a GMail interface. Should improve reliability some too (free account has 99.9% uptime). Also it has a POP3/SMTP interface (with SSL!) and there are a few tricks you can do to get it working with IMAP. If anyone wants a licq.org e-mail address (even just for forwarding), please let me know. Until I can get the settings off fanfic.org, I don't know the existing e-mail accounts. So if you were using one, please tell me what it is and I will set it up for you. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Auto response in ICQ6
On 7/11/07, Sebastian Renzi [EMAIL PROTECTED] wrote: issue and if it's ok if I take care of it. Also I'd like to know if it's ok to send patches to this list or maybe I should send it to someone specific (maybe Jon) so he can check out the code. The list is the place to send it. I haven't been active due to being sick since last week and then went on a 4-day vacation to Guam. Just got back today so I will probably take a look at it tomorrow or Friday. And no, no one is currently working on anything related to ICQ6, but crashes should be a high priority. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Xtraz Status
On Friday 29 June 2007 00:42, Sebastian Renzi wrote: Now I'm working on retrieving the xtraz status message. I've identified the packet that should be sent. The question is: should licq retrieve the message as soon as it determines that the user has xtraz status (this is the default behaviour of Mirabilis ICQ) or should we have a button to retrieve it (like Away or N/A messages)? Since it describes the users current status, it should be retrieved as soon as possible. Mirabilis has the xtraz status override the actual status, so we need to get it and show it instead of the current status. To retrieve the xtraz message, I need to decode an xml message. Is there anything done already? I've seen xml in other parts of the protocol, so I wouldn't like to code something that already exists. Nope, the current XML is not even used at all. ret event='OnRemoteNotification' srvidcAwaySrv/id val srv_id='cAwaySrv' RootCASXtraSetAwayMessage/CASXtraSetAwayMessage uinuser's UIN/uin index1/index titleStatus Name/title descStatus Description/desc /Root /val /srv /ret If all you need is to extract the desc field, then using a string's search capability is sufficient. But if you need more than that, we should use an XML parser perhaps. I still haven't looked at the qt-gui code, but after retrieving the message, I'm planning to modifiy the qt-gui in order to reflect the status with the xtraz icons. I'm planning to use Mirabilis icons, at least for the moment. Then each skin should have their xtraz icons, but I figure that if we're using Mirabilis emoticons, I think that we'll be able to use these icons as well. I'm not sure about the licenses, though. What I would reccommend is to use the current icons as a base that are hardcoded into the Qt-GUI. That way if a skin doesn't specify an icon, we can fallback to the default in the GUI. Well, this is only the beginning. :-) Any hints will be much appreciated. I would also reccommend to breakup any work into smaller patches. Such as #1 Get xtraz status #2 Set xtraz status #3 Extra gui work #4 Anything else? That way it is easier to integrate the patches, and it should reflect the order in which you are making the code. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Coding style
On Thursday 28 June 2007 05:14, Erik Johansson wrote:
Without using boost, it can sometimes be cumbersome to create the
functors that you need, instead of using a simple loop. But
boost::lambda looks like it might be the answer to all my prayers, so
I'm willing to give it a try.
Have you taken a look at boost::bind? It really makes things simple. I haven't
found an example like this, but it works nicely:
// inside a long function
for (iter = users.begin().)
{
(*iter)-calcFunction();
if ((*iter)-verifyFunction)
{
delete (*iter);
users.erase(iter);
break;
}
(*iter)-doMoreWork();
}
And then you can add a new function to the class..
void theClass::doWork(ICQUser *user) // -- pointer reference is necessary
here
{
user-calcFunction()
if (user-verifyFunction())
{
delete user;
user = 0;
return;
}
user-doMoreWork();
}
Then in the original code...
// Do the task with the idea of a function having one main purpose
std::for_each(users.begin(), users.end(), boost::bind(theClass::doWork, this,
_1));
// Remove any deleted iterators
users.erase(std::remove(users.begin(), users.end(), static_castICQUser
*(0)), users.end());
There is also the BOOST_FOREACH, but it doesn't promote modular code. In fact
it does the opposite, so I'm not really that interested in using it.
Jon
--
Jon KeatingICQ: 16325723
[EMAIL PROTECTED] MSN: [EMAIL PROTECTED]
http://www.licq.orgGPG: 2290A71F
http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] [PATCH] Cleaning up server side lists
Here is a fix for the patch I gave to Crazy_Hopper on IRC. Let me know if this
one works, should fix the crashes you were getting.
/me grumbles to self about references being abused.
Jon
--
Jon KeatingICQ: 16325723
[EMAIL PROTECTED] MSN: [EMAIL PROTECTED]
http://www.licq.orgGPG: 2290A71F
http://www.thejon.org HOME: Minamiashigara, Japan
Index: include/licq_icqd.h
===
--- include/licq_icqd.h (revision 4878)
+++ include/licq_icqd.h (working copy)
@@ -13,6 +13,7 @@
#include vector
#include list
+#include map
#include deque
#include string
#include algorithm
@@ -722,7 +723,7 @@
pthread_mutex_t mutex_extendedevents;
std::list ICQEvent * m_lxSendQueue_Server;
pthread_mutex_t mutex_sendqueue_server;
- std::list char * m_lszModifyServerUsers;
+ std::map unsigned long, std::string m_lszModifyServerUsers;
pthread_mutex_t mutex_modifyserverusers;
pthread_mutex_t mutex_cancelthread;
pthread_t thread_monitorsockets,
@@ -819,6 +820,9 @@
void StupidChatLinkageFix();
+ // Helpers
+ void addToModifyUsers(unsigned long, const std::string);
+
// Declare all our thread functions as friends
friend void *Ping_tep(void *p);
friend void *UpdateUsers_tep(void *p);
Index: src/icqd-srv.cpp
===
--- src/icqd-srv.cpp (revision 4925)
+++ src/icqd-srv.cpp (working copy)
@@ -88,13 +88,10 @@
ICQ_SNACxLIST_ROSTxEDITxSTART);
SendEvent_Server(pStart);
- pthread_mutex_lock(mutex_modifyserverusers);
- m_lszModifyServerUsers.push_back(strdup(_szId));
- pthread_mutex_unlock(mutex_modifyserverusers);
-
CPU_AddToServerList *pAdd = new CPU_AddToServerList(_szId, ICQ_ROSTxNORMAL,
0, _bAuthRequired);
gLog.Info(tr(%sAdding %s to server list...\n), L_SRVxSTR, _szId);
+ addToModifyUsers(pAdd-SubSequence(), _szId);
SendExpectEvent_Server(0, pAdd, NULL);
CSrvPacketTcp *pEnd = new CPU_GenericFamily(ICQ_SNACxFAM_LIST,
@@ -124,10 +121,6 @@
if ((*gID)[i] == 0)
{
groups.push_back((*g)[i]);
-
- pthread_mutex_lock(mutex_modifyserverusers);
- m_lszModifyServerUsers.push_back( strdup((*g)[i]) );
- pthread_mutex_unlock(mutex_modifyserverusers);
}
}
@@ -154,10 +147,6 @@
// Keep track of who has been done
users.push_back(strdup(pUser-IdString()));
doneUsers.push_back(strdup(pUser-IdString()));
-
-pthread_mutex_lock(mutex_modifyserverusers);
-m_lszModifyServerUsers.push_back(strdup());
-pthread_mutex_unlock(mutex_modifyserverusers);
}
}
}
@@ -180,26 +169,17 @@
if (pUser-IgnoreList() pUser-GetSID() == 0)
{
ignoredUsers.push_back(strdup(pUser-IdString()));
- pthread_mutex_lock(mutex_modifyserverusers);
- m_lszModifyServerUsers.push_back(strdup());
- pthread_mutex_unlock(mutex_modifyserverusers);
}
else
{
if (pUser-InvisibleList() pUser-GetInvisibleSID() == 0)
{
invisibleUsers.push_back(strdup(pUser-IdString()));
-pthread_mutex_lock(mutex_modifyserverusers);
-m_lszModifyServerUsers.push_back(strdup());
-pthread_mutex_unlock(mutex_modifyserverusers);
}
if (pUser-VisibleList() pUser-GetVisibleSID() == 0)
{
visibleUsers.push_back(strdup(pUser-IdString()));
-pthread_mutex_lock(mutex_modifyserverusers);
-m_lszModifyServerUsers.push_back(strdup());
-pthread_mutex_unlock(mutex_modifyserverusers);
}
}
}
@@ -225,6 +205,7 @@
CSrvPacketTcp *pExport = new CPU_ExportToServerList(users, _nType);
gLog.Info(tr(%sExporting users to server contact list...\n), L_SRVxSTR);
+ addToModifyUsers(pExport-SubSequence(), );
SendEvent_Server(pExport);
CSrvPacketTcp *pEnd = new CPU_GenericFamily(ICQ_SNACxFAM_LIST,
@@ -239,9 +220,7 @@
CSrvPacketTcp *pReply;
pReply = new CPU_UpdateToServerList(, ICQ_ROSTxGROUP, 0);
- pthread_mutex_lock(mutex_modifyserverusers);
- m_lszModifyServerUsers.push_back(strdup());
- pthread_mutex_unlock(mutex_modifyserverusers);
+ addToModifyUsers(pReply-SubSequence(), );
gLog.Info(tr(%sUpdating top level group.\n), L_SRVxSTR);
SendExpectEvent_Server(0, pReply, NULL);
@@ -255,9 +234,7 @@
pReply = new CPU_UpdateToServerList((*g)[i], ICQ_ROSTxGROUP,
(*gID)[i]);
gLog.Info(tr(%sUpdating group %s.\n), L_SRVxSTR, (*g)[i]);
- pthread_mutex_lock(mutex_modifyserverusers);
- m_lszModifyServerUsers.push_back(strdup());
- pthread_mutex_unlock(mutex_modifyserverusers);
+ addToModifyUsers(pReply-SubSequence(), );
SendExpectEvent_Server(0, pReply, NULL);
}
}
@@ -275,13 +252,10 @@
ICQ_SNACxLIST_ROSTxEDITxSTART);
SendEvent_Server(pStart);
- pthread_mutex_lock(mutex_modifyserverusers
[Licq-devel] Re: Coding style
On Wednesday 27 June 2007 02:05, Erik Johansson wrote:
Except for the ones I've commeted on below, I fully agree.
I will update the Wiki page on my lunch break or after work then :)
I don't think we should ban varargs. For e.g. log functions it's
really useful. But we should try very hard to avoid it.
Useful, but not very C++ like. varargs removes any type checking of parameters
to the functions, which makes us rely on printf's formatting that is prone to
errors and unsafe by nature. I think using boost::format would be much better
than C's varargs and the printf family.
Take a look here for more details, the syntax is a bit different, but it
provides type checking and is much safer:
http://www.boost.org/libs/format/index.html
The same here, for some problems, it's just the best solution to use
snprintf and friends. But as above, try to avoid them but if needed
use the secure variants (that take a size argument).
Yes, the secure variants are better. But why not just use C++'s methods? Using
boost makes it pretty easy and like I said above, will give us proper usage
of C++.
I agree that we should use exceptions, but we have to be careful when
throwing across DSO:s (http://gcc.gnu.org/wiki/Visibility).
Plugins shouldn't really be throwing beyond themselves. We should probably
specify that in the Plugin documention.
Where it makes sense, I'm all for it.
I'm pretty sure it is much easier to find examples of when it makes sense than
when it doesn't make sense. Using the STL's algorithms techniques makes us
code in a way that keeps one function to one task. For example...
void ICQ::Logoff()
{
// Mark all users as offline
for_each(users changeStatus(user, offline));
// other work
}
is much better than...
void ICQ::Logoff()
{
// Mark all users as offline
for (iter = users.begin(); ... ++iter)
{
user-setStatus(offline);
// other offline work
}
}
and lets C++ create an optimal loop where we don't have to worry about the
parameters as much..
for (iter = users.begin(); ... ++iter)
changeStatus(*iter, offline);
Jon
--
Jon KeatingICQ: 16325723
[EMAIL PROTECTED] MSN: [EMAIL PROTECTED]
http://www.licq.orgGPG: 2290A71F
http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Protocol Version
On Tuesday 26 June 2007 22:14, Sebastian Renzi wrote: I have some packet dumps, in fact I believe I sent some to you when you started working on it. Honestly I'm not familiarized with licq code, but I can give it a try. Maybe you can send me what you've done, so I have something to start with. Well, a good place is to add some code where we receive a user's status. Check to see if they have an Xtraz status, and if so extract it. That would be the 1st step. If you could get it to print the hex dump to the status (or any other format, whichever is easiest for you), that would be a good starting point. Then we will need to map it to a name and icon. Ah, to get the Xtraz status, I believe we have to send it in the CompatiblityFlags as well. I'll see if I have some code somewhere and post that if I can find it. Also... custom icons will also need to be supported, but that is a different task :) Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Coding style
I put some comments of mine in here. If there are any sections I obmitted, that is my way of agreeing in silence. On Sunday 24 June 2007 18:45, Erik Johansson wrote: It shouldn't matter which way to write them but my vote is on /**, mostly because that's the way I've already started commenting new classes in the qt4-gui. +1 on /**. +2 Where it makes sense to add a reference, I'm all for it. But not to every bugfix. Of course not all rules, but the ones that may help to read the code and why there are certain changes. * Indentation in switch blocks should be described. As the 'case' lines are only labels and not statements, some will not add an indentation step for them but I think it improves readability. Fine by me. Feel free to add it to the wiki :) I cringe at code that doesn't indent case labels. It just feels wrong. * Global variables should be mentioned. Add the usual text that they're evil and then describe a naming convention (if we have any) for the rare cases when they are used anyway. The singleton pattern can be used in all places where we currently use globals, so my vote is on banning globals. Yes for singletons, Nay for globals. * The usage of NULL vs. using 0 should be specified. I remember discussing this in #licq and I think it should be specified which to use. (I still say that NULL is a C constant and that 0 is that thing to use in C++ but I can accept 0 if that's what everyone else wants to use.) NULL for pointers, 0 for integers. (In gcc NULL is defined as a special symbol and not 0. So besides making it clear that something is a pointer, it can actually help catch mistakes. And, IIRC, the upcoming c++ standard will actually introduce null as a keyword.) I don't like using macros unless absolutely necessary. And NULL is a macro, which makes it a hack to C++. I'm pretty sure even Stroustrup has said that he doesn't use NULL. * Specify whether the following is good or bad: if (x) return; Bad. Actually, I like this. It is still easy to see, as long as you use some decent syntax highlighting. But anyways, if anyone has an opinion about it I can go with that, doesn't really matter to me. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Coding style
On Sunday 24 June 2007 02:16, Erik Johansson wrote:
I would like to get started with merging some code from erijo-dev to
the newapi branch. But first I think we should agree on a common
coding style. I have updated http://trac.licq.org/wiki/CodingStyle to
reflect a discussion I had with Anders on #licq some time ago. I'm now
posting it here so that Jon (and others) can give their input as well.
I've given some opinions in the past and we talked on IRC awhile ago as well.
The current version is acceptable for me. The only thing left is the
Commenting section. I think the following points should be added to it:
* Use Doxygen style comments for all function/class definitions. [1]
* When a bug is fixed, add comments to the changed code and reference the
bug number.
* Don't add useless comments [2]
Anything else that you can think of?
Jon
[1]
/// or /** ?
[2]
/** Do some work
*
* @return int
*/
int functionName()
{
// ...
// return the value of x
return x;
}
Insead of return the value of x, a more descriptive comment should be
used. Return the number of errors ... Return the return value from
otherFunc()... If there is no other comment that will help improve the
readability of the code, don't write a comment.
--
Jon KeatingICQ: 16325723
[EMAIL PROTECTED] MSN: [EMAIL PROTECTED]
http://www.licq.orgGPG: 2290A71F
http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Protocol Version
On Friday 22 June 2007 07:57, Sebastian Renzi wrote: Some time ago, the protocol version reported by licq was v9, but lately I've seen licq report v8 again. Is there a reason for that? I changed it to v9 to properly imitate the version tht used xtraz statuses. But it wasn't complete so I backed it down just to be safe. Doing a simple version increment could make the server expect different versions of the protocol, so it needs some more testing just to be safe. What ever happened to that? Was it discarded or it was just delayed? Delayed. Need to fix some bugs first. Is there any way I can help to implement that? In my opinion knowing the real status is a major feature and should be given high priority. Yes, it is important. If you want to help out with it you will first have to get some packet dumps to see how it works. That is always the first part. I had some work done, but it wasn't complete yet so I'm not sure how much that would help you. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: spam-check on mails to licq-commits
On Wednesday 20 June 2007 06:04, Erik Johansson wrote: Jon: Is it possible to disable the spam check on mails going to licq-commits (and licq-tickets)? It seems like googlegroups messes with the mail headers so that autolearn=no version=3.2.0 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on fanfic.org is put first in every mail, instead of staying in the header section as it should. I'll take a look into it. CC'ing Dennis, just in case if he has the chance to look into it before me. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Current SVN
In future versions of Licq, we will be using CMake and the boost libraries. I was thinking of doing that conversion with the current trunk in SVN. With boost, I think it is pretty common to have it installed and if not, easily available. So that would not be a problem, right? As for CMake, I'm not quite sure how much of it is working with Licq. Any input on this Erik? Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] SVN Commit E-mails
The [EMAIL PROTECTED] e-mails will have a different from address with the current setup. Erik, can you send me your file that you were using? Specifically... /home/svn/svnmailer.conf Thanks, Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: protocol plugins
On 6/7/07, kkieling [EMAIL PROTECTED] wrote: i tried build a basic protocol plugin. after registering the plugin i run a select() on the pipe. the exit signal is transmitted without any problems. however, other signals dont work and the licq will die due to segmentation fault and never leave select(). Can you post your code somewhere? And what protocol are you working on implementing? any ideas? are there simple proto examples to play around with? MSN is the only protocol plugin out there. Their is a new API in the works, but it will be a little bit of time before it is working. Jon
[Licq-devel] Re: protocol plugins
On Thursday 07 June 2007 06:51, kkieling wrote: using select() instead of read() to wait for the input gives the same behaviour. i used fd_set f; FD_ZERO( f ); FD_SET( nPipe, f ); select( 1, f, NULL, NULL, NULL ); Having a source ball to look at it and play with might help some more. But first thing wrong I see with this is the select(1... do you really have only one file descriptor, and it is 0? If I'm not mistaken, 0 is the file descriptor for stdin.. you should be setting it to nPipe + 1. when i quit licq, an X is read. when other signals are sent (eg, changing online status), it breaks down. What kind of breakdown? What does gdb say? in the end, the plugin shall be a wrapper around skype, using the dbus interface. with the new skype 1.4 alpha this works pretty well, the only problem is my licq integration ;-) Does skype have a daemon mode as well then? Or do you have to run skype with a GUI to be able to access it? Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: trac and svn downtime
autolearn=no version=3.2.0 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on fanfic.org On Sunday 27 May 2007 22:54, Erik Johansson wrote: That would be good. My connection wont be as good as yours :( What will your new connection be like? I'll shutdown trac this evening and put all files on http://ejohansson.se/files/trac/. Does that work for you? Alright, I'll work on that in about 6 hours. Gonna go to bed now. What about SVN? I might not have time to work on setting that up until the Tuesday morning (Monday night for you I guess). Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Extending plugins
If you recall some previous conversations about the new API, one of the points where we got stuck on was how to add plugins of the plugins. For example, video chat. A video chat plugin can be made as an independent plugin, and it will provide the GUI _and_ network logic. Doing this is quite complicated... providing the hooks to the inner workings of the ICQ plugin and being able to modify the GUI. However, I think a good solution would be to make user of D-Bus[1]. The Qt-GUI and protocol plugins can export an interface to the outside world that any program in any language (that has D-Bus support). Here is a quick overview of how it could potentially work: 1. A videochat plugin gets loaded, and adds a Video Chat to each user's send function menu. [QUserMenu::addMenu()] 2. The user selects Video Chat from the menu. 3. The videochat plugin, using hooks into CICQPlugin sends the request packets and gets the response. 4. The videochat plugin creates a window and displays it, staring the videochat. The nice part of this is that videochat plugin can be in C, C++, Python, etc. And the GUI portion can be GTK, Qt, etc. As long as the language and framework work with D-Bus, it doesn't matter. This can also be a way to get the options of plugins to be handled by the Qt-GUI. D-Bus isn't new, but when I was reading through the documentation and the Qt4 class[2], it seemed like it would be a good idea for Licq 2.0. Jon [1]: http://dbus.freedesktop.org/doc/dbus-tutorial.html [2]: http://doc.trolltech.com/4.2/intro-to-dbus.html -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Events in licq2
Just some responses to your questions. For the most part, what you said is what we have talked about :) I'll read it through again and try to find some parts to pick at ;) On 4/25/07, Erik Johansson [EMAIL PROTECTED] wrote: The question now is, what do you think about this proposal? I'm especially interested in comments on the event pipeline. Is this a good way to do things? What happens if a plugin crashes? Or simply drops an event? Should there be a timeout? As you described the pipeline, I think it is good. As for your questions... If an event gets dropped/stalled, the error recovery will be hard to decide dynamically. For example, if the message is encrypted and gets stuck/lost in the decrypter, the user can't see the message. This is pretty much the worst case scenario, so we should treat all problems within the pipeline as the worst case. So, what do we do? We'd have to save the original message so Licq can be re-run to decrypt the message. So, until the last plugin succesfully handles the event, we should keep a copy around just in case. As for a timeout, I don't think we should do that. If there is a problem with a plugin, the user can stop running it (restart Licq?). The error handling will keep the state, so the next time through the event will be processed properly. It may not sound like a good idea to treat all cases as the worst-case. But if we do treat it like that, we will have a (theoretically) good recovery plan that in the end, will keep the user from losing the data. Of course, it is easy to say here, but that is ideally what I want. Should it be possible to broadcast an event to all plugins at the same time? At first I thought it would be good to have, but I'm gonna have to say no to this. Mainly because the point of the pipeline is to allow plugins to alter events and their properties as seen fit by the plugin developers. If we make an exception, it may not be as flexible a system as we are designing it to be. What about pointers in event properties? Should we allow this or should they be value only? Definitely allow pointers. If we have large objects, we don't want to be having expensive copying operations throughout the pipeline. When a plugin sends an event, does it send it to the daemon and let it decide what to do with it, inform the daemon that this event should be sent to protocol plugin Y or does it send it directly to plugin Y? It should go through the daemon. Since we want to allow plugins to be connected at any point, the daemon will be taking care of that job for us. What about all the stuff I forgot to mention? :) Will have to think about this... Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Help with the Licq codebase
On 4/12/07, Munawar Hafiz [EMAIL PROTECTED] wrote: 1. Does the C/C++ code use the string library functions (strcpy, strcat, gets etc)? A quick grep of the sources will answer this. We use both the string library functions and the C++ std::string. 2. Or does it use some sort of buffer bounds checking, either by rewriting the string library, or checking before every buffer operation? The main bounds checking is done by strncat, strncpy and a few length checks. THere is nothing standard about it. 3. Is the bounds checking available from the first release, or it has been included in a subsequent release? How did the development team go about making this change in the code? It was in there from the beginning, but gradually improved. There was one patch submitter that did a lot of the converstions from str... to strn... function calls. That was after 1.0.0. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: History encoding
On 3/22/07, Stefan Haun [EMAIL PROTECTED] wrote: It seems, the files do not use a unique encoding, but store the message as-is, i.e. as it is sent by the peer. The other way around, if I change the encoding (say from ISO-8859-15 to UTF-8), the messages get stored in UTF-8, but the older messages are still in iso encoding. This becomes an issues when I review my history, because the encodings do not match. I have to admit, while living in America I didn't give a second thought to character encodings and didn't really understand them, since they didn't affect me. So, that is the root of the problem. In Japan there are 3 major types of character encodings, so I've gotten used to the issues with them and wish I would have fixed this a long time ago in Licq. - or convert the messages to an encoding used on the complete history How about we save everything as UTF-8? The main issue that remains is what to do with an existing history file that is not in UTF-8. I'm sure some of the users out there have hugs history files in their own encoding.. I know I do. I would create a patch on this, if it is still worth the work before Licq with the new API is released and which suggestion is better. Sure, getting it fixed is a priority. But like I said, what do we do about converting existing files to UTF-8? The way I see it, we can assume the user's local encoding and try to convert it to UTF-8. Of course there will be some failures, but unless the user's do it manually that is to be expected, unfortunately. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: History encoding
On 3/22/07, Stefan Haun [EMAIL PROTECTED] wrote: To achieve this, I'll do the following: - submit a patch for the history reading/writing mechanism to use UTF-8 only Sounds good. - code a script which converts the existing history into UTF-8, dependent on the per-user encoding settings Ahh yes, we can try and use this. There will be some encoding failures for sure. But that just means that the user can't even see the history unless they fiddle with the encoding settings anyways... Sometime this month, I hope. I can whip up an upgrade script for this on my lunch break some time as well if you want. Been meaning to work on the new API documents as well. I guess I have some stuff to keep me busy at lunch this week ;) Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Licq licq-osd: Faild to find LP_Name
On 3/23/07, Name [EMAIL PROTECTED] wrote: that's because But the next try goes good, plugin loads _work_. (c) me In the licq source directory(that you compiled from), what does this return: grep DLOPEN config.h If it is RTLD_NOW, edit the file and change it to RTLD_LAZY, recompile and see how it goes. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Licq licq-osd: Faild to find LP_Name
On 3/21/07, Name [EMAIL PROTECTED] wrote: Hi. I've installed from ports licq 1.3.4, icqnd licq-osd 1.2.7.2 on my FreeBSD system. When in icqnd gui i choose load licq-osd plugin i got message unable to load the plugin. Bun the next try goes good, plugin loads work. In my licq Network Monitor log i can see: 22:25:31: [ERR] Failed to find LP_Name() function in plugin (osd): Undefined symbol _LP_Name Usually this is because the compiler versions are different. Did you compile licq and all the plugins? If so, what is your gcc version? 22:26:27: [OSD] OSD Plugin initializing 22:26:27: [INI] Starting plugin OSD Plugin (version 1.3.2.1). But the above messages come after loading the plugin... so seems a bit strange actually. Can you send your FreeBSD version as well? -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: refusing messages sent through server from certain users
On 3/14/07, Pollywog [EMAIL PROTECTED] wrote: Is there a way to refuse messages sent through the server by certain users? If you open a bug on trac.licq.org it'll get taken care of (eventually). Put the milestone as 1.3.5. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Adding a user permanently (again)
On 1/27/07, Jon Keating [EMAIL PROTECTED] wrote: On 1/26/07, Joachim Staib [EMAIL PROTECTED] wrote: the ICQUser class has a construction parameter that lets you add a user temporary, so it's information will not be saved after shutting down Licq. However, how can a user be added permanently? Is there some way to set the m_bNotInList flag? There is actually an open bug about making the temporary user be a permanent user. It is actually marked as a high priority. http://trac.licq.org/ticket/724 And it has been updated to have an API call to add permamently. See the link above for the SVN diff. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Owner Document
On Feb 22, 1:48 am, Anders Olofsson [EMAIL PROTECTED] wrote: As I have understood it, protocol plugins would be treated differently from other plugins (use another API) at the plugin level. What I would like is to have all plugins handled the same way and move the protocol handling away from the plugin API. There shouldn't be different types of plugins when looking at the plugin API. This will allow one plugin to contain multiple types of functions and I think it would be messy in both the daemon and UIs to have different types of plugin APIs. Perhaps Erik can chime in? I agree, it would be nice to allow the plugins to be basically the same. With the code in erijo-dev, it appears to be that way now. But anyways, yes, I agree with you about this. Owner id and configuration for the owner is passed to the protocol instance from the daemon upon creation. The daemon will know which owners are configured and load them. Creating protocol instances will be part of that loading. Alright, sorry, I thought you were saying something else. I'm talking mostly about normal startup of a fully configured licq. Not the first run and setup. What you have written above sounds to me that the UI will be invoked on startup to start all owners. I'm assuming you mean it should just be used to create the owners the first time not every time licq is started. I'll work on improving the document to make the distinction clearer. And to go into more detail about a previously configured Licq. ini-file) I therefore wrote xml-block to refer to that data in whatever form it will be runtime. I was just visualizing passing around an XMLStream or something. Of course a loaded plugin will always result in the daemon holding some information about it. What I mean here is that there will be no threads, event handlers, sockets, etc active in an unused protocol plugin, only the bare minimum required to actually have the plugin loaded. So in otherwords, don't run StartPlugin (or whatever it will be called)... manager. The user should not be forced to immediatly create a user when the plugin is loaded the first time. (However, when the new protocol is registered this my generate an event allowing the UI to ask the user if he/she would like to create a new owner, but that should be up to the UI, not forced by the daemon.) Agreed. It doesn't have to be factories, replace factory in my text with any way to get instances of the protocol handlers from the plugins. I thought factories was the thing to use so I wrote it like that that. Well, it sounds like it will be good for user registration, at this point. Just was a caution in general. Jon
[Licq-devel] Re: Licq crashing Trillian?
On 2/18/07, Philipp Kolmann [EMAIL PROTECTED] wrote: yea, thats my forum post. I still have the same problem. I posted it to bugtraq but nothing happened. Seems noone at ceruleanstudios cares that their app seems shitty. Just release a CrashTrillian.c file and then they will fix it ;) -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Licq crashing Trillian?
On 2/18/07, Samuel Blomqvist [EMAIL PROTECTED] wrote: Do you think this is a Licq problem or a Trillian problem? If an application can be crashed remotely, it is a security hole of that program. Depending on the type of crash, it may be open to being exploited to run remote code. What is the Trillian version and is it the latest version? Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Weekly Meeting 20070204
The meeting log is attached to this e-mail. The following items were discuessed: * Creating documents of how to implement the different parts * Assigning people to certain documents * What parts of Licq 2.0 are needed still * 1.3.5 Release (before summer?) We will have the meeting next week, Feb. 11th (Sunday) at 13:00GMT. Same time, same place. Anyone interested in Licq development may come. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan --- Log opened Sun Feb 04 21:59:53 2007 22:00 @erijo howdy all 22:00 @emostar hello 22:00 @emostar and it is now 13:00GMT on the dot, so let's get this started! 22:01 @erijo what's on the agenda? 22:01 @emostar So, first thing on the list ... not a big surprise but Licq 2.0 22:01 @emostar Basically, what needs to be done, and how we can get it done in a timely manner 22:02 @emostar It's been awhile since I've even touched the new code, so it will need a quick review when I start it up again 22:02 @emostar but where it is now, the main core of the plugin - daemon interaction is done 22:03 @erijo i've been doing some experimenting, trying out a clean start 22:03 @emostar what i was working on last was the LicqOwner class and how to get it working in a clean manner 22:03 @emostar hmm, what is wrong with the current code? 22:03 Crazy_Hopper erijo, I thought you were experimenting with boost in whole... 22:04 @emostar thats what i thought as well... 22:05 @erijo i wanted to test the event passing without all the extra stuff that's in licq atm 22:05 @erijo to have a clean core without icq etc. 22:05 @emostar ahh 22:06 @erijo and also to get a pure interface that plugins can use 22:06 @erijo currently, the include directory includes a lot of files that are private to the licq daemon 22:06 @emostar yes.. it may be best to try and separate it a bit 22:07 @emostar of course, i am accustomed to the files so i know which ones to ignore 22:07 @erijo and by make interfaces, i think it should be easier to unit test 22:07 @erijo s/make/making/ 22:07 @emostar the pluginfactory is not in the newapi branch, right? 22:08 @erijo no 22:08 @emostar i guess that is the plugin manager? 22:08 Crazy_Hopper speaking about plugins.. it seems to me that they should gain somewhat like 'priority'.. a queue in which they receive events... 22:08 @erijo that's another problem i have with the code i wrote in newapi. one class does to much 22:09 @emostar Crazy_Hopper: yes, that is in the current api :) 22:10 @emostar seperating the plugin handling and informatino is better 22:10 @emostar so, in other words, lets go with erijo's current way of Factory and Information classes 22:11 @erijo i was hoping to get a core up, that could load plugins, start them and then pass events around 22:12 @emostar there was a patch on licq-dev that accomplished that. but i didn't quite like some of the parts changed 22:13 @emostar one thing i'd like to do though.. is to have some simple documents describing what we are coding 22:13 @emostar and have that reviewed before we do the coding 22:13 @emostar of course it may require some coding to check on the details of things.. but it wouldn't be final code 22:13 @emostar (or even draft?) 22:14 @emostar the main reason i think it's a good idea is so we don't have to change/throw away code that we've spent time on 22:14 @emostar cuz that really sucks :( 22:14 @erijo it's just that it's more fun to write code than text ;) 22:15 @emostar yeah, definitely.. but easier to review and discuss a doc talking about what we are gonna do 22:15 @emostar because there are always many different ways to code what we are gonna do 22:15 Crazy_Hopper coding is good, but in team it is better to know what exactly your partner is workiing on... 22:15 @erijo agree 22:16 @emostar so, first thing is deciding what we will work on 22:16 @emostar i'll take the owner creation/loading (since i have some rought drafts already) 22:17 @emostar the plugin core has informatino already on the wiki 22:17 @emostar so maybe just update that with the latest factory separation 22:18 @erijo i have some other changes i would like to propose for the plugin core as well 22:18 @emostar also, maybe a doc about the life of a plugin 22:18 @erijo My life as a plugin :) 22:18 @emostar creation - execution (events/info/etc) - destruction 22:18 -!- wwp [EMAIL PROTECTED] has quit [...---...] 22:18 @emostar doesnt have to be an autobiography ;) 22:18 @erijo i'd like to work on that 22:18 @emostar alright, sounds good 22:19 @emostar ah, one other thing.. we shouldn't have long waits to review documents.. maybe just once a week send it to licq-dev to be reviewed 22:19 -!- wwp [EMAIL PROTECTED] has joined #licq 22:19 @emostar even if it is only a little bit.. perhaps a little bit is preferred
[Licq-devel] Re: Weekly Meetings
On 2/1/07, Erik Johansson [EMAIL PROTECTED] wrote: What about sunday afternoon/night? Say 13:00 or 14:00 GMT? Hmm, 22:00 on a Sunday should be workable. Let's give it a try this Sunday and see how many people show up. So, let's start at 13:00 GMT. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Weekly Meetings
On 2/1/07, Eugene Paskevich [EMAIL PROTECTED] wrote: Could someone please give me a clue on where those meetings are held? Is it IRC channel that I'm not aware of? They were held in the normal Licq IRC channel. Just we haven't had one for several months. You can take a look at the WIki on http://trac.licq.org for previous logs. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: [Licq-commits] r4825 - in /branches/qt-gui_qt4/src: mainwin.cpp optionsdlg.cpp outputwin.cpp securitydlg.cpp
Please do not ever change tabs/spaces on an entire file when you
commit to SVN. It makes the diff completly unreadable and
unreviewable. Can you please provide a diff of the changes you did
without the space changes so other people can see what actually has
changed?
Jon
Author: flynd
Date: Mon Jan 22 21:18:01 2007
New Revision: 4825
URL: http://svn.licq.org/viewvc/licq?rev=4825view=rev
Log:
Removed WhatsThis button from titlebar of dialogs that no longer uses it.
Modified:
nbsp; nbsp;branches/qt-gui_qt4/src/mainwin.cpp
nbsp; nbsp;branches/qt-gui_qt4/src/optionsdlg.cpp
nbsp; nbsp;branches/qt-gui_qt4/src/outputwin.cpp
nbsp; nbsp;branches/qt-gui_qt4/src/securitydlg.cpp
Modified: branches/qt-gui_qt4/src/mainwin.cpp
URL:
http://svn.licq.org/viewvc/licq/branches/qt-gui_qt4/src/mainwin.cpp?rev=4825r1=4824r2=4825view=diff
==
--- branches/qt-gui_qt4/src/mainwin.cpp (original)
+++ branches/qt-gui_qt4/src/mainwin.cpp Mon Jan 22 21:18:01 2007
@@ -4997,7 +4997,7 @@
nbsp;//
-
nbsp;HintsDlg::HintsDlg(QString hint)
- nbsp;: LicqDialog(0, HintsDlg, false, Qt::WDestructiveClose)
+ nbsp;: LicqDialog(0, HintsDlg, false, Qt::WDestructiveClose |
Qt::WindowTitleHint | Qt::WindowSystemMenuHint)
nbsp;{
nbsp; setCaption(tr(Licq - Hints));
Modified: branches/qt-gui_qt4/src/optionsdlg.cpp
URL:
http://svn.licq.org/viewvc/licq/branches/qt-gui_qt4/src/optionsdlg.cpp?rev=4825r1=4824r2=4825view=diff
==
--- branches/qt-gui_qt4/src/optionsdlg.cpp (original)
+++ branches/qt-gui_qt4/src/optionsdlg.cpp Mon Jan 22 21:18:01 2007
@@ -62,7 +62,7 @@
nbsp;OptionsDlg::OptionsDlg(CMainWindow *_mainwin, pages startPage, QWidget
*parent)
- nbsp;: LicqDialog(parent, OptionsDialog, false, Qt::WDestructiveClose)
+ nbsp;: LicqDialog(parent, OptionsDialog, false, Qt::WDestructiveClose |
Qt::WindowTitleHint | Qt::WindowSystemMenuHint)
nbsp;{
nbsp; setCaption(tr(Licq Options));
Modified: branches/qt-gui_qt4/src/outputwin.cpp
URL:
http://svn.licq.org/viewvc/licq/branches/qt-gui_qt4/src/outputwin.cpp?rev=4825r1=4824r2=4825view=diff
==
--- branches/qt-gui_qt4/src/outputwin.cpp (original)
+++ branches/qt-gui_qt4/src/outputwin.cpp Mon Jan 22 21:18:01 2007
@@ -46,7 +46,7 @@
nbsp;//---
nbsp;CQtLogWindow::CQtLogWindow(QWidget *parent)
- nbsp;: LicqDialog(parent, NetworkLog)
+ nbsp;: LicqDialog(parent, NetworkLog, false, Qt::WindowTitleHint |
Qt::WindowSystemMenuHint)
nbsp;{
nbsp; setCaption(tr(Licq Network Log));
Modified: branches/qt-gui_qt4/src/securitydlg.cpp
URL:
http://svn.licq.org/viewvc/licq/branches/qt-gui_qt4/src/securitydlg.cpp?rev=4825r1=4824r2=4825view=diff
==
--- branches/qt-gui_qt4/src/securitydlg.cpp (original)
+++ branches/qt-gui_qt4/src/securitydlg.cpp Mon Jan 22 21:18:01 2007
@@ -40,7 +40,7 @@
nbsp;SecurityDlg::SecurityDlg(CICQDaemon *s, CSignalManager *_sigman,
nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp;
nbsp; nbsp;QWidget *parent)
- nbsp; : LicqDialog(parent, SecurityDialog, false, Qt::WDestructiveClose )
+ nbsp; : LicqDialog(parent, SecurityDialog, false, Qt::WDestructiveClose |
Qt::WindowTitleHint | Qt::WindowSystemMenuHint)
nbsp;{
nbsp; server = s;
nbsp; sigman = _sigman;
--
Jon KeatingICQ: 16325723
[EMAIL PROTECTED] MSN: [EMAIL PROTECTED]
http://www.licq.orgGPG: 2290A71F
http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: weird code
On 1/8/07, Ladislav Michnovič [EMAIL PROTECTED] wrote: I was pointed at weird code which could be problematic to evaluate for gcc. Here is the patch: Thanks, commited in r4813. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: wiki.licq.org
On 11/30/06, Erik Johansson [EMAIL PROTECTED] wrote: The wiki at wiki.licq.org is being spamed pretty often nowdays. Maybe it's time to remove it and just use trac.licq.org. All material that's in English should be on trac already. Sorry for the delay, I just updated the DNS to have wiki be a CNAME for trac.ejohansson.se. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: newapi patch
On 12/1/06, Martin Garbe [EMAIL PROTECTED] wrote: here is a patch for newapi. If you apply this you can log into the rms plugin with username and password while using msn protocol plugin. It all compiles fine. Although it compiles fine, there are some basics about it that can be improved. For example, don't pass std::string to functions by value. As for the other parts, I'll have to review them more. But it's nice to know the basic architecture is working. I'll have sometime this weekend, I've been busy with work and had a test I was studying for as well. Hopefully I'll be moving in a few weeks and will have more free time as well. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Re: Typing notification issues
Or the real fix is to put all protocol related functionality into the daemon or protocol plugin. The real fix will be included in the new API. But for now, this will get fixed in the qtgui Jon
[Licq-devel] Re: MSN SSL error
Ill take a look at it tonight, but perhaps you can tell me what happens if you connect to that port via HTTPS in a web browser? Jon
[Licq-devel] Re: Rename Makefile.cvs to Makefile.s
Jon here, using my cellphone to reply. I would like to see us test out CMake and after KDE has given it their stamp of approval, have Licq switch to it as well. I will talk more about it in a later email. As for the Makefile name change, I think there is no reason to change it. In fact, it would break any auto build scripts and make any current docs not compatible. Jon
[Licq-devel] Re: Userinfo question
On 10/19/06, Arne Schmitz [EMAIL PROTECTED] wrote: Also the UpdateAllUsers is -- as I said -- quite broken. Maybe we would have to split it in smaller request chunks? Or pause for 0.1 seconds between each request? Not sure, though. Any ideas? The proper solution is to implement the system to send messages in accordance with the limits the server sets when we sign on. And to obey the warnings it sends us as well. I'll see about adding it to Trac. I've done some work in understanding the packets already. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
[Licq-devel] Licq 1.3.4
We are happy to announce the final release of Licq 1.3.4! The pace of development has increased mainly due to Erik Johansson joining the team, and an increase of patch writers. So, without further ado I'd like to say thanks to the following people with this release: * Patrick Cernko * Peter Colberg * Mitch Davis * Quentin Denis * Martin Garbe * Ignatiy Goloviznin * Christian Heim * Daniel Hess * Philipp Kolmann * Danil Krivopustov * Geoffrey Lee * Roger Oksanen * Eugene Paskevich * Sebastian Renzi * Arne Schmitz * Joachim Staib * Alexey Varjat And to see what we have done with this release, please take a look at the detailed release notes at this URL: http://trac.licq.org/wiki/DeveloperArea/ReleaseNotes/1.3.4 The SourceForge download links are at the bottom of this announcement, currently we only have source tarballs. If you want to contribute a binary, please send an e-mail to the Licq-Users mailing list. Thanks to everyone and enjoy 1.3.4! Jon and The Licq Team * http://prdownloads.sourceforge.net/licq/licq-1.3.4.tar.bz2?download * http://prdownloads.sourceforge.net/licq/licq-1.3.4.tar.gz?download -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan pgpkwD8KT0Sfv.pgp Description: PGP signature
[Licq-devel] Re: SSL negotiation
On 9/30/06, Eugene Paskevich [EMAIL PROTECTED] wrote: Please tell me, were there any changes in SSL negotiation code? I have noticed that I'm unable to make successful negotiation to clients running versions less then 1.3.4-rc1. No, there haven't been any changes. Are you sure you are able to make a direct connection with those users? That is probably the #1 problem with getting SSL to work. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
Re: qt-gui: smilies, icons and skin
On 9/27/06, Arne Schmitz [EMAIL PROTECTED] wrote: Am Sonntag, 24. September 2006 15:34 schrieb Quentin Denis: - the KDE icons: an iconset based on the well-known crystal icons from Everaldo. It makes licq look much nicer, espacially in a KDE environment! ;) @Thomas: I'm not very satisfied about the extended icons, but I hope it does not matter that I took over 4 phone-icons from yours! :) I like the KDE icons and have added them to the SVN repository. I even think we could use them as the default. I don't know about the Mirabelis icon sets, though. How do we handle this? The KDE icons are GPL, afaik, but Mirabelis... Mirabelis icons are fine. We can include them unless told otherwise, which hasn't happened yet. Jon -- Jon KeatingICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.orgGPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
