Re: [RFC] statistics performance

[Matt Rogers]

On Mon, Oct 11, 2010 at 2:48 PM, Luca Tettamanti  wrote:
> Hello,
> while trying out the statistics plugin (with kopete 4.5.1) I've
> noticed a big delay (about 40-50 seconds) when quitting the
> application, associated with a disk storm.
> When kopete is closing it changes the online status of each contact to
> "Unknown"; this change triggers an INSERT for each contact into the
> statistics DB which - with the default auto-commit behaviour - result
> in a fsync of the DB. The other bottleneck is the tear down of the
> statisticsContactMap which triggers multiple updates per each contact.
> I tested a few modifications that greatly improved the performance:
> * expose transaction control from StatisticsDB
> * batch the UPDATEs in the destructor of the plugin into a single transaction
> * override plugin's aboutToUnload: disconnect from status update and
> manually set to "Unknown" the status of all the contacts in a single
> batch.
>
> I already have quick&dirty patch, tested with positive result. Do you
> think that the changes are acceptable?
>
> Luca

We don't know unless you post a patch to reviewboard.
--
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Feature development/polishing using git

[Matt Rogers]

On Mon, Aug 30, 2010 at 11:16 AM, Bernhard Friedreich
 wrote:
>  On 30.08.2010 17:59, Matt Rogers wrote:
>> On Mon, Aug 30, 2010 at 10:47 AM, Bernhard Friedreich
>>  wrote:
>>>  Hi!
>>>
>>> I'm new to this list, kopete as well as kde/kopete development. I've
>>> been a KDE user for long and have been following many mailing lists.
>>> Until recently I've used kmess to satisfy my needs but recently I wanted
>>> to give kopete another try again because I wanted to unite my accounts
>>> in one common interface.
>>>
>>> There are some features I'm desperately missing and some minor annoyances.
>>>
>>> To mention some of them:
>>> 1-) polish the participants dock (show avatar, online status, ...)
>> Please be sure to post before and after screenshots of any of the UI
>> pieces you work on. It can be quite hard to visualize otherwise
> Of course I'll do that =)
>>> Is using this tutorial
>>> http://techbase.kde.org/Development/Tutorials/Git/git-svn still the
>>> preferred way?
>>>
>> Yes, the git-svn tutorial is still the best way
> Good to know thanks =) have already cloned the repo and currently
> setting up my dev environment.
> I'm using -DCMAKE_INSTALL_PREFIX=/some/custom/path
> this works for make install - but what is the correct way now to launch
> the devel kopete and not the system kopete?
>
> sorry I'm pretty knew to the cmake install problematics...
>

>From the command line:

export PATH=/some/custom/path/bin:$PATH
export KDEDIRS=/some/custom/path:$KDEDIRS
kbuildsycoca4 --noincremental
kopete

--
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Feature development/polishing using git

[Matt Rogers]

On Mon, Aug 30, 2010 at 10:47 AM, Bernhard Friedreich
 wrote:
>  Hi!
>
> I'm new to this list, kopete as well as kde/kopete development. I've
> been a KDE user for long and have been following many mailing lists.
> Until recently I've used kmess to satisfy my needs but recently I wanted
> to give kopete another try again because I wanted to unite my accounts
> in one common interface.
>
> There are some features I'm desperately missing and some minor annoyances.
>
> To mention some of them:
> 1-) polish the participants dock (show avatar, online status, ...)

Please be sure to post before and after screenshots of any of the UI
pieces you work on. It can be quite hard to visualize otherwise

> 2) don't grey out contacts' avatar which are online but away/busy/... as
> a config option (as many people seem to like the greyed out avatars)
> 3) 0-click reachable status line edit
> 4) support windows live plus color codes
> 5) not all skype emoticons supported? or does this depend on the theme?
> 6) skype avatar/status message support? (afaik not possible because of
> skype limitations)
> 7) ...
>
> Overall I want kopete to be customizable enough to make it look a bit
> more like kmess.
>
> That's the plan... I hope I'll be able to start, but I would prefer
> developing using git.
> Is using this tutorial
> http://techbase.kde.org/Development/Tutorials/Git/git-svn still the
> preferred way?
>

Yes, the git-svn tutorial is still the best way

Thanks
--
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Patch review: clearPluginData() problem

[Matt Rogers]

On Mon, Aug 23, 2010 at 12:20 PM, Warren Dumortier  wrote:
> In my opinion the best solution is to directly remove contacts from the
> contact list where the protocol plugin isn't loaded or found.
> This can't cause any bugs i suppose as the plugin will re-add them the next
> time.
>
> In the meantime i will write the patch that does this.
> When a developer lets me know which solution is the best one, i'd commit my
> patch.
> I also would like to begin hacking on Kopete, maybe this patch will be a
> good opportunity to start! ;)
>
> Kind regards, Warren.
>

What happens when you remove the contact data and that contact was in
a larger metacontact?
--
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [PATCH] Message states in skype

[Matt Rogers]

On Wed, Jun 2, 2010 at 2:08 AM, Pali Rohár  wrote:
> Hello,
>
> some months is on reviewboard ( http://reviewboard.kde.org/r/1815/ )
> uncommitted patch for using message states in skype protocol. If all is ok,
> can somebody commit this patch to svn. It will be good if this patch is part
> of 4.5 release.
>
>

You have an account. You commit it. I don't understand why you're
asking for permission.
--
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Review Request: make Kopete respect global KIO proxy settings when connecting to ICQ

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4163/#review5879
---

Ship it!


The code looks fine. Please commit. 

I'm a bit confused on how this works though. You're using an http proxy, but 
you've just set it up to listen on the normal SOCKS proxy port, and it still 
works? What happens if the proxy in use doesn't support that?

- Matt


On 2010-05-27 03:29:09, Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/4163/
> ---
> 
> (Updated 2010-05-27 03:29:09)
> 
> 
> Review request for Kopete.
> 
> 
> Summary
> ---
> 
> Makes Kopete respect global KIO proxy settings when connecting to ICQ.
> 
> It uses 'https proxy' field of Systemsettings -> Network -> Proxy dialog.
> 
> 
> This addresses bug 186872.
> https://bugs.kde.org/show_bug.cgi?id=186872
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdenetwork/kopete/protocols/oscar/oscaraccount.cpp 1130658 
> 
> Diff: http://reviewboard.kde.org/r/4163/diff
> 
> 
> Testing
> ---
> 
> Kopete connected to my ICQ account via my home configured proxy (had to allow 
> 5190 port for CONNECT command in squid.conf), and refused to connect if I 
> specified wrong proxy settings.
> 
> Kopete also connects to ICQ when I disable use of proxy.
> 
> 
> Thanks,
> 
> Nick
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: When does Kopete move to gitorious.org ?

[Matt Rogers]

On Tue, May 18, 2010 at 3:58 AM, Pali Rohár  wrote:
> On Ut 18. Máj 2010 10:54:03 Frank Schaefer wrote:
>> Hi,
>>
>> I noticed that more and more KDE-projects are moving to gitorious.org
>> (e.g. Amarok, KDevelop, Kate, Konversion).
>> When does Kopete move to gitorious.org ?
>> Wouldn't the beginning of the KDE 4.6 development cycle (4.5 rc1) be a
>> good date ?
>>
>> Cheers,
>> Frank
>> ___
>> kopete-devel mailing list
>> kopete-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/kopete-devel
>
>
> Why to git? Why not to bzr?
>

Because the KDE decided months ago to move to Git.
--
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: When does Kopete move to gitorious.org ?

[Matt Rogers]

On Tue, May 18, 2010 at 3:54 AM, Frank Schaefer
 wrote:
> Hi,
>
> I noticed that more and more KDE-projects are moving to gitorious.org
> (e.g. Amarok, KDevelop, Kate, Konversion).
> When does Kopete move to gitorious.org ?
> Wouldn't the beginning of the KDE 4.6 development cycle (4.5 rc1) be a
> good date ?
>
> Cheers,
> Frank

We will move when the rest of KDE moves. No sooner, no later.
--
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Reviewboard patches

[Matt Rogers]

On Mon, May 10, 2010 at 3:35 AM, Pali Rohár  wrote:
> On Pi 16. Apríl 2010 06:05:26 you wrote:
>> On Tuesday, April 13, 2010 01:01:39 pm Pali Rohár wrote:
>> > Hello,
>> >
>> > I sent some patches to reviewboard last month, but without answer. Is
>> > there any problems with these patches?
>>
>> silence means tacit approval. Just commit them.
>
> Hello,
>
> sorry for a long late...
> Can I commit these patches?
>
> http://reviewboard.kde.org/r/3231/
> http://reviewboard.kde.org/r/3846/
> http://reviewboard.kde.org/r/3846/
>
>

Sure.
--
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: new list admins needed for kopete-devel and kopete-bugs

[Matt Rogers]

On Wed, May 5, 2010 at 9:10 PM, Raphael Kubo da Costa  wrote:
> On Wednesday 05 May 2010 22:16:23 Matt Rogers wrote:
>> Hi,
>>
>> The kopete-devel and kopete-bugs list could use a few more additional
>> moderators/admins to handle the list admin stuff.
>>
>> Any volunteers?
>
> How heavy is the traffic for them?

The moderation traffic is fairly light. kopete-bugs has the most
traffic, but the least amount of moderation, since it's all basically
emails from bugzilla. kopete-devel has more moderation to due because
of the various pieces of spam that come in, but i would say it's only
a once every other day occurance.
--
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

new list admins needed for kopete-devel and kopete-bugs

[Matt Rogers]

Hi,

The kopete-devel and kopete-bugs list could use a few more additional
moderators/admins to handle the list admin stuff.

Any volunteers?
--
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Review Request: Encode avatar filenames prior to saving

[Matt Rogers]

On Monday, April 19, 2010 11:33:04 am Teemu Rytilahti wrote:
> > On 2010-04-17 18:12:22, Raphael Kubo da Costa wrote:
> > > I don't know the code, so to an external reviewer the patch looks OK.
> > > Do you have an SVN account?
> 
> Yup, I do have an account, but of course it'd be nice if someone with
> insight of the code could check this before I commit :-)
> 
> 
> - Teemu
> 
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3632/#review5087
> ---
> 
> On 2010-04-17 14:53:56, Teemu Rytilahti wrote:
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > http://reviewboard.kde.org/r/3632/
> > ---
> > 
> > (Updated 2010-04-17 14:53:56)
> > 
> > 
> > Review request for Kopete.
> > 
> > 
> > Summary
> > ---
> > 
> > This patch uses KIO::encodeFilename() to encode the filename prior to
> > saving it to the filesystem. This allows Kopete to save avatar photos
> > for Jabber groupchat users (where JID has a slash;
> > chatr...@server/userhandle). After this patch the avatar will be
> > displayed in groupchat (though after its vCard is manually fetched
> > first, another bug there).
> > 
> > Earlier Kopete wasn't able to save the image as '/' is reserved character
> > on *nix filesystems.
> > 
> > 
> > This addresses bug 156184.
> > 
> > https://bugs.kde.org/show_bug.cgi?id=156184
> > 
> > Diffs
> > -
> > 
> >   /trunk/KDE/kdenetwork/kopete/libkopete/kopeteavatarmanager.cpp 1115755
> > 
> > Diff: http://reviewboard.kde.org/r/3632/diff
> > 
> > 
> > Testing
> > ---
> > 
> > Tested with current Kopete trunk.
> > 1) Join a XMPP chatroom
> > 2) Open vcard dialog for a member of the chat and allow it to fetch the
> > image 3) The avatar is now shown there.
> > 
> > 
> > Thanks,
> > 
> > Teemu

It does indeed look fine. Please commit
--
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Export contacts

[Matt Rogers]

On Sunday, April 18, 2010 11:23:20 am bravealien wrote:
> Hello,
> I would like to add one option into function "export contacts", which will
> export contacts with some informations, like numbers, or mails to text
> file. It should by realized like a checkbox in export form. After marking
> the checkbox, the contacts would be exported into text file, otherwise
> into the KAddressbook. This text file could be also imported, for example
> in the case of loosing account. Do you think that it would by useful and I
> should write this, or not? Thanks Mikk


Sure, I think it would be useful. Please submit a patch.
-- 
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Reviewboard patches

[Matt Rogers]

On Tuesday, April 13, 2010 01:01:39 pm Pali Rohár wrote:
> Hello,
> 
> I sent some patches to reviewboard last month, but without answer. Is there
> any problems with these patches?

silence means tacit approval. Just commit them.
-- 
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: kopete always connects with empty password for protocols with blank passwords allowed, even if password is saved in config

[Matt Rogers]

On Saturday 20 March 2010 05:33:39 am cyberb...@gmx.de wrote:
> Hi,
> 
> could someone take a short look on this bug
> 
> https://bugs.kde.org/show_bug.cgi?id=229611
> 
> posted by me? Am I right, that this behaviour is wrong? Should I fix it in
> svn and backport to 4.4 branch?
> 
> Volker

Fix it, provide the patch so that it can be reviewed, and it will come out 
whether or not that's desired behavior at that point. I couldn't really tell 
much from the bug report.
-- 
Matt


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: state of the sms plugin

[Matt Rogers]

