Idéias FOX

FOX Toolkit + OpenCV - Vídeo

2010-01-15T15:12:00.007-03:00

Recentemente, uma amiga minha me pediu um exemplo de como exibir um vídeo carregado pelo OpenCV utilizando o FOX.

Então eu rapidamente fiz um programinha para ajudá-la: um micro-player de vídeo. Micro porque não faz nada além de exibir os quadros. Sem som (OpenCV não trabalha com som). Sem controles, nem nada. Abriu o vídeo e pronto.

Obs.: Este tópico, assim como os outros relacionados ao OpenCV, são direcionados àqueles que já tem experiência com o FOX Toolkit, especialmente este aqui por conter itens que ainda não tratei. Tratarei todos esses assuntos em tópicos futuros.

Bom, vamos lá.

FoxVideoPlayerMainWindow.h

Declaração dos objetos

FXImage *image;

Esta é a imagem que será desenhada no canvas (área de desenho), representando cada quadro do vídeo.

FXCanvas *canvas;

Esta é a área de desenho propriamente dita.

CvCapture *capture;

Uma estrutura sinistra que o OpenCV utiliza para guardar as informações do vídeo sendo capturado. Sinistra porque a documentação não revela a estrutura interna. Para conhecê-la, é preciso ir no fonte do OpenCV, coisa que eu ainda não quis fazer.

IplImage *frame;

Cada quadro do vídeo é uma IplImage. Precisa dizer mais?

double freq;

Frequência de atualização. É um vídeo, não é? Não pode ficar no mesmo quadro para sempre.

IplImage *dummy;

Essa é uma pseudo-imagem apenas para converter os quadros para a representação interna do FOX, conforme discutido aqui.

Eventos

Existem apenas três eventos: pintar o canvas, carregar um vídeo e pegar o próximo quadro. Assim:

public:
  enum {
    ID_CANVAS = FXMainWindow::ID_LAST,
   ID_LOAD_VIDEO,

   ID_FRAME,
 };

 /* Pintar o canvas */
 long onPaintCanvas(FXObject*, FXSelector, void*);

 /* Carregar o vídeo */
 long onCmdLoadVideo(FXObject*, FXSelector, void*);

 /* Pegar cada quadro do vídeo */
 long onTimeoutFrame(FXObject*, FXSelector, void*);

E é isso. Agora, vamos implementar essa cambada.

FoxVideoPlayerMainWindow.cpp

Construtor da janela

FoxVideoPlayerMainWindow::FoxVideoPlayerMainWindow(FXApp *a)
  : FXMainWindow(a, "FoxVideoPlayer", 0, 0, DECOR_ALL) {
 FXToolBar *toolBar = new FXToolBar(this, this);
   new FXButton(toolBar, "Abrir vídeo", 0, this, ID_LOAD_VIDEO,
       BUTTON_NORMAL|BUTTON_TOOLBAR);

 canvas = new FXCanvas(this, this, ID_CANVAS,
     LAYOUT_FIX_WIDTH|LAYOUT_FIX_HEIGHT, 0, 0, 0, 0);

 image = 0;

 capture = 0;
 frame = 0;

 dummy = 0;
}

Aqui eu simplesmente crio uma barra de ferramentas com um botão para carregar um vídeo, crio o canvas e inicializo os demais objetos com nulo. Nada de mais.

Pintando o canvas

long FoxVideoPlayerMainWindow::onPaintCanvas(FXObject*, FXSelector, void *ptr) {
  FXEvent *ev = static_cast<FXEvent*>(ptr);
  FXDCWindow dc(canvas, ev);
 if (frame) {
   dc.drawImage(image, 0, 0);
 }

 else {
   dc.setForeground(FXRGB(0, 0, 0));

   dc.fillRectangle(0, 0, canvas->getWidth(), canvas->getHeight());
 }

 return 1;
}

Duas opções: se houver um quadro a desenhar, desenha. Senão, desenha um retângulo preto. Simples.

Carregando o vídeo

Essa função é um pouco grande, então vou quebrá-la em algumas partes.

long FoxVideoPlayerMainWindow::onCmdLoadVideo(FXObject*, FXSelector, void*) {
  FXFileDialog dialog(this, "Abrir vídeo");
    dialog.setDirectory(FXSystem::getHomeDirectory());
 if (!dialog.execute(PLACEMENT_OWNER))
   return 1;

 FXString filename = dialog.getFilename();

Exibe uma caixa de diálogo para selecionar o vídeo.

  capture = cvCaptureFromFile(filename.text());

 if (!capture) {
   FXMessageBox::error(this, MBOX_OK, "Erro", "Erro ao abrir o vídeo");

   return 1;
 }

Abre o vídeo e armazena na estrutura obscura. Um erro e a função cvCaptureFromFile() retorna nulo.

  int width = (int)cvGetCaptureProperty(capture, CV_CAP_PROP_FRAME_WIDTH);
  int height = (int)cvGetCaptureProperty(capture, CV_CAP_PROP_FRAME_HEIGHT);
 freq = cvGetCaptureProperty(capture, CV_CAP_PROP_FPS);
 freq = 1.0 / freq * 1000.0;

Eu preciso saber as dimensões do vídeo e o número de quadros por segundo. A função cvGetCaptureProperty() fornece diversas informações sobre o vídeo. As informações disponíveis são descritas na documentação do OpenCV.

Entretanto, é preciso fazer esse cálculo para saber, digamos assim, o tempo de permanência de cada quadro em milissegundos (o porquê mais para frente).

  canvas->resize(width, height);
  resize(getDefaultWidth(), getDefaultHeight());

Agora que eu sei o tamanho do vídeo, redimensiono o canvas. Depois dele a janela principal.

Explicando rapidamente o que acontece aqui: por padrão, a janela principal é configurada para ficar com o menor tamanho em que caibam todos os filhos. Como eu redimensionei um deles (depois de todos criados), as funções getDefaultWidth() e getDefaultHeight() retornam as dimensões necessárias para caber todo mundo novamente.

  image = new FXImage(getApp(), 0, IMAGE_KEEP|IMAGE_OWNED|IMAGE_SHMP|IMAGE_SHMI,
      width, height);
  image->create();
 dummy = cvCreateImageHeader(cvSize(width, height), IPL_DEPTH_8U, 4);
   cvSetData(dummy, image->getData(), CV_AUTO_STEP);

Criando as imagens. Nada de especial, já falei sobre isso.

  getApp()->addTimeout(this, ID_FRAME, 0);


 return 1;
}

Bom, a última coisa a fazer aqui é disparar um timer para recuperar os quadros do vídeo e desenhá-los. Não queremos esperar, então o tempo é 0.

Quadro-a-quadro

long FoxVideoPlayerMainWindow::onTimeoutFrame(FXObject*, FXSelector, void*) {
  if (!capture)
    return 1;
 frame = cvQueryFrame(capture);

 if (frame) {
   cvCvtColor(frame, dummy, CV_BGR2RGBA);

   image->render();

   canvas->update();

   getApp()->addTimeout(this, ID_FRAME, freq);
 }

 else
   canvas->update();

 return 1;
}

Toda vez que essa função é chamada, o próximo quadro do vídeo é recuperado com cvQueryFrame(). Se não for nulo (ou seja, o vídeo ainda não acabou), os espaços de cor são convertidos com cvCvtColor(). Como dummy utiliza os pixels de image, é como se eu estivesse pintando duas imagens de uma vez só (mas, na verdade, é uma imagem só com duas representações).

Em seguida, vem uma operação importante. É algo que eu demorei muito para entender. Uma imagem (pelo menos no FOX Toolkit, não sei quando a outras bibliotecas de interface gráfica) tem duas representações, uma no lado do cliente outra do servidor. O lado do cliente é esse vetor de pixels que pode ser acessado por meio de image->getData(). O lado do servidor é o servidor gráfico (no meu caso, o X; não sei qual seria no caso do Uíndous ou do Macos). Quando o lado do cliente é alterado, é necessário transferir os pixels para o servidor com render(). Sem isso, seria exibida sempre a mesma imagem que foi criada, apenas um retângulo preto. Só por curiosidade, restore() faz o inverso, recupera os pixels do servidor e põe de volta no cliente.

Tendo a nova imagem no lado do servidor, basta atualizar o canvas. Depois, agenda a recuperação do próximo quadro, desta vez respeitando a frequência de quadros do vídeo.

Quando o vídeo termina, cvQueryFrame() returna nulo. Neste caso, não é mais necessário agendar o próximo quadro. Apenas atualiza o canvas, que será pintado de preto, apenas para não ficar exibindo o último quadro do vídeo.

Resultado

O resultado disso tudo pode ser observado neste vídeo que eu gravei:

Conclusão

Bem, isto foi apenas o básico necessário. Apenas exibi o vídeo, sem aplicar nenhum processamento. Isso, obviamente, deve ser feito depois de recuperar o quadro e antes de convertê-lo para RGBA.

Além disso, no exemplo o vídeo é carregado de um arquivo, mas o OpenCV também captura vídeo pela webcam.

Um abraço e até a próxima.

IplImage e FXImage: revisitado

2009-12-28T15:25:00.000-03:00

Anteriormente, falei aqui como utilizar uma imagem do OpenCV (IplImage) e uma do FOX (FXImage), ambas compartilhando o vetor de pixels. Confira aqui.

Pois bem. Fazendo daquela maneira, há certos problemas: ambos objetos devem permanecer vivos, e o dono dos pixels tem que ser a IplImage.

Isto pode não ser desejado. Por exemplo, vou citar o caso que aconteceu comigo e tive que matar um pouco a cabeça para resolver.

Muitas imagens que eu exibo (com o FOX Toolkit) precisam antes passar por algum processamento (com o OpenCV). Depois disso, eu não preciso mais da IplImage, apenas dos pixels.

Entretanto, seguir os passos explicados no outro tópico levava a um problema seriíssimo, que será explicado no decorrer deste tópico.

Compartilhando pixels: antigamente

Conforme eu havia explicado, criava-se primeiro a IplImage e depois a FXImage, utilizando o vetor de pixels, mais ou menos assim:

IplImage *iplImage = cvCreateImage(cvSize(200, 200), IPL_DEPTH_8U, 4);

FXImage *fxImage = new FXImage(getApp(), iplImage->imageData,
    IMAGE_KEEP|IMAGE_OWNED|IMAGE_SHMP|IMAGE_SHMI,
    iplImage->width, iplImage->height);

Lembrando que era necessário um cast horroroso com reinterpret_cast para transformar os pixels da IplImage de char* para FXColor.

Com isso, eu tenho que minha IplImage "doou" seus pixels para a FXImage, que tomou conta deles. Assim, a IplImage poderia ser dispensada (na verdade, somente o cabeçalho da imagem; o OpenCV permite isso) que a FXImage, quando for liberada, libera também o vetor de pixels.

O problema

Isso causa um problema que eu demorei muito para descobrir. E, depois de descoberto, vê-se que é uma coisa tão simples... é sempre um detalhezinho que cega a gente.

O grande problema é que, como o vetor de pixels é alocado pela IplImage, ele é alocado usando malloc. A FXImage, quando tenta liberar, tenta com delete. Aí não dá certo...

A "solução"

Eu criava as imagens independentemente, cada uma com seu vetor de pixels. Depois de processada, eu fazia uma chamada a memcpy para copiar os pixels. Uma tristeza considerando o contexto.

Compartilhando pixels: a solução de fato

Depois de quase desistir da idéia, eu descobri (dia desses...) o problema. E logo cheguei a uma solução elegante (e óbvia).

Basta criar primeiro a FXImage, que vai apenas "emprestar" os pixels para a IplImage. Assim:

FXImage *fxImage = new FXImage(getApp(), 0,
    IMAGE_KEEP|IMAGE_OWNED|IMAGE_SHMP|IMAGE_SHMI,
    200, 200);

Percebam que o segundo parâmetro, que seria o vetor de pixels, é nulo. Como os pixels são de responsabilidade da FXImage, ela mesma os cria (isso é informado pela opção IMAGE_OWNED).

É necessário também manter os pixels no lado do cliente (opção IMAGE_KEEP). Sem ela, os pixels são liberados depois da imagem criada, impossibilitando o compartilhamento.

Pois bem, agora vamos "emprestar" os pixels da FXImage para a IplImage:

IplImage *iplImage = cvCreateImageHeader(cvSize(200, 200),
    IPL_DEPTH_8U, 4);
  cvSetData(iplImage, fxImage->getData(), CV_AUTOSTEP);

cvCreateImageHeader() aloca todas as informações de uma imagem, com exceção do vetor de pixels. Com isso, a IplImage, que é temporária, apenas pega emprestado os pixels para trabalhar sobre eles. Ao terminar o processamento, podemos liberar o cabeçalho:

cvReleaseImageHeader(&iplImage);

Uma grande vantagem dessa abordagem é que não precisa nem converter a imagem, conforme eu havia feito anteriormente. A imagem já é criada no formato da FXImage.

Conclusão

Conforme havia dito, é uma coisa tão simples e óbvia que fica invisível.

Espero que essa informação seja útil para quem for usar essas duas bibliotecas juntas.

Abraço e até a próxima.

Submenus

2009-12-23T14:37:00.000-03:00

Dando continuidade à nossa série sobre Menus, falarei agora sobre como adicionar submenus. Vamos lá.

Submenus são menus como quaisquer outros

Isso mesmo. O processo de criar um submenu é praticamente o mesmo de criar um menu "normal".

Para exemplificar o processo, vamos criar um menu "Exibir", com um submenu "Zoom". Neste caso, temos dois painéis, que serão declarados da seguinte maneira:

FXMenuPane *_viewMenu;
FXMenuPane *_zoomMenu;

Lembrando que eles devem estar no escopo de classe, pois precisam ser liberados manualmente.

Percebam que o submenu "Zoom" nada mais é que um FXMenuPanel como todos os outros que já vimos até aqui. Agora vamos criá-los, novamente recuando o código para indicar a hierarquia.

_viewMenu = new FXMenuPane(this);
  _zoomMenu = new FXMenuPane(this);
    new FXMenuCommand(_zoomMenu, "&Aumentar\tCtrl++");
    new FXMenuCommand(_zoomMenu, "&Normal\tCtrl+0");
    new FXMenuCommand(_zoomMenu, "&Diminuir\tCtrl+-");

    new FXMenuSeparator(_zoomMenu);

    new FXMenuCommand(_zoomMenu, "A&justar\tHome");
  new FXMenuCascade(_viewMenu, "&Zoom", 0, _zoomMenu);
new FXMenuTitle(menuBar, "&Exibir", 0, _viewMenu);

Explicando...

Na primeira linha, aloco o menu "Exibir".

Na segunda, aloco o (sub)menu "Zoom". Chamando atenção para o recuo, indicando que _zoomMenu será posicionado "dentro" de _viewMenu;

Nas linhas seguintes, preencho com alguns comandos e um separador. Nada além do trivial com recuo.

Em seguida, criamos a entrada no menu "Exibir" que vai expandir o menu "Zoom". Repetindo:

new FXMenuCascade(_viewMenu, "&Zoom", 0, _zoomMenu);

Os parâmetros são os mesmos de FXMenuTitle (comparem com a última linha):

O FXComposite onde ficará localizado o submenu. Neste caso, adicionamos ao painel "Exibir"
O título que vai aparecer no painel, com direito a mnemônico
Ícone
O painel que será exibido ao mover o mouse sobre o título.

Liberando

Como todo bom painel de menu, deve ser liberado manualmente:

delete _viewMenu;
delete _zoomMenu;

Só uma observação: já tratei esse assunto aqui, então é só um lembrete. Quando eu falo em deletar manualmente, é porque estou usando o FOX 1.6. Na versão atual de desenvolvimento (1.7), existe uma classe chamada FXAutoPtr, que é um "ponteiro inteligente". Resumindo a história, ele guarda um ponteiro e automaticamente o libera quando sai de escopo. Veja a descrição aqui (na verdade, uma dúvida enviada à lista de discussão do FOX que eu traduzi e postei aqui).

Resultado

Eis o resultado do nosso submenu:

Menus

2009-12-14T13:54:00.001-03:00

Neste tópico, ensinarei como adicionar uma barra de menus (com menus, obviamente) ao programa. Neste momento, colocarei menus simples, apenas com comandos simples. Há outros componentes que podem ser adicionados aos menus, mas serão tratados em tópicos futuros.

Vamos lá.

Barra de menus

Tudo começa com a barra de menus. Naturalmente, é lá que ficam os menus. E, naturalmente, fica no topo da janela:

FXMenuBar *menuBar = new FXMenuBar(this, LAYOUT_FILL_X|FRAME_RAISED);

Percebam que ela pode ser criada localmente, o próprio FOX se encarrega de liberá-la depois. Além disso, lembrem-se que a localização padrão é no topo da janela, portanto não precisei passar LAYOUT_SIDE_TOP.

Isso cria o espaço ideal para os menus. Aqui, criarei apenas dois, "Arquivo" e "Editar", apenas para exemplificar. Não é um processo complicado. Pelo contrário, é bem simples.

Adicionando menus

Os menus precisam ser declarados com escopo de classe. Então, na declaração da classe, temos:

protected:
  FXMenuPane *_fileMenu;
  FXMenuPane *_editMenu;

Agora, vamos criar e preencher os menus. Neste primeiro exemplo, do menu "Arquivo", vou colocar e explicar linha por linha. No segundo, o menu "Editar", vou colocar tudo de uma vez só para explicar a forma como eu gosto de criar os menus.

Menu Arquivo

_fileMenu = new FXMenuPane(this);

Cria o painel onde ficarão os itens do menu. Os dois parâmetros do construtor são a janela pai e as opções, que não é necessário informar.

new FXMenuCommand(_fileMenu, "&Carregar imagem...", 0, 0, 0);

Cria um comando de menu. Os principais parâmetros são:

Menu onde vai aparecer. Na verdade, pode ficar em um FXComposite qualquer (e, de fato, eu coloquei um sem querer na própria janela, ficou algo bizarro). Como estamos criando menus, é bom que fique em um FXMenuPanel. Neste caso, no menu "Arquivo".
Texto do comando. O caractere & indica que a próxima letra ficará sublinhada, para acesso através de Alt+. Neste caso, Alt+C acionará esse comando. É meio Uíndous, mas muito melhor que em Java (um setMnemonic() horroroso).
Ícone. FXMenuCommands podem ter um ícone associado, indique aqui. Já falei sobre ícones aqui.
Alvo do evento.
ID da mensagem. A série sobre Tratamento de Eventos explica essa parte referente a esses dois últimos parâmetros.

O último parâmetro são as opções, novamente desnecessário informar.

E caso não tenha ficado claro pelo nome da classe: FXMenuCommands lançam eventos do tipo SEL_COMMAND. Isso significa que no mapa de mensagens do tratador (seja a própria janela ou seja lá quem for) vai aparecer algo como:

FXMAPFUNC(SEL_COMMAND,
  FoxTutorialMainWindow::ID_LOAD_IMAGE,
  FoxTutorialMainWindow::onCmdLoadImage),

