Development/FAQs/General FAQ/pt-br

Desenvolvimento/FAQs/FAQ geral

Languages: عربي | Asturianu | Català | Česky | Kaszëbsczi | Dansk | Deutsch | English | Esperanto | Español | Eesti | فارسی | Suomi | Français | Galego | Italiano | 日本語 | 한국어 | Norwegian | Polski | Português Brasileiro | Română | Русский | Svenska | Slovenčina | Slovenščina | српски | Türkçe | Tiếng Việt | Українська | 简体中文 | 繁體中文

Eu quero começar uma nova aplicação. O que você recomenda?

Todos concordamos que existem muitas aplicações para o KDE que precisam ser escritas. Mas também há muitas aplicações existentes no KDE que necessitam sua ajuda.

Para ver as áreas que precisam ajuda, veja esta página.

Antes de começar uma nova aplicação, é uma boa idéia verificar o KDE-Apps.org em busca de projetos existentes e também perguntar na lista de emails kde-devel se alguém já está trabalhando em algo similar.

Sou um desenvolvedor, como posso contribuir com o KDE?

KOffice e KDevelop, apesar de muito aclamados, possuem muito poucos desenvolvedores, então você pode verificar lá. Não é necessário ser um dos principais desevolvedores do KDE para ajudar. O KDE é muito modular, sendo possível melhorar uma área sem conhecer como o sistema completo funciona.

Você também pode perguntar na lista kde-devel por alguém precisando ajuda com algum aplicativo. Utilize a última versão do KDE e repare nas coisas necessárias. Um gerador de temas? Um editor de schema para o Konsole? Melhorar um jogo? Sempre há um pequeno recurso faltando. Vá e implemente-o!

Você é familiar ou sente-se atraído por alguma área específica? Verifique se alguma aplicação relacionada pode ser melhorada. Ou escreva uma nova. O KDE precisa de mais aplicações orientadas a não-geeks.

Eu não sou desenvolvedor, como posso ajudar?

Existem inúmeras tarefas que não exigem habilidades em programação. Escreva reviews de aplicativos para promover o KDE (veja a lista kde-promo), ajude o time de documentação (veja i18n.kde.org/doc), ajude os tradutores (veja i18n.kde.org), ajude a filtrar os bugs reportados (veja bugs.kde.org).

Onde encontro imagens de Konqi, o dragão?

The Konqi for some people SDK is at ftp.kde.org/pub/kde/devel/konqi_sdk.tar.bz2
It was posted to artist.kde.org before that site ceased to be updated.

Mais imagens estão disponíveis em KDE merchandise.

Qual é o nível exigido para contribuir com o KDE? O que devo aprender? O que devo ler?

Você deve conhecer C++. Leia os tutoriais do Qt e navegue por sua documentação para familiarizar-se com os recursos disponibilizados. Depois, leia os tutoriais do KDE e navegue por sua arquitetura e documentação. Ler o KDE Book também não machuca. No entanto, não é necessário conhecer toda a sua arquitetura para tornar-se um desenvolvedor KDE. É muito fácil utilizar nossas tecnologias, portanto concentre-se no que você realmente precisa, e o resto você vai aprendendo com o tempo. KDE TechBase e doc.qt.nokia.com (também disponível no seu $QTDIR/doc/html) são recursos inestimáveis, use-os. Por fim, navegue pelo código-fonte, olhe os diretórios com exemplos, veja como os outros codificam suas aplicações. Ler e escrever código é a melhor maneira de aprender.

Como obter o código do KDE dos repositórios git ou SVN?

Veja a seção "Compilando e Executando o KDE a partir do fonte" na página Primeiros passos

Posso acessar o fonte do KDE online?

Sim

• Navegue para http://websvn.kde.org/ e https://projects.kde.org/
• Procure dentro do código fonte em http://lxr.kde.org/search
• Navegue pelos documentos da API gerados pelo código em http://api.kde.org/

O que devo colocar dentro do meu .subversion/config?

[miscellany]
global-ignores = *.moc *.moc.cc *.moc.cpp config.log config.status \
config.cache *.gmo .deps .libs SunWS_cache *.lo *.la *.rpo *.la.closure \
*_la_closure.cpp *_la_closure.cc *_la_closure.cxx *.all_cc.cc *.all_cpp.cpp \
*.all_C.C *.all_cxx.cxx *_meta_unload.cc *_meta_unload.h *_meta_unload.cpp \
*_meta_unload.C *_meta_unload.cxx index.cache.bz2 .memdump Makefile.rules.in \
Makefile.calls.in Makefile.rules Makefile.calls autom4te.cache *.kidl \
*.o *.lo *.la #*# .*.rej *.rej *.pyc

