Development/Architecture/KDE3/Standard Resources/pt-br: Difference between revisions

From KDE TechBase
(Created page with "O KDE oferece várias formas de acessar os arquivos que o seu aplicativo instalou no disco rígido do usuário enquanto torna transparente para você onde os dados realmente e...")
(Created page with "''Autor inicial:'' Stephan Kulow [mailto:[email protected] ([email protected])]")
 
(23 intermediate revisions by the same user not shown)
Line 8: Line 8:
onde os dados realmente estão. Para permitir aos usuários (ou administrador, na maioria dos casos) mover arquivos para onde eles se encaixarem melhor, o KDE oferece uma lista de diferentes tipos de recursos para a qual o caminho de pesquisa diferente é atribuído. Você pode ter ouvido sobre a variável de ambiente <tt>PATH</tt> para procurar executáveis ou <tt>MANPATH</tt> para procurar man pages (páginas de manuais). Você não esperaria ''man'' para procurar man pages em <tt>PATH</tt>.
onde os dados realmente estão. Para permitir aos usuários (ou administrador, na maioria dos casos) mover arquivos para onde eles se encaixarem melhor, o KDE oferece uma lista de diferentes tipos de recursos para a qual o caminho de pesquisa diferente é atribuído. Você pode ter ouvido sobre a variável de ambiente <tt>PATH</tt> para procurar executáveis ou <tt>MANPATH</tt> para procurar man pages (páginas de manuais). Você não esperaria ''man'' para procurar man pages em <tt>PATH</tt>.


Similiar to that concept KDE seperates search paths for different
Similar a esse conceito o KDE separa caminhos de busca para diferentes coisas para tornar mais simples adicionar caminhos para um recurso específico sem fazer uma procura por outro recurso desnecessário e mais lento e sem exigir de você que coloque tudo em um diretório.
things to make it simpler to add paths for a specific resource without
making a lookup for another resource unnecessary slower and without
requiring you to put everything into one directory.


The types of resources KDE offers are
Os tipos de recursos que o KDE oferece são


* apps - applications menu (.desktop files)
* apps - menu de aplicativos (arquivos .desktop)
* cgi - CGIs to run from khelpcenter* config - configuration files
* cgi - CGIs para executar do khelpcenter* config - arquivos de configuração
* data - where applications store data* exe - executables installed privatly for KDE's use
* data - onde aplicativos armazenam dados* exe - executáveis instalados privadamente para uso do KDE
* html - HTML documentation* icon - application icons to appear in the window manager or the panel
* html - documentação HTML* icon - ícones de aplicativos para aparecer no gerenciador de janela ou painel
* lib - libraries and to be dlopened modules* locale - translation files for KLocale
* lib - bibliotecas e módulos dlopened* locale - arquivos de tradução para KLocale
* mime - mime types* sound - application sounds
* mime - mime types* sound - sons de aplicativos
* toolbar - toolbar pictures
* toolbar - imagens da barra de ferramentas
* wallpaper - wallpapers
* wallpaper - papéis de parede


For all of them exist also Makefile aliases that configures created by the development
Para todos eles existem aliases Makefile também que configura criadas pelo desenvolvimento de ferramentas fornecidas para o KDE (por exemplo, o KDevelop) irá conhecer.
tools provided for KDE (e.g. kdevelop) will know about.


== KStandardDirs ==
== KStandardDirs ==


This is one of the most central classes in kdelibs as
Essa é uma das classes mais centrais na kdelibs, como
it provides a basic service: it knows where the files
ela fornece um serviço básico: ela sabe onde os arquivos
reside on the user's harddisk. And it's meant to be the
estão no disco rígido do usuário. E isso significa que ela é
only one that knows - to make the real location as
a única que sabe - para tornar a localização real mais transparente possível para o usuário e os aplicativos.
transparent as possible to both the user and the applications.


For this it encapsulates all informations from the application
Para isso, ela encapsula todas as informações do aplicativo e
and applications always refer to a file with a resource type
os aplicativos sempre se referem a um arquivo com um tipo de recurso
(e.g. apps) and a filename (e.g. {{path|Home.desktop}}). In an ideal world
(por exemplo, apps) e um nome de arquivo (por exemplo, {{path|Home.desktop}}). Em um mundo ideal, o aplicativo não faria suposição sobre onde este arquivo está e deixaria para <tt>KStandardDirs::findResource("apps", "Home.desktop")</tt>
the application would make no assumption where this file is and
aplicar esse conhecimento.
leaves it up to <tt>KStandardDirs::findResource("apps", "Home.desktop")</tt>
to apply this knowledge.


