Sorry for the delay with the meeting notes and log. The meeting started and ended a bit earlier than usual. My apologies to anyone that missed out on the beginning part. Here is a summary of what was discussed:
* The GeneralPlugin class was discussed a bit and some modifications
are planned.
* Some ideas about how user information is stored and shown in the
GUI of all the plugins were discussed. This isn't done and still
needs some more work. I will do some research to see how much of a
performance hit we will take if use a structure like CEventData for
the user information as well.
* Some explanations about the current classes in the Licq Wiki were
explained a bit.
I would also like to say that the new development branch should try to
make as best use of the STL as possible. The current release of Licq
uses the STL a little bit, mainly because at the time it was written
(1999) the STL was not completely supported on the compilers. But now
all modern compilers support it. I'd also like to see the Boost
(www.boost.org) libraries used were applicable.
The goal is to make it as generic and extend-able as possible to support
many plugins including a sort of plugins of plugins (for example.. to
support video chat). It should be able to be done with C++ using the
modern tools available now. I have a few new books to read that should
also help me out to make better design decisions.
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 26 19:45:42 2006
19:45 <@emostar> Ok, lets start the meeting
19:46 <@emostar> It's a little early, so people will join us as we progress
19:46 <@emostar> So, yesterday I started a new branch in SVN and started
working on the new source files
19:47 < QnD> yes, okay ... enough time ti ask questions about the
LicqCallback-thing you wrote. I must confess that my C++-knowledge doesn't go
that far, so I don't understand anything ...
19:47 <@emostar> There are many things to change, so it will take some time
before we get a working version completed
19:47 < QnD> ti = time
19:47 <@emostar> ok.. are you looking at the wiki now?
19:47 < QnD> yes
19:48 <@emostar> the LicqCallback definition?
19:48 < QnD> yes ...
19:49 <@emostar> so the class for callbacks that will be used is the
LicqCallback class. its a templated class so it will support any object and any
function
19:50 <@emostar> that way the plugins can specify their object and the member
function in that class
19:50 <@emostar> and the daemon doesn't have to know anything about the object
19:50 < QnD> hm ... can you give an example?
19:50 <@emostar> theres one on the wiki :)
19:51 < QnD> really :)? one moment ...
19:51 <@emostar> LicqCallback *pObject = new
LicqCallback<CClass>("user-status-change", this, CClass::handleStatusChange);
19:51 <@emostar> pDaemon->registerCallback(pObject);
19:51 < QnD> oh, yes, there ...
19:52 < QnD> and what does "operator" mean?
19:52 <@emostar> do you understand the example?
19:53 <@emostar> void operator()(void *) is the () operator
19:53 <@emostar> we overload it
19:53 < QnD> yes, I do ... although I always thought that only static member
functions of a class can be set as a parameter
19:53 < QnD> why do you overload it?
19:54 <@emostar> to make calling the object easier.. there has to be a way to
execute the callback
19:54 <@emostar> so it can be done like object(param);
19:55 <@emostar> otherwise we have to add a member function to execute it..
liek "run"
19:55 <@emostar> so then it would be object.run(param);
19:55 <@emostar> but the () operator is meant to run a function.. so its best
to use it
19:56 < QnD> aah! I remember ... have read the "operator" line the wrong way
(and asked myself "why does he define an "operator"-function), all clear now
19:56 <@emostar> it kinda makes the object be a function object..
19:57 <@emostar> and the LicqCallbackBase is used to put the callback objects
in an STL container
19:57 <@emostar> std::list<LicqCallback> doesnt work because its a template
19:58 < QnD> yeah!
19:58 <@emostar> so if you make all of them have a common base, you can put the
pointer tothe LicqCallbackBase in a STL container
19:59 < QnD> yes, sure ...
19:59 <@emostar> that or a boost::shared_ptr would do the trick
20:00 <@emostar> and like we talked about last week.. i made a class
(CEventData) that will allow the params to be taken out by a string name.. and
support any object (nearly)
20:00 <@emostar> http://wiki.licq.org/ProtocolEvent has the details
20:01 < QnD> okay ... looks good. another question: how do you give the
constructor of LicqCallback the callback function?
20:01 < QnD> yes, already saw that - exactly what I meant
20:02 <@emostar> like the example...
20:02 <@emostar> LicqCallback *pObject = new
LicqCallback<CClass>("user-status-change", this, CClass::handleStatusChange);
20:02 <@emostar> the function we are giving is CClass::handleStatusChange()
20:02 <@emostar> technically CClass::handleStatusChange(void *)
20:02 < QnD> yes, but as I wrote above I thought that only static member
functions can be used as a pointer ...
20:03 <@emostar> nope, any function can be used as a pointer
20:03 <@emostar> because it isnt static, we pass the class pointer to the
constructor as well
20:04 <@emostar> in the operator() part it does object->*function()
20:04 <@emostar> we pass both object and function in the constructor
20:05 < QnD> alright ... (you see: neber hat the time to learn much about C++).
ah, I see now
20:06 <@emostar> hmm might be good to pick up a book ;) i'd like to see most of
the work done using STL.. since that makes things so much easier and will save
us time
20:06 <@emostar> and not to mention that it makes more efficient code
20:06 < QnD> yes, bought a book about C++ ;)
20:07 <@emostar> whos the author?
20:07 < QnD> Stroustrup
20:07 <@emostar> The C++ Programming Language?
20:07 < QnD> hmyes
20:08 <@emostar> ahh, i have that one too.. its very good for STL
20:08 <@emostar> rather dry.. but its the best book out there i believe
20:08 < QnD> yes, and expensive :)
20:08 <@emostar> the only thign i regret is i left that book in america... will
bring it back the next time i go home
20:08 <@emostar> i have my assembly book with me though :\
20:09 < QnD> yes, seems to be a good reference book.
20:10 <@emostar>
http://books.google.com/books?id=n9VEG2Gp5pkC&pg=PA2&lpg=PA2&printsec=8&ots=Rci8jmccXR&dq=The+C%2B%2B+Standard+Library&sig=vYOyCr1Gzn2uhkn3pNOBf0lEfTk
20:10 <@emostar> thats the stl "bible"
20:10 <@emostar> anyways..
20:11 <@emostar> i'd like to think we have some solid structures that are quite
flexible.. but only time will tell when we write code with them :)
20:11 <@emostar> if you saw my latest commit in the newapi branch.. all plugins
(not protocol though) will derive from this class
20:12 < QnD> $64.99 for this book - what a world ....
20:12 < QnD> havn't had time to have a look into the new branch yet
20:13 <@emostar> only one new file.. include/licq_generalplugin.h
20:13 <@emostar> and yes.. these books are expensive..
20:13 <@emostar> even more so if you dont live in america
20:15 -!- Rapp [EMAIL PROTECTED] has joined #licq
20:15 <@emostar> you are on the licq-cvs mailling list, right?
20:16 < Rapp> hi
20:16 <@emostar> hello
20:16 <@emostar> Rapp: i got your ssh key.. but i forgot, i will also need your
sf.net user name
20:16 < QnD> no, just on licq-devel
20:16 < Rapp> oh, i have to look that one up...
20:17 <@emostar> QnD: well, if you are going to participate on the latest
development.. the licq-cvs mailing list is critical..
20:19 < QnD> hm, always thought licq-DEVEL is for development :)
20:20 < QnD> however, will join it now
20:20 <@emostar> well it is for development, but licq-cvs has the latest code
changes.. which don't necessarily get discussed on licq-devel
20:21 < QnD> good argument
20:21 <@emostar> i use an svn mailing list at work.. even though the other
people on the list are within talking range.. just makes it easier for everyone
to see a diff and review that or peruse it
20:23 < QnD> yes ...
20:24 < QnD> just took a look at generalplugin.h - this should really be
everything that's needed ...
20:24 <@emostar> yeah, i was hoping so.. not that much different from the
current method.. just making it C++
20:24 < QnD> (except a thing like a plugin description)
20:25 <@emostar> yeah... not sure if we really need that or what
20:26 <@emostar> but i have no issue with adding it if there is a good reason..
20:26 <@emostar> perhaps its better to have it.. so a descriptoin can be shown
before the user loads it or something
20:27 < QnD> yes ... although this requires loading (not running) of all plugins
20:28 < QnD> (a description is quite important, because plugins can now be much
more specific)
20:28 <@emostar> yeah.. but if the user has the plugin "installed" then it may
not be unreasonable to load it for some information
20:28 < QnD> right
20:28 <@emostar> so i will add that
20:30 < QnD> another thing: I thought about plugin dependencies (here we go
shake-window-plugin): a shake-window plugin cannot be loaded without the msn
plugin being installed ...
20:30 <@emostar> hmm yes.. that should be done at the beginning of plugin
initialization
20:30 <@emostar> that way it can quickly escape if it is not present
20:31 < QnD> and should also be another peace of information the plugin gives
to the daemon
20:31 < QnD> (before loading)
20:31 <@emostar> hmmm.. it can be done without the daemon handling it i believe
20:32 <@emostar> what i think is best...
20:32 <@emostar> the daemon allows the plugin to see what plugins are loaded..
so when it is initialized it can check for that plugin's presence
20:32 <@emostar> if it is not there, throw an exception so the daemon knows it
is missing a required plugin and can provide the feedback to the user
20:32 < QnD> hm, but this will require things like checking, giving an error
message ... which must be done by every plugin by itself
20:33 < QnD> ah
20:34 <@emostar> if (!pDaemon->isLoaded("msn")) throw MissingPlugin("msn");
20:34 <@emostar> actually it can past a list to the daemono for it to check..
20:34 <@emostar> i just dont think that it will be used so much
20:35 < QnD> hm, my idea was just to provide a kind of string array to the
daemon that lists the required plugins. if the required plugins are not there
they could either be loaded or an error message could be thrown
20:35 <@emostar> hmm with the plugins of plugins idea.. it may be used a lot
20:35 < QnD> yes
20:36 <@emostar> so yeah.. putting that in the daemon would be nice.. and it
can also be displayed in the plugin info before it is loaded.. so the user
knows what the requirements are
20:36 < QnD> yes
20:36 <@emostar> i will add that as well
20:37 < QnD> another thing: do you already have plans how the info-struct of a
user should look like?
20:38 <@emostar> havent gotten to that point yet
20:38 < QnD> ah, okay ...
20:39 <@emostar> have you given it any thought?
20:40 < QnD> hm, that's everything I wanted to talk about for today :)
20:40 <@emostar> hmm works out well so that i can take the train i wanted to
then ;)
20:40 <@emostar> just one more thing
20:41 <@emostar> if you are gonna have svn access, i need a public ssh key and
your SF.net username
20:41 < QnD> no, not really - thought about string accessors again, but this
might not be a good idea concerning performance
20:41 < QnD> ah, yes ... wait
20:41 <@emostar> yeah, i was thinking the same thing...
20:42 <@emostar> we can have a ton of functions like now (and a huge vtable)
20:42 <@emostar> or somethign like CEventData
20:43 <@emostar> perhaps CEventData isn't that big of a performance hit.. i
will do some work later to check into this
20:44 < QnD> the most important thing is how to group the information later. it
would be great to have some kind of info window that can cope with every
information a proto plugin could provide ...
20:45 <@emostar> yes that would be nice
20:45 <@emostar> especially since ICQ has the largest info window of any
protocol
20:45 < Rapp> maybe some sort of tree structure would make sense?
20:46 < Rapp> for grouping the information?
20:46 <@emostar> hmm.. i will have to give it some consideration
20:46 < QnD> also thought about that - but maybe this was not the best idea
because information may be grouped in a different way to provide a good look
and "lucidity"
20:47 < Rapp> yeah...
20:47 < Rapp> depends on how "general" we want to be
20:47 < Rapp> a 1:1 mapping for every possible protocol would be quite hard, if
you had a fixed layout like now
20:48 < QnD> yes ... but these questions will probably be answered as soon as
there's a concrete way of how to do the GZUI things
20:48 <@emostar> maybe some kind of heirarchy would be best.. to help display it
20:48 < QnD> GZUI = GUI
20:48 < QnD> what do you mean?
20:48 <@emostar> like a General -> Name
20:49 <@emostar> Work -> Company Name
20:49 <@emostar> then the gui knows to show all the General items together
20:49 <@emostar> and the Work is a different grouping
20:49 < QnD> hm... yes
20:50 <@emostar> im sorry, but i have to get going
20:50 < QnD> but still this information cannot be just shown one after the other
20:50 < Rapp> yes, that is actually a tree :) you could do it as tabs or as a
tree view
20:50 < Rapp> ok, cu
20:50 < QnD> yes, no problem - see you later
20:50 < Rapp> gotta get back to work, too :)
20:50 <@emostar> alright, i will leave the log running if anyone else joins in
;)
20:50 <@emostar> and will post it after i have dinner with my gf
20:51 < QnD> okay, Bon appétit!
20:51 <@emostar> thanks :) talk with you later.. email me your ssh key and
sf.net info!
20:51 < QnD> okay :)
20:52 <@emostar> ok.. see ya
20:52 < QnD> yep
20:53 -!- BDick [EMAIL PROTECTED] has joined #licq
20:58 <@Agrajag-> ahh crap
20:58 <@Agrajag-> i got the time wrong
20:58 <@Agrajag-> bugger it
21:05 < Rapp> lol
21:06 <@Agrajag-> heh
21:06 <@Agrajag-> well i read up and i checked out the wiki stuff this morning,
it's all looking good
21:12 <@Agrajag-> well i got my brother who uses gaim to check out how it does
user info GUI stuff. it just gets the protocol plugin to give back an html
string which it displays in one big area. it's simple i guess, but less than
ideal for displaying the information nicely (and the plugins have to do more
work)
21:15 < Rapp> yup, that's why i think some form of tree would be great. like
some simple pointered struct or an XML string. that can be displayed as tabs or
also as a tree widget or something else.
21:16 <@Agrajag-> yeah, that sounds good. an xml string describing (i guess
similar to gtk's glade) the tabs/info would be cool
21:17 <@Agrajag-> and it wouldn't have to be too complicated because i don't
imagine there would be the need for many different types of widgets
21:17 < Rapp> no, it could be simple
21:18 < Rapp> only types needed are string and maybe picture
21:18 < Rapp> the nested XML tags would give the natural hierarchy.
21:19 <@Agrajag-> yeah.. looking the icq info now there's also a tree thing in
More II
21:19 < Rapp> if one thinks that XML is too bloated, of course everything could
be mapped to some struct with pointers
21:19 < Rapp> right
21:21 <@Agrajag-> it would also need to be generic enough that it can be
displayed with any gui, be it qt/gtk/ncurses
21:21 < Rapp> that is not a problem i think
21:21 < Rapp> i can write you a small XML treeview thingy :)
21:21 < Rapp> for console
21:22 < Rapp> we even do not need a full blown XML parser
21:22 < Rapp> we really only need very simple and specialized tags
21:23 <@Agrajag-> yeah.. but i think we'd want it to be extendible to an
extent, so that if one day some other plugin comes along that wants to display
something else, it would be simple enough to add
21:23 < Rapp> yes of course
21:23 < Rapp> but i think an XML example for our case would look like:
21:24 < Rapp> <Userinfo><category name=?General?><text label=?Alias?
value=?John Doe? />...</category>....</Userinfo>
21:24 < Rapp> you will not need much more
21:25 < Rapp> instead of <text> you could also use a <picture> tag
21:25 <@Agrajag-> yep
21:25 < Rapp> i cannot think of much more that one could need
21:59 -!- QnD [EMAIL PROTECTED] has quit [Remote closed the connection]
--- Log closed Thu Apr 26 22:00:39 2006
pgpARjDn36vT9.pgp
Description: PGP signature
