kmess-devel — Internal bug discussion

Re: [KMess-devel] Downloading MsnObjects in master (/hilight Diederik)

[Diederik v. d. B. <vd...@km...>]

Hi Sjors,

Sorry for my really later reply. I hope my input is valuable nevertheless.

There isn't much "bookkeeping" of MsnObjects. What currently happens:
  * The ChatMaster checks whether the file exists, and downloads it otherwise.
  * Things like display picture, and emoticon mappings are stored in-memory 
per-contact.

The responsability could be in the application. There is a signal 
"receivedMsnObjectAnnouncement" and the app can deside what to do. See:
  * http://trac.kmess.org/wiki/MSN%20Protocol%20Library%20Ideas
  * http://trac.kmess.org/attachment/wiki/LibKMess%20Design/kmess-network-
library.png

As for the msntransport lib, it has the protocol basics implemented,
and misses the top-level layer (for End-User-Features) to start a download.

Greetings,

Diederik


Op dinsdag 22 februari 2011 18:48:48 schreef u:
> Hi all,
> 
> I've been looking at the reason why custom emoticons are not shown yet. Now
> that the library correctly links custom emoticons to their messages
> instead of to the contacts that sent them, the behaviour of the library is
> correct. However, in the frontend, the RichTextParser still only looks at
> the contact. I've decided to leave the hack be in the frontend: it's a lot
> easier to fix it later than it is to fix it now. So, once the frontend
> receives a message with custom emoticons in it, it promptly gives the
> custom emoticon shortcuts and their MsnObjectData to the contact to hold
> again. This way, most of the frontend can still work like it did, but at
> least the library has the correct behaviour.
> 
> Then, I started looking at how the actual emoticon file is downloaded;
> let's refresh our minds. In stable, the MsnSwitchboardConnection emits a
> gotMsnObject() signal to the ChatMaster to tell it to download MsnObject
> data unless it already exists. The ChatMaster, after some checks,
> continues to start a MsnObjectTransferP2P application to get the object.
> Eventually, slotMsnObjectReceived is called, which eventually shows the
> object: it either sets it as the contact picture path, shows it as a wink,
> or adds it as the file for a custom emoticon and tells the chat window to
> 'refresh' its view.
> 
> Most of this infrastructure is gone in the master version. On one end,
> MsnChat has the gotMsnObject/startMsnObjectDownload calls commented out,
> because nothing implements those at the moment. On the other end,
> showMsnObject is commented out because it references classes like
> KMessConfig, ContactExtension and Chat to actually change stuff, which are
> in frontend code.
> 
> So we have a few things to implement.
> 
> 1. First of all, some class should get the responsibility of 'bookkeeping'
> MsnObjects: checking if they exist and are valid, and starting their
> download if they aren't. I don't think this should be MsnChat (but it
> might be a worty option); MsnSession sounds like the right class to me. 2.
> Second, there should be a class that actually does the transfer. This used
> to be MsnObjectTransferP2P, a P2PApplication, but even that base class
> doesn't exist in the library anymore. I expect something in
> contrib/msntransport will replace it, but that isn't used yet. 3. Last,
> there should be a message back from the transfer class to showMessage or
> something in the library that the download is completed.
> 
> Here, I've even assumed that we *want* the library to automatically
> download MsnObjects it doesn't know (and I've abstracted away from the
> problem that the library doesn't really have some place to store temporary
> cache files like MsnObjects yet).
> 
> Which class do you think should get responsibility of starting MsnObject
> downloads? Then at least we can make MsnChat link to that class, and we
> can put stubs there. And, (primarily to Diederik,) how is msntransport
> doing? Does it have a class to do P2P downloads? How much work will it be
> to port MsnObjectTransferP2P to, or write a similar class for
> msntransport?
> 
> Once these parts are in place, it will probably be easy to let the
> application decide to download MsnObjects if it doesn't have them, instead
> of the library deciding on itself it needs to download a MsnObject the
> application might not even use.
> 
> Sjors

-- 
 Diederik van der Boor, KMess developer
 Web: www.codingdomain.com

Re: [KMess-devel] Trying to implement the first part of MSNSLP in master

[Sjors G. <sj...@sj...>]

Op 15 apr 2011, om 16:04 heeft Sjors Gielen het volgende geschreven:

> Op 15 apr 2011, om 12:38 heeft Sjors Gielen het volgende geschreven:
> 
>> First of all, I think I'm going to implement invitations. I've looked through msntransport and the MIME type for invitations is nowhere in there, but the invitation keywords "INVITE", "BYE" etc are there. I think the complete SLP dialog is in msntransport/src/msnslp/dialog.h, but I don't know what layer this is; the dialog is built up of Transactions which the msnslp bot can create itself. So if, for every chat, the msnslp bot keeps track of a list of dialogs, would that be a good way to start this?
> 
> Apparantly, the things I've been seeing were invitations into MSNFTP. Is MSNFTP still used nowadays? I somehow remember it is old and unused, but KMess 2.0.x still seems to do it by default. I can implement it in the msnslp bot, but if it's useless to begin with, why bother. That's why I'm asking ;-)

Apparantly, MSNFTP is _newer_ than MSNP2P, it's the currently preferred way. Both MSNFTP and MSNP2P are described on this page: <http://www.hypothetic.org/docs/msn/client/file_transfer.php>. MSNP2P is used as a fallback to MSNFTP and is still used either way for the display picture and other msnobject transfers (I think). So we should implement both, but with a slight edge to MSNP2P as it is needed either way.

MSNFTP is quite easy to handle. MSNP2P is where the msntransport library comes in. All application/x-msnmsgrp2p packets should be sent through the library. It will parse the P2P header, the SLP contents, and the actual requests and responses. Actual behaviour, such as file/msnobject saving, can happen by implementing EUF handlers (EUF = End User Feature). An interface (base class) for those handlers is in the library; you register them through the Platform and when you hand messages to the Platform, the EUF handler methods will be called.

I don't understand everything happening in the library, but this is the focus I will have implementing this the coming days. I will try to interface with the msntransport library for doing MSNP2P in the test bot, and once I reach a sort-of stable state where, for example, MsnObjects can be retrieved, I will start moving stuff into the library. Once it has pretty MSNP2P support, I will start adding MSNFTP, but the largest milestone will have been reached. :)

Please let me know what you guys think, any suggestions or ideas.

Sjors

Re: [KMess-devel] Trying to implement the first part of MSNSLP in master

[Sjors G. <sj...@sj...>]

Op 15 apr 2011, om 12:38 heeft Sjors Gielen het volgende geschreven:

> First of all, I think I'm going to implement invitations. I've looked through msntransport and the MIME type for invitations is nowhere in there, but the invitation keywords "INVITE", "BYE" etc are there. I think the complete SLP dialog is in msntransport/src/msnslp/dialog.h, but I don't know what layer this is; the dialog is built up of Transactions which the msnslp bot can create itself. So if, for every chat, the msnslp bot keeps track of a list of dialogs, would that be a good way to start this?