On Monday 15 March 2010 08:04:15 pm Bruno Bigras wrote:
> Hi,
> 
> I was looking at the sms plugin and were wandering if it's still being
> used.
> 
> Both links in the 'description' button seem to be broken
> (http://zekiller.skytech.org/smssend_en.php and
> http://www.smsclient.org)
> 
> smsclient seems to be still available as ubuntu package.
> 
> Anyone knows if smssend is still maintained? Or if we should drop it
> from the plugin.
> 
> Maybe it should be replaced by another web based sms service or a
> custom script that send emails.
> 
> The ui is also broken when we switch from smssend to smsclient, I
> could take a look at this but first I would like to know if it's still
> usefull.
> 
> Bruno

It's broken. We should just remove it and be done with it, IMO.
-- 
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Set status message after kopete start [PATCH]

[Matt Rogers]

On Wednesday 10 March 2010 12:29:05 am Pali Rohár wrote:
> On St 10. Marec 2010 04:12:13 Matt Rogers wrote:
> > On Tuesday 09 March 2010 09:50:40 am Pali Rohár wrote:
> > > On Po 8. Marec 2010 20:08:00 you wrote:
> > > > On Ne 7. Marec 2010 21:33:44 Raphael Kubo da Costa wrote:
> > > > > On Sunday 07 March 2010 15:38:14 Pali Rohár wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > Kopete doesnt set status message after start or after solid
> > > > > > networking reconnect.
> > > > > > 
> > > > > > It is because, setting online status from kopeteapplication or
> > > > > > kopeteaccountmanager doesnt contains status message (only empty
> > > > > > string).
> > > > > > 
> > > > > > This patch fix this. I try upload this patch file to reviewboard,
> > > > > > but reviewboard show me error: No such revision 1100526 so I
> > > > > > sending it here.
> > > > > 
> > > > > Looks fine overall, even though I don't know this code.
> > > > > ___
> > > > > kopete-devel mailing list
> > > > > kopete-devel@kde.org
> > > > > https://mail.kde.org/mailman/listinfo/kopete-devel
> > > > 
> > > > Hello,
> > > > 
> > > > I see, that status message is not set for account, that comes from
> > > > autoaway. It is same as after starting. (only is set global status
> > > > message in systray, but for accounts is set empty message).
> > > > 
> > > > I updated my patch, which set status message after autoaway.
> > > 
> > > On Ut 9. Marec 2010 04:23:41 Matt Rogers wrote:
> > > > On Sunday 07 March 2010 12:38:14 pm Pali Rohár wrote:
> > > > > Hello,
> > > > > 
> > > > > Kopete doesnt set status message after start or after solid
> > > > > networking reconnect.
> > > > > 
> > > > > It is because, setting online status from kopeteapplication or
> > > > > kopeteaccountmanager doesnt contains status message (only empty
> > > > > string).
> > > > > 
> > > > > This patch fix this. I try upload this patch file to reviewboard,
> > > > > but reviewboard show me error: No such revision 1100526 so I
> > > > > sending it here.
> > > > 
> > > > braces go on separate lines and you're missing braces around the
> > > > single line ifs, but otherwise it looks fine and can be committed.
> > > 
> > > I added missing braces (on separate lines).
> > 
> > looks fine. please commit.
> 
> Commited.
> Is this patch for 4.4 branch?

if there are no new translated strings, sure.
-- 
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Set status message after kopete start [PATCH]

[Matt Rogers]

On Tuesday 09 March 2010 09:50:40 am Pali Rohár wrote:
> On Po 8. Marec 2010 20:08:00 you wrote:
> > On Ne 7. Marec 2010 21:33:44 Raphael Kubo da Costa wrote:
> > > On Sunday 07 March 2010 15:38:14 Pali Rohár wrote:
> > > > Hello,
> > > > 
> > > > Kopete doesnt set status message after start or after solid
> > > > networking reconnect.
> > > > 
> > > > It is because, setting online status from kopeteapplication or
> > > > kopeteaccountmanager doesnt contains status message (only empty
> > > > string).
> > > > 
> > > > This patch fix this. I try upload this patch file to reviewboard, but
> > > > reviewboard show me error: No such revision 1100526 so I sending it
> > > > here.
> > > 
> > > Looks fine overall, even though I don't know this code.
> > > ___
> > > kopete-devel mailing list
> > > kopete-devel@kde.org
> > > https://mail.kde.org/mailman/listinfo/kopete-devel
> > 
> > Hello,
> > 
> > I see, that status message is not set for account, that comes from
> > autoaway. It is same as after starting. (only is set global status
> > message in systray, but for accounts is set empty message).
> > 
> > I updated my patch, which set status message after autoaway.
> 
> On Ut 9. Marec 2010 04:23:41 Matt Rogers wrote:
> > On Sunday 07 March 2010 12:38:14 pm Pali Rohár wrote:
> > > Hello,
> > > 
> > > Kopete doesnt set status message after start or after solid networking
> > > reconnect.
> > > 
> > > It is because, setting online status from kopeteapplication or
> > > kopeteaccountmanager doesnt contains status message (only empty
> > > string).
> > > 
> > > This patch fix this. I try upload this patch file to reviewboard, but
> > > reviewboard show me error: No such revision 1100526 so I sending it
> > > here.
> > 
> > braces go on separate lines and you're missing braces around the single
> > line ifs, but otherwise it looks fine and can be committed.
> 
> I added missing braces (on separate lines).

looks fine. please commit.
-- 
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Set status message after kopete start

[Matt Rogers]

On Sunday 07 March 2010 12:38:14 pm Pali Rohár wrote:
> Hello,
> 
> Kopete doesnt set status message after start or after solid networking
> reconnect.
> 
> It is because, setting online status from kopeteapplication or
> kopeteaccountmanager doesnt contains status message (only empty string).
> 
> This patch fix this. I try upload this patch file to reviewboard, but
> reviewboard show me error: No such revision 1100526 so I sending it here.

braces go on separate lines and you're missing braces around the single line 
ifs, but otherwise it looks fine and can be committed.
-- 
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Review Request: Make skype plugin use message states

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1815/#review4407
---

Ship it!


- Matt


On 2009-12-31 19:27:24, Benson Tsai wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1815/
> ---
> 
> (Updated 2009-12-31 19:27:24)
> 
> 
> Review request for Kopete.
> 
> 
> Summary
> ---
> 
> Currently, the skype plugin does not show a message until it receives 
> acknowledgement via dbus that the message is sent. This introduces a human 
> noticeable between when the user presses enter and when the message shows up. 
> The delay is even longer for the first message because skype has to setup the 
> session. To improve the situation, I modified the skype plugin to use message 
> status to indicate sending/sent and append the message instantly instead of 
> waiting for the ack.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdenetwork/kopete/protocols/skype/libskype/skype.h 1067407 
>   /trunk/KDE/kdenetwork/kopete/protocols/skype/libskype/skype.cpp 1067407 
>   /trunk/KDE/kdenetwork/kopete/protocols/skype/skypeaccount.h 1067407 
>   /trunk/KDE/kdenetwork/kopete/protocols/skype/skypeaccount.cpp 1067407 
>   /trunk/KDE/kdenetwork/kopete/protocols/skype/skypechatsession.h 1067407 
>   /trunk/KDE/kdenetwork/kopete/protocols/skype/skypechatsession.cpp 1067407 
> 
> Diff: http://reviewboard.kde.org/r/1815/diff
> 
> 
> Testing
> ---
> 
> Chatted with friends with the patch applied. It appears to work.
> 
> 
> Thanks,
> 
> Benson
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Review Request: Enable clearsign mode in signed messages (cryptography plugin)

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1657/#review4406
---

Ship it!


Looks good. Please commit (and close the review request after committing)

- Matt


On 2009-10-17 16:14:07, Pali Rohár wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1657/
> ---
> 
> (Updated 2009-10-17 16:14:07)
> 
> 
> Review request for Kopete.
> 
> 
> Summary
> ---
> 
> This patch add support to verify signed messages in clearsign mode and setup 
> clearsign mode as default instead normal mode.
> 
> If message is signed in normal mode, user who doesnt have gnugpg, he cant 
> read this message. But message in clearsign mode is readable without gpg.
> 
> 
> Diffs
> -
> 
>   /trunk/extragear/network/kopete-cryptography/cryptographyplugin.cpp 1036355 
>   /trunk/extragear/network/kopete-cryptography/cryptographypreferences.h 
> 1036355 
>   /trunk/extragear/network/kopete-cryptography/cryptographypreferences.cpp 
> 1036355 
>   /trunk/extragear/network/kopete-cryptography/cryptographysettings.kcfg 
> 1036355 
> 
> Diff: http://reviewboard.kde.org/r/1657/diff
> 
> 
> Testing
> ---
> 
> It works fine.
> 
> Kopete now check signed messages in normal or clearsign mode and encrypted 
> messages.
> 
> 
> Thanks,
> 
> Pali
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Review Request: Add option to build Kopete without video-support

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3074/#review4405
---

Ship it!


I like this. It's a cleaner version of disabling video support for Win32 that 
has even more uses than that did. Please commit (and be sure to close the 
review request when this is committed)

- Matt


On 2010-03-04 18:43:27, Frank Schaefer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3074/
> ---
> 
> (Updated 2010-03-04 18:43:27)
> 
> 
> Review request for Kopete.
> 
> 
> Summary
> ---
> 
> Add option to build Kopete without video-support. Default value is 
> "off"="build with video-support".
> 
> 
> Maybe we should simplify these
> 
> #if !defined(Q_OS_WIN) && !defined(VIDEOSUPPORT_DISABLED)
> 
> lines in the protocol code to
> 
> #ifndef VIDEOSUPPORT_DISABLED
> 
> and let cmake control compilation. These parts of the code actually compile 
> on Windows, too (but of course it doesn't make sense there).
> This would also make it easier for us to enable the video-code of the 
> protocols in the future, when - for example - support for the 
> Windows-video-API is added to class videodevice.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdenetwork/kopete/CMakeLists.txt 1093638 
>   /trunk/KDE/kdenetwork/kopete/kopete/config/CMakeLists.txt 1093638 
>   /trunk/KDE/kdenetwork/kopete/libkopete/CMakeLists.txt 1093638 
>   /trunk/KDE/kdenetwork/kopete/libkopete/ui/avatarselectorwidget.cpp 1093638 
>   /trunk/KDE/kdenetwork/kopete/libkopete/ui/avatarwebcamdialog.cpp 1093638 
>   /trunk/KDE/kdenetwork/kopete/protocols/bonjour/CMakeLists.txt 1093638 
>   /trunk/KDE/kdenetwork/kopete/protocols/qq/CMakeLists.txt 1093638 
>   /trunk/KDE/kdenetwork/kopete/protocols/qq/ui/qqwebcamdialog.cpp 1093638 
>   /trunk/KDE/kdenetwork/kopete/protocols/testbed/CMakeLists.txt 1093638 
>   /trunk/KDE/kdenetwork/kopete/protocols/testbed/ui/testbedwebcamdialog.cpp 
> 1093638 
>   /trunk/KDE/kdenetwork/kopete/protocols/yahoo/CMakeLists.txt 1093638 
>   /trunk/KDE/kdenetwork/kopete/protocols/yahoo/yahoowebcam.cpp 1093638 
> 
> Diff: http://reviewboard.kde.org/r/3074/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Frank
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Fwd: Re: KDE/kdenetwork/kopete/protocols/oscar

[Matt Rogers]

On Friday 26 February 2010 12:47:08 pm Pali Rohár wrote:
> Hello,
> 
> can somebody close this bug? I dont have permitions for this.

Done, along with adding the appropriate permissions.
--
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Review Request: allows kopete to set the mood in skype

[Matt Rogers]

> On 2010-01-21 15:06:56, Pali Rohár wrote:
> > Can you backport it to 4.4?
> 
> Alin M Elena wrote:
> The patch should work without problems. I do not know who can commit it 
> to the branch... Probably would be faster to speak with the distribution 
> people... I really do not know what to do... Roman do you have any thoughts 
> about?
> 
> Alin

this seems like a new feature to me, and as such, we won't backport it, as 
stable branches are bugfixes only.


- Matt


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2534/#review3772
---


On 2010-01-18 22:29:21, Alin M Elena wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2534/
> ---
> 
> (Updated 2010-01-18 22:29:21)
> 
> 
> Review request for Kopete.
> 
> 
> Summary
> ---
> 
> enhances skype wrapper and permits kopete to set the profile mood (status 
> message) for skype
> 
> 
> This addresses bug https://bugs.kde.org/show_bug.cgi?id=221535.
> 
> https://bugs.kde.org/show_bug.cgi?id=https://bugs.kde.org/show_bug.cgi?id=221535
> 
> 
> Diffs
> -
> 
>   
> svn://anonsvn.kde.org/home/kde/trunk/KDE/kdenetwork/kopete/protocols/skype/libskype/skype.h
>  1070407 
>   
> svn://anonsvn.kde.org/home/kde/trunk/KDE/kdenetwork/kopete/protocols/skype/libskype/skype.cpp
>  1070407 
>   
> svn://anonsvn.kde.org/home/kde/trunk/KDE/kdenetwork/kopete/protocols/skype/skypeaccount.cpp
>  1070407 
> 
> Diff: http://reviewboard.kde.org/r/2534/diff
> 
> 
> Testing
> ---
> 
> I have tested on linux, opensuse 11.2 with kde 4.3.87
> tested different manually set profiles Online, Away, Busy...
> and the now listen plugin too. 
> All seem to work...
> 
> 
> Thanks,
> 
> Alin M
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Review Request: Sync contact display name

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3063/#review4285
---

Ship it!


looks fine, if you can test on multiple protocols with no side effects, please 
commit.

- Matt


On 2010-02-26 17:08:45, Pali Rohár wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3063/
> ---
> 
> (Updated 2010-02-26 17:08:45)
> 
> 
> Review request for Kopete.
> 
> 
> Summary
> ---
> 
> If user change display name of metacontact, not always is funcion 
> Kopete::Contact::sync(Kopete::Contact::DisplayNameChanged) called. (Without 
> this patch only when user change custom display name in metacontact 
> configuration widget).
> 
> This patch calling function sync() always when display name is changed.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdenetwork/kopete/libkopete/kopetemetacontact.cpp 1096330 
> 
> Diff: http://reviewboard.kde.org/r/3063/diff
> 
> 
> Testing
> ---
> 
> I tested it with ICQ patch too and for me works fine.
> Before when I changed display name from custom to KABC, function sync was not 
> called and contact name on server side not changed.
> 
> 
> Thanks,
> 
> Pali
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Review Request: Update ICQ contact alias on server side

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3062/#review4284
---

Ship it!


looks fine to me. Please commit.

- Matt


On 2010-02-26 16:34:10, Pali Rohár wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3062/
> ---
> 
> (Updated 2010-02-26 16:34:10)
> 
> 
> Review request for Kopete.
> 
> 
> Summary
> ---
> 
> This patch update ICQ contact alias (displayname) on server side, when user 
> change displayname for metacontact.
> 
> 
> This addresses bug 200582.
> https://bugs.kde.org/show_bug.cgi?id=200582
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdenetwork/kopete/protocols/oscar/icq/icqcontact.cpp 1096330 
>   /trunk/KDE/kdenetwork/kopete/protocols/oscar/oscarcontact.cpp 1096330 
> 
> Diff: http://reviewboard.kde.org/r/3062/diff
> 
> 
> Testing
> ---
> 
> For me it works fine. Now I can use displayname from KABC for all ICQ 
> contacts and names are synced with ICQ server.
> 
> 
> Thanks,
> 
> Pali
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Review Request: Update ICQ contact alias on server side

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3062/#review4283
---

Ship it!


looks fine to me. Please commit.

- Matt


On 2010-02-26 16:34:10, Pali Rohár wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3062/
> ---
> 
> (Updated 2010-02-26 16:34:10)
> 
> 
> Review request for Kopete.
> 
> 
> Summary
> ---
> 
> This patch update ICQ contact alias (displayname) on server side, when user 
> change displayname for metacontact.
> 
> 
> This addresses bug 200582.
> https://bugs.kde.org/show_bug.cgi?id=200582
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdenetwork/kopete/protocols/oscar/icq/icqcontact.cpp 1096330 
>   /trunk/KDE/kdenetwork/kopete/protocols/oscar/oscarcontact.cpp 1096330 
> 
> Diff: http://reviewboard.kde.org/r/3062/diff
> 
> 
> Testing
> ---
> 
> For me it works fine. Now I can use displayname from KABC for all ICQ 
> contacts and names are synced with ICQ server.
> 
> 
> Thanks,
> 
> Pali
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [PATCH] Turn status editor menu into a dialog

[Matt Rogers]

On Monday 15 February 2010 11:39:56 Aurélien Gâteau wrote:
> Hi,
> 
> As I mentioned last week, here is a patch to turn Kopete status 
editor
> menu into a dialog.
> 
> Since the patch is quite large, here is a birds-eye view of what it 
does:
> 
> - Change StatusEditWidget to use a KDialogButtonBox for its 
buttons
> 
> - Move more control from StatusEditAction
> 
> - Introduce a StatusEditDialog class, which users StatusEditWidget 
in a
> way similar to StatusEditAction, but adds a "Cancel" button to the
> KDialogButtonBox
> 
> - Modifies StatusRootAction to use StatusEditDialog instead of
> StatusEditAction
> 
> The patch is against KDE 4.4.0, but should apply to trunk I guess. I
> followed Markus advice and haven't touched the strings yet, as I 
plan to
> get this patch into Kubuntu 10.04. When committed to trunk, I'll 
adjust
> the "Change Message" menu item to "Change Message...".
> 
> What do you think of it?
> 
> Aurélien

Looks fine. I think this can go into both branch and trunk
-- 
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: GaduGadu plugin development

[Matt Rogers]

On Sunday 14 February 2010 05:55:06 pennguin wrote:
> Hello,
> 
> In September I sent some patches to make GaduGadu plugin at 
least useable.
> I don't know about anyone maintaining this plugin and since now I 
have
> more free time I want to implement in new gadu protocol. My goal is 
to
> have it working before next freeze. Since I don't have any kind of 
public
> available server I will post here (through review board) any working 
(and
> bringing something new) patches. Of course any help would be 
great. I will
> base on currently working plugin (as i don't think it is necessary to
> write it from scratch). Am I good to go?
> 
> The minimum plan:
> - implement new protocol (depends on libgadu >1.9.0-rc1) 
includes:
>   UTF-8 messages and longer status messages
>   new online statuses (busy and free for chat)
>   ability to chat with users using new UNI numbers
>   and some more
> - get rid of any qt3to4 dependencies
> 
> Would be nice addition to above to:
> - fix file transfer
> - implement image transfer
> - add ability to delete account and remind password
> 
> 
> Jakub Grandys
> Pennguin
> ___
> kopete-devel mailing list
> kopete-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kopete-devel

Please submit patches at your earliest convenience and we will review 
them.
-- 
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Kopete KStatusNotifierItem menu

[Matt Rogers]

On Wednesday 10 February 2010 11:10:35 Aurélien Gâteau wrote:
> Markus wrote:
> > Am Mittwoch 10 Februar 2010 11:23:48 schrieb Aurélien Gâteau:
> >> I would like
> >> to turn this widget into a dialog. Would you be OK with this 
change?
> > 
> > Hi.
> > Can you post a mockup how it would look like?
> 
> Sure. It would basically look like the menu, except it would be a
> dialog. That is, going from this:
> 
> http://imagebin.ca/view/PoG0-E.html
> 
> To turning the "Message >" item into a "Message..." item, which 
would
> open this (just opened the .ui file for the widget in Designer):
> 
> http://imagebin.ca/view/XtJ6ZRow.html
> 
> Aurélien

This is fine. Please commit if you haven't already.
-- 
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Request for updating Kopete_Jabber_Jingle

[Matt Rogers]

On Friday 29 January 2010 08:48:29 pm Rafał Miłecki wrote:
> 2009/10/11 Rafał Miłecki :
> > I would like to ask you for updating
> > http://userbase.kde.org/Kopete_Jabber_Jingle
> >
> > Currently is says jingle is not supported, but on the other hand
> > http://techbase.kde.org/Schedules/KDE4/4.2_Feature_Plan lists 
jingle
> > voice as "DONE". Moreover starting Kopete I can see video 
preferences
> > (didn't try to talk with anyone yet).
> 
> I would like to ask you again for updating this page. Could someone
> sum up current state with specifying it per-KDE (per-Kopete?) 
version,
> please?
> 

4.0 - no jingle support
4.1 - no jingle support
4.2 - experimental jingle support. not recommended for use
4.3 - no jingle support
4.4 - no jingle support

Is this good enough for somebody else to update the page? I'm 
currently swamped with other things (like 1500+ more emails to go 
through)

> Old replies attached below.
> 
> 
> *
> 
> 
> -- Forwarded message --
> From: Detlev Casanova 
> Date: 2009/10/11
> Subject: Re: Request for updating Kopete_Jabber_Jingle
> To: Rafał Miłecki 
> DW: Anne Wilson , Michaël Larouche
> , kopete-devel@kde.org
> 
> On Sunday 11 October 2009 15:30:15 Rafał Miłecki wrote:
> > HI,
> >
> > I would like to ask you for updating
> > http://userbase.kde.org/Kopete_Jabber_Jingle
> >
> > Currently is says jingle is not supported, but on the other hand
> > http://techbase.kde.org/Schedules/KDE4/4.2_Feature_Plan lists 
jingle
> > voice as "DONE". Moreover starting Kopete I can see video 
preferences
> > (didn't try to talk with anyone yet).
> 
> Hi Rafal,
> 
> http://userbase.kde.org/Kopete_Jabber_Jingle has not been 
updated since KDE
> 3.5, this is not for KDE 4.
> But you're right, it should be updated.
> 
> About Jingle, here's the deal :
> KDE 4.2 came with Jingle support. Unfortunately, The protocol was 
still at
>  an Experimental state at the time and there were some bugs with 
the audio
>  part of Kopete.
> So I decided to deactivate it for KDE 4.3 as the protocol was 
already
>  outdated and no other client had this version implemented. There 
was also
>  problems to connect through firewalls and routers.
> 
> Now that the protocol has been stabilized, I've got a better and up-
to-date
> implementation. It's available on the KDE SVN repository, there :
> 
> svn://anonsvn.kde.org/home/kde/branches/work/kopete/new_jingle
> 
> It's not ready yet (There is no Rtp and it's not been tested at all 
within
> Kopete) so I don't recommend to try it now.
> 
> Rtp should be there soon, I just need to explain oRTP what it has to 
do :-)
> 
> In Kopete, the webcam configuration dialog is used to configure 
your webcam
>  for all protocols (currently, only Yahoo supports video though IIRC),
>  That's why you can configure your webcam even if you can't use it.
> 
> Detlev Casanova.
> 
> PS:I'm not sure the e-mail addresses you used for Anne and 
Michaël are
>  still valid but that's not a problem, I CC'd the answer to the
>  kopete-devel mailing- list.
> 
> 
> *
> 
> 
> -- Forwarded message --
> From: Anne Wilson 
> Date: 2009/10/12
> Subject: Re: Request for updating Kopete_Jabber_Jingle
> To: Detlev Casanova 
> DW: Rafał Miłecki , Michaël Larouche
> , kopete-devel@kde.org
> 
> 
> Thanks for including me in this conversation.  As I don't subscribe 
to the
> kopete-devel list, please keep me cc'd.  Reply below quote:
> 
> On Sunday 11 October 2009 22:52:52 Detlev Casanova wrote:
> > On Sunday 11 October 2009 15:30:15 Rafał Miłecki wrote:
> > > HI,
> > >
> > > I would like to ask you for updating
> > > http://userbase.kde.org/Kopete_Jabber_Jingle
> 
> 
> 
> > http://userbase.kde.org/Kopete_Jabber_Jingle has not been 
updated since
> > KDE 3.5, this is not for KDE 4.
> > But you're right, it should be updated.
> 
> My immediate reaction was that I should use this statement to give 
a more
>  up- to-date page on userbase, but when I look at what exists I 
don't feel
>  competent.  I suspect that quite a lot of that should be deleted, 
but I'm
>  not sure just what.  That leaves us with two options.
> 
> 1) Rafal or one of his associates could update the page directly
> 
> 2) Rafal or teammate could give me a summary of what should be 
deleted, and
> I'll create a page from the remains plus Rafal's comments, then ask 
them to
> check it.
> 
> Either way, I'm happy to work with you all to get this corrected, and
>  thanks again for bringing it to my attention.
> 
> Anne
> ___
> kopete-devel mailing list
> kopete-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kopete-devel
> 
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Jabber disconnect

[Matt Rogers]

On Thursday 28 January 2010 02:53:22 pm Sascha 'saigkill' Manns wrote:
> Hello Mates,
> 
> has anyone an Solution for:
> https://bugs.kde.org/show_bug.cgi?id=202622
> 

Not if it's still open. :)
--
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: libv4l

[Matt Rogers]

On Sunday 24 January 2010 10:14:28 am Frank Schaefer wrote:
> Hi,
> 
> most distros still compile their packages without libv4l, but it is in
> fact indispensable.
> Too many video-device are using custom-decoders and we can't 
provide
> them all (it's also hard to follow kernel-development).
> We have many bug-reports about not working devices and AFAICS 
most of
> them (e.g. 195095, 165357, 166563, 192326, 195811) are caused 
by
> packages beeing compiled without libv4l.
> That's why I would like to make libv4l a requiste for building.
> Any objections ? ;)
> 
> Cheers,
> Frank
> 

I'm fine with this, as long as we make it linux only for the time being. 
--
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: introducing Openfire-Qt / searching for a mentor

[Matt Rogers]

On Friday 15 January 2010 05:11:31 pm Martin wrote:
> Hi,
> 
> at first I want to introduce my first real c++ project: Openfire-Qt [0]
> it's basically a Qt API for the Openfire-C library (see [1])
> 
> Openfire-C is a library which provides access to the xfire network [2]
> as far as I know it's the only actively maintained xfire library out 
there
> (note: there is a pidgin plugin called gfire: [3], [4]. it includes it's
>  own protocol handling code so I won't count that)
> 
> in case you're wondering why I wrote this library:
> I was looking for xfire support inside kopete. trying to add support 
'the
> hackish way' I found it's not very clean to combine a c library which 
uses
> callbacks inside a c++/Qt application
> that was the point where I started to write an abstraction layer 
which
> provides access to Openfire-C's functions by using c++ and Qt.
> 
> as I already stated this library is my first real c++/Qt project (I did a
> small 100 lines of code project before -> that means I'm not very
>  experienced) nevertheless I tried to make the library as good as 
possible.
> 
> my main problem at the moment is that I don't have a mentor.
> at the beginning skyphyr (Alan) helped me out a lot (thanks again!) 
- but
>  he's been busy the last few weeks and he will be busy for the next 
few
>  weeks/months
> 
> I would need two things right now:
> a) I would need a mentor. there are places in my library where I 
can't use
>  a d-pointer for example. it's not easy to explain why - but having a
>  mentor which would at least know tiny bits of my code (so I don't 
have to
>  explain everything multiple times) would be great as it makes 
development
>  easier and more productive (the results are much better)
> b) I would need someone who could review my current code. see 
the gitorious
> project page: [0].
> Albert (TSDgeos) already did a quick (very quick ;)) review of my 
library
>  -> I fixed all problems he found (oh and thanks again to him for his 
nice
>  support)
> 
> if you want to try out my library:
> a minimal sample client (command-line based) is included in the 
'test'
> directory. if you have an xfire account you can log in there and 
receive
> messages.
> note: this "client" is very hackish... I just need it to test my code -
>  it's aim is to make it easier to test my code, not to provide a 
usable
>  client ;)
> 
> now... I really hope at least one of you can help me, so kopete will 
be
>  able to support one more protocol. maybe someone out there 
would also
>  volunteer to write the kopete protocol plugin which will then use 
my
>  library?
> 
> Regards,
> Martin
> 
> [0] http://gitorious.org/openfire-qt
> [1] http://code.google.com/p/openfire-c/
> [2] http://www.xfire.com/
> [3] http://gfireproject.org/
> [4] http://my-trac.assembla.com/gfire/

