Development/FAQs/General FAQ (pt BR)

 

Proposed for Deletion
This page has been proposed for deletion for the following reason: Page was created before the current translation system.

Eu quero iniciar esta nova aplicação. O que vocês aconselham?

Todos nós concordamos que existem muitas aplicações KDE que precisam ser reescritas. Mas existem também muitas aplicações KDE que precisam de sua ajuda.

Para ver estas áreas onde precisam de ajuda, verifique esta página.

Antes de iniciar uma nova aplicação, é sempre uma boa idéia verificar o endereço www.kde-apps.org por aplicações existentes e perguntar na lista de e-mails [email protected] se alguém está começando a trabalhar em um projeto similar.

Eu sou um desenvolvedor, como eu posso contribuir com o KDE?

Verifique os trabalhos abertos na lista de trabalhos. Certamente existe um trabalho que você pode pegar. KOffice e KDevelop, apesar de muito elogiados, tem poucos desenvolvedores, de modo que é interessante dar uma olhada por lá. Não é preciso ser uma desenvolvedor-núcleo do KDE para ajudar. O KDE é bem modular, então você pode perfeitamente melhorar uma área sem conhecimento de como todo o sistema funciona.

Você também pode perguntar no kde-devel se alguém precisa de ajuda na aplicação que está desenvolvendo. Use a versão mais atual do KDE e foque nas coisas que são necessárias. Um gerador de temas? Editor de esquemas para o konsole? Melhorar um jogo? Existe sempre uma pequena característica faltando. Vá e a implemente!

Você é tem familiaridade ou é atraído por algum campo específico? Veja se existe uma aplicação relacionada que seria beneficiada pela sua ajuda. Ou escreva uma. O KDE precisa de mais aplicações orientadas a não-geeks.

Eu não sou um desenvolvedor, como eu posso ajudar?

Existem muitas tarefas que não requerem habilidades de desenvolvimento. Escrever análises de aplicações para promover o KDE (veja a lista de e-mail kde-promo), ajudar a equipe de documentação (veja i18n.kde.org/doc), ajudar nas traduções (veja i18n.kde.org), ajudar a filtrar os bugs encaminhados (veja bugs.kde.org).

Onde eu posso encontrar imagens do dragão Konqi?

O Konqi para algumas pessoas está em ftp://ftp.kde.org/pub/kde/devel/konqi_sdk.tar.bz2 ftp.kde.org/pub/kde/devel/konqi_sdk.tar.bz2]
Isto foi postado para artist.kde.org antes da paǵina deixar de ser atualizada.

Imagens adicionais estão em KDE merchandise.

Qual é o nível de conhecimento requerido para contribuir com o KDE? O que eu devo aprender? O que eu devo ler?

Você precisa conhecer C++. Leia os tutoriais Qt e navegue pelos documentos do Qt para ganhar familiaridade com o que está disponível com Qt. Então leia os tutoriais KDE e navegue pela arquitetura e documentação. Você também pode ler o KDE Book, vão vai doer. Mas você não precisa se familiarizar com toda a arquitetura KDE para tornar-se um desenvolvedor KDE. Usando as tecnologias do KDE é bem fácil, então concentre-se no que realmente é preciso, você pode aprender sobre as outras coisas mais tarde. http://techbase.kde.org and doc.trolltech.com (também em seu $QTDIR/doc/html) são recursos inestimáveis, aproveite. Então, navegue pelo código fonte, veja os exemplos nos diretórios, veja como os outros desenvolveram seus códigos. Lendo e escrevendo código é a melhor maneira de aprender.

O que é SVN? Como posso obter o KDE através do SVN?

Veja a página sobre SVN Anônimo.

O que eu devo colocar em 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 faça o svn diff ignorar espaços em branco, e exiba o nome 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 (SVN trunk).
• seu aplicativo deve ser estável.
• seu aplicativo deve ser mantido. Você irá provavelmente receber uma boa quantidade de bugs reportados e pedidos. As pessoas esperam que você arrume os bugs e implemente os pedidos que façam sentido.

Veja também a próxima pergunta.

Is it better to develop inside or outside 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.

Some of those advantages are: your code ends up on all distro's, people might fix your bugs, you get free translations and documentation, you get tons of bugreports.

On the other side there are disadvantages and responsibilities: you will have to communicate with other developers about your work, other people might make changes to your code, you will have to respect release freezes, you get tons of bugreports and people actually expect that you fix them as well (what are they smoking?), people expect you to maintain your code.

You can't chose for the advantages and ignore the responsibilities that come with it, it's a complete package, it's both or nothing.

In general it should be the author of a piece of software that chooses to put his application in SVN. We usualy don't put software in KDE SVN unless the author wishes to do so. The other way around, if the author prefers to work on his application outside SVN then that's his right as well. Unless there is a split in the actual group of people working on the application it makes no sense to fork the development of an application because of that.

BUT... by putting your code under and open source license and putting it in KDE SVN you give the world at large, as well as KDE in particular, the irrevocable right to use your code. And KDE will use that right at its discretion to protect the interests of KDE, even if that goes against the wishes of the author at that point in time.

---

It is important to know that but don't be afraid. Usually, things work very well. In 5 years, it has only happened once that a developer had his work put kept in KDE while he wanted to remove it.

How do I get SVN access to kde?

See full article at Contribute > Get a SVN Account.

Send a mail to sysadmin (at) kde (dot) org justify why you need SVN access. Make sure to specify your full name and e-mail address, if the From field in your mails doesn't specify them.

Please 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 SVN and bugs.kde.org accounts match. You can change your bugs.kde.org address in the Bugzilla user settings.

You can currently choose between the standard SVN protocol (https using a password) and the svn+ssh using an ssh key. If you choose https, send also an encrypted password (for instance using useradd dummy ; passwd dummy ; grep dummy /etc/passwd /etc/shadow) and see also the tutorial. If you choose svn+ssh, send a public ssh key instead (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 is no restrictions on SVN rights, we expect you not to mess up 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 the KDE SVN repository are listed in the KDE SVN 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 (=kde-alpha). Develop it there and when it is ready, ask 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.

What is kdebindings?

It contains Qt/KDE bindings for Java to use Qt/KDE classes with Java, DCOP bindings for C, Java, Perl, Python to use DCOP in those langages and XParts to embed non-KDE apps as a KPart. There are also other bindings for kde which are not maintained by KDE. Check the binding page of developer.kde.org.

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.

Como eu posso saber qual versão do Qt/KDE eu estou usando?

Execute o Centro de Controle KDE. A tela de apresentação inclui a informação sobre a versão do KDE.

kde-config e todos os programas KDE aceitam --version como argumento.

Qt-copy or Qt from trolltech.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 happens 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 unreproducable, some without enough information to be corrected, etc. If you can help managing and updating the list of outstanding bug, 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 seperate 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 SVN repository. 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.