Apparantly, the things I've been seeing were invitations into MSNFTP. Is MSNFTP still used nowadays? I somehow remember it is old and unused, but KMess 2.0.x still seems to do it by default. I can implement it in the msnslp bot, but if it's useless to begin with, why bother. That's why I'm asking ;-)

Sjors

[KMess-devel] Trying to implement the first part of MSNSLP in master

[Sjors G. <sj...@sj...>]

Op 25 mrt 2011, om 07:05 heeft Adam Goossens het volgende geschreven:

> On the P2P side, I've been able to wrap my head around a lot of the
> concepts as well so if you want someone to bounce ideas off, let me
> know.

Hi Adam and rest,

So _everything_ regarding msnslp, file or display picture transfer is gone in master. We're going to have to start from scratch here, which is a good thing, because now we can do it in a more structured way using the msntransfer library by Gregg.

However, I'm afraid to actually start, as I don't understand the whole picture, probably until I've implemented it all. Therefore, I've copied the KMess Echobot into a seperate directory called the "MSNSLP tester" (it's in the kmess-bots repository on Gitorious). I intend to try to implement most of MSNSLP *inside* this bot, and have it all working, before I start gradually moving things into the library itself. I hope this will enable me to make more mistakes, to see the big picture before I modify the library, and to have an easier testing bed. Of course, I would like your help (your=all of you) while starting to implement things.

First of all, I think I'm going to implement invitations. I've looked through msntransport and the MIME type for invitations is nowhere in there, but the invitation keywords "INVITE", "BYE" etc are there. I think the complete SLP dialog is in msntransport/src/msnslp/dialog.h, but I don't know what layer this is; the dialog is built up of Transactions which the msnslp bot can create itself. So if, for every chat, the msnslp bot keeps track of a list of dialogs, would that be a good way to start this?

By the way, the msntransport library is built around a Platform singleton, which we don't want considering the library shouldn't use anything that's static and non-const. So, I think we should remove the const-ism in Platform, and create a Platform per msnslp bot and eventually, per library instance. Agreed? (As far as I can see, there's no reason to have the Platform as a singleton, except it's easier to get to the object if you know you just have one...)

Sjors

[KMess-devel] master fails to build

[Sjors G. <sj...@km...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

On my machine, currently, master fails to build. I believe this is related to a patch by Ruben; maybe that patch made it worse, maybe it made it better, but all I know is my build fails with the following error:

/Users/sjors/Projecten/kmess/master/build/src/kmessdbusadaptor.cpp: In member function ‘DBusContactList RemoteControlAdaptor::getFriendlyName()’:
/Users/sjors/Projecten/kmess/master/build/src/kmessdbusadaptor.cpp:51: error: conversion from ‘QString’ to non-scalar type ‘DBusContactList’ requested
/Users/sjors/Projecten/kmess/master/build/src/kmessdbusadaptor.cpp: In member function ‘QString RemoteControlAdaptor::getPersonalMessage()’:
/Users/sjors/Projecten/kmess/master/build/src/kmessdbusadaptor.cpp:57: error: ‘class KMessDBus’ has no member named ‘getPersonalMessage’
/Users/sjors/Projecten/kmess/master/build/src/kmessdbusadaptor.cpp: In member function ‘void RemoteControlAdaptor::setPersonalMessage(const QString&)’:
/Users/sjors/Projecten/kmess/master/build/src/kmessdbusadaptor.cpp:75: error: ‘class KMessDBus’ has no member named ‘setPersonalMessage’

Does anyone (Ruben?) have any idea what might be causing this, and how to fix it?

Sjors
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (Darwin)

iEYEARECAAYFAk2jm+QACgkQAZBOHH9jUAlB9gCaA4fmSyrKpAqnM9SdkjwvTO12
9rkAoI/0oekhnWaR2mpXlrFLFu1UboGE
=EJw6
-----END PGP SIGNATURE-----

Re: [KMess-devel] patch #35 question

[Sjors G. <sj...@sj...>]

Op 24 feb 2011, om 00:12 heeft Francesco Nwokeka het volgende geschreven:

> Hi guys,
> 	I'm finishing off the patch for ticket #35. I've got all the settings saved, loaded ecc.
> With how i done things you can also change you status together with your custom personal message. 
> But I've got one question: "are you guys shure you want a combobox instead of the inlineedit?"
> 
> It seems a bit ugly to me. Should I proceed or have you got some suggestions?

Hi Francesco,

I'm very sorry for the late reply. You see, most of us are quite inactive at the moment, and nobody got to responding in, well, almost two months. (We all are either busy studying, working, or founding a company - or a combination...)

About the issue: yeah, that ticket was created before we even had the InlineEdit, and the InlineEdit is actually quite nice. Maybe the two could be combined: have the inlineedit as a normal option, but have a dropdown 'button' at the right (just the button, not the complete widget), that when clicked displays a context menu with possible choices. Something similar to what happens when you click the KMess icon in the systray, or the status icon in the main window to the right.

Do you think that's doable? (If you still want to do it, of course :( )

Sjors

Re: [KMess-devel] Fwd: Applying for a reimbursement to the Desktop Summit 2011

[Adam G. <ada...@gm...>]

I won't be able to make it since I can't get the time off work unfortunately.

On the P2P side, I've been able to wrap my head around a lot of the
concepts as well so if you want someone to bounce ideas off, let me
know.

On Thu, Mar 24, 2011 at 5:33 AM, Sjors Gielen <sj...@sj...> wrote:
> Hi all,
>
> FYI. About the hotel rooms. Don't forget to send them an e-mail soon if you want sponsorship!
>
> BTW, about msnp2p: I'm working on an msnslp bot that will use the P2P messages from the library and the contrib/msnslp code to test whether I can get p2p to work. Eventually most of the code to make it will will go back into the library, but this makes it easier for me to test it. Now that both Diederik and Gregg aren't answering anymore, we'll have to find out most myself. I'll give you an update soon-ish.
>
> Begin doorgestuurd bericht:
>
>> From: Claudia Rauch
>> The reimbursement policy for bigger conferences (and that includes the
>> Desktop Summit) is that KDE e.V. usually reimburses 80% of the travel
>> costs (in your case: the plane ticket) and a certain fixed amount for
>> the accommodation. This time, we already arranged for a number of
>> hostel beds which have already been paid for. These are only for the
>> sponsored attendees. The hostel with those rooms is not listed on the
>> accommodation page, as I will allocated the beds for the sponsored KDE
>> attendees there.
>>
>> To sum up: if you get KDE e.V. sponsorship, I will book you a room in
>> that hostel, and you don't need to worry about it.
>
> Sjors
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software
> be a part of the solution? Download the Intel(R) Manageability Checker
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> KMess-devel mailing list
> KMe...@li...
> https://lists.sourceforge.net/lists/listinfo/kmess-devel
>
>

[KMess-devel] Fwd: Applying for a reimbursement to the Desktop Summit 2011

[Sjors G. <sj...@sj...>]

Hi all,

FYI. About the hotel rooms. Don't forget to send them an e-mail soon if you want sponsorship!

BTW, about msnp2p: I'm working on an msnslp bot that will use the P2P messages from the library and the contrib/msnslp code to test whether I can get p2p to work. Eventually most of the code to make it will will go back into the library, but this makes it easier for me to test it. Now that both Diederik and Gregg aren't answering anymore, we'll have to find out most myself. I'll give you an update soon-ish.

Begin doorgestuurd bericht:

> From: Claudia Rauch
> The reimbursement policy for bigger conferences (and that includes the
> Desktop Summit) is that KDE e.V. usually reimburses 80% of the travel
> costs (in your case: the plane ticket) and a certain fixed amount for
> the accommodation. This time, we already arranged for a number of
> hostel beds which have already been paid for. These are only for the
> sponsored attendees. The hostel with those rooms is not listed on the
> accommodation page, as I will allocated the beds for the sponsored KDE
> attendees there.
> 
> To sum up: if you get KDE e.V. sponsorship, I will book you a room in
> that hostel, and you don't need to worry about it.

Sjors

[KMess-devel] Desktop Summit

[Sjors G. <sj...@sj...>]

Hi all,

Cornelius Schumacher just sent an e-mail over the KDE e.V. list about reimbursement for travel to the Desktop Summit. There will be two deadlines when requests will be decided about. The first of those is April 1st (that's in about 10 days), and the second is June 1st.

Especially to Adam: If you intend to come this August, and like me you're not able to pay for it yourself (with or without the help of an employer), make sure you send them an e-mail about it and an indication of the costs before april! They don't have a lot of funds available, so if you apply late they may have to disappoint you and us all.

I'm sending an e-mail tomorrow or the day after, when I have a good indication of the costs. There's some questions regarding accomodation I'm not sure about, 'cause the accomodation page <https://desktopsummit.org/accomodation> says "you need to contact the travel committee which will do the booking for you", so I think I need to ask the board about that.

Policy: http://ev.kde.org/rules/reimbursement_policy.php

Sjors

[KMess-devel] Forum spam is unmanageable

[Adam G. <ada...@gm...>]

All,

This is out of control - 7 pages of spam posts (4 by unregistered
users, 3 *registered* spam accounts).

What are we going to do about this? The CAPTCHAs in place just aren't
good enough. At the very least I feel we should disable unregistered
posting - next, we need to weed out registered spam accounts.

Is phpBB even capable of protecting against such spam?

[KMess-devel] patch #35 question

[Francesco N. <fra...@gm...>]

Hi guys,
	I'm finishing off the patch for ticket #35. I've got all the settings saved, loaded ecc.
With how i done things you can also change you status together with your custom personal message. 
But I've got one question: "are you guys shure you want a combobox instead of the inlineedit?"

It seems a bit ugly to me. Should I proceed or have you got some suggestions?

Francesco

Re: [KMess-devel] Downloading MsnObjects in master (/hilight Diederik)

[Adam G. <ada...@gm...>]

On Wed, Feb 23, 2011 at 4:48 AM, Sjors Gielen <sj...@sj...> wrote:
> Hi all,
>
> I've been looking at the reason why custom emoticons are not shown yet. Now that the library correctly links custom emoticons to their messages instead of to the contacts that sent them, the behaviour of the library is correct. However, in the frontend, the RichTextParser still only looks at the contact. I've decided to leave the hack be in the frontend: it's a lot easier to fix it later than it is to fix it now. So, once the frontend receives a message with custom emoticons in it, it promptly gives the custom emoticon shortcuts and their MsnObjectData to the contact to hold again. This way, most of the frontend can still work like it did, but at least the library has the correct behaviour.
>

Sounds good to me. The library shouldn't be handling that side of
things - it can provide the mechanism to download MsnObject's, but it
shouldn't be any more aware than that.

> Then, I started looking at how the actual emoticon file is downloaded; let's refresh our minds. In stable, the MsnSwitchboardConnection emits a gotMsnObject() signal to the ChatMaster to tell it to download MsnObject data unless it already exists. The ChatMaster, after some checks, continues to start a MsnObjectTransferP2P application to get the object. Eventually, slotMsnObjectReceived is called, which eventually shows the object: it either sets it as the contact picture path, shows it as a wink, or adds it as the file for a custom emoticon and tells the chat window to 'refresh' its view.
>
> Most of this infrastructure is gone in the master version. On one end, MsnChat has the gotMsnObject/startMsnObjectDownload calls commented out, because nothing implements those at the moment. On the other end, showMsnObject is commented out because it references classes like KMessConfig, ContactExtension and Chat to actually change stuff, which are in frontend code.
>

Yes. This infrastructure doesn't belong in master, which I think you
suggest below. Those methods need to be completely removed, not just
commented out. That will prevent us from making the mistake of putting
that code into MsnChat.

MsnChat is for *chat sessions only* - ie, text message transfer.
P2P-related *anything* shouldn't go in there. This separation is fine,
because (to the best of my knowledge) P2P sessions don't occur over
chat switchboards - a new one will be started for transfer purposes.

> So we have a few things to implement.
>
> 1. First of all, some class should get the responsibility of 'bookkeeping' MsnObjects: checking if they exist and are valid, and starting their download if they aren't. I don't think this should be MsnChat (but it might be a worty option); MsnSession sounds like the right class to me.

I understand what you mean, but I disagree slightly. IMO, the
bookeeping of MsnObjects, their existence and validity, is an
application-specific problem.

The library needs to expose mechanisms for downloading and
transmitting MsnObject data - that should be exposed via the (still
incomplete) P2P API. Signals should be emitted from a P2P-specific
class stating "hey, someone has asked for a new MsnObject transfer!
They want whatever is associated with this object string here"; the
application can then look for that data and, if valid, send it over
the P2P class. If the data is invalid, just tell the P2P class to
reject the request.

Conversely, the higher-level app should be able to say: "please
attempt to retrieve this MsnObject from this particular endpoint and
store it here".

> 2. Second, there should be a class that actually does the transfer. This used to be MsnObjectTransferP2P, a P2PApplication, but even that base class doesn't exist in the library anymore. I expect something in contrib/msntransport will replace it, but that isn't used yet.

Yep! Actually, to help me understand P2P well enough (which I believe
I do now) I drafted a simple P2P API of my own. Basically, at the very
highest level (straddling the border between KMess and the library)
exist two classes: P2P::Endpoint and P2P::Application.

P2P::Application is exactly like P2PApplication from 2.0.x - it's the
base class for abstracting file transfers, MsnObject transfers, webcam
sessions, etc. Each P2P::Application runs over a P2P::Endpoint - the
logical "link" between "us" and the remote address (which could be any
one of a number of MPOP locations). Sitting underneath P2P::Endpoint
is the infrastructure for handing SLP sessions and sending that data
over a switchboard or DirectConnection link.

Gregg's API has similar things, except a large chunk of it is missing
(unimplemented).

> 3. Last, there should be a message back from the transfer class to showMessage or something in the library that the download is completed.
>

Yep - signals on the specific P2P::Application instance will/should handle this.

> Here, I've even assumed that we *want* the library to automatically download MsnObjects it doesn't know (and I've abstracted away from the problem that the library doesn't really have some place to store temporary cache files like MsnObjects yet).
>

IMO, the library shouldn't start automatically downloading anything.
Let the application worry if it wants MsnObjects - after all, the
application could be text based and unable to display images anyway.
We just need to provide the plumbing to make it easy to send or
receive data over P2P without too much hassle.

> Which class do you think should get responsibility of starting MsnObject downloads? Then at least we can make MsnChat link to that class, and we can put stubs there. And, (primarily to Diederik,) how is msntransport doing? Does it have a class to do P2P downloads? How much work will it be to port MsnObjectTransferP2P to, or write a similar class for msntransport?
>

In my mind an application would do this:

P2P::Endpoint *ep = P2P::Manager::instance()->openEndpoint( "fo...@ba..." );
// or possibly:
// P2P::Endpoint *ep = mpopEndpointInstance->p2pEndpoint();

P2P::MsnObjectTransfer *app = new P2P::MsnObjectTransfer( ep );

QFile localFile( "fooobject.png" );
localFile.open(...);
app->downloadMsnObject( msnObject, &localFile );

And connect to the MsnObjectTransfer signals for updates as appropriate.

Diederik might be able to comment more, but my understanding (from
"grep TODO" in contrib/msntransport) is that much of the
infrastructure to support P2P applications is missing from
contrib/msntransport. The MediaFeature class, msntransport's
equivalent of P2P::Application, doesn't even have a header file.

I also have a sneaking feeling msntransport is more complex than it
needs to be. I may be wrong of course.

> Once these parts are in place, it will probably be easy to let the application decide to download MsnObjects if it doesn't have them, instead of the library deciding on itself it needs to download a MsnObject the application might not even use.
>

Absolutely.

I really, *really* want to get P2P working in master. If that means
writing our own API, I'm all for it. I'm just loathe to start hacking
on Gregg's API because I have no idea what the status of it is. Hence
why I'm keen to write our own. We own it, we control it.

Who knows, we might be able to take what we learn and backport some to
2.0.x to improve stuff there.

-Adam.

[KMess-devel] Downloading MsnObjects in master (/hilight Diederik)

[Sjors G. <sj...@sj...>]

Hi all,

I've been looking at the reason why custom emoticons are not shown yet. Now that the library correctly links custom emoticons to their messages instead of to the contacts that sent them, the behaviour of the library is correct. However, in the frontend, the RichTextParser still only looks at the contact. I've decided to leave the hack be in the frontend: it's a lot easier to fix it later than it is to fix it now. So, once the frontend receives a message with custom emoticons in it, it promptly gives the custom emoticon shortcuts and their MsnObjectData to the contact to hold again. This way, most of the frontend can still work like it did, but at least the library has the correct behaviour.

Then, I started looking at how the actual emoticon file is downloaded; let's refresh our minds. In stable, the MsnSwitchboardConnection emits a gotMsnObject() signal to the ChatMaster to tell it to download MsnObject data unless it already exists. The ChatMaster, after some checks, continues to start a MsnObjectTransferP2P application to get the object. Eventually, slotMsnObjectReceived is called, which eventually shows the object: it either sets it as the contact picture path, shows it as a wink, or adds it as the file for a custom emoticon and tells the chat window to 'refresh' its view.

Most of this infrastructure is gone in the master version. On one end, MsnChat has the gotMsnObject/startMsnObjectDownload calls commented out, because nothing implements those at the moment. On the other end, showMsnObject is commented out because it references classes like KMessConfig, ContactExtension and Chat to actually change stuff, which are in frontend code.

So we have a few things to implement.

1. First of all, some class should get the responsibility of 'bookkeeping' MsnObjects: checking if they exist and are valid, and starting their download if they aren't. I don't think this should be MsnChat (but it might be a worty option); MsnSession sounds like the right class to me.
2. Second, there should be a class that actually does the transfer. This used to be MsnObjectTransferP2P, a P2PApplication, but even that base class doesn't exist in the library anymore. I expect something in contrib/msntransport will replace it, but that isn't used yet.
3. Last, there should be a message back from the transfer class to showMessage or something in the library that the download is completed.

Here, I've even assumed that we *want* the library to automatically download MsnObjects it doesn't know (and I've abstracted away from the problem that the library doesn't really have some place to store temporary cache files like MsnObjects yet).

Which class do you think should get responsibility of starting MsnObject downloads? Then at least we can make MsnChat link to that class, and we can put stubs there. And, (primarily to Diederik,) how is msntransport doing? Does it have a class to do P2P downloads? How much work will it be to port MsnObjectTransferP2P to, or write a similar class for msntransport?

Once these parts are in place, it will probably be easy to let the application decide to download MsnObjects if it doesn't have them, instead of the library deciding on itself it needs to download a MsnObject the application might not even use.

Sjors

Re: [KMess-devel] We need a 2.0.6.1

[Adam G. <ada...@gm...>]

Normally, no. I assumed, when fixing the previous problem, that the
lang_preference setting would always be set to *some* valid language
code (that would be based on Hotmail settings - it is a Hotmail
profile message after all). At the time of 2.0.6 it was valid on my
end, it was valid on everybody elses end...until today. Clearly, with
the changes MS is making this assumption is blatently wrong :(

Oh well. Live and learn I guess.

On Wed, Feb 16, 2011 at 7:10 PM, Sjors Gielen <sjo...@gm...> wrote:
> Awesome. Good job on the release preparations!
>
> Is it normal that a single setting change like the language causes kmess to
> be unable to login?
> Op 16 feb. 2011 09:07 schreef "Adam Goossens" <ada...@gm...> het
> volgende:
>> All,
>>
>> Long story short - lang_preference in the initial profile is set to 0
>> in some cases, which causes the dreaded disconnect bug again.
>>
>> We need to roll out 2.0.6.1 to fix this new issue (which has been
>> fixed - 805b996). Since we've got no other changes in 2.0.x since
>> 2.0.6 (apart from a couple of updated translations), I propose tagging
>> 2.0.6.1 at 805b996 and releasing it ASAP (like, by this weekend). To
>> do this, I've created a local 2.0.6.1 tag and release tarball with
>> everything ready to go (CMakeLists, Doxyfile, NEWS, ChangeLog, etc).
>>
>> If everyone is OK with it I'll push the new tag (and update the
>> website too); if someone can give me project access to SourceForge
>> (username: adamgoossens) I'll upload the tarball as well.
>>
>> I've also drafted the release announcement for email. See below.
>>
>> Comments? I want to get on this ASAP so we don't look as hopeless as
>> we did last time :)
>>
>> -Adam.
>>
>> --------------------------
>>
>> February 17 2011 -- The KMess team announces today the availability of the
>> latest release of KMess: KMess 2.0.6.1, the newest version of the Live
>> Messenger (MSN) client, powered by the KDE platform. This release of KMess
>> addresses a critical issue discovered after 2.0.6 which prevented
>> successful login.
>>
>> Here is a quick highlight of the changes in 2.0.6:
>>
>> * Added a fading effect when logging in
>> * Fix crash when taking any action in the Contact Added User dialog
>> * Fixed retrieval of display pictures from MSN storage
>> * Fix bugs which prevented KMess from logging in, stating,
>> "connection has been lost"
>> * Updated French translation
>> * Updated Turkish translation
>> * Updated Catalan translation
>> * Updated German translation
>> * Updated Japanese translation
>> * Updated Spanish translation
>> * Various other smaller updates and fixes...
>>
>> The screenshots page [0] provides a detailed overview of what KMess looks
>> like.
>>
>> You can find the source code at the downloads page [1], and binary
>> packages for various distributions will start flooding in soon.
>>
>> Thanks to 28 volunteer translators, KMess is available in 19
>> languages. Other people, without whom this release would not be what
>> it is today, as well as the current members of the KMess team, are
>> listed on our People page [2].
>>
>> Any remarks, notes, threats, treats, as well as bug reports can be
>> posted at our forums [3]. You can also send us messages using the
>> LikeBack client built into KMess, accessible via Help -> Send a
>> Comment to the Developers. We wish you a lot of fun and chatting with
>> KMess!
>>
>> --
>> The KMess team
>>
>> [0] http://kmess.org/screenshots/
>> [1] http://kmess.org/download/
>> [2] http://kmess.org/people/
>> [3] http://kmess.org/board/
>>
>>
> ------------------------------------------------------------------------------
>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
>> Pinpoint memory and threading errors before they happen.
>> Find and fix more than 250 security defects in the development cycle.
>> Locate bottlenecks in serial and parallel code that limit performance.
>> http://p.sf.net/sfu/intel-dev2devfeb
>> _______________________________________________
>> KMess-devel mailing list
>> KMe...@li...
>> https://lists.sourceforge.net/lists/listinfo/kmess-devel
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> KMess-devel mailing list
> KMe...@li...
> https://lists.sourceforge.net/lists/listinfo/kmess-devel
>

Re: [KMess-devel] We need a 2.0.6.1

[Sjors G. <sjo...@gm...>]

Awesome. Good job on the release preparations!

Is it normal that a single setting change like the language causes kmess to
be unable to login?
Op 16 feb. 2011 09:07 schreef "Adam Goossens" <ada...@gm...> het
volgende:
> All,
>
> Long story short - lang_preference in the initial profile is set to 0
> in some cases, which causes the dreaded disconnect bug again.
>
> We need to roll out 2.0.6.1 to fix this new issue (which has been
> fixed - 805b996). Since we've got no other changes in 2.0.x since
> 2.0.6 (apart from a couple of updated translations), I propose tagging
> 2.0.6.1 at 805b996 and releasing it ASAP (like, by this weekend). To
> do this, I've created a local 2.0.6.1 tag and release tarball with
> everything ready to go (CMakeLists, Doxyfile, NEWS, ChangeLog, etc).
>
> If everyone is OK with it I'll push the new tag (and update the
> website too); if someone can give me project access to SourceForge
> (username: adamgoossens) I'll upload the tarball as well.
>
> I've also drafted the release announcement for email. See below.
>
> Comments? I want to get on this ASAP so we don't look as hopeless as
> we did last time :)
>
> -Adam.
>
> --------------------------
>
> February 17 2011 -- The KMess team announces today the availability of the
> latest release of KMess: KMess 2.0.6.1, the newest version of the Live
> Messenger (MSN) client, powered by the KDE platform. This release of KMess
> addresses a critical issue discovered after 2.0.6 which prevented
> successful login.
>
> Here is a quick highlight of the changes in 2.0.6:
>
> * Added a fading effect when logging in
> * Fix crash when taking any action in the Contact Added User dialog
> * Fixed retrieval of display pictures from MSN storage
> * Fix bugs which prevented KMess from logging in, stating,
> "connection has been lost"
> * Updated French translation
> * Updated Turkish translation
> * Updated Catalan translation
> * Updated German translation
> * Updated Japanese translation
> * Updated Spanish translation
> * Various other smaller updates and fixes...
>
> The screenshots page [0] provides a detailed overview of what KMess looks
> like.
>
> You can find the source code at the downloads page [1], and binary
> packages for various distributions will start flooding in soon.
>
> Thanks to 28 volunteer translators, KMess is available in 19
> languages. Other people, without whom this release would not be what
> it is today, as well as the current members of the KMess team, are
> listed on our People page [2].
>
> Any remarks, notes, threats, treats, as well as bug reports can be
> posted at our forums [3]. You can also send us messages using the
> LikeBack client built into KMess, accessible via Help -> Send a
> Comment to the Developers. We wish you a lot of fun and chatting with
> KMess!
>
> --
> The KMess team
>
> [0] http://kmess.org/screenshots/
> [1] http://kmess.org/download/
> [2] http://kmess.org/people/
> [3] http://kmess.org/board/
>
>
------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> KMess-devel mailing list
> KMe...@li...
> https://lists.sourceforge.net/lists/listinfo/kmess-devel