I don't have any time to mentor anybody at the moment. If my time 
does free up at some point, then I'll contact you to see if you still 
need a mentor.

I still encourage you to work on your code, and post questions to the 
list as you have them. While it may not be as effective as a single 
mentor, I'm sure you'll be able to learn a few things. :)
--
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: Screenshot für Kopete Messenger

[Matt Rogers]

On Saturday 23 January 2010 15:12:58 Tomáš Trnka wrote:
> Dne So 23. ledna 2010 21:50:14 Matt Rogers napsal(a):
> > On Thursday 21 January 2010 11:52:32 Markus Schett wrote:
> > > Sehr geehrtes Kopete Messenger Team!
> > >
> > > Ich betreibe eine Webseite http://www.chat-surium.com/ und habe
> > >  unter http://www.chat-surium.com/multi-messenger/ den Kopete
> > >  Messenger erwähnt inklusive Download Möglichkeit
> > >  http://kopete.kde.org/ nun hätte ich eine Frage, da ich noch keinerlei
> > >  Bilder für diese Seite habe, ob es möglich ist einen Screenshot vom
> > > Kopete Messenger in meine Seite einzubauen, natürlich ohne Kopete
> > > Messenger Logo! Möchte ja meinen Besuchern auch Bilder anbieten. Super
> > > wäre wenn Ihr meine Webseite http://www.chat-surium.com/ auch irgendwo
> > > verlinken könnt, ist natürlich nicht Bedingung! Weiters könnte ich die
> > > Webseite
> > >  http://kopete.kde.org/ noch zusätzlich unter
> > >  http://www.chat-surium.com/chat-info-links/ verlinken.
> > >
> > > Anbei die Webseite  http://www.chat-surium.com/ ist in Wikipedia und in
> > >  Dmoz.org und auch sonst gut referenziert.
> > >
> > > mit freundlichen Grüssen
> > >
> > > Markus
> >
> > Is this legit? I don't read German (yet)
> > --
> > Matt
> 
> Yes, the guy's asking whether he can put a screenshot of Kopete onto his
>  site, where he compares several multiprotocol IM clients.
> 
> 2T
> 

Thanks so much for the translation!
--
Matt


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: Yahoo patches

[Matt Rogers]

On Saturday 23 January 2010 14:42:35 Matt Rogers wrote:
> On Thursday 21 January 2010 20:35:25 Raphael Kubo da Costa wrote:
> > On Friday 22 January 2010 00:11:41 Michael Cole wrote:
> > > On Friday 22 January 2010 12:49:49 am Roman Jarosz wrote:
> > > > Hi,
> > > >
> > > > could you also backport Yahoo fixes to 4.4 branch?
> > > >
> > > > Btw. in 4.4 branch you cannot add/change string so be careful.
> > > >
> > > > Regards
> > > > Roman Jarosz
> > >
> > > Cannot add/change string?
> > >
> > > My changes that I have been working on have new functions - classes
> > > even new files, what does the above statement mean really?..
> >
> > See
> 
> http://techbase.kde.org/Schedules/KDE4/4.4_Release_Schedule#November_25th.2
> 
> > C_2009:_Message_Freeze.
> >
> > That means you must not commit any change that touches translatable
> >  messages (those enclosed with i18n and variations on the theme) before
> >  first discussing it with the translation team. If you're unsure, submit
> >  the patches you want to backport to 4.4 to this list so we can OK them.
> >
> > > Sorry I am new to the KDE SVN...
> > >
> > > I would like to propogate at least the
> > >
> > > 1. Stay Alive and Ping mod.
> > >
> > > 2. Authentication fix
> > >
> > > 3. Audibles Animated Smilies (Does not play them but gives link and the
> > > text associated with the Animation)
> > >
> > > 4. Stealth Settings
> >
> > If you look at
> 
> http://techbase.kde.org/Schedules/KDE4/4.4_Release_Schedule#November_25th.2
> 
> > C_2009:_Hard_Feature_Freeze, you'll see that the 4.4 branch, besides
> > being closed for message changes, is also closed for the so-called
> > "feature commits", which usually means you can only commit bug fixes to
> > the existing code (ie you must not commit code that just introduces new
> > features, or implements a wishlist item).
> >
> > So before backporting that list, double-check your commits to make sure
> >  they don't violate the two rules above.
> >
> > Cheers,
> > Raphael
> 
> I will be backporting these over the next week or so, and will make sure
> nothing breaks string freeze. :)
> --
> Matt
> 

These are backported now. I had more bandwidth available for this than I 
expected. (yay for git)
--
Matt


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: Screenshot für Kopete Messenger

[Matt Rogers]

On Thursday 21 January 2010 11:52:32 Markus Schett wrote:
> Sehr geehrtes Kopete Messenger Team!
> 
> Ich betreibe eine Webseite http://www.chat-surium.com/ und habe
>  unter http://www.chat-surium.com/multi-messenger/ den Kopete
>  Messenger erwähnt inklusive Download Möglichkeit 
>  http://kopete.kde.org/ nun hätte ich eine Frage, da ich noch keinerlei
>  Bilder für diese Seite habe, ob es möglich ist einen Screenshot vom Kopete
>  Messenger in meine Seite einzubauen, natürlich ohne Kopete Messenger Logo!
>  Möchte ja meinen Besuchern auch Bilder anbieten. Super wäre wenn Ihr meine
>  Webseite http://www.chat-surium.com/ auch irgendwo verlinken könnt, ist
>  natürlich nicht Bedingung! Weiters könnte ich die Webseite 
>  http://kopete.kde.org/ noch zusätzlich unter
>  http://www.chat-surium.com/chat-info-links/ verlinken.
> 
> Anbei die Webseite  http://www.chat-surium.com/ ist in Wikipedia und in
>  Dmoz.org und auch sonst gut referenziert.
> 
> mit freundlichen Grüssen
> 
> Markus
> 


Hi Markus,

This is fine. Please feel free to take your own screenshot and post it.
--
Matt


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: Screenshot für Kopete Messenger

[Matt Rogers]

On Thursday 21 January 2010 11:52:32 Markus Schett wrote:
> Sehr geehrtes Kopete Messenger Team!
> 
> Ich betreibe eine Webseite http://www.chat-surium.com/ und habe
>  unter http://www.chat-surium.com/multi-messenger/ den Kopete
>  Messenger erwähnt inklusive Download Möglichkeit 
>  http://kopete.kde.org/ nun hätte ich eine Frage, da ich noch keinerlei
>  Bilder für diese Seite habe, ob es möglich ist einen Screenshot vom Kopete
>  Messenger in meine Seite einzubauen, natürlich ohne Kopete Messenger Logo!
>  Möchte ja meinen Besuchern auch Bilder anbieten. Super wäre wenn Ihr meine
>  Webseite http://www.chat-surium.com/ auch irgendwo verlinken könnt, ist
>  natürlich nicht Bedingung! Weiters könnte ich die Webseite 
>  http://kopete.kde.org/ noch zusätzlich unter
>  http://www.chat-surium.com/chat-info-links/ verlinken.
> 
> Anbei die Webseite  http://www.chat-surium.com/ ist in Wikipedia und in
>  Dmoz.org und auch sonst gut referenziert.
> 
> mit freundlichen Grüssen
> 
> Markus

Is this legit? I don't read German (yet)
--
Matt


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: Yahoo patches

[Matt Rogers]

On Thursday 21 January 2010 20:35:25 Raphael Kubo da Costa wrote:
> On Friday 22 January 2010 00:11:41 Michael Cole wrote:
> > On Friday 22 January 2010 12:49:49 am Roman Jarosz wrote:
> > > Hi,
> > >
> > > could you also backport Yahoo fixes to 4.4 branch?
> > >
> > > Btw. in 4.4 branch you cannot add/change string so be careful.
> > >
> > > Regards
> > > Roman Jarosz
> >
> > Cannot add/change string?
> >
> > My changes that I have been working on have new functions - classes even
> > new files, what does the above statement mean really?..
> 
> See
> 
http://techbase.kde.org/Schedules/KDE4/4.4_Release_Schedule#November_25th.2
> C_2009:_Message_Freeze.
> 
> That means you must not commit any change that touches translatable
>  messages (those enclosed with i18n and variations on the theme) before
>  first discussing it with the translation team. If you're unsure, submit
>  the patches you want to backport to 4.4 to this list so we can OK them.
> 
> > Sorry I am new to the KDE SVN...
> >
> > I would like to propogate at least the
> >
> > 1. Stay Alive and Ping mod.
> >
> > 2. Authentication fix
> >
> > 3. Audibles Animated Smilies (Does not play them but gives link and the
> > text associated with the Animation)
> >
> > 4. Stealth Settings
> 
> If you look at
> 
http://techbase.kde.org/Schedules/KDE4/4.4_Release_Schedule#November_25th.2
> C_2009:_Hard_Feature_Freeze, you'll see that the 4.4 branch, besides being
>  closed for message changes, is also closed for the so-called "feature
>  commits", which usually means you can only commit bug fixes to the
>  existing code (ie you must not commit code that just introduces new
>  features, or implements a wishlist item).
> 
> So before backporting that list, double-check your commits to make sure
>  they don't violate the two rules above.
> 
> Cheers,
> Raphael

I will be backporting these over the next week or so, and will make sure 
nothing breaks string freeze. :)
--
Matt


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: Please close bug 188177, it has been fixed.

[Matt Rogers]

On Saturday 16 January 2010 05:56:50 am Frank Schaefer wrote:
> Please close bug 188177 "configure/video comboboxes are enabled even if
> there isn't any webcam", it has been fixed.
> Auto-closing didn't work because I don't have the required permissions.
> 
> Thanks !
> Frank
> 
> 
> Trunk:
> SVN commit 1072632"Use new API for (hardware) video-controls in
> webcam-configuration-dialog"
> SVN commit 1075597"Video-settings-dialog: disable comboboxes if no
> device available"
> 
> Branch 4.4:
> SVN commit 1075269"Video-settings-dialog: disable comboboxes if no
> device available"
> SVN commit 1075270"Video-settings-dialog: disable "Controls"- and
> "Options"-tabs if no device available"
> 
> 
> 

Permissions added for future bug fixes.
-- 
Matt


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: webcam-patches for branch-4.4

[Matt Rogers]

On Thursday 14 January 2010 13:32:44 Frank Schaefer wrote:
> Hi,
> 
> I finally finished working on a series of patches for kopete's
> webcam-code, which I think should be applied to the 4.4-branch.
> They fix a number of issues with
> - loading/saving of the video-settings
> - device registering + unregistering + switching
> - device input switching
> - GUI-elements in the video-settings-dialog (bug 188177)
> 
> See the a short summary about what they and why below.
> The first 6 patches are basically what I've already put on the
>  review-board. I decided to split them up to make reviewing easier.
>  However, patch 6 ist still complex. Feel free to ask questions.
> 
> All patches apply from Kopetes' root-directory with "patch -p1 <
>  patchfile".
> 
> Even if you do/can not comment the code-changes, please test them and
> report problems.
> 
> Thanks,
> Frank
> 
> 
> ###
> 
> PATCH 1:
> Fix loading of video-setting "Mirror image"
> 
> Fixes a typo in videodevicepool::loadConfiguration().
> --
> PACTH 2:
> Fix loading of video-setting "Whitebalance"
> 
> Add code-line for applying the whitebalance-setting after loading it.
> Also fix the standard value for this setting.
> --
> PATCH 3:
> videodevicepool: decrease model-count in the model-pool when devices are
> removed
> 
> This fixes a bug which causes the wrong device number to be used when
> video-settings are saved in some cases.
> --
> PATCH 4:
> Video-settings (videodevicepool): do not save device automatically when
> open() is called with a device parameter
> 
> With the current code, always the last selected device is saved in the
> video-settings-dialog, even if the settings-changes are cancled/not
>  applied. Restoring the initial value in the settings-dialog would be very
>  complex and video-settings should only be saved by calling
> videodevicepool::saveConfig() explicitly.
> --
> PATCH 5:
> Video-settings (videodevicepool): fix nr. of clients in case of
> device-removal and failed open()
> 
> Set nr. of clients to 0 when the device is removed.
> Do not increase the nr. of clients if open() fails.
> 
> The current code causes video-settings not to be saved in some cases
> (when devices are plugged in for the second time).
> --
> PATCH 6:
> Video-settings (videodevicepool): fix workflow during device-open
> 
> Fixes
> - loading of the saved device
> - closing of the current device before opening a new device
> - handling of multiple clients
> 
> With the current code, always the device with index 0 is used regardless
> of what has been saved.
> This happens, because the video-settings are loaded AFTER the device is
> opened.
> Because the video-settings (options, values for the controls) must be
> applied witch an open device, the only solution is to split the
> loadConfig()-function and into two functions:
> - loadSelectedDevice() => applied before the device is opened to set the
> right device-index
> - loadDeviceConfig()   => applied after the device has been successfully
> opened to set the video-settings
> 
> With the current workflow during device-open (open(int device) calls
> open()), we do not know if the device is selected explicitly or the
> default device should be opened.
> Because of that, merge open() and open(ind device), using negative
> parameters for selecting the standard/saved device (defualt=-1).
> This way, we also fix handling of multiple clients for a device and
> closing of the previous device (which do not work in several cases with
> the current code).
> --
> PATCH 7:
> Fix device-removal in video-settings-dialog
> 
> - stop polling frames from removed device
> - remove unregistered/removed devices from the selection-combobox
> - switch to another device (if available) and start capturing
> --
> PATCH 8:
> Fix device-switching in video-settings-dialog
> 
> Stop capturing from current device and close it before switching to the
> new device
> This fixes the following issues:
> - device-switching not working / hanging devices
> - settings-loading not working after switching to a device for the
> second time (because of >1 clients in videodevicepool)
> --
> PATCH 9:
> Fix device-input-switching in video-settings-dialog
> 
> On most (all ?) devices, the V4L2-ioctl returns EBUSY when trying to
> switch the input while device is streaming.
> Fix it by stopping capturing before switching the input and restarting
> capturing afterwards.
> 

Re: Review Request: webcam-patches for branch-4.4

[Matt Rogers]

On Thursday 14 January 2010 13:32:44 Frank Schaefer wrote:
> Hi,
> 
> I finally finished working on a series of patches for kopete's
> webcam-code, which I think should be applied to the 4.4-branch.
> They fix a number of issues with
> - loading/saving of the video-settings
> - device registering + unregistering + switching
> - device input switching
> - GUI-elements in the video-settings-dialog (bug 188177)
> 
> See the a short summary about what they and why below.
> The first 6 patches are basically what I've already put on the
>  review-board. I decided to split them up to make reviewing easier.
>  However, patch 6 ist still complex. Feel free to ask questions.
> 
> All patches apply from Kopetes' root-directory with "patch -p1 <
>  patchfile".
> 
> Even if you do/can not comment the code-changes, please test them and
> report problems.
> 
> Thanks,
> Frank
> 
> 
> ###
> 
> PATCH 1:
> Fix loading of video-setting "Mirror image"
> 
> Fixes a typo in videodevicepool::loadConfiguration().
> --
> PACTH 2:
> Fix loading of video-setting "Whitebalance"
> 
> Add code-line for applying the whitebalance-setting after loading it.
> Also fix the standard value for this setting.
> --
> PATCH 3:
> videodevicepool: decrease model-count in the model-pool when devices are
> removed
> 
> This fixes a bug which causes the wrong device number to be used when
> video-settings are saved in some cases.
> --
> PATCH 4:
> Video-settings (videodevicepool): do not save device automatically when
> open() is called with a device parameter
> 
> With the current code, always the last selected device is saved in the
> video-settings-dialog, even if the settings-changes are cancled/not
>  applied. Restoring the initial value in the settings-dialog would be very
>  complex and video-settings should only be saved by calling
> videodevicepool::saveConfig() explicitly.
> --
> PATCH 5:
> Video-settings (videodevicepool): fix nr. of clients in case of
> device-removal and failed open()
> 
> Set nr. of clients to 0 when the device is removed.
> Do not increase the nr. of clients if open() fails.
> 
> The current code causes video-settings not to be saved in some cases
> (when devices are plugged in for the second time).
> --
> PATCH 6:
> Video-settings (videodevicepool): fix workflow during device-open
> 
> Fixes
> - loading of the saved device
> - closing of the current device before opening a new device
> - handling of multiple clients
> 
> With the current code, always the device with index 0 is used regardless
> of what has been saved.
> This happens, because the video-settings are loaded AFTER the device is
> opened.
> Because the video-settings (options, values for the controls) must be
> applied witch an open device, the only solution is to split the
> loadConfig()-function and into two functions:
> - loadSelectedDevice() => applied before the device is opened to set the
> right device-index
> - loadDeviceConfig()   => applied after the device has been successfully
> opened to set the video-settings
> 
> With the current workflow during device-open (open(int device) calls
> open()), we do not know if the device is selected explicitly or the
> default device should be opened.
> Because of that, merge open() and open(ind device), using negative
> parameters for selecting the standard/saved device (defualt=-1).
> This way, we also fix handling of multiple clients for a device and
> closing of the previous device (which do not work in several cases with
> the current code).
> --
> PATCH 7:
> Fix device-removal in video-settings-dialog
> 
> - stop polling frames from removed device
> - remove unregistered/removed devices from the selection-combobox
> - switch to another device (if available) and start capturing
> --
> PATCH 8:
> Fix device-switching in video-settings-dialog
> 
> Stop capturing from current device and close it before switching to the
> new device
> This fixes the following issues:
> - device-switching not working / hanging devices
> - settings-loading not working after switching to a device for the
> second time (because of >1 clients in videodevicepool)
> --
> PATCH 9:
> Fix device-input-switching in video-settings-dialog
> 
> On most (all ?) devices, the V4L2-ioctl returns EBUSY when trying to
> switch the input while device is streaming.
> Fix it by stopping capturing before switching the input and restarting
> capturing afterwards.
> 

Re: Code documentation

[Matt Rogers]

On Monday 11 January 2010 12:12:05 Frank Schaefer wrote:
> Tomáš Trnka schrieb:
> > Dne So 9. ledna 2010 19:58:23 Frank Schaefer napsal(a):
> >> /*!
> >> \fn VideoDevicePool::open()
> >>  */
> >>
> >> What kind of code documentation ist that and how does it work ? It's not
> >> doxygen, right ?
> >
> > Hello Frank,
> >
> > actually, that is Qt code documentation style, one of the two Doxygen
> > (the other one is Javadoc) styles. See here for additional info:
> > http://www.stack.nl/~dimitri/doxygen/docblocks.html
> >
> > 2T
> 
> Hmm, thanks Tomáš, I've never seen this Qt-style before...
> Are there any good reasons for using it instead of the Javadoc-style ?
> (If not, why did they try to reinvent the wheel ? ;) )
> I see both styles beeing used, so I guess there is no clear policy ?
> 
> Cheers,
> Frank
> 

No policy really. javadoc style is prefered over Qt style, in general, using 
slash command names (like \param and \return), instead of at command names 
(like @param and @return) but you should go with whatever the majority of the 
file already is.
-- 
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: PATCHES for DISCUSSION: changing the API for video-controls

[Matt Rogers]

