>O &chalk; é infinitamente extensível com plugins. As ferramentas, filtros e grandes blocos da interface do usuário, ou até mesmo os espaços de cores, são plugins. De fato, o &chalk; reconhece estes seis tipos de plugins: </para>
>O &chalk; em si consiste de três bibliotecas em camadas e de uma pasta com algumas classes comuns de suporte: chalkcolor, chalkimage e chalkui. Dentro do &chalk;, os objetos podem ser identificados por um <classname
>Uma palavra sobre a compatibilidade: o &chalk; está ainda em desenvolvimento. Do &chalk; 1.5 até o 1.6, não são esperadas muitas mudanças da API, mas poderão ocorrer algumas. Do &chalk; 1.6 para o 2.0 haverá uma mudança do &Qt;3 para o &Qt;4, do &kde;3 para o &kde;4, do <command
>: esperam-se muitas alterações. Se desenvolver um plugin para o &chalk; e optar por fazê-lo na versão em Subversion do &chalk;, você tem grandes chances de obter ajuda da equipe de desenvolvimento na passagem para a nova versão. Estas alterações também poderão levantar algumas partes deste documento que estejam desatualizadas. Verifique sempre a última documentação da API ou os arquivos de inclusão instalados no seu sistema. </para>
>A biblioteca 'libchalkimage' carrega os plugins de filtros e operações de pintura, e é responsável por lidar com os dados da imagem: mudar os pixels, compor e pintar. Os pincéis, paletas, gradientes e padrões são também carregados pela 'libchalkimage'. O nosso objetivo é tornar a 'libchalkimage' independente do &koffice;, mas atualmente nós compartilhamos o código de carregamento dos gradientes com o &koffice;. </para
>Não é possível, por enquanto, adicionar tipos novos de recursos, como os pincéis, paletas, gradientes ou padrões ao &chalk;. (A adição de pincéis, paletas, gradientes e padrões novos, obviamente.). O &chalk; segue as linhas-guia do projeto Create (<ulink url="http://create.freedesktop.org/"
>) para isso. A adição do suporte para o formato de pincéis do Photoshop precisa de algumas alterações na 'libchalkimage'; por outro lado, a adição de mais arquivos de dados de pincéis do 'gimp' não precisa. </para
>. Um exemplo destes filtros é a Máscara Não-Nítida.</para
></listitem>
<listitem
><para
>As operações de pintura são o conjunto de operações de pintura, como o desenho livre ou a circunferência, os sprays ou a borracha. As operações de pintura deverão estender a classe de base <classname
>KisPaintop</classname
>. Os exemplos de novas operações de pintura seriam o pincel de giz, um pincel a óleo ou um pincel programável complexo.</para
>A biblioteca 'libchalkui' carrega os plugins de ferramentas e de visualização. Esta biblioteca é um componente do &koffice;, mas também contém um conjunto de elementos úteis para outras aplicações gráficas. Talvez nós tenhamos que dividir esta biblioteca em 'chalkpart' e 'chalkui' na versão 2.0. Por enquanto, os criadores de programas não têm acesso a esta biblioteca e os criadores de plugins só têm permissão para usar esta biblioteca ao criar ferramentas ou plugins de visualização. O <classname
> ou de uma das classes de base especializadas, como a <classname
>KisToolPaint</classname
>, a <classname
>KisToolNonPaint</classname
> ou a <classname
>KisToolFreehand</classname
>. Uma nova ferramenta poderia ser uma ferramenta de seleção do objeto em primeiro plano. As ferramentas de pintura (e estas incluem as que pintam sobre os dados selecionados) poderão usar qualquer operação de pintura para determinar a forma como os pixels são alterados.</para
></listitem>
<listitem
><para
>Os plugins de visualização são KParts normais que usam o <command
> para se publicarem eles mesmos na interface de usuário do &chalk;. As opções do menu, as janelas, barras de ferramentas — qualquer tipo de extensão da interface poderá ser um plugin de visualização. De fato, algumas funcionalidades importantes como o suporte de programação do &chalk; é feita como um plugin de visualização.</para
>. Os filtros lêem e salvam os dados da imagem, em qualquer um da miríade de formatos de imagem existentes. Um exemplo de um novo filtro de importação/exportação do &chalk; será um filtro de PDF. Os filtros são carregados pelas bibliotecas do &koffice;. </para>
>Os plugins são escritos em C++ e poderão usar toda a API de programação do &kde;, do &Qt; e do &chalk;. Somente os plugins de visualização deverão usar a API do &koffice;. Não se preocupe: as APIs do &chalk; são bem claras e relativamente bem documentadas (no caso do 'software' livre); além disso, a codificação do seu primeiro filtro é realmente simples. </para
>Se você não quiser usar o C++, poderá criar programas em Python ou em Ruby; isto já é uma coisa diferente, e você atualmente não consegue criar ferramentas, espaços de cores, operações de pintura ou filtros de importação/exportação desta forma. </para
>Os plugins do &chalk; usam o mecanismo de componentes do &kde; para se carregarem; por isso, a documentação de componentes em <ulink url="http://developer.kde.org"
>A sua distribuição já deverá ter instalado os arquivos de inclusão relevantes para o &chalk;, ou poderá ter dividido os arquivos em pacotes de desenvolvimento do &koffice; ou do &chalk;. Você poderá encontrar a documentação da API pública do &chalk; em <ulink url="http://koffice.org/developer/apidocs/chalk/html/"
>O &kde; 3.x e, deste modo, o &koffice; 1.5 e o 1.6 usam o <command
>automake</command
>; o &kde; 4.0 e o &koffice; 2.0 usam o <command
>cmake</command
>. Este tutorial descreve a forma do <command
>automake</command
> criar plugins. </para
><para
>Os plugins são módulos do &kde; e deverão ser assinalados como tal no seu <filename
>Makefile.am</filename
>. Os filtros, ferramentas, operações de pintura, espaços de cores e filtros de importação/exportação necessitam dos arquivos <literal role="extension"
>.desktop</literal
>; os plugins de visualização necessitam de um arquivo do <application
> adicionalmente. A forma mais simples de começar é extrair o projeto 'chalk-plugins', do repositório de Subversion do &koffice;, e usá-lo como base para o seu próprio projeto. Nós pretendemos preparar um pacote com um esqueleto de plugin do &chalk; para o KDevelop, mas isso ainda não foi feito. </para>
> Este é o Makefile de um plugin de filtro. Substitua o <replaceable
>NOMEBIBLIOTECA</replaceable
> pelo nome da seu trabalho, e é tudo. </para
><para
>Se o seu plugin for de visualização, provavelmente você também instalou um arquivo <literal role="extension"
>.rc</literal
> com ítens para os menus e as barras de ferramentas. Da mesma forma, você poderá ter que instalar os cursores e os ícones. Isto tudo é feito com as magias do <filename
>Os filtros de importação e exportação de arquivos usam a plataforma de filtros genérica do &koffice; e precisam ser discutidos separadamente. </para>
</sect4>
<sect4 id="d-p-c-a-boilerplate">
<title
>Auxiliares</title>
<para
>Você também precisa de um pouco de código auxiliar, chamado de plataforma de componentes do &kde;, para instanciar o plugin — um arquivo de inclusão e um arquivo de implementação. </para
KisToolRegistry * r = dynamic_cast<KisToolRegistry*>( mae );
r -> add(new KisFerramentaEstrelafatory());
}
}
FerramentaEstrela::~FerramentaEstrela()
{
}
#include "ferramenta_estrela.moc"
</programlisting>
</para>
</sect4>
<sect4 id="d-p-c-a-registries">
<title
>Registros</title>
<para
>As ferramentas são carregadas pelo registro de ferramentas e registram-se elas mesmas com o registro de ferramentas. Os plugins, como as ferramentas, os filtros e as operações de pintura são carregados apenas uma vez: os plugins de visualização são carregados para cada janela criada. Note que são registradas 'factories' (fábricas de objetos), de um modo geral. Por exemplo, com as ferramentas, é criada uma nova instância de uma ferramenta para cada ponteiro (mouse, tablete, borracha). Uma operação de pintura nova é criada sempre que uma ferramenta recebe um evento de botão do mouse pressionado. </para>
<para
>Os filtros invocam o registro de filtros: <programlisting
>Lembre-se que isto significa que será criado um plugin de visualização para cada visualização que o usuário cria: a divisão de uma janela significa carregar todos os plugins de visualização novamente. </para>
>. Os plugins do &chalk; 1.6 serão provavelmente incompatíveis a nível binário com os do 1.5 e irão necessitar da versão 3. Os plugins do &chalk; 2.0 irão necessitar do número de versão 3. Sim, isto não totalmente lógico. </para>
>Os espaços de cores implementam a classe virtual pura <classname
>KisColorSpace</classname
>. Existem dois tipos de espaços de cores: aqueles que podem usar o <command
>lcms</command
> para as transformações de espaços de cores e aqueles que são muito estranhos para o <command
>lcms</command
> lidar com eles. Os exemplos dos primeiros são o 'cmyk', o 'rgb' ou o 'yuv'. Um exemplo do último é o de cores de água ou o molhado & pegajoso. Os espaços de cores que usam o <command
>lcms</command
> podem ser derivados do <classname
>KisAbstractColorSpace</classname
> ou de uma das classes de base especializadas para um determinado número de 'bits' por canal. </para
>A implementação de um espaço de cores é relativamente simples. O princípio geral é que os espaços de cores funcionam com uma lista simples de 'bytes'. A interpretação desses 'bytes' pertence ao espaço de cores. Por exemplo, um pixel em Cinza de 16 bits consiste em quatro 'bytes': dois para o valor de cinza e dois para o valor do 'alfa'. Você é livre para usar uma estrutura, de modo a lidar com a disposição em memória de um pixel, na sua implementação do espaço de cores, mas essa representação não é exportada. A única forma com que o resto do &chalk; consegue saber os canais e tipos de canais em que os pixels do seu espaço de cores consistem é através da classe <classname
>Esta classe define os canais que compõem um único pixel num espaço de cores em particular. Um canal tem as seguintes características importantes: </para>
<itemizedlist>
<listitem
><para
>um nome a apresentar na interface do usuário</para
></listitem>
<listitem
><para
>uma posição: o 'byte' onde os 'bytes' que representam este canal começam no pixel.</para
></listitem>
<listitem
><para
>um tipo: cor, alfa, substância ou substrato. A cor é uma cor simples, o 'alfa' é a capacidade de transparência, a substância é uma representação da quantidade de pigmento ou outras coisas do género e o substrato é a representação da área de desenho ou tela. (Lembre-se que isto pode ser mudado em breve.)</para
></listitem>
<listitem
><para
>um tipo de valor: 'byte', 'short', 'integer', 'float' — ou outro.</para
></listitem>
<listitem
><para
>tamanho: o número de 'bytes' que este canal ocupa</para
></listitem>
<listitem
><para
>cor: uma representação num <classname
>QColor</classname
> deste canal, para ser visualizado na interface do usuário como, por exemplo, em histogramas.</para
></listitem>
<listitem
><para
>uma abreviatura a usar na GUI, quando não existir muito espaço</para
>Um plugin de espaço de cores consegue suportar qualquer sub-conjunto destas operações de composição possíveis, mas o conjunto deverá sempre incluir o "OVER" (o mesmo que o "NORMAL") e o "COPY". O resto é mais ou menos opcional, ainda que quanto mais, melhor, obviamente. </para>
> podem ser divididos num conjunto de grupos: conversão, identificação e manipulação. </para
><para
>Todas as classes deverão ser capazes de converter um pixel de e para RGB de 8 bits (i.e., um <classname
>QColor</classname
>) e, de preferência, de e para L*a*b de 16 bits. Além disso, existe um método para converter para qualquer espaço de cores a partir do atual. </para
><para
>Os espaços de cores são descritos pelo vetor <classname
>KisChannelInfo</classname
>, o número de canais, o número de 'bytes' em cada pixel, se suporta imagens de Intervalo Altamente Dinâmico, entre outras definições. </para
><para
>A manipulação é, por exemplo, a combinação de dois pixels num único novo: bitBlt, escurecimento ou convolução de pixels. </para
><para
>Consulte por favor a documentação da API para uma descrição completa de todos os métodos que precisa implementar num espaço de cores. </para
><para
>O <classname
>KisAbstractColorSpace</classname
> implementa muitos dos métodos virtuais do <classname
>KisColorSpace</classname
>, usando as funções da biblioteca <command
>lcms</command
>. Sobre a classe <classname
>KisAbstractColorSpace</classname
>, existem classes de espaços de cores de inteiros de 8 e 16 bits, assim como de ponto flutuante de 16 e 32 bits, definindo as operações comuns para mudar a profundidade de cor. </para>
>Os filtros são plugins que examinam os pixels de uma camada e fazem alterações sobre eles. Apesar do &chalk; usar uma infra-estrutura de memória em blocos eficiente para guardar os pixels, os pixels criados pelos filtros não precisam se preocupar com a API de imagens do &Java;, Photoshop ou The Gimp, tendo apenas de tomar conta dos extremos dos blocos e de como <quote
>Lembre-se que é, teoricamente, simples substituir o armazenamento dos dados da imagem por outra infra-estrutura, mas essas infra-estruturas não são atualmente plugins reais, por razões de desempenho.</para
>O &chalk; usa iteradores para ler e gravar os valores dos pixels. Em alternativa, você poderá ler um bloco de pixels para uma área de memória, modificá-la e depois gravá-la de novo como um bloco. Mas isto não é necessariamente mais eficiente, até poderá ser mais lento que usar os iteradores; isto poderá ser apenas mais conveniente. Veja a documentação da API. </para
>As imagens do &chalk; são compostas por camadas, existindo atualmente em quatro tipos: camadas de pintura, camadas de grupo, camadas de ajuste (que contém um filtro aplicado, de forma dinâmica, às camadas abaixo da camada de ajuste) e camadas de componentes. Os filtros funcionam sempre em camadas de pintura. As camadas de pintura contém dispositivos de pintura, da classe <classname
>. Um dispositivo de pintura, por sua vez, dá acesso aos pixels em si. </para
><para
>Os <classname
>PaintDevice</classname
>s são normalmente passados como ponteiros compartilhados. Um ponteiro compartilhado mantém um registro dos locais em que o dispositivo de pintura é usado de fato e remove o dispositivo de pintura quando não for mais usado. Você poderá reconhecer a versão do ponteiro compartilhado de um dispositivo de pintura pelo seu sufixo <literal
>SP</literal
>. Basta lembrar-se que nunca terá que remover explicitamente um <classname
>KisPaintDeviceSP</classname
>. </para
><para
>Vejamos um filtro bastante simples, que inverte cada um dos pixels. O código para esse filtro está na pasta <filename class="directory"
> A função recebe dois dispositivos de pintura, um objeto de configuração (que não é usado neste filtro de exemplo) e um <varname
>rect</varname
>. O <varname
>rect</varname
> descreve a área do dispositivo de pintura, sobre a qual o filtro deverá atuar. Esta área está descrita em valores inteiros, o que significa que não existe qualquer precisão de sub-pixels. </para
><para
>O dispositivo de pintura <varname
>orig</varname
> é o local de onde ler, enquanto o <varname
>dest</varname
> serve para escrever nele. Estes parâmetros poderão apontar para o mesmo dispositivo de pintura atual ou serem dois dispositivos diferentes. (Nota: isto poderá mudar para apenas um dispositivo no futuro.) </para
>Isto cria um iterador para ler os pixels existentes. O Chalk possui três tipos de iteradores: horizontal, vertical e retangular. O iterador de retângulos é o caminho mais eficiente através dos dados da imagem, mas não garante nada sobre a localização do próximo pixel que devolve. Isto significa que não poderá garantir que o pixel que vai obter será adjacente ao pixel que você acabou de obter. Os iteradores de linhas verticais e horizontais, esses sim garantem a localização dos pixels que devolvem. </para
>(2) É criado o iterador de destino com a opção <literal
>write</literal
> igual a <literal
>true</literal
>. Isto significa que, se o dispositivo de pintura de destino for menor que o retângulo gravado, será automaticamente aumentado para caber todos os pixels sobre os quais vai iterar. Repare que existe aqui um potencial erro: se o <varname
>dest</varname
> e o <varname
>orig</varname
> não forem o mesmo dispositivo de pintura, então é bastante possível que os pixels devolvidos pelos iteradores não correspondam. Para cada posição do iterador, o <varname
>orig</varname
> poderá estar, por exemplo, em 165,200, enquanto o <varname
>dest</varname
> poderá estar em 20,8 — assim, a cópia que efetuar aqui poderá distorcer a imagem... </para
></callout>
<callout arearefs="invert3"
><para
>Você deseja saber se um pixel está selecionado? Isso é fácil — use o método <methodname
>isSelected</methodname
>. Mas o estado de selecionado não é uma propriedade binária de um pixel; um pixel poderá estar meio-selecionado, pouco selecionado ou praticamente selecionado. Esse valor também poderá ser obtido do iterador. As seleções são, de fato, um dispositivo de pintura de máscara, com um intervalo entre 0 e 255, onde o 0 é a ausência de seleção e o 255 é a seleção completa. O iterador possui dois métodos: <methodname
>isSelected()</methodname
> e <methodname
>selectedNess()</methodname
>. O primeiro devolve 'true' (verdadeiro), se um pixel estiver selecionado de qualquer forma (i.e., o valor da máscara é maior que 1), enquanto o outro devolve o valor da máscara. </para
></callout>
<callout arearefs="invert4"
><para
>Como observado acima, este <literal
>memcpy</literal
> é um grande erro, de fato... o <methodname
>rawData()</methodname
> devolve o vetor de 'bytes' que é o estado atual; o <methodname
>oldRawData()</methodname
> devolve o vetor de 'bytes', tal como estava antes de ter sido criado o iterador. Contudo, nós podemos estar copiando o pixel errado aqui. Na prática, isto não irá acontecer com muita freqüência, a menos que o <varname
>dest</varname
> já exista e não esteja alinhado com o <varname
>orig</varname
>. </para
></callout>
<callout arearefs="invert5"
><para
>Mas isto é correto: em vez de descobrir qual o 'byte' que corresponde a cada canal, usa-se uma função fornecida com todos os espaços de cores, para inverter os pixels atuais. Os espaços de cores possuem muitas operações com pixels que poderão ser usadas. </para
></callout>
</calloutlist>
<para
>Isto não tudo que existe para criar um filtro. Os filtros possuem outras duas componentes importantes: um objeto de configuração e um elemento gráfico de configuração. Os dois interagem intimamente. O elemento gráfico de configuração cria um objeto de configuração, mas também pode ser preenchido a partir de um objeto de configuração previamente existente. Os objetos de configuração poderão representar eles próprios como XML e poderão ser criados a partir de XML. Isto é o que torna as camadas de ajuste possíveis. </para>
<sect3 id="developers-plugins-filters-iterators">
<title
>Iteradores</title>
<para
>Existem três tipos de iteradores: </para>
<itemizedlist>
<listitem
><para
>Linhas horizontais</para
></listitem>
<listitem
><para
>Linhas verticais</para
></listitem>
<listitem
><para
>Iteradores retangulares</para
></listitem>
</itemizedlist>
<para
>Os iteradores de linhas horizontais e verticais possuem um método para mover o iterador para a próxima linha ou coluna: <methodname
>nextRow()</methodname
> e <methodname
>nextCol()</methodname
>. Usá-los é mais rápido que criar um iterador novo para cada linha ou coluna. </para
>Os iteradores são seguros em ambiente multitarefa no &chalk;; por isso, é possível dividir o trabalho por várias tarefas. Contudo, as versões futuras do &chalk; irão usar o método <methodname
> para saber se o seu filtro poderá ser aplicado em blocos da imagem (&ie;, todos os pixels modificados de forma independente, em vez de serem alterados por um valor determinado a partir de um exame sobre todos os pixels da imagem), distribuindo assim a execução do seu filtro por várias tarefas. </para>
> é uma estrutura que é usada para gravar a configuração do filtro em disco como, por exemplo, nas camadas de ajuste. O plugin de programação usa o mapa de propriedades, que está na base do <classname
>, para ser possível programar os filtros. Os filtros poderão oferecer um elemento gráfico personalizado, que o &chalk; irá mostrar na galeria de filtros, na janela de previsão do filtro ou na página de opções da ferramenta de pintura-com-filtros. </para>
>A maioria dos filtros poderá ser ajustada pelo usuário. Você poderá criar um elemento gráfico de configuração que o Chalk irá usar, sempre que o filtro for usado. Um exemplo: </para>
>Repare que só a parte esquerda desta janela é da sua responsabilidade: o &chalk; toma conta do resto. Existem três abordagens para criar um elemento gráfico de opção: </para>
>Use o &Qt; Designer para criar um base para o elemento gráfico e crie uma sub-classe para o seu filtro</para
></listitem>
<listitem
><para
>Use um dos elementos gráficos simples que mostram um conjunto de barras deslizantes, no caso das listas de números inteiros, números de ponto flutuante ou booleanos. Eles são úteis se, como na imagem acima, se o seu filtro puder ser configurado com um conjunto de inteiros, números de ponto flutuante ou booleanos. Veja a documentação da API do <classname
>Crie um elemento gráfico manualmente. Esta forma não é a recomendada e, se você fizer isso e quiser que o seu filtro se torne parte da versão oficial do &chalk;, então recomenda-se que substitua o seu elemento gráfico codificado à mão por uma versão com o &Qt; Designer.</para
list.insert(list.begin(), new KisOilPaintFilterConfiguration( 1, 30));
return list;
}
</programlisting>
<para
>Você pode ver como ele funciona: ele preenche um vetor com os seus parâmetros inteiros e cria o elemento gráfico. O método <methodname
>configuration()</methodname
> inspeciona o elemento e cria o objeto de configuração do filtro correto, nesse caso, o <classname
>KisOilPaintFilterConfiguration</classname
>. O método <methodname
>listOfExamplesConfiguration</methodname
> (que deverá mudar de nome para um Inglês correto...) devolve uma lista com objetos de configuração de exemplo, para a janela da galeria de filtros. </para>
>Existem mais alguns pontos sobre a codificação de filtros interessantes mas, com esta explicação, a documentação da API e o acesso ao nosso código-fonte, você deverá ser capaz de ter uma boa introdução. Não hesite em contactar a equipe de desenvolvimento do &chalk; no IRC ou na lista de correio. </para>
>As ferramentas aparecem na área de ferramentas do &chalk;. Isto significa que existe um espaço limitado para as ferramentas novas — pense com cuidado, sempre que uma operação de pintura não for o suficiente para os seus fins. As ferramentas poderão usar o mouse/tablete e o teclado de formas complexas, coisa que as operações de pintura não conseguem. Esta é a razão pela qual o Duplicar é uma ferramenta e o spray é uma operação de pintura. </para
>Tenha cuidado com os dados estáticos na sua ferramenta: é criada uma instância nova da sua ferramenta para cada dispositivo de entrada: o mouse, caneta, borracha, spray — o que for. As ferramentas estão divididas em grupos lógicos: </para>
<itemizedlist>
<listitem
><para
>ferramentas de desenho de formas (círculo, retângulo)</para
></listitem>
<listitem
><para
>ferramentas de desenho livre (pincel)</para
></listitem>
<listitem
><para
>ferramentas de transformação que mexem na geometria de uma camada</para
></listitem>
<listitem
><para
>ferramentas de preenchimento (como o balde ou o gradiente)</para
></listitem>
<listitem
><para
>ferramentas de visualização (que não mudam os pixels, mas sim a forma como você vê a tela, como a ampliação)</para
></listitem>
<listitem
><para
>ferramentas de seleção (que mudam a máscara de seleção)</para
></listitem>
</itemizedlist>
<para
>A interface da ferramenta está descrita na documentação da API da classe <classname
>KisTool</classname
>. Existem três sub-classes: <classname
>KisToolPaint</classname
>, <classname
>KisToolNonPaint</classname
> e <classname
>KisToolShape</classname
> (que é, de fato, uma sub-classe de <classname
>KisToolPaint</classname
>), que especializa a <classname
>KisTool</classname
> para as ferramentas de pintura (i.e., mudando os pixels), as tarefas sem ser de pintura e as tarefas de pintura de formas. </para
>Uma ferramenta possui um elemento gráfico de opções, como os filtros. Atualmente, os elementos gráficos aparecem numa página de uma janela acoplável. Nós poderemos mudar esta para uma barra fina, sob o menu principal (que por sua vez substitui a barra de ferramentas) no &chalk; 2.0 mas, por enquanto, desenhe o seu elemento gráfico de opções para caber numa página. Como sempre, é melhor usar o &Qt; Designer para desenhar este elemento gráfico. </para
>O construtor define o nome interno — que não é traduzido — e a chamada à super-classe define o nome visível. Nós também poderemos carregar a imagem do cursor e definir um conjunto de variáveis. </para>
>) são invocados pelo &chalk; quando o dispositivo de entrada (mouse, caneta, borracha, etc.) for pressionado, mudado de posição ou solto. Lembre-se que você também obtém mais eventos se o botão do mouse não for pressionado. Os eventos não são os normais, mas sim eventos sintéticos do &chalk;, uma vez que ele tira partido de alguns truques de baixo nível para obter eventos suficientes para desenhar uma linha suave. Por padrão, as bibliotecas, como o &Qt; (e o GTK), perdem eventos se estiverem muito ocupadas para tratar deles, e nós desejamos obter todos eles. </para>
> é essencial: aqui nós criamos a ação que será ligada à área de ferramentas, para que os usuários possam de fato selecionar a ferramenta. Também é possível atribuir uma tecla de atalho. Repare que existem alguns truques aqui: lembre-se que é criada uma instância da ferramenta para cada dispositivo de entrada. Isto também significa que é chamado o método <methodname
>setup()</methodname
> para cada dispositivo de entrada, e isso significa que é adicionada uma ação com o mesmo nome, várias vezes, à coleção de ações. Contudo, tudo parece funcionar, então porque preocupar-se? </para>
> é chamado para criar o elemento gráfico das opções que o &chalk; irá mostrar na página. Uma vez que existe uma ferramenta para cada dispositivo de entrada, para cada janela, o estado de uma ferramenta poderá ser mantido na ferramenta. Este método só é chamado uma vez: o elemento de opções é guardado e obtido da próxima vez que a ferramenta for ativada. </para>
>As operações de pintura são um dos tipos de plugins mais inovadores no Chalk (em conjunto com os espaços de cores acopláveis). Uma operação de pintura define a forma como as ferramentas mudam os pixels que tocam. O 'spray', o lápis ou o pincel suave: todos eles são operações de pintura. Mas você pode — com muito trabalho — criar uma operação de pintura que leia as definições de pincéis do Corel Painter em XML e usá-las para determinar a forma como a pintura é feita. </para
>As operações de pintura são instanciadas sempre que uma ferramenta de pintura receber um evento <literal
>mouseDown</literal
> e são removidas quando o evento 'mouseUp' for recebido por uma ferramenta de pintura. Entretanto, a operação poderá manter um registro das posições anteriores e os outros dados, como os níveis de pressão, se o usuário usar uma tablete. </para
><para
>A operação básica de uma operação de pintura é mudar os pixels na posição atual do cursor de uma ferramenta. Isto só poderá ser feito uma vez, ou a ferramenta poderá pedir para ser executada em intervalos regulares, graças a um temporizador. A primeira seria útil para uma operação do tipo lápis, enquanto a segunda, obviamente, para uma operação do tipo 'spray'. </para
>As operações de pintura poderão ter um pequeno elemento gráfico, que é colocado numa barra de ferramentas. Deste modo, os elementos de configuração das operações de pintura precisam ter uma disposição horizontal dos elementos gráficos, não mais altas do que um botão da barra de ferramentas. Caso contrário, o &chalk; ficará bastante engraçado. </para
>Vejamos um simples plugin de pintura, um que mostra alguma inteligência de programação. Primeiro, no arquivo de inclusão, está definida uma 'factory' (fábrica de instâncias). Este objeto cria uma operação de pintura, sempre que a ferramenta ativa precisar de uma: </para>
> com o nome público e o privado da operação de pintura — certifique-se de que o nome privado da sua operação de pintura não entra em conflito com outra operação! — e poderá devolver, opcionalmente, uma imagem. O &chalk; poderá então mostrar a imagem em conjunto com o nome, para uma identificação visual da sua operação. Por exemplo, uma operação de faca do pintor teria a imagem com um instrumento desse tipo. </para
> está realmente onde deveria estar, com as operações de pintura. Este método recebe dois parâmetros: a posição atual (que está com números de ponto flutuante, não em pixels) e um objeto <classname
>KisPaintInformation</classname
>, que contém a pressão, o toque em 'x' e 'y' e o vetor de movimento, podendo ser extendido no futuro com outras informações. </para>
<programlisting
>if (!m_painter->device()) return;
KisBrush *pincel = m_painter->brush();
</programlisting>
<para
>Um <classname
>KisBrush</classname
> é a representação de um arquivo de pincel do Gimp: ele é uma máscara, seja ela simples ou uma série de máscaras. De fato, não é usado aqui o pincel, exceto para determinar o <quote
>Não são alterados diretamente os pixels de um dispositivo de pintura: em vez disso, é criado um pequeno dispositivo de pintura, um 'dab', sendo ele composto no dispositivo de pintura atual. </para>
<programlisting
>m_painter->setPressure(info.pressure);
</programlisting>
<para
>Como dizem os comentários, o próximo bloco de código efetua algum trabalho de programação para criar o 'dab' atual. Nesse caso, é desenhado um conjunto de linhas. Quando se terminar esta operação de pintura, o comprimento, a posição e a espessura das linhas será dependente da pressão e carga da tinta, e nós criamos um pincel forte e húmido. Mas ainda eu ainda não tive tempo para terminar isto. </para>
<programlisting
>// Calcular a posição dos tufos. Os tufos estão organizados numa linha
// perpendicular ao movimento do pincel, i.e, a linha a direito entre
for (int i = 0; i < (NUMBER_OF_TUFTS / 2); ++i) {
// Calcular as posições do vetor novo.
vl = listaPontoatual + i * vetorPincel;
KisPoint pl = vl.toKisPoint();
dab->setPixel(pl.roundX(), pl.roundY(), kc);
vr = listaPontoatual - i * vetorPincel;
KisPoint pr = vr.toKisPoint();
dab->setPixel(pr.roundX(), pr.roundY(), kc);
}
vr = vr - vl;
vr.normalize();
</programlisting>
<para
>Finalmente, é desenhado o 'dab' no dispositivo de pintura original e é dito ao pintor que se atualizou um pequeno retângulo do dispositivo de pintura. </para>
<programlisting
>if (m_source->hasSelection()) {
m_painter->bltSelection(x - 32, y - 32, m_painter->compositeOp(), dab.data(),
m_source->selection(), m_painter->opacity(), x - 32, y -32, 64, 64);
}
else {
m_painter->bitBlt(x - 32, y - 32, m_painter->compositeOp(), dab.data(), m_painter->opacity(), x - 32, y -32, 64, 64);
}
m_painter->addDirtyRect(QRect(x -32, y -32, 64, 64));
>Isto é tudo: as operações de pintura são simples e divertidas! </para>
</sect2>
<sect2 id="developers-plugins-viewplugins">
<title
>Plugins de visualização</title>
<para
>Os plugins de visualização ou da janela são os mais esquisitos do grupo: um plugin de visualização é um KPart normal, que poderá fornecer alguma interface do usuário e alguma funcionalidade. Por exemplo, a página do histograma é um plugin de visualização, assim como a janela de rotação. </para>
>O &chalk; funciona com a arquitetura de filtros de arquivos do &koffice;. Existe um tutorial, um pouco antigo mas ainda útil, em: <ulink url="http://koffice.org/developer/filters/oldfaq.php"
>. É provavelmente melhor cooperar com a equipe do &chalk; ao desenvolver filtros de arquivos e fazer o desenvolvimento na árvore de filtros do &koffice;. Lembre-se que você poderá testar os seus filtros, sem executar o &chalk;, usando o utilitário <command
>O grande problema com os filtros de importação é, obviamente, o seu código para ler os dados em disco. O código auxiliar que invoca este código é relativamente simples: </para>
>Nota: é mesmo realmente necessária uma forma para permitir ao &chalk; manter um arquivo aberto, e ler apenas os dados à medida das necessidades, em vez de copiar o conteúdo inteiro para a representação interna do dispositivo de pintura. Mas isso iria significar infra-estruturas de gerenciamento de dados que percebam os arquivos TIFF, entre outros, e isso ainda não está implementado atualmente. Seria o ideal se alguns filtros de arquivos pudessem implementar uma classe temporária chamada <classname
>, criassem um objeto dessa instância com o arquivo atual e o passassem ao KisDoc. Mas o &chalk; lida com o armazenamento por camadas, não por documentos, por isso seria uma fatorização difícil de fazer.</para
>, uma vez que os documentos do &chalk; precisam de um tratamento especial. Não seria, contudo, má ideia verificar se o resultado da conversão não é 0, porque se for, a importação irá falhar.</para
>Se invocarmos este filtro a partir da GUI, teremos que obter uma visão. Se existir, o código de conversão poderá tentar atualizar a barra de progresso.</para
></callout>
<callout arearefs="import4"
><para
>O filtro tem o nome do arquivo de entrada.</para
></callout>
<callout arearefs="import5"
><para
>O <classname
>KisDoc</classname
> precisa se preparar para a importação. Algumas configurações são inicializadas e a opção para desfazer é desativada. Caso contrário, poderia anular a adição de camadas efetuadas pelo filtro de importação, e isso seria um comportamento estranho.</para
></callout>
<callout arearefs="import6"
><para
>Eu optei por implementar o código de importação atual numa classe separada que é aqui instanciada. Você poderá também colocar todo o seu código neste método, mas isso ficaria um pouco confuso.</para
></callout>
<callout arearefs="import7"
><para
>O módulo de importação devolve um código de estado que poderá ser usado para configurar depois o estado do filtro de importação. O &koffice; toma conta de mostrar as mensagens de erro.</para
></callout>
<callout arearefs="import8"
><para
>Se a criação do <classname
>KisImage</classname
> foi bem sucedida, nós configuraremos a imagem atual do documento com a imagem recém criada. Então, isto é tudo: <literal
