O &krita; é infinitamente extensível com 'plugins'. As ferramentas, filtros e grandes blocos da interface do utilizador, ou até mesmo os espaços de cores, são 'plugins'. De facto, o &krita; reconhece estes seis tipos de 'plugins': espaços de cores — estes definem os canais que constituem um único pixel ferramentas — tudo o que é feito com um rato ou outro dispositivo de apontamento operações de pintura — efeitos de pintura acopláveis para as ferramentas filtros de imagens — muda todos os pixels, ou apenas os pixels seleccionados de uma camada 'plugins' de visualização — extende a interface de utilizador do Krita com novas janelas, paletas e operações filtros de importação/exportação — lê e grava todos os tipos de formatos de imagem O &krita; em si consiste em três bibliotecas em camadas e numa pasta com algumas classes comuns de suporte: kritacolor, kritaimage e kritaui. Dentro do &krita;, os objectos podem ser identificados por um KisID, que é a combinação de um texto não-traduzido único (usado ao gravar, por exemplo) e um texto traduzido, para fins de interface. Uma palavra acerca da compatibilidade: o &krita; está ainda em desenvolvimento. Desde o &krita; 1.5 até ao 1.6, não são esperadas muitas mudanças da API, mas poderão ocorrer algumas. Do &krita; 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 automake para o cmake: esperam-se muitas alterações. Se desenvolver um 'plugin' para o &krita; e optar por fazê-lo na versão em Subversion do &krita;, tem excelentes hipóteses de obter ajuda da equipa de desenvolvimento na passagem para a nova versão. Estas alterações também poderão levantar algumas partes deste documento que estejam desactualizadas. Verifique sempre a última documentação da API ou os ficheiros de inclusão instalados no seu sistema. A primeira biblioteca é a 'kritacolor'. Esta biblioteca carrega os 'plugins' de espaços de cores. Um 'plugin' de espaço de cores deverá implementar a classe abstracta KisColorSpace ou, se as capacidades básicas do novo espaço de cores forem implementadas pelo lcms (), extender o KisAbstractColorSpace. A biblioteca 'kritacolor' poderá ser usada noutras aplicações e não depende do &koffice;. A biblioteca 'libkritaimage' 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 'libkritaimage'. O nosso objectivo é tornar a 'libkritaimage' independente do &koffice;, mas partilha-se neste momento o código de carregamento dos gradientes no &koffice;. Não é possível, de momento, adicionar tipos novos de recursos, como os pincéis, paletas, gradientes ou padrões ao &krita;. (A adição de pincéis, paletas, gradientes e padrões novos, obviamente.). O &krita; segue as linhas-guia do projecto Create () para tal. A adição do suporte para o formato de pincéis do Photoshop precisa de algumas alterações na 'libkritaimage'; a adição de mais ficheiros de dados de pincéis do 'gimp' não precisa, por outro lado. O KritaImage carrega os seguintes tipos de 'plugins': Os filtros do &krita; deverão extender e implementar a classe abstracta KisFilter, KisFilterConfiguration e, possivelmente, a KisFilterConfigurationWidget. Um exemplo destes filtros é a Máscara Não-Afiada. 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 extender a classe de base KisPaintop. Os exemplos de novas operações de pintura seriam o pincel de giz, um pincel a óleo ou um pincel programável completo. A biblioteca 'libkritaui' 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 se tenha de dividir esta biblioteca em 'kritapart' e 'kritaui' na versão 2.0. Por agora, 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 KritaUI carrega os seguintes tipos de 'plugins': As ferramentas derivam da KisTool ou de uma das classes de base especializadas, como a KisToolPaint, a KisToolNonPaint ou a KisToolFreehand. Uma nova ferramenta poderia ser uma ferramenta de selecção do objecto em primeiro plano. As ferramentas de pintura (e estas incluem as que pintam sobre os dados seleccionados) poderão usar qualquer operação de pintura para determinar a forma como os pixels são alterados. Os 'plugins' de visualização são KParts normais que usam o kxmlgui para se publicarem eles mesmos na interface de utilizador do &krita;. 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 facto, algumas funcionalidades importantes como o suporte de programação do &krita; é feita como um 'plugin' de visualização. Os filtros de importação/exportação são os filtros do &koffice;, sub-classes de KoFilter. Os filtros lêem e gravam 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 &krita; será um filtro de PDF. Os filtros são carregados pelas bibliotecas do &koffice;. Os 'plugins' são criados em C++ e poderão usar toda a API de programação do &kde;, do &Qt; e do &krita;. Só os 'plugins' de visualização deverão usar a API do &koffice;. Não se preocupe: as APIs do &krita; são bastantes claras e relativamente bem documentadas (no caso do 'software' livre); para além disso, a codificação do seu primeiro filtro é realmente simples. Se não quiser usar o C++, poderá criar programas em Python ou em Ruby; isto já é uma coisa diferente, e não consegue criar de momento as ferramentas, os espaços de cores, as operações de pintura ou os filtros de importação/exportação desta forma. Os 'plugins' do &krita; usam o mecanismo de componentes do &kde; para se carregarem; por isso, a documentação de componentes em também é aqui relevante. A sua distribuição já deverá ter instalado os ficheiros de inclusão relevantes para o &krita; em si, ou poderá ter dividido os ficheiros em pacotes de desenvolvimento do &koffice; ou do &krita;. Poderá encontrar a documentação da API pública do &krita; em . O &kde; 3.x e, deste modo, o &koffice; 1.5 e o 1.6 usam o automake; o &kde; 4.0 e o &koffice; 2.0 usam o cmake. Este tutorial descrevem a forma do automake criar 'plugins'. Os 'plugins' são módulos do &kde; e deverão ser assinalados como tal no seu Makefile.am. Os filtros, ferramentas, operações de pintura, espaços de cores e filtros de importação/exportação necessitam dos ficheiros .desktop; os 'plugins' de visualização necessitam de um ficheiro do KXMLGui nomeplugin.rc adicionalmente. A forma mais simples de começar é extrair o projecto 'krita-plugins', do repositório de Subversion do &koffice;, e usá-lo como base para o seu próprio projecto. Pretende-se preparar um pacote com um esqueleto de 'plugin' do &krita; para o KDevelop, mas tal ainda não foi feito. Vejamos um esqueleto de um módulo de 'plugin'. Em primeiro lugar, o Makefile.am. Isto é o que o &kde; usa para gerar a Makefile que cria o seu 'plugin': kde_services_DATA = kritaNOMEBIBLIOTECA.desktop INCLUDES = $(all_includes) kritaNOMEBIBLIOTECA_la_SOURCES = ficheiro1.cc ficheiro2.cc kde_module_LTLIBRARIES = kritaNOMEBIBLIOTECA.la noinst_HEADERS = inclusao1.h inclusao2.h kritaNOMEBIBLIOTECA_la_LDFLAGS = $(all_libraries) -module $(KDE_PLUGIN) kritaBIBLIOTECA_la_LIBADD = -lkritacommon kritaextensioncolorsfilters_la_METASOURCES = AUTO Esta é a Makefile de um 'plugin' de filtro. Substitua o NOMEBIBLIOTECA pelo nome da seu trabalho, e é tudo. Se o seu 'plugin' for de visualização, provavelmente também instalou um ficheiro .rc com itens para os menus e as barras de ferramentas. Da mesma forma, poderá ter de instalar os cursores e os ícones. Isto é tudo feito com as magias do Makefile.am do &kde;: kritarcdir = $(kde_datadir)/krita/kritaplugins kritarc_DATA = NOMEBIBLIOTECA.rc EXTRA_DIST = $(kritarc_DATA) kritapics_DATA = \ bla.png \ bla_cursor.png kritapicsdir = $(kde_datadir)/krita/pics O ficheiro .desktop anuncia o tipo de 'plugin': [Desktop Entry] Encoding=UTF-8 Icon= Name=Nome Visível ServiceTypes=Krita/Filter Type=Service X-KDE-Library=kritaNOMEBIBLIOTECA X-KDE-Version=2 Os ServiceTypes (tipos de serviços) possíveis são: Krita/Filter Krita/Paintop Krita/ViewPlugin Krita/Tool Krita/ColorSpace Os filtros de importação e exportação de ficheiros usam a plataforma de filtros genérica do &koffice; e necessitam de ser discutidos em separado. Também precisa de um pouco de código auxiliar, chamado de plataforma de componentes do &kde;, para instanciar o 'plugin' — um ficheiro de inclusão e um ficheiro de implementação. Um ficheiro de inclusão: #ifndef FERRAMENTA_ESTRELA_H_ #define FERRAMENTA_ESTRELA_H_ #include <kparts/plugin.h> /** * Um módulo que oferece uma ferramenta de estrela. */ class FerramentaEstrela : public KParts::Plugin { Q_OBJECT public: FerramentaEstrela(QObject *mae, const char *nome, const QStringList &); virtual ~FerramentaEstrela(); }; #endif // TOOL_STAR_H_ E um ficheiro de implementação: #include <kinstance.h> #include <kgenericfactory.h> #include <kis_tool_registry.h> #include "ferramenta_estrela.h" #include "kis_ferramenta_estrela.h" typedef KGenericFactory<FerramentaEstrela> FerramentaEstrelaFactory; K_EXPORT_COMPONENT_FACTORY( kritatoolstar, FerramentaEstrelaFactory( "krita" ) ) FerramentaEstrela::FerramentaEstrela(QObject *mae, const char *nome, const QStringList &) : KParts::Plugin(mae, nome) { setInstance(FerramentaEstrelaFactory::instance()); if ( mae->inherits("KisToolRegistry") ) { KisToolRegistry * r = dynamic_cast<KisToolRegistry*>( mae ); r -> add(new KisFerramentaEstrelaFactory()); } } FerramentaEstrela::~FerramentaEstrela() { } #include "ferramenta_estrela.moc" As ferramentas são carregadas pelo registo de ferramentas e registam-se elas mesmas com o registo 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 por cada janela criada. Repare que são registadas 'factories' (fábricas de objectos), de um modo geral. Por exemplo, com as ferramentas, é criada uma nova instância de uma ferramenta por cada ponteiro (rato, tablete, borracha). Uma operação de pintura nova é criada sempre que uma ferramenta recebe um evento de botão do rato pressionado. Os filtros invocam o registo de filtros: if (mae->inherits("KisFilterRegistry")) { KisFilterRegistry * gestor = dynamic_cast<KisFilterRegistry *>(mae); gestor->add(new KisFilterInvert()); } As operações de pintura invocam o seu registo respectivo: if ( mae->inherits("KisPaintOpRegistry") ) { KisPaintOpRegistry * r = dynamic_cast<KisPaintOpRegistry*>(mae); r -> add ( new KisSmearyOpFactory ); } Os espaços de cores procuram no registo de espaços de cores (com mais algumas complicações): if ( mae->inherits("KisColorSpaceFactoryRegistry") ) { KisColorSpaceFactoryRegistry * f = dynamic_cast<isColorSpaceFactoryRegistry*>(mae); KisProfile *perfilOmissao = new KisProfile(cmsCreate_sRGBProfile()); f->addProfile(perfilOmissao); KisColorSpaceFactory * fabrica = new KisRgbColorSpaceFactory(); f->add(fabrica); KisColorSpace * espacoCoresRGBA = new KisRgbColorSpace(f, 0); KisHistogramProducerFactoryRegistry::instance() -> add( new KisBasicHistogramProducerFactory<KisBasicU8HistogramProducer> (KisID("RGB8HISTO", i18n("RGB8 Histogram")), espacoCoresRGBA) ); } Os 'plugins' de visualização não têm de se registar elas mesmas, obtendo o acesso a um objecto KisView object: if ( mae->inherits("KisView") ) { setInstance(ShearImageFactory::instance()); setXMLFile(locate("data","kritaplugins/shearimage.rc"), true); (void) new KAction(i18n("&Shear Image..."), 0, 0, this, SLOT(slotShearImage()), actionCollection(), "shearimage"); (void) new KAction(i18n("&Shear Layer..."), 0, 0, this, SLOT(slotShearLayer()), actionCollection(), "shearlayer"); m_vista = (KisView*) mae; } Lembre-se que isto significa que será criado um 'plugin' de visualização, de cada vez que o utilizador cria: a divisão de uma janela significa um novo carregamento de todos os 'plugins' de visualização de novo. O &krita; 1.5 carrega os 'plugins' com o X-KDE-Version=2 definido no ficheiro .desktop. Os 'plugins' do &krita; 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 &krita; 2.0 irão necessitar do número de versão 3. Sim, isto não de todo lógico. Os espaços de cores implementam a classe virtual pura KisColorSpace. Existem dois tipos de espaços de cores: aqueles que podem usar o lcms para as transformações de espaços de cores e aqueles que são demasiado estranhos para o lcms 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 lcms podem ser derivados do KisAbstractColorSpace ou de uma das classes de base especializadas para um dado número de 'bits' por canal. 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 Cinzento de 16 bits consiste em quatro 'bytes': dois para o valor de cinzento e dois para o valor do 'alfa'. Está à vontade 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 &krita; consegue saber os canais e tipos de canais em que os pixels do seu espaço de cores consistem é através da classe KisChannelInfo. Os filtros e operações de pintura tiram partido do conjunto rico de métodos oferecidos pelo KisColorSpace, para fazer o seu trabalho. Em muitos dos casos, a implementação predefinida no KisAbstractColorSpace irá funcionar, mas de forma mais lenta que uma implementação personalizada no seu espaço de cores, dado que o KisAbstractColorSpace irá converter todos os pixels para L*a*b de 16 bits e vice-versa. (http://websvn.kde.org/trunk/koffice/krita/kritacolor/kis_channelinfo.h) 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: um nome a apresentar na interface do utilizador uma posição: o 'byte' onde os 'bytes' que representam este canal começam no pixel. 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 factorizado em breve.) um tipo de valor: 'byte', 'short', 'integer', 'float' — ou outro. tamanho: o número de 'bytes' que este canal ocupa cor: uma representação num QColor deste canal, para ser visualizado na interface do utilizador como, por exemplo, em histogramas. uma abreviatura a usar na GUI, quando não existir muito espaço Um Porter-Duff por original; existem várias formas de combinar os pixels para obter uma cor nova. A classe KisCompositeOp define a maior parte delas: este conjunto não é facilmente extensível, excepto se modificar a biblioteca 'kritacolor'. 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, como é óbvio. Os métodos da classe virtual pura KisColorSpace podem ser divididos num conjunto de grupos: conversão, identificação e manipulação. Todas as classes deverão ser capazes de converter um pixel de e para RGB de 8 bits (i.e., um QColor) e, de preferência, de e para L*a*b de 16 bits. Para além disso, existe um método para converter para qualquer espaço de cores a partir do actual. Os espaços de cores são descritos pelo vector KisChannelInfo, 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. A manipulação é, por exemplo, a combinação de dois pixels num único novo: bitBlt, escurecimento ou convolução de pixels. Consulte por favor a documentação da API para uma descrição completa de todos os métodos que necessita de implementar num espaço de cores. O KisAbstractColorSpace implementa muitos dos métodos virtuais do KisColorSpace, usando as funções da biblioteca lcms. Sobre a classe KisAbstractColorSpace, existem classes de espaços de cores de inteiros de 8 e 16 bits, assim como de vírgula flutuante de 16 e 32 bits, definindo as operações comuns para mudar de profundidades de cor. Os filtros são 'plugins' que examinam os pixels de uma camada e fazem alterações sobre eles. Ainda que o &krita; usa uma infra-estrutura de memória em blocos eficiente, para guardar os pixels, os criados de filtros não têm de se preocupar com a API de imagens do &Java;, o Photoshop ou o The Gimp, tendo apenas de tomar conta dos extremos dos blocos e de como colar os blocos em conjunto: o &krita; esconde esse detalhe de implementação. Lembre-se que é, teoricamente, simples de substituir o armazenamento dos dados da imagem por outra infra-estrutura, mas essas infra-estruturas não são 'plugins' reais de momento, por razões de performance. O &krita; usa iteradores para ler e gravar os valores dos pixels. Em alternativa, 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; poderá ser apenas mais conveniente. Veja a documentação da API. As imagens do &krita; são compostas por camadas, das quais existem de momento 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 KisPaintDevice. Um dispositivo de pintura, por sua vez, dá acesso aos pixels em si. Os PaintDevices são normalmente passados como ponteiros partilhados. Um ponteiro partilhado mantém um registo dos locais em que o dispositivo de pintura é usado de facto e remove o dispositivo de pintura quando não for mais usado. Poderá reconhecer a versão do ponteiro partilhado de um dispositivo de pintura pelo seu sufixo SP. Basta lembrar-se que nunca terá de remover explicitamente um KisPaintDeviceSP. Vejamos um filtro bastante simples, que inverte cada um dos pixels. O código para esse filtro está na pasta koffice/krita/plugins/filters/example directory. O método principal é o KisFilterInvert::process(KisPaintDeviceSP orig, KisPaintDeviceSP dest, KisFilterConfiguration* /*config*/, const QRect& rect). A função recebe dois dispositivos de pintura, um objecto de configuração (que não é usado neste filtro de exemplo) e um rect. O rect descreve a área do dispositivo de pintura, sobre a qual o filtro deverá actuar. Esta área está descrita em valores inteiros, o que significa que não existe qualquer precisão de sub-pixels. O dispositivo de pintura orig é o local de onde ler, enquanto o dest serve para escrever nele. Estes parâmetros poderão apontar para o mesmo dispositivo de pintura actual ou serem dois dispositivos diferentes. (Nota: isto poderá mudar para apenas um dispositivo no futuro.) Agora, vejamos o código linha-a-linha: void KisFilterInvert::process(KisPaintDeviceSP orig, KisPaintDeviceSP dest, KisFilterConfiguration* /*config*/, const QRect& rect) { Q_ASSERT(src != 0); Q_ASSERT(dst != 0); KisRectIteratorPixel origIt = orig->createRectIterator(rect.x(), rect.y(), rect.width(), rect.height(), false); KisRectIteratorPixel destIt = dest->createRectIterator(rect.x(), rect.y(), rect.width(), rect.height(), true ); int pixelsProcessados = 0; setProgressTotalSteps(rect.width() * rect.height()); KisColorSpace * cs = orig->colorSpace(); Q_INT32 ptamanho = cs->pixelSize(); while( ! origIt.isDone() ) { if(origIt.isSelected()) { memcpy(destIt.rawData(), origIt.oldRawData(), ptamanho); cs->invertColor( destIt.rawData(), 1); } setProgress(++pixelsProcessados); ++origIt; ++destIt; } setProgressDone(); // Deverá ser chamado, mesmo que não suporte de facto a progressão } Isto cria um iterador para ler os pixels existentes. O Krita tem três tipos de iteradores: horizontal, vertical e rectangular. O iterador de rectângulos é o caminho mais eficiente pelos 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 tem de momento. Os iteradores de linhas verticais e horizontais, esses sim garantem a localização dos pixels que devolvem. (2) É criado o iterador de destino com a opção write igual a true. Isto significa que, se o dispositivo de pintura de destino for menor que o rectângulo gravado, será automaticamente aumentado para caber todos os pixels sobre os quais vai iterar. Repare que existe aqui um potencial erro: se o dest e o orig 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 orig poderá estar, por exemplo, em 165,200, enquanto o dest poderá estar em 20,8 — como tal, a cópia que efectuar aqui poderá distorcer a imagem... Deseja saber se um pixel está seleccionado? Isso é fácil — use o método isSelected. Mas o estado de seleccionado não é uma propriedade binária de um pixel; um pixel poderá estar meio-seleccionado, pouco seleccionado ou praticamente seleccionado. Esse valor também poderá ser obtido do iterador. As selecções são, de facto, um dispositivo de pintura de máscara, com um intervalo entre 0 e 255, onde o 0 é a ausência de selecção e o 255 é a selecção completa. O iterador tem dois métodos: isSelected() e selectedNess(). O primeiro devolve 'true' (verdadeiro), se um pixel estiver seleccionado de qualquer forma (i.e., o valor da máscara é maior que 1), enquanto o outro devolve o valor da máscara. Como se aponta acima, este memcpy é um grande erro, de facto... o rawData() devolve o vector de 'bytes' que é o estado actual; o oldRawData() devolve o vector de 'bytes', tal como estava antes de ter sido criado o iterador. Contudo, poder-se-á estar a copiar o pixel errado aqui. Na prática, isto não irá acontecer com muita frequência, a menos que o dest já exista e não esteja alinhado com o orig. Mas isto é correcto: 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 actuais. Os espaços de cores têm bastantes operações com pixels que poderão ser usadas. Isto não tudo que existe para criar um filtro. Os filtros têm outras duas componentes importantes: um objecto de configuração e um elemento gráfico de configuração. Os dois interagem intimamente. O elemento gráfico de configuração cria um objecto de configuração, mas também pode ser preenchido a partir de um objecto de configuração previamente existente. Os objectos de configuração poder-se-ão representar a eles próprios como XML e poderão ser criados a partir de XML. Isto é o que torna as camadas de ajuste possíveis. Existem três tipos de iteradores: Linhas horizontais Linhas verticais Iteradores rectangulares Os iteradores de linhas horizontais e verticais têm um método para mover o iterador para a próxima linha ou coluna: nextRow() e nextCol(). Se os usar, é mais rápido que criar um iterador novo para cada linha ou coluna. Os iteradores são seguros em ambiente multitarefa no &krita;; por isso, é possível dividir o trabalho por várias tarefas. Contudo, as versões futuras do &krita; irão usar o método supportsThreading() 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. O KisFilterConfiguration é 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 KisFilterConfigaration, para ser possível programar os filtros. Os filtros poderão oferecer um elemento gráfico personalizado, que o &krita; irá mostrar na galeria de filtros, na janela de antevisão do filtro ou na página de opções da ferramenta de pintura-com-filtros. Um exemplo, retirado do filtro de pintura a óleo: class KisOilPaintFilterConfiguration : public KisFilterConfiguration { public: KisOilPaintFilterConfiguration(Q_UINT32 brushSize, Q_UINT32 smooth) : KisFilterConfiguration( "oilpaint", 1 ) { setProperty("brushSize", brushSize); setProperty("smooth", smooth); }; public: inline Q_UINT32 brushSize() { return getInt("brushSize"); }; inline Q_UINT32 smooth() {return getInt("smooth"); }; }; A maioria dos filtros poderá ser afinado pelo utilizador. Poderá criar um elemento gráfico de configuração que o Krita irá usar, sempre que o filtro for usado. Um exemplo: A janela de Pintura a Óleo A janela de Pintura a Óleo A janela de Pintura a Óleo Repare que só a parte esquerda desta janela é da sua responsabilidade: o &krita; toma conta do resto. Existem três abordagens para criar um elemento gráfico de opção: Use o &Qt; Designer para criar um base para o elemento gráfico e crie uma sub-classe para o seu filtro 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 vírgula flutuante ou booleanos. Este são úteis se, como acontece na imagem acima, o seu filtro puder ser configurado com um conjunto de inteiros, números de vírgula flutuante ou booleanos. Veja a documentação da API do KisMultiIntegerFilterWidget, KisMultiDoubleFilterWidget e KisMultiBoolFilterWidget. Crie um elemento gráfico à mão. Esta forma não é a recomendada e, se o fizer e quiser que o seu filtro se torne parte da versão oficial do &krita;, então recomenda-se que substitua o seu elemento gráfico codificado à mão por uma versão com o &Qt; Designer. O filtro de pintura a óleo usa o elemento multi-inteiros: KisFilterConfigWidget * KisOilPaintFilter::createConfigurationWidget(QWidget* parent, KisPaintDeviceSP /*dev*/) { vKisIntegerWidgetParam param; param.push_back( KisIntegerWidgetParam( 1, 5, 1, i18n("Brush size"), "brushSize" ) ); param.push_back( KisIntegerWidgetParam( 10, 255, 30, i18n("Smooth"), "smooth" ) ); return new KisMultiIntegerFilterWidget(parent, id().id().ascii(), id().id().ascii(), param ); } KisFilterConfiguration* KisOilPaintFilter::configuration(QWidget* nwidget) { KisMultiIntegerFilterWidget* widget = (KisMultiIntegerFilterWidget*) nwidget; if( widget == 0 ) { return new KisOilPaintFilterConfiguration( 1, 30); } else { return new KisOilPaintFilterConfiguration( widget->valueAt( 0 ), widget->valueAt( 1 ) ); } } std::list<KisFilterConfiguration*> KisOilPaintFilter::listOfExamplesConfiguration(KisPaintDeviceSP ) { std::list<KisFilterConfiguration*> list; list.insert(list.begin(), new KisOilPaintFilterConfiguration( 1, 30)); return list; } Pode ver como ele funciona: este preenche um vector com os seus parâmetros inteiros e cria o elemento gráfico. O método configuration() inspecciona o elemento e cria o objecto de configuração do filtro correcto, nesse caso, o KisOilPaintFilterConfiguration. O método listOfExamplesConfiguration (que deverá mudar de nome para um Inglês correcto...) devolve uma lista com objectos de configuração de exemplo, para a janela da galeria de filtros. 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, deverá ser capaz de ter uma boa introdução. Não hesite em contactar a equipa de desenvolvimento do &krita; no IRC ou na lista de correio. As ferramentas aparecem na área de ferramentas do &krita;. 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 rato/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. Tenha cuidado com os dados estáticos na sua ferramenta: é criada uma instância nova da sua ferramenta com cada dispositivo de entrada: o rato, caneta, borracha, spray — o que for. As ferramentas estão divididas em grupos lógicos: ferramentas de desenho de formas (círculo, rectângulo) ferramentas de desenho livre (pincel) ferramentas de transformação que mexem na geometria de uma camada ferramentas de preenchimento (como o balde ou o gradiente) ferramentas de visualização (que não mudam os pixels, mas sim a forma como vê a tela, como a ampliação) ferramentas de selecção (que mudam a máscara de selecção) A interface da ferramenta está descrita na documentação da API da classe KisTool. Existem três sub-classes: KisToolPaint, KisToolNonPaint e KisToolShape (que é, de facto, uma sub-classe de KisToolPaint), a qual especializa a KisTool para as ferramentas de pintura (i.e., mudando os pixels) , as tarefas sem ser de pintura e as tarefas de pintura de formas. Uma ferramenta tem um elemento gráfico de opções, como os filtros. De momento, os elementos gráficos aparecem numa página de uma janela acoplável. Poder-se-á mudar esta para uma barra fina, sob o menu principal (que por sua vez substitui a barra de ferramentas) no &krita; 2.0 mas, por agora, 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. Um bom exemplo de uma ferramenta é a estrela: kis_ferramenta_estrela.cc Makefile.am ferramenta_estrela_cursor.png wdg_ferramenta_estrela.ui kis_ferramenta_estrela.h Makefile.in ferramenta_estrela.h kritaferramentaestrela.desktop ferramenta_estrela.cc ferramenta_estrela.png Como poderá ver, são necessárias duas imagens: uma para o cursor e outra para a caixa de ferramentas. O ferramenta_estrela.cc é apenas o carregador do 'plugin', semelhante ao que se viu anteriormente. O recheio real está na implementação: KisFerramentaEstrela::KisFerramentaEstrela() : KisToolShape(i18n("Star")), m_dragging (false), m_currentImage (0) { setName("tool_star"); setCursor(KisCursor::load("ferramenta_estrela_cursor.png", 6, 6)); m_innerOuterRatio=40; m_vertices=5; } O construtor define o nome interno — que não é traduzido — e a chamada à super-classe define o nome visível. Também se poderá carregar a imagem do cursor e definir um conjunto de variáveis. void KisToolStar::update (KisCanvasSubject *assunto) { KisToolShape::update (assunto); if (m_subject) m_currentImage = m_subject->currentImg(); } O método update() é chamado quando a ferramenta é seleccionada. Este não é um método da KisTool, mas sim um método da classe KisCanvasObserver. Os observadores da área de trabalho são notificados sempre que ocorrerem alterações na tela, o que poderá ser útil para as ferramentas. Os seguintes métodos (buttonPress, move e buttonRelease) são invocados pelo &krita; quando o dispositivo de entrada (rato, caneta, borracha, etc.) for pressionado, mudado de posição ou largado. Lembre-se que também obtém mais eventos se o botão do rato não for pressionado. Os eventos não são os normais, mas sim eventos sintéticos do &krita;, dado que se tira partido de alguns truques de baixo nível para obter eventos suficientes para desenhar uma linha suave. Por omissão, as bibliotecas, como o &Qt; (e o GTK), perdem eventos se estiverem demasiado ocupados para tratar deles, e aqui pretende-se ter todos. void KisFerramentaEstrela::buttonPress(KisButtonPressEvent *evento) { if (m_currentImage && evento->button() == LeftButton) { m_dragging = true; m_dragStart = evento->pos(); m_dragEnd = evento->pos(); m_vertices = m_optWidget->verticesSpinBox->value(); m_innerOuterRatio = m_optWidget->ratioSpinBox->value(); } } void KisFerramentaEstrela::move(KisMoveEvent *evento) { if (m_dragging) { // apagar as linhas antigas da área de desenho draw(m_dragStart, m_dragEnd); // mover (alt) ou dimensionar a estrela if (evento->state() & Qt::AltButton) { KisPoint trans = evento->pos() - m_dragEnd; m_dragStart += trans; m_dragEnd += trans; } else { m_dragEnd = evento->pos(); } // desenhar as linhas novas na área de desenho draw(m_dragStart, m_dragEnd); } } void KisFerramentaEstrela::buttonRelease(KisButtonReleaseEvent *evento) { if (!m_subject || !m_currentImage) return; if (m_dragging && evento->button() == LeftButton) { // apagar as linhas antigas da área de desenho draw(m_dragStart, m_dragEnd); m_dragging = false; if (m_dragStart == m_dragEnd) return; if (!m_currentImage) return; if (!m_currentImage->activeDevice()) return; KisPaintDeviceSP dispositivo = m_currentImage->activeDevice ();; KisPainter pintor (dispositivo); if (m_currentImage->undo()) pintor.beginTransaction (i18n("Star")); pintor.setPaintColor(m_subject->fgColor()); pintor.setBackgroundColor(m_subject->bgColor()); pintor.setFillStyle(fillStyle()); pintor.setBrush(m_subject->currentBrush()); pintor.setPattern(m_subject->currentPattern()); pintor.setOpacity(m_opacity); pintor.setCompositeOp(m_compositeOp); KisPaintOp * op = KisPaintOpRegistry::instance()->paintOp(m_subject->currentPaintop(), m_subject->currentPaintopSettings(), &pintor.; pintor.setPaintOp(op); // O Pintor fica como dono vKisPoint coord = starCoordinates(m_vertices, m_dragStart.x(), m_dragStart.y(), m_dragEnd.x(), m_dragEnd.y()); pintor.paintPolygon(coord); device->setDirty( pintor.dirtyRect() ); notifyModified(); if (m_currentImage->undo()) { m_currentImage->undoAdapter()->addCommand(pintor.endTransaction()); } } } O método draw() é um método interno da classe KisToolStar e desenha o contorno da estrela. Este é chamado a partir do método move(), para dar alguma reacção ao utilizador sobre o tamanho e a forma da sua estrela. Repare que se usa a operação de desenho Qt::NotROP, o que significa que, ao invocar o draw() uma segunda vez com o mesmo início e fim, a estrela anteriormente desenhada será removida. void KisToolStar::draw(const KisPoint& inicio, const KisPoint& fim ) { if (!m_subject || !m_currentImage) return; KisCanvasController *controller = m_subject->canvasController(); KisCanvas *canvas = controller->kiscanvas(); KisCanvasPainter p (canvas); QPen pen(Qt::SolidLine); KisPoint posInicio; KisPoint posFim; posInicio = controller->windowToView(inicio); posFim = controller->windowToView(fim); p.setRasterOp(Qt::NotROP); vKisPoint pontos = starCoordinates(m_vertices, posInicio.x(), posInicio.y(), posFim.x(), posFim.y()); for (uint i = 0; i < pontos.count() - 1; i++) { p.drawLine(pontos[i].floorQPoint(), pontos[i + 1].floorQPoint()); } p.drawLine(pontos[pontos.count() - 1].floorQPoint(), pontos[0].floorQPoint()); p.end (); } O método setup() é essencialmente: aqui é criada a acção que será ligada à área de ferramentas, para que os utilizadores possam de facto seleccionar 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 por cada dispositivo de entrada. Isto também significa que é chamado o método setup() por cada dispositivo de entrada, e isso significa que é adicionada uma acção com o mesmo nome, várias vezes, à colecção de acções. Contudo, tudo parece funcionar, daí porquê as preocupações? void KisToolStar::setup(KActionCollection *colleccao) { m_action = static_cast<KRadioAction *>(colleccao->action(name())); if (m_action == 0) { KShortcut atalho(Qt::Key_Plus); atalho.append(KShortcut(Qt::Key_F9)); m_action = new KRadioAction(i18n("&Star"), "ferramenta_estrela", atalho, this, SLOT(activate()), colleccao, name()); Q_CHECK_PTR(m_action); m_action->setToolTip(i18n("Draw a star")); m_action->setExclusiveGroup("tools"); m_ownAction = true; } } O método starCoordinates() contém alguma matemática engraçada — mas não é muito interessante para a discussão sobre a criação dos 'plugins' de ferramentas. KisPoint KisToolStar::starCoordinates(int N, double mx, double my, double x, double y) { double R=0, r=0; Q_INT32 n=0; double angulo; vKisPoint listaCoordenadasEstrela(2*N); // o raio dos lados exteriores R=sqrt((x-mx)*(x-mx)+(y-my)*(y-my)); // o raio dos lados interiores r=R*m_innerOuterRatio/100.0; // o ângulo angulo=-atan2((x-mx),(y-my)); //definir os lados exteriores for(n=0;n<N;n++){ listaCoordenadasEstrela[2*n] = KisPoint(mx+R*cos(n * 2.0 * M_PI / N + angulo),my+R*sin(n *2.0 * M_PI / N+angulo)); } //definir os lados interiores for(n=0;n<N;n++){ listaCoordenadasEstrela[2*n+1] = KisPoint(mx+r*cos((n + 0.5) * 2.0 * M_PI / N + angulo),my+r*sin((n +0.5) * 2.0 * M_PI / N + angulo)); } return listaCoordenadasEstrela; } O método createOptionWidget() é chamado para criar o elemento gráfico das opções que o &krita; irá mostrar na página. Dado que existe uma ferramenta por cada dispositivo de entrada, por 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 activada. QWidget* KisFerramentaEstrela::createOptionWidget(QWidget* mae) { QWidget *elemento = KisToolShape::createOptionWidget(mae); m_optWidget = new WdgFerramentaEstrela(elemento); Q_CHECK_PTR(m_optWidget); m_optWidget->ratioSpinBox->setValue(m_innerOuterRatio); QGridLayout *disposicaoOpcoes = new QGridLayout(elemento, 1, 1); super::addOptionWidgetLayout(disposicaoOpcoes); disposicaoOpcoes->addWidget(m_optWidget, 0, 0); return elemento; } As ferramentas são 'plugins' relativamente simples de criar. Terá de combinar as interfaces KisTool e KisCanvasObserver para criar de facto uma ferramenta. As operações de pintura são um dos tipos de 'plugins' mais inovadores no Krita (em conjunto com os espaços de cores acopláveis). Uma operação de pintura define a forma como as ferramentas mudam os pixels com que mexem. O 'spray', o lápis ou o pincel suave: todos estes são operações de pintura. Mas você pode — com bastante 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. As operações de pintura são instanciadas sempre que uma ferramenta de pintura receber um evento mouseDown e são removidas quando o evento 'mouseUp' for recebido por uma ferramenta de pintura. Entretanto, a operação poderá manter um registo das posições anteriores e os outros dados, como os níveis de pressão, se o utilizador usar uma tablete. A operação básica de uma operação de pintura é mudar os pixels na posição actual do cursor de uma ferramenta. Isto só poderá ser feito uma vez, caso contrário 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'. As operações de pintura poderão ter um pequeno elemento gráfico, o qual é colocado numa barra de ferramentas. Deste modo, os elementos de configuração das operações de pintura precisam de ter uma disposição horizontal dos elementos gráficos, não superiores a um botão da barra de ferramentas. Caso contrário, o &krita; ficará bastante engraçado. Vejamos um simples 'plugin' de pintura, um que mostra alguma inteligência de programação. Primeiro, no ficheiro de inclusão, está definida uma 'factory' (fábrica de instâncias). Este objecto cria uma operação de pintura, sempre que a ferramenta activa precisar de uma: public: KisSmearyOpFactory() {} virtual ~KisSmearyOpFactory() {} virtual KisPaintOp * createOp(const KisPaintOpSettings *configuracao, KisPainter * pintor); virtual KisID id() { return KisID("paintSmeary", i18n("Smeary Brush")); } virtual bool userVisible(KisColorSpace * ) { return false; } virtual QString pixmap() { return ""; } }; A 'factory' também contém o KisID com o nome público e o privado da operação de pintura — garanta que o nome privado da sua operação de pintura não entra em conflito com outra operação! — e poderá devolver, a título opcional, uma imagem. O &krita; 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. A implementação de uma operação de pintura é bastante intuitiva: KisSmearyOp::KisSmearyOp(KisPainter * pintor) : KisPaintOp(pintor) { } KisSmearyOp::~KisSmearyOp() { } void KisSmearyOp::paintAt(const KisPoint &pos, const KisPaintInformation& info) { O método paintAt() está realmente onde deverá ficar, com as operações de pintura. Este método recebe dois parâmetros: a posição actual (que está com números de vírgula flutuante, não em pixels) e um objecto KisPaintInformation, que contém a pressão, o toque em 'x' e 'y' e o vector de movimento, podendo ser extendida no futuro com outras informações. if (!m_painter->device()) return; KisBrush *pincel = m_painter->brush(); Um KisBrush é a representação de um ficheiro de pincel do Gimp: este é uma máscara, seja esta simples ou uma série de máscaras. De facto, não é usado aqui o pincel, excepto para determinar o ponto fulcral sob o cursor. Q_ASSERT(pincel); if (!pincel) return; if (! pincel->canPaintFor(info) ) return; KisPaintDeviceSP dispositivo = m_painter->device(); KisColorSpace * espacoCores = dispositivo->colorSpace(); KisColor kc = m_painter->paintColor(); kc.convertTo(colorSpace); KisPoint ponto = pincel->hotSpot(info); KisPoint pt = pos - ponto; // Dividir as coordenadas em partes inteira e fraccionária. A parte inteira // é onde ficará o 'dab' e a parte fraccionária determina a posição nos // sub-pixels Q_INT32 x, y; double fraccaoX, fraccaoY; splitCoordinate(pt.x(), &x, &fraccaoX); splitCoordinate(pt.y(), &y, &fraccaoY); KisPaintDeviceSP dab = new KisPaintDevice(espacoCores, "smeary dab"); Q_CHECK_PTR(dab); Não são alterados directamente os pixels de um dispositivo de pintura: em vez disso, é criado um pequeno dispositivo de pintura, um 'dab', sendo este composto no dispositivo de pintura actual. m_painter->setPressure(info.pressure); Como dizem os comentários, o próximo bloco de código efectua algum trabalho de programação para criar o 'dab' actual. 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, tendo assim sido criado um pincel forte e húmido. Mas ainda não chegou a altura de terminar. // 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 // a posição actual e a posição anterior. // Os tufos estão espalhados ao longo da pressão KisPoint pontoAnterior = info.movement.toKisPoint(); KisVector2D vectorPincel(-pontoAnterior.y(), pontoAnterior.x()); KisVector2D listaPontoActual = KisVector2D(pos); vectorPincel.normalize(); KisVector2D vl, vr; for (int i = 0; i < (NUMBER_OF_TUFTS / 2); ++i) { // Calcular as posições do vector novo. vl = listaPontoActual + i * vectorPincel; KisPoint pl = vl.toKisPoint(); dab->setPixel(pl.roundX(), pl.roundY(), kc); vr = listaPontoActual - i * vectorPincel; KisPoint pr = vr.toKisPoint(); dab->setPixel(pr.roundX(), pr.roundY(), kc); } vr = vr - vl; vr.normalize(); Finalmente, é desenhado o 'dab' no dispositivo de pintura original e é dito ao pintor que se actualizou um pequeno rectângulo do dispositivo de pintura. 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)); } KisPaintOp * KisSmearyOpFactory::createOp(const KisPaintOpSettings */*configuracao*/, KisPainter * pintor) { KisPaintOp * op = new KisSmearyOp(pintor); Q_CHECK_PTR(op); return op; } É tudo: as operações de pintura são simples e divertidas! 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 utilizador e alguma funcionalidade. Por exemplo, a página do histograma é um 'plugin' de visualização, assim como a janela de rotação. O &krita; funciona com a arquitectura de filtros de ficheiros do &koffice;. Existe um tutorial, um pouco antigo mas ainda útil, em: . É provavelmente melhor cooperar com a equipa do &krita; ao desenvolver filtros de ficheiros e fazer o desenvolvimento na árvore de filtros do &koffice;. Lembre-se que poderá testar os seus filtros, sem executar o &krita;, usando o utilitário koconverter. Os filtros têm duas faces: importação e exportação. Estes são, normalmente, dois 'plugins' diferentes que poderão partilhar algum código. Os itens importantes do Makefile.am são: service_DATA = krita_XXX_import.desktop krita_XXX_export.desktop servicedir = $(kde_servicesdir) kdelnk_DATA = krita_XXX.desktop kdelnkdir = $(kde_appsdir)/Office libkritaXXXimport_la_SOURCES = XXXimport.cpp libkritaXXXexport_la_SOURCES = XXXexport.cpp METASOURCES = AUTO Quer esteja a criar um filtro de importação ou de exportação, o seu trabalho sempre passa por implementar a função que se segue: virtual KoFilter::ConversionStatus convert(const QCString& de, const QCString& para); É a configuração dos ficheiros .desktop que determina a forma como um filtro converte: Importar: X-KDE-Export=application/x-krita X-KDE-Import=image/x-xcf-gimp X-KDE-Weight=1 X-KDE-Library=libkritaXXXimport ServiceTypes=KOfficeFilter Exportar: X-KDE-Export=image/x-xcf-gimp X-KDE-Import=application/x-krita ServiceTypes=KOfficeFilter Type=Service X-KDE-Weight=1 X-KDE-Library=libkritaXXXexport E sim, o tipo MIME escolhido para o exemplo é uma sugestão. Por favor, pode implementar um filtro de XCF? 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: Nota: é mesmo realmente necessária uma forma de permitir ao &krita; manter um ficheiro 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 que as infra-estruturas de gestão de dados que percebam os ficheiros TIFF, entre outros, e isso ainda não está implementado de momento. Seria o ideal se alguns filtros de ficheiros pudessem implementar uma classe temporária chamada KisFileDataManager, criassem um objecto dessa instância com o ficheiro actual e o passassem ao KisDoc. Mas o &krita; lida com o armazenamento por camadas, não por documentos, por isso seria uma factorização difícil de fazer. KoFilter::ConversionStatus XXXImport::convert(const QCString&, const QCString& para) { if (para != "application/x-krita") return KoFilter::BadMimeType; KisDoc * doc = dynamic_cast<KisDoc*>(m_chain -> outputDocument()); KisView * vista = static_cast<KisView*>(doc -> views().getFirst()); QString ficheiro = m_chain -> inputFile(); if (!doc) return KoFilter::CreationError; doc -> prepareForImport(); if (!ficheiro.isEmpty()) { KURL url(ficheiro); if (url.isEmpty()) return KoFilter::FileNotFound; KisImageXXXConverter ib(doc, doc -> undoAdapter()); if (vista != 0) vista -> canvasSubject() -> progressDisplay() -> setSubject(&ib, false, true); switch (ib.buildImage(url)) { case KisImageBuilder_RESULT_UNSUPPORTED: return KoFilter::NotImplemented; break; case KisImageBuilder_RESULT_INVALID_ARG: return KoFilter::BadMimeType; break; case KisImageBuilder_RESULT_NO_URI: case KisImageBuilder_RESULT_NOT_LOCAL: return KoFilter::FileNotFound; break; case KisImageBuilder_RESULT_BAD_FETCH: case KisImageBuilder_RESULT_EMPTY: return KoFilter::ParsingError; break; case KisImageBuilder_RESULT_FAILURE: return KoFilter::InternalError; break; case KisImageBuilder_RESULT_OK: doc -> setCurrentImage( ib.image()); return KoFilter::OK; default: break; } } return KoFilter::StorageCreationError; } Isto é suposto ser um filtro de importação; por isso, se não for invocado para converter para uma imagem do &krita;, algo se passa de errado. A cadeia de filtros já criou um documento de saída para nós. É preciso convertê-lo para um KisDocM, dado que os documentos do &krita; 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. Se invocar este filtro a partir da GUI, terá de se obter uma vista. Se existir, o código de conversão poderá tentar actualizar a barra de progresso. O filtro tem o nome do ficheiro de entrada. O KisDoc precisa de se preparar para a importação. Algumas configurações são inicializadas e a opção para desfazer é desactivada. Caso contrário, poderia anular a adição de camadas efectuadas pelo filtro de importação, e isso seria um comportamento estranho. Optou-se por implementar o código de importação actual numa classe separada que é aqui instanciada. Poderá também colocar todo o seu código neste método, mas isso ficaria um pouco confuso. 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. Se a criação do KisImage foi bem sucedida, será configurada a imagem actual do documento com a imagem acabada de criar. Aí, é tudo: return KoFilter::OK;.