[KMess-devel] We need a 2.0.6.1

[Adam G. <ada...@gm...>]

All,

Long story short - lang_preference in the initial profile is set to 0
in some cases, which causes the dreaded disconnect bug again.

We need to roll out 2.0.6.1 to fix this new issue (which has been
fixed - 805b996). Since we've got no other changes in 2.0.x since
2.0.6 (apart from a couple of updated translations), I propose tagging
2.0.6.1 at 805b996 and releasing it ASAP (like, by this weekend). To
do this, I've created a local 2.0.6.1 tag and release tarball with
everything ready to go (CMakeLists, Doxyfile, NEWS, ChangeLog, etc).

If everyone is OK with it I'll push the new tag (and update the
website too); if someone can give me project access to SourceForge
(username: adamgoossens) I'll upload the tarball as well.

I've also drafted the release announcement for email. See below.

Comments? I want to get on this ASAP so we don't look as hopeless as
we did last time :)

-Adam.

--------------------------

February 17 2011 -- The KMess team announces today the availability of the
latest release of KMess: KMess 2.0.6.1, the newest version of the Live
Messenger (MSN) client, powered by the KDE platform. This release of KMess
addresses a critical issue discovered after 2.0.6 which prevented
successful login.

Here is a quick highlight of the changes in 2.0.6:

 * Added a fading effect when logging in
 * Fix crash when taking any action in the Contact Added User dialog
 * Fixed retrieval of display pictures from MSN storage
 * Fix bugs which prevented KMess from logging in, stating,
