Resolvendo problemas de acentuação no Texmaker no Ubuntu 11.10

5 Comentários

acentuação tex

Após iniciar meu mestrado,  fui “obrigado” pelo meu orientador a utilizar o Tex/LaTeX para edição/confecção de documentos e apresentações. No começo achei ruim, mas hoje agradeço por conhecer e utilizar essa ferramenta fantástica.

Após uma procurar por aplicativos que me auxiliassem na edição desses arquivos, encontrei o Texmaker. Basicamente ele um aplicativo multiplataforma (Windows, MacOS e Linux) que possui, entre outras funcionalidades, suporte a  unicode, corretor ortográfico, auto-complete, um visualizador de pdf embutido, assistentes para geração de tabelas, figuras, etc. Além disso ele é um projeto open-source (GPL) e está disponível nos repositórios oficiais do Ubuntu.

Os problemas de acentuação começaram a aparecer no Texmaker após a atualização do meu sistema Ubuntu da versão 11.04 para a 11.10. Após algum tempo editando um documento, o editor simplesmente não colocava os acentos no locais corretos. Um exemplo corriqueiro do problema aparecia na hora de digitar a palavra não. O editor simplesmesmente trocava a grafia correta dessa palavra por na~o. Para contornar esse problema era necessário reiniciar o aplicativo. Mesmo após algumas atualizações pelo Update-Manager o problema persistia.

Após algumas buscas no Google, descobri que esse problema ocorria devido a falta de uma biblioteca qt, a  ibus-qt4. Para instalá-la e solucionar esse problema de vez basta digitar o comando abaixo no terminal:

sudo apt-get install ibus-qt4

Para que estiver interessado em outros editores Tex/LaTeX, um bom comparativo pode ser visto aqui.

Anúncios

Problemas com o corretor ortográfico do LibreOffice

1 Comentário

Olá pessoal,

depois de um bom tempo sem postar nada (acho que mais de 1 ano) devido ao aperreio que passei no primeiro ano do mestrado, acho que, enfim, voltei :).

Depois de uns 8 meses usando apenas o LaTex para confecção de meus trabalhos/apresentações/relatórios (altamente recomendado para isso), fui obrigado a utilizar um pacote office para redigir minha proposta de dissertação, já que o modelo da mesma é disponibilizado apenas em um arquivo .doc, e encontrei um probleminha meio chato: o corretor ortográfico funcionava apenas para a língua inglesa.

Depois de algumas buscas no google sem sucesso e correções feitas pelo meu orientador, descobri a dica de como corrigir esse problema no Ubuntu Fórum, mais precisamente através da dica do cesargcomp que pode ser encontrada aqui.