On Saturday 09 January 2010 12:48:43 pm Frank Schaefer wrote:
> Matt Rogers schrieb:
> > On Sunday 03 January 2010 05:33:19 am Frank Schaefer wrote:
> >> The problem is, that (AFAIK) subversion isn't capable of creating
> >> offline patch-series.
> >> That's why I used git, which is usually not a problem.
> >> But for some unknown reasons, review-board doesn't accept them (even
> >> after modifying them manually).
> >> 
> >> So here they are as atachments.
> >> All patches apply fine with "patch p1 < patchname" from kopetes'
> >> root-directory.
> >> 
> >> As I already mentioned, the main intention is to make the API for the
> >> video-controls more flexible and functional.
> >> 
> >> Some of the problems with the current code are:
> >>  - only a fixed set of controls is supported
> >>  - no possibility to determine if a control is really supported by a
> >>  
> >>device
> >>  
> >>  - non-numeric controls (e.g. actions) are not supported
> >>  - custom (driver-defined) controls are not supported
> >>  - additional informations like default-/min-/max-values and required
> >>  
> >>step-size are not available
> >>  
> >>  - problems: e.g. the V4L2-control V4L2_CID_HUE combines the two
> >>  
> >>controls "hue" and "color" in a single control
> >> 
> >> That's why I suggest the following changes:
> >> - use IDs to identify/address the supported controls
> >> - the values of controls can be querried/set with the new functions
> >> 
> >>  getControlValue(ctrl_ID, value)
> >>  setControlValue(ctrl_ID, value)
> >> 
> >> - the controls supported by the device can be querried with 4 new
> >> 
> >>   functions, one of them for each group of controls (numeric, boolean,
> >>   menus, actions). These functions return data structures which contain
> >>   the control-ID, the title and additional informations (depending on
> >>   the control-type).
> >> 
> >> Some additional benefits are
> >> - control-grouping makes GUI-design easier (different GUI-elements)
> >> - controls can be reset to default-values
> >> - the real (not normed) numeric value of a control can be displayed
> >> - ...
> >> 
> >> 
> >> There are still some things to do:
> >> - reenable saving of the settings (loading is disabled in current runk,
> >> 
> >>   too !) After taking a deeper look into the loading-/saving-procedures,
> >>   I noticed that there are many other problems...
> >>   For example: devices should be identified by their uid, not their
> >>   model-name !
> >> 
> >> - translation of the control-titles.
> >> 
> >>   I'm not yet familar with KDEs translation mechanism, but the only
> >>   problem I see is the translation of custom (driver-specific) controls.
> >>   We get them from the V4L2-API directly.
> >> 
> >> - Documentation
> >> 
> >> Although the patches are working fine, they are mainly intended for
> >> discussion about the general approach (so please don't complain about
> >> whitespace-errors ;) )
> >> 
> >> Comments are appreciated.
> >> 
> >> Frank
> > 
> > Please feel free to commit your patches to trunk now that you've got an
> > SVN account.
> 
> Thanks, I will rebase and commit them tomorrow with some some minor
> changes applied:
> - use K- instead of Q-GUI-elements
> - return value int instead of bool for getControlValue(), setControlValue()
> - tr() => i18n()
> - add + ":" to the titles of the controls
> - fix whitespaces in IdGuiElements
> - use m_name instead of _name for members in videodevice
> - other mail address
> 
> Frank
> ___
> kopete-devel mailing list
> kopete-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kopete-devel

excellent! thanks for your work!
-- 
Matt


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: Code documentation

[Matt Rogers]

On Saturday 09 January 2010 12:58:23 pm Frank Schaefer wrote:
> /*!
> \fn VideoDevicePool::open()
>  */
> 
> What kind of code documentation ist that and how does it work ? It's not
> doxygen, right ?
> 
> Thanks,
> Frank
> 
> ___
> kopete-devel mailing list
> kopete-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kopete-devel

no, it is doxygen. :)
-- 
Matt


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: PATCHES for DISCUSSION: changing the API for video-controls

[Matt Rogers]

On Sunday 03 January 2010 05:33:19 am Frank Schaefer wrote:
> The problem is, that (AFAIK) subversion isn't capable of creating
> offline patch-series.
> That's why I used git, which is usually not a problem.
> But for some unknown reasons, review-board doesn't accept them (even
> after modifying them manually).
> 
> So here they are as atachments.
> All patches apply fine with "patch p1 < patchname" from kopetes'
> root-directory.
> 
> As I already mentioned, the main intention is to make the API for the
> video-controls more flexible and functional.
> 
> Some of the problems with the current code are:
>  - only a fixed set of controls is supported
>  - no possibility to determine if a control is really supported by a
>device
>  - non-numeric controls (e.g. actions) are not supported
>  - custom (driver-defined) controls are not supported
>  - additional informations like default-/min-/max-values and required
>step-size are not available
>  - problems: e.g. the V4L2-control V4L2_CID_HUE combines the two
>controls "hue" and "color" in a single control
> 
> That's why I suggest the following changes:
> - use IDs to identify/address the supported controls
> - the values of controls can be querried/set with the new functions
>  getControlValue(ctrl_ID, value)
>  setControlValue(ctrl_ID, value)
> - the controls supported by the device can be querried with 4 new
>   functions, one of them for each group of controls (numeric, boolean,
>   menus, actions). These functions return data structures which contain
>   the control-ID, the title and additional informations (depending on
>   the control-type).
> 
> Some additional benefits are
> - control-grouping makes GUI-design easier (different GUI-elements)
> - controls can be reset to default-values
> - the real (not normed) numeric value of a control can be displayed
> - ...
> 
> 
> There are still some things to do:
> - reenable saving of the settings (loading is disabled in current runk,
>   too !) After taking a deeper look into the loading-/saving-procedures,
>   I noticed that there are many other problems...
>   For example: devices should be identified by their uid, not their
>   model-name !
> - translation of the control-titles.
>   I'm not yet familar with KDEs translation mechanism, but the only
>   problem I see is the translation of custom (driver-specific) controls.
>   We get them from the V4L2-API directly.
> - Documentation
> 
> Although the patches are working fine, they are mainly intended for
> discussion about the general approach (so please don't complain about
> whitespace-errors ;) )
> 
> Comments are appreciated.
> 
> Frank


Please feel free to commit your patches to trunk now that you've got an SVN 
account.
-- 
Matt


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: Fix wrong video device beeing used after other video devices have been removed

[Matt Rogers]

On Friday 08 January 2010 02:34:20 pm Cláudio Pinheiro wrote:
> To me it's ok. I'll commit when I get home.
> 
> 
> Cláudio
> 
> On Wed, Jan 6, 2010 at 4:03 PM, Frank Schaefer 
wrote:
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > http://reviewboard.kde.org/r/2514/
> > ---
> > 
> > Review request for Kopete.
> > 
> > 
> > Summary
> > ---
> > 
> > Decrease index of the current video device when devices with lower
> > indexes are removed.
> > Also set current index to 0 (default), if the current device is removed.
> > 
> > 
> > Diffs
> > -
> > 
> >  /trunk/KDE/kdenetwork/kopete/libkopete/avdevice/videodevicepool.cpp
> > 
> > 1070774
> > 
> > Diff: http://reviewboard.kde.org/r/2514/diff
> > 
> > 
> > Testing
> > ---
> > 
> > Tested with a 2-device-setup: removed the 1st (index 0) while capturing
> > from the 2nd (index 1).
> > 
> > 
> > Thanks,
> > 
> > Frank
> > 
> > ___
> > kopete-devel mailing list
> > kopete-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/kopete-devel

He can just commit to trunk now, since his account is now active.
-- 
Matt


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: PATCHES for DISCUSSION: changing the API for video-controls

[Matt Rogers]

On Sunday 03 January 2010 05:33:19 am Frank Schaefer wrote:
> The problem is, that (AFAIK) subversion isn't capable of creating
> offline patch-series.
> That's why I used git, which is usually not a problem.
> But for some unknown reasons, review-board doesn't accept them (even
> after modifying them manually).
> 
> So here they are as atachments.
> All patches apply fine with "patch p1 < patchname" from kopetes'
> root-directory.
> 
> As I already mentioned, the main intention is to make the API for the
> video-controls more flexible and functional.
> 
> Some of the problems with the current code are:
>  - only a fixed set of controls is supported
>  - no possibility to determine if a control is really supported by a
>device
>  - non-numeric controls (e.g. actions) are not supported
>  - custom (driver-defined) controls are not supported
>  - additional informations like default-/min-/max-values and required
>step-size are not available
>  - problems: e.g. the V4L2-control V4L2_CID_HUE combines the two
>controls "hue" and "color" in a single control
> 
> That's why I suggest the following changes:
> - use IDs to identify/address the supported controls
> - the values of controls can be querried/set with the new functions
>  getControlValue(ctrl_ID, value)
>  setControlValue(ctrl_ID, value)
> - the controls supported by the device can be querried with 4 new
>   functions, one of them for each group of controls (numeric, boolean,
>   menus, actions). These functions return data structures which contain
>   the control-ID, the title and additional informations (depending on
>   the control-type).
> 
> Some additional benefits are
> - control-grouping makes GUI-design easier (different GUI-elements)
> - controls can be reset to default-values
> - the real (not normed) numeric value of a control can be displayed
> - ...
> 
> 
> There are still some things to do:
> - reenable saving of the settings (loading is disabled in current runk,
>   too !) After taking a deeper look into the loading-/saving-procedures,
>   I noticed that there are many other problems...
>   For example: devices should be identified by their uid, not their
>   model-name !
> - translation of the control-titles.
>   I'm not yet familar with KDEs translation mechanism, but the only
>   problem I see is the translation of custom (driver-specific) controls.
>   We get them from the V4L2-API directly.
> - Documentation
> 
> Although the patches are working fine, they are mainly intended for
> discussion about the general approach (so please don't complain about
> whitespace-errors ;) )
> 
> Comments are appreciated.
> 
> Frank

0001 is fine.
0002 is fine.
0003 is fine.
0004 is fine.
0005 is fine.
0006 is fine.
0007 is fine.

I reviewed the original mail you sent (sorry for not moderating it in time, I 
was without a decently usable mail client all weekend) and I think all these 
patches are fine and can go in once trunk is opened for new stuff, since they 
add new strings (via the UI files), unless this is really a bug fix, which at 
that point, we might be able to get an exception from the translation team.
-- 
Matt


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: [PATCH] libmsn fixes

[Matt Rogers]

On Saturday 02 January 2010 07:31:45 pm Pau Garcia i Quiles wrote:
> On Sat, Jan 2, 2010 at 9:02 PM, Roman Jarosz  wrote:
> > On Sat, 02 Jan 2010 17:05:28 +0100, Pau Garcia i Quiles
> > 
> >  wrote:
> >> On Sat, Jan 2, 2010 at 3:28 PM, Roman Jarosz  wrote:
> >>> Hi,
> >>> 
> >>> Boiko, here is the first pile of libmsn fixes.
> >>> 
> >>> The 4th patch was not included intentionally.
> >> 
> >> Regarding patch
> >> 0005-Remove-ifdef-LIBMSN_INBOX_URL_ENABLED-and-make-pure-.patch, I
> >> think you do not need to bump soname because the method is virtual.
> >> See http://tinyurl.com/ydfphzy
> > 
> > Hm, I don't see anything about pure virtual functions
> 
> From http://tinyurl.com/ydfphzy :
> 
> "You cannot...
> [...]
> For virtual member functions:
> * add a virtual function to a class that doesn't have any virtual
> functions or virtual bases.
> * add new virtual functions to non-leaf classes as this will break
> subclasses. See below for some workarounds or ask on mailing lists.
> [...]"
> 
> In this case, that's a leaf class and it already has virtual methods
> (i. e. there is a virtual table already), so the change it's
> binary-compatible.
> 
> >, but the bump is
> >
> > also because
> > the older version (0.2.0) could have LIBMSN_INBOX_URL_ENABLED on/off so
> > this
> > will force Kopete recompilation and will fix all the unexpected crashes.
> 
> Soversion was changed from 0.1.0 to 0.2.0 because
> LIBMSN_INBOX_URL_ENABLED broke binary compatibility even when
> LIBMSN_INBOX_URL_ENABLED was OFF, due to the addition of data members
> (search the archives of this mailing list, I explained this in great
> detail a few weeks ago).
> 
> Bump soname just to force Kopete to be rebuilt is a very bad practice
> and I oppose.
> 
> Bumping soname without a need makes my life as the Debian maintainer
> of libmsn more complicated because I need to submit the package and go
> through the FTP-masters queue again, which may take several weeks.
> Please don't.

Sorry, but we're not responsible for Debian project process issues. We *are* 
responsible for making sure we don't have stupid bugs and crashes in our code. 
If it takes a long time to get your stuff uploaded into Debian, that's not our 
problem.

I'm in favor of an soversion bump if it makes our job as library users easier, 
then I'm all for it.
-- 
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [PATCH] libmsn fixes

[Matt Rogers]

On Saturday 02 January 2010 08:28:44 am Roman Jarosz wrote:
> Hi,
> 
> Boiko, here is the first pile of libmsn fixes.
> 
> The 4th patch was not included intentionally.
> 
> Regards,
> Roman

Look fine to me.
-- 
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: How to post a series of patches for discussion ?

[Matt Rogers]

On Friday 01 January 2010 10:46:38 am Frank Schaefer wrote:
> Hi,
> 
> and happy new year to all !
> I would like to post a series of 7 patches for DISCUSSION, which will
> make libkopetes' API for video-controls (contrast, brightness, ...) much
> more flexible and functional.
> They will also modify the video-configuration-dialog.
> Of course, I tried to keep them as small as possible, but they still
> change many lines of code...
> Some patches also deactivate a feature which is then reintroduced with
> the following patch, so they should be reviewed/discussed as series.
> 
> So my question is: how should I post these patches ? Put them on the
> review board ? Post them as one or as separate mails ? Post them inline
> or as attachments ?
> 
> Greetings,
> Frank
> 

Please use reviewboard to post them. Mark each patch as being part of a 
series. Something like "1 of 7" as a prefix would be just fine.

Thanks
-- 
Matt


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: Webcam fixes

[Matt Rogers]

On Sunday 27 December 2009 07:51:09 pm Alex Merry wrote:
> When trying to generate an avatar from a webcam capture, kopete crashed.  I
> fixed the crash and committed it (just a guard on the size of the
> destination of memcpy - r1066810 [trunk], r1066826 [4.3]), but the
> underlying problem was still there, causing the image from the webcam to
> be screwed up.
> 
> The problem is that the configure dialog's A/V page webcam widget sets the
> webcam capture size to 320x240, then the avatar webcam dialog tries to set
> it to 640x480.  This fails (because the device is in use), but the
> VideoDevice class goes ahead assuming it worked.
> 
> The attached patch is a quick fix for it.  It also fixes the problem where
> you can get a camera listed multiple times in the A/V config page.
> 
> The fix is pretty straightforward and minimal - I'd like to tidy up the
> webcam support in kopete properly when we're out of feature freeze.
> 
> Alex

looks fine. please commit.
-- 
Matt


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: the picture download patch and the webcam patch

[Matt Rogers]

On Wednesday 16 December 2009 08:44:09 pm Michael Cole wrote:
> I noted a bug that it was not notifying the application that the icon /
>  Avatar had changed..
> 
> This is the correct fix now.
> 
> I am currently working on the Download - Upload attachments..
> 
> Regards Michael Cole
> 

Ok, I tried to apply this patch. I'm a bit confused. I didn't really 
understand the patch all that much, and neither did the 'patch' program. So, I 
applied it manually, and I'm really not all that sure what parts of the patch 
matter and which ones don't.

If you have an anonymous subversion checkout, you can just run 'svn diff' on 
your working copy and make a patch that way, rather than having to make a copy 
of the directories doing funky stuff like that. :)

Could you resend the correct version using 'svn diff' instead? 

Thanks
-- 
Matt


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: the picture download patch and the webcam patch

[Matt Rogers]

On Wednesday 16 December 2009 07:34:03 am Michael Cole wrote:
> I have attached a diff file for the changes.
> 
> The most important changes are in the files
> /kopete/protocols/yahoo/libkyahoo/webcamtask.cpp
> /kopete/protocols/yahoo/libkyahoo/picturenotifiertask.h
> /kopete/protocols/yahoo/libkyahoo/picturenotifiertask.cpp
> /kopete/protocols/yahoo/libkyahoo/client.cpp
> /kopete/libkopete/kopetechatsession.cpp
> 
> The rest of the changes are just debuging changes.
> 
> I will retest this today if anyone see bugs in other protocols related to
> these changes please notify us..
> 
> What these changes do.
>   You can accept a webcam from a Yahoo user.
> 
>   You can send your webcam (Bug still here but they can then request and
>  view your web cam)(It does not send the popup to the other user.)
> 
>   I am using Mandria and a fault there mentioned that you must run this
>  command first before it works perfectly.
>   export LD_LIBRARY=/usr/lib/ 
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so
>   kopete
> 
> The users Avatars now are downloaded and stored, It only downloads them so
>  far if the other user changes their Avatar while you are online.
> 
> I will review this and see if I can force a request to the users, so then
>  we can get the latest when you are either chatting or when they go online.
> 
> Regards Michael Cole...
> 

Thanks for the patches. They're in my patch queue now, and I should get them 
committed to subversion within the next week or so. You'll get an email when 
these patches get committed.

Please feel free to submit more patches as you have time. :)
-- 
Matt


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: Kopete window showing higher everytime I click on the systray icon

[Matt Rogers]

On Thursday 17 December 2009 12:02:50 Dâniel Fraga wrote:
> On Thu, 17 Dec 2009 15:49:46 -0200
> 
> Dâniel Fraga  wrote:
> > This issue happens only with Kopete.
> >
> > Everytime I click on the systray icon, the Kopete window shows
> > in a higher position (everytime near the top of the screen).
> >
> > Any hints?
> 
> https://bugs.kde.org/show_bug.cgi?id=211731
> 

which i am sure is a duplicate of another bug somewhere but don't have the 
number just yet
-- 
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: You guys need help?

[Matt Rogers]

On Monday 14 December 2009 06:21:09 am Michael Cole wrote:
> I will volunteer to help you guys with the yahoo protocol and others when I
> get that one fully working.
> 
> I have been going through the code and noticed some easy bugs to fix.
> 
> I have not been involved in this type of work before working on a major
> project but it looks like you guys need some help.
> 
> Im running mandriva, and have your latest SVN version running here now.
> 
> for Avatars (Icons download) and also the webcam 90%.. I dont have the send
> request working perfectly but after the request the other end can select
>  view webcam and it works..
> 
> I will need hand holding on sending you patches or what you will require.
> 
> I have been programming for over 25 years now..
> 
> Regards Michael Cole.
> 

We would absolutely love help. 

If you already have patches, then the best thing to do would be to either post 
them on reviewboard, or send them to the kopete-devel list. 

At that point, we'll review them (I usually do this on Fridays) and get them 
committed to subversion. After awhile (aka when I get tired of committing your 
patches because they're good patches) you'll be able to apply for a subversion 
account and commit directly.

Any help that you're willing to provide would be awesome.
-- 
Matt


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: KDE games on kopete

[Matt Rogers]

On Monday 14 December 2009 09:35:08 pm Zubin Mithra wrote:
> I don`t know if the idea of games on kopete is appealing; however i
> believe it hasn`t been taken up yet.
> 
> What i propose here is slightly different; what if we could make an
> API using which developers could make kopete-extentions for various
> KDE games. Consequently, users could play the KDE games with each
> other over kopete.
> 
> This would mean that developing a game for KDE would be more or less
> like developing a game for kopete.
> 
> Is this possible? This idea is`nt mature as of now; so i`d love to
> have ideas, suggestions etc.
> 
> 
> cheers!!!
> Zubin Mithra
> P.S. i had presented this idea on #kopete at irc.kde.org and the core
> idea has changed since then. :)

I'm pretty sure that this is possible. There's two approaches that I currently 
see that you could use to implement this:

1. Make it kopete-dependant. This means that you would basically publish an 
API for people to use in order to set up the communication between the two 
settings of games, perhaps by picking the best protocol available at the time. 
I'm not exactly sure how this would work considering the proprietary nature of 
every single IM protocol other than XMPP. This approach could require that an 
XMPP account be set up in Kopete before being useful.

