Please find attached the log of today's meeting. Topics: Mainly GUI and plugin clarifications.
Arne -- Dipl.-Inform. Arne Schmitz Phone +49 (0)241 80-21817 Computer Graphics Group Fax +49 (0)241 80-22899 RWTH Aachen University http://www.rwth-graphics.de Ahornstrasse 55, 52074 Aachen, Germany
* Du sprichst jetzt in #licq * Das Thema für #licq ist: Meeting Today | http://www.frappr.com/licq | Licq 1.3.2 | http://www.licq.org | If you can't get your answer here, use the mailing list: licq-main@lists.sourceforge.net | licq.org's new SSH fingerprint: 1e:3f:35:a6:f3:01:8b:23:68:dd:da:12:3d:b3:28:62 * Das Thema für #licq wurde gesetzt durch emostar um Tue Jun 6 06:02:26 2006 * CTCP VERSION von freenode-connect empfangen * tirramissu hat die Verbindung getrennt (Remote closed the connection) * tirramissu ([EMAIL PROTECTED]) hat #licq betreten * Camael ([EMAIL PROTECTED]) hat #licq betreten Camael alright, think I'm too late for the meeting ... erijo Camael: no, it hasn't started yet... Camael normally I'm at university at that time - when does it actually start? erijo today i think it will start when emostar returns Camael alright :) erijo to quote: 11:36 <@emostar> instead of 20:00 perhaps 21:00, i'm going out for a lil bit after work erijo and i think he's gmt+9 Camael hm ... "if you cannot say a good thing about it better say nothing" (or however this saying is in english) ... Agrajag- that would make it now wouldn't it? it's 21:25 gmt+9 now isn't it? erijo it is Camael didn't have the time to follow the development of Licq. how far is the new version now? erijo i'd say not that far Camael the problem is that it's quite hard to get an impression of the progress because jon copied the whole old source into the new branch (which is not the best idea in my eyes)... erijo As a programmer it is tempting to start from scratch, but i think jon did the right call when deciding to base the new api on the old codebase. It's easier to work with something that compiles and runs. You don't have to rewrite everything at once, instead you can do it piece by piece. Camael yes, but it was jon who said the the source is (a) full of obsolete code and (b) not that lucid anymore... this will create nothing but long search times for a certain part in the source, even longer trash killing and a much longer debugging... if the new and the old engine would base on the same idea this wasn't a problem but I think the paradigm is somehow new Rapp i agree wit erijo Rapp with Agrajag- i think once the new api stuff is figured out, the "trash killing" and debugging shouldn't be too hard. i imagine once the icq protocol is taken out of the daemon there wont be so much obsolete code Camael hm ... hopefully. another problem is that it's quite hard to get into the structure of the code for programmers (except jon)... however Rapp yup, the rest is pretty straight forward i guess Rapp well, any foreign code is difficult to manage at first. but i found it relatively easy after a short time to figure out some stuff in the innards of licq. although i haven't come around to fix the two or three things, i always wanted to fix... Agrajag- i think the new protocol api will make it a lot easier to understand anyway erijo i belive that it's psychological good to always have a fully working licq (even if it isn't actually working and you're just fooling yourself) Rapp i think the old licq "only" has some high level design problems, not so much code readability erijo Rapp: there are places... :) Rapp ah, well... Rapp :) Camael erijo: maybe ... although experience showed me the opposite :) Rapp anyway -- one should also not fall for the over-engineering trap. good SW-engineering is important, but sometimes you just have to start with something that plainly works and is maintainable. Rapp the rest is then a process of re-engineering Rapp and that's what we do with licq Rapp and i think it is a good way to do it. Camael hm, yes ... it might depent on the success that one had with this technique Camael :) erijo i agree. a "good" api in a year is better than "the perfect" in three ;) Camael yes, but the "perfect" api might have a lifetime of 10 years while the "good" lives 5 :) Rapp Camael, yes, of course. if you become leader of a project like ¨relational database written in gw-basic" you better start from scratch. it depends on the setting which tool you should choose. i for one think that licq is not such a case where we need a restart. Rapp just rip the stupid icq protocol out of the daemon and everything will look better :) Camael hehe, too easy to be the wrong way :) erijo a "good" api can always evolve into "the perfect" one... Agrajag- ok i can't stay up any later, gotta go to bed, gotta get to work early tomorrow. cya guys Camael apropos easyness: think one should start thinking about the design of the new frontend. because the backend and the frontend are more or less independant from the users way maybe some people should make first drafts about it so everything is in a good state of development when the backend is ready Rapp Agrajag-, cu Camael see you erijo Agrajag-: cu erijo Camael: you mean qt-gui-ng? Camael yup Camael it's kinda antiquated regarding the look and the usability erijo agree erijo but first someone has to come up with a good idea for how plugins can alter the gui Camael hm ... I don't really think that this depends on creating first stuff about the new gui.... Camael but of course it's important ... has someone had a godd idea already? Camael godd -> good erijo not that i know erijo there was some talk about xml, but that might be a bit too complex Camael hm ... someone in the mailing list wrote that a kind of XML meta GUI API would be a bad idea which is propably true. jon once suggested to let the plugins only modify specific places (users menu, toolbar ...). this would be the easiest and most efficient thing but would make plugins not THAT cool anymore :) (I'm thinking about "contactlist nicer" or a better history window or stuff like this). Rapp what exactly are the requirements? what needs to be altered in the gui? erijo Rapp: that is the central question Camael ... this question is still a task in the mailing list I think erijo yup, i tried starting a thread, but... Camael the problem is that basically everything could be altered. eg someone doesn't like the standard chat window -> install a plugin which delivers a new chat window in IRC style or so ... Camael so what can be done answering this question is "what MINIMALLY should a plugin be able to alter" Rapp hm Camael but the question is whether this will help, because if you now say "let's give it the possibility to add entries to the main menu" what shall happen then? a window must pop up Rapp i think things like that should be provided only later Rapp i think the most important things are: Rapp 1. giving an option tab in the configuration dialog for each plugin Rapp (or something similar) Rapp 2. allowing plugins to install hooks, e.g. in the context menu or the message window of a contact Rapp 3. allowing plugins to maybe represent a button or something in the message window (similar to above, e.g. for encryption plugins) Camael sorry, have to go now. see you later Rapp cu erijo cu * Camael has to go buying things Rapp is there anything else to talk about? and where is emostar today? :) erijo should we create an abstract LicqGui class with all required operations, and require qt-gui, gkt-gui, html-gui etc. to implement concrete classes? Rapp hm Rapp would be a solution, maybe Rapp how is this handled at the moment? Rapp actually i think it would be quite a good idea, maybe Rapp what kind of operations would we need? erijo we could create a minimalistic gui package Rapp do the current GUIs communicate via the pipe? Rapp or is there some more sophisticated communication ATM? erijo in trunk there is a pipe erijo in newapi no erijo all communication is done by sending events erijo i.e. calling functions Rapp yes, i see Rapp should be faster :) if that is a problem... Rapp i think the following: Rapp 1. a gui plugin needs to support some basic authentication and message receive/sending stuff Rapp that could be done of course in form of some aptly named functions that are called by the daemon / plugin router, Rapp 2. the question is, where do for example the histories go? is there a history plugin? is it part of the user objects? Rapp (i would guess something like that) erijo i would like to see support for "meta users", so this is how i see it: erijo a message is received by the daemon from the a icq protocol plugin instance. The daemon replaces the user object with the meta user object erijo the message is then sent to all plugins that have registered to receive messages, e.g. a history plugin erijo this way you can have a "text file history" and e.g. a "mysql history" Rapp don't forget the decryption plugins.... Rapp we had that last week, too Rapp decryption plugins would have to be synchronous Rapp since decryption may depend on interactive passphrase input Rapp a decrypt plugin would have to be able to store the incoming messages, or otherwise the pipeline might be: icq -> daemon -> history -> decrypt [-> optional decrypted history replacement] -> gui erijo yes, but if the decrypt plugin returns something to stop further processing the daemon wont send it to the history plugin. Then, when the decryption is done, the decrypt plugin would ask the daemon to continue processing erijo i assume that you don't want to store encrypted messages? Rapp no, i think i want them decrypted. that what other users told me, too. in case they loose the key or something Rapp our idea last week was: Rapp store a flag (ENCRYPTED) in the message Rapp and delay all messages after that, until the decryption plugin has decrypted all encrypted messages (deleting the flag) Rapp so the history may store E messages temporarily Rapp but according to jon the flow of messages must be in order of arrival Rapp so we have to process the messages in a deterministic pipeline. Rapp at least for each contact! Rapp multiple contacts could possibly be processed asynchronously erijo something like this: Rapp the history plugin might also store incoming messages, even if the decrypt plugin stalls while waiting for user input erijo the decrypt plugin is the first to receive an incoming message erijo if the message is encrypted it's marked with ENCRYPTED flag erijo the message continues down the pipe Rapp mhm erijo the history plugin stores it erijo the gui skips it, waiting for the decrypted one erijo when the decryption is done, the decrypt plugin sends it down the pipe again erijo since the unique id of the message is the same, all plugins know that this is an updated version Rapp yes, that is a possible solution erijo the history plugin replaces the previous stored one erijo the gui shows this one Rapp exactly. Rapp plus the gui should delay display of messages, until the decrypted one has arrived. although i htink this might lead to problems Rapp but otherwise order of packages might get disturbed. Rapp one *might* display "Message encrypted!" in the gui or something Rapp maybe with a hotspot to force decryption... Rapp i meant: order of messages erijo this is only a problem if a user sends an encrypted message followed by an unencrypted one erijo in that case, do as you said is a good idea erijo *doing Rapp yes, but you never know, it might happen. Rapp plus we definitely have to have an option to skip the decryption if necessary, e.g. if someone forgot the password Rapp with my proposed flow it would be possible to cancel the decryption dialog and still see following unencrypted messages Rapp but anyway, your pipeline flow is i think great. combined with the above described behavior of the gui, i think it should work. erijo am i correct in assuming that you only enter the password for the first message (per session)? Rapp no, not necessarily. e.g. gpg-agent uses the qt-pinentry module to ask for the passphrase every N minutes (i.e. it caches the phrase for N minutes) Rapp some people even prefer to not cache it at all erijo k Rapp also gpg-agent might use an attached smart-card to decrypt. Rapp which the user can plug off any time Rapp (also i guess no licq user uses this :) erijo what if we replace the encryption flag with an encryption-pending and an encryption-failed flag? Rapp well Rapp why that? Rapp oh, i see erijo i would leave it to the gui to do whatever it thinks is best Rapp yes, the user could tell licq to never try to decrypt the message again. Rapp or what would you like to achieve with that? erijo (just a note: i meant decryption-pending etc...) Rapp yes, of course erijo if you just have encrypted, the gui can't tell if it can assume that a decrypted will arrive erijo but maybe this is an implementation detail and not worth discussing now? erijo better to focus on the main flow Rapp yes, it is a detail, but the order of the plugins is still important and more high-level. but i think this is discussed enough erijo as long as the gui knows that the message is encrypted, it can do whatever it likes. And, as long as message have a timestamp, the gui can chose to display a "Message encrypted!" placeholder if an clear-text message is received before the decrypted Rapp yep erijo but the decryptplugin has to be able to ask for a password. So we're back to that issue again... Rapp that is not hte issue of the decryptplugin Rapp that is the issue of the encryption library Rapp e.g. gpg-agent is called by gpgme Rapp and gpg-agent chooses an input method, e.g. a qt-dialog Rapp we do not have to know anything about that Rapp the only important thing is, that the decryption plugin runs as its own thread, because the input is blocking! erijo this wouldn't work with a html gui Rapp yes, true. that is the problem of the html gui :) erijo nor a console gui Rapp that i don't know. gpg-agent can also ask a passphrase on the console. but i am not sure if that works in a multi-threaded program Rapp anyhow: we cannot even do anything about it, because gpgme handles all that stuff. Rapp that is the good and the bad about gpgme erijo it isn't possible to pass a password to the decrypt function? Rapp other libraries might do it differently... but i think gpgme will be the most used plugin Rapp hmmmm Rapp lemme see Rapp oh, yes, we can set a passphrase callback Rapp although gpgme advises to let the backend engine (e.g. gpg) use its own passphrase agent Rapp *slap* Rapp man i am stupid erijo if $DISPLAY is set then let gpgme handle it, else send a message asking the gui to ask the user Rapp this solves also a current problem of blocking the qt-gui.... Rapp exactly Rapp ok, i have got to leave Rapp will you send a log of this session to the list, or shall i do this? erijo please do :) Rapp ok. then cu next week or so
pgpCHO3ELwucx.pgp
Description: PGP signature
_______________________________________________ Licq-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/licq-devel
