Re: GSoC History plugin
On Saturday 20 June 2015 15:56:05 Joshua Joseph wrote: On Sat, Jun 20, 2015 at 4:38 PM, Pali Rohár pali.ro...@gmail.com wrote: I had not thought of that. :) Same for Contact: Does not it make sense to store Kopete::Contact representing room? Or do you think it is not needed at all? Yes. I will change to Kopete::Contact. I think you did not change anything, or yes? Just changed the type column to int. Anyway detecting multi user chat messages with that mutually exclusive condition (only one of contact/session or name is set) is really hard to imagine and also write correct select sql statement (it is even possible to write optimal one for SQLite??). Rather use some multi user group chat boolean column (in SQLite there is no boolean, just int). LIke this? Still I do not know what description means... There is still information about If in multi user mode... and so on. Also timestamp cannot be text. --messages table CREATE TABLE messages ( id Integer Primary Key Autoincrement Not Null, --Unique message identifier timestamp Text, --When the message was handled message Text, --HTML containing the message contents protocol Text Not Null, --Protocol used (Kopete::Protocol::pluginId()) account Text Not Null, --Account used (Kopete::Account::accountId()) direction Integer Not Null, --(Inbound = 0, Outbound=1, Internal=2) (Kopete::Message::MessageDirection) importance Integer, -- (Low, Normal, Highlight) (Kopete::Message) (Kopete::Message::MessageImportance) contact Text, -- The local contact used in this message (if applicable). (Kopete::Contact::ContactId()). If present, we know we are in single user mode. subject Text, --If applicable, this will store the subject of the message session Text, -- Internal session identifier. session_name Text, -- If in multi user mode, a human readable name for the session. from Text, --Internal identifier for the message sender from_name Text, --Human readable name of the message sender to Text, --Internal identifier for the message recipient to_name Text, --Human readable name of the message recipient. state Integer, --(Unknown = 0, Sending = 1, Sent = 2, Error = 3) type Integer, --The type of message. (TypeNormal, TypeAction, TypeFileTransferRequest, TypeVoiceClipRequest) (Kopete::Message::MessageType) is_group Integer Default='0' --If this is set to 1, then we know we are in multi user mode. ) session_name Text, -- If in multi user mode, a human readable name for the session. from Text, --Internal identifier for the message sender from_name Text, --Human readable name of the message sender to Text, --Internal identifier for the message recipient to_name Text, --Human readable name of the message recipient. Kopete::Message::from() and Kopete::Message::to() can represent those from/to values... Just to note that Kopete::Message::to() is list of Kopete::Contact object. It is not single/one Kopete::Contact. Maybe storing it as concatenation with , separator? Or totally drop list and just store first Contact? Its better to store all with a preset delimiter. Ok. I think that most kopete protocols (maybe all now??) just set one contact for Kopete::Message::to() value. So I think that in future (when Kopete::Message will be ported to KF5) we could change list to single value. If you think that full list is needed, we can use delimiter and maybe in future change it only to single value. Noted. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
Re: Review Request 124094: Do away with K3ListBox classes texteffect plugin
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124094/#review81595 --- plugins/texteffect/texteffectpreferences.cpp (line 149) https://git.reviewboard.kde.org/r/124094/#comment55929 better to use ++f plugins/texteffect/texteffectpreferences.cpp (line 151) https://git.reviewboard.kde.org/r/124094/#comment55928 why don't add directly ret.appent(...-item(f)-text()) ? plugins/texteffect/texteffectpreferences.cpp (line 184) https://git.reviewboard.kde.org/r/124094/#comment55930 currentItem no ? single selection plugins/texteffect/texteffectpreferences.cpp (line 187) https://git.reviewboard.kde.org/r/124094/#comment55931 Remove loop currentItem plugins/texteffect/texteffectpreferences.cpp (line 204) https://git.reviewboard.kde.org/r/124094/#comment55932 currentItem ? plugins/texteffect/texteffectpreferences.cpp (line 232) https://git.reviewboard.kde.org/r/124094/#comment55933 fix indent - Laurent Montel On juin 19, 2015, 7:13 après-midi, R.Harish Navnit wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124094/ --- (Updated juin 19, 2015, 7:13 après-midi) Review request for Kopete, Laurent Montel and Pali Rohár. Repository: kopete Description --- Replace the K3ListBox classes with QListWidget. Diffs - plugins/texteffect/texteffectpreferences.cpp 35fac60d419cbac5644a8e143be1fc7c640385a9 plugins/texteffect/texteffectprefs.ui 1b82f3de4b449373a3dedb39b664c0f645f1d02a Diff: https://git.reviewboard.kde.org/r/124094/diff/ Testing --- Build succeeds. Thanks, R.Harish Navnit ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
Kopete - PGP Plugin (GSoC 2015)
Hello everybody, Below I attach the updated timeline for this year's GSoC project, where you can find detailed information about my current (and future) work. For the time being, there is a git repo which you can find here: http://nikhatzi.gr:9091/nikhatzi/kopete (latest code will be updated in about 2-3 days, as I study for my exams too). My project is also updated in the kde gsoc reports status page. Frequent e-mails will be sent from now on to this list to update everyone interested with the latest changes. Thank you for your time and the opportunity to work on this awesome project! Yours, Nikolaos Chatzidakis GSoC 2015 PGP Plugin Timeline (updated) By the time of writing this timeline, the backbone of the PGP plugin is ready. Some problems occurred though, that need to be resolved with the respective developers of the library used in the project (QCA). June 22-30: Add account menu in plugin so that the user can select different key for every account that he/she uses. The KCM module is ready and able to display a combo list to select a key for encrypting messages. All info combined will be store in the gnupg-keyring. July 1-12: Expand the PGP plugin to make it easy for the user to select a contacts public key. Corresponding menu will be added in kopetes right-click menu to simplify usage. The same time, the chat window will be configured to allow an encrypted session initiation, after contacting with the other person to verify that he has our public key selected. (There will be no public key validation for obvious reasons. Doing so via an unencrypted channel provides no protection at all) 13-19: Alpha version of PGP plugin. There will be a public call for help. Users will be able to try the new plugin, test it thoroughly and report any bugs found to be resolved. 20-26: The new PGP plugin uses the QCA Qt library for encrypting/decrypting messages, as well as storing the keys info in the gnupg-keyring. Current version in most GNU/Linux distributions is 2.1, which results to installing the QCA plugins as a separate package. Since version 2.1 (stable), QCA is bundled with all the plugins included, which means that the new plugin must take into account the version of QCA and respond respectively, so that it will be backwards compatible with older versions of the library. During this period there will be a contact with the QCA developers to clear things up on how to proceed. 27-31: After expanding the plugin to be backwards compatible there will be Beta version of the plugin with public call for help. Users with any QCA library version will be asked to try the new version to insure interoperability of the new plugin. Bugs will be fixed. August 1-9: Since in this years GSoC kopete is under heavy development, a fellow GSoCer is responsible for porting Kopete to latest KF5 libraries. Its a good idea to start porting the plugin to the new KF5 libraries and make it compatible with the new release of kopete. This way we can be sure that the new plugin wont create any problems with later version of Kopete and will last for a long time using latest technologies. 10-16: Heavy development with the help of R. Harish Navnit for kopete-kf5 specific issues. 17-24: Unit testing of final PGP release, bug fixing and documentation. Notes: During this timeline I omitted the evaluation periods, and didnt count them as dead time during GSoC, since the PGP plugin is an ongoing work and time-demanding to be left for some days on its own. ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
Re: GSoC History plugin
On Sat, Jun 20, 2015 at 5:22 PM, Pali Rohár pali.ro...@gmail.com wrote: On Saturday 20 June 2015 15:56:05 Joshua Joseph wrote: On Sat, Jun 20, 2015 at 4:38 PM, Pali Rohár pali.ro...@gmail.com wrote: I had not thought of that. :) Same for Contact: Does not it make sense to store Kopete::Contact representing room? Or do you think it is not needed at all? Yes. I will change to Kopete::Contact. I think you did not change anything, or yes? Just changed the type column to int. Anyway detecting multi user chat messages with that mutually exclusive condition (only one of contact/session or name is set) is really hard to imagine and also write correct select sql statement (it is even possible to write optimal one for SQLite??). Rather use some multi user group chat boolean column (in SQLite there is no boolean, just int). LIke this? Still I do not know what description means... There is still information about If in multi user mode... and so on. Also timestamp cannot be text. I'd sent in the wrong one: --messages table CREATE TABLE messages ( id Integer Primary Key Autoincrement Not Null, --Unique message identifier timestamp Integer, --When the message was handled message Text, --HTML containing the message contents protocol Text Not Null, --Protocol used (Kopete::Protocol::pluginId()) account Text Not Null, --Account used (Kopete::Account::accountId()) direction Integer Not Null, --(Inbound = 0, Outbound=1, Internal=2) (Kopete::Message::MessageDirection) importance Integer, -- (Low, Normal, Highlight) (Kopete::Message) (Kopete::Message::MessageImportance) contact Text, -- The local contact used in this message (if applicable). (Kopete::Contact::ContactId()). If present, we know we are in single user mode. subject Text, --If applicable, this will store the subject of the message session Text, -- Internal session identifier. session_name Text, -- A human readable name for the session. from Text, --Internal identifier for the message sender from_name Text, --Human readable name of the message sender to Text, --Internal identifier for the message recipient to_name Text, --Human readable name of the message recipient. state Integer, --(Unknown = 0, Sending = 1, Sent = 2, Error = 3) type Integer, --The type of message. (TypeNormal, TypeAction, TypeFileTransferRequest, TypeVoiceClipRequest) (Kopete::Message::MessageType) is_group Integer Default='0' --If this is set to 1, then we know we are in multi user mode. ) Thanks, Joshua ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
Re: GSoC History plugin
On Saturday 20 June 2015 16:31:50 Joshua Joseph wrote: On Sat, Jun 20, 2015 at 5:22 PM, Pali Rohár pali.ro...@gmail.com wrote: On Saturday 20 June 2015 15:56:05 Joshua Joseph wrote: On Sat, Jun 20, 2015 at 4:38 PM, Pali Rohár pali.ro...@gmail.com wrote: I had not thought of that. :) Same for Contact: Does not it make sense to store Kopete::Contact representing room? Or do you think it is not needed at all? Yes. I will change to Kopete::Contact. I think you did not change anything, or yes? Just changed the type column to int. Anyway detecting multi user chat messages with that mutually exclusive condition (only one of contact/session or name is set) is really hard to imagine and also write correct select sql statement (it is even possible to write optimal one for SQLite??). Rather use some multi user group chat boolean column (in SQLite there is no boolean, just int). LIke this? Still I do not know what description means... There is still information about If in multi user mode... and so on. Also timestamp cannot be text. I'd sent in the wrong one: --messages table CREATE TABLE messages ( id Integer Primary Key Autoincrement Not Null, --Unique message identifier timestamp Integer, --When the message was handled message Text, --HTML containing the message contents protocol Text Not Null, --Protocol used (Kopete::Protocol::pluginId()) account Text Not Null, --Account used (Kopete::Account::accountId()) direction Integer Not Null, --(Inbound = 0, Outbound=1, Internal=2) (Kopete::Message::MessageDirection) importance Integer, -- (Low, Normal, Highlight) (Kopete::Message) (Kopete::Message::MessageImportance) contact Text, -- The local contact used in this message (if applicable). (Kopete::Contact::ContactId()). If present, we know we are in single user mode. Hm? subject Text, --If applicable, this will store the subject of the message session Text, -- Internal session identifier. session_name Text, -- A human readable name for the session. from Text, --Internal identifier for the message sender from_name Text, --Human readable name of the message sender to Text, --Internal identifier for the message recipient to_name Text, --Human readable name of the message recipient. state Integer, --(Unknown = 0, Sending = 1, Sent = 2, Error = 3) type Integer, --The type of message. (TypeNormal, TypeAction, TypeFileTransferRequest, TypeVoiceClipRequest) (Kopete::Message::MessageType) is_group Integer Default='0' --If this is set to 1, then we know we are in multi user mode. ) Thanks, Joshua -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
Re: GSoC History plugin
On Sat, Jun 20, 2015 at 4:38 PM, Pali Rohár pali.ro...@gmail.com wrote: I had not thought of that. :) Same for Contact: Does not it make sense to store Kopete::Contact representing room? Or do you think it is not needed at all? Yes. I will change to Kopete::Contact. I think you did not change anything, or yes? Just changed the type column to int. Anyway detecting multi user chat messages with that mutually exclusive condition (only one of contact/session or name is set) is really hard to imagine and also write correct select sql statement (it is even possible to write optimal one for SQLite??). Rather use some multi user group chat boolean column (in SQLite there is no boolean, just int). LIke this? --messages table CREATE TABLE messages ( id Integer Primary Key Autoincrement Not Null, --Unique message identifier timestamp Text, --When the message was handled message Text, --HTML containing the message contents protocol Text Not Null, --Protocol used (Kopete::Protocol::pluginId()) account Text Not Null, --Account used (Kopete::Account::accountId()) direction Integer Not Null, --(Inbound = 0, Outbound=1, Internal=2) (Kopete::Message::MessageDirection) importance Integer, -- (Low, Normal, Highlight) (Kopete::Message) (Kopete::Message::MessageImportance) contact Text, -- The local contact used in this message (if applicable). (Kopete::Contact::ContactId()). If present, we know we are in single user mode. subject Text, --If applicable, this will store the subject of the message session Text, -- Internal session identifier. session_name Text, -- If in multi user mode, a human readable name for the session. from Text, --Internal identifier for the message sender from_name Text, --Human readable name of the message sender to Text, --Internal identifier for the message recipient to_name Text, --Human readable name of the message recipient. state Integer, --(Unknown = 0, Sending = 1, Sent = 2, Error = 3) type Integer, --The type of message. (TypeNormal, TypeAction, TypeFileTransferRequest, TypeVoiceClipRequest) (Kopete::Message::MessageType) is_group Integer Default='0' --If this is set to 1, then we know we are in multi user mode. ) session_name Text, -- If in multi user mode, a human readable name for the session. from Text, --Internal identifier for the message sender from_name Text, --Human readable name of the message sender to Text, --Internal identifier for the message recipient to_name Text, --Human readable name of the message recipient. Kopete::Message::from() and Kopete::Message::to() can represent those from/to values... Just to note that Kopete::Message::to() is list of Kopete::Contact object. It is not single/one Kopete::Contact. Maybe storing it as concatenation with , separator? Or totally drop list and just store first Contact? Its better to store all with a preset delimiter. Ok. I think that most kopete protocols (maybe all now??) just set one contact for Kopete::Message::to() value. So I think that in future (when Kopete::Message will be ported to KF5) we could change list to single value. If you think that full list is needed, we can use delimiter and maybe in future change it only to single value. Noted. -- Pali Rohár pali.ro...@gmail.com ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel -- Thanks, Joshua ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
Re: GSoC History plugin
On Sat, Jun 20, 2015 at 5:35 PM, Pali Rohár pali.ro...@gmail.com wrote: On Saturday 20 June 2015 16:31:50 Joshua Joseph wrote: On Sat, Jun 20, 2015 at 5:22 PM, Pali Rohár pali.ro...@gmail.com wrote: On Saturday 20 June 2015 15:56:05 Joshua Joseph wrote: On Sat, Jun 20, 2015 at 4:38 PM, Pali Rohár pali.ro...@gmail.com wrote: I had not thought of that. :) Same for Contact: Does not it make sense to store Kopete::Contact representing room? Or do you think it is not needed at all? Yes. I will change to Kopete::Contact. I think you did not change anything, or yes? Just changed the type column to int. Anyway detecting multi user chat messages with that mutually exclusive condition (only one of contact/session or name is set) is really hard to imagine and also write correct select sql statement (it is even possible to write optimal one for SQLite??). Rather use some multi user group chat boolean column (in SQLite there is no boolean, just int). LIke this? Still I do not know what description means... There is still information about If in multi user mode... and so on. Also timestamp cannot be text. I'd sent in the wrong one: --messages table CREATE TABLE messages ( id Integer Primary Key Autoincrement Not Null, --Unique message identifier timestamp Integer, --When the message was handled message Text, --HTML containing the message contents protocol Text Not Null, --Protocol used (Kopete::Protocol::pluginId()) account Text Not Null, --Account used (Kopete::Account::accountId()) direction Integer Not Null, --(Inbound = 0, Outbound=1, Internal=2) (Kopete::Message::MessageDirection) importance Integer, -- (Low, Normal, Highlight) (Kopete::Message) (Kopete::Message::MessageImportance) contact Text, -- The local contact used in this message (if applicable). (Kopete::Contact::ContactId()). If present, we know we are in single user mode. Hm? subject Text, --If applicable, this will store the subject of the message session Text, -- Internal session identifier. session_name Text, -- A human readable name for the session. from Text, --Internal identifier for the message sender from_name Text, --Human readable name of the message sender to Text, --Internal identifier for the message recipient to_name Text, --Human readable name of the message recipient. state Integer, --(Unknown = 0, Sending = 1, Sent = 2, Error = 3) type Integer, --The type of message. (TypeNormal, TypeAction, TypeFileTransferRequest, TypeVoiceClipRequest) (Kopete::Message::MessageType) is_group Integer Default='0' --If this is set to 1, then we know we are in multi user mode. ) Thanks, Joshua -- Pali Rohár pali.ro...@gmail.com ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel Oh My! It seems I am not yet awake fully. --messages table CREATE TABLE messages ( id Integer Primary Key Autoincrement Not Null, --Unique message identifier timestamp Integer, --When the message was handled message Text, --HTML containing the message contents protocol Text Not Null, --Protocol used (Kopete::Protocol::pluginId()) account Text Not Null, --Account used (Kopete::Account::accountId()) direction Integer Not Null, --(Inbound = 0, Outbound=1, Internal=2) (Kopete::Message::MessageDirection) importance Integer, -- (Low, Normal, Highlight) (Kopete::Message) (Kopete::Message::MessageImportance) contact Text, -- The local contact used in this message (if applicable). (Kopete::Contact::ContactId()). subject Text, --If applicable, this will store the subject of the message session Text, -- Internal session identifier. session_name Text, -- A human readable name for the session. from Text, --Internal identifier for the message sender from_name Text, --Human readable name of the message sender to Text, --Internal identifier for the message recipient to_name Text, --Human readable name of the message recipient. state Integer, --(Unknown = 0, Sending = 1, Sent = 2, Error = 3) type Integer, --The type of message. (TypeNormal, TypeAction, TypeFileTransferRequest, TypeVoiceClipRequest) (Kopete::Message::MessageType) is_group Integer Default='0' --If this is set to 1, then we know we are in multi user mode. ) Sorry about that. -- Thanks, Joshua ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
Re: GSoC History plugin
On Saturday 20 June 2015 17:07:06 Joshua Joseph wrote: On Sat, Jun 20, 2015 at 5:35 PM, Pali Rohár pali.ro...@gmail.com wrote: On Saturday 20 June 2015 16:31:50 Joshua Joseph wrote: On Sat, Jun 20, 2015 at 5:22 PM, Pali Rohár pali.ro...@gmail.com wrote: On Saturday 20 June 2015 15:56:05 Joshua Joseph wrote: On Sat, Jun 20, 2015 at 4:38 PM, Pali Rohár pali.ro...@gmail.com wrote: I had not thought of that. :) Same for Contact: Does not it make sense to store Kopete::Contact representing room? Or do you think it is not needed at all? Yes. I will change to Kopete::Contact. I think you did not change anything, or yes? Just changed the type column to int. Anyway detecting multi user chat messages with that mutually exclusive condition (only one of contact/session or name is set) is really hard to imagine and also write correct select sql statement (it is even possible to write optimal one for SQLite??). Rather use some multi user group chat boolean column (in SQLite there is no boolean, just int). LIke this? Still I do not know what description means... There is still information about If in multi user mode... and so on. Also timestamp cannot be text. I'd sent in the wrong one: --messages table CREATE TABLE messages ( id Integer Primary Key Autoincrement Not Null, --Unique message identifier timestamp Integer, --When the message was handled message Text, --HTML containing the message contents protocol Text Not Null, --Protocol used (Kopete::Protocol::pluginId()) account Text Not Null, --Account used (Kopete::Account::accountId()) direction Integer Not Null, --(Inbound = 0, Outbound=1, Internal=2) (Kopete::Message::MessageDirection) importance Integer, -- (Low, Normal, Highlight) (Kopete::Message) (Kopete::Message::MessageImportance) contact Text, -- The local contact used in this message (if applicable). (Kopete::Contact::ContactId()). If present, we know we are in single user mode. Hm? subject Text, --If applicable, this will store the subject of the message session Text, -- Internal session identifier. session_name Text, -- A human readable name for the session. from Text, --Internal identifier for the message sender from_name Text, --Human readable name of the message sender to Text, --Internal identifier for the message recipient to_name Text, --Human readable name of the message recipient. state Integer, --(Unknown = 0, Sending = 1, Sent = 2, Error = 3) type Integer, --The type of message. (TypeNormal, TypeAction, TypeFileTransferRequest, TypeVoiceClipRequest) (Kopete::Message::MessageType) is_group Integer Default='0' --If this is set to 1, then we know we are in multi user mode. ) Thanks, Joshua -- Pali Rohár pali.ro...@gmail.com ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel Oh My! It seems I am not yet awake fully. --messages table CREATE TABLE messages ( id Integer Primary Key Autoincrement Not Null, --Unique message identifier timestamp Integer, --When the message was handled message Text, --HTML containing the message contents protocol Text Not Null, --Protocol used (Kopete::Protocol::pluginId()) account Text Not Null, --Account used (Kopete::Account::accountId()) direction Integer Not Null, --(Inbound = 0, Outbound=1, Internal=2) (Kopete::Message::MessageDirection) importance Integer, -- (Low, Normal, Highlight) (Kopete::Message) (Kopete::Message::MessageImportance) contact Text, -- The local contact used in this message (if applicable). (Kopete::Contact::ContactId()). subject Text, --If applicable, this will store the subject of the message session Text, -- Internal session identifier. session_name Text, -- A human readable name for the session. from Text, --Internal identifier for the message sender from_name Text, --Human readable name of the message sender to Text, --Internal identifier for the message recipient to_name Text, --Human readable name of the message recipient. state Integer, --(Unknown = 0, Sending = 1, Sent = 2, Error = 3) type Integer, --The type of message. (TypeNormal, TypeAction, TypeFileTransferRequest, TypeVoiceClipRequest) (Kopete::Message::MessageType) is_group Integer Default='0' --If this is set to 1, then we know we are in multi user mode. ) Sorry about that. -- Thanks, Joshua Ok, looks good. Maybe also timestamp and message should not be null... Now to implement it! -- Pali Rohár pali.ro...@gmail.com signature.asc
Re: GSoC History plugin
On Fri, Jun 19, 2015 at 7:03 PM, Pali Rohár pali.ro...@gmail.com wrote: On Friday 19 June 2015 16:54:57 Joshua Joseph wrote: On Fri, Jun 19, 2015 at 10:33 AM, Pali Rohár pali.ro...@gmail.com wrote: On Friday 19 June 2015 09:59:17 Joshua Joseph wrote: On Thu, Jun 18, 2015 at 10:07 PM, Pali Rohár pali.ro...@gmail.com wrote: I get it now. We will have to store the contactId() also. I will need to get good column names to avoid confusion with the foreign key columns. See my yesterday email where I proposed to store pluginId() as protocol, accounId() as account, contactId() as contact and from/to values to be protocol dependent. And another question: Do we need to separate table for group chat messages? Cannot we use some chat session identifier for each message? That would also work. See my schema below for a one table based approach. If for each message we store these data: protocol independent: * protocol - Kopete::Protocol::pluginId() - not null * account - Kopete::Protocol::accoundId() - not null * direction - Kopete::Message::direction() - not null * contact - Kopete::Protocol::contactId() protocol dependent (all strings): * session - session identifier * session_name - human readable name of session * from - from contact identifier * from_name - human readable from contact name * to - to contact identifier * to_name - human readable to contact name See this schema. I think it will capture all of the above. For protocol, account and contact fields, I have used Text columns. I am also adding a message_type column, so that we can keep track of special messages such as room events (user join, quit etc). Do you think that that will be necessary? I think this is handled by Kopete::Message::MessageDirection::Internal: http://api.kde.org/4.x-api/kdenetwork-apidocs/kopete/libkopete/html/classKopete_1_1Message.html Maybe it make sense to add GUI option to enable/disable logging of internal messages. For somebody it could be useless and just take space on disk. For somebody else it could be useful to see when contact sent some file or left/joined group chat... (and when you are sending schema or part of source code via email, please do not wrap schema lines as it is hard to read) --messages table CREATE TABLE messages ( message_id Integer Primary Key Autoincrement Not Null --Unique message identifier timestamp Text --When the message was handled message Text --HTML containing the message contents protocol Text Not Null --Protocol used (Kopete::Protocol::pluginId()) account Text Not Null --Account used (Kopete::Account::accountId()) direction Integer Not Null --(Inbound = 0, Outbound=1, Internal=2) (Kopete::Message::MessageDirection) importance Integer -- (Low, Normal, Highlight) (Kopete::Message) (Kopete::Message::MessageImportance) contact Text -- The local contact used in this message (if applicable). (Kopete::Contact::ContactId()). If present, we know we are in single user mode. subject Text --If applicable, this will store the subject of the message session Text -- Internal session identifier. If this is provided, then we know we are in multi user mode. session_name Text -- If in multi user mode, a human readable name for the session. from Text --Internal identifier for the message sender from_name Text --Human readable name of the message sender to Text --Internal identifier for the message recipient to_name Text --Human readable name of the message recipient. message_type --The type of message. (TypeNormal, TypeAction, TypeFileTransferRequest, TypeVoiceClipRequest) (Kopete::Message::MessageType) ) Why message_ prefix (for message_type and message_id) if other columns which you are propose do not have message_ prefix? And there is missing Kopete::Message::MessageState property. See the schema below, I have updated it. Timestamp should be integer as SQLite does not have dedicated DATE type and I do not thing that it can use indexes on string date formats for fast search (e.g all messages which were sent in specific day). Yes. For other db systems that will be quite doable and fast. For SQLite we just need to stay with integer... Anyway, I think that current solution could work now. What can be useful space optimization: There will be more times rows with duplicate string columns (protocol, account, contact, session, *_name). Maybe it could make sense to create new tables for it and reference integer foreign keys from message tables. For now we can proceed with a
Re: Kopete - PGP Plugin (GSoC 2015)
Hi, On Sun, Jun 21, 2015 at 3:55 AM, Pali Rohár pali.ro...@gmail.com wrote: Also your new gpg plugin could be drop-in replacement for old cryptography plugin, so once it will be finished I would like to delete source code and documentation of cryptography plugin from Kopete tree. So, can I ignore this plugin while porting ? It seems to be free of k3 classes anyways, so I'm not concerned about it at the moment. Cheers, R.Harish Navnit The Enigma http://harishnavnit.wordpress.com/ ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
Re: Kopete - PGP Plugin (GSoC 2015)
On Saturday 20 June 2015 18:59:04 Nikos Chatzidakis wrote: Hello everybody, Below I attach the updated timeline for this year's GSoC project, where you can find detailed information about my current (and future) work. For the time being, there is a git repo which you can find here: http://nikhatzi.gr:9091/nikhatzi/kopete (latest code will be updated in about 2-3 days, as I study for my exams too). My project is also updated in the kde gsoc reports status page. Frequent e-mails will be sent from now on to this list to update everyone interested with the latest changes. Thank you for your time and the opportunity to work on this awesome project! Yours, Nikolaos Chatzidakis Hi! Thanks for information. I would propose to rename your new plugin to gpg or gnupg as will only supports PGP encryption/signatures via gnupg (implemented by qca-gnupg plugin). We already have otr plugin in Kopete which implements OTR cryptography and your current name cryptography2 is not so good idea. Anyway, look into cryptography plugin which is in Kopete tree. It stores public for Kopete::MetaContact into contact list plugin data. Raw xml file is in ~/.kde/share/apps/kopete/contactlist.xml. MetaContact class represent list of all contacts (Kopete::Contact) and it would be nice to support per contact key (not per metacontact), like otr plugin. Also your new gpg plugin could be drop-in replacement for old cryptography plugin, so once it will be finished I would like to delete source code and documentation of cryptography plugin from Kopete tree. There will be probably problem that switching to new version will loose configuration of per metacontact public keys. And it would be cool to migrate these old settings to new plugin. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