This also has the disadvantage that it will be obsolete when Kopete 2.0 comes 
out (currently hoping to hit the KDE 4.6 or KDE 4.7 timeframe)

2. Use telepathy and it's tubes framework. This has the advantage of being 
both client, and desktop agnostic. Telepathy is the freedesktop.org standard 
for interfacing with various communication protocols including IM, VoIP, etc. 
They provide a tube framework for passing arbitrary data (IIUC) that could be 
used to establish the link between the players in your game. 

Just my thoughts. Would love to see what you come up with as you  move 
forward.
-- 
Matt


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: Hello, need help

[Matt Rogers]

On Monday 07 December 2009 04:01:31 Slavic wrote:
> Hello
> Thank you for kopedo, i like it very much but I have a problem,
> I have turned off the main toolbar in kopedo and I don't know how to bring
>  it back??? Thank you in advance.
> 

Hold down the 'Ctrl' key and then press the 'M' key.

Thanks
-- 
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [PATCH] Support for Message Indicator in Kopete

[Matt Rogers]

On Friday 04 December 2009 06:12:19 pm Luis Bernardo Henao Jaramillo wrote:
> please ask the same question to m...@kde.org
> 
> 
> 
> 
> 
> Best regards..
> 
> 
> 
> Luis Henao.
> 
> > From: ma...@kde.org
> > To: kopete-devel@kde.org
> > Subject: Re: [PATCH] Support for Message Indicator in Kopete
> > Date: Thu, 3 Dec 2009 21:28:05 -0600
> > CC: aurelien.gat...@canonical.com; jridd...@ubuntu.com
> >
> > On Thursday 03 December 2009 07:45:31 am Aurélien Gâteau wrote:
> > > Hi,
> > >
> > > I am a bit late at this, but I wanted to send you a patch which has
> > > been integrated in Kubuntu Karmic to add support for the Message
> > > Indicator to Kopete.
> > >
> > > Message Indicator is a new way to avoid missing incoming messages. It
> > > tries to avoid disturbing the user while still providing him access to
> > > necessary information. This system is cross-desktop: it is implement on
> > > KDE as a Plasma widget, and on GNOME as a panel applet.
> > >
> > > For more information you can have a look at a post from my blog:
> > >
> > > http://agateau.wordpress.com/2009/09/18/indicators-notifications-and-co
> > >/
> > >
> > > This patch adds support for this new system to Kopete. I initially
> > > implemented it completely as a plugin, but in the end I had to extend
> > > the plugin API a bit so that my plugin was able to control whether the
> > > application should exit when the user click the (x) button of the main
> > > window. This was necessary because the plugin implement a
> > > systray-icon-like behavior (ie: If the plugin is running, clicking the
> > > (x) button should not close Kopete)
> > >
> > > To build this plugin you need:
> > > - libindicate: http://launchpad.net/libindicate
> > > - libindicate-qt: http://launchpad.net/libindicate-qt
> > >
> > > You probably also want the Plasma widget:
> > > - https://launchpad.net/plasma-indicatordisplay
> > >
> > > I know this is quite late in KDE schedule to ask for this to go in
> > > trunk. If you like the idea but think it is too late for KDE 4.4, I'll
> > > come back to you when trunk unfreeze for 4.5.
> > >
> > > Aurélien
> > >
> > > PS: Please CC me of answers
> >
> > The plugin should go to extragear proper. The other changes to Kopete
> > itself can go in.
> >
> > Also, the cmake check is not up to KDE standards since it uses
> > pkg-config, so you'll want to write a libindicate and/or libqindicate
> > cmake module for it.
> 

Why do I need to ask myself the same question? :)
-- 
Matt


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: [PATCH] Support for Message Indicator in Kopete

[Matt Rogers]

On Thursday 03 December 2009 07:45:31 am Aurélien Gâteau wrote:
> Hi,
> 
> I am a bit late at this, but I wanted to send you a patch which has been
> integrated in Kubuntu Karmic to add support for the Message Indicator to
> Kopete.
> 
> Message Indicator is a new way to avoid missing incoming messages. It
> tries to avoid disturbing the user while still providing him access to
> necessary information. This system is cross-desktop: it is implement on
> KDE as a Plasma widget, and on GNOME as a panel applet.
> 
> For more information you can have a look at a post from my blog:
> 
> http://agateau.wordpress.com/2009/09/18/indicators-notifications-and-co/
> 
> This patch adds support for this new system to Kopete. I initially
> implemented it completely as a plugin, but in the end I had to extend
> the plugin API a bit so that my plugin was able to control whether the
> application should exit when the user click the (x) button of the main
> window. This was necessary because the plugin implement a
> systray-icon-like behavior (ie: If the plugin is running, clicking the
> (x) button should not close Kopete)
> 
> To build this plugin you need:
> - libindicate: http://launchpad.net/libindicate
> - libindicate-qt: http://launchpad.net/libindicate-qt
> 
> You probably also want the Plasma widget:
> - https://launchpad.net/plasma-indicatordisplay
> 
> I know this is quite late in KDE schedule to ask for this to go in
> trunk. If you like the idea but think it is too late for KDE 4.4, I'll
> come back to you when trunk unfreeze for 4.5.
> 
> Aurélien
> 
> PS: Please CC me of answers
> 

The plugin should go to extragear proper. The other changes to Kopete itself 
can go in.

Also, the cmake check is not up to KDE standards since it uses pkg-config, so 
you'll want to write a libindicate and/or libqindicate cmake module for it.
-- 
Matt


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: [kopete-devel] Removing prefix from list messages.

[Matt Rogers]

On Sunday 22 November 2009 02:14:16 pm shiplu wrote:
> Will you use any new prefix?
> 

no
-- 
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

[kopete-devel] Removing prefix from list messages.

[Matt Rogers]

Hi,

I'm removing the [kopete-devel] subject prefix from the list messages, 
effective 
immediately.

If you're using this prefix to filter your email, stop now, and use the List-Id 
header instead. If your MDA (either email client or other software) doesn't 
support filtering on arbitrary headers, get better software.

Thanks
-- 
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [kopete-devel] Google Talk support in Kopete

[Matt Rogers]

On Friday 20 November 2009 08:57:31 am Pali Rohár wrote:
> So, can I commit?
> 
> > Hi
> >
> > On 19/11/2009, at 13:12, Alex Fiestas wrote:
> > > On Thursday 19 November 2009 13:23:28 Aleix Pol wrote:
> > >> Well, we all knew that this is a feature that was planned, even if it
> > >> was not on the wiki.
> > >> Anyway, maybe it can be released in extragear before 4.5? this is a
> > >> much needed feature imho...
> > >>
> > >> Aleix
> > >
> > > I agree with apol and others, this feature is a "killer" one, so event
> > > if it wasn't in the wiki I think that we should add an exception here.
> > >
> > > If you want Matt, we can organize a bug day only for this feature, to
> > > be sure that it's working well. We have enough time to fix any issue it
> > > could have.
> >
> > If the opinion of a not-so-active developer counts, it is indeed a good
> > feature to have for 4.4
> >
> > Cheers
> >
> > Boiko

Yes, please commit.
-- 
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [kopete-devel] Google Talk support in Kopete

[Matt Rogers]

On Wednesday 18 November 2009 07:43:23 am Rafał Miłecki wrote:
> 2009/11/18 Raphael Kubo da Costa :
> > On Wednesday 18 November 2009 11:03:03 Pali Rohár wrote:
> >> > On Wednesday 18 November 2009 09:50:18 Pali Rohár wrote:
> >> > > Hello,
> >> > >
> >> > > finally I have libjingle Google Talk voice call support for Kopete.
> >> > > Patch for Kopete jabber protocol is on
> >> > > http://reviewboard.kde.org/r/753/
> >> > >
> >> > > For work this patch need googletalk-call application, which is on
> >> > > google`s svn repository http://libjingle.googlecode.com/svn/trunk/
> >> > >
> >> > > I convert automake files to cmake and now I can compile google`s
> >> > > libjingle with kopete.
> >> > >
> >> > > So, can I now commit patch from reviewboard and import google
> >> > > libjingle repository to
> >> > > kdenetwork/kopete/protocols/jabber/googletalk/libjingle ?
> >> > >
> >> > > I sending cmake patch and patch for google`s libjingle to fix
> >> > > crashed and compile under gcc 4.3 / 4.4
> >> > >
> >> > > I test it, and voice call works fine with windows Google Talk client
> >> > > and Gmail web voice plugin.
> >> >
> >> > I'm ok with it but don't forget we're in Soft Feature Freeze
> >>
> >> So, can I commit patches and google`s libjingle to svn?
> >
> > I couldn't find an entry for this in the Feature Plan [1].
> >
> > If we're to follow the guidelines strictly, this will have to wait until
> > 4.5.
> >
> > [1] http://techbase.kde.org/Schedules/KDE4/4.4_Feature_Plan#kdenetwork
> 
> Pali was waiting long time for reviewing on RB, see linked review
> request. So I still would like to see this commited.
> 

Sorry, but if this was wanted for KDE 4.4, it should have gone in the feature 
plan. I'm not going to take responsibility for somebody else forgetting to add 
something to the feature plan.

It can go in for KDE 4.5.
-- 
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [kopete-devel] Google Talk support in Kopete

[Matt Rogers]

On Wednesday 18 November 2009 07:03:03 am Pali Rohár wrote:
> > On Wednesday 18 November 2009 09:50:18 Pali Rohár wrote:
> > > Hello,
> > >
> > > finally I have libjingle Google Talk voice call support for Kopete.
> > > Patch for Kopete jabber protocol is on
> > > http://reviewboard.kde.org/r/753/
> > >
> > > For work this patch need googletalk-call application, which is on
> > > google`s svn repository http://libjingle.googlecode.com/svn/trunk/
> > >
> > > I convert automake files to cmake and now I can compile google`s
> > > libjingle with kopete.
> > >
> > > So, can I now commit patch from reviewboard and import google libjingle
> > >  repository to kdenetwork/kopete/protocols/jabber/googletalk/libjingle
> > > ?
> > >
> > > I sending cmake patch and patch for google`s libjingle to fix crashed
> > > and compile under gcc 4.3 / 4.4
> > >
> > > I test it, and voice call works fine with windows Google Talk client
> > > and Gmail web voice plugin.
> >
> > I'm ok with it but don't forget we're in Soft Feature Freeze
> 
> So, can I commit patches and google`s libjingle to svn?
> 
> > Detlev Casanova.
> 

No. It's not in the feature plan. We're in soft feature freeze, which means 
that only features that are on the feature plan can be committed.
-- 
Matt
___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [kopete-devel] Review Request: Add support for sorting contactlist based on log size

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2110/#review3135
---


i agree with the feature but i dislike the current implementation only because 
history is currently not in the Kopete core (nothing wrong with the code 
itself). I would love to see this done as a property (in the same way protocols 
do properties) that the History plugin sets on the contacts and the 
metacontacts rather than the current way it's done. This may even simplify the 
implementation in the model.

- Matt


On 2009-11-10 00:26:17, Jeremy Van den Eynde wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2110/
> ---
> 
> (Updated 2009-11-10 00:26:17)
> 
> 
> Review request for Kopete.
> 
> 
> Summary
> ---
> 
> This patch adds a new sort option for contacts. It calculates at startup the 
> total size of the logs of each metacontact, and uses this size for sorting 
> (most talked to metacontacts are on top). Each contact's log size is updated 
> when necessary.
> 
> 
> Diffs
> -
> 
>   
> /branches/KDE/4.3/kdenetwork/kopete/kopete/contactlist/contactlistproxymodel.cpp
>  1046123 
>   /branches/KDE/4.3/kdenetwork/kopete/libkopete/kopeteappearancesettings.kcfg 
> 1046123 
>   /branches/KDE/4.3/kdenetwork/kopete/libkopete/kopetecontact.h 1046123 
>   /branches/KDE/4.3/kdenetwork/kopete/libkopete/kopetecontact.cpp 1046123 
>   /branches/KDE/4.3/kdenetwork/kopete/libkopete/kopetemetacontact.h 1046123 
>   /branches/KDE/4.3/kdenetwork/kopete/libkopete/kopetemetacontact.cpp 1046123 
>   /branches/KDE/4.3/kdenetwork/kopete/plugins/history/historylogger.h 1046123 
>   /branches/KDE/4.3/kdenetwork/kopete/plugins/history/historylogger.cpp 
> 1046123 
>   
> /branches/KDE/4.3/kdenetwork/kopete/kopete/config/appearance/appearanceconfig_contactlist.ui
>  1046123 
> 
> Diff: http://reviewboard.kde.org/r/2110/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jeremy
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [kopete-devel] Review Request: Group Offline contacts into a separate group "Offline Users"

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2179/#review3133
---


looks fine, I think. Can you provide a screenshot for the new configuration 
dialog


/branches/KDE/4.3/kdenetwork/kopete/kopete/contactlist/contactlistproxymodel.cpp


(groupObject == Kopete::Group::offline()) would be better, as it removes 
the potential ambiguity.


- Matt


On 2009-11-15 02:38:41, Barry Carter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2179/
> ---
> 
> (Updated 2009-11-15 02:38:41)
> 
> 
> Review request for Kopete.
> 
> 
> Summary
> ---
> 
> This patch allows a new configuration option to be set which will show all 
> offline users grouped into a folder called "Offline Users".
> 
> When a contact comes online, the metacontact is removed from the offline 
> group, and added to the normal group folder. Likewise when the contact goes 
> offline, the contact is added to the offline users folder.
> 
> Rules: 
> If "Show Offline" is set, then the offline folder group is removed from view.
> If a search is in progress, the offline folder is removed from view.
> Using the proxyfilter lessThan, the Offline folder is always pushed to the 
> bottom of the list.
> 
> Protection:
> Removed right click access to the folder so no renaming etc can be done 
> (wise?).
> Removed ability for a user to move a contact to the offline folder.
> 
> Side Effects:
> The offline users folder is always visible even when not connected to a 
> network.
> 
> Implementation:
> The offline folder is a "special" group like temporary or toplevel. This 
> allows it to hide away from the group menus while still being filterable.
> 
> Future:
> Assuming anyone is interested in this feature, there are a couple of cosmetic 
> changes that might be made. One is... The offline folder will never have an 
> online contact, so instead of showing "Offline Users (0/1000)" it could be 
> abbreviated to "Offline Users (1000)"
> 
> Questions:
> If we simply call the folder "Offline" would we get better i18n?
> Is there a better way to do this?
> 
> built against 0.80.2
> 
> 
> Diffs
> -
> 
>   
> /branches/KDE/4.3/kdenetwork/kopete/kopete/config/appearance/appearanceconfig_contactlist.ui
>  1046954 
>   
> /branches/KDE/4.3/kdenetwork/kopete/kopete/contactlist/contactlistproxymodel.cpp
>  1046954 
>   
> /branches/KDE/4.3/kdenetwork/kopete/kopete/contactlist/contactlisttreemodel.cpp
>  1046954 
>   
> /branches/KDE/4.3/kdenetwork/kopete/kopete/contactlist/kopetecontactlistview.cpp
>  1046954 
>   
> /branches/KDE/4.3/kdenetwork/kopete/kopete/contactlist/kopeteitemdelegate.cpp 
> 1046954 
>   
> /branches/KDE/4.3/kdenetwork/kopete/libkopete/contactlist/kopetecontactliststorage.cpp
>  1046954 
>   
> /branches/KDE/4.3/kdenetwork/kopete/libkopete/contactlist/xmlcontactstorage.cpp
>  1046954 
>   /branches/KDE/4.3/kdenetwork/kopete/libkopete/kopeteappearancesettings.kcfg 
> 1046954 
>   /branches/KDE/4.3/kdenetwork/kopete/libkopete/kopetecontactlist.cpp 1046954 
>   /branches/KDE/4.3/kdenetwork/kopete/libkopete/kopetegroup.h 1046954 
>   /branches/KDE/4.3/kdenetwork/kopete/libkopete/kopetegroup.cpp 1046954 
>   /branches/KDE/4.3/kdenetwork/kopete/libkopete/kopetemetacontact.cpp 1046954 
> 
> Diff: http://reviewboard.kde.org/r/2179/diff
> 
> 
> Testing
> ---
> 
> Tested against 0.80.2 in /branches/KDE/4.3/kdenetwork/
> 
> 
> Screenshots
> ---
> 
> Offline Users
>   http://reviewboard.kde.org/r/2179/s/262/
> 
> 
> Thanks,
> 
> Barry
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [kopete-devel] Review Request: Implementation of a better contact search system.

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2159/#review3132
---


looks fine, move the cast around, submit a new patch, and i'll commit.


/branches/KDE/4.3/kdenetwork/kopete/kopete/contactlist/contactlistproxymodel.cpp


do this check first and you can skip all the casting if it's not a 
metacontact


- Matt


On 2009-11-13 17:44:48, Barry Carter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2159/
> ---
> 
> (Updated 2009-11-13 17:44:48)
> 
> 
> Review request for Kopete.
> 
> 
> Summary
> ---
> 
> This patch allows the contact quicksearch to search: MetaContact name, email 
> address and also MetaContact-> account contact names.
> The patch works by expanding the search parameters when filterRegExp is not 
> empty.
> An additional feature of the patch is that it will remove group folders if 
> there is no search result. This feature could be considered weak in that it 
> walks the list of metacontacts for each group. If the search filterRegExp is 
> found within the group's contacts, then the group folder is allowed to be 
> shown. As you can imagine, for lots of contacts per folder, evaluating the 
> regexp twice per metacontact could be slow (still seemed usable with 1 
> contacts)
> 
> I would add that this is a first time kopete code fix for me, and I probably 
> implemented some of the casting etc. the hard way. Pointers are welcome!
> 
> 
> Diffs
> -
> 
>   
> /branches/KDE/4.3/kdenetwork/kopete/kopete/contactlist/contactlistproxymodel.h
>  1046954 
>   
> /branches/KDE/4.3/kdenetwork/kopete/kopete/contactlist/contactlistproxymodel.cpp
>  1046954 
> 
> Diff: http://reviewboard.kde.org/r/2159/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Barry
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [kopete-devel] Review Request: kopete chatmemberlistmodel enhancement

[Matt Rogers]

On Friday 30 October 2009 09:37:28 cyberb...@gmx.de wrote:
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1862/
> ---
> 
> (Updated 2009-10-30 14:37:27.946772)
> 
> 
> Review request for Kopete and Matt Rogers.
> 
> 
> Changes
> ---
> 
> I have now done the little changes. One last (big?) problem: this diff is
>  against 4.3 branch. I have no trunk build, and will not use kde trunk on
>  my pc (pc is very slow).
> 
> a) may I commit it to 4.3 branch?
> b) may someone else make it work in trunk? (the files should not have
>  changed much I think)
> 
> 
> Summary
> ---
> 
> - Changed the chatmemberlistmodel so that it sorts the contacts by
>  onlinestatus-weight/nickname (important for IRC). - chatmemberlistmodel
>  manages it's own sorted list of contacts
> - implemented the "FIXME"s so that the add/remove slots do not call
>  "reset()" anymore, which takes a lot of time for big irc channels - added
>  signal/slot for nickname-change to chatsession (model needs to know for
>  resorting)
> 
> 
> Diffs (updated)
> -
> 
>  
>  /branches/KDE/4.3/kdenetwork/kopete/kopete/chatwindow/chattexteditpart.cpp
>  1026738 /branches/KDE/4.3/kdenetwork/kopete/kopete/chatwindow/chatview.cpp
>  1026738
>  /branches/KDE/4.3/kdenetwork/kopete/libkopete/chatsessionmemberslistmodel.
> h 1035610
>  /branches/KDE/4.3/kdenetwork/kopete/libkopete/chatsessionmemberslistmodel.
> cpp 1035610
>  /branches/KDE/4.3/kdenetwork/kopete/libkopete/kopetechatsession.h 1035610
>  /branches/KDE/4.3/kdenetwork/kopete/libkopete/kopetechatsession.cpp
>  1035610
> 
> Diff: http://reviewboard.kde.org/r/1862/diff
> 
> 
> Testing
> ---
> 
> works for me with IRC, ICQ,..
> 
> 
> Screenshots
> ---
> 
> IRC with sorted members
>   http://reviewboard.kde.org/r/1862/s/228/
> 
> 
> Thanks,
> 
> Cyberbeat
> 

