Hello, Here is the log for this week's meeting. The items discussed were:
* How plugins can modify the GUI
* Options dialog
* Multiple instances of one protocol
* Some admin stuff.
Not a whole lot, but the plugins modifying/influencing the GUI is a big
topic by itself.
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 Tue May 16 20:02:30 2006 20:02 <@emostar> Alright, so who is here? 20:03 < rsLeo> i'm here 20:03 <@emostar> Hmm.. ok, rsLeo and emostar are here. 20:03 < erijo> I'm also here 20:03 <@emostar> erijo: first time? 20:04 <@emostar> erijo: ahh Erik? 20:04 < erijo> kind of, i've been reading the logs 20:04 < erijo> yupp 20:04 <@emostar> ok, i was just wondering who erijo was all of a sudden ;) 20:05 <@emostar> rsLeo: I will add your account to licq.org for editing the website soon. what has been taking so long is setting up the ACL policy. 20:05 <@emostar> looks like i can finish it soon though 20:05 < rsLeo> ok 20:06 <@emostar> the server is doing way too many things, so i have to make sure it all works 20:06 <@emostar> so, lets see about getting down to busines 20:07 < rsLeo> emostar: i wrote a mail to the licq mirror admin but nobody answered. 20:07 <@emostar> rsLeo: which admin? 20:07 < rsLeo> emostar: the people on licq site in the mirror section 20:07 <@emostar> ahh 20:08 <@emostar> I can setup the Canada one 20:08 <@emostar> just the German and .cz ones are unknown.. 20:08 <@emostar> i had shell access to the .de mirror.. but lost the ip with the crash 20:09 < rsLeo> is anybody using the mirrors? 20:09 < erijo> if you need a mirror in sweden I can host one on my server 20:09 <@emostar> havent had any complaints.. maybe they all just switched to the main server 20:09 <@emostar> erijo: sure, the more the merrier :) 20:09 < erijo> any info on how to do it? 20:10 < rsLeo> in 20 minutes i have to go. 20:10 <@emostar> setup a virtual host for www.se.licq.org and I'll upload the current website to svn 20:10 <@emostar> I'll send you a private e-mail with instructions 20:10 < erijo> k 20:11 < rsLeo> what are the topics for today? 20:11 <@emostar> I have changed the LicqCallback interface to use erijo's suggestions 20:12 <@emostar> I will commit those to SVN shortly, I was gonna get around to it this morning but wanted to confirm a few parts first 20:12 <@emostar> rsLeo: just a few topics of the api is all i have 20:13 < rsLeo> emostar: ok 20:13 <@emostar> after i get the plugin architecture done, someone should do the task of modifying the rms plugin. 20:13 <@emostar> while that is done, i will make a new class for protocol plugins 20:13 <@emostar> and update the daemon to use that 20:15 <@emostar> while we do all this, we should also work on completing the api specification 20:16 < rsLeo> the changed RMS uses the general plugin? 20:16 <@emostar> the main remaining parts are how plugins can modify the GUI and extending plugins (as Joachim said earlier about video chat) 20:16 < rsLeo> or is a general plugin? 20:16 <@emostar> After i commit the new pipeline stuff, i will commit my changes to rms. it uses the GeneralPlugin class as a parent. 20:17 <@emostar> it will then need to use the callbacks 20:17 <@emostar> and pushing signals to the daemon (change status, send message) 20:18 <@emostar> which also reminds me that the sending signals to the daemon API needs to be finished 20:20 <@emostar> so, any comments on anything? 20:21 < rsLeo> nothing at the moment 20:21 < erijo> I was thinking a bit about how protocol plugins can present options to e.g. qt-gui. 20:21 <@emostar> well one question is.. does the protocol plugin and general plugin modify the gui in the same way or different ways? 20:22 <@emostar> i've been thinking the same ways.. to allow maximum flexibility 20:23 < erijo> what about using a xml-format where the pps (protocol plugins) lays out exactly how the gui for changing options should look like? 20:24 < erijo> since if the gps is just given a list of options, it's hard to lay them out in a logical way without creating a hard dependence between the plugins 20:25 <@emostar> yeah.. that would require us to have a simple markup language for creating guis 20:25 < erijo> like: the qt-gui asks the daemon for the settingsfile for the icq plugin. it gets back the icq-options.xml which looks something like this 20:25 <@emostar> <gui_option> <checkbox label="Option Name>... 20:25 <@emostar> ah go ahead :) 20:26 < erijo> <tabs><tab> 20:26 < erijo> <vbox cols="2"><option ... /><option ... /></vbox> 20:27 <@emostar> and when the options get changed... how does it save the data? 20:27 < erijo> the idea is that you specify exactly how the options should be displayed (which would be translated to QVbox etc) 20:27 < erijo> for every option you have <option data="name"> 20:28 < erijo> then you use the boost::dict_something_i_dont_remember which have the value of the option name 20:28 <@emostar> that could be done.. but would require some big changes in the guis to comply with it i believe 20:29 <@emostar> but.. i think it is the best choice.. to allow all plugins to have a major impact on the gui 20:29 <@emostar> not only options, but other windows.. such as video chat for example.. 20:30 <@emostar> i'll admit that the one nice thing ICQ has done is making the Xtraz plugin API.. it looks like it can be quite powerful (but the API is closed to the public) 20:31 < erijo> what can be done with that? 20:31 <@emostar> it extends the protocol and adds features (most of which are crap..) 20:31 <@emostar> but the idea is nice 20:32 < rsLeo> sorry but i have to go. Would be nice if more can be discussed at the mailinglist. cu 20:32 <@emostar> rsLeo: ok, thanks for coming 20:34 <@emostar> I think plugins should be allowed to specify: Options Tab... Modify the main menu.. Modify user menus.. 20:34 <@emostar> with the menus they should be able to create submenus as well 20:36 < erijo> I was thinking about a class CPluginManager which would keep track of all available plugins and which plugins could query for information about other plugins. 20:37 < erijo> e.g. options, menus etc 20:38 <@emostar> hmm.. when would it be used? 20:39 < erijo> the original idea was that all plugins would come with a short text file describing them (name, version...) and this class would keep track of those. This way you don't have to load plugins to get that info. 20:40 <@emostar> yeah, that would be very useful to reduce the amount of handles and memory used.. 20:40 <@emostar> that way if you have 100 plugins in your folder it doesnt load all of them ;) 20:41 < erijo> qt-gui queries for protocol plugins and lists them so that the user can select one. She selects the icq plugin, which is loaded. The qt-gui then queries for the icq plugin's menus etc 20:42 < erijo> btw, will plugins run in their own thread? 20:42 <@emostar> yeah 20:43 <@emostar> if you look at licq_generalplugin.h there is a mention of how to start the thread 20:43 <@emostar> some thought will have to go into how protocol plugins modify menus with more than one instance active 20:44 < erijo> is more than one instance something that is planed for? 20:45 <@emostar> yes 20:45 <@emostar> you can be logged into 2 icq uin's simultaneously.. 20:45 <@emostar> or 1 icq uin and 1 aim screenname 20:46 <@emostar> or 40 20:46 <@emostar> :p 20:47 < erijo> 1 icq and 1 aim shouldn't be any problem. 2 icq on the other hand... 20:48 <@emostar> why would that be a problem? 20:49 <@emostar> icq and aim are the same thesedays.. the only difference is the username can't begin with a number for aim 20:49 <@emostar> some CAPS that we send are different.. but basically the same now 20:49 < erijo> i was thinking about how they would modify the gui 20:50 < erijo> especially when you have the same contact on both accounts 20:50 <@emostar> perhaps 2 types of menus... one for the general menu, which if alreayd present wont be erased but will call all instances 20:50 <@emostar> and then one for the user which calls a specific instance 20:51 <@emostar> yeah, some work will need to be done to allow that.. i've been thinking of how to implement this for a few years.. 20:51 <@emostar> but it was nearly impossible with the old api 20:51 <@emostar> so i didnt do a rehaul at that time.. 20:52 -!- rulfo [EMAIL PROTECTED] has joined #Licq 20:52 < erijo> an plans on support for "merging" contacts on diffrent networks (person A is on both icq and msn, but should only show as one user) 20:53 <@emostar> ive had some thoughts of that.. i think its a good idea 20:53 <@emostar> but introduces many complexities 20:53 < erijo> yes 20:53 <@emostar> like when you look at the user's info.. what od you see? 20:54 <@emostar> and if you read their away message.. which do you see? 20:54 <@emostar> they can be done with a menu for each link... 20:54 <@emostar> but that obviously needs to be planned out 20:54 < erijo> the user should select an order: first icq, then msn, etc. Then you just take the info from the first network that the user is on 20:54 <@emostar> priorities 20:55 < erijo> yeah 20:56 <@emostar> the main thing i want to do is make sure that most of the features we want get into the api design, so we can plan it from the start to be complete 20:57 < erijo> if this is done in the daemon, it would be somewhat transparent for guis 20:57 <@emostar> and not have to hack away everytime we want to add somethign that got left out 20:57 < rulfo> this new web interface feature in licq, how can I activate / start it? Do I need a plugin for that? ... I'm interesetd in this one... the screenshots looked promising. 20:57 <@emostar> yeah, the daemon's job is to do the grunt work to make plugins easier 20:58 <@emostar> rulfo: you need the rms plugin to be working properly 20:59 < erijo> but the best way to get a good api design is proably to making something that uses it and then iterate when something is missing. This way you don't spend time designing something that's never used. 21:00 < rulfo> ok... is there any information about this one on licq.org... found nothing there... 21:00 <@emostar> rulfo: there is some documentation in the tarball 21:01 < rulfo> ok.. I'll have a look at it. 21:01 <@emostar> yeah, i think getting the current plugins to work with the new api is a good first step 21:05 < erijo> about the newapi. I have almosted finished CBuffer. It works like this: 21:06 < erijo> CBuffer myBuffer; myBuffer << littleEndian << uint8_t(1) << uint8_t(2) << bigEndian << uint16_t(3) << uint32_t(4); 21:06 <@emostar> looks good. how about the access for Encrypt_Client? 21:06 < erijo> to read: uint32_t data; myBuffer >> bigEndian >> data; or myBuffer >> littleEndian >> data; 21:07 < erijo> you can use myBuffer[] as well 21:08 < erijo> so it should work for Encrypt_Client as well 21:08 <@emostar> ahh 21:08 <@emostar> yes, that is good 21:09 < erijo> i'll finish it up tonight and post it to the list 21:09 <@emostar> alright.. i will probably be asleep by then if it is "tonight" for you 21:11 < erijo> if you update www.se.licq.org to point to 85.8.4.85 it should display a test page now 21:12 < erijo> or even better, make it a CNAME to eddie.ejohansson.se 21:15 <@emostar> ok, will add a cname soon 21:17 <@emostar> ok, got it up 21:18 <@emostar> se.licq.org and www.se.licq.org both work.. but www.se will be official 21:18 < erijo> ok, I'll add an alias for the non-www 21:18 <@emostar> i think we can finish now... right? 21:20 < erijo> first, what's next on the todo list? 21:20 <@emostar> getting rms converted to the new callback style.. but ihave to commit some changes first 21:21 < erijo> k. I'll wait for that then 21:22 <@emostar> i hope to get it in by tonight :) 21:22 < erijo> :) 21:22 <@emostar> but first i have to get dinner.. it's already 21:20 21:23 < erijo> living in the future, must feel good :) 21:24 <@emostar> not very different i think ;) --- Log closed Tue May 16 21:24:18 2006
pgpaETQIWQh2b.pgp
Description: PGP signature
