{5} Selected Tickets by Developer (Full Description) (17 matches)

Being able to use your webcam is a highly requested feature, in fact a reason for users to ignore KMess at this moment. Therefore I'd like to have this feature in the next version.

There is libmimic for the video frames part. It's also said some webcam transfers (guess 2-way) happen over RTP.

If KMess send an INVITE for a picture transfer, WLM may send an INVITE back to initiate a direct connection. KMess rejects these invitations currently, since it breaks the state machine based on the isUserStartedApp() value.

Steps to fix this:

• Allow these messages if the user didn't initiate the session.
• Fix all state problems by this change.
• The data preparation ACK should be sent after the connection is established or assumed to be failed.

The openSUSE build service has a problem to compile KMess. This should be fixed. URL is: https://build.opensuse.org/project/show?project=home%3Avpilo

(this needs a Build Service account).

Useful links for Build Service:

• http://en.opensuse.org/Build_Service/Deb_builds
• http://en.opensuse.org/Build_Service/cross_distribution_package_how_to
• http://en.opensuse.org/Build_Service/Tips_and_Tricks#List_available_packages_in_a_distro

The current KMess server protocol is based on MSNP12 (MSN Messenger 7.5). To make use of new features like offline chat conversations we need to upgrade the server protocol.

Of special attention:

• proper XML parsing
• contact list soap handling

This one is not planned for 2.0, because it could potentially delay the release a lot.

After that we could work on:

• msn spaces integration
• shared folder support
• yahoo im support through msn

Ticket based on [this forum topic http://kmess.org/board/viewtopic.php?f=2&t=3140]

It has been asked on the forum if we can implement an option to customize how the Now Playing info is displayed.

An option like this should be kept in some Advanced dialog... not clearly in the sun.

As of KDE 4.1, there is a KCabinet class to extract .cab files. It would be nice if we can use this class. It will remove the dependency on cabextract.

I think I've found a way to merge all popups and sounds settings. That would be a lot easier than having to configure notifications from two very different places (account settings and Configure Notifications dialog).

Since recently I've moved all KNotify code to the kmess/notification/ classes, it would even be a lot simpler to implement.

• First the user sets the KNotify dialog to display messageboxes, passive or not we can avoid to care. Of course we would set the KNotify defaults accordingly to our current popup balloons default settings.
• Then, in the Notification* classes, we 'override' the KNotifyClient::event() call:
  • Collect all settings for the event we need to send, by using KNotifyClient::getPresentation() and KNotifyClient::getFile()
  • Check from the presentation bitfields if the messagebox presentation mode is on.
  • Delete from the presentation bitfields the Messagebox and Passivepopup modes if set.
  • Call KNotifyClient::userEvent() to send the original event with the usual message, sound, presentation etc but of course without the messagebox presentation modes.
  • If the messagebox presentation mode was set, popup our custom balloon.

KMess focuses the 1.5 release on receiving everything: but that, too, can be too much.

Sometimes it happens to chat with a contact whose custom emoticons have been added completely unknowingly. The shortcuts for their emoticons often are a single character, like "d", "k", or ".", and more often than not they're HUGE, so your chat becomes almost impossible to follow without proper skills at resolving rebuses.

KMess should allow the user to not only stop translating new custom emoticons - and winks - but also to remove received winks and emoticons, replacing the former with the original shortcut text, and the latter with just a text link.

This should be possible via a chat window menu option and via two settings in the contact properties.

The options could be an Action Menu:

• Allow custom emoticons
• Disable annoying custom emoticons
• Disable all custom emoticons

with "annoying" meaning: emoticons which shortcut is a single character, and emoticons which don't have special characters in the shortcut. Not sure about how to explain this meaning to the user in a menu, though :P

For one on one chats, the settings changed via menu item should be remembered in the contact's properties. For group chats, the option should not be associated to the involved contacts, but should only be set for the duration of the chat (i.e. when the group chat is closed, the setting is not saved anywhere).