Saw that this was committed. Thanks. :) Are you going to backport it to the 
4.3 branch? Or should I?
-- 
Matt


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: [kopete-devel] Review Request: Change the KAction for a KToggleAction for the new isAlwaysVisible property

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1873/#review2860
---

Ship it!


add a comment then commit it.


/trunk/KDE/kdenetwork/kopete/libkopete/kopetemetacontact.cpp
<http://reviewboard.kde.org/r/1873/#comment2238>

are you abusing the onlineStatusChanged signal here? If so, it would be 
nice to at least add a comment explaining why.


- Matt


On 2009-10-17 21:22:56, Bruno Bigras wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1873/
> ---
> 
> (Updated 2009-10-17 21:22:56)
> 
> 
> Review request for Kopete and Matt Rogers.
> 
> 
> Summary
> ---
> 
> This is a small update for my last patch.
> 
> With this the contact list is refreshed when the property change and I added 
> a checkbox to see the state of the property (could be very handy for people 
> having many contact grouped into on metacontact).
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdenetwork/kopete/libkopete/kopetecontact.h 1036347 
>   /trunk/KDE/kdenetwork/kopete/libkopete/kopetecontact.cpp 1036347 
>   /trunk/KDE/kdenetwork/kopete/libkopete/kopetemetacontact.cpp 1036347 
> 
> Diff: http://reviewboard.kde.org/r/1873/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bruno
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [kopete-devel] Review Request: kopete chatmemberlistmodel enhancement

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1862/#review2859
---


Nice patch. Fix the nitpicking I did and it can be committed.


/branches/KDE/4.3/kdenetwork/kopete/kopete/chatwindow/chatview.cpp
<http://reviewboard.kde.org/r/1862/#comment2231>

braces go on separate lines in kopete



/branches/KDE/4.3/kdenetwork/kopete/kopete/chatwindow/chatview.cpp
<http://reviewboard.kde.org/r/1862/#comment2232>

braces on separate line here too.



/branches/KDE/4.3/kdenetwork/kopete/libkopete/chatsessionmemberslistmodel.cpp
<http://reviewboard.kde.org/r/1862/#comment2233>

the debug should be removed. 



/branches/KDE/4.3/kdenetwork/kopete/libkopete/chatsessionmemberslistmodel.cpp
<http://reviewboard.kde.org/r/1862/#comment2234>

braces on a separate line here.



/branches/KDE/4.3/kdenetwork/kopete/libkopete/kopetechatsession.h
<http://reviewboard.kde.org/r/1862/#comment2235>

add another p in suppress. :)



/branches/KDE/4.3/kdenetwork/kopete/libkopete/kopetechatsession.cpp
<http://reviewboard.kde.org/r/1862/#comment2236>

i see no reason to keep this debug statement.


- Matt


On 2009-10-27 23:02:59, Cyberbeat wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1862/
> ---
> 
> (Updated 2009-10-27 23:02:59)
> 
> 
> Review request for Kopete and Matt Rogers.
> 
> 
> Summary
> ---
> 
> - Changed the chatmemberlistmodel so that it sorts the contacts by 
> onlinestatus-weight/nickname (important for IRC).
> - chatmemberlistmodel manages it's own sorted list of contacts
> - implemented the "FIXME"s so that the add/remove slots do not call "reset()" 
> anymore, which takes a lot of time for big irc channels
> - added signal/slot for nickname-change to chatsession (model needs to know 
> for resorting)
> 
> 
> Diffs
> -
> 
>   /branches/KDE/4.3/kdenetwork/kopete/kopete/chatwindow/chattexteditpart.cpp 
> 1026738 
>   /branches/KDE/4.3/kdenetwork/kopete/kopete/chatwindow/chatview.cpp 1026738 
>   /branches/KDE/4.3/kdenetwork/kopete/libkopete/chatsessionmemberslistmodel.h 
> 1035610 
>   
> /branches/KDE/4.3/kdenetwork/kopete/libkopete/chatsessionmemberslistmodel.cpp 
> 1035610 
>   /branches/KDE/4.3/kdenetwork/kopete/libkopete/kopetechatsession.h 1035610 
>   /branches/KDE/4.3/kdenetwork/kopete/libkopete/kopetechatsession.cpp 1035610 
> 
> Diff: http://reviewboard.kde.org/r/1862/diff
> 
> 
> Testing
> ---
> 
> works for me with IRC, ICQ,..
> 
> 
> Screenshots
> ---
> 
> IRC with sorted members
>   http://reviewboard.kde.org/r/1862/s/228/
> 
> 
> Thanks,
> 
> Cyberbeat
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [kopete-devel] kdenetwork - unnecessary find_package(KdepimLibs REQUIRED)

[Matt Rogers]

On Thursday 29 October 2009 08:59:12 Maciej Mrozowski wrote:
> On Wednesday 28 of October 2009 21:53:00 Urs Wolfer wrote:
> > On Wednesday 28 October 2009 18:47:38 Alexander Neundorf wrote:
> > > On Wednesday 28 October 2009, Matt Rogers wrote:
> > > > On Tuesday 27 October 2009 19:33:54 Maciej Mrozowski wrote:
> > > > > On Thursday 22 of October 2009 18:44:15 Alexander Neundorf wrote:
> >
> > [...]
> >
> > > > > - removed support for standalone krdc compilation - doesn't work
> > > > > well as it needs cmake modules from kdenework/cmake anyway.
> > >
> > > The krdc developers should comment on this.
> >
> > It's supposed to work... Probably it got broken with one of the recent
> >  chagnes (telepathy?). Anyway, I would like to keep this "feature" since
> > it makes it easier work with a IDE. It's not fundamental IMHO, but a nice
> > feature. I will try to fix it in a nice way ASAP (probably this
> > weekend?). If anyone has a better way to fix KRDC standalone build, feel
> > free to work on it.
> >
> > [...]
> 
> Well, apart from it mainly lacks cmake modules (that are provided by
>  toplevel kdenetwork/cmake, because they are shared), so making really
>  standalone build would require:
> - either duplicating them to project cmake subdirectory (and maybe some
> recently moved to kdelibs as well if one is paranoid about kdelibs
> compatibility) - the easiest, but leaves a little maintenance burden
> - moving most commonly used (or maybe all of them?) to kdelibs, after they
> pass some QA, and depend on particular kdelibs version at build time.
> 
> Alternative approach (rather feature request for cmake) - create mechanism
>  to fetch (and update) all cmake modules from some online repository, so
>  that there's no need to depend on particular kdelibs version just to have
>  cmake modules available to use.
> 
> > > > I dislike the STREQUAL stuff. if (NOT INSIDE_KDENETWORK) is about a
> > > > bazillion times easier to read. I'd rather use kdenetwork_SOURCE_DIR
> > > > or whatever it is that gets generated by the "project(kdenetwork)"
> > > > call. Seriously, does having an extra variable actually add that
> > > > significant of a cost?
> 
> If it was up to me, if any, I'd prefer STREQUAL way as it is the most
>  generic and will work like everywhere. It does not need module_SOURCE_DIR
>  nor any other external variables to be defined, thus it can serve as a
>  good copy/paste example to be used elsewhere.

I don't care as long as the use case I mention below can still be supported.

> I think the best way of getting just some subdirectory to build/develop is
>  to fetch whole module (like kdenetwork), then remove every subdir that is
>  not 'cmake' and not 'krdc' for instance. It will be 'standalone' in terms
>  it won't build unnecessary stuff, yet it doesn't need separate cmake
>  codepaths to get it done (easier maintenance, no duplicated code - win-win
>  if you ask me).
> 

Except that it doesn't work for the more common use case of using git-svn to 
mirror a single directory, so it's not the best way for me (and others). That 
was what the whole INSIDE_KDENETWORK thing was trying to address, if we can 
use the STREQUAL way or some other more generic way, then whatever, as long as 
I can still use it like I want.
-- 
Matt


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: [kopete-devel] kdenetwork - unnecessary find_package(KdepimLibs REQUIRED)

[Matt Rogers]

On Tuesday 27 October 2009 19:33:54 Maciej Mrozowski wrote:
> On Thursday 22 of October 2009 18:44:15 Alexander Neundorf wrote:
> 
> Sorry for a lag.
> 
> > +if(INSIDE_KDENETWORK)
> >
> > +   find_package(KdepimLibs REQUIRED)
> > +   include_directories(${KDEPIMLIBS_INCLUDE_DIR})
> > +
> > +else(INSIDE_KDENETWORK)
> >
> > Why is kdepimlibs only required when kopete is built as part of
> > kdenetwork
> 
> It's not exactly like this - if you look at
> http://websvn.kde.org/trunk/KDE/kdenetwork/kopete/CMakeLists.txt?revision=1
> 041143&view=markup
> 
> there's already indication, that kopete authors used to (not sure whether
>  it applies anymore) distribute/build kopete as standalone application and
>  check for kdepimlibs in this case.
> 
> > Also, while you are working on this, could you please check which of all
> >  the included CheckSomething.cmake files in kopete/CMakeLists.txt and
> > krdc/CMakeLists.txt are actually used there ?
> 
> Some indeed aren't, and in krdc none are... (see revised patch attached to
> this mail).
> 
> > And I don't really like this one:
> > +if(INSIDE_KDENETWORK)
> >
> > There are at least two other options:
> > +if(NOT ${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR})
> > which will work not only in kdenetwork, but in all other places too,
> >
> > or, more similar to the first one:
> > +if(kdenetwork_SOURCE_DIR)
> > This exists only when kopete is built as part of kdenetwork, due to the
> > project(kdenetwork)
> > call at the top of kdenetwork/CMakeLists.txt, which defines this variable
> >  (and also kdenetwork_BINARY_DIR)
> 
> I'm not the author of INSIDE_KDENETWORK concept so cannot really comment
>  here, though I agree with you - the less cmake variables created and the
>  more universal approach - the better.
> 
> Revised patch:
> - moved to (${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}) way
>  of detecting standalone build in kopete
> - removed support for standalone krdc compilation - doesn't work well as it
> needs cmake modules from kdenework/cmake anyway.
> - removed unused CheckXXX.cmake includes from kopete
> - moved KdepimLibs check to kopete subdir
> - moved kdenetwork toplevel include_directories (KDEPIMLIBS_INCLUDE_DIR) to
> kopete/CMakeLists.txt and removed duplicated one from
>  kopete/plugins/bonjour - removed duplicated find_package(LibVNCServer) as
>  there's
> macro_optional_find_package(LibVNCServer) already just below
> - minor code style cleanup (FIND_PACKAGE->find_package) in kopete
> 
> Any comments on this? (Urs?)
> (please keep discussion in kde-buildsystem, thanks)
> 

I dislike the STREQUAL stuff. if (NOT INSIDE_KDENETWORK) is about a bazillion 
times easier to read. I'd rather use kdenetwork_SOURCE_DIR or whatever it is 
that gets generated by the "project(kdenetwork)" call. Seriously, does having 
an extra variable actually add that significant of a cost?

Otherwise, I have no problems with this patch. 
-- 
Matt (Not subscribed to kde-buildsystem, please cc me or keep kopete-devel in 
the chain)


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: [kopete-devel] Kopete on UserBase

[Matt Rogers]

On Thursday 22 October 2009 12:30:47 AnneWilson wrote:
> We are in the middle of tidying up formatting on UserBase, to bring all
>  pages into some sort of consistency.  Today I've been working on Kopete's
>  page, http://userbase.kde.org/Kopete.  The information there was taken
>  from wiki.kde.org, some 16 months ago, and is quite badly out of date. 
>  Then there are sub-pages, many about the protocols, including
> http://userbase.kde.org/Kopete_Protocols_Overview.
> 
> I've looked at the current Kopete pages, http://kopete.kde.org/, and there
> doesn't seem to be any equivalent pages.  It would help me if you would
>  give me some instructions on how to proceed.  Are those pages now
>  redundant?  Does more up-to-date information exist anywhere?  Do you want
>  to update things yourselves, or do you want me to update them?  And if I
>  am to do it, can you point me to the best place to get relevant
>  information?
> 
> The one thing I want to avoid is giving a bad impression of Kopete, that
> ignores all the work of the last few years.
> 
> I am, of course, not subscribed to this list, so it would be helpful if you
> could CC me in any reply.
> 
> Anne
> 

The information on the old wiki.kde.org is most likely out of date. The 
information that's currently on the web site is out of date. I'm not sure 
about the redundancy of the pages between the two sites. The Kopete web site 
will be updated soon-ish (within the next week or so) with some news items. A 
more substantial update will require more time and won't be available 
immediately, although it's on my TODO list.