"connection has been lost"
 * Updated French translation
 * Updated Turkish translation
 * Updated Catalan translation
 * Updated German translation
 * Updated Japanese translation
 * Updated Spanish translation
 * Various other smaller updates and fixes...

The screenshots page [0] provides a detailed overview of what KMess looks
like.

You can find the source code at the downloads page [1], and binary
packages for various distributions will start flooding in soon.

Thanks to 28 volunteer translators, KMess is available in 19
languages. Other people, without whom this release would not be what
it is today, as well as the current members of the KMess team, are
listed on our People page [2].

Any remarks, notes, threats, treats, as well as bug reports can be
posted at our forums [3]. You can also send us messages using the
LikeBack client built into KMess, accessible via Help -> Send a
Comment to the Developers. We wish you a lot of fun and chatting with
KMess!

--
The KMess team

[0] http://kmess.org/screenshots/
[1] http://kmess.org/download/
[2] http://kmess.org/people/
[3] http://kmess.org/board/

Re: [KMess-devel] Suggestions for improvement on the Gitorious merge request

[Sjors G. <da...@da...>]

Hi Daniel,

I've looked through your improvements and they're looking good! A few things drew my attention while looking through the code:

1. The TODO in the Plugin constructor:
#warning TODO: implement this function when a user adds plugins.
2. The TODO in PluginsPage::loadSettings(Account*) and ::saveSettings(Account*):
#warning TODO: implement this function.
3. The QScriptEngine inclusion (and forward declaration) in pluginsmaster.{cpp,h}.
4. Are you sure you didn't change pluginsdelegate (by Joris Guisson)? If so, disregard this one. If not: update the file, just like you updated PluginsModel :)