Continuando:

new FXMenuSeparator(_fileMenu);

Apenas um separador. Desenha uma linha para separar os comandos em seções.

new FXMenuCommand(_fileMenu, "&Sair\tCtrl+Q\tEncerrar o aplicativo",
        0, getApp(), FXApp::ID_QUIT);

Mais um comando, para fechar o aplicativo. Desta vez fiz com que esse comando lançasse um evento para exemplificar. Já falei sobre como fechar o aplicativo através de um comando aqui.

A única observação adicional é quanto ao texto do comando. Assim como o texto dos botões, este também é dividido em três seções, separadas pelo caractere de tabulação:

A primeira é o texto que será exibido. Natural e praticamente obrigatório.
A segunda são as teclas de atalho (aceleradores). Neste caso, coloquei Ctrl+Q para fechar o aplicativo. Opcional.
A terceira é o texto que aparecerá na barra de status. Falaremos dela no futuro. Opcional.

Bom, isso preenche o nosso menu "Arquivo". Vamos, agora, adicioná-lo à barra de menus (ou vocês achavam que isso já tinha sido feito?):

new FXMenuTitle(menuBar, "&Arquivo", 0, _fileMenu);

Aqui informamos:

A barra de menus onde vai ficar. Novamente, pode ficar em um FXComposite qualquer. Mas não há a menor necessidade de uma bizarrice dessas.
O título que vai aparecer. Não preciso mais dizer para que serve o &, preciso?
Ícone. Eu, particularmente, nunca vi em nenhum programa (escrito em FOX ou não) um menu com ícone. Mas o FOX Toolkit te dá essa liberdade.
O painel que será exibido ao acionar o menu.

Nosso menu Arquivo está pronto. Observemos, agora, o menu Editar.

Menu Editar

_editMenu = new FXMenuPane(this);
  new FXMenuCommand(_editMenu, "&Preferências...", 0, 0, 0);
new FXMenuTitle(menuBar, "&Editar", 0, _editMenu);

Bom, esse aqui é só para mostrar a maneira como eu normalmente crio menus (e, de fato, qualquer objeto composto por uma hierarquia).

Na primeira linha eu sigo o recuo normal do código. Esta é, digamos, a linha de criação (cunhei esse termo agora...).

Em seguida, vêm as linhas de preenchimento (de novo...). Nelas, coloco os objetos que vão "dentro" do objeto principal, com um recuo a mais exatamente para deixar claro essa hierarquia.

No final, volto ao recuo da linha de criação. É a linha de realização ( >D ), pois nela dou um sentido ao meu objeto (afinal, não faz sentido criar um painel sem acesso a ele).

Desenvolvi esse estilo quando comecei a trabalhar com o OpenSceneGraph (não confundam com OpenSG) e precisava definir as características de um modelo, ficava mais ou menos assim:
osg::ref_ptr geode = new osg::Geode();
  osg::Geometry *geometry = new osg::Geometry();
   osg::Vec3Array *vertexArray = new osg::Vec3Array();
   /* Preenche a lista de vértices */
   geometry->setVertexArray(vertexArray);

   osg::DrawElementsUInt *primitiveSet = new osg::DrawElementsUInt(GL_POINTS);
   /* Adiciona as primitivas */
   geometry->addPrimitiveSet(primitiveSet);
  geode->addDrawable(geometry);

Recuar os objetos mais internos me ajudou a entender melhor a hierarquia dos objetos do OpenSceneGraph e acabei aplicando essa técnica ao programar com o FOX Toolkit. Não vou explicar porque está fora do escopo do tópico (e do blog como um todo...).

Bom, é apenas uma sugestão.

Liberando os menus

FXMenuPanels são objetos compartilháveis, assim como ícones. Isso serve, por exemplo, para exibir o mesmo painel pelo menu ou clicando com o botão direito sobre algum objeto.

Sendo assim, devem ser liberados "na mãozona":

delete _fileMenu;
delete _editMenu;

Resultado

Depois disso tudo, o menu Arquivo fica conforme a imagem a seguir. Em destaque, a barra de status mostrando o texto do comando de sair.

Considerações finais

Notem o texto dos comandos de "Carregar imagem..." (menu Arquivo) e "Preferências..." (menu Editar). Eles terminam em reticências.

Terminar um texto de exibição (tanto de comandos de menu como também de botões) com reticências informa imediatamente ao usuário que uma nova janela se abrirá, onde ele terá que executar mais ações.

Outra observação importante é onde posicionar o código para criação dos menus. No início, eu colocava tudo no construtor. As coisas foram aumentando de tamanho, e resolvi apenas criar a barra no construtor e chamar uma função, populateMenu(), para fazer essa tarefa.

Agora, as coisas no meu projeto estão ficando grandes demais, e estou pensando seriamente em criar uma nova classe só para isso. Acontece que, na pressa de obter resultados, a gente acaba tocando tudo no mesmo lugar. Nessa brincadeira até o padrão MVC vai para o espaço. Por favor, não façam isso.

Bom, esse é o que tem de mais básico em termos de menus. Ainda vou discutir sobre submenus e outros elementos que podem aparecer em um FXMenuPanel. Um abraço e até lá.

FXMessageBox: Tratando a resposta do usuário

2009-09-25T16:52:00.000-03:00

Neste tutorial, falei sobre as opções de botões que o FXMessageBox fornece ao usuário. Obviamente, cada mensagem requer um conjunto de botões adequado. Mas como saber qual botão foi pressionado?

Hoje, veremos como detectar qual o botão clicado pelo usuário, em resposta à mensagem exibida.

Relembrando o conjunto de botões

O protótipo das funções que exibem mensagens são da seguinte forma (message, aqui, é utilizado como um nome genérico para information, question, warning e error):

static FXuint message(FXWindow* owner, FXuint opts, const char* caption,
        const char* message, ...);

O parâmetro opts é onde se informa o conjunto de botões que vão aparecer na mensagem, através da seguinte enumeração (abstraindo os valores):

enum {
  MBOX_OK,
  MBOX_OK_CANCEL,
  MBOX_YES_NO,
  MBOX_YES_NO_CANCEL,
  MBOX_QUIT_CANCEL,
  MBOX_QUIT_SAVE_CANCEL,
  MBOX_SKIP_SKIPALL_CANCEL,
  MBOX_SAVE_CANCEL_DONTSAVE
};

Percebam, então, que os botões que podem aparecer em uma mensagem são:

OK
Cancel
Yes
No
Quit
Save
Don't save
Skip
Skip All

Tratando a resposta

Voltando ao protótipo da função, vemos que ela retorna um FXint. É justamente esse retorno que indica qual o botão pressionado. Esse valor também está presente em uma enumeração para facilitar (dar nomes a números mágicos é uma boa prática de programação). Essa enumeração é a seguinte:

enum {
  MBOX_CLICKED_YES      = 1,    /// The YES button was clicked
  MBOX_CLICKED_NO       = 2,    /// The NO button was clicked
  MBOX_CLICKED_OK       = 3,    /// The OK button was clicked
  MBOX_CLICKED_CANCEL   = 4,    /// The CANCEL button was clicked
  MBOX_CLICKED_QUIT     = 5,    /// The QUIT button was clicked
  MBOX_CLICKED_SAVE     = 6,    /// The SAVE button was clicked
  MBOX_CLICKED_SKIP     = 7,    /// The SKIP button was clicked
  MBOX_CLICKED_SKIPALL  = 8     /// The SKIP ALL button was clicked
};

Oito valores enumerados para nove botões?

É...

Fuçando no código fonte, descobri algo assim:

