Once again we had our weekly meeting, it was our 3rd one and we are starting to get more people to come and participate in the discussions. Here is a summary of what was discussed:
* Handling of responsibilities
* Rapp will be taking care of the mailing lists
* rsLeo will help with maintaining and improving the website
* Agrajag and Rapp will help test/review patches
* Agrajag will be the new release engineer
* Rapp will assist with the German translation if Thomas (both?)
are unable to.
* The new Licq API will use parts of the Boost library
(www.boost.org) for implementing details. I'd also like to see more
usage of the STL. There are many good books out there about C++/STL
and designing with these. Look for books by Herb Stutter and Scott
Meyers if you are interested (of course Bjarne Stroustrup's book is
good too ;)
* More details of the new API were discussed
* Sending events to users will be done by a function in the user's
class
* How to handle multiple accounts on the same protocol
simultaneously
* Plugins of plugins was mentioned (i.e. for video chat)
In 2 weeks, I won't be available for the meeting on Wednesday. If you
guys want to have it late on Tuesday, that would be better for me.
Wednesday - Sunday will be my holiday (Golden Week in Japan), so I
might not be around much. I will probably be going on a short trip
somewhere.
That's all for now.
Jon
--
________________________________________________________
Jon Keating ICQ: 16325723
[EMAIL PROTECTED] MSN: [EMAIL PROTECTED]
http://www.licq.org GPG: 2290A71F
http://www.thejon.org HOME: Minamiashigara, Japan
--- Log opened Wed Apr 19 20:04:49 2006 20:05 <@emostar> So, let's start, ok? 20:05 < Rapp> ok 20:05 <@Agrajag-> yep 20:05 < QnD> yup 20:05 <@emostar> I added some more information to the Wiki, not a whole lot, but have more to discuss. 20:06 <@emostar> As for the protocol event structure, like QnD said on the mailing list, an interface that provides a generic interface to set/get data should be implemented. 20:07 <@emostar> I have been playing around with a few different implementations and thought perhaps using the Boost library would be nice. It has a lot of code that could come in handy. 20:07 < Rapp> like what in particular? 20:07 < QnD> Boost library ... what is it for? 20:07 <@emostar> smart_ptr in particular 20:08 <@emostar> its a collection of libraries.. some of which will probably make their way into standard C++ 20:08 < Rapp> QnD, www.boost.org 20:08 <@emostar> they have some libraries that deal with generic templates 20:08 < Rapp> hm, ok. smart_ptr is a nice thing. 20:08 < QnD> never heard :) 20:08 <@emostar> let me show some example code... 20:09 < Rapp> they actually have a whole lot of support classes, for almost everything... 20:09 <@emostar> http://licq.pastebin.com/668973 20:10 <@emostar> yes, i find them very useful. the only thing i would be worried about is how hard is it to distribute them with licq, so people don't have to go and download the boost libraries to compile licq. 20:10 < QnD> what in your paste was boost-code now? everything? 20:10 < Rapp> QnD, the shared_ptr 20:10 <@emostar> shared_ptr is Boost code 20:11 < Rapp> emostar, boost is part of every major distro now... 20:11 < QnD> and what does it do? 20:11 < Rapp> i don't think it would be a very hard limitation 20:11 <@emostar> CEventData is a template... so you cannot have it in an STL container (the way we want at least) 20:11 < Rapp> QnD, keeps track of who still references the pointer 20:11 <@emostar> so you have 2 options, create a base class that does nothing and make a list of that 20:11 <@emostar> or use share_ptr 20:11 < QnD> nice 20:12 <@emostar> also does memory deallocation on its own 20:12 <@emostar> similiar to std::auto_ptr 20:12 < QnD> nicer 20:12 <@Agrajag-> sounds good 20:12 < Rapp> http://www.boost.org/libs/smart_ptr/shared_ptr.htm 20:12 < Rapp> better than auto_ptr actually. the latter cannot be shared 20:12 <@emostar> Rapp: hmm dont think it is in my distro... 20:12 < Rapp> really? 20:12 < Rapp> what do you use? 20:13 < Rapp> opensuse and debian contain it 20:13 <@emostar> Slackware 10.0 20:13 < Rapp> ok :) 20:13 < Rapp> but people with slackware know how to install it :) 20:13 <@emostar> and its in fedora.. 20:14 <@emostar> i believe it can be bundled with licq.. there isnt anything to really compile (3 libs??). most of the work is in the header files. 20:14 < Rapp> thats true 20:14 < Rapp> but one problem is always: having the most recent versions... 20:14 <@Agrajag-> but then i guess you'd want to keep that up to date with boost 20:14 < agliv5> This might be a stupid question, but I'm new to Linux so here it goes: Can PC games that are designed for windows be run under Linux? 20:14 <@emostar> if we Boost, then http://wiki.licq.org/?title=LicqCallback should use shared_ptr instead of the base class that does nothing. 20:14 <@Agrajag-> agliv5: this isn't the place to ask that 20:15 < agliv5> I know 20:15 < Rapp> agliv5, look up cadega and wine. and ask on another channel :) 20:15 < QnD> hm, boost seems to be cool, but I still don't understand why we need this 20:15 < Rapp> QnD, helps with the development 20:15 < Rapp> higher level code -> easier maintenance 20:15 <@emostar> QnD: it provides code that we will implement.. so theoretically things are faster if we have the code in a library already ;) 20:15 < Rapp> since emostar is doing most of it it would be great for other people to step in :) 20:16 < QnD> hm, however - will propably understand it later ;) 20:16 <@Agrajag-> if you think we're only going to use a small part of it then i guess it's ok bundling it 20:16 <@emostar> QnD: function - Function object wrappers for deferred calls or callbacks, 20:16 <@emostar> it has that.. not sure if we really need it though. 20:17 <@Agrajag-> were there any other libraries/frameworks/whatever that you came across? 20:17 < Rapp> so, is there -- apart from boos -- a top plan for today? what has to be clarified? 20:17 <@emostar> Agrajag-: not really.. 20:17 < Rapp> s/boos/boost 20:18 < rsLeo> work sharing 20:18 <@emostar> Rapp: yes, seeing about getting some responsiblities to other people 20:18 < Rapp> ok. what tasks do have to distributed? 20:19 <@emostar> Mailing list admin... Release engineer (releases arent often so should be easy).. Web site improvements/maintenace.. Reviewing patches.. 20:20 <@Agrajag-> i'm the release engineer at work (and we use svn) so i'll be happy to do that :) 20:20 < Rapp> i read on the wiki thomas reitelbach isn't active anymore? do we still have someone watching the german i18n? 20:20 <@emostar> thomas is busy with other things... he told me he'd still like to help out with the german translation though 20:20 < Rapp> mailing list admin -- i could do that, i guess? what's the job? 20:20 <@Agrajag-> i'll be happy to review patches for parts of licq that i understand 20:21 <@emostar> Agrajag-: I'll get some documentation about how i have been doing the releases into the wiki soon 20:21 < Rapp> emostar, otherwise i could do the german translation. 20:21 < QnD> what about general development? 20:21 <@emostar> incoming paste...... 20:21 <@emostar> Message from DreamForce 20:21 <@emostar> Sat Feb 18 19:07:44 2006 [----] 20:21 <@emostar> anyway, from time to time i would like to update the german translation since licq still is my favorite client and _when_ i use ICQ, then it's licq ?? 20:21 <@emostar> Message from DreamForce 20:21 <@emostar> Sat Feb 18 19:06:49 2006 [----] 20:21 <@emostar> as you know, i'm no longer active with licq anymore. i've become the project leader of the german i18n KDE team and this takes most of my free time. 20:21 <@emostar> Rapp: mailing list admin is just checking the queue and deleting spam and allowing messages though 20:22 < Rapp> well, i guess i could do that :) 20:22 <@emostar> i do that when i get around to it.. but sometimes valid messages get held off for a month :\ 20:22 <@Agrajag-> if more than one person is needed i'll help with that too 20:22 <@emostar> Rapp: I'll give you the URLs and passwords after i setup your account. i just need your e-mail address 20:22 <@emostar> Agrajag-: sure, the more the merrier ;) 20:23 <@emostar> phone.. brb 20:23 < rsLeo> I could do website improvements 20:23 * Rapp has icq # 49247365 -- would be nice to be able to talk to you all :) 20:24 < agliv5> emostar how'd you end up being the project leader of a german team? 20:24 < Rapp> agliv5, no, not he... 20:24 <@Agrajag-> emostar: that's not him that's DreamForce 20:24 < Rapp> thomas is 20:24 <@Agrajag-> err 20:24 < QnD> ... but these are the smaller tasks. I hoped to see a list concerning some more important stuff 20:24 <@Agrajag-> agliv5 rather 20:24 <@emostar> just a min 20:27 <@emostar> rsLeo: i'll give the info to you when i get the server finished 20:27 < rsLeo> ok 20:28 <@emostar> Agrajag-: ahhh... yes 20:32 < QnD> hm ... still on the phone :)? 20:32 <@emostar> yes...... 20:33 < agliv5> I know this isn't really the right forum, but nobody else is answering me... I can log in as su, but sudo for example doesn't work... I get a password incorrect error... what's up with that? 20:33 <@Agrajag-> agliv5: join #ubuntu 20:34 < agliv5> I am in Ubuntu 20:34 < Rapp> agliv5, no, join the channel #ubuntu -- type /join #ubuntu in your irc client 20:34 < Rapp> please!! :) 20:34 < agliv5> I've been asking questions all morning and I haven't goten a single reply 20:34 <@emostar> back 20:34 < QnD> for doing sudo you need to type in the users password and not your root password 20:35 <@Agrajag-> agliv5: perhaps because you're asking questions that are well documented and could be solved with a simple google search 20:35 < agliv5> Of course I know that THIS forum is Licq 20:35 < Rapp> back to business 20:35 <@emostar> yes 20:36 <@emostar> so if we could get some people to work on patches, the main thing is testing that it works and doesn't break anything 20:36 <@emostar> and if it works, just send a note to the email list that it worked or what problems there were 20:37 < agliv5> Agrajag- I aggree that 99% of the questions that I asked today were solved by google, but what am I supposed to search for whith authentication problems? 20:38 < Rapp> hm, ok. i could do that, but my time is a bit limited, sadly. i also got some ideas for small patches that annoy me and some friends of mine. but diving into the licq code is the biggest problem.... 20:38 <@emostar> agliv5: please hold on to the questions for later.. we only get to meet once a week, so we have to stay focused 20:38 <@Agrajag-> emostar: ok, so what sort of patches are we talking about here? changes to the api? updating existing plugins to work with the new api? 20:38 < agliv5> oh I'm sorry I didn't know I was inturupting SORRY 20:39 <@emostar> agliv5: no worries.. we'll be done in an hour i believe 20:39 <@emostar> just generic patches sent by other people 20:39 <@Agrajag-> ah right ok 20:40 <@emostar> they are usually small and easy to test... but its nice to have other people help out cuz sometimes i get many small patches in the queue that takes a long time 20:40 <@emostar> so, perhaps we can talk about the API now? 20:40 < QnD> YES! 20:40 <@emostar> hehe ;) 20:40 <@Agrajag-> hehe yep 20:41 <@Agrajag-> brb 20:41 <@emostar> there is one major point that i haven't addressed yet in the wiki or in my own documents that i scribble.. 20:41 -!- sgt-d [EMAIL PROTECTED] has quit ["mIRC Power Pack 8.00 (www.mIRCPowerPack.com) by sod/sgt-d ([EMAIL PROTECTED])"] 20:41 <@emostar> another main advantage of redoing the API is to allow multiple accounts for the same protocol 20:42 < QnD> sure 20:42 <@emostar> at a lowlevel, it means the protocol will have to have more than one instance running.. 20:44 <@emostar> at a higher level.. the API has to specify with instance to use 20:44 < QnD> if the protocol was an object this wouldn't be THAT problem, I think. Something like you wrote in your wiki "daemon->pushToProto(u->getPPID(), "send-message", pMsgData);" would be not ideal then, better is "daemon->pushToProto(u->getProtocol() "send-message", pMsgData);" (where getProtocol() gets the address of the protocol object) 20:44 < Rapp> will the protocol plugins still be realized through .so files? or will they be just statically linked to the daemon? 20:44 <@emostar> Rapp: .so files 20:45 <@emostar> QnD: well the main issue is if i have the same user on 2 accounts. 20:45 < QnD> i don't know how hard it is in a lowlevel way to make out which pakets come from which user of the same proto 20:45 < Rapp> QnD, i guess they will arrive on different ports? 20:45 <@emostar> at the low level (in the daemon) it has to match the user to the protocol instance. the common denominator is the account owner. 20:46 < Rapp> ah, that way around, ok 20:46 < QnD> ah, okay. so every instance of a proto object would receive everything and then decide whether it drops the packet (wrong account) or not ... 20:46 <@emostar> a user object will have to be aware of its owner.. 20:47 <@emostar> QnD: the daemon's job is to make sure it goes to the correct place 20:47 <@emostar> putting that work in the protocol plugin makes it complex for the protocol plugind evelopers 20:47 < QnD> yes, but to do this the deamon already has to understand icq packets for example. and this is not his task 20:47 <@emostar> the daemon needs to ensure everything goes where it is intended to go, in the correct order 20:48 <@emostar> well, the daemon doesnt know about icq packets.. its just pushing signals/events around 20:48 < Rapp> oh, i see 20:48 <@emostar> inside the signal/event needs to be something to tie it with the correct plugin instance 20:48 < Rapp> sounds clever 20:48 < Rapp> the daemon is only some sort of switch routing the signals around 20:49 <@emostar> yes.. and as we discussed before, the daemon wont even know what it is pushing around exactly.. it just obeys the rules it has.. 20:49 < Rapp> icq packets will only be dealt with in the icq protocol plugin, right? 20:49 <@emostar> yes 20:49 < Rapp> yeah 20:49 < Rapp> cool 20:49 < Rapp> sounds good 20:50 < Rapp> maybe you should put a drawing in the wiki? :) 20:50 < QnD> hm, havn't got that right ... what if there is a proto plugin now and it is sending packets to the icq server. another proto plugin also does this and now two packets come back. how will the proto plugin know which packet is for which instance? 20:50 < Rapp> QnD, they will be received on different ports 20:50 < Rapp> and each proto plugin listens on a different port 20:50 <@emostar> the socket descriptor is unique for each protocol plugin 20:51 < QnD> i don't have much experience with the core of the icq proto, but I've always thought it's always on 5190 20:51 < Rapp> QnD, on the server side, yes 20:51 <@emostar> thats the remote port ;) 20:51 < QnD> aaaahh, okay :) 20:51 < Rapp> QnD, read up on basic network programming :) 20:51 <@emostar> on the local side, we just listen to the descriptor that is connected to the server 20:51 <@emostar> its nothing different than what licq does now if there is an icq and msn account both online 20:51 < QnD> Rapp: might be a good idea 20:51 < Rapp> and that will be some random port number 20:52 <@emostar> but for example.. if ICQ#1 and ICQ#2 is online.. the plugin will tell ICQ#2 to go away 20:52 <@emostar> so the daemon needs to send the "status-change" signal only to ICQ#2 20:52 < Rapp> great, so emostar, you basically have to do a detailed sketch of the API, the functions and their semantics, and then everyone can implement some of the functionality :) your ideas sound simple enough... :)) 20:53 < QnD> why should it tell this to ICQ#2? 20:53 <@emostar> Rapp: yeah.. the only hard put is putting it all together to a complete whole. currently im slowly piecing it together.. then will put the final glue together when all the small parts are ready 20:54 <@emostar> for example.. the qt-gui has an icq status flower for each instance 20:54 < Rapp> ok 20:54 <@emostar> the user tells one account to change status 20:54 < QnD> yep 20:54 <@emostar> currently it is done by specifying the protocol id... 20:54 <@emostar> but if we support multiple accouns with the same protocol.. it needs more than a protocol id 20:54 <@emostar> it needs an id for that instance 20:54 < Rapp> actually, we could even use the Qt signal/slot scheme for this... 20:55 <@Agrajag-> Rapp: no i don't think so 20:55 < Rapp> and the daemon could connect() the parts? 20:55 < Rapp> ok, why not? 20:55 < QnD> that's what I meant above. don't use the protocol ID as an argument but the proto object itself 20:55 <@Agrajag-> Rapp: other plugins shouldn't need qt dependancies 20:55 <@emostar> Rapp: techinally.. thats what we are doing 20:55 < Rapp> that's true 20:55 <@emostar> Rapp: that part is mentioned in the wiki.. and in the previous 2 meeting logs ;) 20:55 * Rapp blushes 20:55 < Rapp> oops 20:56 < rsLeo> why should a person login to one protocol with different account at the same time? 20:56 <@emostar> QnD: the protocol ID? hmm.. that works with sending events like "logon" "change-status" .. etc 20:56 <@emostar> but "send-message" will need more i believe 20:56 < Rapp> rsLeo, because one for spam, one regular. one for the wife, one for the spouse... :) 20:56 < Rapp> doing it that way is also more general, and thus much simpler. 20:56 < Rapp> since it is not harder to implement 20:57 < rsLeo> ok 20:57 <@emostar> rsLeo: you can then send test messages to yourself to debug your new features ;) 20:57 < Rapp> lol 20:57 < QnD> at the moment I cannot imagine why ... with the proto obj address everything is given the daemon could need -> the protocol instance. 20:58 < rsLeo> emostar: for testing i can use -b at the moment and start multiple instances. 20:58 -!- erijo [EMAIL PROTECTED] has joined #licq 20:58 <@emostar> hmm.. just seems like a bit of a burden on the plugins to maintain the object id for everything.. 20:58 <@emostar> rsLeo: yeah.. but you can do it in the same instance.. just was joking anywyas 20:59 <@emostar> when it sends a message, it needs to object id then... 21:00 < QnD> don't see a burden here ... when you want to do something with a user (eg sending him a message) you always have his proto 21:00 <@emostar> i was thinking that a user would have an owner.. and then the daemon can map the owner to the protocol instance 21:01 <@emostar> but one protocol can have 2 instances.. 21:01 < rsLeo> why not using the socket id to identify a protocol/user 21:02 <@emostar> the user object needs to have some reference to the protocol instance..... 21:03 < QnD> I don't think that's very obvious. generally I don't really understand why for example "sendEvent" is a function of the daemon and not of a user (which then passes the event to the daemon) 21:03 <@emostar> that way the plugins can just do: pushToProto(pUser, "send-msg", pData); or something similiar. 21:04 <@emostar> QnD: hmm interesting idea 21:04 <@emostar> perhaps that is easiest for the plugins 21:05 <@emostar> the daemon will do the push event to the protocol.. so the plugin just calls send message.. 21:05 <@emostar> ahh 21:05 <@emostar> the reason we dont do that is because the daemon doesnt know what a message is technically 21:06 < QnD> in the end the thing that is done concerns the user and not the daemon, so it should be a user function. Something like LicqUser->SendEvent("name", variables);. This function then calls the daemon with the right plugin instance as a parameter (or the socket descriptor, however - although I think using the socket descriptor as a parameter would break a good abstraction-leveled system) 21:07 <@emostar> user->sendEvent("send-message", pData); should be sufficient 21:07 <@emostar> like you said ;) 21:07 < QnD> yeah ;) 21:08 <@emostar> giving the plugin a socket descriptor is asking for trouble close(sockFD); 21:09 < QnD> what do you mean with that? 21:10 <@emostar> the plugin can disconnect protocol plugins if we give it a socket descriptor.. 21:10 <@emostar> but anyways.. 21:11 < QnD> also using an ID which is not the proto instance address would require a list in the daemon that can allocate the ID to the instance... 21:12 < agliv5> Are you all still in a meeting? I promise it's a Licq question :) 21:12 < QnD> (the list of loaded instances should be there anyway but there's no need to do an ID-comparison to find the right proto instance 21:12 < rsLeo> agliv5: yes still in meeting 21:13 <@emostar> yeah.. will have to work on some implementations... perhaps you can write something up in the wiki while im still working on the main api? 21:13 <@emostar> agliv5: you can ask if its about licq.. just dont expect an immediate reply 21:13 < QnD> yes 21:14 < QnD> another thing I wanted to talk about is a common abstract protocol interface 21:14 < agliv5> Can I install using Slackware's installation guide or is the guide to old? Is there a more up-to-date guide somewhere? 21:15 <@emostar> QnD: alright.. go ahead 21:15 < QnD> i don't know much about the core stuff of protocols but it would be cool if there was a common interface which every protocol plugin supports 21:15 <@emostar> agliv5: its old.. but may still work, not much has changed 21:16 < agliv5> Oh yeah, and the link to the unofficial Licq manual is dead 21:16 < agliv5> emostar thanks I'll do my best 21:16 * Rapp is back. sorry... had to work.... 21:16 < QnD> something very basic like sendPacket(&packetData); 21:16 <@emostar> QnD: that can be done... having a base plugin implement some of the basic functions and then the base plugin connects the callbacks to the daemon 21:16 < QnD> or something 21:17 <@emostar> hmm yes.. we do have licq_socket.h 21:17 < QnD> the purpose of this simple API should be the possibility to extend it by other plugins - and here comes the all beloved "shake window" example again 21:19 < QnD> a "shake window"-plugin then could look for the existence of the MSN plugin (if its not there it just stops). if it IS there it tries to get the exported lowlevel functions, something like daemon->getPlugins("MSN"); and then plugin1->sendPacket(&shakewindowPacket); 21:20 <@emostar> it will also need to be able to connect callbacks to the daemon.. 21:21 < QnD> yes, of course ... it's a normal plugin that can also add "services" 21:22 < QnD> it adds the service "shake window" where the main window (which is maybe also influenced by this plugin) then listens to 21:22 < QnD> main window -> message window 21:22 < QnD> not "main window" 21:23 <@emostar> we could do all that.... but is it necessary to add the overhead of plugins of plugins when it can just be in the plugin? 21:24 < QnD> sure, but I'm thinking of things like video chat which are (probably) complicated enough for an own plugin ... 21:24 <@emostar> hmmm yeah 21:24 < QnD> or "push to talk" or "icq games" or things like that. things that might not be wanted by everybody. whoever likes the features can add them by plugins 21:25 < QnD> (this kind of plugins then are probably "hybrid" plugins which serve GUI AND protocol stuff) 21:26 <@emostar> yes, this will need some design work done too if we are to implement it 21:26 <@emostar> i was thinking that too actually 21:27 < QnD> hm yes... I have some concrete ideas but havn't articulated them yet - will do this and post a message in licq-devel 21:28 <@emostar> sounds good 21:29 < agliv5> Do I need to use qt 2.0.2 as the guide instructs or should I use a newer version? 21:29 <@emostar> agliv5: take a look at the website, it has the requirements (qt 3.0 or higher) 21:30 < QnD> there are also other things I was thinking about GUI stuff but this is still too far away. just wanted to throw my 5ct in the round before I have to go (which is now) 21:30 < QnD> see you next week 21:30 <@emostar> alright, well you can always add it to the wiki or send a mail.. 21:30 <@emostar> ok, talk with you later 21:31 < QnD> great - have a nice evening 21:31 -!- QnD [EMAIL PROTECTED] has quit ["... und tschüß"] 21:34 <@emostar> anyone around? 21:34 < erijo> emostar: Have you considered making the daemon a separate process and making it possible to connect to it with more than one "gui" at the same time? 21:35 <@emostar> erijo: thats what the new api would allow 21:35 < erijo> ahh great 21:36 <@emostar> there is some basic support for it now.. but it wasnt done that way by design 21:36 <@emostar> so it doesnt work perfectly.. 21:36 <@emostar> but the new api is being designed to support plugins in the correct manner.. 21:37 < erijo> this would mean it's possible to have the daemon on a server and connect to it remotely over tcp/ip, or? 21:37 <@emostar> hmm.. no.. 21:38 <@emostar> if thats what you want.. even with the current api it can be done that way if someone writes an interface for the rms plugin 21:38 <@emostar> i think 4 years ago i made a basic win32 interface for the rms plugin 21:39 <@emostar> never released it.. and it got lost.. but it really was basic 21:40 < erijo> ok. I might have to take a look at it when the development of the new licq is started... 21:41 < erijo> it would be a great feature 21:41 < Rapp> (also still here) so, when do you think will some final draft of the API be ready? 21:41 <@emostar> erijo: i think you can do the work now with the RMS plugin 21:42 <@emostar> that part of the rms plugin won't change... just the inner workings will change 21:42 < rsLeo> Why would spellchecker be a protocol plugin? 21:43 <@emostar> Rapp: good question... depends how much time i spend on it.. i've been reading some new C++ books i have as i go along to see if it can be improved 21:43 <@emostar> rsLeo: it wouldnt be.. 21:44 < rsLeo> In one of your last mails you said "It's better to say protocol plugins (PP) and general plugins (GP). (RMS isn't a GUI and spellecheker won't be a GUI)." 21:45 <@emostar> yes.. a spellchecker would be a GP (General Plugin, not GUI plugin) 21:45 <@emostar> i was saying that GUI Plugins will be called GP (General Plugins) 21:45 < erijo> I most definitely will take a look at it when I get back home 21:46 < rsLeo> ok, i see 21:48 < rsLeo> i have to go. cu next week. 21:48 <@emostar> alright, thanks for coming 21:49 <@emostar> Rapp: I guess we can finish it now? 21:50 < Rapp> sure :) 21:50 < Rapp> gotta get back to work, too --- Log closed Wed Apr 19 21:50:20 2006
pgpYe0IdUfXEs.pgp
Description: PGP signature