I applied the patch locally (not a 100% clean apply, some whitespace you fixed was already fixed, but that's no problem). After that, I had a compilation error in PluginsPage and PluginsMaster. Both of the files included ui_plugininfo.h which is generated from plugininfo.ui which doesn't exist anymore. Maybe you still have that .ui file on your system, creating the ui_plugininfo.h so you don't get a build error? Anyway: if I remove the inclusion and comment out the "private Ui::PluginInfo" in pluginsmaster.h, the code compiles wonderfully.

Except for one warning:
> master/src/plugins/plugin.h: In constructor ‘Plugin::Plugin(const QString&, QObject*)’:
> master/src/plugins/plugin.h:70: warning: ‘Plugin::file_’ will be initialized after
> master/src/plugins/plugin.h:66: warning:   ‘Kross::Action* Plugin::action_’
> master/src/plugins/plugin.cpp:46: warning:   when initialized here

I'll fix that one, but remember to fix your warnings before you send in a patch ;-)

KMess works beautifully with the patch applied, as does the plugin setting screen (nice that you've made it per-account!). However, there's a user-interface bug. I don't have python-kross installed, so probably that's why my plugins won't activate: if I tick a checkbox, it instantly un-ticks without any warning, GUI or terminal. You should definitely display a warning here. (If you want, some information that doesn't look like it should be in GUI, can be outputted via QDebug.)

Anyway, python-kross is not in my repositories, so it'll take me some time to compile and install it. After that, I will test the plugins but I expected you already tested them extensively. We will have to add CMake checker scripts to the CMakeLists.txt to warn people in advance that they have software missing to get everything out of KMess.

With regard to your question earlier;

Op 6 jan 2011, om 12:03 heeft Daniel E. Moctezuma het volgende geschreven:

> 18. It's normal to say "foo *bar" instead of "foo* bar". I'll explain why if you want.
> As far as I know the result would be the same using one or another, I suppose you say it because of a coding standard, maybe? If not, I would appreciate if you can explain please.

Yes, this is a coding standard / style thing. The reason it's the normal convention is because of this case:
> int* a, b;
In this case, 'a' is an int-pointer, and b is simply an int. The coding style makes this a little more clear:
> int *a, b;
And if you want two pointers, you consistently write:
> int *a, *b;

Anyway: I've pushed your patch, I'm fixing most of the things above quickly (as you won't learn anything from fixing them yourself anymore). There's a few things I would like to get from you sometime soon:
- an implementation of Plugin::Plugin and PluginsPage::{load,save}Settings,
- a patch that makes KMess display a message box if enabling a plugin didn't work, including as much reason as you can show,
- if you know how to do it, or are willing to find out: a bit of CMake code to check whether python-kross and/or ruby-kross are available (and/or working, if possible).

Either way: huge thanks for this patch, and for working with me all this time :) you can now print <http://www.gitorious.org/kmess/kmess/commit/1355ba446f8406094dbd89a414b12a1633fc85a3>, frame it, and hang it  somewhere where you'll see it and be proud a few times every day ;-)

Thanks again,
Sjors

Re: [KMess-devel] Suggestions for improvement on the Gitorious merge request

[Sjors G. <sj...@km...>]

Op 28 dec 2010, om 23:45 heeft Sjors Gielen het volgende geschreven:

>> Also I'm not sure if this is a problem with my distro or so, but it seems that all the plugins are enabled by default when you get to the enable/disable window (they are configured to be disabled by default, though), I'll appreciate if somebody can confirm this.
> 
> I'll read through the patch tomorrow as soon as I can - if it looks OK I'll apply it locally and check if I have that behaviour too. Will let you know.

Hi Daniel,

And read through the patch I did. There's a few things I want to say, first, but most of them are merely warnings: you can fix most of them in a matter of seconds. If you could spend some time on this (it's an important part of delivering a good patch) I'll merge it right after!