new FXButton(buttons, "&Don't Save", NULL, this, ID_CLICKED_NO, ...

Ou seja, o valor retornado quando o usuário clica em "Don't Save" é MBOX_CLICKED_NO. Faz sentido, mas eu acharia melhor se tivesse um nome específico, o valor até poderia ser o mesmo. Mas vai entender...

Exemplo

Vou dar um exemplo simples, até porque aqui não tem mistério nenhum (fora esse de cima...). Suponha que o usuário vai realizar uma operação que não pode ser desfeita. Isso deve ser informado ao usuário, caso ele volte atrás em sua decisão. Nosso tratador fica assim:

long FoxTutorialMainWindow::onCmdEraseAll(FXObject*, FXSelector sel, void*) {
  FXuint answer;

  answer = FXMessageBox::question(this, MBOX_YES_NO, "Apagar tudo",
      "Essa ação não pode ser desfeita.\nDeseja continuar?");

  switch (answer) {
    case MBOX_CLICKED_YES:
      FXMessageBox::information(this, MBOX_OK, "Dados apagados",
          "Todos os dados foram apagados.");
    break;

    case MBOX_CLICKED_NO:
      FXMessageBox::information(this, MBOX_OK, "Dados não apagados",
          "Os dados não foram apagados.");
    break;

    default: break;
  }

  return 1;
}

Resultado

Discussão

Nada de mais aqui. Se o usuário clicou em "Yes", exibe uma mensagem informando que todos os dados foram apagados. Se clicou em "No", informa que não foram apagados. Realmente sem mistérios.

Conclusão

Este tópico foi apenas um complemento de outro anterior (link). Aqui encerro oficialmente a série sobre o FXMessageBox. A partir daqui, começaremos a falar de elementos que compõem uma interface gráfica típica (menus, barras de ferramentas, barra de status etc.). Até lá!

Tratamento de Eventos: Sem eventos a tratar

2009-09-18T13:41:00.007-03:00

Pode parecer contraditório (e talvez realmente seja) o título deste tópico, mas não vejo onde mais encaixá-lo senão na categoria de Tratamento de Eventos.

Acontece que às vezes criamos uma janela que não precisa tratar nenhum evento em especial, portanto não necessita do mapa de mensagens. É sobre isso que falarei neste tópico.

Quando a janela não trata eventos

Imagine que você precisa de uma janela apenas para exibir algumas informações. Nenhuma entrada do usuário é necessária, nenhuma ação do usuário é executada. Essa janela não precisa tratar evento nenhum, então não precisa de um mapa de mensagens.

Ainda assim, precisa chamar a macro FXIMPLEMENT.

Uma pausa para algumas explicações

Depois de tantos tópicos escritos, só agora senti a necessidade de explicar para que serve esse par de macros: FXDECLARE/FXIMPLEMENT. Confesso que eu simplesmente utilizava, mas sem saber qual o real significado delas. Escrevendo este tópico, tive a curiosidade de investigá-las.

A macro FXDECLARE, como o próprio nome sugere, é colocada dentro da declaração da classe. Após expandida, ela toma a seguinte forma (coloquei espaços para melhorar a legibilidade ):

public:
  struct FXMapEntry {
    FX::FXSelector keylo;
    FX::FXSelector keyhi;
    long (classname::* func)(FX::FXObject*,FX::FXSelector,void*);
  };
  
  static const FX::FXMetaClass metaClass;

  static FX::FXObject* manufacture();

  virtual long handle(FX::FXObject* sender,FX::FXSelector sel,void* ptr);

  virtual const FX::FXMetaClass* getMetaClass() const {
    return &metaClass;
  }

  friend FX::FXStream& operator <<(FX::FXStream& store,const classname* obj) {
    return store.saveObject((FX::FXObjectPtr)(obj));
  }

  friend FX::FXStream& operator >>(FX::FXStream& store,classname*& obj) {
    return store.loadObject((FX::FXObjectPtr&)(obj));
  }

private:

Explicando:

Ela cria uma struct interna, chamada FXMapEntry, que armazena as entradas do mapa de mensagens.
Declara um objeto estático do tipo FXMetaClass, que armazena informações que descrevem um objeto FOX.
manufacture() nada mais é que um método fábrica que retorna um novo objeto; por isso o construtor padrão vazio privado é obrigatório.
handle() é o método utilizado para executar as ações propriamente ditas e também utilizado para delegar ações a outros objetos.
Os demais são irrelevantes no momento.

Pois bem, a outra macro, FXIMPLEMENT, é o complementar de FXDECLARE. É ela quem vai implementar os métodos declarados por FXDECLARE. Por isso ela é obrigatória, mesmo na ausência do mapa de mensagens. Após expandida, o método handle() é implementado da seguinte maneira:

long classname::handle(FX::FXObject* sender, FX::FXSelector sel, void* ptr) {
  const FXMapEntry* me=(const FXMapEntry*)metaClass.search(sel);

  return me ? (this->* me->func)(sender,sel,ptr)
            : baseclassname::handle(sender,sel,ptr);
}

Fuçando no código-fonte, vi que o método search() faz uma busca linear pelo mapa de mensagens, até encontrar uma entrada contenha o FXSelector sel (passado como parâmetro de handle()). Vejam:

const void* FXMetaClass::search(FXSelector key) const {
  register const FXObject::FXMapEntry* lst=(const FXObject::FXMapEntry*)assoc;
  register FXuint n=nassocs;

  while(n--) {
    if (lst->keylo <= key && key <= lst->keyhi)
      return lst;

    lst = (const FXObject::FXMapEntry*) (((const FXchar*)lst)+assocsz);
  }

  return NULL;
}

Ou seja, se encontrar a entrada, executa a função associada; senão, delega para a superclasse. Isto segue o padrão de projeto "Cadeia de Responsabilidade" ("Chain of Responsibility"), em que um objeto vai delegando a ação a seus superiores (digamos assim), até que alguém o trate. Neste caso, o topo da hierarquia é FXObject, cujo método handle() chama onDefault(), que apenas retorna 0.

Voltando...

Depois de toda essa explicação, podemos voltar ao nosso assunto principal. Suponhamos que temos uma janela que não trata nenhum evento. Neste caso, existem duas opções: declarar um mapa vazio, ou simplesmente não declarar mapa nenhum. A primeira opção já foi discutida em um dos primeiros tutoriais, mas vou reproduzi-la aqui:

FXDEFMAP(FoxTutorialMainWindow) FoxTutorialMainWindowMap[] = {
};

FXIMPLEMENT(FoxTutorialMainWindow, FXMainWindow,
    FoxTutorialMainWindowMap, ARRAYNUMBER(FoxTutorialMainWindowMap))

Neste caso, a macro ARRAYNUMBER calcula o tamanho do vetor, que é 0 (cuidado: alguns compiladores reclamam). Na hora da busca pela mensagem, o laço while é ignorado e a função retorna NULL, disparando o processo já discutido.

A outra maneira é não declarar mapa nenhum. A chamada a FXIMPLEMENT fica assim:

FXIMPLEMENT(FoxTutorialMainWindow, FXMainWindow, NULL, 0)

Conclusão

Acho que este tópico encerra a discussão sobre o mapa de mensagens. Se eu me lembrar de alguma outra coisa nesse sentido, postarei aqui.

Entretanto, ainda há muito o que falar com relação ao tratamento de mensagens. Essa série será bem longa! Até a próxima!

Tratamento de Eventos: Uma ação para vários IDs

2009-09-17T12:31:00.002-03:00

Quando falei sobre o mapa de mensagens (aqui), eu adicionei quatro mapeamentos. Entretanto, todos eles eram do mesmo tipo e chamavam a mesma ação; vejam:

FXMAPFUNC(SEL_COMMAND,
  FoxTutorialMainWindow::ID_INFORMATION,
  FoxTutorialMainWindow::onCmdMessage),

FXMAPFUNC(SEL_COMMAND,
  FoxTutorialMainWindow::ID_QUESTION,
  FoxTutorialMainWindow::onCmdMessage),

FXMAPFUNC(SEL_COMMAND,
  FoxTutorialMainWindow::ID_WARNING,
  FoxTutorialMainWindow::onCmdMessage),

FXMAPFUNC(SEL_COMMAND,
  FoxTutorialMainWindow::ID_ERROR,
  FoxTutorialMainWindow::onCmdMessage),

Uma situação dessas ocorre quando eu tenho várias ações muito semelhantes: em vez de definir um callback para cada ação, eu defino apenas um; a diferença entre eles é feita dentro do corpo da função.

O FOX Toolkit fornece uma macro auxiliar para facilitar essa tarefa: FXMAPFUNCS. Neste tópico, explicarei como usá-la.

Definindo uma ação para vários IDs

Diante de uma situação dessas, seria bem mais fácil se eu pudesse diminuir o número de linhas a serem escritas. A propósito, o FOX Toolkit tem um slogan que diz: "Cada linha de código não escrita é uma linha correta". Pense no caso de uma calculadora: cada botão executa uma ação bem semelhante um ao outro: adicionar o seu valor à expressão e atualizar a caixa de texto que a exibe.

Imagina se eu tivesse que escrever uma função para cada botão? Seriam 10 botões de dígitos + 5 operações (contanto com a igualdade), isso apenas para uma calculadora básica. 15 funções, 15 entradas no mapa.

Para facilitar, pode-se definir apenas uma função e ligá-las todas aos botões da calculadora. E para evitar as quinze entradas no mapa, utiliza-se a macro FXMAPFUNCS. Para não ficar maçante, e reaproveitar os códigos já escritos, vou voltar ao exemplo do tutorial sobre as mensagens exibidas ao usuário.

Declarando as mensagens

Para poder utilizar a macro FXMAPFUNCS, é necessário que os IDs das mensagens sejam declarados seqüencialmente. Isso porque a macro pega um intervalo de IDs. No nosso exemplo:

enum {
  ID_INFORMATION = FXMainWindow::ID_LAST,
  ID_QUESTION,
  ID_WARNING,
  ID_ERROR,

  ID_LAST,
};

Com isso, basta usar a macro mágica. A sintaxe dela é:

FXMAPFUNCS(tipo, ID_min, ID_max, callback)

No nosso exemplo, o mapa de mensagens fica assim:

FXDEFMAP(FoxTutorialMainWindow) FoxTutorialMainWindowMap[] = {
  FXMAPFUNCS(SEL_COMMAND,
             FoxTutorialMainWindow::ID_INFORMATION,
             FoxTutorialMainWindow::ID_ERROR,
             FoxTutorialMainWindow::onCmdMessage),
};

Ou seja, com apenas uma chamada, eu defini a mesma ação para quatro mensagens diferentes.

Diferenciando as mensagens

Já que cada evento vai disparar a mesma ação, é preciso diferenciar os diferentes eventos. Todo callback no FOX Toolkit tem o mesmo formato (com os nomes típicos dos parâmetros):

long onAction(FXObject *sender, FXSelector sel, void *ptr);

Neste caso, o que mais importa é o segundo parâmetro (sempre que um parâmetro não for utilizado, pode permanecer anônimo). Um FXSelector nada mais é que uma mistura entre o tipo de mensagem e o ID da mensagem. Essa mistura é feita automaticamente pela macro FXSEL ao se acrescentar uma entrada no mapa. Apenas adiantando uma informação, essa macro também é utilizada ao se delegar ações; falarei sobre isso no futuro.

Já que o FOX junta essas duas informações, ele pode separá-las: FXSELID recupera o ID da mensagem, e FXSELTYPE recupera o tipo da mensagem. Sendo assim, fica fácil saber quem enviou a mensagem, sem precisar recorrer a ponteiros (como normalmente acontece com uma certa linguagem que dizem não ter ponteiros). Um teste switch resolve o caso:

long FoxTutorialMainWindow::onCmdMessage(
        FXObject*, FXSelector sel, void*) {
  switch (FXSELID(sel)) {
    case ID_INFORMATION:
      FXMessageBox::information(this, MBOX_OK, "Informação",
              "Operação finalizada");
    break;

    case ID_QUESTION:
      FXMessageBox::question(this, MBOX_YES_NO, "Sair",
              "Deseja realmente sair do programa?");
    break;

    case ID_WARNING:
      FXMessageBox::warning(this, MBOX_OK, "Aviso",
              "Valor não especificado.\nAtribuindo padrão 1.");
    break;

    case ID_ERROR:
      FXMessageBox::error(this, MBOX_OK, "Erro",
              "%s: Arquivo não encontrado", filename.text());
    break;

    default: break;
  }

  return 1;
}

Percebam que como eu não uso nem o primeiro nem o último parâmetro, deixei eles anônimos. Dar um nome a eles pode gerar um warning enjoado por parte do compilador.

Conclusão

Neste exemplo, utilizei FXSELID para recuperar o ID da mensagem dentro do FXSelector. Mas eu falei também de FXSELTYPE, para recuperar o tipo. Isso me dá a chance de definir a mesma ação para diferentes tipos e diferenciá-los dentro da função.

Não tenho certeza se dá para fazer algo semelhante no mapa; existem duas macros, FXMAPTYPE e FXMAPTYPES, mas nunca as utilizei. Parece que elas definem um mapeamento de um tipo de mensagem (ou intervalo de tipos, no caso da segunda) para todos os IDs possíveis, chamando a mesma ação. Resumindo: melhor não usar.

Com relação ao mapa de mensagens, acho que só falta falar de quando uma janela não trata nenhum evento. Mas se eu lembrar de mais alguma outra coisa, eu posto aqui. Até a próxima.

Tratamento de Eventos: Tipos de mensagem

2009-09-15T12:10:00.001-03:00

No tópico anterior, falei especificamente sobre o mapa de mensagens. Neste tópico, falarei sobre alguns tipos de mensagem que podem ser disparados.

Talvez esse tópico seja um pouco maçante, porque existem diversos tipos. Vou ser breve em cada um deles, pois são mais uma questão de prática que de teoria.

Outra característica deste tópico é que, apesar de no FOX Toolkit não haver nenhuma distinção de categoria de eventos (eventos de mouse, teclado, janela etc), vou dividi-los aqui dessa forma para facilitar a leitura.

Os tipos de mensagem estão definidos em fxdefs.h. Não vou copiá-lo aqui porque são 80 tipos de mensagem (sem contar o primeiro, SEL_NONE, e o último, SEL_LAST). Estão definidos dentro da enumeração FXSelType, e todos têm o prefixo SEL_. Sendo 80, é muito provável que a maioria deles não seja utilizada. Eu, pelo menos, não utilizo muitos. Portanto, vou limitar a minha explicação àqueles que eu já usei, ou que pelo menos sei para que servem.

Vou tentar também seguir a ordem em que são declarados na enumeração. Ainda, vou agrupar eventos muito semelhantes ou complementares. Comecemos então a analisá-los.

Eventos de teclado

SEL_KEYPRESS
SEL_KEYRELEASE

Em se tratando de teclado, há somente esses dois eventos a serem tratados. Uma tecla foi pressionada (SEL_KEYPRESS), uma tecla foi liberada (SEL_KEYRELEASE).

Apenas uma observação: se o programa não se importar com qual foi a tecla pressionada/liberada, não há nada extra. Mas se a tecla for importante, é necessário incluir o arquivo fxkeys.h. Nele estão as definições dos valores de todas as teclas que podem ser pressionadas.

Eventos de mouse

SEL_LEFTBUTTONPRESS
SEL_LEFTBUTTONRELEASE

Botão esquerdo do mouse pressionado/liberado.

SEL_MIDDLEBUTTONPRESS
SEL_MIDDLEBUTTONRELEASE

Botão do meio do mouse pressionado/liberado.

SEL_RIGHTBUTTONPRESS
SEL_RIGHTBUTTONRELEASE

Botão direito do mouse pressionado/liberado.

SEL_MOTION
SEL_ENTER
SEL_LEAVE

Esses três tipos de mensagem referem-se ao movimento do mouse relativo ao objeto que lança o evento. Quando um mouse entra na área do objeto, este lança um evento do tipo SEL_ENTER. Quando o mouse se move dentro de um objeto, este lança um evento do tipo SEL_MOTION. Finalmente, quando o mouse sai da área do objeto, este lança um evento do tipo SEL_LEAVE.

SEL_CLICKED
SEL_DOUBLECLICKED
SEL_TRIPLECLICKED
SEL_MOUSEWHEEL

Clique, duplo clique, triplo clique e movimento da roda do mouse. Não lembro de ter usado nenhum dos três primeiros.

Já o tratamento do evento da roda do mouse é meio esquisito; no momento não me recordo como é feito, mas futuramente falaremos disso.

Eventos de janela

SEL_PAINT

Indica que um objeto deve ser redesenhado. Muito útil quando se tem um canvas: define-se um callback que desenha no canvas, que é executado sempre que este lança um evento do tipo SEL_PAINT.

SEL_CONFIGURE

Este evento é lançado quando a janela é redimensionada. Este aqui é utilizado, por exemplo, quando há uma janela com um canvas OpenGL que, ao ser redimensionada, precisa reajustar a viewport e as matrizes de visualização para evitar distorções na imagem (quem trabalha com OpenGL sabe do que estou falando).

SEL_UPDATE

Este evento é lançado constantemente pelo objetos. Ao capturar um evento destes, é possível alterar o estado do objeto que o lançou. Por exemplo, um botão deve permanecer inativo enquanto não houver nenhum arquivo aberto; a partir do momento em que abre-se um arquivo, este botão deve ser ativado. Isto pode ser feito capturando-se o evento do tipo SEL_UPDATE que ele lança.

Execução de comandos

SEL_COMMAND

Sempre que eu falo desse tipo de mensagem eu dou os exemplos mais básicos possíveis: um botão clicado e um menu acionado. Mas não são somente botões e menus que enviam mensagens deste tipo. Diversos componentes também o fazem, mas isso fica para tópicos mais específicos. Por enquanto, esses dois exemplos são suficientes.

SEL_TIMEOUT

Serve para chamar a ação associada depois de um determinado intervalo de tempo.

SEL_CHORE

Serve para executar a ação associada sempre que não houver nenhum outro evento para tratar.

No início, eu utilizava para redesenhar o canvas o tempo inteiro. Em aplicações simples, isso não proporcionava perda de desempenho perceptível. Quando eu fiz um programa maior, de reconstrução de subestações elétricas, isso deixava lentíssimo. Foi só eu deixar isso de lado e atualizar o canvas somente quando necessário e o programa ficou uma bala. Portanto, evitem usar o chore dessa maneira, a menos que vocês queiram ter certeza que o processador está trabalhando (possivelmente à toa...).

Curiosidade: "chore" significa "tarefa doméstica".

Conclusão

Este tópico foi apenas uma introdução aos tipos de mensagem, mostrando apenas um pouco da teoria. Bem melhor será quando forem vistos na prática. Portanto, escreverei tópicos específicos para explicar com mais detalhes e mostrar exemplos do tratamento de cada tipo aqui apresentado. Até lá.

Tratamento de Eventos: Mapa de mensagens

2009-09-14T14:26:00.001-03:00

O mapa de mensagens é, digamos assim, o cerne do tratamento de eventos no FOX Toolkit. É ele quem determina que callback deve ser chamado em resposta a que tipo de mensagem, enviada por um determinado objeto.

Neste tópico, explicarei com mais detalhes como funciona o mapa. Vamos lá.

Definição do mapa

O mapa de mensagens é definido através da macro FXDEFMAP. Essa macro recebe um parâmetro, que é o nome da classe. Com esta macro, declara-se um vetor onde são armazenados os mapeamentos de mensagens; essa macro expandida nada mais é que uma declaração de uma variável normal. Seguindo o exemplo dos nossos tutoriais, temos o seguinte:

FXDEFMAP(FoxTutorialMainWindow) FoxTutorialMainWindowMap[] = {

};

Essa macro (que termina com o parêntese fechado) é expandida na seguinte declaração:

static const FoxTutorialMainWindowMap::FXMapEntry
        FoxTutorialMainWindowMap[] = {

};

Sendo que FXMapEntry é uma struct interna criada automaticamente pela macro FXDECLARE, chamada ao declararmos a classe FoxTutorialMainWindow (lembram?). Ou seja, estamos declarando um vetor de entradas do mapa de mensagem.

Percebam o nome do vetor de mapeamento. Aqui temos um padrão de nomenclatura: o nome do vetor é composto pelo nome da classe com o sufixo "Map".

Dentro deste vetor, colocamos os mapeamentos em si. Isto é feito com auxílio da macro FXMAPFUNC, que veremos em seguida.

Adicionando mapeamentos

A macro FXMAPFUNC recebe três parâmetros: o tipo da mensagem, o ID da mensagem e um ponteiro para o callback. Tomando como exemplo este tutorial, adicionamos os seguintes mapeamentos:

FXMAPFUNC(SEL_COMMAND,
    FoxTutorialMainWindow::ID_INFORMATION,
    FoxTutorialMainWindow::onCmdMessage),

FXMAPFUNC(SEL_COMMAND,
    FoxTutorialMainWindow::ID_QUESTION,
    FoxTutorialMainWindow::onCmdMessage),

FXMAPFUNC(SEL_COMMAND,
    FoxTutorialMainWindow::ID_WARNING,
    FoxTutorialMainWindow::onCmdMessage),

FXMAPFUNC(SEL_COMMAND,
    FoxTutorialMainWindow::ID_ERROR,
    FoxTutorialMainWindow::onCmdMessage),

Tipo de mensagem

Informa qual o tipo de evento que foi disparado: um comando, um clique do mouse, uma tecla pressionada, uma janela redimensionada etc.

Teremos um tópico exclusivo (ou vários tópicos...) para discutir os diferentes tipos de mensagem.

ID da mensagem

De certa maneira, identifica quem enviou a mensagem. Junto com o tipo da mensagem, tem-se uma combinação suficiente para dizer que ação (callback) deve ser executada. Essa combinação deve ser única, portanto uma declaração como a seguinte não é válida:

FXMAPFUNC(SEL_COMMAND, ID_ACTION, onCmdAction1),
FXMAPFUNC(SEL_COMMAND, ID_ACTION, onCmdAction2),

Neste caso, tentamos fazer com que a mesma mensagem ative duas ações, o que na realidade não ocorre. É possível, entretanto, combinar a mesma mensagem com diferentes tipos, podendo ou não executar a mesma ação. Por exemplo, eu tenho um canvas (área de desenho) que deve executar uma determinada ação quando o mouse for clicado e outra quando for redimensionado. Como é um objeto só, ele vai ter apenas um ID, diga-se ID_CANVAS. No mapa, teremos (para efeito de exemplo, vou omitir o escopo dos identificadores; compare com os exemplos reais acima):

FXMAPFUNC(SEL_CLICKED, ID_CANVAS, onCanvasClick),
FXMAPFUNC(SEL_CONFIGURE, ID_CANVAS, onCanvasConfigure),

É possível, ainda, que um mesmo ID, com diferentes tipos de mensagem, execute a mesma ação. Digamos que nosso canvas trate igualmente o clique com o botão esquerdo e direito do mouse:

FXMAPFUNC(SEL_LEFTBUTTONPRESS, ID_CANVAS, onCanvasClick),
FXMAPFUNC(SEL_RIGHTBUTTONPRESS, ID_CANVAS, onCanvasClick),

Resumindo, apenas a combinação <tipo de mensagem, id da mensagem> deve ser única.

Ponteiro para o callback

É exatamente isso: um ponteiro para a função membro, que foi declarada na classe (e, naturalmente, deve estar devidamente implementada). Realmente não há muito o que dizer aqui.

Observações finais

Nos exemplos didáticos, eu removi o escopo dos identificadores (id e ponteiros de função) por motivos de espaço. É necessário fornecê-los pelo seguinte motivo: a declaração do mapa de mensagens, na verdade, declara um vetor global, ou seja, fora do escopo da classe. Estando fora do escopo da classe, é necessário informá-lo, qualificando os identificadores através do operador de escopo ( :: ).

Outro motivo, talvez menos comum, é que é possível que um objeto de uma classe execute uma ação de outro objeto de outra classe. Isso acontece, por exemplo, quando um botão de uma caixa de diálogo altera o estado de um componente da janela principal, ou seja, o comando deste botão dispara uma ação da janela principal.

Estes dois motivos explicam, também, porque tanto as IDs das mensagens quanto as ações devem estar localizadas na interface pública da classe.

Conclusão

Neste tópico, apresentei alguns detalhes referentes ao mapa de mensagens. É muito importante entendê-lo, já que ele informa que ações devem ser executadas em resposta às diversas ações do usuário.

Existem ainda alguns outros detalhes, mas que deixarei para outros tópicos, pois acho que este já está extenso e cobriu bem o básico. Até lá.

Liberando memória

2009-07-15T12:10:00.003-03:00

Foi postada na lista de e-mails do FOX Toolkit uma dúvida que achei bem interessante para colocar aqui, pois é um assunto básico: liberação de memória.

A dúvida foi enviada por John Selverian, e apresento-a aqui, junto com a resposta dada pelo Jeroen van der Zijp. Ela tem alguns conceitos que ainda não apresentei aqui, mas serve como um norte para o futuro.

Já falei rapidamente sobre isso em tópicos anteriores, mas creio que postando essa dúvida aqui o assunto fique mais sólido, além de apresentar um aspecto bem interessante a esse respeito. Vamos lá.

Liberando memória

Eu tenho uma pergunta bem básica. Eu tenho várias janelas FXDialogBox. Nos arquivos de cabeçalho eu declaro ponteiros e no construtor eu aloco a memória. No método de sair de algumas dessas FXDialogBox eu deleto a memória e em algumas não (sloppy programming, eu acho). Não vejo diferença na alocação de memória ou vazamento. Estou fazendo algo errado ou a memória é automaticamente liberada pelo FOX? Também, muitas vezes meu destrutor não é chamado... isso faz sentido?

Obrigado,

John S

Resposta

O FOX tenta liberar a memória, sim. Mas não há contagem de referência ou coleta de lixo, então ele só deleta as coisas que sabe que pode deletar:

Janelas pais liberam widgets filhos.
A árvore de widgets inteira é liberada pelo FXApp.

Mas:

Recursos compartilhados como ícones, fontes NÃO são deletados, já que várias referências podem existir (exceção: stock icons e cursores que são criados pelo FXApp).

Uma regra simples é deletar, no destrutor do diálogo, todos os ícones/fontes/etc. que você criar em seu construtor do diálogo.

No FOX 1.7, agora tem FXAutoPtr, que faz isso bem fácil:
class MyDialog : public FXDialog {
FXAutoPtr<FXIcon> buttonIcon;
};
A idéia do FXAutoPtr é comportar-se como um ponteiro normal mas agir como o único dono do objeto para o qual aponta, e então quando o FXAutoPtr é destruído então o objeto que ele aponta também é destruído.

Então declarar suas variáveis de ícones como FXAutoPtr em vez de FXIcon* vai eliminar a necessidade de escrever explicitamente comandos delete em seus destrutores.

Espero que ajude,
- Jeroen

---
Retirado da lista de e-mails Foxgui-users. Veja o original aqui.

FXMessageBox: Opções de botões

2009-05-25T17:07:00.001-03:00

No tópico anterior, apresentei as mensagens que o FOX Toolkit fornece ao usuário através da classe FXMessageBox. Percebam que as mensagens de informação, aviso e erro possuíam apenas o botão OK, enquanto a pergunta possuía dois botões, Sim e Não.

Neste tópico, mostrarei as opções de botões disponíveis para as caixas de mensagem. Novamente, mostrarei apenas os trechos de código e o resultado, pois são bem auto-explicativos.

Os botões que devem aparecer na caixa de mensagem são passados como segundo parâmetro, e são definidos em termos de uma enumeração declarada em FXMessageBox.h:

enum {
  MBOX_OK                   = 0x10000000,
  MBOX_OK_CANCEL            = 0x20000000,
  MBOX_YES_NO               = 0x30000000,
  MBOX_YES_NO_CANCEL        = 0x40000000,
  MBOX_QUIT_CANCEL          = 0x50000000,
  MBOX_QUIT_SAVE_CANCEL     = 0x60000000,
  MBOX_SKIP_SKIPALL_CANCEL  = 0x70000000,
  MBOX_SAVE_CANCEL_DONTSAVE = 0x80000000
};

MBOX_OK

FXMessageBox::information(&app, MBOX_OK, "Informação",
   "Operação finalizada");

MBOX_OK_CANCEL

FXMessageBox::question(&app, MBOX_OK_CANCEL, "Apagar tudo",
   "Essa operação não pode ser desfeita.\nDeseja continuar?");

MBOX_YES_NO

FXMessageBox::question(&app, MBOX_YES_NO, "Sair",
   "Sair do programa?");

MBOX_YES_NO_CANCEL

FXMessageBox::question(&app, MBOX_YES_NO_CANCEL, "Salvar arquivo",
   "O arquivo foi alterado.\nDeseja salvar antes de sair?");

MBOX_QUIT_CANCEL

FXMessageBox::question(&app, MBOX_QUIT_CANCEL, "Processo em execução",
   "Terminar o aplicativo encerrará um processo em andamento."
   "\nDeseja mesmo sair?");

MBOX_QUIT_SAVE_CANCEL

FXMessageBox::question(&app, MBOX_QUIT_SAVE_CANCEL, "Salvar arquivo",
   "O arquivo foi alterado.\nDeseja salvar antes de sair?");

MBOX_SKIP_SKIPALL_CANCEL

FXMessageBox::error(&app, MBOX_SKIP_SKIPALL_CANCEL, "Entrada inválida",
   "Entrada inválida.");

MBOX_SAVE_CANCEL_DONTSAVE

FXMessageBox::question(&app, MBOX_SAVE_CANCEL_DONTSAVE, "Salvar arquivo",
   "O arquivo foi alterado.\nDeseja salvar antes de sair?");

Em inglês?

É... open-source: quem quiser em português, tem que ir no código-fonte, traduzir e recompilar.

No próximo tópico, mostrarei como tratar a opção selecionada pelo usuário.

Até lá.

FXMessageBox: Tipos de mensagem

2009-05-25T11:58:00.006-03:00

Esta será uma série a respeito da classe FXMessageBox. Ela serve para, como o próprio nome diz, exibir uma mensagem ao usuário de forma fácil e rápida.

Já utilizei esta classe em um tutorial passado para exibir uma mensagem de boas-vindas ao FOX Toolkit. Aquele foi apenas um tipo de mensagem dentre quatro disponíveis nesta classe:

informação
pergunta
aviso
erro

Esses quatro tipos de mensagem são fornecidos em forma de funções estáticas de FXMessageBox, ou seja, não é preciso instanciar explicitamente um objeto para exibir uma mensagem ao usuário.

Neste tópico, apenas discutirei os parâmetros de cada função, que são gerais, e mostrarei um exemplo de cada tipo, pois realmente não há muito o que explicar. Vamos lá.

Parâmetros

Cada função estática (information, question, warning, error) recebe pelo menos quatro parâmetros:

FXWindow* owner, FXuint opts, const char* caption, const char* message, ...

Existe também uma outra versão que, em vez de se passar uma janela, passa-se o aplicativo:

FXApp* app, FXuint opts, const char* caption, const char* message, ...

Essa segunda versão é útil, por exemplo, quando se deseja exibir uma mensagem ao usuário antes da janela principal ser criada.

Os parâmetros serão explicados a seguir.

FXWindow *owner / FXApp *app

Janela/aplicativo da mensagem. Nada de muito especial aqui.

FXuint opts

As opções da mensagem. Aqui se informam quais são os botões que aparecerão na mensagem (OK, Cancelar etc.). Para não ficar muito extenso, abordarei essa questão em outro tópico.

const char* caption

Título da janela com a mensagem. Também nada de especial aqui.

const char* message, ...

Texto da mensagem. Aqui, sim, há um detalhe importante.

Percebam as reticências. Isso indica que essa função recebe um número variável de parâmetros. Neste caso, no mínimo os quatro que são explicitamente declarados.

Essa mensagem é formatada pelo FOX de forma muito semelhante à função printf(). Ou seja, se eu quiser exibir uma mensagem que contenha dados da aplicação, não é necessário montá-la manualmente, pois o FOX faz isso automaticamente. Um exemplo (didático...) será mostrado mais à frente.

Exemplos

Nesta seção, mostrarei um exemplo de cada tipo de mensagem. O código-fonte para esse tutorial está disponível no final do tópico.

Serão mostrados apenas o trecho de código usado para exibir a mensagem e uma captura de tela da mensagem.

Obs.: Apenas lembrando, pelo fato de serem funções estáticas, são chamadas diretamente da classe, sem necessidade de instanciar um objeto, através do operador de escopo (::).

Informação

FXMessageBox::information(this, MBOX_OK, "Informação",
  "Operação finalizada");

Pergunta

FXMessageBox::question(this, MBOX_YES_NO, "Sair",
  "Deseja realmente sair do programa?");

Aviso

FXMessageBox::warning(this, MBOX_OK, "Aviso",
  "Valor não especificado.\nAtribuindo padrão 1.");

Erro

FXMessageBox::error(this, MBOX_OK, "Erro",
  "%s: Arquivo não encontrado", filename.text())

Discussão

Em primeiro lugar, percebam que para cada tipo de mensagem há um ícone diferente; é basicamente isso que diferencia um tipo do outro, pois o resto é igual. Essas são o que chamamos de funções de conveniência, pois automatizam tarefas comuns.

Segundo, na mensagem de aviso, eu utilizei uma quebra de linha para evitar que a mensagem fique muito longa. Isso é de controle exclusivo do usuário; o texto da mensagem é exibido através de um FXLabel, que não executa quebra de linha automática.

E terceiro, na mensagem de erro, um exemplo didático da formatação da mensagem a la printf(): a mensagem exibe o conteúdo de uma variável.

Conclusão

Esta foi apenas uma introdução às mensagens que o FOX Toolkit disponibiliza para o usuário. Existem outros aspectos relacionados, que serão discutidos em outros tópicos.

Até lá, e um abraço.

---
Código-fonte deste tutorial.

Layout Managers: Aninhamento

2009-05-14T12:39:00.010-03:00

Todos os gerenciadores de layout do FOX podem ser aninhados, ou seja, podem ser filhos de outros gerenciadores de layout. Essa, na verdade, é uma característica obrigatória em qualquer biblioteca de interface gráfica, pois é isso que permite compor a aparência dos programas. Sem essa capacidade, ficaria quase impossível criar uma interface sofisticada (pense em posicionar cada elemento manualmente, ajustar as bordas de cada seção e outras tarefas tediosas).

Neste tópico, apresentarei um exemplo bem simples (e didático...) desse aninhamento. Farei uma janela semelhante a uma que eu criei para a minha monografia. À esquerda da janela principal, quatro imagens; à direita, uma janela para a exibição 3D. Assim:

Vou logo avisando que vai ficar bem diferente dessa de cima. No final eu explico por que. O objetivo desse tópico é basicamente mostrar o aninhamento dos gerenciadores de layout, utilizando a bagagem que foi adquirida até aqui.

Comecemos, então.

Codificação

O primeiro elemento da janela é uma barra de menu. Aqui tudo será simulado, então utilizarei um HorizontalFrame para a barra:

23   FXHorizontalFrame *menuBar = new FXHorizontalFrame(this,
24       LAYOUT_SIDE_TOP|LAYOUT_FILL_X|PACK_UNIFORM_WIDTH);

Os "menus" são simplesmente labels:

26   /* Menu Arquivo */
27   new FXLabel(menuBar, "&Arquivo");
28
29   /* Menu Imagens */
30   new FXLabel(menuBar, "&Imagens");

Agora vêm os aninhamentos. Na verdade, desde a primeira vez que colocamos um gerenciador de layout, fizemos um aninhamento, já que a própria janela já é um gerenciador de layout, mas aqui isso fica mais explícito.

Primeiramente, um frame horizontal representando o conteúdo da janela:

32   FXHorizontalFrame *contents = new FXHorizontalFrame(this,
      LAYOUT_SIDE_TOP|LAYOUT_FILL|FRAME_NORMAL);

Eu gosto de definir os filhos imediatamente, formando realmente uma árvore no código (inclusive com indentação); acho que fica mais fácil saber quem é filho de quem, em vez de definir todos os filhos e depois os filhos dos filhos.

Sendo assim, o primeiro filho de contents é um frame vertical:

33     FXVerticalFrame *frameExam = new FXVerticalFrame(contents,
        LAYOUT_FILL|FRAME_NORMAL);

Dentro dele, tem dois frames horizontais (que ficarão um sobre o outro); dentro de cada um deles, tem dois objetos do tipo FXFrame (que pode ser considerado um espaço vazio), que ficarão um do lado do outro:

34       FXHorizontalFrame *ccFrame = new FXHorizontalFrame(frameExam,
          LAYOUT_FILL|FRAME_NORMAL);
35         new FXFrame(ccFrame, LAYOUT_FILL|FRAME_NORMAL);
36         new FXFrame(ccFrame, LAYOUT_FILL|FRAME_NORMAL);
37
38       FXHorizontalFrame *mloFrame = new FXHorizontalFrame(frameExam,
          LAYOUT_FILL|FRAME_NORMAL);
39         new FXFrame(mloFrame, LAYOUT_FILL|FRAME_NORMAL);
40         new FXFrame(mloFrame, LAYOUT_FILL|FRAME_NORMAL);

O segundo filho de contents também é um FXFrame, apenas para ocupar o espaço:

42       new FXFrame(contents, LAYOUT_FILL|FRAME_NORMAL);

Resultado

Repetindo, o resultado é totalmente diferente do que foi mostrado acima. Com essa codificação, o que se obtém é isso:

Eu mandei a borda ser desenhada "afundada" justamente para que o aninhamento seja mais visível.

Discussão

O resultado ficou bem diferente do modelo por alguns motivos básicos.

Primeiramente, no modelo eu não utilizei somente FX(Horizontal|Vertical)Frame (não resisti à regex). Existem gerenciadores de layout bem mais propícios para uma interface como aquela.

Segundo, não alterei valores de espaçamento; por isso, dá para ver que as bordas ficam bem distantes umas das outras.

Terceiro, de contents para baixo, todos estão com a opção LAYOUT_FILL. Isso faz que o tamanho final de cada filho seja proporcional ao seu tamanho padrão em relação a seus irmãos. Como do lado esquerdo tem mais filhos, este ficou bem maior que o direito.

E quarto, para o modelo, eu defino explicitamente a largura dos contêineres das imagens (as áreas escuras) de acordo com as imagens carregadas. Tanto que, ao iniciar o programa, eles estão com a largura padrão, que é 1. Vejam:

Conclusão

Este tópico mostrou como é feito o aninhamento de gerenciadores de layout no FOX Toolkit. Espero ter ficado bem claro, pois é algo extremamente útil.

Utilizei nele poucos recursos porque achei melhor me limitar ao que já foi tratado até aqui. Entretanto, tudo o que foi dito aqui vale para qualquer outro gerenciador de layout. O FOX vem inclusive com um exemplo que diz "É claro que eles podem ser aninhados arbitrariamente." Creio que essa frase mostra bem o espírito da coisa.

Só uma observação final: FXFrame, ao contrário do que possa parecer, NÃO é um gerenciador de layout. Muito menos superclasse de FX(Horizontal|Vertical)Frame (como sugere o sufixo). É ele que desenha as bordas dos controles (grossa, fina, levantada, abaixada etc.).

FXFrame pode ser utilizado apenas como um "guarda-lugar" (placeholder), como foi feito aqui. Entretanto, é mais utilizado como classe-base para controles simples; por exemplo, FXLabel é derivado direto de FXFrame (e FXButton é derivado direto de FXLabel).

Um abraço e até a próxima.

---
Código-fonte para este tutorial.

Layout Managers: FXVerticalFrame

2009-05-11T14:35:00.000-03:00

Neste tópico, falarei a respeito do gerenciador de layout FXVerticalFrame. A princípio, eu achei que seria demais um tópico só para ele, por ser bastante semelhante ao FXHorizontalFrame. Pensei então em apenas tratá-lo rapidamente dentro deste tópico. Mas percebi que eram temas muito diferentes, e apenas iria deixar o tópico mais extenso.

Resolvi, então, tratá-lo em um tópico exclusivo. Aproveito, ainda, para falar de mais algumas opções de layout.

Vamos lá, então.

Exemplo

Como eu utilizei esse gerenciador em um tópico anterior, vou reaproveitá-lo aqui. São apenas dois botões.

Primeiramente, é preciso criar o gerenciador:

23   FXVerticalFrame *contents =
24     new FXVerticalFrame(this, LAYOUT_FILL|FRAME_NORMAL);

Aqui, eu crio um FXVerticalFrame que se expandirá por toda a janela em ambas as direções (LAYOUT_FILL). FRAME_NORMAL significa que ele terá uma borda grossa e rebaixada. As opções de borda serão discutidas em detalhes futuramente.

Agora eu crio os botões:

26   new FXButton(contents, "&Hello FOX!", NULL, this, ID_HELLO,
27       BUTTON_NORMAL|LAYOUT_FILL_X);
28
29   new FXButton(contents, "&Goodbye, FOX!", NULL, a, FXApp::ID_QUIT,
30       BUTTON_NORMAL|LAYOUT_FILL_X|LAYOUT_BOTTOM);

O primeiro botão será posicionado junto à borda superior (por padrão), e se expandirá pelo eixo horizontal.

Já o segundo tem apenas uma diferença em relação ao primeiro (em opções de layout): ele será colocado junto à borda inferior (LAYOUT_BOTTOM).

Resultado

Neste tópico, há um vídeo mostrando o resultado do tratamento dos eventos.

No vídeo, a janela está com o tamanho mínimo, ou seja, os dois botões aparecem juntos um do outro. Agora vejam o que acontece quando se redimensiona a janela:

Conclusão

Conforme eu falei no início deste tópico, o FXVerticalFrame é bastante semelhante ao FXHorizontalFrame. Desta forma, tudo o que foi discutido no no outro tópico vale aqui também.

Sendo assim, deixo para a curiosidade do leitor fazer testes incluindo novos botões e utilizando as opções de layout e empacotamento já discutidos.

Um abraço e até a próxima.

Tratamento de Eventos: Convenções de nomenclatura

2009-05-11T13:05:00.002-03:00

No tópico anterior, mostrei como capturar um evento e utilizar um tratador definido pelo usuário.

Neste tópico falarei sobre as convenções de nomenclatura do callbacks.

São três convenções que ajudam na identificação imediata dos callbacks, bem como de sua funcionalidade:

Sempre começam com on.
Em seguida, vem um identificador do tipo de mensagem. Este será discutido mais adiante.
Por último, um nome descritivo opcional. Caso exista, deve deixar claro que ação ele executará.

O identificador do tipo de mensagem deve condizer, claro, com o tipo de mensagem que irá tratar. Existem três tipos que são normalmente abreviados:

SEL_COMMAND: abreviado para onCmd...
SEL_UPDATE: abreviado para onUpd...
SEL_CHANGED: abreviado para onChg...

O terceiro é bem raro no FOX, só encontrei seis ocorrências de callbacks desse tipo (não que isso signifique que o usuário não possa definir seus próprios).

Normalmente, para esses três tipos de mensagem é necessário informar um nome extra, já que por si sós não são descritivos o suficientes (terceiro item das convenções).

Para os demais tipos de mensagem, normalmente utiliza-se o nome completo. Exemplos:

SEL_LEFTBUTTONPRESS: onLeftButtonPress
SEL_PAINT: onPaint
SEL_KEYPRESS: onKeyPress

Esses já dizem claramente o que vão tratar, por isso normalmente recebem o nome completo. E, ao contrário daqueles três, normalmente não é necessário mais de um tratador por janela, ou seja, não precisam de um nome extra para diferenciá-los.

Voltando, então, ao exemplo do tópico anterior, nós temos uma mensagem chamada ID_HELLO. Este é um evento disparado por um botão, ou seja, do tipo SEL_COMMAND. Um nome bastante adequado para o callback que trata essa mensagem, portanto, é onCmdHello.

Com isso, eu já sei que onCmdHello é o callback (on) que vai tratar um comando (Cmd), referente à mensagem ID_HELLO (Hello).

Conclusão

Este tópico foi apenas para chamar atenção a esse pequeno detalhe, mas que eu considero bastante importante, afinal, é importante ter boa legibilidade no código.

Posteriormente, falarei mais especificamente sobre o mapa de mensagens e os tipos de mensagem fornecidos pelo FOX Toolkit.

Um abraço e até lá.

Tratamento de Eventos: Enviando e tratando

2009-05-07T17:23:00.000-03:00

No primeiro tópico sobre tratamento de eventos (aqui), eu criei um botão que apenas fechava o aplicativo, ou seja, o botão enviava uma mensagem pré-definida.

Neste tópico, mostrarei como definir suas próprias mensagens a serem enviadas, assim como tratar os eventos a elas relacionados.

Pois bem, ponhamos a mão na massa.

Declaração das mensagens

O primeiro passo é declarar as mensagens que serão enviadas. Isto é feito na declaração da classe através de uma enumeração, que deve estar na interface pública. Assim:

30 public:
31   enum {
32     ID_HELLO = FXMainWindow::ID_LAST,
33
34     ID_LAST,
35   };

Aqui, estou chamando minha mensagem de ID_HELLO, seguindo a convenção de prefixar as mensagens com ID_. É importante também que o nome seja bem descritivo.

Em se tratando de uma enumeração, por padrão os itens são numerados seqüencialmente começando em 0. Porém essa é uma característica indesejável nesse caso, pois isso proporcionaria conflito de mensagens. Para garantir que cada mensagem tenha um valor diferente, todos os widgets FOX declaram a "mensagem" ID_LAST, cujo único propósito é garantir a seqüência de mensagens e evitar colisão. Então, deve-se atribuir à primeira mensagem o valor da última mensagem da superclasse direta, neste caso FXMainWindow.

Eu costumo definir também a minha própria ID_LAST, apesar de nunca ter derivado uma classe minha. Se for garantido que sua classe não será derivada, não é necessário.

Declaração dos callbacks

Além das mensagens, é preciso definir as funções que irão tratar as mensagens. Quando se trata de interação com o usuário, essas funções são chamadas callbacks, exatamente porque elas não têm um momento certo para serem chamadas, mas são executadas em resposta às ações do usuário. Em outro tópico discutirei um tema relevante com relação a essa questão dos callbacks.

Eles devem estar na interface pública da classe. Como C++ permite definir o escopo dos componentes da classe diversas vezes, eu gosto de "agrupar" a declaração das mensagens e dos callbacks em uma "seção pública" separada, conforme pode-se observar no código.

No FOX, todos os callbacks têm um protótipo igual:

long callback(FXObject*, FXSelector, void*);

ou seja, sempre retornam um long e recebem três parâmetros: FXObject*, FXSelector, void*.

Além disso, existe uma convenção de nomenclatura, que será tratada em outro tópico.

Neste exemplo, definimos o seguinte callback:

37   long onCmdHello(FXObject*, FXSelector, void*);

Aqui terminamos as declarações necessárias. Agora partimos para a implementação.

Mapa de mensagens

O mapa de mensagens é definido com auxílio da macro FXDEFMAP, já apresentada aqui. Porém, estava vazio, pois a janela não tratava nenhum evento. Agora vamos colocar um mapeamento nele.

Cada mapeamento é definido pela macro FXMAPFUNC, recebe três parâmetros: tipo da mensagem, ID da mensagem e um ponteiro para o callback. No nosso exemplo, temos:

13   FXMAPFUNC(SEL_COMMAND,
      FoxTutorialMainWindow::ID_HELLO,
      FoxTutorialMainWindow::onCmdHello),

Obs.: Por limitações de espaço, quebrei a linha em três, mas normalmente deixo a declaração inteira em uma linha só.

Isso quer dizer que sempre que a nossa janela receber uma mensagem do tipo SEL_COMMAND (um botão clicado, um menu selecionado etc.), associado à mensagem ID_HELLO, ela deve executar o callback onCmdHello.

A linha contendo a chamada à macro FXIMPLEMENT permanece intacta, pois a macro auxiliar ARRAYNUMBER garante a atualização automática do tamanho do mapa de mensagens.

Conectando os objetos

Em seguida, eu preciso dizer quem vai enviar essa mensagem. Para isso, eu criei um botão:

26   new FXButton(contents, "&Hello FOX!", NULL, this, ID_HELLO,
27       BUTTON_NORMAL|LAYOUT_FILL_X);

Quando o usuário clica no botão, ele lança um evento do tipo SEL_COMMAND, associado à sua mensagem, que neste caso é ID_HELLO. Esse evento é enviado para o alvo do botão, que neste caso é a própria janela (this).

Em seguida, o alvo (nossa janela) consulta seu mapa de mensagens e descobre que um evento SEL_COMMAND, associado à mensagem ID_HELLO, resulta em uma chamada a onCmdHello.

Implementando o callback

Naturalmente, o callback deve ser implementado. Neste exemplo, será exibida uma mensagem de saudação:

48 long FoxTutorialMainWindow::onCmdHello(FXObject*, FXSelector, void*) {
49   FXMessageBox::information(this, MBOX_OK, "Olá", "Olá, FOX Toolkit");
50
51   return 1;
52 }

Note o valor de retorno: 1. Callbacks, no FOX Toolkit, retornam basicamente 1 para informar que o evento foi tratado, ou 0, indicando que não foi tratado.

Essa convenção é utilizada para, por exemplo, tratar a atualização da interface, especialmente em eventos do mouse: se o evento foi tratado, agenda uma atualização da interface; senão, nada mais acontece.

Na prática, o valor de retorno é quase sempre 1 (pelo menos, eu nunca retornei 0, mas já andei fuçando os fontes e isso acontece, portanto é bom saber).

Com isso, temos um botão que, ao ser clicado, exibe uma mensagem ao usuário.

Resultado

Confira no vídeo a seguir como ficou a nossa janela:

---
Código-fonte para este tutorial.
Baixar vídeo.

Botões: Texto e ícone

2009-05-05T16:35:00.002-03:00

Neste tópico, falarei sobre adicionar um ícone ao botão, e mostrarei as posições relativas entre ícone e texto.

Carregando o ícone

Para carregar o ícone, basta proceder conforme explicado aqui.

Na declaração da classe:

30   FXIcon *searchIcon;

Em loadIcons():

82   searchIcon = iconSource.loadScaledIconFile("icons/search.gif", 32);

Lembrando que o ícone deve ser destruído manualmente, em destroyIcons():

89   delete searchIcon;

Com isso, basta passar o ícone como terceiro argumento do construtor do botão:

new FXButton(p, "text", searchIcon, ...

Posições relativas entre ícone e texto

A relação de posição entre ícone e menu é definida em FXLabel.h. FXButton é derivado direto de FXLabel. Isso significa que todas as opções deste valem para aquele também. Significa também que toda a discussão a seguir é válida para quando adicionarmos legendas (labels) na nossa interface.

Existem cinco maneiras de posicionar um ícone em relação ao texto, e cada uma delas possui dois sinônimos. As opções são:

enum {
 ICON_UNDER_TEXT      = 0,
 ICON_AFTER_TEXT      = 0x00080000,
 ICON_BEFORE_TEXT     = 0x00100000,
 ICON_ABOVE_TEXT      = 0x00200000,
 ICON_BELOW_TEXT      = 0x00400000,
 TEXT_OVER_ICON       = ICON_UNDER_TEXT,
 TEXT_AFTER_ICON      = ICON_BEFORE_TEXT,
 TEXT_BEFORE_ICON     = ICON_AFTER_TEXT,
 TEXT_ABOVE_ICON      = ICON_BELOW_TEXT,
 TEXT_BELOW_ICON      = ICON_ABOVE_TEXT
};

Obs.: existem também opções de posicionamento de texto e ícone em relação ao widget, usando opções de justificação, mas isso fica para outro tópico.

ICON_UNDER_TEXT
TEXT_OVER_ICON

Seu valor é 0, o que indica que esta é a opção "padrão". No fim deste tópico, falarei a respeito dessa questão.

Esta opção faz com que o ícone apareça por trás do texto. Exemplo:

25   new FXButton(matrix, "ICON_UNDER_TEXT", searchIcon, NULL, 0,
26       FRAME_RAISED|FRAME_THICK|ICON_UNDER_TEXT);
27
28   new FXButton(matrix, "TEXT_OVER_ICON", searchIcon, NULL, 0,
29       FRAME_RAISED|FRAME_THICK|TEXT_OVER_ICON);

ICON_AFTER_TEXT
TEXT_BEFORE_ICON

Desenha o ícone à direita do texto. Exemplo:

32   new FXButton(matrix, "ICON_AFTER_TEXT", searchIcon, NULL, 0,
33       FRAME_RAISED|FRAME_THICK|ICON_AFTER_TEXT);
34
35   new FXButton(matrix, "TEXT_BEFORE_ICON", searchIcon, NULL, 0,
36       FRAME_RAISED|FRAME_THICK|TEXT_BEFORE_ICON);

ICON_BEFORE_TEXT
TEXT_AFTER_ICON

Desenha o ícone à esquerda do texto. Exemplo:

39   new FXButton(matrix, "ICON_BEFORE_TEXT", searchIcon, NULL, 0,
40       FRAME_RAISED|FRAME_THICK|ICON_BEFORE_TEXT);
41
42   new FXButton(matrix, "TEXT_AFTER_ICON", searchIcon, NULL, 0,
43       FRAME_RAISED|FRAME_THICK|TEXT_AFTER_ICON);

ICON_ABOVE_TEXT
TEXT_BELOW_ICON

Desenha o ícone acima do texto. Exemplo:

46   new FXButton(matrix, "ICON_ABOVE_TEXT", searchIcon, NULL, 0,
47       FRAME_RAISED|FRAME_THICK|ICON_ABOVE_TEXT);
48
49   new FXButton(matrix, "TEXT_BELOW_ICON", searchIcon, NULL, 0,
50       FRAME_RAISED|FRAME_THICK|TEXT_BELOW_ICON);

ICON_BELOW_TEXT
TEXT_ABOVE_ICON

Desenha o ícone sob o texto. Exemplo:

53   new FXButton(matrix, "ICON_BELOW_TEXT", searchIcon, NULL, 0,
54       FRAME_RAISED|FRAME_THICK|ICON_BELOW_TEXT);
55
56   new FXButton(matrix, "TEXT_ABOVE_ICON", searchIcon, NULL, 0,
57       FRAME_RAISED|FRAME_THICK|TEXT_ABOVE_ICON);

Voltando à questão do valor "padrão"

ICON_UNDER_TEXT tem valor 0, o que o torna, teoricamente, a opção padrão.

Para entender essa questão, note que as demais opções podem ser divididas entre posicionamento vertical (ICON_ABOVE_TEXT e ICON_BELOW_TEXT) e posicionamento horizontal (ICON_BEFORE_TEXT e ICON_AFTER_TEXT).

Isso significa que eu posso combinar opções de posicionameto horizontal e vertical. Porém, se eu não especificar um ou outro, a opção padrão será utilizada. Neste caso, é melhor entender a opção padrão não como o nome diz (ícone debaixo (atrás?) do texto), mas que o ícone ficará centralizado naquele eixo que não foi especificado.

Voltando aos exemplos, perceba que ICON_AFTER_TEXT e ICON_BEFORE_TEXT deixam o ícone centralizado na vertical. Da mesma forma, ICON_ABOVE_TEXT e ICON_BELOW_TEXT deixam o ícone centralizado na horizontal. Ainda, a opção ICON_UNDER_TEXT deixa o ícone centralizado em ambos os eixos.

Então por que "padrão", entre aspas? Tem algum detalhe?

Sim. Este padrão é considerado neste caso, em que se omite o posicionamento em um dos eixos. Acontece que muitos widgets FOX têm uma opção com o sufixo _NORMAL, que reúnem as opções mais comuns, e são passadas como argumento padrão para o construtor.

Assim, para o FXButton, temos BUTTON_NORMAL, definido junto com outras opções:

BUTTON_NORMAL    = (FRAME_RAISED|FRAME_THICK |
               JUSTIFY_NORMAL|ICON_BEFORE_TEXT)

Na declaração do construtor:

FXButton(FXComposite* p, ..., FXuint opts=BUTTON_NORMAL, ...

Ou seja, para um botão, o padrão é exibir o ícone à esquerda do texto. Como não foi especificado o posicionamento na vertical, fica centralizado.

Espero que essa diferença tenha ficado clara. A distinção está na questão de existir uma opção padrão (que leva o valor 0 exatamente para que não seja necessário informá-la explicitamente) e existir um argumento padrão para o construtor de um widget, que reúne as opções mais comuns, que não necessariamente são as opções padrões.

E como fica se eu combinar posicionamento vertical e horizontal?

Veja:

Deixo como exercício.

Até a próxima.

---
Código-fonte para este tutorial.

Layout Managers: FXHorizontalFrame

2009-05-04T13:30:00.001-03:00

Neste tópico, falarei sobre o gerenciador de layout FXHorizontalFrame. Aproveito também para mostrar algumas dicas de layout.

Descrição

O gerenciador de layout HorizontalFrame é utilizado para posicionar automaticamente as janelas filhas horizontalmente, da esquerda para a direita, ou da direita para a esquerda, dependendo das dicas de layout da janela.

Obs.: "janela" aqui refere-se a qualquer derivado de FXWindow.

Exemplo

Neste exemplo, temos um HorizontalFrame e dentro dele seis botões:

22   FXHorizontalFrame *frame = new FXHorizontalFrame(this,
23     LAYOUT_FILL_X|PACK_UNIFORM_WIDTH|PACK_UNIFORM_HEIGHT|FRAME_RAISED);

Aqui, é criado o frame. Ele se expandirá por todo o eixo X da janela (LAYOUT_FILL_X) e todos os seus filhos terão a mesma dimensão (PACK_UNIFORM_WIDTH | PACK_UNIFORM_HEIGHT). Também possui uma borda "levantada", que eu coloquei aqui apenas para destacar.

Em seguida, são criados os botões:

25   new FXButton(frame, "Botão 1");
26   new FXButton(frame, "Botão 2");
27   new FXButton(frame, "Botão com texto grande");
28   new FXButton(frame, "Botão em\nduas linhas");
29
30   new FXButton(frame, "Centro", NULL, NULL, 0,
31       BUTTON_NORMAL|LAYOUT_CENTER_X);
32
33   new FXButton(frame, "Botão à direita", NULL, NULL, 0,
34       BUTTON_NORMAL|LAYOUT_RIGHT);

Os dois primeiros não têm nada de peculiar. O terceiro possui o texto mais longo de todos e o quarto tem o texto quebrado em duas linhas. Isso vai influir no layout dos botões, conforme veremos mais adiante.

O quinto botão é posicionado no centro (LAYOUT_CENTER_X). Isso não fará que ele fique no centro da janela, mas no centro da área restante. O BUTTON_NORMAL serve para preservar as características originais de borda e texto do botão. O sexto botão fica alinhado à direita (LAYOUT_RIGHT).

Não há muito o que discutir além disso, só mostrar o resultado.

Resultado

Percebe-se que os botões estão todos juntos. Isso se deve ao fato de eu não ter especificado nenhum tamanho para a janela principal (na verdade, não especifiquei tamanho de ninguém...). Assim, ela assume o tamanho mínimo para que caibam todos os seus filhos. E assim cada filho dela também o fez.

Por isso o "Botão com texto grande" ficou mais longo e o "Botão em duas linhas" ficou com altura maior. Como o frame foi instruído a deixar todo mundo nas mesmas dimensões, todo mundo recebeu a largura do terceiro botão e a altura do quarto.

Aliás, esse é o principal motivo pelo qual eu não especifiquei um tamanho para a janela principal, como vinha fazendo nos tutoriais anteriores (nos quais eu criava uma janela 200x200). Especificar um tamanho corre o risco de não caber todo mundo, ou de ficar grande demais. Na verdade, é bem difícil acertar. É muito melhor deixar o próprio FOX tratar esses detalhes.

E quanto ao posicionamento dos dois últimos botões? Um centralizado e o outro à direita?

Pois bem, esse é o tamanho mínimo, que coube todo mundo, então fica todo mundo juntinho. Se eu aumentar a janela, eles assumem a posição correspondente:

Desta vez fica claro: o botão "Centro" ficou no meio do espaço disponível, e o "Botão à direita" ficou no canto onde realmente deveria estar.

Conclusão

Este tópico mostrou um dos gerenciadores de layout mais simples que o FOX Toolkit fornece. Mostrou também como agem algumas dicas de layout, bem como as dicas de empacotamento discutidas aqui e aqui.

Com o tempo, ficará bem mais claro o poder que os gerenciadores de layout oferecem.

Só como presente de despedida desse tópico, uma pergunta que não quer calar:

Se eu não definisse aquelas opções de empacotamento?

Apenas veja:

Eu poderia ainda instruir os botões a ficarem centralizados no eixo Y (LAYOUT_CENTER_Y), mas isso não ajudaria muito em termos estéticos. Vou deixar isso a cargo da curiosidade do leitor.

---
Código-fonte para este tutorial.

Layout Managers: Packing Styles

2009-04-30T19:04:00.003-03:00

Neste tópico aqui, falei das dicas de layout (layout hints). Essas dicas são passadas para quem vai ficar dentro do gerenciador de layout. Por exemplo, quando eu pus um botão na janela (veja aqui), eu passei LAYOUT_FILL em suas opções, para que ocupasse a janela inteira.

Existem ainda outras opções que definem o layout, mas que devem ser passadas para o próprio gerenciador de layout. Essas opções determinam a forma de empacotamento dos filhos, e também são definidas em FXWindow.h. São elas:

enum {
  PACK_NORMAL         = 0,
  PACK_UNIFORM_HEIGHT = 0x00008000,
  PACK_UNIFORM_WIDTH  = 0x00010000
};

PACK_NORMAL

Opção padrão: cada widget com seu tamanho. Nem precisa passar se for o caso (novamente, a não ser que você quiser maior clareza no código...).

PACK_UNIFORM_HEIGHT

Primeiramente, o gerenciador calcula o filho com maior altura. Depois, utiliza esse valor para todos os outros filhos, deixando todo mundo com a mesma altura.

PACK_UNIFORM_WIDTH

Da mesma forma, deixa todos os filhos com a mesma largura.

Essas duas últimas opções sobrepõem opções individuais dos filhos, como LAYOUT_FIX_WIDTH.

À medida que avançarmos em nossos tutoriais sobre gerenciadores de layout, mostrarei essas opções funcionando.

Tratamento de Eventos: Introdução

2009-04-28T13:46:00.005-03:00

Neste tutorial, coloquei um botão simples na janela. Esse botão não possuía ação nenhuma. Inútil.

Agora, vou adicionar um evento a este botão: fechar o aplicativo (embora o texto do botão seja "Hello FOX"...).

Para isso, basta informar quem é o alvo do evento e qual a mensagem:

22   new FXButton(this, "Hello, &FOX!", NULL, getApp(), FXApp::ID_QUIT,
23       BUTTON_NORMAL|LAYOUT_FILL);

Neste caso, o alvo do meu evento é o próprio aplicativo, que pode ser recuperado chamando getApp(), presente em todas as classes derivadas de FXId (na prática, quase todas as classes FOX são; veja aqui a hierarquia de FXId).

A bem da verdade, nem seria necessário chamar esse método, já que estamos no construtor da janela, cujo primeiro parâmetro é a aplicação; bastava eu passar o ponteiro. Utilizei essa chamada aqui apenas para ilustrar.

O próximo parâmetro é o identificador da mensagem. Por convenção, sempre começa com ID_. Aqui eu passei ID_QUIT, que pertence à classe FXApp.

É só isso. Assim, eu conectei o botão à aplicação. Quando o botão envia um evento, a aplicação responde. Basicamente, é assim que os objetos se comunicam no FOX Toolkit.

Mas o que acontece lá dentro?

Bom, existem alguns detalhes a respeito disso. Com este exemplo, só posso dizer que o botão envia para a aplicação uma mensagem do tipo ID_QUIT, e a aplicação responde com a ação correspondente, ou seja, terminar a aplicação.

Futuramente, entrarei em detalhes e explicarei como funciona o mecanismo de comunicação entre os objetos FOX.

Só um detalhe, para o qual eu apanhei no começo e levei um certo tempo para descobrir o que era: eu criei um botão para fechar o aplicativo, mas em vez de passar o aplicativo, eu passei a janela. Resultado: a janela fechava, mas o aplicativo continuava executando... aí eu tinha que matar o processo.

Layout Managers: Layout Hints

2009-04-27T15:30:00.002-03:00

As Layout Hints são opções passadas pelos widgets para os gerenciadores de layout que os contêm para informar algo a respeito de sua posição e tamanho. Assim como as opções de decoração (aqui), essas são apenas dicas; entretanto, os gerenciadores de layout farão o possível para atender aos pedidos.

A falta de algumas dicas quer dizer que o comportamento padrão deve ser utilizado, portanto muitas vezes não é preciso informá-las: as dicas do FOX Toolkit foram projetadas para que as situações mais comuns requeiram menos dicas. Por exemplo, normalmente os gerenciadores organizam seus filhos da esquerda para a direita, de cima para baixo, ou seja, não é preciso informar essas opções se esse for o caso.

Essas dicas estão definidas em FXWindow.h:

enum {
LAYOUT_NORMAL      = 0,
LAYOUT_SIDE_TOP    = 0,
LAYOUT_SIDE_BOTTOM = 0x00000001,
LAYOUT_SIDE_LEFT   = 0x00000002,
LAYOUT_SIDE_RIGHT  = LAYOUT_SIDE_LEFT|LAYOUT_SIDE_BOTTOM,
LAYOUT_FILL_COLUMN = 0x00000001,
LAYOUT_FILL_ROW    = 0x00000002,
LAYOUT_LEFT        = 0,
LAYOUT_RIGHT       = 0x00000004,
LAYOUT_CENTER_X    = 0x00000008,
LAYOUT_FIX_X       = LAYOUT_RIGHT|LAYOUT_CENTER_X,
LAYOUT_TOP         = 0,
LAYOUT_BOTTOM      = 0x00000010,
LAYOUT_CENTER_Y    = 0x00000020,
LAYOUT_FIX_Y       = LAYOUT_BOTTOM|LAYOUT_CENTER_Y,
LAYOUT_DOCK_SAME   = 0,
LAYOUT_DOCK_NEXT   = 0x00000040,
LAYOUT_RESERVED_1  = 0x00000080,
LAYOUT_FIX_WIDTH   = 0x00000100,
LAYOUT_FIX_HEIGHT  = 0x00000200,
LAYOUT_MIN_WIDTH   = 0,
LAYOUT_MIN_HEIGHT  = 0,
LAYOUT_FILL_X      = 0x00000400,
LAYOUT_FILL_Y      = 0x00000800,
LAYOUT_FILL        = LAYOUT_FILL_X|LAYOUT_FILL_Y,
LAYOUT_EXPLICIT    = LAYOUT_FIX_X|LAYOUT_FIX_Y |
                 LAYOUT_FIX_WIDTH|LAYOUT_FIX_HEIGHT
};

Percebam que as opções default têm valor 0.

A seguir, a explicação de cada opção. A menos quando informado o contrário, essas opções valem para todos os gerenciadores de layout.

LAYOUT_NORMAL

Modo de layout default.

LAYOUT_SIDE_TOP (default)
LAYOUT_SIDE_BOTTOM
LAYOUT_SIDE_LEFT
LAYOUT_SIDE_RIGHT

Utilizados somente quando o gerenciador de layout for do tipo FXPacker, FXGroupBox ou FXTopWindow. Posiciona o widget junto à borda superior, inferior, esquerda ou direita, respectivamente.

LAYOUT_SIDE_TOP e LAYOUT_SIDE_BOTTOM reduzem a altura do espaço disponível, enquanto LAYOUT_SIDE_LEFT e LAYOUT_SIDE_RIGHT reduzem a largura.

Essas opções não têm efeito nenhum se utilizadas em outros gerenciadores de layout.

LAYOUT_FILL_COLUMN
LAYOUT_FILL_ROW

Utilizados somente dentro de um FXMatrix.

Se todos os widgets de uma mesma coluna especificarem LAYOUT_FILL_COLUMN, então a coluna inteira é redimensionada se a matriz for redimensionada horizontalmente.

Da mesma forma, se todos o widgets de uma mesma linha especificarem LAYOUT_FILL_ROW, então a linha inteira é redimensionada se a matriz for redimensionada verticalmente.

LAYOUT_LEFT (default)
LAYOUT_RIGHT

Posiciona o widget no lado esquerdo ou direito do seu contêiner, respectivamente. Quando utilizado em um FXPacker, FXGroupBox ou FXTopWindow, só fazem sentido se em conjunto com LAYOUT_SIDE_TOP ou LAYOUT_SIDE_BOTTOM.

LAYOUT_TOP (default)
LAYOUT_BOTTOM

Posiciona o widget na parte de cima ou de baixo do seu contêiner, respectivamente. Quanto utilizado em um FXPacker, FXGroupBox ou FXTopWindow, só fazem sentido se em conjunto com LAYOUT_SIDE_RIGHT ou LAYOUT_SIDE_BOTTOM.

LAYOUT_FIX_X
LAYOUT_FIX_Y

Podem ser usados nenhum, um deles ou ambos. Instruem o gerenciador a posicionar o widget exatamente na posição informada pelo construtor do objeto. (Veja este tópico)

LAYOUT_FIX_WIDTH
LAYOUT_FIX_HEIGHT

Instruem o gerenciador a exibir o widget no tamanho especificado no construtor. (Veja este tópico)

LAYOUT_MIN_WIDTH (default)
LAYOUT_MIN_HEIGHT (default)

Estes não precisam ser especificados nunca (a não ser para enfatizar o fato durante a leitura do código), pois este é o comportamento padrão. Faz com que o gerenciador exiba o widget com seu tamanho mínimo.

LAYOUT_CENTER_X
LAYOUT_CENTER_Y

Centraliza o widget no gerenciador na direção especificada, adicionando espaço extra ao redor dele. O tamanho do widget será o padrão (o tamanho mínimo), a menos que seja informado explicitamente.

LAYOUT_FILL_X
LAYOUT_FILL_Y

Faz com que o widget ocupe todo o espaço disponível no contêiner na direção especificada. Se um ou mais widgets forem posicionados no mesmo gerenciador com essas opções, o espaço é dividido proporcionalmente aos seus tamanhos mínimos.

Obs.: Essa regrinha acima não funciona para dois gerenciadores de layout lado-a-lado.

LAYOUT_DOCK_SAME
LAYOUT_DOCK_NEXT
LAYOUT_RESERVED_1

Confesso que não sei para que servem, e a documentação não fala nada a respeito.

LAYOUT_FILL

Apenas uma combinação de LAYOUT_FILL_X e LAYOUT_FILL_Y para conveniência.

LAYOUT_EXPLICIT

Outra opção de conveniência: combinação de LAYOUT_FIX_X, LAYOUT_FIX_Y, LAYOUT_FIX_WIDTH e LAYOUT_FIX_HEIGHT, ou seja, te dá controle total sobre a posição e o tamanho do widget.

Widgets

2009-04-24T16:35:00.004-03:00

Este tópico discute um pequeno detalhe a respeito do construtor dos widgets FOX. Serve para mostrar um dos pontos fortes do FOX Toolkit, a consistência, e também alguns aspectos que serão mostrados aqui servirão para tópicos futuros.

Bom, os widgets FOX têm um construtor similar:

FXWidget(FXComposite *p,
   ...
   FXObject* tgt,
   FXSelector sel,
   FXuint opts,
   FXint x, FXint y,
   FXint w, FXint h,
   FXint pl, FXint pr,
   FXint pt, FXint pb
   FXint hs, FXint vs
);

Alguns dele já foram explicados em tópicos anteriores, mas vou falar de todos aqui.

FXComposite *p

O componente que será o pai do widget criado. Serve para montar a hierarquia dos objetos FOX sem a necessidade guardar em um ponteiro e chamar algo do tipo p->add() (sem querer falar mal de outras linguagens...).

Normalmente é um gerenciador de layout.

Parâmetros específicos

Depois do dono do widget, vêm alguns parâmetros específicos. Por exemplo, para um botão (FXButton) esses parâmetros são o texto do botão e o ícone.

Naturalmente, nem todos os widgets terão parâmetros específicos, e a quantidade varia de widget para widget. Mas eles sempre vêm depois do dono e antes do alvo dos eventos (exceto para gerenciadores de layout).

FXObject *tgt

FXObject é o topo da hierarquia de classes do FOX Toolkit. Esse parâmetro indica que objeto irá receber os eventos disparados.

Se esse parâmetro é um FXObject, então qualquer objeto FOX pode receber eventos?

Sim. Não só receber como também enviar.

E só aproveitando o ensejo, aqui outra grande característica do FOX se revela: a capacidade de conectar os objetos entre si. Aqui essa conexão é estabelecida.

FXSelector sel

Além do alvo do evento, é preciso dizer qual é a mensagem que este widget envia. FXSelector nada mais é que um inteiro sem sinal.

Quando falarmos de tratamento de evento, esses dois parâmetros serão discutidos em mais detalhes.

Obs.: não estão presentes em gerenciadores de layout. Simplesmente porque eles não enviam eventos que o usuário queira tratar por conta própria.

FXuint opts

As opções do widget.

Alguns widgets possuem opções específicas. Por exemplo, um botão tem a opção BUTTON_TOOLBAR (entre outras, naturalmente) que faz com que ele tenha aparência achatada, levantando as bordas ao se passar com o mouse por cima (como o próprio nome diz, um botão da barra de ferramentas).

Aqui são passadas também opções de borda e de layout. No tutorial sobre criar um botão (aqui), eu criei um botão normal (ou seja, com borda levantada, grossa, com o texto centralizado e o ícone antes do texto) e que se expande pela janela inteira (uma opção de layout).

Todas essas opções são definidas por meio de enumerações e podem ser combinadas com o operador OU sobre bits ( | ).

FXint x, FXint y

Posição. O único detalhe é que essas coordenadas são em relação à janela pai (mãe?). Mas como os gerenciadores de layout se encarregam de posicionar seus filhos, raramente é necessário especificá-los manualmente.

FXint w, FXint h

Largura e altura do widget. Novamente, isso é controlado pelos gerenciadores de layout. Mas é mais comum precisar controlar o tamanho que a posição.

Normalmente não é necessário porque a maioria dos widgets sabe seu tamanho mínimo: um botão, por padrão, sempre vai ter um tamanho suficiente para exibir seu texto e ícone. Entretanto, alguns widgets não têm um tamanho mínimo: um FXCanvas, por exemplo, não tem nada dentro dele para calcular seu tamanho mínimo, então tem que dizer o tamanho dele (ou deixar que o gerenciador de layout o diga).

FXint pl, FXint pr, FXint pt, FXint pb

Bem, esses parâmetros servem para informar a quantidade de espaço entre sua borda e outros widgets. Se for um gerenciador de layout, define o espaço entre sua borda interna e os widgets (conforme já explicado aqui). Se for um widget folha (ou seja, não recebe nenhum filho na hierarquia), indica o espaço entre sua borda externa e outros widgets, conforme a figura a seguir:

Esses aqui é que são raros de especificar. Os valores padrões que eles apresentam dão praticamente sempre bons resultados.

FXint hs, FXint vs

Estes só estão disponíveis para gerenciadores de layout. Informam o espaço entre os seus filhos; também foi explicado aqui. E seus valores padrões também dão um resultado agradável.

Errata: Ícones

2009-04-23T18:34:00.004-03:00

No tutorial sobre ícones, eu falei que o ícone deve saber quem é seu aplicativo. Isto é correto.

Entretanto, logo em seguida eu disse que isso era para que o ícone fosse criado junto com o aplicativo. Não é bem assim.

Um aplicativo FOX (FXApp) não tem conhecimento dos ícones ou imagens. Então quem tem a responsabilidade de criá-los é exatamente quem vai utilizá-los, seja uma janela, um botão ou qualquer outro objeto que exiba um ícone/imagem.

Ou seja, se a minha janela tem um ícone, o create() da janela vai chamar o create() de seu ícone. E como ícones e imagens podem ser compartilhados, a eles é permitido chamar create() mais de uma vez.

Observe que os objetos FOX são organizados em uma hierarquia em árvore, em que os pais criam os filhos. Isso quer dizer que se eu instancio uma imagem e dou um dono para ela antes que esse dono tenha sido criado, essa imagem será criada junto com seu dono.

Se eu instanciar uma imagem depois que seu dono foi criado, é preciso chamar create() na imagem manualmente.

Bom, o objetivo desse tópico era apenas apresentar essa correção. No fundo, no fundo, as imagens são criadas junto com o aplicativo, que é a raiz da hierarquia. Só que as imagens não são filhas do aplicativo, como eu imaginei, sendo criadas automaticamente se, e somente se, tiverem algum widget que seja dono delas.

Botões: Botão simples

2009-04-23T15:22:00.008-03:00

Retornando aos tutoriais básicos, falarei agora rapidamente sobre criar um botão na interface. Também os detalhes são diversos aqui, portanto este também é o primeiro tópico de uma série sobre os botões que o FOX Toolkit disponibiliza.

Neste primeiro tópico, criarei apenas um botão que se expande pela janela inteira e não está associado a nenhum evento (falarei mais tarde sobre tratamento de eventos).

Vamos lá, então.

FoxTutorialMainWindow.cpp

22   new FXButton(this, "Hello, &FOX!", NULL, NULL, 0,
23       BUTTON_NORMAL|LAYOUT_FILL);

Pronto, o botão está criado.

Discussão

FXButton é a classe FOX para um botão simples, que você pressiona, solta, e ele executa uma ação. Aqui eu instancio um novo objeto dessa classe. Novamente, sem a necessidade de atribuir a um ponteiro, pois a própria janela se encarregará de liberá-lo.

Os parâmetros que foram passados:

this: significa que o botão será colocado dentro da própria janela principal.
"Hello, &FOX!": texto que aparecerá no botão. O & significa a letra que servirá de mnemônico, no caso F. Assim, Alt+F é o atalho para pressionar o botão. Existem outros detalhes dentro do texto do botão, que serão discutidos mais adiante.
NULL: o ícone do botão. Aqui é criado um botão somente com texto, então fica nulo mesmo.
NULL: o alvo da mensagem. Como ele não lança nenhum evento, nulo.
0: a mensagem que o botão envia. Novamente, ele não lança nenhum evento: zero.
BUTTON_NORMAL|LAYOUT_FILL: opções do botão. BUTTON_NORMAL significa um botão com borda grossa e elevada, com o texto centralizado e o ícone à esquerda. LAYOUT_FILL significa que ele será expandido para ocupar a janela inteira. Esses detalhes serão explicados em seu devido tempo.

As demais opções referem-se à posição, tamanho e espaçamentos do botão, e normalmente não é necessário informá-los, pois têm valores padrões.

Resultado

Lembrando que FXMainWindow é um gerenciador de layout, redimensionar a janela fará com que o botão seja automaticamente redimensionado.

---
Código-fonte para este tutorial.

Layout Managers: Espaçamentos

2009-04-17T18:18:00.003-03:00

Todos os gerenciadores de layout do FOX Toolkit têm um preenchimento (padding) interior, que afasta seus widgets filhos das suas bordas de cima, baixo, esquerda e direita por uma certa distância em pixels.

Além do preenchimento, há também um espaçamento (spacing), que é a distância (em pixels) entre dois widgets dentro do mesmo gerenciador de layout.

Bom, acho que com um desenho fica mais fácil de entender:

PL - espaço entre os widgets e a borda esquerda do gerenciador
PR - espaço entre os widgets e a borda direita
PT - espaço entre os widgets e a borda superior
PB - espaço entre os widgets e a borda inferior

HS - espaço horizontal entre um widget e outro
VS - espaço vertical entre um widget e outro

Esses parâmetros (nessa ordem) são tipicamente os seis últimos parâmetros do construtor de um gerenciador de layout. Porém, são fornecidos valores padrões para esses parâmetros, ou seja, na maioria dos casos não será necessário informá-los.

Como exemplo, o construtor de FXHorizontalFrame:


FXHorizontalFrame(FXComposite *p,
               FXuint opts = 0,
               FXint x = 0, FXint y = 0,
               FXint w = 0, FXint h = 0,
               FXint pl = DEFAULT_SPACING,
               FXint pr = DEFAULT_SPACING,
               FXint pt = DEFAULT_SPACING,
               FXint pb = DEFAULT_SPACING,
               FXint hs = DEFAULT_SPACING,
               FXint vs = DEFAULT_SPACING
              );

DEFAULT_SPACING é uma enumeração definida em FXPacker.h (FXHorizontalFrame deriva diretamente de FXPacker):


enum { DEFAULT_SPACING = 4 };

Ou seja, ao se colocar widgets dentro de um FXHorizontalFrame, estes estarão distantes das bordas por quatro pixels, e distantes entre si também por quatro pixels (isto, claro, se os valores não forem informados, aceitando os padrões).

Layout Managers: Introdução

2009-04-17T12:23:00.006-03:00

Em uma interface gráfica de usuário, é muito importante que layout seja bem atrativo. Informar manualmente as posições e dimensões de cada objeto dá ao programador total controle sobre a interface. Entretanto, essa abordagem tem duas desvantagens seriíssimas:

é uma tarefa tediosa e que consome muito tempo
se o tamanho da tela mudar, os objetos devem se adaptar a essas mudanças; se suas posições e dimensões forem absolutas, eles não se modificarão junto com a tela

Devido a isso, a maneira mais recomendada de se posicionarem objetos é utilizando os chamados Gerenciadores de Layout (Layout Managers). A tarefa principal de um gerenciador de layout é arrumar os objetos que estão dentro dele de alguma maneira específica. Existem diferentes gerenciadores, que organizam seus objetos de cima para baixo, da esquerda para direita, em forma de grade e até um por cima do outro. A maioria deles permite, também, que as posições e dimensões sejam informadas explicitamente.

As vantagens de se utilizarem os gerenciadores de layout incluem:

Evita a tarefa chata de posicionar os controles
Os controles são rearrumados automaticamente quando há mudanças no layout (por exemplo, o usuário aumenta o tamanho da fonte)
O layout é recalculado automática e inteligentemente quando o usuário redimensiona a janela
Fica mais fácil adicionar controles que são criados automaticamente dependendo do controle do programa, como por exemplo interfaces criadas com base em bancos de dados

Todos os gerenciadores de layout do FOX Toolkit são derivados de FXComposite. Isso significa que é possível aninhá-los arbitrariamente. Esse aninhamento dos gerenciadores adequados, junto com as opções de layout passadas tanto para os próprios gerenciadores quanto para os objetos que ficarão dentro deles é que definirá o arranjo da interface.

Gerenciadores de layout básicos

O FOX Toolkit vem com alguns gerenciadores de layout de propósito geral. Os principais são:

FXPacker: posiciona os objetos dentro de seu retângulo, grudandos-os a um dos lados (esquerdo, direito, superior ou inferior) e reduzindo o tamanho disponível de acordo. Por exemplo, se um objeto é posicionado à esquerda ou direita, a largura é reduzida; se for posicionado em cima ou embaixo, a altura é reduzida.
FXTopWindow: opera da mesma forma que o FXPacker; entretanto, não é utilizado diretamente, pois não tem um construtor público. É utilizado indiretamente através de FXMainWindow e FXDialogBox (duas subclasses diretas). Resumindo, toda janela que for criada (seja a principal ou uma caixa de diálogo) vai ter esse comportamento.
FXHorizontalFrame: organiza os filhos horizontalmente da esquera para direita (padrão) ou da direita para esquerda.
FXVerticalFrame: organiza os filhos verticalmente de cima para baixo (padrão) ou de baixo para cima.
FXMatrix: organiza os filhos em forma de grade, com linhas e colunas.
FXSwitcher: posiciona os filhos exatamente um em cima do outro, deixando apenas um deles visível
FXGroupBox: provê a mesma funcionalidade do FXPacker, além de adicionar bordas ao redor do conteúdo e um rótulo (label) opcional.
FXSplitter: divide a tela horizontal ou verticalmente em duas áreas; a divisão pode ser movida pelo usuário.
FX4Splitter: divide a tela em quatro partes; da mesma forma, o usuário pode modificar as divisões.
FXSpring: tipicamente colocada dentro de um FXHorizontalFrame ou FXVerticalFrame. A grande diferença do FXSpring para outros gerenciadores é que ele permite uma divisão da tela em proporções fixas, por exemplo, dividir uma janela em três partes nas proporções 1:2:1 (a janela do meio sempre será o dobro das outras duas).

Continua...

Esta é apenas a primeira parte de uma séries de tópicos relacionados aos gerenciadores de layout. Este é um assunto muito extenso, que ainda tem muito a ser discutido. Existem vários detalhes a respeito deles, e haverá tópicos específicos para cada gerenciador mostrado acima.

Exibir imagem do OpenCV (IplImage)

2009-04-16T14:10:00.006-03:00

Além do FOX Toolkit, eu utilizo a biblioteca OpenCV (Open Source Computer Vision Library), pois trabalho com Processamento de Imagens. Então surgiu a necessidade de juntar os dois.

O OpenCV até fornece alguns recursos de interface gráfica, mas são muito limitados: apenas janelas, trackbars e tratamento de eventos de mouse e teclado. A próxima figura mostra uma janela com uma trackbar.

Quebrando, então, a seqüência de tutoriais básicos, vou ensinar como exibir uma imagem do OpenCV (IplImage) em um aplicativo FOX.

Para isso, criarei um aplicativo que abre uma imagem pelo OpenCV, exibe e aplica o filtro da média. Não vou falar da criação da interface e do tratamento de eventos, apenas mostrar como se faz a "conversão" de IplImage para FXImage.

Na declaração da classe, eu apenas declaro os ponteiros para as imagens:


19   FXImageView *imageView;
20
21   FXImage *fxImage;
22   IplImage *iplImage;

No construtor, eu apenas atribuo nulo a ambas, já que o usuário é quem vai escolher a imagem.


32   fxImage = 0;
33   iplImage = 0;

A "conversão" é feita ao carregar a imagem:


52 long MainWindow::onCmdOpen(FXObject*, FXSelector, void*) {
53   FXFileDialog dialog(this, "Abrir imagem");
54
55   if (!dialog.execute(PLACEMENT_OWNER))
56     return 1;
57
58   if (fxImage)
59     delete fxImage;
60
61   if (iplImage)
62     cvReleaseImage(&iplImage);
63
64   FXString filename = dialog.getFilename();
65
66   IplImage *temp = cvLoadImage(filename.text());
67   iplImage = cvCreateImage(cvGetSize(temp), IPL_DEPTH_8U, 4);
68
69   cvCvtColor(temp, iplImage, CV_BGR2RGBA);
70
71   cvReleaseImage(&temp);
72
73   FXColor *colorData = reinterpret_cast<FXColor*> (iplImage->imageData);
74
75   fxImage = new FXImage(getApp(), colorData,
76       IMAGE_SHMP|IMAGE_SHMI|IMAGE_KEEP,
77       iplImage->width, iplImage->height);
78
79   fxImage->create();
80
81   imageView->setImage(fxImage);
82
83   return 1;
84 }

Aqui, eu crio uma imagem temporária só para carregar a imagem do arquivo. Neste caso, ele abre uma imagem colorida com três canais de 8 bits.

A representação interna do IplImage é um vetor de caracteres e os pixels são armazenados em BGR.

A representação interna do FXImage é um vetor de FXColor (equivalente a um inteiro sem sinal). Em cada inteiro são armazenados quatro canais (um byte para cada): RGBA.

Bom, aí já temos uma semelhança: ambos armazenam em um vetor. Isso que dizer que eu posso aproveitar o vetor de pixels do IplImage e jogar dentro do FXImage. Basta converter a representação interna.

Então, cria-se uma IplImage com quatro canais e profundidade de 8 bits sem sinal. Esta é a que foi declarada em nossa classe.


67   iplImage = cvCreateImage(cvGetSize(temp), IPL_DEPTH_8U, 4);

Basta então converter nossa imagem temporária de BGR para RGBA:


69   cvCvtColor(temp, iplImage, CV_BGR2RGBA);

Assim, já temos uma IplImage com representação interna parecida com a de FXImage. É preciso ainda converter de char* para FXColor*. Essa não é uma conversão padrão, portanto é preciso usar um operador especial para isso.

Eu acho até dolorido usá-lo, mas não vi outra alternativa.


73   FXColor *colorData = reinterpret_cast<FXColor*> (iplImage->imageData);

Com um vetor de pixels no formato interno do FXImage, é só criar nossa imagem:


75   fxImage = new FXImage(getApp(), colorData,
76       IMAGE_SHMP|IMAGE_SHMI|IMAGE_KEEP,
77       iplImage->width, iplImage->height);
78
79   fxImage->create();

Como a imagem foi criada depois do aplicativo, é preciso chamar create() manualmente.

Manipulando a imagem

Agora, temos um FXImage com o vetor de pixels compartilhado com o IplImage. Isso significa que qualquer operação executada sobre a imagem Ipl refletirá na imagem FX.

Isso é demonstrado aqui, onde eu aplico o filtro da média para suavizar a imagem:


88 long MainWindow::onCmdSmooth(FXObject*, FXSelector, void*) {
89   cvSmooth(iplImage, iplImage, CV_BLUR, 3, 3);
90
91   fxImage->render();
92
93   imageView->update();
94
95   return 1;
96 }

Os únicos detalhes é que é preciso chamar render() de FXImage e atualizar o imageView.

O render() é necessário porque há duas representações do FXImage: uma do lado do cliente, que neste caso é o vetor compartilhado entre as duas imagens, e o lado do servidor gráfico. render() atualiza o lado do servidor gráfico, de forma que seja exibida a imagem modificada.

E é preciso atualizar o imageView porque ele não detecta automaticamente alterações na imagem, então é preciso informar manualmente que ele deve se redesenhar.

Trabalhando com vídeos

O OpenCV, além de imagens estáticas, também trabalha com vídeos, que podem ser capturados de câmeras ou lidos de arquivos.

Cada quadro do vídeo é recuperado em um IplImage. Isso significa que dá para usar a técnica descrita acima. O problema é que a imagem que representa cada quadro não pode ser deletada nem modificada. Isso significa que para cada quadro do vídeo, é preciso fazer a conversão para uma outra imagem.

Seria mais simples se desse para modificar a imagem retornada, assim dava para compartilhar os pixels sem a necessidade de uma imagem extra.

Infelizmente, não tenho nenhum exemplo a mostrar com vídeos.

Resultado

Créditos

Imagem retirada do Eu Podia Tá Matando

---
Código-fonte deste tutorial.
Baixar vídeo.

FXTopWindow: Decorações e Posicionamento de Janelas

2009-04-15T13:38:00.003-03:00

Quando falei sobre criar a janela principal (aqui), citei alguns aspectos relativos às decorações da janela e seu posicionamento, informando que isto era definido em FXTopWindow.h, onde está definida a superclasse direta de FXMainWindow.

Falarei agora especificamente desses dois assuntos.

Decorações

As decorações são itens "extras" que o seu decorador de janelas acrescenta. São as bordas da janela, barra de título, botões de minimizar, maximizar, fechar, menu da janela etc. FXTopWindow.h define a seguinte enumeração:


enum {
DECOR_NONE        = 0,
DECOR_TITLE       = 0x00020000,
DECOR_MINIMIZE    = 0x00040000,
DECOR_MAXIMIZE    = 0x00080000,
DECOR_CLOSE       = 0x00100000,
DECOR_BORDER      = 0x00200000,
DECOR_SHRINKABLE  = 0x00400000,
DECOR_STRETCHABLE = 0x00800000,
DECOR_RESIZE      = DECOR_SHRINKABLE|DECOR_STRETCHABLE,
DECOR_MENU        = 0x01000000,
DECOR_ALL         = (DECOR_TITLE       |
                     DECOR_MINIMIZE    |
                     DECOR_MAXIMIZE    |
                     DECOR_CLOSE       |
                     DECOR_BORDER      |
                     DECOR_SHRINKABLE  |
                     DECOR_STRETCHABLE |
                     DECOR_MENU
                    )
};

Apesar de serem bem intuitivos os nomes, vou explicá-los:

DECOR_NONE: Janela sem bordas, sem nada, só com o conteúdo. Se parecer inútil, pense em uma janela em modo tela cheia.
DECOR_TITLE: Título da janela.
DECOR_MINIMIZE: Adiciona a capacidade de minimizar a janela.
DECOR_MAXIMIZE: Adiciona a capacidade de maximizar a janela.
DECOR_CLOSE: Adiciona a capacidade de fechar a janela.
DECOR_BORDER: Adiciona bordas à janela.
DECOR_SHRINKABLE: Possibilita diminuir o tamanho da janela.
DECOR_STRETCHABLE: Possibilita aumentar o tamanho da janela.
DECOR_RESIZE: Permite aumentar ou diminuir a janela. Perceba que é apenas uma combinação das duas anteriores para facilitar.
DECOR_MENU: Habilita o menu da janela.
DECOR_ALL: Já conhecido, habilita todo mundo.

Agora a pergunta: se é tão intuitivo, porque explicar cada um? Simples. Essas são apenas sugestões para o decorador de janelas. Não são regras.

Isso quer dizer que, se o decorador achar melhor desenhar um item que você não especificou, ele desenha. Por isso eu não falei "Desenha isso", "Desenha aquilo", mas sim "Adiciona a capacidade", "Habilita". Por exemplo, para exibir o botão de fechar, tem que ter a barra de título (e com certeza as bordas vêm de brinde). Acontece também de se especificarem somente os botões de minimizar e fechar, mas o de maximizar aparece junto, desabilitado.

O que eu quero dizer é que cada decorador tem suas regras próprias, e que essas são apenas sugestões. Mas tenha certeza que o que você especificar ele faz. E se não especificar, também não faz; ou seja, se você não quer que a janela aumente de tamanho nem maximize, ela não irá, embora o botão de maximizar esteja lá (desabilitado, claro).

Não quero dizer, por outro lado, que você deva confiar sempre nos itens que vêm de "brinde". Especifique sempre os que você quer ter certeza que estejam disponíveis.

Posicionamento

Para mostrar a janela, chamei o método show(), passando PLACEMENT_SCREEN como parâmetro, exibindo no meio da tela. As opções de posicionamento são:

enum {
 PLACEMENT_DEFAULT,
 PLACEMENT_VISIBLE,
 PLACEMENT_CURSOR,
 PLACEMENT_OWNER,
 PLACEMENT_SCREEN,
 PLACEMENT_MAXIMIZED
};

PLACEMENT_DEFAULT: No tamanho e posição que foram especificados no construtor.
PLACEMENT_VISIBLE: Posiciona a janela para ficar totalmente visível. Confesso que nunca usei...
PLACEMENT_CURSOR: Posiciona onde está o cursor do mouse.
PLACEMENT_OWNER: Posiciona no centro da janela dona desta. Quando adicionarmos mais janelas, esta opção será utilizada.
PLACEMENT_SCREEN: Já conhecido, posiciona no centro da tela.
PLACEMENT_MAXIMIZED: Deixa a janela do tamanho da tela. Mas tem uma ressalva.

O PLACEMENT_MAXIMIZED realmente deixa a janela do tamanho da tela. Porém, dependendo do decorador (sempre ele...) as bordas vão todas embora. Dos que eu já usei (foram só três, mas tudo bem), só o Emerald (sempre ele...) preservou as bordas, deixando a janela do jeito que se imagina que uma janela maximizada deva ser. O decorador do Windows (não sei o nome) e o gtk-window-decorator (decorador padrão do GNOME) sumiram com as bordas.

E se eu quiser que a janela já inicie maximizada, com borda e tudo?

Chame maximize() em vez de show().

Tutorial: Ícones

2009-04-14T13:45:00.005-03:00

O que seria uma interface gráfica sem eles? Neste tutorial ensinarei a colocar ícones na janela (tanto o pequeno quanto o grande). Claro que ícones no FOX não servem apenas para isso, mas como eu só falei da janela principal, é lá que vamos colocá-los.

Um breve histórico

Acrescentar um ícone na interface FOX era bem trabalhoso. Primeiro, era preciso converter a imagem em um vetor (sim, um vetor estilo C) de pixels utilizando um programa chamado reswrap, distribuído junto com o FOX Toolkit. Sua sintaxe era:

reswrap [ options ] [ -o[a] arquivo_de_saida ] arquivos ...

Opções:

-o – Cria ou sobrescreve arquivo_de_saida
-oa – Acrescenta ao arquivo_de_saida
-e – Gera declaração de referência externa
-i – Gera um arquivo de cabeçalho

Assim, criavam-se dois arquivos, um icons.h com a declaração dos vetores, e um icons.cpp com o conteúdo deles. Era uma coisa monstruosa.

Todo este trabalho foi aliviado com a chegada de uma classe mágica: FXIconSource. Mas vamos ao código. Vou exibir aqui apenas as modificações relativas ao tutorial anterior.

FoxTutorialMainWindow.h

21 private:
22   void loadIcons();
23
24   void destroyIcons();
25
26 protected:
27   FXIcon *windowIcon;
28   FXIcon *windowMiniIcon;

Discussão

22/24: Métodos para carregar/destruir os ícones. Apenas por motivos de organização, deixando a tarefa centralizada.

27/28: Os dois ícones da janela.

O restante do arquivo permanece igual.

FoxTutorialMainWindow.cpp

18 FoxTutorialMainWindow::FoxTutorialMainWindow(FXApp *a)
19   : FXMainWindow(a, "Tutorial FOX", NULL, NULL, DECOR_ALL, 0, 0, 200, 200) {
20   loadIcons();
21
22   setIcon(windowIcon);
23   setMiniIcon(windowMiniIcon);
24 }

...

32 FoxTutorialMainWindow::~FoxTutorialMainWindow() {
33   destroyIcons();
34 }
35
36 /******************************************************************************/
37
38 void FoxTutorialMainWindow::loadIcons() {
39   FXIconSource iconSource(getApp());
40
41   windowIcon = iconSource.loadIconFile("icons/folders.gif");
42   windowMiniIcon = iconSource.loadScaledIconFile("icons/folders.gif", 16);
43 }
44
45 void FoxTutorialMainWindow::destroyIcons() {
46   delete windowIcon;
47   delete windowMiniIcon;
48 }

Discussão

20: Carrega os ícones. Descrição do método mais adiante.

22/23: Configura os ícones para a janela.

33: Ícones podem ser compartilhados (utilizados por mais de um widget por vez), portanto devem ser destruídos manualmente.

38-43: Nosso método para carregar os ícones.

39: Cria um objeto da classe FXIconSource. Apesar do nome, serve também para carregar imagens. Mas vamos com calma.
Cada ícone deve saber quem é sua aplicação, portanto o IconSource já deve vir com essa informação. Serve para que eles sejam criados junto com a aplicação.

41: Carrega um ícone do arquivo, retornando um ponteiro para o ícone.

42: Idem, mas além de carregar, escala o ícone para que nenhuma de suas dimensões exceda o valor estabelecido (no caso, 16 pixels).

45-48: Nosso destrutor.
Conforme dito acima, precisamos destruir manualmente nossos ícones. delete é o suficiente para isso.

Resultado

Considerações finais

Por que GIF?

Apenas dois motivos: é suportado nativamente pelo FOX Toolkit e suporta transparência. Mas nada impede de usar outros formatos.

Créditos

Destaque de sintaxe provido por Code2HTML, v. 0.9.1
On Stage Icon Set

---
Código-fonte deste tutorial.

FXMainWindow

2009-04-13T13:30:00.001-03:00

Já que nosso último tutorial foi sobre criar uma janela vazia, usando FXMainWindow, falarei agora especificamente sobre essa classe.

Descrição

A MainWindow é normalmente a janela central de uma aplicação. Aplicações podem ter qualquer número de janelas principais.

Quando uma MainWindow é fechada, ela envia uma mensagem SEL_CLOSE para o seu alvo; o alvo deve retornar 0 se não houver nenhuma objeção contra o fechamento, e 1 caso contrário.

Depois que a mensagem SEL_CLOSE for enviada e nenhuma objeção for levantada, a janela principal deletará a si mesma.

Declaração


 1 class FXAPI FXMainWindow : public FXTopWindow {
 2   FXDECLARE(FXMainWindow)
 3 protected:
 4   FXMainWindow(){}
 5 private:
 6   FXMainWindow(const FXMainWindow&);
 7   FXMainWindow &operator=(const FXMainWindow&);
 8 public:
 9
10   /// Constrói uma janela principal
11   FXMainWindow(FXApp* a, const FXString& name,
12                FXIcon *ic = NULL, FXIcon *mi = NULL,
13                FXuint opts = DECOR_ALL,
14                FXint x = 0, FXint y = 0,
15                FXint w = 0, FXint h = 0,
16                FXint pl = 0, FXint pr = 0,
17                FXint pt = 0, FXint pb = 0,
18                FXint hs = 0, FXint vs = 0
19   );
20
21   /// Cria os recursos do servidor (server-side)
22   virtual void create();
23
24   /// Destrutor
25   virtual ~FXMainWindow();
26 };

Sim, ela é só isso.

Discussão

1: A classe FXMainWindow é derivada de FXTopWindow. Por isso ela é pequena desse jeito, toda a funcionalidade dela é herdada das superclasses. E a hierarquia não é pequena:

Obs.: Em tópicos deste tipo, tratarei de apenas uma classe, ou seja, vou me limitar ao que a declaração da classe apresenta.

11-19: Construtor. Recebe 15 parâmetros:

FXApp *a - Ponteiro para a aplicação.
FXString &name - Título da janela.
FXIcon *ic, FXIcon *mi - Ícones da janela.

Ícone grande, que aparece quando se troca de janela com Alt+Tab
Ícone pequeno, que aparece no canto superior esquerdo da janela

FXuint opts - Opções da janela.
Essas opções referem-se às decorações da janela, e são definidas em FXTopWindow.h. Chegaremos lá.

FXint x, FXint y - Posição inicial da janela.
FXint w, FXint h - Largura e altura da janela.
FXint pl, FXint pr, FXint pt, FXint pb - Espaçamento entre os componentes e a borda da janela.
Uma MainWindow é um gerenciador de layout (layout manager), portanto aceita esses parâmetros. Quando falarmos de gerenciadores de layout, explicarei melhor.

FXint hs, FXint vs - Espaçamento entre um componente e outro.
Idem.

Percebam que apenas a aplicação e o título da janela são obrigatórios. Todos os outros parâmetros têm valores default, ou seja, podem ser omitidos. Outra vantagem do FOX Toolkit: os parâmetros default asseguram um layout agradável aos olhos.

Observações

A descrição da classe foi retirada da própria documentação de referência.
O gráfico de herança foi desenhado com o programa Dia.

Links

Tutorial: Janela simples

2009-04-09T15:39:00.005-03:00

De posse de um ambiente de desenvolvimento todo configurado, passemos à parte mais interessante: o código.

Neste tutorial, ensinarei a criar uma janela simples, vazia. Essa janela será, naturalmente, a nossa janela principal, e será incrementada a cada tutorial.

Sendo essa janela a principal, ela dever ser derivada da classe FXMainWindow.

Obs.: Toda classe no FOX Toolkit tem o prefixo FX.

FoxTutorialMainWindow.h

 1 /*
 2  * FoxTutorialMainWindow.h
 3  *
 4  *  Created on: 07/04/2009
 5  *      Author: edgar
 6  */
 7
 8 #ifndef FOXTUTORIALMAINWINDOW_H
 9 #define FOXTUTORIALMAINWINDOW_H
10
11 #ifndef FXMAINWINDOW_H
12 #include <fox-1.6/FXMainWindow.h>
13 #endif
14
15 class FoxTutorialMainWindow : public FXMainWindow {
16   FXDECLARE(FoxTutorialMainWindow)
17
18 private:
19   FoxTutorialMainWindow() {}
20
21 public:
22   FoxTutorialMainWindow(FXApp *a);
23
24   virtual void create();
25
26   virtual ~FoxTutorialMainWindow();
27 };
28
29 #endif /* FOXTUTORIALMAINWINDOW_H */

Analisando linha por linha:

15: A classe FoxTutorialMainWindow é derivada de FXMainWindow.

16: Macro para declaração de hierarquia. Obrigatório para todas as classes FOX.

19: Construtor default privado sem corpo. Obrigatório também.

22: Construtor público. É o que vamos utilizar. Recebe como parâmetro um ponteiro para FXApp, classe que representa uma aplicação FOX.

24: Todos os componentes FOX têm um método virtual void create(); aqui vamos sobrescrevê-lo.

26: Nosso destrutor.

FoxTutorialMainWindow.cpp


 1 /*
 2  * FoxTutorialMainWindow.cpp
 3  *
 4  *  Created on: 07/04/2009
 5  *      Author: edgar
 6  */
 7
 8 #include <fox-1.6/fx.h>
 9
10 #include "FoxTutorialMainWindow.h"
11
12 FXDEFMAP(FoxTutorialMainWindow) FoxTutorialMainWindowMap[] = {
13 };
14
15 FXIMPLEMENT(FoxTutorialMainWindow, FXMainWindow,
16     FoxTutorialMainWindowMap,
      ARRAYNUMBER(FoxTutorialMainWindowMap))
17
18 FoxTutorialMainWindow::FoxTutorialMainWindow(FXApp *a)
19   : FXMainWindow(a, "Tutorial FOX", NULL, NULL, DECOR_ALL,
        0, 0, 200, 200) {
20 }
21
22 void FoxTutorialMainWindow::create() {
23   FXMainWindow::create();
24
25   show(PLACEMENT_SCREEN);
26 }
27
28 FoxTutorialMainWindow::~FoxTutorialMainWindow() {
29 }

Analisando linha por linha:

8: fx.h é um arquivo de fachada que inclui quase todos os arquivos de cabeçalho do FOX Toolkit. Por enquanto, basta saber que ele inclui o suficiente para a interface gráfica de um programa comum.

Outro ponto que merece destaque é que todas as classes FOX estão dentro do namespace FX. O arquivo fx.h automaticamente instrui o compilador a usar esse namespace (using namespace FX;), a menos que a macro FX_NO_GLOBAL_NAMESPACE esteja definida. Mas cá entre nós, quem iria querer definir essa macro e usar FX::FXMainWindow? Detalhe: isso para todas as classes.

12-13: Definição do mapa de mensagens. Aqui é definido o tratamento de eventos, ou seja, a resposta da janela diante das ações do usuário. Como nossa janela não vai tratar nenhum evento por enquanto, ele fica vazio mesmo. Quando falarmos de tratamento de eventos, explicarei o mapa de mensagens com mais detalhes.

15-16: Implementação do mapa de mensagens. Esse é obrigatório. Os parâmetros dessa macro são:

Nome da classe (FoxTutorialMainWindow)
Nome da superclasse (FXMainWindow)
Mapa de mensagens (FoxTutorialMainWindowMap)
Número de entradas do mapa de mensagens. Para não haver a necessidade de atualizar manualmente esse valor sempre que colocar ou tirar uma entrada do mapa, o FOX provê a macro ARRAYNUMBER, que calcula o número de elementos de um vetor estático.

18-20: Construtor. Como nossa classe é derivada de FXMainWindow, aqui chamamos o construtor da superclasse para a devida inicialização. Mais tarde falarei especificamente da classe FXMainWindow; portanto, apenas saiba que os parâmetros passados são, respectivamente:

a aplicação que será dona dessa janela
título da janela
ícone grande (o ícone que aparece quando se muda de janela com Alt+Tab)
ícone pequeno (o que fica no canto da janela, na barra de título)
decorações da janela (borda, barra de título, menu da janela etc.)
posição X e Y da janela
largura e altura da janela

Ou seja, estamos criando uma janela com as seguintes propriedades:

chamada "Tutorial FOX"
sem ícones (normalmente passa-se NULL para ambos, sendo ajustados dentro do construtor)
com todas as decorações disponíveis (mais detalhes sobre isso mais tarde, em outro post)
inicialmente posicionada no canto superior esquerdo da tela (0, 0)
tamanho inicial de 200x200

22-26: Aqui sobrescrevemos o método create(). Na verdade, apenas o estendemos para que, além de criar a janela, ela possa ser automaticamente exibida. Neste caso, ela será exibida no centro da tela.

28-39: Nosso destrutor. A classe não tem nada de novo, então não há o que destruir explicitamente. Vazio.

main.cpp

É necessário fornecer uma função main() (não WinMain() ou qualquer outra específica de plataforma) para que o programa rode. Normalmente, pode ser implementada da seguinte forma:


 1 /*
 2  * main.cpp
 3  *
 4  *  Created on: 07/04/2009
 5  *      Author: edgar
 6  */
 7
 8 #include <fox-1.6/fx.h>
 9
10 #include "FoxTutorialMainWindow.h"
11
12 int main(int argc, char *argv[]) {
13   FXApp app("Tutorial FOX", "Edgar Moraes Diniz");
14
15   app.init(argc, argv);
16
17   new FoxTutorialMainWindow(&app);
18
19   app.create();
20
21   return app.run();
22 }

Analisando linha por linha:

12: Por favor, sempre declarem a função main() dessa forma, retornando um inteiro e recebendo dois parâmetros, argc inteiro e argv um vetor de strings. Nada de void main(void). Isso é válido para qualquer aplicativo, mesmo (e principalmente) em linha de comando.

13: Instancia um objeto FXApp, que representa nossa aplicação. Os parâmetros são o nome da aplicação e o fabricante.

15: Inicia o aplicativo, analisando os argumentos de linha de comando. Não adianta tentar burlar a regra da linha 12, passando 0 e NULL. O FOX não deixa.

17: Instancia a nossa janela. Aqui cabe uma discussão interessante sobre o FOX Toolkit.

Percebam que eu não atribuí a nenhum ponteiro. Simplesmente porque não é necessário. O único parâmetro que eu tenho para a janela é a minha aplicação. Essa aplicação vai armazenar o ponteiro para a janela. Quando a aplicação for destruída, ela destrói tudo o que é dela, incluindo essa janela.

Pode parecer estranho no começo (eu levei um certo susto quando vi...), mas com o uso, percebe-se que esse é uma enorme vantagem do FOX. E isso ocorre o tempo inteiro; quando povoarmos nossa janela, isso ficará claro. Resumindo: não preciso ficar me preocupando em destruir um monte de objetos; eles são destruídos por seus donos.

19: Cria a aplicação. Da mesma forma, chamar create() em um objeto FOX faz com que ele chame create() de todos os seus filhos, ou seja, aqui será criada (e, lembrem-se, exibida) nossa janela.

21: Roda a aplicação. É o loop principal do programa, que vai ouvir e tratar eventos.

Resultado

Depois de compilado, basta executar. O resultado:

Lembram do DECOR_ALL? Ele permite que você redimensione, minimize e maximize a janela (entre outros aspectos). Brinquem à vontade com isso. Mais tarde falaremos do poder que o FOX Toolkit oferece com relação a essas três operações.

Obs.: Essa janela não está assim por causa do FOX. O FOX é responsável somente por essa área acinzentada interna. As bordas são de responsabilidade do decorador de janelas (por isso o prefixo DECOR_). Estou usando aqui o Emerald, o decorador de janelas para usar com o Compiz Fusion.

---
Código-fonte para este tutorial.

Tutorial: Criando um projeto

2009-04-08T14:47:00.009-03:00

O propósito desse tutorial é ensinar a criar um projeto que utilize o FOX Toolkit.

Vou explicar por que. Quem usa o Visual Studio precisa de uma atenção especial ao criar um projeto. Existem certas peculiaridades no processo.

Criando um projeto no Visual Studio

Na janela New Project, selecione, em Project Type, Win32, dentro de Visual C++. Em Templates, selecione Win32 Project.

Na verdade, nada impede que você selecione Win32 Console Application. A única diferença é que sempre que o programa rodar, vai aparecer um console, além da janela.

Na próxima janela, em Application Settings, marque a caixa "Empty Project".

Depois disso, é preciso configurar algumas opções do Linker. Vá no menu Project -> Properties...

Em Configuration Properties / Linker / Advanced, digite mainCRTStartup em Entry Point. Isso fará com que o linker utilize a função main(), em vez de procurar por WinMain().

Essa configuração só é necessária quando se utiliza o Visual Studio. A próxima é necessária para todos os IDEs.

Linkando com a biblioteca FOX

Obviamente, para poder utilizar as classes do FOX Toolkit, é necessário linkar com a biblioteca.

No Visual Studio, ainda nas propriedades do projeto, na seção Linker / Input, coloque FOX-1.6.lib em Additional Dependencies.

Não importa qual IDE seja utilizado, é necessário configurar o projeto para linkar com a biblioteca do FOX. Isso normalmente é feito nas propriedades do projeto. Só o que muda é que no gcc, não se coloca a extensão do arquivo nem o prefixo lib.

Por exemplo, no Eclipse (que utiliza o gcc), basta informar FOX-1.6. Ao compilar o programa, o Eclipse chama g++ -lFOX-1.6. O próprio linker se encarrega de colocar o prefixo lib e a extensão correta.

Daqui em diante, não vou mais me ater a um IDE específico. Falei sobre o Visual Studio porque ele possui essas peculiaridades, mas a partir daqui o processo é o mesmo para todo mundo.

Tutorial: Configurando o FOX

2009-04-07T18:01:00.006-03:00

Download

O FOX Toolkit encontra-se disponível para download no endereço www.fox-toolkit.org/download.html. Há sempre quatro versões disponíveis:

- Development snapshot (a versão mais atual disponível - também conhecido como bleeding edge)
- Development (versão em desenvolvimento)
- Stable (versão estável)
- Old stable (versão estável anterior)

Todas as versões estão disponíveis em dois pacotes diferentes: .zip para Windows e .tar.gz para Unix/Linux. Apesar disso, o conteúdo de ambos é exatamente o mesmo. Quem faz a diferença é a preferência do usuário.

O mais recomendado para os usuários comuns/finais é baixar a versão estável. A versão em desenvolvimento é para quem deseja testar bugs, enquanto o snapshot é a versão que está em desenvolvimento ativo, ou seja, é indicada para quem quer contribuir com o FOX ajudando no desenvolvimento.

Bom, depois de baixado, descompacte no local desejado, e aqui o processo se bifurca entre os usuários Windows e Linux (são os dois sistemas para os quais posso dar suporte).

Windows

A configuração do FOX Toolkit no Windows que será explicada aqui refere-se ao uso com o Microsoft Visual Studio 2005. Para quem utiliza o MinGW/MSYS ou Cygwin (ambos ports do gcc para Windows), as instruções são semelhantes à configuração no Linux.

Eu normalmente recomendo descompactar em C:\, porque o acesso é mais rápido. C:\Arquivos de programas também é interessante, pois algumas bibliotecas que têm instalador vão pra lá; colocar o FOX Toolkit junto delas fica mais organizado. Utilizarei a notação FOX_DIR para me referir ao diretório onde foi descompactado o arquivo.

Em FOX_DIR\windows\vcpp existe um workspace do MSVC 6.0 (o antigão mesmo) chamado win32.dsw. Abra esse arquivo. Se você usa uma versão posterior, ele vai perguntar se deseja converter para a versão mais nova (que nem se chama mais Workspace, mas Solution; entretanto, vou utilizar aqui o termo workspace, pois estou acostumado a ele e por ser o termo utilizado pela maiorias das IDEs). Apenas diga que sim, tanto para o workspace em si como para todos os projetos que estão dentro dele.

Neste workspace, há um projeto chamado "fox". Clique com o botão direito sobre ele e selecione "Set as Startup Project". Depois mude a configuração de Debug para Release e mande construir a biblioteca em Build -> Build fox. Aguarde um momento enquanto a biblioteca é compilada; não demora muito.

Será então criado um arquivo chamado FOX-1.6.lib em FOX_DIR\lib.

Agora é preciso configurar os diretórios de include e lib, para que o Visual Studio ache os arquivos de cabeçalho do FOX e a biblioteca. Essa é uma parte que eu acho chata quando se usa o Visual Studio, tem que informar quais são os diretórios.

Vá em Tools -> Options... e selecione "VC++ Directories" dentro de "Projects and Solutions". Configure os diretórios conforme as figuras abaixo.

Notem que eu destaquei também o OpenCV (Open Source Computer Vision Library). Essa é uma biblioteca que vem com um instalador para Windows, e se instala em Arquivos de Programas (apenas uma curiosidade).

Pronto! O Visual Studio está configurado para a programação com FOX Toolkit.

Linux

Para quem usa Linux, descompacte de preferência em um diretório sem espaços e de fácil acesso pelo terminal. A instalação é a padrão:

$ ./configure
$ make
# make install

Isso é o suficiente para começar a usar o FOX Toolkit no Linux. Os arquivos se espalham por /usr/local (include, lib, bin, man etc.). Como é um diretório padrão, o gcc encontra os cabeçalhos e bibliotecas naturalmente.

Obs.: Ao contrário do que ocorre no Visual Studio, compilar o FOX com gcc demora bastante...

Dúvida: Designer

2009-04-06T15:25:00.004-03:00

Uma dúvida bastante freqüente quando se fala em bibliotecas de interface gráfica é se elas possuem um editor visual. Com relação ao FOX Toolkit, a resposta é não. Pelo menos não algum que possa ser realmente utilizado.

Isso pode ser um balde de água fria (principalmente considerando que esse é o nosso segundo post), mas creio que é algo que deva ser dito com antecedência.

Para explicar a ausência de uma ferramenta desse tipo, as palavras de Jeroen van der Zijp, o próprio idealizador do FOX:

Sem dúvida, desenho de interface WYSIWYG (What You See Is What You Get - O que você vê é o que você tem) é legal. Mas eu suspeito que há motivos para que nenhum projeto de construtor de interface tenha sido levado a cabo até agora:

1) A construção de componentes do FOX Toolkit é feita com C++ bem compacto.

Já que isso é feito dentro de seu ambiente de edição confortável, cortar e colar código é mais rápido que devanear pela tela.

Pelo menos é isso que eu faço. Todos os meus menus são copiados e modificados a partir do primeiro que eu digitei. Quero apostar que posso fazer isso mais rápido em meu editor que abrir um construtor de interface, carregar um arquivo que descreve a interface, sair clicando com o mouse e escrever o arquivo de volta.

2) Muitos usuários do FOX Toolkit vêm de ambientes onde colocação programática e gerenciadores de layout eram a norma.

Colocar componentes usando gerenciadores aninhados requer um pouco mais de planejamento que desenhar interativamente na tela; entretanto, eu arrisco dizer que também leva a interfaces melhores.

Diálogos redimensionáveis são bem fáceis quando se usam gerenciadores de layout, e um desenhista de interface competente determinará que controles podem tirar vantagem desta capacidade de desenhar e acordo.

Como contra-exemplo, pense na minúscula caixa de texto onde você é forçado a informar suas opções de compilador no Visual Studio.

Então há a habilidade de mudar tamanhos de fonte, conteúdo de rótulos (labels), e ícones. Gerenciadores de layout automaticamente se recalculam baseados em seu conteúdo, e então mudar fontes ou legendas nos botões não requer nenhum redesenho ou devaneio com um construtor de interface.

Este recurso também será muito útil quando programadores passarem para outra linguagens.

3) A interface é apenas uma pequena parte de um projeto de programação típico.

