Interfaces gráficas e os aplicativos Linux

Muitos utilitários e ferramentas do Tux encontram-se disponíveis na linha de comando: decodificadores, compactadores, editores, etc. Porém, por mais poderosas e práticas que sejam, certas atividades não são muito amigáveis para serem feitas através do terminal. Por exemplo, converter um filme no formato MPEG para SVCD com o VCDImager e queimá-lo numa mídia através do cdrecord não seriam tarefas tão intuitivas assim para serem feitas “na ponta dos dedos”. Felizmente, para estas necessidades, existem as interfaces gráficas…

Splash-screen do K3b, obtido da versão 1.0.5.

No Windows, estamos habituado a ver os programas como um todo: por exemplo, um descompactador de arquivos é apenas um aplicativo com todas as funções embutidas em seu corpo: a interface gráfica, as rotinas do programa, as bibliotecas e os filtros de conversão (codecs). Isto acontece devido a natureza do licenciamento: diferente dos programas livres, os proprietários não compartilham códigos; por isso, os seus desenvolvedores têm que praticamente “fazer de tudo”. No Tux, as aplicações não só compartilham o código-fonte livres, como também utilizam o motor do programa. Muitos desenvolvedores até deixam de implementar as rotinas do motor para desenvolver apenas interfaces gráficas.

Um fronted – ou do português interface gráfica (embora não seja um termo exato) – é nada mais que uma camada de software que funciona acima da engine (ou motor) do programa, disponibilizando suas funcionalidades através de uma interface gráfica desenvolvida para este propósito. Por exemplo, se quisermos assistir um filme DVD, poderíamos fazer isto com o motor do aplicativo apropriado (MPlayer ou Xine) na linha de comando; porém, seríamos obrigado a utilizar teclas de atalho, o que não seria tão intuitivo (embora a maioria das aplicações já tragam a sua interface oficial).

Um belo e clássico exemplo está no K3b, considerada a melhor aplicação multimídia para a criação, manipulação e gravação de imagens ISO em mídias de CD/DVD. Porém, por mais incrível e sofisticado que possa ser, o K3b é – à grosso modo – apenas uma interface gráfica, pois ele depende essencialmente de uma série de ferramentas e bibliotecas são necessárias para ter à disposição, todas as funcionalidades oferecidas pelo K3b, como o cdrecorder, cdrdao, vcdimager e monkeyaudioplugins, entre outros. Além disso, ainda há as bibliotecas do KDE, onde sem este último, não haveria como executar o K3b.

Então, qual seriam as vantagens de se ter diferentes pacotes – e toda aquela complicação de gerenciamento de pendências – para compor as funcionalidades completas de um programa? Felizmente muitas…

Como havia dito, os desenvolvedores não precisam “reinventar a roda”: Ao invés de criarem todo o programa e a “parte chata” da interface gráfica, podem se dedicar a escrever apenas o código necessário para construir as rotinas essenciais da aplicação (chamada também de bibliotecas ou motor principal). O trabalho de desenvolver uma interface gráfica poderá ficar a cargo de outros membros da equipe, voluntários ou até mesmo projetos interessados com certas aptidões (designers, por exemplo).

O mesmo se dá para a criação de interfaces gráfica: em vez de gastar horas em codificações complexas e altamente estressantes, o desenvolvedor poderá utilizar as suas habilidades artísticas e percepções humanas para criar verdadeiras obras de arte, com o intuito de facilitar a interação daqueles usuários menos habituados a terrível “tela preta”.

Para os grandes projetos de ambientes gráficos como o KDE e o GNOME (e até mesmo o Xfce), temos ainda a possibilidade de ter integrado à eles, a tecnologia de diversas aplicações, porém com o diferencial destas não serem vistas pelos seus usuários como recursos “alienígenas”, pois ao mesmo tempo em que suas funcionalidades são integradas, o visual das interfaces passa a ser mais belo, consistente e unificado!

A manutenção e atualização destas aplicações – tanto o motor quanto o da interface (entre outras bibliotecas e pendência) – torna-se também bastante interessante em virtude dos aspectos relacionados à segurança: a aplicação das correções e das atualizações torna-se mais amena e fluída se a realizarmos apenas nos pacotes que necessitam de intervenção. Isto também facilitará o seu update, pois nós só necessitaremos baixar o pacote atualizado, e não o programa inteiro. O mesmo vale para as suas bibliotecas e pendências.

Por último, ainda há maior flexibilização na escolha das opções…

No Windows, só poderemos optar entre a aplicação X, Y e Z mediante a uma avaliação global de seus recursos e funcionalidades, o que quer dizer que, por melhor que façamos nossas escolhas, isto não quer dizer necessáriamente que estaremos 100% satisfeito: em casos extremos, poderemos optar por uma aplicação que satisfaça nossas necessidades, mas que tenha uma interface confusa e de difícil assimilação; ou o inverso, um aplicação simples e fácil de usar, mas que peca na falta de recursos e flexibilidade. No máximo, poderemos customizar a interface através da aplicação de um tema ou ajustar suas opções de configuração conforme a necessidade; mas ainda assim, isto está muito longe da flexibilidade tão desejada. Nem vou comentar sobre o quesito desempenho…

Já no Tux, não só poderemos optar entre a aplicação X, Y e Z desejada, como também poderemos optar pelas interfaces disponíveis. Por exemplo, temos excelentes reprodutores multimídia como os já comentados Xine e MPlayer, que são dotados de diferentes interfaces gráficas, como as disponibilizadas pelo próprio projeto (Xine-UI e GMPlayer) e aquelas desenvolvidas por outros, como o Kaffeíne, o GXine e o Totem (para o Xine), e o SMPlayer e KPlayer (para o MPlayer). Das possibilidades, há até interfaces que podem suportar múltiplas engines: por exemplo, o KMPlayer suporta tanto o Xine quanto o MPlayer, além do GStreamer. Infelizmente, das interfaces existentes, a maioria são projetadas específicamente para um determinado ambiente gráfico, tal como são o Kaffeíne, o KPlayer e o KMPlayer (para o KDE) como o GXine, o Totem e o SMPlayer (para o GNOME). Mesmo assim, não há maiores dificuldades em se projetar diferentes interfaces para diferentes ambientas gráficos.

Então, ainda preferem aquele sistema proprietário, em que o licenciamento é obrigatório (e caro), vem “pelado” com nenhuma aplicação e ainda por cima, cada aplicação é uma grande caixa preta devoradora de RAM? Se sim, revejam seus conceitos… &;-D

Por Ednei Pacheco <ednei.pacheco [at] gmail.com>
http://by-darkstar.blogspot.com/