1. I noticed in your `diff` commandline that you --exclude=lib. Are you sure you didn't change anything in the library?
2. My compliments with using the .desktop file! Using a standard for that is really nice.
3. You have this change in your CMakeLists.txt:
-TARGET_LINK_LIBRARIES( ${PROJECT_NAME} ${kmess_LIBS} )
+TARGET_LINK_LIBRARIES( ${PROJECT_NAME} ${kmess_LIBS} ${KDE4_KROSSCORE_LIBS} ${KDE4_KROSSUI_LIBS} ${X11_LIBRARIES} )
You should add the Kross libraries to ${kmess_LIBS} like the rest of the libraries. Also, adding ${X11_LIBRARIES} here is really not right: if KrossUI needs it it'll be in KROSSUI_LIBS and you can't assume KMess will eventually be using X11. For example, Mac builds don't use X11 at all.
4. Great job on the IRC-like commands plugin! Removing that from the core code and adding it again as a plugin is a huge plus for your patch.
5. What is ChatWindow::text_ for? It's only assigned and emited once, but not used anywhere.
6. Adding KMESSDEBUG definitions to kmessdebug.h that aren't relevant to the plugin system or your patch, is added noise, and you should probably send them in as a seperate patch.
7. TODO in your code on line 54 of kmessaccount.h. You should look at that, or remove it.
8. What's the comment for on line 293 of kmesschat.cpp?
9. Why is messageRecieved (which is wrongly spelled) commented out on line 75 of kmesschat.h?
10. Why is clearMessageEditor() commented out on line 82 of kmesscontactlist.h?
11. KMessInfo line 75: getKmessName() is not really a slot: it's const so it can't 'do' anything, there's no reason to use it as a true slot. This is true for Session too, where most of your getters are slots for no reason. I personally think it's "clean" to make them pure functions, but it doesn't matter in functionality.
12. Line 207 of plugin.cpp: why "interpreter", why not .interpreternameForFile() ? Why detect by filename later? This will break if Kross support changes over time, which it undoubtedly will. I.e. if Perl is added, KMess can never understand ".pl", but Kross will...
13. Why are only KPluginInfo and bool in that struct MetaInfo? It's never used by itself, so it could very well be directly private to the object too. (It's OK, just interested)
14. The PluginsMaster constructor contains an old TODO and commented out Account code, what about that? (The destructor contains stuff too)
15. You left QScriptValue PluginsMaster::evaluateScript() in, but that won't work anymore, will it? (Any other stuff left in that should be removed? QScriptEngine *engine_?)
16. getPluginList() contains old commented out code that can be removed. You might want to make the return value of that method a reference (const QList<>&) so it doesn't need to be copied. Then, getPluginsCount() may be removed too.
17. What's this for? line 443 of pluginsmaster.cpp
+  enableRunPlugin( selected.count() > 0 && num_not_running > 0 );
+  enableStopPlugin( selected.count() > 0 && num_running > 0 );
18. It's normal to say "foo *bar" instead of "foo* bar". I'll explain why if you want.
19. The windowIcon of plugininfo.ui is wrong:
+    <normaloff>../../../../../usr/share/icons/oxygen/16x16/actions/help-about.png</normaloff
>../../../../../usr/share/icons/oxygen/16x16/actions/help-about.png</iconset>
20. Who's Joris Guisson? pluginsdelegate.h line 3:
+ * (C) Copyright 2009 Joris Guisson <jor...@gm...>              *
And Ivan Vasic?
+ * (C) Copyright 2008 Ivan Vasic <iv...@gm...>                        *
Note that if you used their code, you have to make a 1:1 copy of their copyright notice, even if that means there are three copyright notices. You can't only copy their names and the year, iirc.
21. Some code in PluginsModel is the same as the code in PluginsMaster. Is that really needed? You can use PluginsMaster::addPluginFromDesktopFile() too, right?
22. Why don't PluginsPage::loadSettings() and PluginsPage::saveSettings() do anything? (Q_UNUSED() there only hides that it doesn't do anything, you should leave that out if it's a todo or add a #warning!)