Please feel free to update the pages on Userbase (and the main web site, if 
you wish). The best place to get information currently is from the IRC channel 
(#kopete on Freenode) or here on the mailing list.
-- 
Matt


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: [kopete-devel] Review Request: Fix the bug that a contact can't me moved into a group created in Kopete (WLM)

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1917/#review2773
---

Ship it!


looks fine. please commit.

- Matt


On 2009-10-21 03:12:33, Bruno Bigras wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1917/
> ---
> 
> (Updated 2009-10-21 03:12:33)
> 
> 
> Review request for Kopete and Matt Rogers.
> 
> 
> Summary
> ---
> 
> It seems that with WLM, groups are only created when adding a new contact.
> 
> When creating a new group and moving a contact into it. It seems to works but 
> when Kopete is restarted, the contact is back into is old group and the group 
> appars in Kopete but not on the MSN server.
> 
> It's in two parts because it's seems the group is not created fast enough in 
> WlmContact::sync() just before being affected to the contact.
> 
> 
> This addresses bug 190353.
> https://bugs.kde.org/show_bug.cgi?id=190353
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdenetwork/kopete/protocols/wlm/wlmaccount.cpp 1038263 
>   /trunk/KDE/kdenetwork/kopete/protocols/wlm/wlmcontact.cpp 1038263 
> 
> Diff: http://reviewboard.kde.org/r/1917/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bruno
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [kopete-devel] Review Request: Add support for google libjingle voice call

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/753/
---

(Updated 2009-10-17 02:52:07.243590)


Review request for Kopete and Detlev Casanova.


Changes
---

Detlev, please indicate whether or not this can be committed so it can either 
go in, or not. Thanks!


Summary
---

This patch add support (for jabber protocol) Google Talk libjingle voice call. 
It use external libjingle "call" applicaion and stun server from 
http://code.google.com/p/libjingle/


Diffs
-

  trunk/KDE/kdenetwork/kopete/protocols/jabber/CMakeLists.txt 1000543 
  trunk/KDE/kdenetwork/kopete/protocols/jabber/googletalk/googletalk.h 
PRE-CREATION 
  trunk/KDE/kdenetwork/kopete/protocols/jabber/googletalk/googletalk.cpp 
PRE-CREATION 
  
trunk/KDE/kdenetwork/kopete/protocols/jabber/googletalk/googletalkcalldialog.h 
PRE-CREATION 
  
trunk/KDE/kdenetwork/kopete/protocols/jabber/googletalk/googletalkcalldialog.cpp
 PRE-CREATION 
  
trunk/KDE/kdenetwork/kopete/protocols/jabber/googletalk/googletalkcalldialog.ui 
PRE-CREATION 
  trunk/KDE/kdenetwork/kopete/protocols/jabber/jabberaccount.h 1000543 
  trunk/KDE/kdenetwork/kopete/protocols/jabber/jabberaccount.cpp 1000543 
  trunk/KDE/kdenetwork/kopete/protocols/jabber/jabbercontact.h 1000543 
  trunk/KDE/kdenetwork/kopete/protocols/jabber/jabbercontact.cpp 1000543 

Diff: http://reviewboard.kde.org/r/753/diff


Testing
---

It works fine with call application from http://code.google.com/p/libjingle/ 
with patches from http://code.google.com/p/libjingle/issues/list installed in 
PATH

I try it with windows version of Google Talk (on windows) and voice call works. 
I can make call, accept/reject incoming call, hang up call.


Thanks,

Pali

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [kopete-devel] Review Request: Show the contact picture if available in the Participants View

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1394/#review2680
---


no action to address reviews, marked the review as discarded. Please feel free 
to resurrect it when there are updates available for the patch.

- Matt


On 2009-09-12 14:33:25, Aleix Pol wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1394/
> ---
> 
> (Updated 2009-09-12 14:33:25)
> 
> 
> Review request for Kopete.
> 
> 
> Summary
> ---
> 
> I was browsing through the code thinking of some way to improve the chat 
> window.
> 
> I had 2 problems. I wanted to see the contact's picture in a reasonable 
> format (bigger than in the chat view) and the participants list view looked 
> kind of boring/empty most of the time, so I came up with this patch that adds 
> a delegate that can do that.
> 
> It could be improved a little bit but here you can see (mostly in the 
> screenshot) what the patch does and does not.
> 
> Hope you find it useful.
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdenetwork/kopete/libkopete/chatsessionmemberslistmodel.h 1022530 
>   trunk/KDE/kdenetwork/kopete/libkopete/chatsessionmemberslistmodel.cpp 
> 1022530 
>   trunk/KDE/kdenetwork/kopete/kopete/chatwindow/chatmemberslistview.cpp 
> 1022530 
>   trunk/KDE/kdenetwork/kopete/kopete/chatwindow/CMakeLists.txt 1022530 
>   trunk/KDE/kdenetwork/kopete/kopete/chatwindow/chatmembersdelegate.h 
> PRE-CREATION 
>   trunk/KDE/kdenetwork/kopete/kopete/chatwindow/chatmembersdelegate.cpp 
> PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/1394/diff
> 
> 
> Testing
> ---
> 
> Umm... use it...
> 
> 
> Screenshots
> ---
> 
> 
>   http://reviewboard.kde.org/r/1394/s/190/
> 
> 
> Thanks,
> 
> Aleix
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [kopete-devel] Review Request: Add option to send signed/encrypted messages via jabber in pgp inline format

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1656/#review2679
---

Ship it!


please commit.

- Matt


On 2009-09-20 12:04:17, Pali Rohár wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1656/
> ---
> 
> (Updated 2009-09-20 12:04:17)
> 
> 
> Review request for Kopete.
> 
> 
> Summary
> ---
> 
> This patch add option to send signed or encrypted messages in old pgp inline 
> format.
> 
> A lot of jabber clients doesnt support XEP-0027, so users cant receive signed 
> or encrypted messages.
> This option doesnt use XEP-0027, so all signed or encrypted messages will be 
> shown in jabber client (and user can run GnuGPG external).
> 
> This patch fix also deleting string "-END PGP MESSAGE-" at end of 
> jabber message (when inline format is off; with XEP-0027), because it musnt 
> be in jabber encrypted message.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdenetwork/kopete/protocols/jabber/jabberaccount.h 1025987 
>   /trunk/KDE/kdenetwork/kopete/protocols/jabber/jabberaccount.cpp 1025987 
>   /trunk/KDE/kdenetwork/kopete/protocols/jabber/jabberchatsession.cpp 1025987 
>   
> /trunk/KDE/kdenetwork/kopete/protocols/jabber/ui/dlgjabbereditaccountwidget.ui
>  1025987 
>   
> /trunk/KDE/kdenetwork/kopete/protocols/jabber/ui/jabbereditaccountwidget.cpp 
> 1025987 
> 
> Diff: http://reviewboard.kde.org/r/1656/diff
> 
> 
> Testing
> ---
> 
> This patch works for me fine.
> If I chating with someone, who has opened gmail and have gnugpg installed, he 
> can verify or encrypt my messages.
> Without this patch, he only see "This message is encrypted." and he doesnt 
> see PGP block data.
> 
> 
> Thanks,
> 
> Pali
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [kopete-devel] Review Request: Enable clearsign mode in signed messages (cryptography plugin)

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1657/#review2678
---


what does clearsign mode do exactly and why should we enable it by default?

In theory, the patch looks fine, but I'm not sure I agree with the change in 
defaults.

- Matt


On 2009-09-20 12:23:02, Pali Rohár wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1657/
> ---
> 
> (Updated 2009-09-20 12:23:02)
> 
> 
> Review request for Kopete.
> 
> 
> Summary
> ---
> 
> This patch add support to verify signed messages in clearsign mode and setup 
> clearsign mode as default instead normal mode.
> 
> If message is signed in normal mode, user who doesnt have gnugpg, he cant 
> read this message. But message in clearsign mode is readable without gpg.
> 
> 
> Diffs
> -
> 
>   /trunk/extragear/network/kopete-cryptography/cryptographyplugin.cpp 1025986 
> 
> Diff: http://reviewboard.kde.org/r/1657/diff
> 
> 
> Testing
> ---
> 
> It works fine.
> 
> Kopete now check signed messages in normal or clearsign mode and encrypted 
> messages.
> 
> 
> Thanks,
> 
> Pali
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [kopete-devel] Review Request: kopete chatmemberlistmodel enhancement

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1862/#review2677
---

Ship it!


the d-pointer is nice, but we don't prefix d-pointer member variables with 'm' 
or 'm_'. If you have an svn account, please commit. If you don't have one, let 
me know and I'll commit it, with the aforementioned d-pointer changes.


branches/KDE/4.3/kdenetwork/kopete/libkopete/chatsessionmemberslistmodel.cpp


fix this whitespace error


- Matt


On 2009-10-16 17:11:52, Cyberbeat wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1862/
> ---
> 
> (Updated 2009-10-16 17:11:52)
> 
> 
> Review request for Kopete.
> 
> 
> Summary
> ---
> 
> - Changed the chatmemberlistmodel so that it sorts the contacts by 
> onlinestatus-weight/nickname (important for IRC).
> - chatmemberlistmodel manages it's own sorted list of contacts
> - implemented the "FIXME"s so that the add/remove slots do not call "reset()" 
> anymore, which takes a lot of time for big irc channels
> - added signal/slot for nickname-change to chatsession (model needs to know 
> for resorting)
> 
> 
> Diffs
> -
> 
>   branches/KDE/4.3/kdenetwork/kopete/libkopete/chatsessionmemberslistmodel.h 
> 1035610 
>   
> branches/KDE/4.3/kdenetwork/kopete/libkopete/chatsessionmemberslistmodel.cpp 
> 1035610 
>   branches/KDE/4.3/kdenetwork/kopete/libkopete/kopetechatsession.h 1035610 
>   branches/KDE/4.3/kdenetwork/kopete/libkopete/kopetechatsession.cpp 1035610 
> 
> Diff: http://reviewboard.kde.org/r/1862/diff
> 
> 
> Testing
> ---
> 
> works for me with IRC, ICQ,..
> 
> 
> Screenshots
> ---
> 
> IRC with sorted members
>   http://reviewboard.kde.org/r/1862/s/228/
> 
> 
> Thanks,
> 
> Cyberbeat
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [kopete-devel] Review Request: Ability to show individuals contacts even if offline

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1619/#review2676
---

Ship it!


this looks fine. please commit.

- Matt


On 2009-10-15 15:25:43, Bruno Bigras wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1619/
> ---
> 
> (Updated 2009-10-15 15:25:43)
> 
> 
> Review request for Kopete.
> 
> 
> Summary
> ---
> 
> Add the possibility to always show a contact even if offline like in Pidgin. 
> It makes sending messages to "always invisible" friends much easier when 
> having many contacts.
> 
> 
> This addresses bug 98757.
> https://bugs.kde.org/show_bug.cgi?id=98757
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdenetwork/kopete/kopete/contactlist/contactlistproxymodel.cpp 
> 1035504 
>   /trunk/KDE/kdenetwork/kopete/kopete/contactlist/contactlisttreemodel.cpp 
> 1035504 
>   /trunk/KDE/kdenetwork/kopete/kopete/contactlist/kopeteitembase.h 1035504 
>   /trunk/KDE/kdenetwork/kopete/libkopete/kopetecontact.h 1035504 
>   /trunk/KDE/kdenetwork/kopete/libkopete/kopetecontact.cpp 1035504 
>   /trunk/KDE/kdenetwork/kopete/libkopete/kopeteglobal.h 1035504 
>   /trunk/KDE/kdenetwork/kopete/libkopete/kopeteglobal.cpp 1035504 
>   /trunk/KDE/kdenetwork/kopete/libkopete/kopetemetacontact.h 1035504 
>   /trunk/KDE/kdenetwork/kopete/libkopete/kopetemetacontact.cpp 1035504 
>   /trunk/KDE/kdenetwork/kopete/libkopete/ui/kopetestdaction.h 1035504 
>   /trunk/KDE/kdenetwork/kopete/libkopete/ui/kopetestdaction.cpp 1035504 
> 
> Diff: http://reviewboard.kde.org/r/1619/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bruno
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [kopete-devel] Kopete 1.0 and beyond

[Matt Rogers]

On Sunday 04 October 2009 04:06:38 George Goldberg wrote:
> 2009/10/2 Will Stephenson :
> > On Friday 02 October 2009 05:04:31 Matt Rogers wrote:
> >> So, right now, the plan is to release Kopete 1.0 with KDE 4.4. If
> >> anybody thinks that this shouldn't be done, then please speak up now so
> >> we can change the plan. :)
> >>
> >> For beyond Kopete 1.0, my current plan is to morph Kopete into the KDE
> >> equivalent of GNOME's Empathy. This means converting Kopete to
> >> Telepathy. As part of this conversion, I also would like to make use of
> >> the various other kde4 technologies like akonadi, etc. I also want to
> >> resurrect Decibel in the form of various Kopete components that are
> >> available throughout the whole KDE stack for various purposes.
> >>
> >> So the whole point of writing this email is to solicit feedback. So,
> >>  feedback please! :)
> >
> > Strong agreement.  Kopete should organise an ev-funded sprint for the
> > morphing planning (and you should get a passport, hint hint).
> 
> Yes definitely :). I think a sprint would be by far the best way to
> make a plan for what to do, since there is a lot to figure out. This
> is going to be a pretty major change to Kopete. I can probably
> organise one (I'll investigate more if there is interest) if people
> would be able to come to the UK.
> 

Unless it can be in Dallas, and I can get time for it, I won't be able to go 
to a sprint. I get only get two weeks of vacation a year from my employer 
until 2012 (and then I'll get three!) so I have a limited amount of time for a 
sprint, especially considering that 80% of my vacation time is already 
allocated.

IOW, the farther away it is from Dallas, the less likely it is that I'll be 
there.
-- 
Matt


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: [kopete-devel] Gadu Icons

[Matt Rogers]

On Saturday 03 October 2009 14:12:19 Jakub Grandys wrote:
> Hello,
> 
> I'm working on next patch for gadu plugin (support for blocking contacts
>  etc.) and I need to bring couple of new overlays icons (and clean current
>  ones). Could anyone tell my how this should be done? I mean, should I
>  create just overlays, if yes in what size, name etc? There are a lot of
>  unused icons in protocols/gadu/icons (same for most protocols), what for?
>  Another question, am I allowed to use different overlay for away status -
>  something more similar to gadu's original one?
> 

Why do you need/want this? Is there something wrong with the current set of 
overlays? The whole point of Kopete is to unify the majority of the IM 
experience across protocols, not keep it fragmented.

> And one more, should I use Kopete::Account::block() etc or I should made my
> own black list management?
> 
> Pennguin,
> Jakub Grandys

I don't know how this is done. I suppose for the artwork, you could ask the 
oxygen folks for some artwork.
-- 
Matt


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: [kopete-devel] Kopete 1.0 and beyond

[Matt Rogers]

On Sunday 04 October 2009 04:11:36 George Goldberg wrote:
> 2009/10/2 Aleix Pol :
> > I don't want to break the party but... isn't Decibel dead already? maybe
> > we should pick a project that's already alive and with some kind of proof
> > that works.
> 
> Decibel is dead, but that doesn't matter. The Telepathy world has
> changed a lot since Decibel was started, and there is really no need
> for it now. (And just for clarification, Decibel != Telepathy, and
> Telepathy is extremely alive).
> Decibel originally did the job of ChannelDispatcher/Account Manager
> (as mentioned in my first mail to this thread). However, it was never
> completed and fell unmaintained some time ago. We now have Telepathy
> Mission Control 5. This is a fully functional, maintained,
> cross-desktop Channel Dispatcher/Account Manager, so we have no need
> to maintain our own one. Decibel was supposed to also handle the
> integration into other KDE technologies (like Nepomuk), but since this
> has never been implemented in Decibel, there's no reason to implement
> it there.
> 
> > Also... this might be quite some work, shouldn't we try to get it done
> > before announcing it?
> 
> Yeah, this would be a lot of work, and we should be careful to make
> sure it doesn't end up being vapourware like Decibel did. But on the
> other hand we need to have enough publicity for it to get more
> interested people involved. There is a definite need to find a balance
> here.
> 

I wouldn't be announcing it if my intention was to keep it being vaporware. 
Currently I'm targeting KDE 4.5 or KDE 4.6 for this work to be released.

-- 
Matt


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: [kopete-devel] Kopete 1.0 and beyond

[Matt Rogers]

On Sunday 04 October 2009 04:12:59 George Goldberg wrote:
> 2009/10/3 Detlev Casanova :
> > On Friday 02 October 2009 05:04:31 Matt Rogers wrote:
> >> For beyond Kopete 1.0, my current plan is to morph Kopete into the KDE
> >> equivalent of GNOME's Empathy. This means converting Kopete to
> >> Telepathy. As part of this conversion, I also would like to make use of
> >> the various other kde4 technologies like akonadi, etc. I also want to
> >> resurrect Decibel in the form of various Kopete components that are
> >> available throughout the whole KDE stack for various purposes.
> >
> > The Telepathy plugin is promising, isn't it ? Would the Decibel
> > resurrection make that not-really-born yet plugin a deprecated one ?
> 
> That plugin would cease to exist if Kopete became "KDE's Empathy", but
> that plugin only exists as a temporary measure until Kopete becomes
> "KDE's Empathy" anyway, so it doesn't matter :)
> 

IOW, that plugin will cease to exist. :P
-- 
Matt


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: [kopete-devel] Kopete 1.0 and beyond

[Matt Rogers]

On Sunday 04 October 2009 04:04:36 George Goldberg wrote:
> 2009/10/2 Matt Rogers :
> > Hi,
> 
> Hi Folks,
> 
> As the guy who is driving the work on Telepathy adoption in KDE, I
> have quite a lot I'd like to contribute to this thread. I'll start
> with some general information in this mail, and then address specific
> points in further replies.
> 

Not to this thread you don't ;)

I suggest you start at least one new thread for further collaboration on this 
topic. :)

> > So, right now, the plan is to release Kopete 1.0 with KDE 4.4. If anybody
> > thinks that this shouldn't be done, then please speak up now so we can
> > change the plan. :)
> >
> > For beyond Kopete 1.0, my current plan is to morph Kopete into the KDE
> > equivalent of GNOME's Empathy. This means converting Kopete to Telepathy.
> > As part of this conversion, I also would like to make use of the various
> > other kde4 technologies like akonadi, etc. I also want to resurrect
> > Decibel in the form of various Kopete components that are available
> > throughout the whole KDE stack for various purposes.
> 
> I think this is a fantastic idea, obviously ;)
> 
> And now for a little background about Telepathy, for those who aren't
> already familiar with it. Telepathy is a framework for real time
> communication which is based around DBus. Its main purpose on the
> desktop is to remove monolithic IM clients and replace them with deep
> integration into applications and the desktop environment. Due to it's
> DBus nature, you can have, for example, a plasmoid displaying your IM
> account presence, A couple of chat windows open in Kopete, a buddy
> list in Kopete, a voice call in KCall, a buddy list plasmoid, a
> collaborative session in KWord etc etc etc and all of them
> automatically gain support for all protocols Telepathy provides just
> by using the abstracted Telepathy API. On the protocol side, Telepathy
> has daemons called Connection Managers, which handle the actual IM
> protocol, e.g MSN, Jabber, SIP etc and the Telepathy client libraries
> (e.g. TelepathyQt4) talk over DBus to these Connection Managers. In
> the middle there is a daemon which does all the account storage and
> allows you to request channels (e.g. text/voice/video/etc channels) to
> your contacts. This is called the Account Manager/Channel Dispatcher.
> For a much better and more in-depth explanation of how Telepathy
> works, see [1] and [2].
> 
> Where are we at with Telepathy in KDE now? I've been working along
> with Abner Silva, George Kiagiadakis and others for over a year now to
> get the infrastructure for Telepathy in place. We now have a
> rudimentary Telepathy plugin for Kopete in playground. The point of
> this was to allow Telepathy to be used in Kopete sooner than waiting a
> completely Telepathy-based version of Kopete. We also have a gorgeous
> plasmoid for your account presence that Abner created, and a (still
> playground quality but working and getting there) VoIP app based on
> Telepathy in KCall (written by George). We also have support currently
> being merged into Krdc/Krfb to share your desktop over Telepathy
> tubes. I have also been working with Sebastian Trueg (of Nepomuk) and
> Marco Barisione and Danielle Madeley (both of Gnome) to sort out
> ontologies for building meta-contacts with Nepomuk/Tracker in a way
> that will be both cross-desktop compatible and also inter-application
> compatible within KDE. I'll be attending the Nepomuk Workshop [3] to
> finish implementing this in November, if anyone else is particularly
> interested in this, then do come along too :)
> 
> So, in conclusion, I'd be very keen to contribute to make Kopete
> "KDE's Empathy" :).
> 
> I hope this provides some useful context. I'll now follow up to some
> of the other posts already in this thread.
> 
> 
> Cheers,
> 
> George
> 
> --
> [1] http://telepathy.freedesktop.org/wiki/
> [2] http://people.collabora.co.uk/~danni/telepathy-book/ (n.b. this
> document is work-in-progress)
> [3]
>  http://techbase.kde.org/Projects/Nepomuk/OpenSocialSemanticDesktopWorkshop
> 2009 ___
> kopete-devel mailing list
> kopete-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kopete-devel
> 

-- 
Matt


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: [kopete-devel] Kopete 1.0 and beyond

[Matt Rogers]

On Sunday 04 October 2009 04:04:36 George Goldberg wrote:
> 2009/10/2 Matt Rogers :
> > Hi,
> 
> Hi Folks,
> 
> As the guy who is driving the work on Telepathy adoption in KDE, I
> have quite a lot I'd like to contribute to this thread. I'll start
> with some general information in this mail, and then address specific
> points in further replies.
> 
> > So, right now, the plan is to release Kopete 1.0 with KDE 4.4. If anybody
> > thinks that this shouldn't be done, then please speak up now so we can
> > change the plan. :)
> >
> > For beyond Kopete 1.0, my current plan is to morph Kopete into the KDE
> > equivalent of GNOME's Empathy. This means converting Kopete to Telepathy.
> > As part of this conversion, I also would like to make use of the various
> > other kde4 technologies like akonadi, etc. I also want to resurrect
> > Decibel in the form of various Kopete components that are available
> > throughout the whole KDE stack for various purposes.
> 
> I think this is a fantastic idea, obviously ;)
> 
> And now for a little background about Telepathy, for those who aren't
> already familiar with it. Telepathy is a framework for real time
> communication which is based around DBus. Its main purpose on the
> desktop is to remove monolithic IM clients and replace them with deep
> integration into applications and the desktop environment. Due to it's
> DBus nature, you can have, for example, a plasmoid displaying your IM
> account presence, A couple of chat windows open in Kopete, a buddy
> list in Kopete, a voice call in KCall, a buddy list plasmoid, a
> collaborative session in KWord etc etc etc and all of them
> automatically gain support for all protocols Telepathy provides just
> by using the abstracted Telepathy API. On the protocol side, Telepathy
> has daemons called Connection Managers, which handle the actual IM
> protocol, e.g MSN, Jabber, SIP etc and the Telepathy client libraries
> (e.g. TelepathyQt4) talk over DBus to these Connection Managers. In
> the middle there is a daemon which does all the account storage and
> allows you to request channels (e.g. text/voice/video/etc channels) to
> your contacts. This is called the Account Manager/Channel Dispatcher.
> For a much better and more in-depth explanation of how Telepathy
> works, see [1] and [2].
> 
> Where are we at with Telepathy in KDE now? I've been working along
> with Abner Silva, George Kiagiadakis and others for over a year now to
> get the infrastructure for Telepathy in place. We now have a
> rudimentary Telepathy plugin for Kopete in playground. The point of
> this was to allow Telepathy to be used in Kopete sooner than waiting a
> completely Telepathy-based version of Kopete. We also have a gorgeous
> plasmoid for your account presence that Abner created, and a (still
> playground quality but working and getting there) VoIP app based on
> Telepathy in KCall (written by George). We also have support currently
> being merged into Krdc/Krfb to share your desktop over Telepathy
> tubes. I have also been working with Sebastian Trueg (of Nepomuk) and
> Marco Barisione and Danielle Madeley (both of Gnome) to sort out
> ontologies for building meta-contacts with Nepomuk/Tracker in a way
> that will be both cross-desktop compatible and also inter-application
> compatible within KDE. I'll be attending the Nepomuk Workshop [3] to
> finish implementing this in November, if anyone else is particularly
> interested in this, then do come along too :)
> 

How does the Nepomuk stuff fit in if we store contact details (include contact 
to metacontact inclusion) in Akonadi? 

I'm interested in this, but I won't be going to the workshop though. I have no 
time budget for travel.

> So, in conclusion, I'd be very keen to contribute to make Kopete
> "KDE's Empathy" :).
> 
> I hope this provides some useful context. I'll now follow up to some
> of the other posts already in this thread.
> 
> 
> Cheers,
> 
> George
> 
-- 
Matt


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: [kopete-devel] Kopete 1.0 and beyond

[Matt Rogers]

On Friday 02 October 2009 16:37:46 Aleix Pol wrote:
> On Thu, Oct 1, 2009 at 8:04 PM, Matt Rogers  wrote:
> > Hi,
> >
> > So, right now, the plan is to release Kopete 1.0 with KDE 4.4. If anybody
> > thinks that this shouldn't be done, then please speak up now so we can
> > change
> > the plan. :)
> >
> > For beyond Kopete 1.0, my current plan is to morph Kopete into the KDE
> > equivalent of GNOME's Empathy. This means converting Kopete to Telepathy.
> > As
> > part of this conversion, I also would like to make use of the various
> > other kde4 technologies like akonadi, etc. I also want to resurrect
> > Decibel in the
> > form of various Kopete components that are available throughout the whole
> > KDE
> > stack for various purposes.
> >
> > So the whole point of writing this email is to solicit feedback. So,
> > feedback
> > please! :)
> > --
> > Matt
> >
> > ___
> > kopete-devel mailing list
> > kopete-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/kopete-devel
> 
> I don't want to break the party but... isn't Decibel dead already? maybe we
> should pick a project that's already alive and with some kind of proof that
> works.

Sure, Decibel as it currently is today is dead. Parts of kopete, along with 
some things in playground/network would most likely become the "new" Decibel.

> Also... this might be quite some work, shouldn't we try to get it done
> before announcing it?
> 

I'm not announcing anything other than my own plans and trying to get input, 
feedback, etc. on whether people think this is a good idea and want to help or 
if I'm just going to be wasting my time. :)

> Well anyway, good luck with it :) I think that using telepathy would be a
> big step forward anyway. ^^
> Aleix
> 

-- 
Matt


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: [kopete-devel] using KTcpSocket in Kopete

[Matt Rogers]

On Friday 02 October 2009 07:07:29 Will Stephenson wrote:
> Hi
> 
> One of our security guys looked at Kopete a long time ago and realised it
> doesn't consistently verify SSL certs, warn the user if they are invalid,
>  or allow a user to set an acceptance policy.  This counts as a security
>  hole.
> 
> I quickly grepped through Kopete trunk and saw it is using QTcpSocket and
> QSslSocket.  Would there be any resistance to porting protocols to
>  KTcpSocket? Having one socket class throughout would allow us to use a
>  shared common set of CA certs and certificate policy.
> 
> Will


No objections. If you could even port the cases that still use 
K3BufferedSocket, that would be awesome.
-- 
Matt


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: [kopete-devel] Kopete 1.0 and beyond

[Matt Rogers]

