Ir ao conteúdo
  • Cadastre-se

Interface gráfica Eclipse Helios


andisu

Posts recomendados

Olá, eu sou novato no Eclipse, sempre usei o netbeans, me disseram que no eclipse o código fica mais limpo e tal... Eu prefiro o eclipse para rodar programas e tudo a facilidade é maior, porém não tenho a mínima ideia de como programar interfaces nele, e nem Java ME que são as duas coisas de que mais preciso... Tentei instalar o Visual Editor mas no Eclipse Helios que é a nova versão ele não instala, parece que ele foi descontinuado. O que preciso i1nstalar para conseguir programar Java ME e interfaces gráficas?

Obrigado!!!

Link para o comentário
Compartilhar em outros sites

Olá, realmente a versão atual do Visual Editor não está rodando no Eclipse Helios, pelo menos eu não consegui instalar de jeito nenhum... porém encontrei esse link (http://www.eclipse.org/projects/project-plan.php?projectid=tools.ve) do projeto Visual Editor inclusive com datas programadas de lançamento de versões... mas não há nada para download... se alguém souber de algo e puder postar.

Obs.: a versão 1.4 do VE roda perfeitamente no Eclipse Galileu, eu tenho as duas versões do Eclipse instaladas, uso o Helios para Aplicações Web e o Galileu para Aplicações de interface gráfica tradicional.

Link para o comentário
Compartilhar em outros sites

Recomendo a voltar a usar o NetBeeans. Nunca mude de ferramenta porque DIZEM.

O NetBeeans não suja código nenhum. Ele gera código. O código que o NetBeeans usa para produzir interfaces por exemplo sempre vai parecer sujo. Porque foi o que a Sun criou na API do Java para os construtores de GUI usarem.

Link para o comentário
Compartilhar em outros sites

Algumas coisas que temos que compreender quando queremos trabalhar com as interfaces em Java (Lembrar que Interfaces em Java não tem nada a ver com Interface Gráfica de Usuário ou GUI. Aqui estamos a falar de GUI) são os painéis raiz (root panels). Os painéis raiz são os contentores máximos que podem formar janelas. Dentro deles podemos ter vários outros tipos de contentores (painéis) e dentro dos mesmos contentores, vários tipos de controles.

Aí nasce o problema. Em Java, a posição dos controles não é definida por coordenadas mas por critérios bem definidos chamados Layout Manangers. E aí vão alguns:

Box Layout.

Grid Layout.

GridBag Layout.

Card Layout.

Flow Layout.

Border Layout.

GridBag Layout.

Group Layout.

Este último foi desenvolvido exactamente para ser usado por construtores. Ora, seu código parece meio sujo mais é preciso. Aliás, mesmo manualmente se pode programar interfaces usando o Group Layout.

Não é uma questão de sujidade. É uma questão de escrever em código o que desenhamos na tela. Se tentarmos escrever manualmente uma vez entenderemos como pode levar linhas e linhas de código.

Tudo o que pensamos fazer de modo visual tem de ser escrito em código no fundo de tudo!

Link para o comentário
Compartilhar em outros sites

Um último exemplo do que pode parecer sujar código.

Criamos um formulário no NetBeeans e arrastamos um JButton para ele. Clicamos com o lado direito, vamos para os eventos e adicionamos um evento ActionPerfomed por exemplo.

Parece simples não?

Mas não é.

Primeiro a variável tem que ser declarada, inicializada, devemos definir o texto que irá mostrar (mesmo que seja aquele que vem escrito por padrão). Precisamos, por meio de código, definir seus tamanhos preferidos e o lugar em que se vai localizar, o que é outra história.

Como se isso não bastasse precisamos entender um novo conceito. O de auscultadores de eventos. Um objecto auscultador de eventos é exactamente o que o seu nome diz. Mas ele não é um objecto comum. Em Java temos classes, classes abstractas e interfaces. Porque no Java não há herança múltipla, uma classe só pode herdar de uma outra e nunca de duas outras. Para solucionar isso surgem as interfaces. Ora, diferentemente das classes, as interfaces só definem os métodos e cabe as classes que as vão implementar implementar todos seus métodos. As classe abstractas são uma espécie de mistura entre interfaces e classes.

Significa que se por exemplo criamos um evento ActionPerfomed, no fundo temos de criar uma classe qualquer que implemente ActionEvent e nela implementar todos os métodos (que neste caso é um só) de ActionEvent, criar um objecto dessa classe e dar ao botão de comandos como parâmetro por via do método .addActionListener().

O que o NetBeeans vai fazer é criar um método xxxActionPerfomed... e colocar uma chamada ao método dentro do método ActionPerfomed da classe que criou.

Quanta salada...

Link para o comentário
Compartilhar em outros sites

Numa situação como essa, acho que o código é bom. Mas a situação em si já é complexa.

Envolve muita cosa. Não falei de figuras, de Borders... e tudo mais.

E para completar, o NetBeans tem sua API também para facilitar as tarefas que muitas vezes incorpora ao nosso código.

No entanto, se criamos uma classe simples. O código é simples também.

Aconselho a voltar a usar o NetBeeans. Pode usar os dois em simultâneo.

Link para o comentário
Compartilhar em outros sites

Arquivado

Este tópico foi arquivado e está fechado para novas respostas.

Sobre o Clube do Hardware

No ar desde 1996, o Clube do Hardware é uma das maiores, mais antigas e mais respeitadas comunidades sobre tecnologia do Brasil. Leia mais

Direitos autorais

Não permitimos a cópia ou reprodução do conteúdo do nosso site, fórum, newsletters e redes sociais, mesmo citando-se a fonte. Leia mais

×
×
  • Criar novo...

 

GRÁTIS: ebook Redes Wi-Fi – 2ª Edição

EBOOK GRÁTIS!

CLIQUE AQUI E BAIXE AGORA MESMO!