Se você puder construir um controle de interface em uma única linha de código, mas gasta dúzias de linhas tratando sua funcionalidade na aplicação, você não economizou trabalho algum só por eliminar essa única linha.

É melhor tentar eliminar essas dúzias de outras linhas.

E é exatamente isso o que fazemos no FOX Toolkit por meio do FXDataTarget e a capacidade de interconexão entre componentes para reduzir a quantidade de "cola" entre os componentes e aquilo que eles controlam.

4) As tentativas até agora não suportaram a evolução a longo prazo das interfaces.

Vamos encarar, nenhum programa começa com a interface toda em sua forma final. Se uma ferramenta de design não provê suporte para toda a duração do projeto, realmente não será extremamente útil.

Em particular, deve suportar a modificação de design de interfaces que já estão enganchadas a funcionalidades da aplicação.

5) Usar interfaces criadas programaticamente, junto com gerenciadores de layout, torna fácil criar blocos de controles de interface dirigidos por dados.

Misturar controles gerados por construtores de interface com controles programáticos pode ser difícil devido à rigidez das posições no código gerado pelo construtor de interface.

Esta não é uma desculpa para a falta de um designer de interface para o FOX Toolkit, mas uma análise justa dos fatos, pelo menos como eu os vejo.

Eu gosto do conceito de Construtores de Interface, mas eu provavelmente teria que admitir que eu mesmo preferiria não me importar em usá-los para meus próprios projetos mesmo se existissem, devido ao efeito bem marginal [e possivelmente até negativo!] em minha produtividade.

