WOL
Home Download Documentação A Fazer... Links Pascal Começar

WOLGUI - A Fazer...

Devido ao fato de estarmos sós no projeto, não temos como melhorar o código como desejamos. Assim, vamos construindo o código em ritmo muito lento, principalmente porque temos de corrigir e depurar a fonte criada ou refeita. Entre muitas tarefas a se realizarem para melhoria da biblioteca, listamos as seguintes:

Canvas Memory Criar um canvas destinado à operação offscreen, isto é, em memória do qual o canvas atual possa derivar ou ser derivado. Atualmente, o canvas faz operações em memória, mas não é especializado.
Canvas PostScript Necessidade de criação de um canvas Post Script para utilização principalmente em Linux. Atualmente, o gerador de relatórios permite a criação de rotinas em Post Script, mas sem a utilização de um canvas específico para isso.
Canvas Image Necessidade de criação de canvas voltado somente para imagem. Atualmente, o canvas é derivado para todas as operações (memória, janela, imagem).
ImageList O ImageList atual não está como deveria ser. A classe necessita de melhorias que permitam a que interface não sofra tantas alterações entre Windows e GTK.
TabControl O TabControl necessita de alterações no que concerne ao tempo de desenho. Algumas funções parecem não funcionar com perfeição.
Picture/Image Melhorar os métodos da picture e da image. As classes atuais não são suficientemente claras para que se separe operações em memória (o que depende da criação de um canvas para memória) das operações em canvas. Necessita de melhorias no salvamento e carregamento de imagens. Incluir manipuladores para imagens compactadas como png, jpg, dentre outras. Criação de métodos para escalar a imagem para determinado tamanho (atualmente a GUI que permite isso sem programação é o Windows). Métodos para rotacionar, espelhar, converter cores, etc. são desejados.
Application Criação de um shell verdadeiro para TWOLShellApplication, de forma a ser uma janela oculta a ser destinada ao ícone da barra de tarefas. Melhoria nas rotinas gereciadoras de janelas.
ToolBar Melhoria da interface de entrada de botões com a inclusão de edição de eventos, modificação de ícones. A barra de ferramentas atual pode receber somente ícones padrões.
StatusBar Necessita melhorias na interface de forma a aceitar através de entrada via janela de partes definidas pelo usuário. A barra de status atual aceita partes programadas manualmente pelo usuário com conhecimento da API da GUI em uso.
Animate Necessita de melhorias no tocante ao aprimoramento das rotinas. Ainda não existe na GTK, mas poderá ser criada usando pixbuf, podendo rodar diversos formatos, como GIF.
HotKey Criação de hotkey para GTK e outras GUIs. Atualmente a hotkey só está presente no Windows.
DateTime Criação de uma entrada de data para a GTK e outras GUIs. Atualmente, somente o Windows tem esse tipo de entrada.
Tool Tips Aprimoramento das rotinas de Tool Tips ou Hint. As rotinas ainda não respondem em objetos fora de um formulário.
Banco de Dados Necessita de aprimoramento nas rotinas de acesso a banco de dados. A tabela (dbf) continua sem suporte a arquivos de indices.
Package WOL Melhoria na forma de instalação de objetos são desejáveis. Desejável também é a compatibilidade com componentes escritos no estilo Delphi. Notamos que um dos empecilhos é o fato de que um objeto criado com a engenharia de biblioteca dinâmica (DLL) não é completamente compatível com a interface do WOLDesigner. Os objetos vindos das DLLsão nulos para o kernel do WOL Designer. Em geral, não suporta o método RecreateWnd.
Pascal Parser Otimização do parser de pascal, necessário para ler fontes e traduzi-las para janelas. Ainda existem alguns falhas de leituras.
XML Parser Otimização do parser de XML, que lê formulários WOL escritos nesse formato.
Writer Pascal Melhorias nas rotinas de escrita dos formulários em pascal com a manutenção de códigos inderidos pelo programador. Atualmente, somente os campos declarados dentro do cabeçalho do formulário e o código escrito nos eventos são preservados. O writer reescreve todo o código do formulário a cada vez que é escrito.
Writer XML Melhorias e padronização das rotinas de escrita de código XML que escreve o formulário usando esse formato.
Non Standard Criação de janela que possibilite a criação de métodos e eventos não padrão. Atualmente, o programador tem de abrir o arquivo fonte e digitar seu código. O WOL Designer recupera o código (não perde), mas não possibilita que se escreva um código que não esteja relacionado a um evento. Depois de escrito o evento/método não padrão, é possível editá-lo no designer.
Designer Engine Melhoria na engenharia de desenho (formulário de trabalho) são necessárias tanto na padronização quanto nos encaixes com as possibilidades da GUI em uso.
TWOLCustom... Criação de classes TWOLCustom... com propriedades não publicadas (published). Isso permite uma derivação melhor quando se trata de usá-lo com a interface do WOLDesigner. Na verdade, cada TWOL... seria a derivação do TWOLCustom... com as propriedades publicadas. Para entender o porquê disso, veja o código da unit WOLTESTE.PP. No designer, aparecem todas as propriedades do TWOLEdit, do qual o TWOLSpinButton deriva. Derivando de um TWOLCustomEdit, as propriedades que apareceriam no designer seriam as declaradas como públicadas no objeto TWOLSpinButton.
Inspector Melhorar a interface do inspetor de objetos é uma necessidade. Apesar de estável, robusto e seguro, a interface não é muito interessante visualmente.
SharpContainer Publicar o SharpContainer, um container encaixável em janela, o qual recebe formulários especiais chamados SharpForm. Todos os formulários sharp ficam contidos em um container e são mostrados quando se muda valores de propriedades dos desses. As operações amostragem são iguais ao de um formulário comum (show, showmodal, close, destroy, etc. Esses formulários já estão bastantes maduros quanto à interface e podem ser publicados (documentados). Atualmente, não há inclusão de SharpContainer nem de SharpForm no WOLDesigner, mas esse reconhece as classes. A inclusão é manual, mas versão sharp é feita para que se aproveite todo o código usado nos formulários comuns.
HiliteLabel O TWOLHiliteLabel também ainda não foi documentado e não há inclusão dele no WOLDesigner, embora esse reconheça a classe. A inclusão é manual, bastando alterar a classe de TWOLLabel para TWOLHiliteLabel.
BitButton Publicar documentação do TWOLBitButton, não publicado mas reconhecido pelo WOLDesigner, é outra necessidade. É necessário criar interface de entrada de imagens no WOLDesigner para isso. As aparências em GTK e Windows são diferentes. No Windows, não há como pegar os recursos de ícones da barra de ferramentas que preenchem a propriedade GlyphKind do botão. Além disso não aparece o título do botão enquanto o ícone estiver presente.
Thread Incrementar o código da thread definida no arquivo fonte WOLGUI19.PP. Ainda está em estágio alfa de desenvolvimento. É necessário estudar as threads do Windows, cujo código está "rabiscado" no arquivo e as da GTK.
Cache Refazer o código de cache de banco de dados do arquivo fonte WOLGUI42.PP. Por enquanto, essa classe não está sendo utilizada em nenhum ponto da WOLGUI.
Preview Necessidade de incrementar o código do preview rudimentar que está escrito no arquivo fonte WOLGUI43.PP. Esse preview é muito rudimentar.
Bar Code Necessidade de incrementar o código existente no arquivo fonte WOLGUI44.PP que é relativo a códigos de barras. Atualmente, somente gera imagem do tipo bitmap. É necessário deixar em aberto para gerar qualquer tipo de imagem.
Folder Necessidade de publicar o FolderPath, contido no arquivo fonte WOLGUI45.PP, fazendo melhorias no código e acréscimo de funções.
Debug Incrementar o código existente na unidade WOLDEBUG.PP de forma a melhorar a depuração da própria biblioteca.