KTp: Difference between revisions
Grundleborg (talk | contribs) m moved Scratchpad/KopeteTelepathy to Telepathy: moving this page out of the scratchpad to its new home. |
Update page to transclude sections from subpages rather than simple link to them |
||
(57 intermediate revisions by 10 users not shown) | |||
Line 1: | Line 1: | ||
{{Note|This page has old content. See page history.}} | |||
== | = KDE Telepathy - Real-Time Communication and Collaboration = | ||
{{:KTp/Header}} | |||
== Getting Involved == | |||
{{:KTp/Getting Involved}} | |||
== Development == | |||
{{:KTp/Developers}} | |||
== Testing == | |||
{{:KTp/Testers}} | |||
== | == Packaging == | ||
{{:KTp/Packaging_Guide}} | |||
== See also == | |||
[http://community.kde.org/index.php?title=Special%3APrefixIndex&prefix=KTp&namespace=0 Index of KDE Community Wiki pages about Telepathy] | |||
== | |||
Latest revision as of 22:28, 26 February 2024
KDE Telepathy - Real-Time Communication and Collaboration
Getting Involved
Who can be a contributor?
This project needs coders, designers, artists, testers, documentation writers. To help out, get in touch, tell us how you're interested in helping.
Contacting the developers
IRC
- The #kde-telepathy IRC channel on Libera.Chat (web client)
Setup
- Main page: Instructions
Before you start playing with/hacking on the Telepathy integration stuff, you need to have the latest version compiled and working.
First steps
The best way to get involved is to start working on some "junior jobs". These are small bugs or features that exist in our applications that are a good way to get to learn the code, and learn our workflow process.
A list of junior jobs can be found here.
If you want to work on any of those, get in touch!
Recommended Reading
- Telepathy Wiki
- Telepathy Specifications
- Telepathy Qt Documentation
- The Architecture of Open Source Applications: Telepathy
- KDE API documentation
- GitHub Docs: Getting Started with Git
Workflow
If you want to work on a feature, start by cloning the git repository from the KDE Invent server. Then create a new branch in the cloned directory and start working there. Try to keep your commits atomic (small and meaningful). Once you are finished working on a single bug or feature, push the branch in your cloned repository back to the KDE Invent server (under your own account) and then use the web interface to create a Merge Request back to the official repository before asking someone on the developer team to review it. Once it is reviewed, you may be asked to make further changes, but once all concerns are addressed it will be merged into the codebase.
External links
- Telepathy home page (FreeDesktop.org)
Development
Introduction
Real-time communication has traditionally been a detached feature of desktop computing, provided via standalone instant messaging clients with poor integration into the desktop experience. One of the primary goals of the KDE 4 series is to tighten integration between different components of the environment. The KDE Telepathy (hereafter "KTp") project aims to tackle just this.
Our aims are:
- To integrate real-time communication deeply into the KDE workspaces and applications
- To provide an infrastructure to aid development of collaborative features for KDE applications.
If you find these goals appealing, why not consider getting involved? C++ programming is not a requirement.
Technical information
- The RTCC project uses the cross-desktop Telepathy Framework as the basis for our work.
- We should try and reuse code from Kopete and other existing code wherever possible. However, this should be balanced with the need to refactor/rewrite where appropriate, to keep the new code true to Telepathy idioms.
Frequently asked questions
- See also: Gkiagia’s Blog: What is Telepathy-KDE?
You can find a list of answers to frequently asked questions here: FAQ.
The plan
- Build components equivalent to a traditional IM application, using Kopete code as much as possible, and integrating with other pillars of KDE, where appropriate.
- Add advanced Telepathy features such as voice/video.
- Build components and convenience classes to enable real-time communication and collaboration features in any KDE SC app that wants them.
Current ongoing large tasks
- Active KTp tasks
- KTp icons
- KDE Connect
- KPeople
- Metacontacts
- Model roles
- New Call UI
- Proper library
- Text UI QML
- KTp Video Call UI
Workflow
- Main page: Getting involved § Workflow
Use of milestones
We're trialing a clever use of milestones suggested by Jeroen van Meeuwen.
How it works
All bugs by default have the milestone future
to indicate that "we'll do it at some point." If we have no intention of doing it, it should not be in Bugzilla.
For each (upcoming) release there is a version-next, such as 0.4-next
. This contains everything we want fixed in the 0.4.x series.
As we approach each release, we create a milestone for its version number (following the example above, the milestone would be 0.4.0
). Any bug we really want fixed before we can finalize that release then has its milestone changed from 0.4-next
to 0.4.0
. Any bug that we are happy to release 0.4.0 with, but still want fixed within the lifespan of the 0.4.x series remains in 0.4-next
. This process then gets repeated for every release.
Summary
0.5.0
= really aiming to fix this in 0.5.00.5.1
= really aiming to fix this 0.5.10.5-next
= aim to fix this at some point in the 0.5 series.
What should have a milestone
Bugs that we know how to fix, have a solid plan for resolving and have the resources to execute. Assigning everything to "0.4.0" when there's no way we can get it done will help no one.
It should remain a small list of high-priority tasks, such that developers can see what is important.
What bugs should I prioritize working on?
Anything tagged for the next release. In the case of the 0.4.0
milestone, then anything in 0.4-next
, and finally anything in future
.
Obviously, being free software, you're free to work on whatever the hell you want.
Naming policy
- Main page: Naming Policy
Events
Testing
Getting started
- Main page: KTp: Getting started
Before you start playing with or testing the latest KDE Telepathy, you need to have the latest version compiled and working.
Common questions
- Main page: KTp FAQ
Reporting bugs
Report bugs at Bugzilla.
Packaging
Packaging KDE-Telepathy is complicated for two reasons:
- Due to the modular nature of Telepathy, there are several distinct components, each in separate Git repositories.
- There are large numbers of runtime inter-dependencies to worry about.
This page attempts to ease packaging KDE-Telepathy in a useful way by explaining these issues.
Upstream packages
Several upstream packages are essential for KDE-Telepathy to work. These are the ones encountered as dependencies in a normal compilation:
telepathy-qt
>= LATEST (currently 0.9.8), Build and Runtime Dependencytelepathy-mission-control
>= 5.7.9 (currently 5.16.6), Runtime DependencyQJson
Build Dependency forktp-auth-handler
QtGStreamer
Build Dependency forktp-call-ui
telepathy-logger
Build and Runtime Dependency fortelepathy-logger-qt
kdelibs
>= 4.7.0 (currently 4.14.0), Build and Runtime Dependency
The IM networks that KDE-Telepathy can connect to are determined by which Telepathy Connection Managers are installed. These are runtime-only dependencies, but which ones are installed will decide what IM networks KDE-Telepathy supports. The following are the ones we recommend—whether they are installed optionally or required is, of course, up to you.
telepathy-gabble
>= 0.13.7 (currently 0.18.4), for Jabber/XMPP support, including Google Talk and Facebook, might very probably crash with earlier versionstelepathy-haze
for all the other protocols, as supported bylibpurple
telepathy-farstream
should be compiled beforetelepathy-qt
for compilation ofktp-call-ui
to proceed
KDE-Telepathy packages
The different components of KDE-Telepathy are housed in separate Git repositories on KDE Invent's Network group. Some of these components are currently recommended to use, while others are not yet ready to be installed by users.
Ready components
These components have reached a level of maturity where they are interesting to users. We recommend providing these components at the current time.
Name | Description | Dependencies |
---|---|---|
ktp-common-internals
|
Internal library | telepathy-qt
|
ktp-accounts-kcm
|
Account management KCM | ktp-common-internals
|
ktp-approver
|
KDED module that shows a notification when somebody starts a chat with you | ktp-common-internals
|
ktp-text-ui
|
Text chat application | ktp-common-internals
|
ktp-contact-list
|
Contact list application – also provides icons and other data files that are shared among the other applications | ktp-common-internals
|
ktp-kded-module
|
Workspace integration module – provides several plugins like auto-away, the infamous 'Now listening to...' and also an error handler (important!!) | ktp-common-internals
|
ktp-desktop-applets
|
Plasma widgets – provides a presence applet which acts as the central system tray icon of traditional IM clients, a simplified contact list, an applet which represents a single contact and can be used to trigger actions like 'Send mail' and 'Initiate conversation', … | ktp-common-internals
|
ktp-filetransfer-handler
|
Background application for handling file transfers | ktp-common-internals
|
ktp-auth-handler
|
Background application for handling passwords and SSL/TLS certificates | ktp-common-internals
|
ktp-send-file
|
Dolphin/Konqueror context menu plugin for easily sending files to contacts | ktp-common-internals ktp-filetransfer-handler (at runtime)
|
ktp-call-ui
|
Voice and video chat with contacts | ktp-common-internals
|
ktp-contact-runner
|
Show contacts in KRunner | ktp-common-internals
|
telepathy-logger-qt
|
Provides support for loading saved message logs | ktp-common-internals telepathy-logger QtGLib (from QtGStreamer)
|
- Required components for basic functionality:
- Highly recommended components (should be installed by default):
- Optional components:
Experimental components
Several other components are under development, however unless they are listed above, we do not recommend packaging them yet. This is because they are subject to major changes/removal at any time, and are not ready for end users.
Note about accounts-kcm-plugins
Our 0.1.0
release had an extra package called telepathy-kde-accounts-kcm-plugins
. These plugins have now been merged into the main telepathy-kde-accounts-kcm
package and are no longer shipped separately.
Release tarballs
The latest release is 0.9.0
. Tarballs can be found at the KDE FTP mirrors.
Distributions
Here is a list of known packaging efforts for various distributions. If you are also doing packages for a distribution, please add your information here.