E para fazer o svn diff ignorar espaços em branco, e imprimir os nomes das funções:

[helpers]
diff-cmd = /usr/local/bin/_svndiff

com o seguinte em /usr/local/bin/_svndiff:

#!/bin/sh
exec /usr/bin/diff -b -u -p "$@"

Não se esqueça de tornar /usr/local/bin/_svndiff executável.

Eu quero colocar meu aplicativo no KDE

Existem três requisitos:

• seu aplicativo deve compilar com a última versão do KDE (git master ou SVN trunk).
• seu aplicativo deve ser estável.
• seu aplicativo deve ser mantido. Você provavelmente receberá uma boa quantidade de relatos de problemas e outros pedidos, e as pessoas esperam que você conserte os problemas e implemente os pedidos que façam sentido.

Veja também a próxima questão.

É melhor desenvolver dentro ou fora do KDE?

As core developer Waldo Bastian explains in a copyrighted mail:

Being part of KDE means that you have to work together with others. Such cooperation brings along advantages but it also brings along responsibilities.

Algumas das vantagens são: seu código irá para todas as distros, outras pessoas podem arrumar seus problemas, você ganha traduções e documentação, e também toneladas de relatos de bugs.

Por outro lado, existem algumas desvantagens e responsabilidades: você terá que comunicar-se com outros desenvolvedores sobre seu trabalho, outras pessoas podem modificar seu código, você deverá respeitar os congelamentos pré-lançamento, você receberá toneladas de relatos de problemas, e as pessoas esperam que você arrume-os também (o que elas andam fumando?), elas esperam que você mantenha o código.

Você não pode escolher as vantagens e ignorar as responsabilidades que vêm com elas, é um pacote fechado. É tudo ou nada.

Em geral é o autor de um software quem decide colocar sua aplicação nos repositórios do KDE. Nós normalmente não colocamos nada no repositório, a menos que o autor assim decida. No outro sentido, se o autor prefere trabalhar sua aplicação em outro lugar, isso também é um direito seu. A menos que haja uma divisão entre o grupo de pessoas trabalhando na aplicação, não faz sentido dividir o desenvolvimento por esse motivo.

MAS... ao colocar seu código sob uma licença de código livre e no repositório do KDE, você dará ao mundo, assim como ao KDE em particular, o direito irrevogável de usar o seu código. E o KDE vai usar desse direito como for conveniente para proteger os interesses do KDE, mesmo que isso possa ir contra os desejos do próprio autor em algum momento.

É importante saber tudo isso, mas não se assuste. Normalmente as coisas funcionam muito bem. Em 5 anos, houve somente uma ocorrência de um desenvolvedor que colocou seu trabalho no KDE e depois quis tirá-lo.

Como obtenho permissão de escrita nos repositórios do KDE?

Leia o artigo completo em Contribua > Obtenha uma Conta de Colaborador KDE.

Go to [KDE Identity] , fill out the form and describe why you need write access. Make sure to specify your full name and e-mail address.

Please also include the name of your bugs.kde.org account, if non-existent please create one so that it can be given usual developer rights. Closing bugs.kde.org reports with keywords in commit comments only works if the email address of your KDE Identity and bugs.kde.org accounts match. You can change your bugs.kde.org address in the Bugzilla user settings.

Git requires use of an ssh key, and new accounts for SVN must also choose the svn+ssh protocol. Send a public ssh key (e.g. ~/.ssh/id_dsa.pub)

See also #How do I create a SSH key?

If you are contributing to an application that is not yours, it is a good idea to first submitting your coding as patches to the author and let him apply them. If the author is not maintaining his application, you might become the new maintainer...

Although there are few restrictions on repository commit rights, we expect you not to disrupt other developers' code without their consent. You must also respect the feature freezes of the release schedule (published on developer.kde.org)

A detailed list of rules you should follow when committing to KDE repositories are listed in the KDE Commit Policy.

My app is not stable but I would like to have it in KDE