Eu já usei construtores de interface e o conhecimento adquirido dessa experiência é que eu fico muito feliz em fazer desenhos com essas ferramentas, mas não consigo muito no sentido de trabalho real.

---

Esta dúvida foi retirada da lista de e-mails de usuários do FOX Toolkit. Leia a conversa toda aqui (em inglês).

O que é o FOX Toolkit?

2009-04-03T11:44:00.001-03:00

FOX é um toolkit em C++ para desenvolvimento fácil e efetivo de Interfaces Gráficas de Usuário (GUI - Graphical User Interface). Oferece uma coleção ampla e crescente de controles, e provê o estado da arte em facilidades como arrastar e soltar, seleção, assim como widgets OpenGL para manipulação de gráficos 3D. FOX também implementa ícones, imagens e recursos de conveniência como ajuda na barra de status e dicas de ferramentas. Dicas de ferramentas podem ser usadas até em objetos 3D!

Uma importância considerável é dada para fazer do FOX um dos mais rápidos toolkits disponíveis, e para minimizar o uso de memória: o FOX Toolkit utiliza técnicas para acelerar o desenho da interface. A memória é conservada ao permitir que os programadores criem e destruam elementos da interface sob demanda (on the fly).

Apesar de o FOX Toolkit já oferecer uma ampla coleção de controles, o FOX alavanca o C++ para permitir aos programadores construírem controles e elementos de interface adicionais, simplesmente pegando controles existentes e criando classes derivadas que simplesmente adicionam ou redefinem o comportamento desejado.