Let me know what you think about most of these! Hopefully we can merge the patch ASAP :-)

Sjors

Re: [KMess-devel] Suggestions for improvement on the Gitorious merge request

[Sjors G. <sj...@km...>]

Op 13 dec 2010, om 01:56 heeft Daniel E. Moctezuma het volgende geschreven:

> Hi Sjors (and all KMess devs),

Hi Daniel,

Sorry for responding to you this late :( I have free time from school now, so hopefully we can get that patch merged finally ;-)

> Long time, no see. I've been more in real life (school) than in coding, but finally got time to clean my previous patch.
> Here I'm sending it for you to check it and get some feedback if possible.
> I'm not including 1 of 3 plugins (predefined sentences) as is the plugin that makes use of the icons, and as you mentioned:
> <normaloff>../../../../../../usr/share/icons/oxygen/16x16/categories/preferences-system.png</normaloff>../../../../../../usr/share/icons/oxygen/16x16/categories/preferences-system.png</iconset>
> 
> the path should be "preferences-system" only. I'm working on that and decided to include it later when it's fixed so we can focus on the Plugin System first.

Good idea! We'll see it coming.

> In chatmaster.h there are these functions that were originaly private:
> // Get all chats in all chat windows
> QList<Chat*>       getAllChats();
> // Return the window for the given chat
> ChatWindow        *getChatWindow( Chat *chat );
> // Return the chat window where we're having an conversation with the given contact.
> Chat              *getContactsChat( const QString &handle, bool privateChat );
> // Check whether the contact is in any of the existing chat windows.
> bool               isContactInChat( const QString &handle );
> 
> 
> I made them public as they are the only functions needed in kmesschat.cpp that weren't accesible, but what should  be better here (for the plugsys purpose)? make KMessChat a friend class of ChatMaster or leave it as I did making public only the necessary functions?

I think it's fine to make these functions public. They don't return any real private information, I think. Friend classes are usually something to avoid in situations like this, or you end up friend classing every class that needs a tiny bit of private information, that could very well be public, too.

> Also I'm not sure if this is a problem with my distro or so, but it seems that all the plugins are enabled by default when you get to the enable/disable window (they are configured to be disabled by default, though), I'll appreciate if somebody can confirm this.

I'll read through the patch tomorrow as soon as I can - if it looks OK I'll apply it locally and check if I have that behaviour too. Will let you know.

> In addition, KMess should create a 'pluginsconfig' folder on the account folder at install: .kde/share/apps/kmess-dev/em...@em.../pluginsconfig/plugin-folder-here
> How can this be done? Somewhere in CMakeLists.txt?