Para correção do problema você terá que baixar três extensões para o LibreOffice (que também servem para o OpenOffice). São elas:

  • VERO: Corretor ortográfico que já com o novo acordo ortográfico feito entre os países de língua portuguesa. Pode ser baixado no seguinte link: http://www.broffice.org/verortografico/baixar. Baixe o arquivo Vero_pt_BR_VersaoAtualAOC.oxt, onde VersaoAtual é substituído pelo número da versão recente extensão.
  • DicSin: Dicionário de sinônimos para o LibreOffice. Para obtê-lo, visite: http://www.dicsin.com.br/content/download.php.
  • CoGrOO: corretor em nível sintático (colocação pronominal, . Também pode ser utilizado como corretor gramatical, mas o próprio site do projeto é aconselha o uso do VERO para essa finalidade. A última versão do CoGrOO pode ser encontrada aqui.
Após baixar os três arquivos, abra o LibreOffice. Na barra de  menus, vá em Ferramentas -> Gerenciador de extensões (ver Figura 1).
Figura 1

Figura 1

Uma nova janela irá abrir e nela clique no botão Adicionar… o selecione os arquivos baixados anteriormente. Reinicie o LibreOffice e vá em  Ferramentas-> Opções. Na janela de Opções vá em Configurações de Idioma -> Idioma e mude o idioma padrão para Português (Brasil), como na Figura 2.

Figura 2

Figura 2

Caso tenha qualquer dúvida, fique a vontade para postá-la nos comentários.

Retornando à atividade

1 Comentário

Garfield Wakening

Depois de um longo tempo longe (do blogo) estou retornando. Minha longa ausência foi devido a diversos fatores como TCC, pesquisas, estágios, etc.

Vou ministrar um mini-curso sobre desenvolvimento de aplicativos para Android no final do próximo mês e decidi fazer uma série de posts sobre o assunto. Espero que aproveitem.

Componentes Visuais CLDC – parte 3

Deixe um comentário

foto-topo-imagens

Agora irei falar sobre algo que deixará os nossos MIDlets com um pouco mais de vida: Imagens. Imagens são algo indispensável para aplicativos sejam eles para Desktop, Web ou mobile.

Em Java ME existem duas formas de se trabalhar com images:

  • Criando imagens diretamente no MIDlet (no braço!)
  • Utilizar imagens como um recurso

Nesse post não irei trabalhar com a primeira opção, então iremos utilizar imagens já criadas por outros aplicativos.

A primeira coisa que precisamos é de uma imagem. Para isso, pegue uma imagem qualquer, de preferência .PNG como está estabelecido na documentação oficial, e coloque dentro da pasta res que está dentro da árvore de diretórios de seu projeto no Eclipse – ver figura abaixo.

Pasta res

Pasta res

Para fazer isso basta copiar e colar a imagem dentro da pasta.

Agora crie um MIDlet com o nome de ExampleImage. Adicione um Display, um Form e um novo atributo do tipo Image. Faça tudo como nos outros posts. O código completo pode ser visto abaixo.

import java.io.IOException;

import javax.microedition.lcdui.Display;
import javax.microedition.lcdui.Form;
import javax.microedition.lcdui.Image;
import javax.microedition.midlet.MIDlet;
import javax.microedition.midlet.MIDletStateChangeException;

public class ImageExample extends MIDlet
{

	private Display display;
	private Form myForm;
	private Image img;

	public ImageExample()
	{
		display = Display.getDisplay(this);
		myForm = new Form("Image Example");

		// Para criar uma imagem temos que realizar uma operação de
		// I/O, por isso a necessidade de um bloco try...catch
		try
		{
			// Aqui nós pedimos um recurso, nesse caso uma imagem
			img = Image.createImage("/img01.png");
		}
		catch (IOException e)
		{
			e.printStackTrace();
		}

		// Como Image extende Item utilizamos um simples append() em myForm
		myForm.append(img);
	}

	protected void destroyApp(boolean arg0) throws MIDletStateChangeException
	{
		// nada aqui ainda...
	}

	protected void pauseApp()
	{
		// nada aqui ainda...
	}

	protected void startApp() throws MIDletStateChangeException
	{
		display.setCurrent(myForm);
	}

}

Rode o exemplo e voilá, temos um MIDlet que apresenta uma imagem.

ExampleImage em ação

ExampleImage em ação

Agora vamos as explicações de como conseguirmos nossa imagem.

A primeira diferença que você pode ter percebido foi a necessidade de um bloco try…catch quando “criamos” nossa imagem. Ele é necessário pois estamos realizando uma operação de I/O (entrada/saída) e todo tipo de operação que possa dar errado precisa ser envolvida por um bloco try…catch (Java ME ainda é Java 😉 ).

A segunda diferença é que nós realmente não “criamos” uma imagem. Não usamos um construtor padrão como em Form, mas obtemos nossa imagem a partir de um método estático da classe Image, Image.createImage(String name), onde a String representa o caminho completo para a nossa imagem, com a extensão e tudo. Como exemplo, olhe o trecho de código abaixo:

img = Image.createImage("/img01.png");

Podemos perceber que a nossa imagem está dentro na raiz de res, por isso usamos ‘/’ + ‘nome completo do arquivo’. Se nossa imagem estivesse em outras pasta dentro de res teríamos que colocar o caminho completo para a imagem. Caso movêssemos nossa imagem para dentro de outra pasta, por exemplo ‘imgs’ (ainda dentro de res pois uma imagem é um recurso e todo recurso deve estar dentro dessa pasta) o código para obter a nossa imagem ficaria assim:

img = Image.createImage("/imgs/img01.png");
Imagem dentro de uma subpasta de RES

Imagem dentro de uma subpasta de RES

Agora é com vocês. Tentem utilizar imagens da forma como fiz aqui ou utilizando um dos outros método estáticos disponíveis. Uma outra coisa legal é utilizar imagens com a classe ChoiceGroup.

Até a próxima!

Entendo Sistemas Operacionais – parte 3

Deixe um comentário

Introdução

Esta é a terceira e última parte do artigo Entendo Sistemas Operacionais, que foi dividida em 3 partes. Sugiro a leitura das duas outras partes, Entendo Sistemas Operacionais parte 1 e Entendo Sistemas Operacionais parte 2. Nesta parte falarei um pouco sobre o kernel de um sistema operacional e como geralmente ele pode ser estruturado.

Como visto na primeira parte deste artigo, o kernel é a definição mais aceita sobre o que seria um sistema operacional e nada mais justo do quê dedicar uma parte inteira do artigo para falar sobre ele.

Segundo [1], o kernel é o programa de sistemas mais importante e mais íntimo do hardware (para saber o que é um programa de sistema leia a parte 1 deste artigo). Ele geralmente é escrito em linguagens de montagem como Assembly ou linguagens de sistema, como C ou C++. Ele é constituído de uma série de módulos bem definidos, com entradas, saídas e funções bem definidas.

Serão apresentados os três modelos mais comuns de como o kernel do sistema operacional pode ser estruturado. Segundo [2], a divisão entre esses três modelos não quer dizer que eles sejam exclusivos, podendo surgir casos que eles são complementares, como é o caso do Microsoft Windows NT, que usa uma estrutura híbrida.

1. Estrutura Simples ou Kernel monolítico

É a estrutura mais usada em sistemas operacionais. Segundo [1], a estrutura é tal que não existe qualquer estrutura. O sistema operacional é escrito como uma coleção de procedimentos, e um procedimento pode chamar outro sempre que sentir necessidade.

Estes sistemas começaram bastante simples e pequenos, depois cresceram além do seu escopo original. Exemplos de sistemas que passaram por isso foram o MS-DOS e o UNIX.

No início de seu desenvolvimento, o UNIX foi bastante limitado pelas funcionalidades do hardware. Mesmo utilizando a estrutura de kernel monolítico, o UNIX conseguiu evoluir com o passar dos anos, devido principalmente a evolução do hardware, o que tornou o desenvolvimento desse sistema operacional mais fácil, pois ele pode ser divido em peças menores, o que aumentou o seu controle sobre o sistema computacional de uma forma geral. Exemplos destas mudanças podem ser observadas no Linux e outros sistemas UNIX-like.

Um fato interessante, foi o debate que ocorreu entre um dos autores de [1], Tanenbaum, e o desenvolvedor do kernel do Linux, Linus Torvalds, ocorrida em 1992. O debate ocorreu pelo fato de Linus ter resolvido usar a estrutura de kernel monolítico para desenvolver o Linux, estrutura a qual Tanenbaum era totalmente contrário, pois defendia a estrutura de camadas Toda a discussão pode ser vista aqui.

Em [2], podemos encontrar uma boa descrição de como o kernel do UNIX era estruturado e como possivelmente a maiorias dos kernels que utilizam esta estrutura também eram: “O kernel é constituído de uma série de interfaces e drivers de dispositivos, que foram adicionados e expandidos ao longo dos anos em que o UNIX evoluiu. […] Tudo o que está abaixo da interface de chamada de sistema e acima do hardware físico é o kernel. O kernel fornece o sistema de arquivos, o scheduling da CPU, o gerenciamente de memória e outras funções do sistema operacional até as chamadas de sistema. Tudo somado, trata-se de um enorme montante de funcionalidades combinadas em um único nível.”

2. Estrutura em camadas

Nesta estrutura, o sistema operacional é divido em número x de camadas, onde cada uma delas oferece serviços bem definidos à camada superior. A camada de nível mais baixo (camada 0) representa o hardware e a camada mais alta representa os programas aplicativos.

Segundo [3], “cada camada é uma espécie de máquina virtual, oferecendo determinados serviços à camada situada acima dela .” Essa estrutura tenta reduzir a complexidade do projeto, onde uma camada não sabe como as outras realmente funcionam, tendo que somente usar funções e serviços das camadas de nível mais baixo.

A principal vantagem da abordagem em camadas, segundo [2], é alta modularidade conseguida. Além disso, este enfoque simplifica a depuração e a verificação do sistema. Caso aconteça algum erro durante a depuração de uma camada em particular, o erro deve estar nesta camada, pois as camadas abaixo dela já estarão depuradas, o que proporciona uma maior segurança aos projetistas ao realizar modificações no sistema.

O primeiro sistema operacional a implementar esta estrutura foi o THE, construído por E. W. Dijkstra e seus alunos no Technische Hogeschool Eindhoven, na Holanda em 1968. A sua estrutura pode ser verificada na figura abaixo:

Sistema em camadas THE
Sistema em camadas THE

Embora o enfoque em camadas apresente algumas vantagens sobre os sistemas baseados em kernels monolíticos, os sistemas comerciais não utilizam esta estrutura (pelo menos por completo) porque ela apresenta algumas dificuldades. As principais são:

  • uma vez definida uma camada, ela só poderá enxergar as camadas que estão abaixo dela. Como definir cada uma das camadas sem causar inconsistências?
  • este tipo de estrutura tende a ser menos eficiente do que outras opções, como kernel monolítico (já discutidos) e microkernels (discutido adiante), pois cada camada gera overhead ao funcionamento do sistema. Como já visto anteriormente, os usuários utilizam programas aplicativos e talvez eles não tenham muita paciência para esperar por um programa que não faz nada por eles de forma direta.

Devido a estas limitações, algumas abordagens foram adotadas para contorná-las como usar um número reduzido de camadas com mais funcionalidades ou usar estruturas híbridas.

3. Microkernels

Está técnica tem uma abordagem simples de ser entendida: remova tudo o que não for essencial ao kernel e implemente como programas de sistema e de usuário. O resultado é um kernel menor. Segundo [2], “os microkernels provêem, em geral, gerenciamento de processos e de memória mínimos, adicionalmente a facilidades de comunicação”.

A principal função do microkernel, segundo [2], é proprocionar facilidade de comunicação entre o programa cliente e os diversos serviços que estão também operando no espaço do usuário. A comunicação é feita através de troca de mensagens, que será demonstrada através de um simples exemplo. Imagine que você quer abrir um arquivo através de um editor de texto. Para isso ele deve “conversar” com o servidor de arquivos, através da troca de mensagens entre eles. No enfoque de microkernel o programa cliente e o serviço nunca interagem diretamente. Então como eles vão “conversar”?

A tal conversa acontece da seguinte forma:

  1. O programa usuário diz ao microkernel que necessita de um determinado arquivo;

  2. o microkernel verifica se os parâmetros passados a ele são válidos e então, se forem, repassa estes parâmetros para o servidor de arquivos;

  3. o servidor de arquivos vai atrás do arquivo e repassa-os para o microkernel;

  4. o microkernel repassa o arquivo para o programa aplicativo.

Como pode ser observado, os programas se comunicam inderetamente trocando mensagens com o microkernel.

Outros benefícios que os microkernels oferecem são:

  • facilidade de expandir o sistema operacional, pois os novos serviços são adicionados ao espaço do usuário não exigindo modificações no kernel;
  • facilidade de manutenção do sistema, pois as mudanças tendem a ser menores porque o kernel é mínimo;
  • aumento de segurança e confiabilidade, já que a maioria dos serviços opera em processos usuário e, caso algum processo falhar, o resto do sistema continuará operando.

Diversos sistemas operacionais contemporâneos tem usado o enfoque de microkernel e estes sistemas estão onde menos esperamos, como em nossos celulares (Symbian), nos roteadores da Cisco e outros sistemas industriais e embarcados com o QNX.

Recomendo a leitura do artigo abaixo escrito pelo próprio Tanenbaum que trata da importância dos microkernels:

http://www.linuxnewmedia.com.br/materia/tanenbaum_por_que_os_computadores_nao_funcionam_sem_parar

Conclusão

O projeto de um sistema operacional é algo bastante complexo, onde vários aspectos devem ser levados em conta. Um dos aspectos principais diz respeito a estrutura interna do sistema, ou do kernel do sistema para ser exato.

A estrutura dos sistemas operacionais seguem geralmente três enfoques, kernel monolítico, camadas ou microkernel. Por serem enfoques diferentes não quer dizer que possam ser exclusivos, ou seja, sistemas operacionais podem apresentar uma mescla de dois destes enfoques ou variações destes. Cada enfoque tem suas vantagens e desvantagens,

O enfoque dos microkenerls tem ganhado cada vez mais força devido a sua alta modularidade, segurança e facilidades de expansão e manutenção. O enfoque de kernel monolítico é ainda o mais utilizados nos sistemas operacionais, devido a questões históricas de evolução do hardware e da necessidade que os sistemas computacionais tem de sistemas operacionais.

Espero que todos tenham gostado dessa pequena introdução a sistemas operacionais. Foram deixados muitos tópicos de lada, com chamadas de sistemas, threads e muitos outros serviços oferecidos por estes sistemas, pois o objetivo era mostrar de forma rápida a importância destes complexos sistemas que utilizamos todos os dias e nem paramos para pensar como eles funcionam (já que essa é a principal função deles).

Para os que se interessaram por essa área, sugiro a leitura das referências dos artigos, principalmente do livro de SILBERSCHATZ, GALVIN, GAGNE, referência [2] deste artigo.

REFERÊNCIAS:

[1] Andrew S. Tanenbaum & Albert S. Woodhull, Sistemas Operacionais: Projeto e Implementação – 2ª edição. Bookman, 2000.

[2] Abraham Silberschatz et al. Fundamentos de Sistemas Operacionais – 6ª edição, Livros Técnicos e Científicos (LTC), 2004.

[3] Andrew S. Tanenbaum, Computer Networks – 4ª edição, Campus.