The main idea behind {{class|KStandardDirs}} is that there are several
A principal ideia por trás da {{class|KStandardDirs}} é que há vários prefixos de topo onde os arquivos estão abaixo. Um destes prefixos é aquele onde o usuário instalou a kdelibs dentro, outro onde o aplicativo foi instalado e outro é {{path|$HOME/.kde}}, mas talvez haja mais. Sob esses prefixos há vários sufixos bem definidos onde os tipos de recursos específicos são encontrados. Por exemplo para os ícones da barra de ferramentas que é {{path|share/toolbar}} e
toplevel prefixes where files are below. One of this prefixes is
the one where the user installed kdelibs into, one where the
application has been installed to and one is {{path|$HOME/.kde}}, but there
may be even more. Under these prefixes there are several well
defined suffixes where specific resource types are to be found.
For example for toolbar icons that is {{path|share/toolbar}} and
{{path|share/apps/&lt;appname&gt;/pics}}.
{{path|share/apps/&lt;appname&gt;/pics}}.


So the search algorithm basicly appends to each prefix each registered
Então, basicamente o algoritmo de busca acrescenta para cada prefixo um sufixo registrado e tenta localizar o arquivo lá. Para tornar a coisa ainda mais complexa, é possível também registrar caminhos absolutos que a KStandardDirs procura depois de não encontrar nada nas etapas antigas. Eles podem ser úteis se o usuário deseja fornecer diretórios específicos que não estão em seu diretório {{path|$HOME/.kde}} como exemplo para ícones.
suffix and tries to locate the file there.
To make the thing even more complex, it's also possible to register
absolute paths that KStandardDirs looks up after not finding anything
in the former steps. They can be useful if the user wants to provide
specific directories that aren't in his {{path|$HOME/.kde}} directory as
example for icons.


=== On the usage of <tt>locate</tt> and <tt>locateLocal</tt> ===
=== Sobre o uso de <tt>locate</tt> e <tt>locateLocal</tt> ===


locate and locateLocal are both convenient functions that make the use of
locate e locateLocal são duas funções convenientes que tornam o uso da
KStandardDirs as simple as possible. You have however the possibility to
KStandardDirs o mais simples possível. Você, no entanto, tem a possibilidade de
use the full power of KStandardDirs without them.
usar o poder da KStandardDirs sem elas.


Typical KDE applications use resource files in one out of three ways:
Os aplicativos típicos do KDE usam arquivos de recursos em uma das três maneiras:


* A resource file is read but is never written. A system default is supplied but the user can override this default in his local .kde directory:
* Um arquivo de recurso é lido mas nunca alterado. Um padrão do sistema é fornecido mas o usuário pode substituir este padrão em seu diretório local .kde:


<syntaxhighlight lang="cpp-qt">
<syntaxhighlight lang="cpp-qt">
Line 75: Line 56:
</syntaxhighlight>
</syntaxhighlight>


* A resource file is read and written. If the user has no local version of the file the system default is used. The resource file is always written to the users local .kde directory.
* Um arquivo de recurso é lido e escrito. Se o usuário não tiver uma versão local do arquivo o padrão do sistema é usado. O arquivo de recurso é sempre escrito para o diretório local de usuários .kde.


<syntaxhighlight lang="cpp-qt">
<syntaxhighlight lang="cpp-qt">
Line 88: Line 69:
</syntaxhighlight>
</syntaxhighlight>


* A resource file is read and written. No system default is used if the user has no local version of the file. The resource file is always written to the users local {{path|.kde}} directory.
* Um arquivo de recurso é lido e escrito. Nenhum padrão de sistema é usado se o usuário não tem versão local do arquivo. O arquivo de recurso é sempre escrito para o diretório local de usuários {{path|.kde}}.


<syntaxhighlight lang="cpp-qt">
<syntaxhighlight lang="cpp-qt">
Line 101: Line 82:
</syntaxhighlight>
</syntaxhighlight>


''Initial Author:'' Stephan Kulow [mailto:[email protected] ([email protected])]
''Autor inicial:'' Stephan Kulow [mailto:[email protected] ([email protected])]


[[Category:KDE3]]
[[Category:KDE3]]
[[Category:Architecture]]
[[Category:Architecture]]

Latest revision as of 13:42, 9 September 2014


Arquitetura do KDE - Acessando diretórios de recursos padrões

Visão geral

