Construa seu navegador
Nesta edição vamos continuar o desenvolvimento do RDL Navigator, um browser personalizado
O KDE (K Development Environment) possui um grande número de APIs extremamente úteis para o programador. Entre os assuntos abordados neste artigo, alguns podem ser de grande importância para quem deseja desenvolver as sempre populares aplicações de quiosque usadas em supermercados, comércio, terminais de auto-atendimento, etc.
Montagem com Componentes
O KDE possui uma API que permite que uma aplicação utilize os recursos de outra. Esta API é a KParts. Quem der uma olhada no KDE, verá que a ênfase é muito grande na utilização da orientação a objetos. Por isso, as aplicações tendem a colocar funcionalidades em objetos “isolados”. Uma aplicação pode, então, disponibilizar este objeto e, conseqüentemente, suas funcionalidades, para outras aplicações.
Quando um objeto é disponibilizado com o uso da KParts, este passa a ser um componente do KDE. Esta arquitetura de componentes faz com que seja possível criarmos um navegador web apenas utilizando partes de outros programas.
Poderemos criar uma KPart futuramente em nosso navegador, mas por enquanto, vamos utilizar a API KParts apenas do ponto de vista da aplicação cliente, ou seja, vamos usar uma KPart de outra aplicação: no caso a KHTMLPart.
Para usar uma parte, procedemos da mesma maneira como se fôssemos utilizar widgets normais, pois a KParts faz com que os componentes ajam como tais.
O trecho a seguir inicializa uma KHTMLPart para a nossa aplicação.
m_html = new KHTMLPart(this, “khtml”);
m_html->widget()->setFocusPolicy(WheelFocus);
m_html->setPluginsEnabled(true);
m_html->setJScriptEnabled(true);
m_html->setJavaEnabled(true);
m_html->setMetaRefreshEnabled(true);
m_html->widget()->resize(width()-16, height()-110);
m_html->setURLCursor(KCursor::handCursor());
connect(m_html->browserExtension(),
SIGNAL(openURLRequest(const KURL &, const KParts::URLArgs &)),this,
SLOT(slotUrlOpen(const KURL &, const KParts::URLArgs &)));
connect(m_html, SIGNAL(setWindowCaption(const QString&)),
this, SLOT(slotSetTitle(const QString&)));
connect(m_html, SIGNAL(setStatusBarText(const QString&)),
this, SLOT(slotOnURL(const QString&)));
Antes de mais nada, deixe-me dizer que muito deste trecho não é necessário, pois algumas opções são padrão e foram incluídas apenas para mostrar possibilidades.
A primeira parte do código inicializa a variável m_html com o recém criado objeto KHTMLPart e indica que a parte deve estar preparada para responder às requisições de um wheel mouse (aqueles de rodinha).
A parte intermediária especifica diversas opções para a parte HTML. Entre elas, que o componente deverá aceitar JavaScript, plugins e applets Java. Em alguns casos pode ser útil desativar estas opções como, por exemplo, no caso de aplicações quiosque.
E, por fim, conectamos alguns sinais para abrir uma nova URL, especificar o texto de título da janela e barra de status. Com isso, nossa aplicação já é capaz de renderizar páginas da web. A figura 1 mostra nossa aplicação renderizando a página da Revista do Linux.
Para encurtar, a chave do uso da KHTMLPart no nosso browser é o sinal openURLRequest que conectamos ao slot slotUrlOpen. Quando o usuário escolhe uma nova URL na opção “Open”, esta chama “manualmente” o método openURL para abrir a nova localização. Até aí tudo simples. A confusão começará quando o usuário clicar em um link da página. Por padrão, a KHTMLPart não segue links quando clicados. Isto é muito útil novamente para as aplicações quiosque, pois por padrão o componente fica preso em um local. Para podermos seguir os links, precisamos conectar o sinal openURLRequest, que é emitido sempre que uma nova URL é requisitada pelo próprio componente. Desse modo, quando o usuário clicar em um link, a função slotUrlOpen é chamada. Esta função não poderia ser mais simples:
void KrdlgatorView::slotUrlOpen(const KURL &url, const KParts::URLArgs &urlargs){
// abre a url solicitada
openURL( url );
}
Deu para perceber que usar os componentes do KDE é algo extremamente simples, sem praticamente nada diferente de usar um widget normal. O uso de KParts pode se tornar mais complexo quando se cria uma aplicação que pode usar mais de uma KPart simultaneamente. Um exemplo de aplicação deste tipo são as aplicações do KOffice que podem conter várias KParts embutidas em seus documentos (um documento do KWord com duas planilhas do KSpread embutidas, por exemplo). Porém, em 90% dos casos o uso de KParts é um simples ato de manusear um único componente como se fosse um único widget.
Insistindo mais um pouco em um assunto que pode ou não interessar a muita gente, as aplicações de quiosque estão ficando cada vez mais populares no Brasil, e muitos estão procurando o Linux para isso, devido à maior estabilidade (não sei quanto a vocês, mas eu odeio chegar a um terminal de auto-atendimento e ver aquelas mensagens de “general protection fault”) e ao baixo preço de implantação. O uso da KHTMLPart é bem indicado para este tipo de aplicação, já que ele foi desenvolvido com isto em mente desde o início. Além da KHTMLPart, outra coisa que pode ajudar muito os desenvolvedores é o mecanismo de DCOP que veremos a seguir.
Controle Remoto
Muitas vezes, é interessante que uma aplicação possa ser controlada externamente. Um caso típico (e que se aplica ao nosso exemplo) é fazer com que o browser abra uma URL específica. Isso pode ser útil para quiosques (novamente) que vendem espaços publicitários, por exemplo, já que o conteúdo do espaço pode ser alterado remotamente para todas as aplicações sem necessidade de reiniciar nada.
O KDE possibilita isso com o uso do Desktop Communication Protocol, ou simplesmente DCOP. Para usar o DCOP, uma aplicação deve fazer duas coisas: registrar-se com o servidor DCOP e criar uma interface a ser exportada. Isto é extremamente fácil de fazer. A primeira parte (o registro) é feito pela seguinte chamada:
app.dcopClient()->registerAs(app.name());
A segunda parte (a interface) é quase tão simples, envolvendo apenas a criação de uma classe abstrata herdando DCOPObject. Mais tarde, alguma classe que venha a ser exportada deverá herdar esta interface e implementar os métodos desejados.
Sendo assim, nosso browser disponibilizará um método para que uma aplicação ou um usuário mude a URL corrente do browser. Para isso, além de termos registrado a aplicação com o servidor DCOP, nós criamos a classe KrdlgatorIface (ela é tão pequena que o arquivo inteiro pode ser incluído aqui):
#ifndef KRDLGATORIFACE_H
#define KRDLGATORIFACE_H
#include <dcopobject.h>
class KrdlgatorIface : virtual public DCOPObject
{
K_DCOP
public:
k_dcop:
virtual void openURL(QString url) = 0;
};
#endif // KRDLGATORIFACE_H
Tudo nesta classe é simples cut & paste. A única coisa que o programador cria são as declarações dos métodos desejados logo após k_dcop:. No nosso caso, vamos ter apenas um método chamado openURL.
A implementação destes métodos é feita nas classes que herdam KrdlgatorIface. No caso trata-se da classe KrdlgatorView onde a função openURL está. Não há absolutamente nada de diferente nesta função. Tudo é feito transparentemente.
A partir de agora, outras aplicações poderão conectar-se ao nosso browser e solicitar a troca de URL. Pode-se também utilizar o utilitário kdcop para controlar o nosso programa. Para testar, inicialize o browser e use o kdcop para visualizar as interfaces do Krdlgator como visto na figura 2. Você pode selecionar o método openURL e pressionar Executar para chamar o método (o programa irá solicitar a URL desejada).
Além do kdcop, pode-se usar o utilitário de linha de comando dcop. Este é muito útil para shell scripts. Digitando apenas dcop resultará numa lista de todos os objetos disponíveis. Digitando também o nome do objeto poderemos ver a lista de métodos disponíveis naquele objeto. Podemos, por exemplo, ver a lista de métodos do krdlgator da seguinte forma:
< dcop krdlgator
qt
Krdlgator
KrdlgatorIface
MainApplication-Interface
ksycoca
< dcop krdlgator KrdlgatorIface
QCStringList interfaces()
QCStringList functions()
void openURL(QString url)
Como se pode ver, além da interface criada por nós, várias outras interfaces são disponibilizadas automaticamente pela Qt e pelas diversas APIs do KDE. Mas antes de vermos o que estas interfaces podem oferecer, vamos usar nossa própria interface para mudar a URL do browser:
%lt; dcop krdlgator KrdlgatoIface openURL http://www.kde.org
As outras interfaces contêm alguns métodos padrão para a maioria das aplicações. Por curiosidade, veja os métodos disponibilizados pela interface Krdlgator no kdcop como na figura 3. Não dá para mostrar todos os métodos em uma só tela, já que são, nada mais, nada menos, que 126 métodos! Eles envolvem muita coisa como posicionamento na tela, tamanho da janela, estado (maximizado, minimizado...) entre dezenas de outras possibilidades. Vale a pena dedicar um pouco de tempo para conhecer tudo o que pode ser controlado remotamente.
Para uma aplicação chamar um método de outra, ela deve usar um QDataStream e chamar a função DCOPClient::send(). Antes de fazer isso, porém, ela deve registrar um cliente DCOP da seguinte forma:
DCOPClient *client = kapp->dcopClient();
bool done = client->attach();
Feito isto, a aplicação já pode se conectar com outra:
QByteArray data;
QDataStream arg( data, IO_WriteOnly );
QString url = “http://developer.kde.org”;
arg << url;
client->send( “krdlgator”,
“KrdlgatoIface”,
“openURL(QString)”,
data));
O DCOP permite que uma aplicação controle outra, além de permitir o controle a partir de um simples shell script. É também possível controlar uma aplicação a partir de uma outra máquina pela rede, bastando que se exporte o DISPLAY desejado (e aquele tenha permissões corretas).
Próximo mês
Com o uso de interfaces DCOP e as Kparts, é possível desenvolver aplicações de quiosque bastante interessantes. Aos muitos desenvolvedores deste tipo de aplicação: vale a pena conhecer o que o KDE oferece neste sentido.
Mês que vem vamos expandir o browser com personalização e vamos melhorar a aparência dos diálogos e conhecer um pouco dos diálogos padrão do KDE.
Roberto Teixeira -
