kitclient-devel Mailing List for Kit AIM Client
Brought to you by:
kit
Menu
▾
▴
kitclient-devel — Discussion of Kit development
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(16) |
Oct
(19) |
Nov
(4) |
Dec
(24) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(10) |
Feb
(6) |
Mar
(11) |
Apr
(1) |
May
|
Jun
|
Jul
(5) |
Aug
(6) |
Sep
(3) |
Oct
(2) |
Nov
(7) |
Dec
(1) |
| 2002 |
Jan
(1) |
Feb
|
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jim B. <Bla...@yi...> - 2002-05-01 00:09:13
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 30 April 2002 01:58 am, dominique devriese wrote: > Op dinsdag 30 april 2002 10:23, schreef u: > > OK, now that I have had some time to apply and test your patch, it lo= oks > > like there are a couple things we need to fix. The hash that the jab= ber > > server uses is actually computed by concatenating the session ID (sen= t by > > the server in the "id" attribute of its <stream> tag) with the passwo= rd, > > running this string through the SHA-1 algorithm to generate a 20-byte > > hash, then converting the hash into a 40-character hex representation= =2E=20 > > So the code has been changed to grab the session ID, which is working= , > > but the other two are not. First, we need a 40 character hex string.= =20 > > Write now the code only produces a 32 char string (probably borrowed = code > > from MD5). I changed the ksha file and added the extra 4 %02x, but th= is > > is still generating bad hashes. I haven't been able to follow the co= de > > very well, so I am still not sure where the problem is. For refrence,= the > > psi client has this working, so here are some of the values. > > Hi, i've implemented the code directly from the RFC > (http://www.ietf.org/rfc/rfc3174.txt?number=3D3174) > There will prolly be some bug in there somewhere: as i said, i hadn't b= een > able to test the code yet... > Or maybe the RFC and the w3c (which the jabber protocol reference point= s > to) are talking about different versions of the hash (?) > Anyway, i'm willing to fix this for you if you want, but first read > below... As far as I know the versions should be the same, although I haven't look= ed at=20 it much. I was kind of putting that stuff off :) > > > hash string | psi's digest | ksha1's digest > > 1784195969wrongpass | 81f1efd91575d752e4ad228c56345d60adb60210 | > > 61b761b114dd10407cb463dfda10aad9cd274fd3 > > 184972892pass | 187d36293171046be561dfc4d6c62cec09c8c70b | > > 33f34de9f548b1c9f6f3271b6785602912ef463b > > > > Also, is it necessary to link to the provided ksha1 file, or can we j= ust > > use the kmdcodec files in kdelibs? Thanks for the info and help, > > Well, this is the problem: in the patch i sent you, i had included it a= s a > patch to kjabber. But since then, kjabber seems to have disappeared fr= om > cvs (?). kjabber is a module under kitclient. So just go to the sourceforge kitcli= ent=20 page and checkout the kjabber module. A working version with a qsock=20 implementation is availible with the -D "1/21/02 10:00:00 UTC" option, wh= ile=20 HEAD uses kextsock.=20 > Also since then, i had thought it was best to just put this in > kmdcodec.h/cpp, which is done (it was in cvs the last time i checked), = but > i have been talking with George Staikos, and it prolly won't stay there > (he's not sure what to do with KMD5 either). > The problem is that if we start putting all these hash algo's in the > kdelibs, this can become unnecessarily large, and since most kde apps d= on't > require them, it doesn't seem like the right way to go... Sounds reasonable. I'll just keep using my local version then (with the=20 correction for hexDigest). > > In the mean time, i also lost the patch i sent you (i've been doing lot= s of > things wrong here :( > > Conclusion: it's not clear yet what's going to happen to this code, but= if > you want, and send me your current code, or tell me where to get it, i'= m > willing to fix this SHA1 implementation, but it would have to be in you= r > source only, i do think it can use the kcodecs class from kmdcodec... The HEAD branch in cvs contains the original ksha files that you sent me = with=20 your modifying patch. =20 > > domi > PS: what is the deal by the way with KJabber and Psi, i can't find kjab= ber > anywhere in cvs, and psi only contains a libpsi... Why don't psi and > kjabber merge ? Psi is using Qt only, kjabber is being designed to work with KDE. Althou= gh=20 there is not much of a difference here, it is important. Specificly, the= use=20 of KExtendedSocket instead of QSocket is critical for people behind a=20 firewall or using SOCKS, since kextsock can use global settings and we do= n't=20 have to implement these protocols ourselves in the client. Also, psi is=20 using a more C style implementaion (structs) of messages, presnece and=20 packets. I have tried to develop more robust objects that should be able= to=20 be more extendable in the future. psi aslo parses the xml from the serve= r=20 without relying as much on Qt, while I have tried to use QDom for almost = all=20 XML manipulation. On the other hand, psi has a well working library with= =20 many features, and very active development. Kopete also seems to have a=20 jabber plugin springing up, but again it is using qsocket, which confuses= me=20 a little since it is a kde program. I haven't read its code closely at a= ll,=20 so I don't have much else to say about that. In any case, I think a working KSHA library would be usefull elsewhere in= KDE,=20 so I would be happy to help test this one and I think it would be a good = idea=20 to continue its development. kit...@li...urceforge is being = used=20 to discuss kjabber and kit, and you can talk to either me (Blackfoot) or = Neil=20 on #kde on the openprojects network if you have any general questions. =20 Thanks for your help, - --=20 Jim Blomo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjzPMh0ACgkQUlS7JsvyVRI+LwCeJWzQRhhpynTJoLOMtuL1AHFq +v0An2FyhSaoVnIq4cBom06SP2Qs7wh2 =3DiD3D -----END PGP SIGNATURE----- |
|
From: Jim B. <Bla...@yi...> - 2002-04-29 07:32:35
|
First I would like to thank Dominique Devriese for supplying a patch to=20 support SHA1 encrypted passwords. Not only has he helped add a valuable=20 feature, but he has got me motivated again. KExtendedSocket has never worked with kjabber. =20 How it should work: KExtendedSocket is used as the source for a QDomDocum= ent. =20 The QDomQodument parses the full xml tag and then we can decide what to d= o=20 with it. setSource takes a QIODevice, which K*Extended*Socket (eventuall= y)=20 inherits from. However, when QDom parses the socket, we get an error:=20 unexpected end of file on the first character, and we can never get any d= ata=20 from the socket. =20 How it does work: QSocket (also inheriting from QIODevice) seems to be wo= rking=20 perfectly (check out with the -D "1/21/02 10:00:00 UTC" option). =20 Why this isn't a solution: QSocket does not support SOCkS or other networ= k=20 settings that users can specifiy and that all kde compliant programs shou= ld=20 use. =20 Why other solutions don't work: Getting data from KExtendedSocket a diffe= rent=20 way. This would require passing a refrence to the readBlock funtion. Th= is=20 would requiring either having enough buffer size for anything the server = will=20 throw your way or parsing the chuncks that you do grab into the buffer. = Now=20 the first option might be impossible for file transfers, and the second=20 option kind of defeats the purpose of using QDom for parsing. KSock is n= ot=20 derived from QIODevice, so we can't use that. I would appreciate suggestions on how to work around this, or an explanat= ion=20 of kextsock's noncompliant behavior. Untill then, I will probably be usi= ng=20 QSock to continue development. Thanks, --=20 Jim Blomo |
|
From: Jim B. <Bla...@yi...> - 2002-04-09 08:29:24
|
Checking to see if I can send to list. Please ignore. Jim |
|
From: Neil S. <ne...@qu...> - 2002-01-25 02:06:03
|
please ignore, testing -- Neil Stevens ne...@qu... Don't think of a bug as a problem. Think of it as a call to action. |
|
From: Neil S. <ne...@qu...> - 2001-12-02 22:48:36
|
To anyone who's monitoring Kit 2 progress... I just compiled and installed libkjabber and kit 2, and used it to connect to jabber.org, and received messages with it. I think Kit 2 in KDE 3.1 should be a reasonable goal. -- Neil Stevens ne...@qu... Don't think of a bug as a problem. Think of it as a call to action. |
|
From: Neil S. <ne...@qu...> - 2001-11-29 02:27:27
|
Wow... a lot is there now! I'll try to see about porting Kit to it in the next week or so. Really. :-) -- Neil Stevens ne...@qu... Don't think of a bug as a problem. Think of it as a call to action. |
|
From: Jim B. <Bla...@yi...> - 2001-11-19 10:40:29
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 18 November 2001 04:40 pm, Neil Stevens wrote: > So, how *are* things going on kjabber? > > Aside from the network code, how fully featured is the protcol side? The code in cvs is not fully featured. It contains questionable support for some of the iq namespaces. Because I realized how ugly that code was, and had a couple ideas on how to make it better, I am totally rewriting that section. Messages are simple to deal with, because we basicly format it and send it to the UI. Presence are also fairly simple; they have an added step of updating the Roster with their availability. Presences are also the low level way one adds contacts to one's roster, so some work has to be done there too, but all of that should theoreticly be working now. iq types are where we need the big improvment. Because there are lots of different namespaces (functions) that can go under here we need to handle each in different ways, which is what I am doing now. As soon as I get the framework fleshed out, I will update cvs and anyone who wants to make it more complete can work on that. A lot of it will just be formating the XML into some appropriet Qt format, and signalling out. I think this new way will also make it easier for the inevitable increase in namespaces we will see as jabber grows. Expect the cvs update by Wednesday, 11/21. Thanks in advance for the new folks who are interested in the project. We have two main areas of development: UI which Neil is handling, and KJabber, which I am mainly doing. Even if you are very interested in the UI, please take a peak at kjabber and see if you can help out any there; we can't use the UI untill we can actually connect to a server :) Jim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjv44YYACgkQUlS7JsvyVRLUZQCeIWKnCOHcYc3yVN3mrnek3vmh GwYAnRzSXFPmFFchTs4KuCmD83ePA/1c =TZYk -----END PGP SIGNATURE----- |
|
From: Neil S. <ne...@qu...> - 2001-11-19 05:53:54
|
On Sunday November 18, 2001 09:41, Duncan Mac-Vicar Prett wrote: > Yeah :-) > > Ok, I will start reading a lot, I need to learn very well cvs, the > Makefiles you use, and of course more kde, qt > > My wishlist for a decent jabber client is: > - A good docking with icon theme support (and we must provide the > classics ones: the icq flower, the aim one, msn one, jabber one, etc) That's something that can be handled on the KDE side. Kit need take no action to allow icon styles. > - A nice contact list where is no difference between a icq buddy or a > aim one. may be just they can use different icons. That's inherent in jabber. Whether a jid is ne...@ja..., pre...@ai..., presjpolk%irc...@ir... or whatever, they're all treated the same as equal jids. > - Nice setup wizards.... like helping the user to choose a jabber > server. Definitely planned. > The contact list of common jabber clients is confusing for newbies and > people that come from other IM systems, Jabber supports various > "resources" of a buddy like "office" "home" etc. A smart contact list > should show just once the contact..... and no make a confusing tree for > every buddy in the list. Again I'd be just fine with turning off display of groups. I might even make it default, as you suggest. > You should be able to associate nice icons to transports, buddys, > resources, etc. > > Any suggestion? I'd have to think on that one. Overall you make good points, and I look forward to your input in future development. -- Neil Stevens ne...@qu... Don't think of a bug as a problem. Think of it as a call to action. |
|
From: Duncan Mac-V. P. <du...@kd...> - 2001-11-19 05:42:20
|
Yeah :-) Ok, I will start reading a lot, I need to learn very well cvs, the Makefiles you use, and of course more kde, qt My wishlist for a decent jabber client is: - A good docking with icon theme support (and we must provide the classics ones: the icq flower, the aim one, msn one, jabber one, etc) - A nice contact list where is no difference between a icq buddy or a aim one. may be just they can use different icons. - Nice setup wizards.... like helping the user to choose a jabber server. The contact list of common jabber clients is confusing for newbies and people that come from other IM systems, Jabber supports various "resources" of a buddy like "office" "home" etc. A smart contact list should show just once the contact..... and no make a confusing tree for every buddy in the list. You should be able to associate nice icons to transports, buddys, resources, etc. Any suggestion? Duncan On Monday 19 November 2001 01:50, you wrote: > On Sunday November 18, 2001 08:43, Duncan Mac-Vicar Prett wrote: > > On Sunday 18 November 2001 21:40, you wrote: > > > So, how *are* things going on kjabber? > > > > > > Aside from the network code, how fully featured is the protcol side? > > > > New newbie developer here :-) > > > > Duncan (a.k.a BaRRiL) > > Yeah, I sent my status question when I saw your subscription notice, so > that you'd know the list works. :-) |
|
From: Neil S. <ne...@qu...> - 2001-11-19 04:47:48
|
On Sunday November 18, 2001 08:43, Duncan Mac-Vicar Prett wrote: > On Sunday 18 November 2001 21:40, you wrote: > > So, how *are* things going on kjabber? > > > > Aside from the network code, how fully featured is the protcol side? > > New newbie developer here :-) > > Duncan (a.k.a BaRRiL) Yeah, I sent my status question when I saw your subscription notice, so that you'd know the list works. :-) -- Neil Stevens ne...@qu... Don't think of a bug as a problem. Think of it as a call to action. |
|
From: Duncan Mac-V. P. <du...@kd...> - 2001-11-19 04:43:31
|
On Sunday 18 November 2001 21:40, you wrote: > So, how *are* things going on kjabber? > > Aside from the network code, how fully featured is the protcol side? New newbie developer here :-) Duncan (a.k.a BaRRiL) |
|
From: Neil S. <ne...@qu...> - 2001-11-19 00:37:50
|
So, how *are* things going on kjabber? Aside from the network code, how fully featured is the protcol side? -- Neil Stevens ne...@qu... Don't think of a bug as a problem. Think of it as a call to action. |
|
From: Neil S. <ne...@qu...> - 2001-10-09 17:03:08
|
On Tuesday October 09, 2001 12:37, Jim Blomo wrote: > Talking with Neil (correct me if I'm wrong), development will be two > pronged. I will be focusing on getting KJabber to work, and possibly > looking at expanding it. Since jabberoo was primarily focused on > chatting, and KJabber was modled after it, KJabber will have to become > more robust to accomodate some of jabber's other features like browsing. right. > The other half of development will be concerned with overhauling (full > rewrite?) libkit with two goals. First, splitting kitwindow into two > logical components so that each handles one specific job. Second, > optimized use of the new stuff we have to work with: qt3, kde3, and > kjabber. Already we have seen the disappearance of ilk like > StringToQString, and I look forward to more changes. right. Time to update... -- Neil Stevens ne...@qu... "I fear all we have done is to awaken a sleeping giant and fill him with a terrible resolve." - Yamamoto Isoroku |
|
From: Jim B. <Bla...@yi...> - 2001-10-09 07:37:47
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes, that's right, the slumbering project has awakened and is running once again, for better or worse! The cvs version of kjabber, libkit, and myplugin now compile and run with qt3/kde3 and kjabber. One can even play around with the settings and whatnot. However, merely attempting to get online freezes the program, so obviously a lot of work needs to be done. Talking with Neil (correct me if I'm wrong), development will be two pronged. I will be focusing on getting KJabber to work, and possibly looking at expanding it. Since jabberoo was primarily focused on chatting, and KJabber was modled after it, KJabber will have to become more robust to accomodate some of jabber's other features like browsing. The other half of development will be concerned with overhauling (full rewrite?) libkit with two goals. First, splitting kitwindow into two logical components so that each handles one specific job. Second, optimized use of the new stuff we have to work with: qt3, kde3, and kjabber. Already we have seen the disappearance of ilk like StringToQString, and I look forward to more changes. So when this gets done, will anyone actually be able to use it? Yes! Despite appearances when connecting to either jabber.org or jabber.com, the Agents that connect to other IM services work quite well. This is because some (AOL comes to mind) are blocking jabber sites' IP addresses. However, I have set up a jabber server on my box (blackfoot.reshall.berkeley.edu) that communicates perfectly with AIM (I tested using a windows client), among others. If you would like to be able to access it, I need to add your domain to hosts.allowed, so email me. This is only for testing, as the server will not be running 24/7 (or anything close to it), and I may need to delete/reinstall entire directory for testing purposes. As always, help is appreciated if you are interested. Have a good week, Jim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjvCqUcACgkQUlS7JsvyVRIG8gCcDkFKOhYBMp3P/Uensguw63NQ TxAAn3Ob3jVwKyQhYpP+MRl/iS3qlQr2 =b2yt -----END PGP SIGNATURE----- |
|
From: Neil S. <ne...@qu...> - 2001-09-26 03:59:58
|
On Tuesday September 25, 2001 08:45, Neil Stevens wrote: > I cvs update with eagerness. :-) wow.. everything compiles, even make check.. when I'm not tired I'll look at what it is exactly that I compiled :-) -- Neil Stevens ne...@qu... "I fear all we have done is to awaken a sleeping giant and fill him with a terrible resolve." - Yamamoto Isoroku |
|
From: Neil S. <ne...@qu...> - 2001-09-26 03:44:20
|
On Tuesday September 25, 2001 08:15, Jim Blomo wrote: > So I made the first commit to kjabber in months last night, starting off > what will hopefully be some solid development and testing. The commits > were just some changes in the way the test programs output, but I was > also testing to see if the base classes were working with the cvs > version of qt3 and kde3 (they are). My next step is reviewing the code > to make sure it complies with and uses the new/changed stuff in qt3 > since the last beta I looked at. Once testing is done with all the > classes, its just a matter of plugging it into kit's framework, which > hopefully won't be that hard considering I've kept the API very similar. > Help is always welcome! Perfect timing, I did a full compile of qt-copy, kdelibs, kdebase, and some more today. I cvs update with eagerness. :-) > PS Someone get AOL to open up to jabber so I can actually use this when > I'm done coding it. Well, AOL has fairly recently said they intend to open up AIM to server-server communications. That should open it up to Jabber. -- Neil Stevens ne...@qu... "I fear all we have done is to awaken a sleeping giant and fill him with a terrible resolve." - Yamamoto Isoroku |
|
From: Jim B. <Bla...@yi...> - 2001-09-26 03:17:25
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So I made the first commit to kjabber in months last night, starting off what will hopefully be some solid development and testing. The commits were just some changes in the way the test programs output, but I was also testing to see if the base classes were working with the cvs version of qt3 and kde3 (they are). My next step is reviewing the code to make sure it complies with and uses the new/changed stuff in qt3 since the last beta I looked at. Once testing is done with all the classes, its just a matter of plugging it into kit's framework, which hopefully won't be that hard considering I've kept the API very similar. Help is always welcome! Jim PS Someone get AOL to open up to jabber so I can actually use this when I'm done coding it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuxSEYACgkQUlS7JsvyVRIOwACeId5VJI3hXwvlmew+75cHh94v LBwAni/qK4L76wfYhw5x6X0pxiwgUw/V =HIRP -----END PGP SIGNATURE----- |
|
From: Neil S. <ne...@qu...> - 2001-08-29 05:40:06
|
Playing with my new scanner I put a new logo on http://kitclient.sourceforge.net/ ... -- Neil Stevens ne...@qu... Don't think of a bug as a problem. Think of it as a call to action. |
|
From: Neil S. <ne...@qu...> - 2001-08-29 00:47:51
|
On Tuesday August 28, 2001 09:50, Bjorn Helgaas wrote: > I had kit working with SOCKS (I started it with "socksify kit"). Then I > upgraded to KDE 2.2.0, and kit stopped working. Unfortunately I don't > know the exact version that used to work; I think it was KDE 2.1.x. You're using Kit 1, that comes with KDE? KDE 2.2 has built-in SOCKS support, which Kit 1 will take advantage of. This mailing list is for development of the Jabber Kit 2 client. -- Neil Stevens ne...@qu... Don't think of a bug as a problem. Think of it as a call to action. |
|
From: Bjorn H. <bjo...@hp...> - 2001-08-28 16:49:07
|
I had kit working with SOCKS (I started it with "socksify kit"). Then I upgraded to KDE 2.2.0, and kit stopped working. Unfortunately I don't know the exact version that used to work; I think it was KDE 2.1.x. I'm using the Dante SOCKS client, and other applications still work fine (i.e., "socksify cvs update", "socksify ftp", etc, work). When I start up kit with "socksify kit" and try to go online, kit dies and I get a message like this: $ socksify kit $ Aug 28 10:39:18 kit[766]: Rconnect(): 15.1.50.190.53 15.1.50.190 is a machine inside our firewall, but not my socks server. Not sure where that comes from. When I configure SOCKS in KDE, the "Auto detect" and "Use Dante" options don't work (the Test button says SOCKS couldn't be loaded). Maybe Debian puts Dante in a strange place. When I specify a custom library path of /usr/lib/libdsocksd.so.0, the Test button says SOCKS was found and initialized correctly, but when I then try to start up kit, I get the following when trying to go online: $ kit $ Aug 28 10:45:35 KDE[773]: Rconnect(): 64.12.163.199.9898 Any suggestions or ideas of things to try would be greatly appreciated! Bjorn |
|
From: Neil S. <ne...@qu...> - 2001-08-15 12:26:47
|
I propose we split the projects Kit and libkjabber, with me retaining maintenance of Kit, and Jim (if he wants it) being the lead developer/maintainer of KJabber. Sound like a good idea? Jim: Would you like to take over libkjabber? Do you have time? -- Neil Stevens ne...@qu... Don't think of a bug as a problem. Think of it as a call to action. |
|
From: James B. <jb...@uc...> - 2001-08-10 05:29:00
|
I just rsynced Qt3 (and it hasn't changed for a while, which means it stabilizing == good) and built everything, including check. I did not have change KDE_OPTIONS or any other system variables. Some background information: for the regular kde cvs build I have /usr/local/qt symlinked to /usr/src/kde-cvs/qt-copy. The rsynced version of Qt3 is in /usr/src/qt3, and is built but *not* "make install"ed. Configure options were: "-prefix /usr/src/qt3 -debug -qt-gif -no-g++-exceptions -system-jpeg -no-tablet". Both qt directories are in ld.so.conf, but QTDIR points to qt2. Steps to compile kjabber: ./configure --enable-debug --with-qt-dir=/usr/src/qt3 make ## this gives you the error: ## roster_meta_unload.cpp:5: `objectDict' ## undeclared ## open test_roster_meta_unload.cpp, insert the line ## "Q_EXPORT QObjectDictionary *objectDict;" make make check ## this gives you the error: ## test_roster_meta_unload.cpp:5: `objectDict' ## undeclared ## open test_roster_meta_unload.cpp, insert the line ## "Q_EXPORT QObjectDictionary *objectDict;" make check The only warning this build gives is when running test-roster: "/usr/bin/ld: warning: libqt.so.2, needed by /usr/local/kde/lib/libDCOP.so, may conflict with libqt.so.3". Since we don't use DCOP, I don't think this is a problem, and it will go away with the qt3 conversion anyway. The final class, kjabber, I cannot compile yet because of inheritence problems; kextsock is derived from qt2's qsocket, and I mix in qt3's qsocket. For the most part, however, this class is coded. After this is tested, the next steps are intergrating it in the rest of kit2 (which shouldn't be much trouble as the API hasn't changed much), converting plugins and such to use kjabber's packet types, then adding more robust support for things like vcards, agents, encryptino, and other advanced jabber features. After that I have some new ideas about plugins, but that is a long way off. I don't see much happening until kde3 (cvs HEAD) becomes compilable regularly, both becuase this is important, and I will be busy with the start of school until then. Cheers, -- Jim Blomo <Bla...@yi...> <jb...@uc...> Lazy programmers are the best programmers. Think Tom Sawyer painting the fence. That's intelligence. -Linus Torvalds search.keyserver.net |
|
From: Neil S. <ne...@qu...> - 2001-08-05 23:12:52
|
Well, I finally got Qt 3 from rsync to compile, so I set about compiling kjabber.. After adding KDE_OPTIONS=qtonly to the top of the kjabber/Makefile.am and kjabber/test/Makefile.am to turn off meta unload, the lib itself would build. However, make check still fails for me becuase -lqt is picking up /usr/lib/libqt.so... almost there, though :-) I suspect soon enough that CVS kdelibs will require Qt 3, so our problems will be solved that way. -- Neil Stevens ne...@qu... Don't think of a bug as a problem. Think of it as a call to action. |
|
From: Neil S. <ne...@qu...> - 2001-07-08 17:36:04
|
I suggest everyone get Qt 3 (either the beta 2 or the current source via rsync), as there's a *really* good chance the next KDE will use it. Hopefully we can base kjabber on it. -- Neil Stevens ne...@qu... Don't think of a bug as a problem. Think of it as a call to action. |
|
From: Neil S. <ne...@qu...> - 2001-07-07 14:38:35
|
I've imported a new module into the Kit sourceforge cvs - kjabber, with the basic makefiles ready to be filled in with libkjabber_SOURCES and whatnot. Let's not lose any sources again. Let's build some new momentum. -- Neil Stevens ne...@qu... Don't think of a bug as a problem. Think of it as a call to action. |