O KDE oferece várias formas de acessar os arquivos que o seu aplicativo instalou no disco rígido do usuário enquanto torna transparente para você onde os dados realmente estão. Para permitir aos usuários (ou administrador, na maioria dos casos) mover arquivos para onde eles se encaixarem melhor, o KDE oferece uma lista de diferentes tipos de recursos para a qual o caminho de pesquisa diferente é atribuído. Você pode ter ouvido sobre a variável de ambiente PATH para procurar executáveis ou MANPATH para procurar man pages (páginas de manuais). Você não esperaria man para procurar man pages em PATH.

Similar a esse conceito o KDE separa caminhos de busca para diferentes coisas para tornar mais simples adicionar caminhos para um recurso específico sem fazer uma procura por outro recurso desnecessário e mais lento e sem exigir de você que coloque tudo em um diretório.

Os tipos de recursos que o KDE oferece são

  • apps - menu de aplicativos (arquivos .desktop)
  • cgi - CGIs para executar do khelpcenter* config - arquivos de configuração
  • data - onde aplicativos armazenam dados* exe - executáveis instalados privadamente para uso do KDE
  • html - documentação HTML* icon - ícones de aplicativos para aparecer no gerenciador de janela ou painel
  • lib - bibliotecas e módulos dlopened* locale - arquivos de tradução para KLocale
  • mime - mime types* sound - sons de aplicativos
  • toolbar - imagens da barra de ferramentas
  • wallpaper - papéis de parede

Para todos eles existem aliases Makefile também que configura criadas pelo desenvolvimento de ferramentas fornecidas para o KDE (por exemplo, o KDevelop) irá conhecer.

KStandardDirs

Essa é uma das classes mais centrais na kdelibs, como ela fornece um serviço básico: ela sabe onde os arquivos estão no disco rígido do usuário. E isso significa que ela é a única que sabe - para tornar a localização real mais transparente possível para o usuário e os aplicativos.

Para isso, ela encapsula todas as informações do aplicativo e os aplicativos sempre se referem a um arquivo com um tipo de recurso (por exemplo, apps) e um nome de arquivo (por exemplo, Home.desktop). Em um mundo ideal, o aplicativo não faria suposição sobre onde este arquivo está e deixaria para KStandardDirs::findResource("apps", "Home.desktop") aplicar esse conhecimento.

A principal ideia por trás da KStandardDirs é que há vários prefixos de topo onde os arquivos estão abaixo. Um destes prefixos é aquele onde o usuário instalou a kdelibs dentro, outro onde o aplicativo foi instalado e outro é $HOME/.kde, mas talvez haja mais. Sob esses prefixos há vários sufixos bem definidos onde os tipos de recursos específicos são encontrados. Por exemplo para os ícones da barra de ferramentas que é share/toolbar e share/apps/<appname>/pics.

Então, basicamente o algoritmo de busca acrescenta para cada prefixo um sufixo registrado e tenta localizar o arquivo lá. Para tornar a coisa ainda mais complexa, é possível também registrar caminhos absolutos que a KStandardDirs procura depois de não encontrar nada nas etapas antigas. Eles podem ser úteis se o usuário deseja fornecer diretórios específicos que não estão em seu diretório $HOME/.kde como exemplo para ícones.

Sobre o uso de locate e locateLocal

locate e locateLocal são duas funções convenientes que tornam o uso da KStandardDirs o mais simples possível. Você, no entanto, tem a possibilidade de usar o poder da KStandardDirs sem elas.

Os aplicativos típicos do KDE usam arquivos de recursos em uma das três maneiras:

  • Um arquivo de recurso é lido mas nunca alterado. Um padrão do sistema é fornecido mas o usuário pode substituir este padrão em seu diretório local .kde:
// Code example
myFile = locate("appdata", "groups.lst")
myData = myReadGroups(myFile);
  • Um arquivo de recurso é lido e escrito. Se o usuário não tiver uma versão local do arquivo o padrão do sistema é usado. O arquivo de recurso é sempre escrito para o diretório local de usuários .kde.
// Code example
myFile = locate("appdata", "groups.lst")
myData = myReadGroups(myFile);
...
doSomething(myData);
...
myFile = locateLocal("appdata", "groups.lst");
myWriteGroups(myFile, myData);
  • Um arquivo de recurso é lido e escrito. Nenhum padrão de sistema é usado se o usuário não tem versão local do arquivo. O arquivo de recurso é sempre escrito para o diretório local de usuários .kde.
// Code example
myFile = locateLocal("appdata", "groups.lst");
myData =  myReadGroups(myFile);
...
doSomething(myData);
...
myFile = locateLocal("appdata", "groups.lst");
myWriteGroups(myFile, myData);

Autor inicial: Stephan Kulow ([email protected])