On Friday 02 October 2009 06:43:34 Will Stephenson wrote:
> On Friday 02 October 2009 05:04:31 Matt Rogers wrote:
> > So, right now, the plan is to release Kopete 1.0 with KDE 4.4. If anybody
> > thinks that this shouldn't be done, then please speak up now so we can
> >  change the plan. :)
> >
> > For beyond Kopete 1.0, my current plan is to morph Kopete into the KDE
> > equivalent of GNOME's Empathy. This means converting Kopete to Telepathy.
> >  As part of this conversion, I also would like to make use of the various
> >  other kde4 technologies like akonadi, etc. I also want to resurrect
> >  Decibel in the form of various Kopete components that are available
> >  throughout the whole KDE stack for various purposes.
> >
> > So the whole point of writing this email is to solicit feedback. So,
> >  feedback please! :)
> 
> Strong agreement.  Kopete should organise an ev-funded sprint for the
>  morphing planning (and you should get a passport, hint hint).
> 
> Will

Well, you have a passport, right? :P 
-- 
Matt


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: [kopete-devel] Fwd: Kopete shows user name in chat

[Matt Rogers]

Hi,

I agree. This is not a security issue. I don't even agree that this is a 
privacy issue. If a user doesn't like the fact that their real name is shown 
in our chat client, then they should not enter a real name when using IRC. If 
your argument would apply to other IM protocols, our use of a user's real name 
that they provided to the IM service would also be an issue. However, it is 
not an issue for other IM services (we've received no complaints at least), so 
I see no reason to treat IRC any differently. Also note that we don't ship an 
IRC plugin in the KDE4 version of Kopete, so I would imagine that a great deal 
of people have quit using Kopete for IRC anyways.

Your privacy concerns are appreciated. However, the Kopete development team 
will not likely make any changes to address this complaint.

Thanks
--
Matt

On Thursday 01 October 2009 11:58:30 David Faure wrote:
> Hello,
> 
> I don't think this is a "security" issue, rather a privacy issue,
> so there's no reason to keep it undisclosed, all irc users know about whois
> already. For this reason I'm forwarding your email to the kopete
>  development mailing-list, for the kopete developers to answer it and/or
>  fix kopete if necessary.
> 
> David.
> 
> --  Forwarded Message  --
> 
> Subject: Kopete shows user name in chat
> Date: Wednesday 18 March 2009
> From: T P D 
> To: secur...@kde.org
> Cc:
> 
> Kopete by default shows the user's account name in IRC chat as the
> user's "Full Name".
> 
> No warning is given to users that their account names will be shown to
> anyone performing an IRC /whois command.
> 
> While it appears possible to override this behavior, it's not intuitive,
> as the value labeled "Full Name" is modified by changing a setting
> labeled "Real Name".
> 
> Even worse Kopete presumably has added code to access the account name
> when no "Real Name" is given; that is, someone actually affirmatively
> thought this behavior was a "Good Thing". This too is counter-intuitive:
> a setting left blank should not, without warning, result in transmitting
> display sensitive user information. Blank implies "show nothing", not
> "show my actual name".
> 
> This is quite simply, a security hole, as much as any buffer overrun.
> Worse, a security hole someone purposely added.
> 
> Did no one, during requirements gathering, code writing, or code review
> think that the reason people use nicks in IRC is because they don't wish
> to show their real names? Or that those wishing to reveal their real
> name should have to explicitly do so?
> 
> 
> For me, knowing that someone knowingly and affirmatively coded this
> calls into question the judgment of the entire KDE team.
> 
> 
> ---
> 

-- 
Matt


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

[kopete-devel] Kopete 1.0 and beyond

[Matt Rogers]

Hi,

So, right now, the plan is to release Kopete 1.0 with KDE 4.4. If anybody 
thinks that this shouldn't be done, then please speak up now so we can change 
the plan. :)

For beyond Kopete 1.0, my current plan is to morph Kopete into the KDE 
equivalent of GNOME's Empathy. This means converting Kopete to Telepathy. As 
part of this conversion, I also would like to make use of the various other 
kde4 technologies like akonadi, etc. I also want to resurrect Decibel in the 
form of various Kopete components that are available throughout the whole KDE 
stack for various purposes.

So the whole point of writing this email is to solicit feedback. So, feedback 
please! :)
-- 
Matt


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: [kopete-devel] How to unset an account mood in Kopete 0.70.90

[Matt Rogers]

On Wednesday 30 September 2009 07:17:57 Romain wrote:
> Hi,
> 
> I've set a mood for myself on a jabber account, but now would like to
>  remove it.
> It seems clicking "None" does not work, at least not immediately since
>  other colleagues still see the mood with different clients (Gajim,
>  Pidgin..; all linux laptops).
> 
> Should the change be immediate ?
> 
> I've seen in protocols/jabber/jabberaccount.cpp (1109-1122) this snippet of
> code :
> 
> void JabberAccount::slotSetMood()
> {
> KAction *action = (KAction *)sender();
> Mood::Type type = (Mood::Type)action->data().toInt();
> if(type == Mood::None)
> {
> }
> else
> {
> PubSubItem psi("current",
> Mood(type).toXml(*client()->client()->rootTask()->doc()));
> JT_PubSubPublish *task = new
> JT_PubSubPublish(client()->client()->rootTask(), QString("
> http://jabber.org/protocol/mood";), psi);
> task->go(true);
> }
> }
> 
> 
> If nothing is done when Mood is None, how is one supposed to reset a mood
> back to None once one has been chosen ?
> 
> Many thanks,
> Romain.
> 

I think you've found the answer. :) Could you provide a patch to fix this, or 
at the very least file a bug (if there isn't one already?)
-- 
Matt


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: [kopete-devel] Cleaning up Kopete's icons?

[Matt Rogers]

On Sunday 20 September 2009 16:19:08 Raphael Kubo da Costa wrote:
> Hi there,
> 
> After the KNotificationIcon commits, I get that "?" icon instead of
> Kopete's when I'm online. That prompted me to look at what was wrong
> and, while doing that, I found some old icons (the ones with the "ox"
> prefix) in the kopete/ directory that don't seem to be used for quite
> some time. There are some icons in the icons/ directory that fall into
> the same case.
> 
> Is there any specific reason they're still there? Can they be deleted?
> 
> Still on this matter, the KNotificatonsItem commit references some
> icons that simply don't exist, such as "kopete-offline" (previously
> the gray icon was generated on the fly on top of the default icon) and
> "user-connecting". I was thinking of creating creating that gray icon,
> and maybe using it for the connecting status as it used to happen.
> Last but not least, in KopeteSystemTray::slotReevaluateAccountStates
> it seems to need a call to setIconByName again in the
> Kopete::OnlineStatus::Online case, but I suppose it shouldn't.

go ahead and make the cleanups
-- 
Matt


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: [kopete-devel] Enable OTR plugin by default?

[Matt Rogers]

On Sunday 27 September 2009 14:26:55 Michael Zanetti wrote:
> Hello everyone,
> 
> We have 2 whishes in bko [1][2] for enabling the OTR plugin by default in
> kopete. As I use it anyways I would obviously support this.
> 
> What is your opinion? Am I allowed to enable it or should I close the
>  whishes as WONTFIX?
> 
> Cheers,
> Michael
> 
> [1] https://bugs.kde.org/show_bug.cgi?id=188121
> [2] https://bugs.kde.org/show_bug.cgi?id=202899
> 

If enabled by default, what sort of ramifications does this have for the 
"normal" user (aka one that doesn't use OTR)
-- 
Matt


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: [kopete-devel] Review Request: Replaced kopete systray with NotificationItem

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1635/#review2396
---

Ship it!


looks fine. please commit. thanks for the port!

- Matt


On 2009-09-18 19:50:08, Davide Bettio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1635/
> ---
> 
> (Updated 2009-09-18 19:50:08)
> 
> 
> Review request for Kopete and Plasma.
> 
> 
> Summary
> ---
> 
> This patch replaces KSysTray with KNotificationItem.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdenetwork/kopete/kopete/kopetewindow.cpp 1025366 
>   /trunk/KDE/kdenetwork/kopete/kopete/systemtray.h 1025366 
>   /trunk/KDE/kdenetwork/kopete/kopete/systemtray.cpp 1025366 
> 
> Diff: http://reviewboard.kde.org/r/1635/diff
> 
> 
> Testing
> ---
> 
> I've been using kopete with this patch for some hours...
> 
> 
> Thanks,
> 
> Davide
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [kopete-devel] Review Request: Ability to show individuals contacts even if offline

[Matt Rogers]

> On None, Matt Rogers wrote:
> > Is this any way that this can be done through the use of a contact property 
> > rather than adding API? Kopete 1.0 is coming soon, and so I'm basically 
> > treating the API as frozen unless there are critical concerns around it.
> > 
> > Also, there isn't a contact list version bump to go with the added XML tag, 
> > which would only be needed if we do not switch to using a contact property.
> 
> Bruno Bigras wrote:
> Thanks for the fast response!
> 
> Do you have any sample of something already using a "contact property"? I 
> don't know much about Kopete's structure, I guess you mean without touching 
> libkopete.

the api for the properties is setProperty() and property() in Kopete::Contact, 
at least that's how you would use them. You'd need something like what's in 
protocols/oscar/oscarprotocol.h and protocols/oscar/oscarprotocol.cpp to 
declare the new property. I'm not sure exactly where you'd declare the new 
property at, so that it's available by all, but that's the basics of it.


- Matt


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1619/#review2379
---


On 2009-09-16 04:21:32, Bruno Bigras wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1619/
> ---
> 
> (Updated 2009-09-16 04:21:32)
> 
> 
> Review request for Kopete.
> 
> 
> Summary
> ---
> 
> Add the possibility to always show a contact even if offline like in Pidgin. 
> It makes sending messages to "always invisible" friends much easier when 
> having many contacts.
> 
> For now, it adds a "always-visible" tag in contactlist.xml.
> 
>  contactId="{ef566dff-e12c-41e6-8390-c0a4319e}" >
> 
> false
> 
> 
> This addresses bug 98757.
> https://bugs.kde.org/show_bug.cgi?id=98757
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdenetwork/kopete/kopete/contactlist/contactlistproxymodel.cpp 
> 1024049 
>   /trunk/KDE/kdenetwork/kopete/kopete/contactlist/contactlisttreemodel.cpp 
> 1024049 
>   /trunk/KDE/kdenetwork/kopete/kopete/contactlist/kopeteitembase.h 1024049 
>   /trunk/KDE/kdenetwork/kopete/kopete/contactlist/kopetelviprops.h 1024049 
>   /trunk/KDE/kdenetwork/kopete/kopete/contactlist/kopetelviprops.cpp 1024049 
>   /trunk/KDE/kdenetwork/kopete/kopete/contactlist/kopetemetalvipropswidget.ui 
> 1024049 
>   /trunk/KDE/kdenetwork/kopete/libkopete/contactlist/xmlcontactstorage.cpp 
> 1024049 
>   /trunk/KDE/kdenetwork/kopete/libkopete/kopetecontact.h 1024049 
>   /trunk/KDE/kdenetwork/kopete/libkopete/kopetecontact.cpp 1024049 
>   /trunk/KDE/kdenetwork/kopete/libkopete/kopetemetacontact.h 1024049 
>   /trunk/KDE/kdenetwork/kopete/libkopete/kopetemetacontact.cpp 1024049 
>   /trunk/KDE/kdenetwork/kopete/libkopete/kopetemetacontact_p.h 1024049 
> 
> Diff: http://reviewboard.kde.org/r/1619/diff
> 
> 
> Testing
> ---
> 
> 
> Screenshots
> ---
> 
> 
>   http://reviewboard.kde.org/r/1619/s/205/
> 
> 
> Thanks,
> 
> Bruno
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [kopete-devel] On review board Was: Review Request: GaduGadu import/export contacts list fix

[Matt Rogers]

On Monday 14 September 2009 16:00:13 Aleix Pol wrote:
> Review board is great but I wonder if we should center so much on the
> whitespaces on the review. I mean, yes they're ugly and bad, but when
> someone sends his patch, he wants people to be focused on the actual
>  work...
> 
> :/ no?
> 

I won't commit a patch that has whitespace errors, so yes, for the first 
review, I'm going to make sure I knock out the low hanging fruit. This is my 
approach to patch review. Sorry you don't like it

In this case, there's nothing else wrong with the patch other than the 
whitespace, so once I look over it again to make sure it still looks ok, then 
I'll commit it. 

Also, please don't top post on mailing lists.
--
Matt

> On Mon, Sep 14, 2009 at 1:01 PM, Jakub Grandys  
wrote:
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > http://reviewboard.kde.org/r/1604/
> > ---
> >
> > (Updated 2009-09-14 20:01:56.874976)
> >
> >
> > Review request for Kopete.
> >
> >
> > Changes
> > ---
> >
> > Whitespaces fixed and small bug - default value for export on change 
and
> > ignore anons were swaped.
> >
> >
> > Summary
> > ---
> >
> > Complete fix for importing and exporting contacts list. All known to me
> > related bugs are fixed:
> > - improper generation of exported list
> > - bad handling of messed up lists
> > - ability to add contact with empty, nonnumerical or UID=0
> > - with empty contacts list you wouldn't receive ANY message or contacts
> > list from server
> >
> > New features:
> > - delete contacts list
> > - manual import from account's action menu
> > - config options for both import on login in and export contacts on any
> > change to contacts list to server (currently not configurable, default is
> > same as now)
> > - revoked action menu (see screenshots)
> >
> >
> > This addresses bugs 184696, 204282 and 204285.
> >https://bugs.kde.org/show_bug.cgi?id=184696
> >https://bugs.kde.org/show_bug.cgi?id=204282
> >https://bugs.kde.org/show_bug.cgi?id=204285
> >
> >
> > Diffs (updated)
> > -
> >
> >  /trunk/KDE/kdenetwork/kopete/kopete/kopete.notifyrc 1023241
> >  /trunk/KDE/kdenetwork/kopete/protocols/gadu/gaduaccount.h 1023241
> >  /trunk/KDE/kdenetwork/kopete/protocols/gadu/gaduaccount.cpp 
1023241
> >  /trunk/KDE/kdenetwork/kopete/protocols/gadu/gaducontactlist.cpp 
1023241
> >  /trunk/KDE/kdenetwork/kopete/protocols/gadu/gadueditaccount.cpp 
1023241
> >  /trunk/KDE/kdenetwork/kopete/protocols/gadu/gadusession.h 1023241
> >  /trunk/KDE/kdenetwork/kopete/protocols/gadu/gadusession.cpp 1023241
> >  /trunk/KDE/kdenetwork/kopete/protocols/gadu/ui/gadueditaccountui.ui
> > 1023241
> >
> > Diff: http://reviewboard.kde.org/r/1604/diff
> >
> >
> > Testing
> > ---
> >
> > Works for me ;)
> >
> >
> > Screenshots
> > ---
> >
> > New ActionMenu
> >  http://reviewboard.kde.org/r/1604/s/202/
> > Old ActionMenu
> >  http://reviewboard.kde.org/r/1604/s/204/
> >
> >
> > Thanks,
> >
> > Jakub
> >
> > ___
> > kopete-devel mailing list
> > kopete-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/kopete-devel
> 

-- 
Matt


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: [kopete-devel] Review Request: GaduGadu import/export contacts list fix

[Matt Rogers]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1604/#review2359
---


Do we need the menu options to explicitly export and import contacts from the 
server? Almost all of the other protocols just do this by default already. What 
keeps Gadu from doing the same thing here?


/trunk/KDE/kdenetwork/kopete/protocols/gadu/gaduaccount.cpp


the red indicator here means there's extra whitespace. please remove it.



/trunk/KDE/kdenetwork/kopete/protocols/gadu/gaduaccount.cpp


fix whitespace here too.



/trunk/KDE/kdenetwork/kopete/protocols/gadu/gaduaccount.cpp


whitespace



/trunk/KDE/kdenetwork/kopete/protocols/gadu/gaduaccount.cpp


whitespace



/trunk/KDE/kdenetwork/kopete/protocols/gadu/gaduaccount.cpp


whitespace



/trunk/KDE/kdenetwork/kopete/protocols/gadu/gaduaccount.cpp


whitespace



/trunk/KDE/kdenetwork/kopete/protocols/gadu/gaduaccount.cpp


whitespace



/trunk/KDE/kdenetwork/kopete/protocols/gadu/gaduaccount.cpp


whitespace



/trunk/KDE/kdenetwork/kopete/protocols/gadu/gadueditaccount.cpp


whitespace


- Matt


On 2009-09-14 12:53:19, Jakub Grandys wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1604/
> ---
> 
> (Updated 2009-09-14 12:53:19)
> 
> 
> Review request for Kopete.
> 
> 
> Summary
> ---
> 
> Complete fix for importing and exporting contacts list. All known to me 
> related bugs are fixed:
> - improper generation of exported list
> - bad handling of messed up lists
> - ability to add contact with empty, nonnumerical or UID=0
> - with empty contacts list you wouldn't receive ANY message or contacts list 
> from server
> 
> New features:
> - delete contacts list
> - manual import from account's action menu
> - config options for both import on login in and export contacts on any 
> change to contacts list to server (currently not configurable, default is 
> same as now)
> - revoked action menu (see screenshots)
> 
> 
> This addresses bugs 184696, 204282 and 204285.
> https://bugs.kde.org/show_bug.cgi?id=184696
> https://bugs.kde.org/show_bug.cgi?id=204282
> https://bugs.kde.org/show_bug.cgi?id=204285
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdenetwork/kopete/kopete/kopete.notifyrc 1023241 
>   /trunk/KDE/kdenetwork/kopete/protocols/gadu/gaduaccount.h 1023241 
>   /trunk/KDE/kdenetwork/kopete/protocols/gadu/gaduaccount.cpp 1023241 
>   /trunk/KDE/kdenetwork/kopete/protocols/gadu/gaducontactlist.cpp 1023241 
>   /trunk/KDE/kdenetwork/kopete/protocols/gadu/gadueditaccount.cpp 1023241 
>   /trunk/KDE/kdenetwork/kopete/protocols/gadu/gadusession.h 1023241 
>   /trunk/KDE/kdenetwork/kopete/protocols/gadu/gadusession.cpp 1023241 
>   /trunk/KDE/kdenetwork/kopete/protocols/gadu/ui/gadueditaccountui.ui 1023241 
> 
> Diff: http://reviewboard.kde.org/r/1604/diff
> 
> 
> Testing
> ---
> 
> Works for me ;)
> 
> 
> Screenshots
> ---
> 
> New ActionMenu
>   http://reviewboard.kde.org/r/1604/s/202/
> Old ActionMenu
>   http://reviewboard.kde.org/r/1604/s/204/
> 
> 
> Thanks,
> 
> Jakub
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

Re: [kopete-devel] Review Request: Make building skypebuttons optional

[Matt Rogers]

> On 2009-09-12 02:21:26, Matt Rogers wrote:
> > Commit!
> 
> Raphael Kubo da Costa wrote:
> Done. Should this be backported?

if skypebuttons is present in the 4.3 branch, then yes.


- Matt


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1574/#review2316
---


On 2009-09-12 01:42:55, Raphael Kubo da Costa wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1574/
> ---
> 
> (Updated 2009-09-12 01:42:55)
> 
> 
> Review request for Kopete.
> 
> 
> Summary
> ---
> 
> Currently, using Firefox 3.5 with the skypebuttons plugin crashes the browser 
> on FreeBSD with the following error:
> 
> terminate called after throwing an instance of 
> '__gnu_cxx::__concurrence_lock_error'
>   what():  __gnu_cxx::__concurrence_lock_error
>   
> Abort trap (core dumped)
> 
> Until the cause of the problem is properly figured out, not building the 
> directory by passing -DBUILD_skypebuttons=OFF is a solution.
> 
> Furthermore, looking at the plugin's CMakeLists.txt it always assumes Firefox 
> (or something similar) is installed, which isn't always the case.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdenetwork/kopete/protocols/skype/CMakeLists.txt 1022549 
> 
> Diff: http://reviewboard.kde.org/r/1574/diff
> 
> 
> Testing
> ---
> 
> By not building and installing the plugin, Firefox stops crashing on every 
> startup.
> 
> 
> Thanks,
> 
> Raphael
> 
>

___
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel