Translate

Jump to: navigation, search
Settings

Information about the group Translation of the wiki page Development/FAQs/Technical FAQ.
NavigationShowing messages from 1 to 100 of 106. [ Previous page ] [ Next page ]
Development/FAQs/Technical FAQCurrent message text
...cal FAQ/Page display title/pt-brDesenvolvimento/FAQs/FAQ Técnico
...ent/FAQs/Technical FAQ/106/pt-br{{improve|O sistema build mudou no KDE4.}}
...pment/FAQs/Technical FAQ/2/pt-br==Como faço para iniciar um novo aplicativo?==
...pment/FAQs/Technical FAQ/3/pt-brO jeito mais fácil é usar kdesdk/kapptemplate para gerar o CMakeLists.txt. Ou você pode apenas copiar um CMakeLists.txt de outro aplicativo e instalá-lo em um novo diretório acima do que estão os códigos existentes do KDE. Ou você pode iniciar da velha maneira, do zero.
...pment/FAQs/Technical FAQ/4/pt-br==O que é plasma, kpart, kio, kdeinit, ...==
...pment/FAQs/Technical FAQ/5/pt-brConsulte o TechBase, especialmente os [[Special:myLanguage/Development/Architecture|documentos da arquitetura]]. Consulte também o livro do kde.
...pment/FAQs/Technical FAQ/6/pt-br==Eu realmente preciso usar kpart?==
...pment/FAQs/Technical FAQ/7/pt-brBem, você não é obrigado, mas é muito melhor. KPart permite uma poderosa reutilização de código. Tendo em vista o fato de que é simples usar essa tecnologia e que ela é amplamente implementada, é uma pena não usá-la se você puder.
...pment/FAQs/Technical FAQ/8/pt-br==Como escrevo um CMakeLists.txt?==
...pment/FAQs/Technical FAQ/9/pt-brPor favor, siga esse [[Special:myLanguage/Development/Tutorials/CMake|tutorial do CMake ]].
...ment/FAQs/Technical FAQ/10/pt-br==Que alvos estão disponíveis para make?==
...ment/FAQs/Technical FAQ/11/pt-br*all: o alvo padrão (o que você obtém quando digita "make"). 
*clean: remove todos os arquivos gerados 
*distclean: também remove os arquivos gerados por Makefile.cvs Não é muito útil no KDE (veja dist para o conceito "dist" e svn-clean para uma melhor maneira do make realmente remover). 
*dist: supostamente para fazer tarball do SVN, mas não é suportado muito bem no KDE. Melhor usar kdesdk/scripts/cvs2pack para isso. 
*force-reedit: executa novamente automake e am_edit no Makefile.am 
*install: bem, instala tudo 
*install-strip: instala tudo e descarta os binários (remove símbolos de depuração). 
*install-exec: somente instala os binários e bibliotecas 
*install-data: somente instala os arquivos de dados
*check: compila os programas de teste (ou seja, aqueles definidos com check_PROGRAMS). É possível até mesmo executar alguns testes durante "make check", veja kdelibs/arts/tests/Makefile.am
...ment/FAQs/Technical FAQ/12/pt-br==Tenho um checkout do SVN, não há nenhuma configuração e nenhum Makefile?==
...ment/FAQs/Technical FAQ/13/pt-brUse make -f Makefile.cvs Ele vai executar todas as etapas de geração do Makefile
...ment/FAQs/Technical FAQ/14/pt-br==Como posso excluir temporariamente determinados diretórios da compilação?==
...ment/FAQs/Technical FAQ/15/pt-brEnquanto hackeia um programa pode ser útil excluir determinados diretórios da compilação que, de outra forma, seriam recompilados, mas que efetivamente não precisam ser. Também, se você fez o checkout do código que não compilou e não tem tempo ou conhecimento para corrigir os erros, você pode querer desativar a compilação do diretório tudo junto. Há dois casos. Diretório e subdiretórios. Para os diretórios você pode simplesmente apagá-los (ou não fazer checkout neles)
...ment/FAQs/Technical FAQ/16/pt-brSe por alguma razão você não quer fazer isso, você pode também definir <code>DO_NOT_COMPILE="someapp"</code> antes de chamar configure, que fará configure ignorar "someapp". Para compilar apenas poucos diretórios, ao invés de usar <code>DO_NOT_COMPILE</code> para excluir a maioria deles, você pode listar em um arquivo chamado ''inst-apps'', no nível superior, os subdiretórios de nível superior que você quer compilar.
...ment/FAQs/Technical FAQ/17/pt-brPara desativar a compilação de qualquer diretório, inclusive subdiretórios, você tem que modificar os arquivos Makefile ou Makefile.am. Makefile.am não é recomendado porque o arquivo está no Subversion do KDE e você pode acidentalmente commitar suas alterações. Então, vamos modificar o Makefile aqui:
...ment/FAQs/Technical FAQ/18/pt-brAbra o Makefile no diretório imediatamente acima do diretório que você deseja excluir, em um editor de texto e procure por uma variável <code>SUBDIRS</code>. Ela, frequentemente, se parecerá um pouco como
...ment/FAQs/Technical FAQ/19/pt-br{{Input|1=SUBDIRS = share core ui . proxy taskmanager taskbar applets extensions data}}
...ment/FAQs/Technical FAQ/20/pt-brBasta remover o diretório que você deseja excluir e salvar seu arquivo. Um novo make vai ignorar o diretório que você acabou de remover.
...ment/FAQs/Technical FAQ/21/pt-brÀs vezes você terá que olhar com mais atenção porque a variável SUBDIRS consiste de uma série de outras variáveis​​:
...ment/FAQs/Technical FAQ/22/pt-br<code>SUBDIRS = $(COMPILE_FIRST) $(TOPSUBDIRS) $(COMPILE_LAST) </code>
...ment/FAQs/Technical FAQ/23/pt-brAqui você tem que encontrar as variáveis <code>COMPILE_FIRST</code>, <code>TOPSUBDIRS</code> e <code>COMPILE_LAST</code>. Uma destas contém o diretório que você quer excluir. Remova o diretório de onde você encontrá-lo e salve o Makefile novamente.
Para desfazer as alterações, você pode gerar novamente o Makefile do zero ou reverter para um backup mais antigo (você fez um, não é? :-).
Para criar novamente um Makefile, basta make force-reedit.
...ment/FAQs/Technical FAQ/24/pt-brVocê também pode copiar a linha original no arquivo ao editar e fazer um comentário, prefixando um '#' na frente dele. Em seguida, desfazer a mudança é tão fácil como fazer a linha modificada com um comentário e remover o comentário na linha original.
...ment/FAQs/Technical FAQ/25/pt-br==Quais são as diferentes opções de compilação?==
...ment/FAQs/Technical FAQ/26/pt-br<code> --enable-debug</code>
: Adiciona símbolos de depuração, desabilita otimizações e ativa o log de kdDebug().
...ment/FAQs/Technical FAQ/27/pt-brcode>--disable-debug</code>
: O oposto do anterior: habilita otimizações e desativa o log de kdDebug().
...ment/FAQs/Technical FAQ/28/pt-br<code> --enable-final</code>
: Concatena todos os arquivos .cpp em um grande arquivo all_cpp.cpp, e compila de uma só vez, ao invés de compilar cada arquivo .cpp por vez. Isso faz com que a compilação seja muito maior e, muitas vezes, leva a uma melhor otimização do código, mas também requer muito mais memória. E, muitas vezes, resulta em erros de compilação quando os cabeçalhos incluídos por diferentes arquivos de origem colidem um com o outro, ou quando se utiliza funções c estáticas com o mesmo nome em diferentes arquivos de origem.
Esta é uma boa coisa a fazer no momento do empacotamento, mas, claro, não para desenvolvedores, já que uma mudança em um arquivo significa recompilar tudo.
...ment/FAQs/Technical FAQ/29/pt-br<code> --disable-fast-perl</code>
: Por padrão, usuários KDE usam perl ao invés de sh e sed para converter Makefile.in para Makefile. 
Esta é uma adição ao autoconf feita por Michael Matz. Você pode usar esta opção para desabilitar isso, mas é muito mais lento.
...ment/FAQs/Technical FAQ/30/pt-br==Que opção de compilação você recomenda?==
...ment/FAQs/Technical FAQ/31/pt-brIf you are a developer, you should definitely compile Qt and KDE with --enable-debug. You will then be able to debug your program even inside Qt and KDE function calls. 
If you are just a user, you can still use --enable-debug. KDE will occupy more space on your hard disk but it won't slow down your desktop. The advantage is that you get stack trace when an application crashes. If you can reproduce a crashing behaviour, go to bugs.kde.org, check that your bug doesn't exist yet and submit it. It will help us improve kde.
For Qt, the compilation options are explained in qt-copy/README.qt-copy.
...ment/FAQs/Technical FAQ/32/pt-br==Dicas para aumentar a velocidade de compilação?==
...ment/FAQs/Technical FAQ/33/pt-brSee ''--enable-final'' above :) . ''make final'' uses the all-in-one-file trick in the current directory even if --enable-final wasn't used, and ''make no-final'' does a normal compilation in the current directory even if --enable-final was used. 
Include your moc files! Header files declaring a QObject descendant have to be run through moc to produce a .moc file. This .moc file has to be compiled, for which two possibilities exists: compile it separately, or #include it in the C++ file implementing that above mentioned class. The latter is more efficient in term of compilation speed. BTW, kdesdk/scripts/includemocs does this automatically.
Buy more ram, a faster machine and another processor. On a bi-PIII 866 MHz with 1GB of RAM, kde compiles at a decent speed :-)))
...ment/FAQs/Technical FAQ/34/pt-br==There is a STRIP variable set in the Makefile but it doesn't seem to be used?==
...ment/FAQs/Technical FAQ/35/pt-brThe strip is done at install. To use it, use "make install-strip" instead of "make install".
...ment/FAQs/Technical FAQ/36/pt-br==Que identação eu devo usar?==
...ment/FAQs/Technical FAQ/37/pt-brSe você está trabalhando em uma aplicação existente, repeite a indetação do author. Se não, você pode usar qualquer identação que lhe for conveniente.
...ment/FAQs/Technical FAQ/38/pt-br==Qua é a diferença entre i18n 3 I18N_NOOP?==
...ment/FAQs/Technical FAQ/39/pt-brIf you do
<code>QString translatedStuff = i18n("foobar");</code> translatedStuff will contain the translation of "foobar", while for <code> const char *markedStuff = I18N_NOOP("foobar");</code> <tt>markedStuff</tt> will still contain literal "foobar", but translators will know you want "foobar" translated so you can later on do <code>QString translatedStuff = i18n(markedStuff);</code> and get the translation of "foobar", which wouldn't work without that I18N_NOOP. 
So, normally you want to just use i18n(), but in cases where you absolutely need to pass something untranslated, but still need to translate it later or in the case that you have something to be translated before the KInstance exists, use <code>I18N_NOOP()</code>.
...ment/FAQs/Technical FAQ/40/pt-br==I get "virtual tables error"?==
...ment/FAQs/Technical FAQ/41/pt-brThis often comes from the moc files not being in sync with the sources, or not linked at all. Check that you are running the right moc. 'which moc' will tell it. Regenerate your moc files (make force-reedit; make clean; make).
...ment/FAQs/Technical FAQ/42/pt-br==I have added Q_OBJECT to myClassHeader.h but no moc files is generated?==
...ment/FAQs/Technical FAQ/43/pt-brYou need am_edit to reparse your Makefile.am to generate the correct Makefile. If it's the first Q_OBJECT you're using in this directory, you'll need to re-run Makefile.cvs or create_makefile from kdesdk/scripts. Otherwise, you can simply run "make force-reedit".
...ment/FAQs/Technical FAQ/44/pt-br==To go quicker, I have coded my whole class in a cpp file, how do I get the moc files generated?==
...ment/FAQs/Technical FAQ/45/pt-brHmm, don't do that, if some of the classes use the Q_OBJECT macro. Maybe METASOURCES=file.cpp might work for moc files though.
...ment/FAQs/Technical FAQ/46/pt-br==I have developed a kpart (or a plugin). I don't want to install it yet because it is not finished but I need that KDE finds it when I request it using KTrader or KLibLoader. How do I do that?==
...ment/FAQs/Technical FAQ/47/pt-brKDE searches its libraries in $KDEDIR/lib and in the lib directory of all the components of $KDEDIRS (note the additional 'S', this different from $KDEDIR). So, while you are still developing your library and don't want to install it, you can use this trick:
...ment/FAQs/Technical FAQ/48/pt-br: cd to your development directory, the one where your library is built. <br />
: Set up KDEDIRS so that it include your development directory: export KDEDIRS=`pwd`:$KDEDIR <br />
: Create a pseudo lib directory where KDE should find your component: ln -s .libs lib (all the objects and libraries are built in the .libs directory). <br />
: Run kbuildsycoca to inform KDE that it KDEDIRS has changed.
...ment/FAQs/Technical FAQ/49/pt-brNow, KDE should find your library when using KTrader or KLibLoader.
...ment/FAQs/Technical FAQ/50/pt-br==How can I install additional KDE stuff when I am not root?==
...ment/FAQs/Technical FAQ/51/pt-brIf want to install your application privately, configure it with another prefix: for $HOME/kdeprefix, use <code>configure --prefix=$HOME/kdeprefix</code>. Then let KDE know about this prefix: set KDEDIRS to <tt>$HOME/kdeprefix:$KDEDIR</tt>. To make KDE aware of new prefixes, one can also edit /etc/kderc and add
...ment/FAQs/Technical FAQ/52/pt-br{{Input|1=[Directories]
prefixes=/the/new/prefix}}
...ment/FAQs/Technical FAQ/53/pt-brbut this doesn't answer this specific question ;-)
Make sure to run "kbuildsycoca" after setting the new KDEDIRS.
...ment/FAQs/Technical FAQ/54/pt-br==My kpart lib is not listed when I request it with KTrader==
...ment/FAQs/Technical FAQ/55/pt-brThe mimetype database must be rebuilt when you install new services (such as applications or parts). In theory this happens by itself (kded is watching those directories), but in doubt, run "kbuildsycoca".
The best way to debug trader-related problems is to use <code>ktradertest: cd kdelibs/kio/tests; make ktradertest</code>, then run <code>./ktradertest</code> to see how to use it.
...ment/FAQs/Technical FAQ/56/pt-br==I changed something in kdelibs, installed the new lib, but new KDE apps don't seem to use it?==
...ment/FAQs/Technical FAQ/57/pt-brThe solution is simple: start new apps from a command line, then they will use the new lib.
...ment/FAQs/Technical FAQ/58/pt-brThe reason is that applications started by other KDE applications (kicker, minicli, konqueror, etc.) are started via kdeinit, which loads the libs when KDE starts. So the "old" version of the libs keep being used. But if you want kdeinit to start using the new libs, simply restart it. This is done by typing kdeinit in a terminal.
...ment/FAQs/Technical FAQ/59/pt-brThis is necessary if you can't start things from the command line - e.g. for a kioslave. If you change something in kio, you need to restart kdeinit and kill the running kioslave, so that a new one is started.
...ment/FAQs/Technical FAQ/60/pt-br==I'm developing both a KPart and a standalone application, how do I avoid duplicated code?==
...ment/FAQs/Technical FAQ/61/pt-brApps are often tempted to link to their part because they of course have much functionality in common. However this is wrong for the reasons below.
...ment/FAQs/Technical FAQ/62/pt-brA lib is something you link to, a module is something you dlopen. You can't dlopen a lib ; you can't link to a module.
...ment/FAQs/Technical FAQ/63/pt-brA lib has a version number and is installed in $libdir (e.g. $KDEDIR/lib) a module doesn't have a version number (in its name), it's more like a binary (we don't have konqueror-1.14.23 either :), and is installed into kde_moduledir (e.g. $KDEDIR/lib/kde3) (which means it's not in the search path for ld.so, so this breaks on systems without -rpath).
...ment/FAQs/Technical FAQ/64/pt-brIf you didn't understand the above, don't worry. The point is: you should NOT make your application link to your (or any other) KPart, nor any other kind of dlopened module.
...ment/FAQs/Technical FAQ/65/pt-brThe solutions:
...ment/FAQs/Technical FAQ/66/pt-brLet the app dlopen the part. This is what KOffice does. However this limits the app to the very limited ReadOnlyPart/ReadWritePart API. Keep in mind that you can't call a non-virtual method whose implementation you don't link to. The solution is to define a ReadWritePart-derived class (like we have in koffice: KoDocument), with new virtual methods. Either this derived class has code (and you need a lib shared by the app and the part, see point 2 below), or an abstract interface (header file only) is enough. You can also use known interfaces to child objects of the part instead of changing the base class of the part itself - this is the solution used by e.g. KParts::BrowserExtension.
...ment/FAQs/Technical FAQ/67/pt-brDefine a common library with the common classes and let both the part and the app use it. That library can be noinst_ or lib_, both work. In the first case the compiled object code is duplicated, in the second case a real versioned lib will be installed. The idea here is that the part itself is not available to the app, but instead the part is a very thin wrapper around the same classes as the app uses. Only KParts-specific stuff remains in the part.
...ment/FAQs/Technical FAQ/68/pt-br==What is the best way to launch another app?==
...ment/FAQs/Technical FAQ/69/pt-brIn KDE there are several ways to start other programs from within your application. Here is a short summary of your options with reasons why you should or should not use them.
...ment/FAQs/Technical FAQ/70/pt-br===fork + exec===
...ment/FAQs/Technical FAQ/71/pt-brYou never want to use this unless you have a very good reason why it is impossible to use KProcess.
...ment/FAQs/Technical FAQ/72/pt-br===KProcess===
...ment/FAQs/Technical FAQ/73/pt-brYou want to use this if you need to start a new process which needs to be a child of your process, e.g. because you want to catch stdout/stderr or need to send it data via stdin. You should never use this to start other KDE applications unless your application is called kgdb :-)
...ment/FAQs/Technical FAQ/74/pt-br===startServiceByDesktopPath===
...ment/FAQs/Technical FAQ/75/pt-brPreferred way to launch desktop (KDE/Gnome/X) applications or KDE services. The application/service must have a .desktop file. It will make use of KDEinit for increased startup performance and lower memory usage. These benefits only apply to applications available as KDEinit loadable module (KLM)
...ment/FAQs/Technical FAQ/76/pt-br===KRun===
...ment/FAQs/Technical FAQ/77/pt-brGeneric way to open documents/applications/shell commands. Uses startServiceBy.... where applicable. Offers the additional benefit of startup-notification.<br /> [http://api.kde.org/4.x-api/kdelibs-apidocs/kio/html/classKRun.html KRun] can start any application, from the binary or the desktop file, it will determine the mimetype of a file before running the preferred handler for it, and it can also start shell commands. This makes KRun the recommended way to run another program in KDE.
...ment/FAQs/Technical FAQ/78/pt-br=== KToolInvocation::invokeBrowser ===
...ment/FAQs/Technical FAQ/79/pt-br[http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKToolInvocation.html KToolInvocation::invokeBrowser] launches a web browser. The difference with using the more generic KRun on the webpage URL is that KRun has to determine the mimetype of the URL first (which, for HTTP, involves starting a download to read the headers), so if you know that the URL is an HTML webpage, use invokeBrowser, it will be faster.
...ment/FAQs/Technical FAQ/80/pt-brMore details: the problem with KRun for webpages is that it delays the appearance of the  browser window, and if the user's preferred browser is a non-kde application like firefox then it has to start a second download while konqueror which can reuse the kioslave started by KRun. On the other hand if the URL might be an image or anything else than html, then KRun is the right solution, so that the right application is started.
...ment/FAQs/Technical FAQ/81/pt-br==How do I create and submit a patch to KDE?==
...ment/FAQs/Technical FAQ/82/pt-brYou have spotted a bug and you want to write the code to fix it. Or you want to code a specific feature. Sending a patch is very appreciated by developers. A tutorial is available but here is a description of how you should proceed:
...ment/FAQs/Technical FAQ/83/pt-br* Get the latest KDE using SVN to check that the code you want to write has not been added yet.
* Check the bug database to see if your bug is not worked on.
...ment/FAQs/Technical FAQ/84/pt-br* Get in contact with the author. His/her name is in the about box or in the source header. If the project has a mailing-list, browse the archives to see if your bug/feature has not been the subject of any discussion. If you can't find any mailing lists or author, simply write to kde-devel.
...ment/FAQs/Technical FAQ/85/pt-br* Post a message explaining your intentions. It is important to inform the author(s) about what you are planning because somebody might already be working on your feature, or a better design could be proposed by the author, or he could give you some good advice.
...ment/FAQs/Technical FAQ/86/pt-br* Next step is to code your feature. It is usually a good idea to keep an original at hand and to work on a copy. This allow to check the behaviour of both versions of the code. Respect the author's indentation and naming scheme, code carefully, think about side-effects and test everything many times.
...ment/FAQs/Technical FAQ/87/pt-br* Using the latest KDE code, make a diff using either svn diff or a diff -uNp original-dir new-dir. Don't send reversed patch. The first argument of diff should be the old directory and the second the new directory.
...ment/FAQs/Technical FAQ/88/pt-br* Send a mail to the author/mailing-list with your patch as attachment (don't forget to attach it :-) ).
...ment/FAQs/Technical FAQ/89/pt-br* People usually have some remarks on your work and you must work further on your patch to improve it. It is common to see three or four submission before acceptation.
...ment/FAQs/Technical FAQ/90/pt-brOk, you have done it, your code has been included in KDE. You are now fully part of the KDE project. Thanx a lot.
...ment/FAQs/Technical FAQ/91/pt-br==How do I make my application Xinerama and multi-head safe?==
...ment/FAQs/Technical FAQ/92/pt-brNever make assumptions about the geometry of the "desktop" or the arrangement of the screens. Make use of the following functions from kglobalsettings.h: 
<syntaxhighlight lang="cpp-qt">
 static QRect KGlobalSettings::splashScreenDesktopGeometry(); 
 static QRect KGlobalSettings::desktopGeometry(const QPoint& point); 
 static QRect KGlobalSettings::desktopGeometry(QWidget *w); 
</syntaxhighlight>
Use splashScreenDesktopGeometry() to determine the geometry of the desktop when you want to display an application splash screen. Use desktopGeometry() to determine the geometry of the desktop with respect to a given point on the desktop, or with respect to a given widget. Do not use the Qt class QDesktopWidget to determine these values yourself. The KDE functions take the user's settings into account, something the Qt functions cannot do.
...ment/FAQs/Technical FAQ/93/pt-brIt is ideal to try to avoid using the desktop geometry altogether. Your application will be much more standards compliant if you let the window manager place your windows for you. When this is not possible, you have the aforementioned functions available. Please beware that the geometry that is returned from these functions may not start at (0,0)! Do your math correctly!
...ment/FAQs/Technical FAQ/94/pt-brOne other caution: Both KWin and the NETWM specification have severe difficulties handling struts with Xinerama or "merged" displays. This can result in dead areas on the screen, for instance if kicker does not span a whole edge. There is not much that can be done about this, and you should try to avoid hacks to circumvent this at this time. We hope to find a proper solution for this soon.
...ment/FAQs/Technical FAQ/95/pt-br==I get an error about KDE not finding UIC plugins, but I know they're installed. What's wrong?==
...ment/FAQs/Technical FAQ/96/pt-brThis is almost certainly an installation problem, not a KDE code problem. A number of problems can lead to this, but most likely you have more than one version of Qt laying around and the configure script is calling a different one than KDE is using.
...ment/FAQs/Technical FAQ/97/pt-brAnother thing that may help is to rebuild and reinstall your kdewidgets.so file, which is located in the kdelibs/kdewidgets directory. Note that if you *do* have multiple versions of Qt, this may compile against the wrong one.
...ment/FAQs/Technical FAQ/98/pt-brThis problem creeps up on various mailing lists occasionally, so looking at the archives on lists.kde.org may be helpful.
...ment/FAQs/Technical FAQ/99/pt-br==I put some functions in anonymous namespace and someone reverted it and made those functions static, why?==
NavigationShowing messages from 1 to 100 of 106. [ Previous page ] [ Next page ]
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal