A week late but, better late than never. Last weeks meeting log attached. // Erik
-- Fatal error! Hit any user to continue... Erik Johansson http://ejohansson.se
13:55 <@erijo> hello
13:55 < flynd> hello, do we have a meeting this week?
13:55 <@erijo> hope so
13:57 <@erijo> let's see how many turn up
14:04 <@erijo> how's it going with the qt4 port?
14:05 < flynd> slow, haven't happened much the last week. I've started to
convert the contact list but there are still some things I need to fix before I
can commit anything
14:07 <@erijo> besides the contact list, how much qt3support stuff is left?
14:07 < flynd> I found that I could put any widget in the cell of a QTreeWidget
but I think the QLabels (that's what I'm using to draw the icons on) is
stealing the events from the list
14:08 < flynd> Don't know. A lot I think, but most of it is working so once the
contact list is fixed there shouldn't be much more to de bofore the qt4-gui is
fully functional
14:10 < flynd> grep fro "Q3" in src returned 1736 lines
14:13 <@erijo> but you are working on the contact list now?
14:13 < flynd> yes
14:14 <@erijo> great
14:14 < flynd> if by working you mean mostly adding debug printouts, reading
qt4-documentation and trying to guess why things doesn't work like I want them
to =)
14:16 <@erijo> do you have any additional comments on "the life of a plugin"?
14:18 < flynd> I think the mails contain all the comments I have
14:20 < flynd> but I have wondered at bit how to make the gui with this. For
each plugin loaded there will be more configuration options which should be
added to the gui options dialog so either the gui most have extra code for
every plugn that is supported or the gui itself must also be able to have
plugins
14:20 <@erijo> ok
14:21 <@erijo> yes, options are one of the problems that has to be resolved
14:22 <@erijo> there has been some discussion about this earlier, but without
reaching a solution
14:22 < flynd> this means that either the gui must be updated for each plugin
that is created, and any other gui created (gtk, web, text, etc) also needs to
be updated in the same way
14:23 <@erijo> yes
14:23 < flynd> or the plugins need to have a gui-module as well for each
existing gui
14:23 < flynd> neither is any good
14:24 <@erijo> i'm thinking about having a central database in the daemon where
all plugins store their settings
14:24 <@erijo> then, the gui could list some of the options in the normal
options dialog
14:25 <@erijo> and have a "about:config" as firefox where all options are listed
14:25 < flynd> or the plugins could have some metadata that describes the
configuration parameters (datatypes, ranges etc)... this would make the options
dialog look something like the firefox about:config page which is not very user
friendly
14:25 < flynd> =)
14:27 <@erijo> the only way to have the gui not know about a plugin's options
is if plugins ship with some kind of description of how the options dialog
should look for them
14:27 < flynd> this is probably how it must be done to be plugin-friendly then
the config-description can be extended to contain grouping of the options so a
gui can divid the options in pages or groups for better usability
14:28 <@erijo> yes
14:30 < flynd> the problem is to make the config-description in a way that
allows the gui to look like the plugin was native to the gui
14:31 <@erijo> that would probably require some kind of "xml-gui"
14:31 <@erijo> and i'm not sure we want to do that
14:32 < flynd> yes, at least some way to just throw in all the options and then
let some automatic layout handler draw the dialog
14:33 < flynd> I think just having the about:config will be enough to start
with so we can get licq2 running, we can improve it later
14:35 <@erijo> true. We shouldn't over-engineer stuff until it's called for :)
14:35 <@erijo> so, any ideas on the about:config thingy?
14:35 <@erijo> an option needs a name, datatype, optional range, description
14:36 <@erijo> and it needs to be localized
14:37 < flynd> it can also be an array or struct (like the columns
configuration for the gui)
14:38 < flynd> range may not always be enough, some options are enums (usually
displayed as radiobuttons or comboboxes)
14:40 < flynd> maybe it should use QSettings, I haven't read much about it but
it looks like it could be useful
14:40 <@erijo> we can't use qt since it should work for all plugins
14:42 < flynd> not even QtCore?
14:42 <@erijo> no
14:43 < flynd> ok, then we have to implement something ourselfs, but a simple
list of options will probably not be flexible enough. I think it has to be a
flexible tree structure like the windows registry
14:45 <@erijo> do we really need that kind of flexibility?
14:47 < flynd> I'm not sure, but I like flexibility =)
14:47 <@erijo> it's nice, but it takes time
14:47 < flynd> If the structure of the config tree can be mapped directly to
the tree-navigation in the config dialog it would be great =)
14:50 < flynd> At least to start with I don't think it has to even be handled
as a tree internaly, just use the path and option name as a index and it will
just be a list to handle, but can be displayed as a tree to the user instead of
a flat about:config list
14:53 <@erijo> qtplugin->getOption("general;main window;start hidden", &myBool);
14:54 < flynd> something like that yes
14:55 < flynd> but I'm thinking it like LicqConfig->getOption("QtGui;Main
Window;Start Hidden", &myBool);
14:57 < flynd> plugins will have to register their options (with datatypes and
default values) when they are loaded and then getOption() and setOption()
should be enough
14:57 <@erijo> i was thinking about having a method void*
IDaemon::getInterface(TPluginId id, const char* interfaceName);
14:58 <@erijo> when a plugin wish to get e.g. the settings for an icq plugin it
would call daemon->getInterface(icqId, "IOptions");
14:59 <@erijo> if the icq plugin has options, it would return an instance of
IOptions
14:59 <@erijo> otherwise, it would return NULL
14:59 < flynd> you mean each plugn should handle config for it self? wouldn't
it be better to keep a central config handler in the daemon to reduce the need
for each plugin to have copies of the same config handling code?
15:03 < flynd> the config handler of the daemon would of course have to be very
flexible for it to be useful for all plugins but I don't think it is impossible
15:03 <@erijo> that was my initial thought, but now i'm leaning more towards
having more logic in the plugins
15:04 < flynd> version switch of a plugin will be easier if the plugidn handles
configuration by itself
15:04 <@erijo> this interface could e.g. have an method validateOption(name,
value);
15:06 < flynd> using a central config can also have a validateOption, if might
even forward the call to the plugin for the actual validation in non-trivial
cases but it could still be a single point for managing the config repository
15:10 <@erijo> would you mind writing a document describing the interface for
this central repo, how it would work and how plugins would use it?
15:11 < flynd> a way forward could be to leave the configuration in the plugnis
for now to have fewer requirements on the daemon at this point and then we can
see if maybe it should be moved in future versions
15:14 < flynd> ok, I can take some time to think about it and see if I can
write something implementable
15:16 <@erijo> it doesn't need to be long, just something that can be posted to
and discussed on licq-dev
15:20 < flynd> ok, I'll see what I can do and try not to make it too complicated
15:20 <@erijo> great
15:23 <@erijo> anything else we should discuss?
15:24 < flynd> is anything else happening right now that you or me is involved
in?
15:25 <@erijo> i'll write together a little something on how events are passed
around in licq2
15:26 <@erijo> and this idea i have about getInterface, be it from a plugin or
the daemon
15:27 <@erijo> other than that, not much
15:28 < flynd> ok, I don't have anything else I'm doing. But I'm thinking on
having a look at the msn plugin, there are too many critical messages about
failed pictures
15:30 <@erijo> ok
15:30 < flynd> I don't really care that licq fails several times a day to
download pictures for my contacts and I don't think the error should be
classified as critical and popup
15:30 < flynd> but as I haven't looked in the msn code at all yet I was hoping
someone else would fix it =)
15:33 <@erijo> i'm not using msn that much, so i have never got those message
15:33 <@erijo> so don't count on me ;)
15:33 < flynd> damn =)
15:35 <@emostar> just got here...
15:36 <@emostar> flynd: about the msn issue, I'll send you a patch to add some
debugging output that could help
15:36 < flynd> I guess that means I'll be the one fixing it then =)
15:36 <@emostar> i haven't been using msn a lot recently.. my mom messages me
too much :P
15:36 <@emostar> depends on the time it takes...
15:37 <@emostar> shouldn't be that much of an issue.. just writing the a
15:37 <@emostar> packets to a file.. much like a standard file transfer
15:39 <@emostar> and an easy way to force it to be re-downloaded is to close
licq, edit ~/.licq/users/<email>.MSN_ and delete the PPField stuff
15:40 < flynd> ok, send the patch and I'll see if I can fix it
15:40 <@emostar> gotta make it first..
15:42 <@emostar> erijo: i have the Owner document nearly done
15:43 <@emostar> will upload it to wiki and send an e-mail tomorrow
15:43 <@erijo> great
15:44 <@erijo> i haven't started on the events document yet
15:45 <@emostar> there is some stuff on the wiki about events..
15:45 <@emostar> just a start thought
15:45 <@emostar> though
15:46 <@erijo> yes, i used that as a base when creating this:
http://trac.licq.org/browser/branches/erijo-dev/licq/licq/interface/event.h
15:48 < flynd> erijo: I didn't have to write many lines on the config handler
to realize that I will complicate it too much =) Maybe you should keep it in
the plugins like you soid to keep it simple =)
15:51 <@erijo> ok :)
15:51 <@erijo> should it be possible to have more than one instance of a
non-protocol plugin?
15:52 < flynd> why not?
15:52 <@erijo> is there any use-case for it?
15:54 < flynd> maybe you could start an extra instance of a UI plugin, like if
you remote connect to your computer and want to have a gui via X-forward
without restarting licq
15:55 <@erijo> but how would that work?
15:55 < flynd> or if you have a small but general notification plugin that can
send events to other programs/files/displays/systems/etc and it can only handle
one destination but you want multiple, then you load the plugin once for each
destination
15:56 < flynd> I'm not sure, you would have to provide a DISPLAY when loading
the plugin in some way =)
15:56 <@erijo> the problem is, how can we load a plugin and say that this is
instance X?
15:57 <@erijo> with protocol plugins it easy, but for general plugins
15:57 < flynd> why is it different?
15:57 <@erijo> every protocol have an owner associated
15:58 <@erijo> but when we load that notification plugin, how can we say that
this instance should send events to this file and that this other instance
should send it to that file?
15:58 < flynd> will you actually be loading the protocol plugin twice or will
you just allow them to handle multiple users?
15:59 < flynd> s/users/accounts/
15:59 <@erijo> load it twice (or at least create two separate instances)
16:00 <@erijo> something like: loadProtocol(uin) and loadProtocolNewUser();
16:01 < flynd> I think you can limit the general plugins to just one instance.
At least for now
16:02 <@emostar> flynd: are you getting Too Much Data errors?
16:03 < flynd> Will the protocol plugins be different from other plugins or
will all plugins have the same interface and protocols just do a
registerProtocolHandler() on allowing one plugin to handle multiple protocols?
16:03 <@emostar> sorry, gettin gtoo tired to think, gonna crash
16:04 < flynd> emostar: [ERR] Display Picture: Encountered an error before the
session id was received: MSNSLP/1.0 500 Internal Error
16:04 <@erijo> emostar: good night
16:04 < flynd> the error at the end varies though
16:05 < flynd> I get too much data received as well sometimes
16:08 < flynd> erijo: Will the protocol plugins be different from other plugins
or will all plugins have the same interface and protocols just do a
registerProtocolHandler() on load allowing one plugin to handle multiple
protocols?
16:10 <@erijo> that's an idea
16:11 < flynd> then all plugins could be handled the same way, no special
treatment for the protocol plugins
16:13 < flynd> registerProtocolHandler() would provide a factory for the
protocol which can be called multiple times to get an instance for each owner
16:15 <@erijo> yes
16:16 < flynd> and protocol handling would separated from the plugin handling
16:17 <@erijo> and as far as the plugin loader is concerned, there is only one
instance of each plugin
16:17 < flynd> yes
16:18 <@erijo> that does indeed simplify things
16:25 <@erijo> we'll see what jon has to say about LicqOwner and how it would
fit in
16:28 * Crazy_Hopper is back (gone 13:13:34)
16:29 < Crazy_Hopper> whew... better late than never... :-/
16:29 < Crazy_Hopper> hi everyone
16:29 < flynd> wb
16:30 < Crazy_Hopper> erijo: did you have a moment to play with the current qt4
gui?
16:31 <@erijo> no. did i say i would have one?
16:32 < Crazy_Hopper> nope, at least I don't remember one.. :-) I was just
curious about the glitch i have here...
16:32 <@erijo> i haven't used qt4 for a while now. flynd is the expert
16:33 < flynd> but I don't want to touch my keyboard settings in X now that
they finally work =)
16:34 < Crazy_Hopper> i know. have tried to squeeze him about it yesterday...
and you see why I wasn't succesful.. ;-))
16:40 <@erijo> you can always hope that the problem is magically solved somehow
:)
16:41 <@erijo> time for me to go
16:41 <@erijo> see you all later
pgpoRuIH8qUqF.pgp
Description: PGP signature