Um dos objetivos cordiais do projeto do FOX Toolkit é a facilidade de programação; dessa forma, a maioria dos controles pode ser criada usando uma única linha de código C++; a maioria dos parâmetros têm valores sensatos, que podem ser omitidos, e os gerenciadores de layout (layout managers) asseguram que os desenhistas de interface não precisem se preocupar com alinhamentos precisos.

Outro recurso legal do FOX Toolkit que reduz significativamente o número de linhas de código que devem ser escritas é a sua habilidade de ter widgets conectados entre si, e de passar certos comandos entre eles; por exemplo, um item de menu "Esconder barra de ferramentas" pode ser diretamente conectada à barra de ferramentas, fazendo com que fique oculta.

Finalmente, o FOX Toolkit deixa fácil manter o estado da interface de uma aplicação fazendo que os elementos atualizem-se automaticamente, perguntando o estado da aplicação. Este recurso elimina um grande esforço que pode passar por sensibilizar, desativar, marcar/desmarcar etc. dependendo do estado da aplicação.

FOX é Independência de Plataforma!

A lista de plataformas está crescendo! Atualmente, temos o FOX Toolkit rodando em um grande número de sistemas operacionais, desde o Linux, FreeBSD, SGI IRIX, HP-UX, IBM AIX, SUN Solaris, DEC/Compaq Tru64 UNIX, até sistemas operacionais MS-Windows como Windows9x, Windows NT, Windows ME e Windows 2000. Como a maioria da implementação do FOX Toolkit é completamente inconsciente da plataforma subjacente (em muitos casos nem inclui arquivos de cabeçalho), as aplicações funcionam praticamente de forma idêntica em todas essas plataformas.

Por exemplo, aqui é a aplicação de amostra do FOX textedit rodando sob Windows NT. E aqui é a mesma aplicação rodando em um sistema Silicon Graphics Octane.

---
Texto traduzido da página oficial. Leia o original aqui.