As a first step, we can put it in playground, which is essentially "kde-alpha". Develop it there and when it is ready, request that your app to be moved to the appropriate KDE package or the extragear module.

I don't want to lose my SVN history.

This is no longer possible with Subversion. Maybe in the future, if the server is upgraded and allows that. Note that for git this is not an issue.

What is kdebindings?

It contains Qt bindings for Ruby, PHP, C# to use Qt classes with those langages, KDE bindings for Ruby, C#, python to use KDE classes with those langages, and XParts to embed non-KDE apps as a KPart. Check the binding page of TechBase.

Does the feature freeze apply to playground?

No, playground are not a released packages. The same is true for kdereview and extragear: they are not frozen and released. But if you want your app to move to a package, ask for it before the beta-release.

Can I have a stable and an unstable KDE on the same computer?

Yes, check the Building 2 Versions documentation.

How do I know which version of Qt/KDE I am using?

kde-config and all kde programs accept --version as argument.

Qt-copy or Qt from qt.nokia.com : if one were doing a clean build of trunk, which would be preferable?

You can use either. They are binary compatible (forward and backward). There can be, however, a few bugfixes in qt-copy over the most recent Qt release. Especially if building from qt-copy, pay attention to the apply-patches script.

How can I checkout a single directory from a SVN module?

Checkout the top-level dir with 'svn co -N /modulename', 'cd modulename', 'svn up admin' to get the admin/ dir and then finally checkout the dir you want with 'svn up subdir'

For instance, to get only reaktivate from playground/utils: svn co -N /playground/utils; svn up reaktivate Then compile as usual.

The same answer applies to the question "How do I get a single language out of kde-i18n?".

If you don't know the name of the directory you want to check out, you can browse websvn.kde.org to find it.

How can I get one of the KDE application as a standalone tarball?

kdesdk/scripts/svn2dist is a script to extract an application from the KDE source tree and package it as a standalone application.

How do I close my own bug reports?

If you reported a bug that is fixed in a new release of KDE but is still reported as open, you can close it. It might happen because your bug is the same as another one, or simply because the developer fixed something without noticing that it would correct your bug.

You can do that from your Subversion commit. To do so, append to your commit message a line like this:

BUG: XXXXX where XXXXX is the bug report you want to close. If the report you're closing is adding a new feature, you can use FEATURE instead of BUG.

Managing a bug list is a huge task for the developers and they usually have a lot of bugs listed, some being fixed already without their knowledge, some being unreproducible, some without enough information to be corrected, etc. If you can help by managing and updating the list of outstanding bugs, you will be gladly welcome. And you will receive an even happier welcome if you provide a patch.

How do I create a SSH key?

SSH makes use of two keys: a private key and a public key. You should keep the private key secret at all times and only place it on machines over which you have direct control. Public, shared, and community machines are not suitable environments to store SSH private keys. Take action to help prevent theft of your SSH private key data. Setting a password on your SSH private key will help reduce the risks involved with private key theft.

Generate a key pair for each major location you work from. This helps to reduce the impact when your key gets stolen. When someone obtains access to your private key, your key can be abused in attempts to compromise KDE servers. Well known open source projects have been compromised this way in the past, YOU must help us to make sure that this doesn't happen with KDE servers as well. For that reason it is important to notify sysadmin (at) kde (dot) org immediately when you notice that someone may have had access to your private key for example when a computer on which it was stored has been hacked or infected with a virus, worm or trojan.

If you choose to make a backup of your SSH private key data, please ensure that any such backup is stored in a secure manner as well.

For the practical part, the following command can be used to generate a SSH private/public key pair with ssh-keygen -t dsa This will create a private key as ~/.ssh/id_dsa and a public key as ~/.ssh/id_dsa.pub.

There are times when you may want to use a key of a different name to the default, perhaps to use separate keys for different projects. To let SSH know which key you want to use for KDE.org, you can keep a list of servers and their corresponding keys in ~/.ssh/config. For example,

Host svn.kde.org 
IdentityFile ~/.ssh/id_dsa_kde

In order to use SSH to access KDE servers you need to send your public key to sysadmin (at) kde (dot) org.

How can I monitor changes made by others?

The kde-commits mailinglist carries automatic notifications for all changes made in the KDE repositories. The KDE-Commits mailinglist is very high traffic. An alternative is CommitFilter which allows you to get notification for only those areas that interest you.