Quando voltamos ao assunto de programação para Desktop, uma das melhores soluções no mundo de código aberto são as Linguagens Phyton e C, pois ambas possibilitam uma grande integridade com o Sistema Operacional, o qual o mesmo é desenvolvido.
Uma leve introdução à linguagem de desenvolvimento
Com o amadurecimento das linguagens de programação orientada a objetos, proporcionou uma vasta integração da plataforma e aplicativos. Excelentes linguagens como C, C++, Phyton, Java e etc… são constantemente usadas neste tipo de desenvolvimento, se destacando sem sombra de duvida aquelas que possui uma melhor performance e agilidade para o caso específico.
Quando voltamos ao assunto de programação para Desktop, uma das melhores soluções no mundo de código aberto são as Linguagens Phyton e C, pois ambas possibilitam uma grande integridade com o Sistema Operacional, o qual o mesmo é desenvolvido.
O Compiz trabalha com facilidade e domina o gerenciamento de janelas, sem que possam ter algum tipo de conflito com os demais Gerenciadores. Desenvolvido inicialmente pela Novell, empresa de software, e hoje seu desenvolvimento é movido por grandes contribuidores do mundo inteiro.
Qualquer software que se preze deve possuir um codificação limpa e bem delfinida, para que possam ser facilmente interpretadas por outros desenvolvedores. Por este motivo todos os desenvolvedores devem seguir o mesmo estilo de programação.
Estilo básico do algorítimo
Exemplo simples
defaultMinimizeAnimInit (CompScreen * s, CompWindow * w)
{
ANIM_SCREEN(s);
ANIM_WINDOW(w);
if (animZoomToIcon(as, aw))
{
aw->animTotalTime /= ZOOM_PERCEIVED_T;
aw->animRemainingTime = aw->animTotalTime;
aw->usingTransform = TRUE;
}
defaultAnimInit(s, w);
}
Como estamos falando de código aberto, os colaboradores usam editores de textos simples para trabalhar. Ambos recomendam o editor Vim.
Estrutura dos plugins
Virtualmente todos os plugins precisam armazenar dados de alguma forma, e na maioria das vezes tem que ser unida a uma estrutura central, um bom exemplo seria o armazenamento de dados do processo de uma animação ou a opacidade de uma janela em desvanecimento do plugin Para se obter esses acessos os plugins precisam de acesso à base.privates em um CompDisplay e um em um CompScreen e em um CompWindow. O displayPrivateIndex é armazenado em um espaço dos plugin, geralmente visível na parte superior de um código. O initDisplay pedirá () este índice e alocará a memória para a estrutura, a seguir une a estrutura a d->base.privates [displayPrivateIndex] (que é uma união, assim d->base.privates [displayPrivateIndex] .ptr).
Para os outros índices, aplica-se o mesmo processo, a não ser que o screenPrivateIndex seja armazenado geralmente na estrutura de encaixe da exposição, e o windowPrivateIndex na estrutura de encaixe da tela.
A maioria dos plugins setup para alcançar estas funções, chamadas geralmente PLUGINNAME_DISPLAY (o *d) CompDisplay, por exemplo, que conduziria a um *pd de PluginnameDisplay; variável, onde o p é a inicial do plugin.
Plugin cubo igualmente ganhou a capacidade para alcançar as estruturas de cada um, que outros encaixes (plugins) podem usar demasiadamente. Isto é conseguido por uma função do núcleo que permita que plugin peça um displayPrivateIndex de outro plugin; o descanso é uma matéria de compartilhar um encabeçamento, ou seja, são as libs que estão em jogo.
Relacionamento com ambiente gráfico X
É preciso ter uma boa performance quando relacionamos o Ambiente Gráfico ao Sistema Operacional Linux, ambos aparentemente são os mesmos, mas na realidade o Sistema Operacional não está interligado ao Ambiente Gráfico, ou seja, o Ambiente Gráfico trabalha sobre a plataforma de baixo nível e faz parte do seu corpo estrutural, por isso o mesmo sabe fazer um bom gerenciamento da memoria RAM proporcionando, assim, uma boa flexibilidade e desempenho na hora da execução do programa.
O Ambiente Gráfico que mencionamos é chamado de X. Ele possibilita a que outros programas possam gerenciar as suas janelas, mas para que isso possa ter bom exito existem observações importantes a tratar, tais como o tamanho de tela, múltiplas telas, conhecidas como bigscreem e multscreem. Apesar de serem diferentes elas são de extrema importância na hora da execução.
O multHead é responsável por gerenciar os dois tratamento citados, seu objetivo principal é trabalhar em cabeçalho, na prática é como colocar várias pessoas usando a mesma máquina sem uma atrapalhar a outra. A idéia do multHead é baseado nesta otimização e melhor aproveitamento dos recursos que temos. Essa é uma idéia que surgiu basicamente da comunidade de software livre. Acho que a maior e primeira referência no assunto foi Alvils Stoss um letão (nascido na Letônia) que escreveu um patch para o kernel chamado Backstreet Ruby. Esse patch foi bem assimilado pela comunidade e mais tarde possibilitou o servidor X a suportar nativamente o conceito sem adaptações. O servidor X é “um capítulo a parte”. Na verdade a concepção dos sistemas Unix definem os recursos de vídeo através de uma aplicação remota cliente-servidor (X).
Esse processo de cabeçalho de compartilhamento X possui o mesmo efeito tanto para o Compiz, Xinerama, MergedFB, TwinView e XrandR. XRandR tem uma maneira diferente de começar a informação, mas para os plugins todas estas aproximações diferentes são transparentes. Na configuração ou instalação de cada cabeçalho possui duas exposições dentro do compscreen, ou seja, cada compscreen compartilha a mesma posição. Para cada tela teremos uma variável de exposição: 0.0 para a primeira, 0.1 para a segunda. Esses cabeçalhos são na maioria das vezes independentes e não possibilitam uma movimentação das janelas entre elas. A razão fundamental disso é poder usar cartões de vídeos múltiplos. Por isso não é difícil adicionar funcionalidades, como o DRI e o composit quando usamos cartões de vídeo.
Relacionamento de cabeçalho de códigos
Não há muito a pensar aproximadamente para a maioria de programadores quando utilizam multiscreen. Apenas certifique-se que você não mistura os dados de CompDisplay e de CompScreen. Também, nunca use d->screens sem dar um ciclo com ela. Em instalações normais, os d->screens referem-se a uma única tela, mas multscreen refere-se somente à varias telas. Uma regra é passar de algum modo o CompScreen sempre que você sabe que a função a usará. É seguro começar de screen->display, mas não diretamente CompDisplay.
Ao usar o multscreen verifique se o contexto esta correto antes de antes de modificar texturas. Isso pode facilmente ser feito usando o makescreencurrent, antes de fazer a modificação contextual. Todas as funções de núcleo que tratam textura fazem isso.
Bigscreen, entretanto, é ligeiramente mais complicado. Com bigscreen, nós tratamos somente o um CompScreen, mas o screen->outputDev entra no jogo. Por exemplo, há diferença entre a largura do monitor e a largura da tela. Além do que o Compiz igualmente se ajusta acima dos pontos diferentes de CompOutput para o desenho.
Para cada cabeçalho em um ambiente do bigscreen, os processos do paintOutput () são chamados. São chamados na “parte inferior” do paintScreen (), que é chamado somente uma vez por a tela real. O fullscreenOutput faz coisas ainda mais complicadas, que é um especial CompOutput que faça com que nós extraiamos à tela inteira, não apenas a parte superior.
s->width
Usado usado para tratar, larguras e as alturas saída-específicas.
s->height
Usado usado para tratar, larguras e as alturas saída-específicas.
makeScreenCurrent
Usado usado para tratar, Usado usado para tratar
CompDisplay
Usado usado para tratar saída, exposição, apresentação em tela,
CompScreen
Usado usado para tratar entrada. Um exemplo deste é a execução atual de ScreenGrabs. A entrada é tratada no contexto da exposição.
Referência: www.compiz-fusion.org
Por José Cleydson – https://www.gnu-lia.org/
