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

From KDE TechBase
No edit summary
No edit summary
Line 32: Line 32:
Para isso, ela encapsula todas as informações do aplicativo e
Para isso, ela encapsula todas as informações do aplicativo e
os aplicativos sempre se referem a um arquivo com um tipo de recurso
os aplicativos sempre se referem a um arquivo com um tipo de recurso
(por exemplo, 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
The main idea behind {{class|KStandardDirs}} is that there are several

Revision as of 12:54, 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.

The main idea behind KStandardDirs is that there are several 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 $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 share/toolbar and share/apps/<appname>/pics.

So the search algorithm basicly appends to each prefix each registered 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 $HOME/.kde directory as example for icons.

On the usage of locate and locateLocal

locate and locateLocal are both convenient functions that make the use of KStandardDirs as simple as possible. You have however the possibility to use the full power of KStandardDirs without them.

Typical KDE applications use resource files in one out of three ways:

  • 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:
// Code example
myFile = locate("appdata", "groups.lst")
myData = myReadGroups(myFile);
  • 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.
// Code example
myFile = locate("appdata", "groups.lst")
myData = myReadGroups(myFile);
...
doSomething(myData);
...
myFile = locateLocal("appdata", "groups.lst");
myWriteGroups(myFile, myData);
  • 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 .kde directory.
// Code example
myFile = locateLocal("appdata", "groups.lst");
myData =  myReadGroups(myFile);
...
doSomething(myData);
...
myFile = locateLocal("appdata", "groups.lst");
myWriteGroups(myFile, myData);

Initial Author: Stephan Kulow ([email protected])