O &krita; é 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 &krita; reconhece estes seis tipos de plugins: espaços de cores — eles definem os canais que constituem um único pixel ferramentas — tudo o que é feito com um mouse 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 selecionados de uma camada plugins de visualização — estende a interface de usuário 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 de três bibliotecas em camadas e de uma pasta com algumas classes comuns de suporte: kritacolor, kritaimage e kritaui. Dentro do &krita;, os objetos podem ser identificados por um KisID, que é a combinação de um texto não-traduzido único (usado ao salvar, por exemplo) e um texto traduzido, para fins de interface. Uma palavra sobre a compatibilidade: o &krita; está ainda em desenvolvimento. Do &krita; 1.5 até o 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;, 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. 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 abstrata KisColorSpace ou, se as capacidades básicas do novo espaço de cores forem implementadas pelo lcms (), estender o KisAbstractColorSpace. A biblioteca 'kritacolor' poderá ser usada em outras 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 objetivo é tornar a 'libkritaimage' independente do &koffice;, mas atualmente nós compartilhamos o código de carregamento dos gradientes com o &koffice;. Não é possível, por enquanto, 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 projeto Create () para isso. A adição do suporte para o formato de pincéis do Photoshop precisa de algumas alterações na 'libkritaimage'; por outro lado, a adição de mais arquivos de dados de pincéis do 'gimp' não precisa. O KritaImage carrega os seguintes tipos de plugins: Os filtros do &krita; deverão estender e implementar a classe abstrata KisFilter, KisFilterConfiguration e, possivelmente, a KisFilterConfigurationWidget. Um exemplo destes filtros é a Máscara Não-Nítida. 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 KisPaintop. Os exemplos de novas operações de pintura seriam o pincel de giz, um pincel a óleo ou um pincel programável complexo. 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 nós tenhamos que dividir esta biblioteca em 'kritapart' e 'kritaui' 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 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 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. Os plugins de visualização são KParts normais que usam o kxmlgui para se publicarem eles mesmos na interface de usuário 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 fato, 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 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 &krita; será um filtro de PDF. Os filtros são carregados pelas bibliotecas do &koffice;. Os plugins são escritos em C++ e poderão usar toda a API de programação do &kde;, do &Qt; e do &krita;. Somente os plugins de visualização deverão usar a API do &koffice;. Não se preocupe: as APIs do &krita; 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. 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. 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 arquivos de inclusão relevantes para o &krita;, ou poderá ter dividido os arquivos em pacotes de desenvolvimento do &koffice; ou do &krita;. Você 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 descreve 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 arquivos .desktop; os plugins de visualização necessitam de um arquivo do KXMLGui nomeplugin.rc adicionalmente. A forma mais simples de começar é extrair o projeto 'krita-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 &krita; para o KDevelop, mas isso 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 = arquivo1.cc arquivo2.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 Este é o 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 você também instalou um arquivo .rc 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 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 arquivo .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 arquivos usam a plataforma de filtros genérica do &koffice; e precisam ser discutidos separadamente. 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. Um arquivo 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 arquivo de implementação: #include <kinstance.h> #include <kgenericfatory.h> #include <kis_tool_registry.h> #include "ferramenta_estrela.h" #include "kis_ferramenta_estrela.h" typedef KGenericfatory<FerramentaEstrela> FerramentaEstrelafatory; K_EXPORT_COMPONENT_fatoRY( kritatoolstar, FerramentaEstrelafatory( "krita" ) ) FerramentaEstrela::FerramentaEstrela(QObject *mae, const char *nome, const QStringList &) : KParts::Plugin(mae, nome) { setInstance(FerramentaEstrelafatory::instance()); if ( mae->inherits("KisToolRegistry") ) { KisToolRegistry * r = dynamic_cast<KisToolRegistry*>( mae ); r -> add(new KisFerramentaEstrelafatory()); } } FerramentaEstrela::~FerramentaEstrela() { } #include "ferramenta_estrela.moc" 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. Os filtros invocam o registro de filtros: if (mae->inherits("KisFilterRegistry")) { KisFilterRegistry * gestor = dynamic_cast<KisFilterRegistry *>(mae); gestor->add(new KisFilterInvert()); } As operações de pintura invocam o seu próprio registro: if ( mae->inherits("KisPaintOpRegistry") ) { KisPaintOpRegistry * r = dynamic_cast<KisPaintOpRegistry*>(mae); r -> add ( new KisSmearyOpfatory ); } Os espaços de cores procuram no registro de espaços de cores (com mais algumas complicações): if ( mae->inherits("KisColorSpacefatoryRegistry") ) { KisColorSpacefatoryRegistry * f = dynamic_cast<isColorSpacefatoryRegistry*>(mae); KisProfile *perfilOmissao = new KisProfile(cmsCreate_sRGBProfile()); f->addProfile(perfilOmissao); KisColorSpacefatory * fabrica = new KisRgbColorSpacefatory(); f->add(fabrica); KisColorSpace * espacoCoresRGBA = new KisRgbColorSpace(f, 0); KisHistogramProducerfatoryRegistry::instance() -> add( new KisBasicHistogramProducerfatory<KisBasicU8HistogramProducer> (KisID("RGB8HISTO", i18n("RGB8 Histogram")), espacoCoresRGBA) ); } Os plugins de visualização não têm que se registrar eles mesmos, obtendo o acesso a um objeto KisView: if ( mae->inherits("KisView") ) { setInstance(ShearImagefatory::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 para cada visualização que o usuário cria: a divisão de uma janela significa carregar todos os plugins de visualização novamente. O &krita; 1.5 carrega os plugins com o X-KDE-Version=2 definido no arquivo .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 totalmente 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 muito 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 determinado 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 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 &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 rico conjunto de métodos oferecidos pelo KisColorSpace, para fazer o seu trabalho. Em muitos dos casos, a implementação padrão no KisAbstractColorSpace irá funcionar, mas de forma mais lenta que uma implementação personalizada no seu espaço de cores, uma vez 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 usuário 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 mudado 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 usuário 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, exceto modificando 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, obviamente. 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. Além disso, existe um método para converter para qualquer espaço de cores a partir do atual. Os espaços de cores são descritos pelo vetor 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 precisa 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 ponto flutuante de 16 e 32 bits, definindo as operações comuns para mudar a profundidade de cor. Os filtros são plugins que examinam os pixels de uma camada e fazem alterações sobre eles. Apesar do &krita; 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 colar os blocos em conjunto: o &krita; oculta esse detalhe de implementação. 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. O &krita; 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. As imagens do &krita; 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 KisPaintDevice. Um dispositivo de pintura, por sua vez, dá acesso aos pixels em si. Os PaintDevices 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 SP. Basta lembrar-se que nunca terá que 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 objeto 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á atuar. 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 atual 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 fato a progressão } Isto cria um iterador para ler os pixels existentes. O Krita 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. (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 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 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 — assim, a cópia que efetuar aqui poderá distorcer a imagem... Você deseja saber se um pixel está selecionado? Isso é fácil — use o método isSelected. 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: isSelected() e selectedNess(). 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. Como observado acima, este memcpy é um grande erro, de fato... o rawData() devolve o vetor de 'bytes' que é o estado atual; o oldRawData() 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 dest já exista e não esteja alinhado com o orig. 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. 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. Existem três tipos de iteradores: Linhas horizontais Linhas verticais Iteradores retangulares Os iteradores de linhas horizontais e verticais possuem um método para mover o iterador para a próxima linha ou coluna: nextRow() e nextCol(). Usá-los é 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 previsão do filtro ou na página de opções da ferramenta de pintura-com-filtros. Um exemplo, retirado do filtro de pintura à ó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 ajustada pelo usuário. Você 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 à Óleo A janela de Pintura à Óleo A janela de Pintura à Ó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 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 KisMultiIntegerFilterWidget, KisMultiDoubleFilterWidget e KisMultiBoolFilterWidget. 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 &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 à ó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; } 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 configuration() inspeciona o elemento e cria o objeto de configuração do filtro correto, nesse caso, o KisOilPaintFilterConfiguration. O método listOfExamplesConfiguration (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. 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 &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 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. 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: ferramentas de desenho de formas (círculo, retâ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 você vê a tela, como a ampliação) ferramentas de seleção (que mudam a máscara de seleçã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 fato, uma sub-classe de KisToolPaint), que 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 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 &krita; 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. 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 pode 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 foi visto 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. Nós também poderemos 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 é selecionada. 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 (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 &krita;, 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. 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. Ele é chamado a partir do método move(), para dar alguma reação ao usuário sobre o tamanho e a forma da sua estrela. Note 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() é 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 setup() 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? 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. 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. 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. Você terá que combinar as interfaces KisTool e KisCanvasObserver para criar de fato 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 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. 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 registro das posições anteriores e os outros dados, como os níveis de pressão, se o usuário usar uma tablete. 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'. 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 &krita; ficará bastante engraçado. 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: public: KisSmearyOpfatory() {} virtual ~KisSmearyOpfatory() {} 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 — 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 &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 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 KisPaintInformation, 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. if (!m_painter->device()) return; KisBrush *pincel = m_painter->brush(); Um KisBrush é 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 ponto focal 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 fracionária. A parte inteira // é onde ficará o 'dab' e a parte fracionária determina a posição nos // sub-pixels Q_INT32 x, y; double fraccaoX, fraccaoY; splitCoordinate(pt.x(), &x, &fracaoX); splitCoordinate(pt.y(), &y, &fracaoY); KisPaintDeviceSP dab = new KisPaintDevice(espacoCores, "smeary dab"); Q_CHECK_PTR(dab); 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. m_painter->setPressure(info.pressure); 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. // 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 atual 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 listaPontoatual = KisVector2D(pos); vectorPincel.normalize(); KisVector2D vl, vr; 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(); Finalmente, é desenhado o 'dab' no dispositivo de pintura original e é dito ao pintor que se atualizou um pequeno retâ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 * KisSmearyOpfatory::createOp(const KisPaintOpSettings */*configuracao*/, KisPainter * pintor) { KisPaintOp * op = new KisSmearyOp(pintor); Q_CHECK_PTR(op); return op; } Isto é 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 usuário 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 arquitetura de filtros de arquivos do &koffice;. Existe um tutorial, um pouco antigo mas ainda útil, em: . É provavelmente melhor cooperar com a equipe do &krita; 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 &krita;, usando o utilitário koconverter. Os filtros possuem duas faces: importação e exportação. Eles são, normalmente, dois plugins diferentes que poderão compartilhar algum código. Os ítens 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 Não importa se você está criando um filtro de importação ou de exportação, o seu trabalho sempre passa por implementar a função a seguir: virtual KoFilter::ConversionStatus convert(const QCString& de, const QCString& para); É a configuração dos arquivos .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 para permitir ao &krita; 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 KisFileDataManager, criassem um objeto dessa instância com o arquivo atual e o passassem ao KisDoc. Mas o &krita; lida com o armazenamento por camadas, não por documentos, por isso seria uma fatorizaçã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 arquivo = m_chain -> inputFile(); if (!doc) return KoFilter::CreationError; doc -> prepareForImport(); if (!arquivo.isEmpty()) { KURL url(arquivo); 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 é supostamente um filtro de importação; por isso, se não for invocado para converter para uma imagem do &krita;, algo está errado. A cadeia de filtros já criou um documento de saída para nós. É preciso convertê-lo para um KisDocM, uma vez 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 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. O filtro tem o nome do arquivo de entrada. O KisDoc 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. 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. 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, nós configuraremos a imagem atual do documento com a imagem recém criada. Então, isto é tudo: return KoFilter::OK;.