This is user-specific data (since you're talking about a .kde directory), and during installation, you never install user-specific data, only system-specific data. Remember that if I compile and system-wide-install kmess as myself, then another user on the system may want to use it too. The normal way to do this, is to create the directory during startup / initialisation, or whenever it is actually needed. You can use our existing configuration classes, or KDE's classes, to get to know what the KDE directory is (it's not always ~/.kde), and you can use QDir (iirc) to create the directory so you can create files in it.

As said, I'll look at the patch tomorrow. Sorry again for responding this late, it's been a busy time for me too :(

Thanks again,
Sjors

Re: [KMess-devel] By default building against bundled version of libfoo, instead of system-installed

[Sjors G. <da...@da...>]

Op 29 nov 2010, om 20:46 heeft Valerio Pilo het volgende geschreven:

> I'm 100% in favor of removing the preliminary check for system-installed 
> versions (option 1 -- snippet [2])

I didn't do this yet, and I don't think I'm going to do it soon. There is a ticket open with major priority for kmess-3.0 (<https://trac.kmess.org/ticket/529>), so the work will stay in there :-)

Sjors

Re: [KMess-devel] By default building against bundled version of libfoo, instead of system-installed

[Valerio P. <va...@km...>]

In data lunedì 29 novembre 2010 14:02:22, Sjors Gielen ha scritto:
> Hi all,
> 
> A few months ago, we talked about building against bundled versions instead
> of system-installed versions by default. After most of us agreed it was
> the best idea, we included a patch to always build against bundled
> libkmess-msn, unless some switch was given to build against a
> system-installed one, I remember.
> 
> A few days ago, this was posted in the KMess channel:
> http://pastebin.com/ws4sdKpm (a copy is included below[0]) - this was
> caused by kmess by default building against a system-installed libisf
> instead of a bundled one. Libisf is still always bundled with KMess,
> seeing cmake/check-submodules.pl [1]. However, it is only used if there
> was no system-installed version[2]. The paste shows that this is unwise:
> the installed version might be lagging behind if we're building a new
> version of KMess. (And my previous argument: two subsequent builds with
> different versions of KMess and libisf, would have unexpected effects.)
> 
> There are two options to solve this:
> 
> 1. by default, use bundled libisf just like with libkmess,
> 2. don't bundle libisf anymore.
> 
> I'm still for option 1, then later option 2 once libisf is released as its
> own library. I'll also patch in the change sometime soon if there are no
> objections. What option do you prefer? Thoughts?
> 
> Sjors
> 
> -- [0] --
> Scanning dependencies of target kmess
> [ 20%] Building CXX object src/CMakeFiles/kmess.dir/kmess_automoc.o
> [ 20%] Building CXX object
> src/CMakeFiles/kmess.dir/chat/chathistorymanager.o [ 21%] Building CXX
> object src/CMakeFiles/kmess.dir/chat/chathistorywriter.o [ 22%] Building
> CXX object src/CMakeFiles/kmess.dir/chat/chatmaster.o
> /home/merike/Allalaadimised/kmess-stable/src/chat/chatmaster.cpp: In
> member function 'void ChatMaster::slotGotInkMessage(const QString&, const
> QString&, InkFormat)':
> /home/merike/Allalaadimised/kmess-stable/src/chat/chatmaster.cpp:1361:
> error: 'writerPng' is not a member of 'Isf::Stream' make[2]: ***
> [src/CMakeFiles/kmess.dir/chat/chatmaster.o] Error 1
> make[1]: *** [src/CMakeFiles/kmess.dir/all] Error 2
> make: *** [all] Error 2
> 
> -- [1] --
> EXECUTE_PROCESS( COMMAND
> ${CMAKE_CURRENT_SOURCE_DIR}/cmake/check-submodules.pl OUTPUT_VARIABLE
> GIT_SUBMODULES_OK ) (and in that file)
> foreach(split /\n/, `git submodule status`)
> (and as output of that command)
>  ca65ccbf94cb92aa9852a2e3894503d33bf19ebd contrib/isf-qt (ca65ccb)
> 
> -- [2] --
> # If the ISF library is not installed on the system.
> # use the bundled version.
> IF( NOT ISFQT_FOUND )
>   SET( ISFQT_INCLUDE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/contrib/isf-qt/include
> )

I'm 100% in favor of removing the preliminary check for system-installed 
versions (option 1 -- snippet [2])

Valerio

-- 
Valerio Pilo
KMess developer team
------
KMess
- the Live Messenger alternative for KDE -
web: www.kmess.org - irc: #kmess at Freenode

[KMess-devel] By default building against bundled version of libfoo, instead of system-installed

[Sjors G. <sj...@km...>]

Hi all,

A few months ago, we talked about building against bundled versions instead of system-installed versions by default. After most of us agreed it was the best idea, we included a patch to always build against bundled libkmess-msn, unless some switch was given to build against a system-installed one, I remember.

A few days ago, this was posted in the KMess channel: http://pastebin.com/ws4sdKpm (a copy is included below[0]) - this was caused by kmess by default building against a system-installed libisf instead of a bundled one. Libisf is still always bundled with KMess, seeing cmake/check-submodules.pl [1]. However, it is only used if there was no system-installed version[2]. The paste shows that this is unwise: the installed version might be lagging behind if we're building a new version of KMess. (And my previous argument: two subsequent builds with different versions of KMess and libisf, would have unexpected effects.)

There are two options to solve this:

1. by default, use bundled libisf just like with libkmess,
2. don't bundle libisf anymore.

I'm still for option 1, then later option 2 once libisf is released as its own library. I'll also patch in the change sometime soon if there are no objections. What option do you prefer? Thoughts?

Sjors

-- [0] --
Scanning dependencies of target kmess                                                                                                          
[ 20%] Building CXX object src/CMakeFiles/kmess.dir/kmess_automoc.o                                                                            
[ 20%] Building CXX object src/CMakeFiles/kmess.dir/chat/chathistorymanager.o                                                                  
[ 21%] Building CXX object src/CMakeFiles/kmess.dir/chat/chathistorywriter.o                                                                   
[ 22%] Building CXX object src/CMakeFiles/kmess.dir/chat/chatmaster.o                                                                          
/home/merike/Allalaadimised/kmess-stable/src/chat/chatmaster.cpp: In member function 'void ChatMaster::slotGotInkMessage(const QString&, const QString&, InkFormat)':
/home/merike/Allalaadimised/kmess-stable/src/chat/chatmaster.cpp:1361: error: 'writerPng' is not a member of 'Isf::Stream'
make[2]: *** [src/CMakeFiles/kmess.dir/chat/chatmaster.o] Error 1
make[1]: *** [src/CMakeFiles/kmess.dir/all] Error 2
make: *** [all] Error 2

-- [1] --
EXECUTE_PROCESS( COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/cmake/check-submodules.pl OUTPUT_VARIABLE GIT_SUBMODULES_OK )
(and in that file)
foreach(split /\n/, `git submodule status`)
(and as output of that command)
 ca65ccbf94cb92aa9852a2e3894503d33bf19ebd contrib/isf-qt (ca65ccb)

-- [2] --
# If the ISF library is not installed on the system.
# use the bundled version.
IF( NOT ISFQT_FOUND )
  SET( ISFQT_INCLUDE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/contrib/isf-qt/include )

Re: [KMess-devel] Telepathy implementation in kmess

[Sjors G. <da...@da...>]

Op 24 nov 2010, om 22:51 heeft Sjors Gielen het volgende geschreven:

> See my blog post for a recent update: http://dazjorz.com/blog/?p=79

Sorry, wrong link: http://dazjorz.com/blog/?p=51

Sjors

Re: [KMess-devel] Telepathy implementation in kmess

[Sjors G. <sj...@km...>]

Op 20 sep 2010, om 18:42 heeft Francesco Nwokeka het volgende geschreven:

> Hi guys!
> Wanted to ask you lot a question about the implemtation of the msn protocol in KMESS. 
> I keep an eye on a few kde projects and I came to read about telepathy. Telepathy is 
> used by Kopete to communicate over most instant messaging protocols. So I ask : "why 
> not use telepathy inside Kmess?" it would solve a lot of problems and make kmess 
> portable also for other protocols in case one day you guys would like to "expand" 
> kmess's horizons. 
> Here's a link to telepathy so you can have a read.

Hi Francesco,

So a few days after your e-mail, I remembered nobody responded to it yet. One of our developers said "I'll respond to him", but as far as I can see this never happened. I didn't feel like responding, too, but I will now :P

Anyway, we know about Telepathy, we've heard a lot about it at aKademy in Finland, and we've discussed it a lot. Earliest answer is: not gonna happen too soon. We're still splitting up our library, and until work on that is done (which will take *at least* months) we probably won't implement any Telepathy stuff. After that, however, we might start discussing it again, see how it's doing in the rest of the world, and start implementing some features of it.

See my blog post for a recent update: http://dazjorz.com/blog/?p=79

Sorry for replying this late, hopefully you were still interested in the answer ;-)

Thanks,
Sjors

Re: [KMess-devel] KMess LikeBack - Answer to your feedback, #6568

[Sjors G. <sj...@km...>]

(To list: This is a bug report that came in via Likeback, about not being able to add a new emoticon being sent to you by another contact.)

Op 22 nov 2010, om 22:30 heeft Victor Dugas het volgende geschreven:

> Interesting, It works with one contact but not another...

Are you sure you don't have the emoticon yet? If you have chat logging enabled, you can check the logs to see if the emoticons are clickable there (that's, in this case, a bug, but it's useful here). The image should be clickable if you don't have the emoticon yet.

There is only one corner case that in practice never hits, when the checksums of the images are the same. So in practice: if you are sure you don't have the emoticon yet, there's a bug somewhere. :)

Sjors