Legal mesmo mas acho que as m: Legal mesmo, a muito esperava por isso. Acho que as melhores indicações de links seriam:

http://monoblog.sl.org.br/blog/?p=89
http://primates.ximian.com/~lluis/blog/pivot/entry.php?id=47

MONO? : MONO?
Drogas estou fora!!!!!


MONO = MONO(PÓLIO).

Homosexualismo e Mono tem as: Homosexualismo e Mono tem as suas ideologias parecidas ...

Os dois tentam provar ao mundo que são uma coisa normal e que devemos aceita-lá.
Enganan-se os dois são oriundos de uma especie real, mas formal uma coisa que não pode ser classificada como algo correto ou verdadeiro.

Microsoft?: Me desculpe se estou sento (por estar sendo) idiota, mas é verdade que a micros**t está, de alguma forma, envolvida nisto? (mais uma vez peço desculpa pela pergunta)

Muito bom mesmo!: Muito bom mesmo! As coisas estão caminhando mais rápido do que eu imaginava. Esse IDE esta ficando fantástico e vai facilitar muito a adoção da plataforma.

Depende, quem criou a especif: Depende, quem criou a especificação da tecnologia foi ela. Mas o envolvimento vai até esse ponto.

Veja detalhes em:
Mono and Microsoft

Incrível..cheguei à uma con: Incrível..cheguei à uma conclusão..babaca nunca se identifica
É tão covarde que não tem coragem de colocar o nome real e/ou completo em suas "opiniões".

Além de tudo é analfabeto (homossexualismo com um s) e com princípios morais da era medieval.

Cássio R. Es_kelsen

Babacas anônimos??? : Babacas anônimos???
Fora desse site!!!

Quer criticar, critica, mas tenha a hombridade de se identificar.

Cássio R. Es_kelsen

P.S: sim, estou revoltado, principalmente contra esses moleques imberbes que não sabem o que estão falando.

MS: A MS também é responsável por barrar o povo do mono nas conferências.

Credo tecnlogia espeficada pe: Credo tecnlogia espeficada pela microsoft? que coisa horrivel.

Copiar logo a microsoft, é uma burrice extrema, onde vamos parar.

O mono é tão bom, mas tão: O mono é tão bom, mas tão bom, que o site do mono-br é feito com o mediawiki que é em php.


hauahauh comédia, nem eles mesmo têm coragem de usar esta joça.

Onde vamos parar se continuar: Onde vamos parar se continuarmos a julgar uma tecnologia/idéia apenas por quem a criou? ;-)

No ambiente Web não sei o es: No ambiente Web não sei o estado atual do mono, mas pelo menos no desktop têm aparecido aplicações interessantes, como o Tomboy, Banshee entre outros.

Especificação por especific: Especificação por especificação eu fico com o j2ee, pelo menos sei que a empresa por trás já ajudou com o mundo opensource, mesmo que com intenções obscuras, mas ajudou.

Alêm do j2ee ser milhões de vezes melhor.

Revoltado este menino !: O Cássio, vc tá com algum problema de prisão de ventre ? Qta revolta cara, que peso no coração ! Seja ABERTO a novas experiências... HUHAUHAUHAUHAUHAUHAUHAUHAUH !

Pior que a Microsoft é Imitar a Mesma: Cara este papo do Mono é a maior furada ! Usa PHP, usa Java, Perl que são livres (Java ainda com restrições) e vc não precisa pedir a benção ao Bill Gates... Sai dessa.

Porque? eu já babo nos ovos: Porque? eu já babo nos ovos do bill gates!!

Quer maior prova de amor que está ?


Cássio R. Es_kelsen

Porque usar estas outras tecn: Porque usar estas outras tecnologias mortas? com o advento do mono tudo se renovará.

Agora sim !: Pronto este acabou de sair do armário ! Vc baba no ovo direito ou esquerdo dele ? Ou prefere os dois ? Hein ? Hein ?

Evangelização: Rapaz eu adoro estes religiosos de software, isto prova que nasce um otário a cada 5 minutos. Eles adoram pregar para todos que sua tecnologia é melhor que a outra, tem argumentos como versículos de livros religiosos.

Será que isto é algum tipo de distúrbio ou anomalia de suas personas, ou será que querem ter uma razão para suas pobres vidinhas sem graça ?

AHAHAHAHAHAHAH ! É patético estes caras pregando para a patuléia em geral, precisando serem ouvidos para se sentirem importantes...

Nos dois, eu sou guloso! : Nos dois, eu sou guloso!


Cássio R. Es_kelsen

Caro, informe eu, atráveis d: Caro, informe eu, atráveis desta, que o linuxit, está avenda com o intuiro portifrolio.
O meu brog está zendo portaido para o, momo.



falou,


wrochal(@)linuxit.com.br

Os meus tbm !: Aproveita chupa meus ovos, mas não baba muito...

HUHAUHAUHAUHAUHAUHAUHAUHAUHAUHAHUAHAUHAH !

É ...: Como diria o mestre yoda supremo e excelentissimo Morimoto.

Aff, que comunidade perdida.

Tá tão perdida: E tão burra, que até hje tem muito otário trabalhando de graça pros outros. Eu mesmo já ganhei um monte de grana nas costas destes caras...

off topic geral: Richard "Strollman", com essa sua paixão louca e doentia pelo dinheiro, fico pensando quem realmente ganhou dinheiro nas costas de alguém.

Esse não sou eu!!!: É incrivel o cúmulo da mediocridade, a pessoa se sugeita a usar o nome dos outros para poder ser percebido.

Atos mediocres atingem pessoa: Atos mediocres atingem pessoas mediocres ...

O http://www.portaljava.com.b: O http://www.portaljava.com.br/ tb eh montado com php

br-linux deprimente: a chegada desse babaca "Stallman" baixou o nível geral desse site. Nunca vi tanta palhaçada e vontade de aparecer juntas...

que tal bani-lo, brain?

Quanto ao Glade e sua integração: ótimo. Mas daí a dizer que o Glade + monodevelop é semelhante ao Delphi já é um pouco demais. O Glade não é tão simples de usar quanto o Forms designer do Delphi, por várias razões:

* Layout Managers são muito úteis, mas na prática bem mais difíceis de se projetar telas do que sem eles;
* a interface não é tão ágil e bem integrada quanto a do Delphi, principalmente pelo fato de haver múltiplas janelas para os vários componentes da interface do programa, mas com poucas opções para se movimentar por eles via teclado. Talvez integrado ao monodevelop ajude...

Fora isso, fico imaginando porque é chamado Glade3, quando o programa ainda está na versão 2...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Quem sabe: Eu não tenho ganho até nas suas costas ???

Ahi Nemesis ARREGOU !: Posso ser banido, chutado, e detonado, mas eu volto com outro nome e a discussão fica boa de novo. Não aguentou ! chora ! FFFUUUIIII !

Pois é... aqui no Brasil é: Pois é... aqui no Brasil é assim, muita gente pra criticar e pouca gente para ajudar.

Essa versão que foi integrad: Essa versão que foi integrada ao MonoDevelop é o Glade 3 que está em desenvolvimento e tira vantagens das novas versões do GTk. Além disso o novo glade (Glade 3) trás um biblioteca pra integrá-lo a outros aplicativos.

Dá um olhada nesses links, um é a página com informações sobre o Glade 3 e a outro um screenshot do MonoDevelo com o plugin Glade:

http://glade.gnome.org/todo.html
http://primates.ximian.com/%7Elluis/images/imglade3.png

Olá, alguêm sabe o endereç: Olá, alguêm sabe o endereço de algum site ou sistema web desenvovlido em mono?
Fiquei curioso agora.

Obrigado

Desculpe nemesis, mas se têm: Desculpe nemesis, mas se têm mais alguêm que torna o br-linux deprimente é seus comentártios.
O nivel dos seus comentários não são nem um pouco diferentes do Stalman (não estou defedendo) mas antes de falar sujo tem que ver se não está mal lavado.
Olha só uma pequena prova:
http://br-linux.org/linux/node/2618/30090#comment-30090

Queria saber quem é esse ani: Queria saber quem é esse animal de circo que entra aqui usando o nome dos outros.

Realmente, assim é difícil de participar do br-linux. Infelizmente virou jardim de infância de menino mimado.

Fui.

Cássio R. Es_kelsen

O BR-Mono é feito em Mono: : O BR-Mono é feito em Mono:

http://www.br-mono.org

Quanto a sistemas ou mesmo sites, qualquer sistema ou site em ASPNET também roda no Mono, segue alguns exemplos:

MojoPortal http://www.mojoportal.com/
nGallery http://www.gotmono.net/Default.aspx?pageindex=5&pageid=24
BlogX http://www.gotmono.net/Default.aspx?pageindex=5&pageid=25
IBuySpy http://www.gotmono.net/Default.aspx?pageindex=5&pageid=26
Rainbow Portal http://www.gotmono.net/Default.aspx?pageindex=5&pageid=28
ASP.NET Forums http://www.gotmono.net/Default.aspx?pageindex=5&pageid=27

AT&T ???: Amigo,

De forma alguma, essa dúvida é comum.

A MS está para o Mono assim como a AT&T está para o Linux :)

Olha, a MS criou o C# e mandou para a ECMA avaliar, que é um órgão normatizador europeu como a ABNT é no Brasil. A ECMA aprovou, editou 2 documentos (ECMA 334 e 335) e encaminhou para a ISO, que é o órgão mundial de padronização e que também aprovou (ISO 23270/2003, se não me engano).

O que os desenvolvedores do Mono estão fazendo é implementando os padrões aprovados nos documentos da ECMA e da ISO para que possamos desenvolver softwares multiplataformas. No Windows você tem o .NET, no MacOSX o PortableNet e no Linux o DotGNU e o Mono. Teoricamente um código escrito para o Mono vai rodar no Windows e no MacOSX; mas na prática precisa de um pouco de habilidade para programar em razão do nível de implementação das plataformas nos diversos SOs.

A linguagem foi criada pela MS e muita gente diz que Java e C++ são mais poderosas etc (concordo, em termos). Outros dizem que o desenvolvimento com C# é mais rápido etc (também concordo, em termos). Você vai ter gente defendendo todos os pontos de vista :) Evangelizadores para todos os gostos :) Isso é normal :) Agora que C# veio para ficar como Java, C++, Python etc, veio :)

Em resumo, é isso :)

PS.: Essa resposta está liberada sob a "Creative Commons", assim se alguém quiser corrigir ou melhorar a resposta, fique à vontade!
---
Magno K - LinUser # 142.324

BR-Trolls:
Eu não quero defender nenhum dos dois, mas aqui está lotado de trolls mesmo. Pior são aqueles que ficam ofendidos porque alguem criticou aquilo que eles consideram como a Verdade Perfeita & Incontestável e levam a coisa para o nível pessoal.

> (não estou defedendo)

Defedendo??? Ainda bem que não está :P

Complicação:
> Alêm do j2ee ser milhões de vezes melhor.

E milhões de vezes mais complicado tambem.

Mas já é um avanço muito maior e mais rápido que o Java: Mas já é um avanço muito maior e mais rápido que o Java teve.

Veja precisou a IBM liberar o código do Visual Age para que surgi-se o Ecplise. O NetBean foi construído pela Sun.

Não existe nenhum IDE opensource java que foi 100% escrito pela comunidade.
O MonoDevelop nasceu do SharpDevelop e foi inteiramente escrito em C# um esforço e mérito da comunidade de software livre sem a ajuda de nenhuma empresa doando anos de trabalho em código fonte.

E realmente fiz uma injustiça ao delphi ao compara-lo ao MonoDevelop. Ele não é gera aplicações multiplataforma, não suportas svn, não trabalhar com múltiplas linguagens e enterra no windows os usuário que usam ele. Realmente fui injusto.

Quanto aos sistema de layouts do GTK reclame com o pessoal do GNOME.
Ou então você pode usar o Windows.Forms, tem um esquema de DataBind que é show de bola.

Só nas especificações abertas?: > O que os desenvolvedores do Mono estão fazendo é implementando os padrões aprovados nos documentos da ECMA e da ISO para que possamos desenvolver softwares multiplataformas.

Acho interessante a criação de alternativas livres para a linguagem C#/.NET. O problema, no entanto, é quando esta ambição vai além das especificações padronizadas pela ECMA/ISO e entra nas partes "obscuras", como o Windows Forms.

Segundo o Binhara[1], o Windows Forms já está disponível no Mono (para a versão 1.2). Estou enganado ou esse discurso de que o Mono é "100% ECMA/ISO" é inconsistente?

--
GAFFitter: a file fitter powered by a genetic algorithm.
FLTK: fast light C++ GUI toolkit.

ECMA: O Mono implementa tudo que esta no ECMA e as coisa que não estão no ecma também.

O que esta no ECMA:
- A Runtime
- O C#
- E o core Lib do .NET

O que é importante e não está no ECMA
- ASP.NET
- Windows.Forms
- ADO.NET

O pessoal do mono demorou a começa a implementar o windows.forms e no inicio era um bind para o Wine mas não deu certo. O pessoal do Mono estava esperando o Avalon (ao inves do windows.forms) mas a MS demorou tanto e ate agora não liberou. Então o pessoal do mono percebeu que o Windows.Forms teria uma vida muito maior que o esperado. A solução do pessoal do mono foi implementar o Windows.Forms pois senão ficaria complicada a aceitação dele.

Pra Java tem o JEdit 100% li: Pra Java tem o JEdit 100% livre.

--
[]s,
Emerson
JID: emerson.pardo

J2EE: "E milhões de vezes mais complicado tambem"

Criar aplicações corporativas dignas desse nome dá trabalho...

GUJ e Javafree! :-P: O GUJ (www.guj.com.br) é feito em J2EE faz tempo. O JavaFree (www.javafree.org) já é puro java a uns dois anos.

O pessoal do portal java talvez ainda esteja ocupado demais para implementar e adaptar seu site, ou não viu motivos para fazer isso até agora.

mortas?: Vc. está falando do PL1, do LOGO, do ALGOL, suponho?

"Com o advento do Mono"? Mono não é nenhuma descoberta revolucionária.

Ele é uma implementação do M$ .NET, que por sua vez finalmente aprendeu a trabalhar, construiu a VM CLR (baseada no que aprenderam no projeto de sua JVM licenciada, em mil novecentos e Java 1.2), "chupinhou" a linguagem e a API Java para fazer o C#. Claro, teve o cuidado de eliminar grande parte das medidas de segurança e robustez em nome da "usabilidade", não sem antes adicionar bastante açúcar sintático (pra ajudar a comunidade a engolir, suponho).

.NET é uma cópia (pálida) do que já existia antes.

Nem por isso eu desestimulo o pessoal do Mono. Espero que eles trabalhem melhor do que a M$. Que o Mono seja uma opção pra quem gosta.

Layout Managers: * Layout Managers são muito úteis, mas na prática bem mais difíceis de se projetar telas do que sem eles;

Layout Managers são uma mão na roda para suportar resoluções diferentes de tela, ou variações de tema, e obrigam vc. a pensar mais longe do que "naquilo que vc. está vendo". Por isso, acho uma técnica necessária para GUI de qualidade hoje em dia.

Mas muita gente pode discordar. Eu respondo então que a maior utilidade dos gerenciadores de layout é em aplicações multiplataforma, quando vc. não sabe qual o cliente gráfico que vai rodar sua aplicação. Aí é que vc. precisa garantir uma Aparência e Comportamento uniformes.

trabalho desperdiçado: Não existe nenhum IDE opensource java que foi 100% escrito pela comunidade.
O MonoDevelop nasceu do SharpDevelop e foi inteiramente escrito em C# um esforço e mérito da comunidade de software livre sem a ajuda de nenhuma empresa doando anos de trabalho em código fonte.

É uma pena que tenha sido assim... Reinventar a roda é desperdício de trabalho que poderia ser usado para outros fins.

Existem milhares de projetos puramente Open-Source escritos em Java para milhares de utilidades não cobertas por nenhum produto proprietário que tenha sido liberado. Se não há ainda nenhuma IDE inteiramente livre é pq os desenvolvedores Java são práticos e estão satisfeitos com as ferramentas que existem e que funcionam.

Para o ramo intreiramente didático (nicho não coberto pelo NB ou o Eclipse), a Monash University desenvolveu o BlueJ (www.bluej.org) com conceitos muito originais. Vc. devia dar uma olhada.

Para sua informação eu tenho um projeto de IDE, que adiciona coisas realmente novas às existentes. Mas só libero para a comunidade após ter uma base de código razoável. Acho que fim do ano eu chego lá. :-]

Ah, sim... Não posso deixar de comentar:

Ou então você pode usar o Windows.Forms, tem um esquema de DataBind que é show de bola.

A JGoodies, que trabalha com Java SL junto ao www.java.net, foi a pioneira com databind em Java Swing a muito tempo. Atualmente existem muitos frameworks assim, inclusive projetos que vão fazer parte do Swing oficial nas próximas versões. Consulte: Java Desktop

vc sabe que não: quando quero fazer uma provocação inocente, eu dou uma piscada ;)

a maioria dos meus comentários é construída em cima de argumentos lógicos. O "Stallman" é irracional como a maioria das crianças...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

realmente injusto: Considerando que o Delphi hoje pode ser programado em C#, usa .NET e emite bytecode CIL, ele deve rodar -- ou vir a rodar -- em mono, certo? Então, certamente deve ser multiplataforma e não deixar os usuários presos ao Win...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

dignidade: dignidade é escrever "sobrenome" ao invés de "strSufixoFamiliarHerdado" em aplicações "corporativas"/"enterprise"...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

não entendi nada... %-]: Cara, o que vc. quis dizer com isso?

não entendi a coisa... %-)

teoricamente: Nada impede a M$ de ir acrescentando incompatibilidades sutis à API a medida que o Mono for correndo atrás. Ela tem o poder pra fazer isso por ser a "dona da bola", de forma muito mais fácil do que quando ela tentou fazer o mesmo com Java. Nesse último caso ela falhou 3 vezes, mas com o Mono a história pode ser diferente.

Eu não confio na portablidade do .NET, em qualquer implementação.

Ah, "Stallman": Mostre algum nível técnico por favor. Se não, deixa esse site em paz.

quis dizer: quis dizer que programadores "enterprise" não conhecem os princípios KISS.

*edit*
por exemplo, só para ficar no monodevelop, encontrei essa patch aqui:

public virtual object Visit(ParenthesizedExpression parenthesizedExpression, object data)
{
if (parenthesizedExpression.Expression == null) return null;
return parenthesizedExpression.Expression.AcceptVisitor(this, data);
}

uau, nomes kilométricos para variáveis locais em um procedimento curto, redundância de expressões ( == null ) e outros recursos estilísticos "enterprise".

reescrevendo o trecho acima no estilo KISS:

public virtual object Visit( ParenthesizedExpression exp, object data )
{
ExpressionType e = e.Expression;
return (e)? e.AcceptVisitor(this, data) : null;
}

ok, pra ser honesto, não é nem culpa de programadores "enterprise", mas das ferramentas "enterprise" que eles usam, que colocam nomes padrão que são o nome do tipo em caixa baixa.

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

provocação: Nenhuma provocação é inocente, Nemesis ;-) (atenção: isso foi uma provocação).

"Malhar" alguma tecnologia sem apresentar motivos técnicos e/ou políticos, não gera bons frutos, vai terminar num flame religioso.

Não custa nada procurar ser mais cordato nas suas "espetadelas", cara.

Mas sim, vc. até que é mais consciente. A falta de respeito desses caras com *todo mundo* aqui é o fator de diferenciação.

A mensagem não era do Binhar: A mensagem não era do Binhara, deve ter sido coisa do Richard Stallman se fazendo passar por ele.

Vejá que está como "não confirmado".

malho: "'Malhar' alguma tecnologia sem apresentar motivos técnicos"

ops, desculpem. Não pensei que PHP hoje ainda merecesse alguma motivação técnica para ser malhado. Pensei que já fosse bom-senso... ;)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

e no Windows?: Gostaria de testar o MonoDevelop, mas, mesmo o Mono sendo multi-plataforma, não existe versão daquele para Windows. Não entendo...

putz: É mesmo!

Da próxima vez vou tomar + cuidado e verificar se o post vem de um usuário de verdade.

Pessoal do Linux-BR: Identificamos uma outra espécie de troll: O troll transformista!c Sugiro um novo apelido (se é que esse tipo de criança merece): Doppleganger.

Não pensei que PHP hoje aind: Não pensei que PHP hoje ainda merecesse alguma motivação técnica para ser malhado. Pensei que já fosse bom-senso

[Isso foi uma provocação e não deveria ser executada nunca...]

Eu já fui programador (e até instrutor) de PHP e *também* não gosto. Mas é inegável que há um espaço razoável para ele no mundo livre (diga-se de passagem, a comunidade incrivelmente torce menos o nariz pra ele que pro Java, vai entender...).

Se há espaço, há uma comunidade "trabalhadora". Quem trabalha pelo futuro da sua tecnologia, seja ela qual for, não merece ser zoado. Vc. pode criticar (e se receber a resposta, todo mundo aqui ganha + conhecimento com isso), mas não pode negar seus méritos.

Também é verdade que discutir esse assunto não cabe aqui... Me moderem, pessoal, se acharem necessário ;-]

[]s

Esse é um outro problema: Esse é um outro problema com o .NET/Mono.

Não recebendo ajuda da M$, o pessoal do projeto Mono tb. não vai "erguer a taça" pra ela!

Acredito que vc. possa portar o projeto para Win, não sem algum esforço (e assim por a prova a portabilidade do Mono). Se conseguir, manda uma notícia!

O MonoDevelop é construido s: O MonoDevelop é construido sob as bibliotecas Gtk, Gnome libraries e algumas outras como o GtkSourceView e o Glade. O Mono é portável e roda no Windows mas o MonoDevelop tem esse problema com algumas dependências, se você vai usar no Windows sugiro que utilizer o SharpDevelop com Mono.

As bibliotecas do Gnome estão sendo portadas para Windows e talvez até já funcionem o problema agora é só portar o GtkSourceView aí teremos o MonoDevelop no Windows.

Windows:
Copernico,

Sem querer defender os Monos, mas existe Mono para Windows. Acho que voce queria dizer "portar o projeto para .NET", não?

De novo: cada mono no seu galho ;-)

enquanto isso: vc pode ser bem produtivo usando gvim para Windows. Quem sabe quando monodevelop para Windows surgir, vc já esteja craque e até passe a desprezar IDEs? :)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Fácil de entender:
>>> a comunidade incrivelmente torce menos o nariz pra ele que pro Java, vai entender...

PHP -> Simples

Java -> Complicado

Simplicidade é uma virtude, embora as vezes não pareça.

IDEs:
Nemesis,

Agora voce chutou a santa dos caras :D

Não é tão fácil de entender assim: Fosse assim e todos já teriam abandonado o C/C++... Ou você acha lógica de ponteiros uma coisa simples?

--
[]s,
Emerson
JID: emerson.pardo

Até que é simples: A lógica de ponteiros é simples. Enfadonho é o gerenciamento de memória.
--
Alan Kelon Oliveira de Moraes - kelon.org

Mais fácil do que parece:
PHP é basicamente para Web (embora exista um GTK binding)

Se alguem está fazendo sites Web (que pode ser feito em PHP) usando C/C++, é porque gosta de complicar mesmo. Me desculpe se este for o seu caso.

Acredito que existam poucos casos em que faz sentido usar C/C++ nos dias de hoje (com máquinas poderosas e muita memória)

O fato do C (que tem 36 anos de idade) não ter sido abandonado até agora mostra que a informática está precisando se renovar.

Não... eu quis dizer Mono pa: Sim, existe Mono para Windows, o objetivo inicial não era a portabilidade mas sim disponibilizar um ambiente gerênciado com a linguagem C#.

No inicio não havia idéia de disponibilizar bibliotecas como ADO.NET e para acesso a dados usariam o GNOMEDB, com o tempo as pessoas começaram a exigir mais compatibilidade com o .NET e aí começaram a implementar inclusive o WinForms.

Resumindo: O .NET não é portável mas o Mono é.

Abaixo o link da página de downloads do Mono e um link para a versão Windows hospedada na mesma página:

http://www.mono-project.com/Downloads
http://www.go-mono.com/archive/1.1.13/windows-installer/0/mono-1.1.13-gtksharp-2.4.0-win32-0.exe

Nesse instalador para Windows é instalado inclusive o GtkSharp para o caso de você querer executar suas aplicações gráficas.

nada é fácil: "PHP -> Simples"

PHP não é simples: é tacanho. Como disse Einstein: " Everything should be simple, but not simpler."

"Simplicidade é uma virtude"

Concordo plenamente. Mais do que isso: deveria ser um ideal.

C/C++ e PHP têm algo em comum: popularidade. Mas por motivos diferentes: PHP, pq é incrivelmente simples para que mesmo não programadores possam arranhar; C/C++, por serem as linguagens de base tanto do *nix quanto do Windows.

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Delphi: Delphi .NET sem a VCL roda..
Delphi puro não ..

monodevelop no windows: Apesar do Mono Develop ser escrito em C#, ele usa uma série de bibliotecas além do GTK que só estão disponíveis no linux, apesar delas serem software livre.

São bibliotecas muito recentes do Gnome que ainda nao estão nem sendo usadas no gnome atual. Estão no gnome que esta em desenvolvimento.
Como essas bibliotecas estão em desenvolvimento e mudam muito rápido ninguem ainda empacotou elas para o windows.

Entao por hora o monodevelop só está diponível para Windows.

Tem o sharpdevelop para windows. Mas ele tem o mesmo problema. Estão usando algumas lib do windows que não tem no linux. O pessoal está tentando remover essas lib e agora com a disponibilidade do Windows.Forms para linux é possivel que logo tenhamos o sharpDevelop
rodando no linux

IDEs JAVA: Acho que me expressei mau. Sim, eu conheço as duas outras iniciativas mas mesmo o JEdit surgiu a pouco tempo.
E 80% de quem desenvolve java usa o Eclipse.

Durante muito tempo a IDE usada pelo pessoa de JAva era a da Borland o JBuilder. O que eu quiz dizer é que se comparamos a maturidade e o tempo de vida do Java.
O MonoDevelop foi desenvolvido muito mais rapidamente do que o tempo que se teve no java para surgir um Eclipse da vida.

Com relação ao Swing e seu databind. Eu não conhecia. Mas se para você o swing é legal, vai fundo. Desenvolve aplicação desktop com ele mas por favor não me chama. Eu desenvolvi 1 vez 1 aplicação em Swing e não quero ver isso mais na minha frente nunca mais.

Tivemos sérios problemas de interface. Num sistema operacional roda de um geito em outro roda de outro. Muito Obrigado mas estou muito bem com o GTK# e com Windows.Forms.

é verdade: queria falar uma coisa e falei outra, ou sem clareza.

--
[]s,
Emerson
JID: emerson.pardo

O que quis dizer é que a exp: O que quis dizer é que a explicação das pessoas torcerem o nariz pra Java é que ela seja complicada é uma explicação simplória demais.

C/C++ são tão complicados quanto, tem bibliotecas tão extensas quanto (e redundantes; a Borland, por exemplo, usa uma tal de AnsiString quando poderia usar o std::string). A explicação está mais para o que o nemesis disse aí embaixo: PHP é simples demais que até não programadores conseguem murmurar alguma coisa com essa linguagem.

--
[]s,
Emerson
JID: emerson.pardo

concordo absolutamente: GTK tem uma interface bem mais sã a do que Swing. Estou falando da API mesmo.

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Falar sobre o "baixo nível" sem o conhecer é perigoso...: Processadores de imagens, interpretadores, sistemas operacionais, drivers, servidores de altíssima requisição, bancos de dados não são tão poucos casos assim...

C não é abandonado porque é muito simples, muito eficiente, bem padronizada, tem *muito* código pronto e simplesmente não tem concorrente à altura para o que propõe. C++? Se você quiser complicar, vá em frente ;)

Há coisas para as quais usar linguagens de alto nível não é simplesmente ineficiente: é complicado. Aquela biblioteca em Java para acessar porta serial seria diabolicamente difícil de ser feita em Java, por exemplo. Aliás, sabe como é que Python às vezes consegue desempenho até bem melhor que Java quando tem tudo para ser ainda mais lento? Simples: as biblitecas em Python são feitas praticamente todas em C.

Pode acreditar: as "máquinas potentes" de hoje em dia simplesmente não seriam nem de longe rápidas se não existisse alguém tentando evitar fazer multiplicações no kernel do seu sistema operacional. Há pessoas que usam C para que você se engane pensando que C é ultrapassado. Se você fala o que fala, agradeça a elas.

--
Adam Victor Nazareth Brandizzi
Estudante de Ciência da Computação - UnB
Jabber: brandizzi@jabber.org
"Real programmers don't use Pascal; just integer ones can do it."

Outros motivos: Existem outros motivos, mas este é o mais evidente.

C/C++ não são tão complicados. Eles são antiquados (o que é diferente). 2005 e ainda com gereciamento de memória na "munheca".

Quanto ao que o Nemesis escreveu, é isso mesmo. Afinal, nem todo mundo é obrigado a saber programar, só fazer uma página Web dinâmica.

Digo o mesmo:
Quanta gente escreve device drivers? Quanta qente escreve sites Web?

O mercado de "baixo nível" é muito menor. Ainda mais no Brasil.

O C é antiquado. Uma prova disso é que já houve várias tentativas de atualização (exemplo: C++ mesmo, Objective C e até o Java) para reduzir aquelas características que acabam fazendo o programador dar tiro no próprio pé (é só ver os relatórios de vulnerabilidades cheios de casos de buffer overflows)

Se o C não foi posto de lado até hoje, é mais provável que seja porque tais tentativas tenham falhas, não conseguindo cobrir todas as capacidades do original.

OBS: As bibliotecas do Python são feitas em C no CPython.

munheca: "2005 e ainda com gereciamento de memória na 'munheca'"

vc pode ter bibliotecas que façam coleta automática para vc, por exemplo, a famosa boehm-gc. Mas querer que gerenciamento automático venha com C/C++ por padrão é pedir demais: Java existe justamente para isso. Se todas as linguagens tiverem GC, só vai ser possível ter performance em device drivers, interpretadores ou kernels programando direto em assembly e dizendo adeus à ( relativa ) portabilidade...

"nem todo mundo é obrigado a saber programar, só fazer uma página Web dinâmica"

só para fazer porcamente...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

"O mercado de 'baixo nível': "O mercado de 'baixo nível' é muito menor"

é a elite no pedaço... ;)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

:
>>> só para fazer porcamente...

Para isto existe o PHP, certo? ;-)

:
>>> é a elite no pedaço... ;)

Eles tambem pensam que são, enquanto os consultores (principalmente aqueles que já soluções prontas, independente do problema que seja) ganham muito mais. Quem é a elite, então? :/

O pessoal do BR Linux adora meus posts - sempre me censuram, portanto estou no caminho certo :))

elite != $$: quantos não são os ricos que vc encontra por aí, com carrão, acompanhados da puta da moda, saindo nas colunas sociais, que são semi-analfabetos, ladrões e pobres-de-espírito em geral?...

elite técnica faz por gostar de fazer, não pra ganhar dinheiro ou fama...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Discordo: Se você considerar apenas o mercado de PCs, sim, o mercado para programação em baixo nivel é pequeno mas o mercado de programação envolve também dispositivos menores desde PDAs até controles remotos inteligentes e este mercado é imensamente maior que o de PCs. Nesta área, linguagens como C e assembly dominam (C tem crescido muito, aliás) a imensa maioria dos trabalhos mas existe também Pascal, Forth, Basic e até Java :)
___
Nullum magnum ingenium sine mixtura dementiae fuit - Seneca

E durante a espera não daria: E durante a espera não daria pra implementar algo que poderia, quem sabe, até ser utilizado pela própria M$.

Imagina no lugar de ficar esperando que a M$ determinasse o caminho, eles mesmos poderiam indicar como as coisas iriam funcionar.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Carlos Wagner - São Luís / MA

P.S.: As palavras acima fazem parte da minha visão do assunto e não pretendem ser, de modo algum, a verdade absoluta sobre o mesmo.

Obrigado!

(elite != $$) == ilusão:
>>> elite técnica faz por gostar de fazer, não pra ganhar dinheiro ou fama...

Nemesis! Hoje tu tá inocente demais!!! Vai me dizer que nem reconhecimento o cara vai querer?

Técnicos não são elite - só pensam que são.

inocência: "Vai me dizer que nem reconhecimento o cara vai querer?"

O técnico mais brilhante e genial que conheço viveu há uns 300 anos atrás, não teve reconhecimento de seu trabalho em vida e provavelmente a humanidade teria perdido um de seus maiores gênios, se cerca de um século depois não tivessem redescoberto suas obras empoeiradas em velhos baús. Johann Sebastian Bach era o sujeito...

"Técnicos não são elite - só pensam que são."

Eu discordo, é claro. Técnicos têm capacidade de análise e de fazer acontecer. Se o mundo só tivesse arquitetos, só teríamos plantas, não prédios.

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

munheca: "vc pode ter bibliotecas que façam coleta automática para vc, por exemplo, a famosa boehm-gc. "

Se você olhara a documentação do mono vera que o mono usa o boehm-gc.

o que ele não faz é permiti: o que ele não faz é permitir ao próprio programador fazer sua gerência de memória, claro... e obter desempenho com isso ;)

*edit*
esquece, binhara. estou só sendo implicante. vamos abrir uma cerveja que hoje é sexta... :D

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Discorde a vontade:
Discorde a vontade, mas o maior mercado é o de PCs.

inocência pura:
>>> Eu discordo, é claro. Técnicos têm capacidade de análise e de fazer acontecer. Se o mundo só tivesse arquitetos, só teríamos plantas, não prédios.

Então o peão de obra é elite e o arquiteto não é. Cada vez mais inocente voce está :/

Por favor, censurem meu post!

Algumas são mais fáceis que outras:
Peraí! Eu nunca disse que PHP era bom. Só estava justificando sua popularidade.

Quanto ao C/C++, a vida é curta demais para isso ;P

com prazer!: "o peão de obra é elite e o arquiteto não é."

De certo modo, sim, já que as maiores edificações da humanidade -- inclusive as pirâmides da antiguidade -- se devem a esses anônimos.

Mas programadores não são meros peões, pois têm na capacidade de análise, criatividade e resolução de problemas habilidades primordiais e necessárias ao seu trabalho. A não ser que vc esteja falando de codificadores apenas, ou programadores PHP... :P

"Por favor, censurem meu post!"

com prazer! ;)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Utopia:
>>> De certo modo, sim, já que as maiores edificações da humanidade -- inclusive as pirâmides da antiguidade -- se devem a esses anônimos.

Nemesis, sua maneira de encarar isso é muito bacana, mas o mercado de trabalho é o oposto disso. E, querendo ou não, fazemos parte dele.

Não faço pouco dos programadores PHP, pois alguem tem que lavar banheiro e eu não to a fim ;-)

Por favor, censurem meu post de novo!

Tem certeza?: Já havia IDE profissional para Java em 1997, apenas dois anos após o Java ser lançado. O projeto Mono iniciou oficialmente em 19 de julho de 2001 e só agora tem-se uma IDE.

A conta é bastante simples.

--
Alan Kelon Oliveira de Moraes - kelon.org

jEdit é de 1999.: O jEdit está registrado no sourceforge desde 1999.

Quem podia pagar, utilizava o JBuilder; senão, Netbeans.

--
Alan Kelon Oliveira de Moraes - kelon.org

Eles implementara... é o Gtk: Eles implementara... é o Gtk# que roda inclusive em ambiente Windows.

Você acha que eles vão perd: Você acha que eles vão perder uma peça de marketing cheia de botõezinhos assim e vão para o velho e feio editor de textos? Faz de conta que eu acredito. ;)
Quanto mais firula, melhor.

Ou faziam na mão, no editor: Ou faziam na mão, no editor de texto.
Imagino se essa turma voltar no tempo 20 anos atrás e tiverem que programar. Morrem de fome, sem as IDEs poluídas, complicadas e pesadas que tanto amam. E estou falando de todas.

De quem voce está falando?:
>Você acha que eles vão perder uma peça de marketing cheia de botõezinhos assim e vão para o velho e feio editor de textos? Faz de conta que eu acredito. ;)
>Quanto mais firula, melhor.

De quem voce está falando? Dos monos ou dos javalis? Ou são tudo a lesma lerda?

Regressão por quê?: Não há motivos para regredir 20 anos no mundo tecnológico, porque é um caminho de mão única e sem volta. IDEs são produtivas e não poluídas, pois reduzem o trabalho repetitivo e tornam-o mais produtivo. Imagine você fazendo Rename Method em um código com 5000 arquivos. Em IDEs como o Eclipse, com dois cliques o problema está resolvido. Outro exemplo é a construção de GUI; Você até pode querer fazer uma interface do zero uma primeira vez, no entanto, as próximas vezes, serão certamente com ajuda de IDEs

Atenciosamente,

--
Alan Kelon Oliveira de Moraes - kelon.org

Eu que pergunto, regressão p: Eu que pergunto, regressão por quê? Saber fazer o código sem IDEs é regredir? A produtividade de uma IDE é relativa ao que você sabe fazer fora dela. No caso de Java, tem gente que só sabe usar o Ant de dentro do Eclipse, sendo que é muito fácil usá-lo sem precisar desse monstrinho. ;)
E você acaba aprendendo mais coisas fazendo do jeito ... digamos, bruto. Um script com 3 linhas usando o sed faz a substituição que você mencionou, acredito que até mais rapidamente, e ainda você aprende um pouco de shell script, coisa que ás vezes parece magia negra por que está acostumado com as "facilidades" da interface gráfica. E fica produtivo em outra área.
Mas o que eu mencionei e quis apontar principalmente no meu comentário é que essa turma faz muito alarde em cima de IDEs. Você pode até gostar delas, mas tem que aprender a se virar sem também. Mas se quiser usar, usa.
Esse tanto de propaganda em cima de IDEs acaba virando firula, para um programador que goste da coisa a fundo. Se ninguém se importar em fazer mais as coisas com os mínimos de recursos disponíveis, daqui alguns anos vamos estar só com um bando de "arrastadores-e-soltadores" que vão perder mais tempo chorando e tentando consertar problemas quando der algum problema nas IDEs ou nos arquivos de projetos por elas gerenciados do que efetivamente fazendo (e aprendendo como fazer) código.

De qualquer um que fala que: De qualquer um que fala que é programador só usando uma IDE ou ferramentas de apoio.
Os monos e os javalis no meio disso também. Tem javali que fala que programa em Java mas usa tanta ferramenta automática que nem sobra mais nada para escrever depois. ;)
Inclusive são esses que adoram coisas inchadas e enormes (sai pra lá, jacaré!) que dão a má-fama do Java IMHO.

I é de Integrated não de criador de GUI: From Wikipedia, the free encyclopedia
Integrated development environment: An integrated development environment (IDE), also known as integrated design environment and integrated debugging environment, is a type of computer software that assists computer programmers to develop software.

I é de Integrated, justamente para não ter que sair do ambiente para executar outras ações. Não vejo como um clique duplo em uma task seja mais complicado que abrir um shell, entrar na pasta do projeto e digitar ant sua-task. Usar o ant dentro do Eclipse não elimina o fato de saber criar arquivos build.xml manualmente, portanto seu comentário de só saber usar o Ant de dentro do Eclipse é falho.

Um script simples de 3 linhas em sed não irá definitivamente resolver o problema que citei, porque não se trata de uma simples substituição de texto. É possível ter-se dois métodos com a mesma assinatura em classes distintas - ou mesmo em uma única classe - e desejar renomear apenas uma delas. O sed saberá distinguir pelo contexto? Um segundo exemplo é o ato de mover uma classe de um pacote para outro. 3 linhas em sed resolverão o problema?

Bash script não é mesmo magia negra, pelo contrário, é bastante simples de aprender e útil em vários casos, por exemplo, safei-me em diversas ocasiões com while, cut e grep ;) entretanto não resolve todos os problemas do mundo. Embora seja fácil de aprender, ainda exigirá estudo, dedicação e conhecimento das ferramentas disponíveis no ambiente, que logicamente demandará muito tempo para fazer um simples Rename Method.

Também não vejo como uma IDE não possa gerar código com bom desempenho. É um argumento que se desfaz sozinho, pois sua afirmação foi baseada apenas em achismos.

Programar no VIm + Exuberant Ctags rodando em cima do TWM
é massa e já o fiz por muito tempo em projetos pequenos durante a graduação, porém é totalmente inviável para projetos grandes devido as complexidades adicionais inerentes aos mesmos.

Por fim, reforço que IDE não é sinônimo de GUI Builder. Por exemplo, no Eclipse 3.1 não há um editor de GUI junto com a ferramenta e não perde o título de IDE mais usada no mundo.

Atenciosamente,
--
Alan Kelon Oliveira de Moraes - kelon.org

Pra que perder tempo reinventando a roda?: Qual o problema com as ferramentas de apoio? O make é uma ferramenta de apoio, então só por isto você vai ficar digitando

gcc -c -I../../../includes/header1.h something1.c

gcc -c -I../../../includes/header2.h something2.c

gcc -I../../../includes/header1.h -I../../../includes/header2.h main.c something1.o something2.o -o killer-app


ooda vez que for compilar a aplicação? Puxa! Que massa que isto vai lhe fazer programar tremendamente melhor!

Se várias partes do software podem ser automatizadas, por que perder tempo reinventando a roda e reescrevendo tudo novamente a todo momento? Com os geradores de código sobra tempo para pensar-se e criar-se algo mais interessante. Se a infra-estrutura está bem solidificada, por que vou perder tempo refazendo-a quando posso aproveitá-la e, a partir da mesma, criar softwares resolvam problemas da vida real?

Abraço,
--
Alan Kelon Oliveira de Moraes - kelon.org

Nenhum se as ferramentas de a: Nenhum se as ferramentas de apoio não abstraem o seu conhecimento.
IDEs, quer você queira ou não, deixa grande parte dos seus utilizadores com preguiça de pensar e extremamente dependente da ferramenta. Não estou falando de todo mundo, mas da grande maioria.
E você forçou comparando o make com o Eclipse, hein. ;)

> Não vejo como um clique du: > Não vejo como um clique duplo em uma task seja mais complicado que
> abrir um shell, entrar na pasta do projeto e digitar ant sua-task.

É mais difícil se você não tiver máquina para rodar a IDE ou mesmo se não tiver ela instalada ou ela der pau. ;)

> portanto seu comentário de só saber usar o Ant de dentro do Eclipse é
> falho

Não se você levar em conta a quantidade de gente que não sabe usar ele fora do Eclipse. ;)

> O sed saberá distinguir pelo contexto?
> 3 linhas em sed resolverão o problema?

Aí você já está adicionando mais complexidade ao problema e se depois de muito tempo discutindo isso chegarmos a uma conclusão de como fazer iríamos ter até um bom projeto para liberar para a comunidade. Deixa para lá, que a thread vai sair ali pela direita. ->

> Bash script não é mesmo magia negra, pelo contrário, é bastante
> simples de aprender e útil em vários casos.

Sim, mas tem gente que fica tão dependente e emburrecido por causa das IDEs que se esquecem disso e quando alguém faz um script levinho acham que o cara é o maior hacker do mundo. :)

> É um argumento que se desfaz sozinho, pois sua afirmação foi baseada
> apenas em achismos.

Pelo contrário, você quem está achando alguma coisa a respeito disso. Eu até agora emiti opiniões sem falar do que uso ou não uso, então você não sabe do meu envolvimento/conhecimento disso, e está achando coisas. :)

> porém é totalmente inviável para projetos grandes devido as
> complexidades adicionais inerentes aos mesmos

Depende do projeto grande. Você complica ele se você quiser. Ah, tem o Emacs que é muito bom também.

> IDE não é sinônimo de GUI Builder

Também reforço que nem estou falando tanto de GUI. Estou falando de gente que choraria e não programaria nada sem as suas IDEs, e dos vícios que uma IDE (ainda mais se for GUI builder) cria. Mas cada mono no seu galho, como disse o amigo aqui na thread. :)

O problema:
O problema com geradores de código é o monte de código que é entulhado na aplicação, gerando um produto de baixa qualidade. Um caso notório são ferramentas para Web que geram páginas pesadas com muitas tags inúteis, sujeira pura.

Até o make pode ser ruim, se mal utilizado, pois a pessoa que está compilando normalmente não verifica se o Makefile só tem o que deveria ter realmente.

Com as IDEs, o problema do "entulho" vai ao extremo (o Eclipse precisa de 1GB de RAM para ter uma performance aceitável num Pentium 3)

apples and oranges: Java foi desenvolvido por uma empresa comercial e sua primeira IDE também o foi. O que isso significa, é que tinham gente trabalhando nos projetos 8 horas por dia ou mais e (bem) pagas para isso. Não querendo desmerecer projetos open-source, mas tirando os maiores e mais ativos, a maioria conta com poucos recursos humanos e tempo.

Além disso, tem certeza que Java nasceu em 1995? Eu me lembro de ter feito um trabalho de faculdade sobre essa então nascente tecnologia ainda em 1994. Fora que era um hype incrível na época, de modo que assim que surgiu, pouco depois tecnologias addon -- como IDEs -- já estariam disponíveis, pq a coisa definitivamente era "quente"...

Se vc fosse comparar certo, compararia Java/Netbeans ( ambos da SUN ) com .Net/VisualStudio ( ambos M$ ). Ou então, Kaffe/? com mono/monodevelop. :)

Por fim, monodevelop já estava em um estado relativamente usável há pelo menos 1 ano atrás.

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

é disso que eu gosto! :D: "Um script simples de 3 linhas em sed não irá definitivamente resolver o problema"

Definitivamente, não. Foi forçação de barra mesmo, destinada a mostrar que a simplicidade das ferramentas de shell é melhor do que uma IDE completa e redundante. Eu compartilho deste sentimento, mas, embora muitas coisas perfeitamente úteis e aceitáveis sejam possíveis de ser obtidade de forma bem mais simples realmente apenas com sed, awk ou perl e bom-senso na seleção dos alvos a sofrerem o processamento, eu gostaria de ressaltar que não há um equivalente dentre as ferramentas de shell padrão do *nix para um analisador sintático. Existe um famoso gerador: bison/yacc, o que já é um começo.

IDEs têm em seu componente analisador sintático um de seus grandes trunfos. Ele geralmente fica rodando em uma thread em separado, analisando tudo o que vc digita e com conhecimento sintático dos arredores ao texto armazenado em uma árvore abstrata de sintaxe em memória, continuamente modificada. É ele quem ajuda com tais serviços como auto-compleção sintática ou o exemplo dado com renomeação de nomes de métodos, nos quais é necessários ter a informação do contexto sintático, não podendo ser mera substituição textual.

Seria um projeto interessante implementar um front-end de linha-de-comando com analisadores sintáticos para várias linguagens de programação e que oferecesse operações baseadas no posicionamento de um cursor virtual por diferentes partes do texto de algum arquivo ou pipe. Integrando esse front-end com emacs ou vim já seria uma ajuda enorme para ações que antes estavam disponíveis apenas em IDEs pesadas ou em linhas sem fim de algum hack perl... :)

"Um segundo exemplo é o ato de mover uma classe de um pacote para outro. 3 linhas em sed resolverão o problema?"

não, mas possivelmente 3 em perl farão a mágica. :)

"que logicamente demandará muito tempo para fazer um simples Rename Method."

mas se vc puser em um script e reutilizar, não terá o mesmo trabalho sempre e ainda vai economizar em recursos computacionais por não precisar de uma IDE. :)

"Também não vejo como uma IDE não possa gerar código com bom desempenho."

Olha, eu já trabalhei com Delphi, Visual Studio.NET e Eclipse. Delphi é incomensuravelmente mais ágil que as outras. Máquinas Virtuais e centenas de bibliotecas rodando em cima delas é que fazem a diferença. ;)

"Programar no VIm + Exuberant Ctags rodando em cima do TWM
é massa e já o fiz por muito tempo em projetos pequenos durante a graduação, porém é totalmente inviável para projetos grandes devido as complexidades adicionais inerentes aos mesmos."

Talvez para alguns seja um letdown, mas se a tal ferramenta de linha de comando para análise sintática existisse e pudesse se comunicar com o emacs e vim, já faria uma diferença enorme na aceitação. Juntava uns scripts básicos para gerenciamento de projeto e faria a festa de programadores "enterprise" de ocasião. :)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Efeito M$: Haha... LoL!

Isso é coisa da nossa boa e velha M$ e seus padrões obscuros de nomenclatura. Quem quiser rir a beça é só dar uma olhada nos identificadores de APIs nativas do Windows. Tem coisa como hDwiDnToolDf()... ;-)

Os vendedores do Ruindows dizem que ele obedece ao princípio KISS. Mas parece que é só na interface com o usuário, pq quando se vê código, ptz!

Mas isso não é característica de programador corporativo. Muitos (os melhores) seguem boas métricas, bons padrões e boas práticas.

Quem for programador e quiser dar boas risadas (e corrigir alguns maus hábitos), é só visitar Esse site

[]s

Desempenho?: No meus tempos de programador C++, a maioria das vezes que me vi, ou a algum colega, codificar gerência de memória "na unha" (com mallocs, pilhas de ponteiros, etc), resultou em um bom desempenho nos testes, mas queda de desempenho (e as vezes até "travadas") rodando em outros ambientes que não o de desenvolvimento. Levava muito tempo até que conseguíssemos um desempenho aceitável e a estabilidade necessária.

Em tempo de projeto, vc. não tem como prever como o ambiente de execução vai se comportar. É por isso que, hoje, não vejo memória manual como uma boa idéia.

Outro problema é portabilidade. Tenta fazer um prog que gerencie ponteiros no braço, usando o o Kalix, recompile e rode no Delphi sob Ruindows sem alterações...

Escopo diferente: GTK+ é um toolkit de widgets. Nada mais. Swing é um framework MVC completo para interfaces gráficas. Inclui mais funcionalidades que o GTK (incluindo cross-cuttings como Look And Feel plugável, gerenciamento de layout, etc).

API mais poderosa = + complexidade.

Na minha opinião, GTK é muito feito e tem problemas de usabilidade (como a falta de suporte à interfaces MDI). Mas Swing pode emular a aparência e comportamento do GTK, cas seja desejo do usuário (GTK+ já é o Look And Feel padrão para Linux, no J2SE5.0).

Produtividade: IDEs são produtivas, desde que vc. as use como *ferramentas* e não como *muletas*.

Alguns "programadores" VB e Visual C++ que conheço chegam ao ponto de confundir a linguagem e suas APIs com a IDE ("a sua linguagem tem recurso de auto-competar? A minha tem!").

Se vc. vê a ferramenta fazer alguma coisa que vc. não entende como acontece, é um sintoma de que vc. deveria largá-la até aprender.

No caso do JBuilder por exemplo já vi muita gente perdendo horas e horas em listas de discussão tentando resolver um problema de compilação simplesmente por não entender o conceito de classpath, que é básico em Java.

Em relação a edição de GUI, até hoje eu escrevo minhas interfaces manualmente (claro, usando frameworks de layout como o JGoodies Forms, por exemplo), assim como a maior parte da comunidade Java. Isso pq uma IDE não pode pensar. Eu posso. Seu código jamais vai ser mais eficiente, limpo e bem planejado como o meu.

IDE deve ser feita e usada como uma extensão do seu braço. Não como cérebro substituto.

nenhum: Se está falando de *profissionais de verdade*, não está falando de nenhum dos dois...

Bons programadores são independentes de plataforma. "Zebras" também são.

C: C não foi abandonado até hoje pq ele é maravilhoso para escrever rapidamente coisas que, do contrário, vc. teria que escrever em Assembly.

Isso significa: quando vc. precisa escrever rotinas que são fortemente dependentes da plataforma operacional na qual vc. está. Ou quando o equipamento que vc. usa é tão limitado que isso é muito mais importante do que quaisquer outros interesses.

O ideal é escrever em baixo nível o que precisa ser escrito, e acessar essas rotinas a partir de uma língua de nível superior.

Só tenha o cuidado de, antes de escrever suas rotinas nativas, verificar se já não existe uma solução para o seu problema acessível de uma plataforma de alto nível. Por exemplo: A partir de J2SE 1.4 não faz mais sentido escrever rotinas nativas de I/O de alta performance, pois o pacote padrão java.nio implementa uma das mais eficientes APIs de I/O da atualidade (todas as novidades nesse campo são suportadas, desde simples buffers nativos até seletores/canais assíncronos, multiplexação, etc).

Problemas de interface: Tivemos sérios problemas de interface. Num sistema operacional roda de um geito em outro roda de outro. Muito Obrigado mas estou muito bem com o GTK# e com Windows.Forms.

Desculpa, Binhara (dessa vez é vc. mesmo, certo? Só como "sanity check"). Mas vou te fazer a mesma pergunta que faço aos meus alunos:

Você sabia o necessário Swing, gerenciadores de layout e aparência e comportamento plugáveis antes de fazer seu trabalho (estou levando em conta que é um trabalho profissional, não uma telinha de fim-de-semana) ou só ligou a sua IDE "da moda" e confou nela pra fazer tudo por você?

Esse comportamento que vc. descreveu aparenta ser conseqüência do uso de layout nulo (sem gerenciamento) ou um PLAF inadequado.

As aplicações que faço não têm problemas de portabilidade visual em nenhuma plataforma que já testei (ou que os meus usuários testaram). Uso gerenciadores básicos para tarefas simples (e tenho alguns templates pessoais para idiomas mais comuns de layout) , JGoodies Forms para layouts mais elaborados e uso uma só aparência e comportamento para todas as plataformas (O Liquid, Alloy e os PLAF da JGoodies são os meus favoritos, Mas o novo substance está progredindo rápido).

Ah, projeto minhas interfaces sobre papel quadriculado primeiro antes de implementar "no braço". E isso não reduz minha produtividade: levo em média de 5 a 20 min. por tela, tempo semelhante ao obtido por alunos meus usando o Matisse do Netbeans.

"Swing é um framework MVC co: "Swing é um framework MVC completo para interfaces gráficas."

Em outras palavras: um toolkit de widgets com suporte ao modelo MVC. Hmm, surpreendentemente, praticamente qualquer toolkit gráfico permite um bom suporte a MVC, já que este modelo foi criado exatamente para se modelar GUIs! Entretanto, algumas preferem simplicidade ao invés de masturbação mental. :)

"Look And Feel plugável,"

em outras palavras: temas, como o de GTK.

" gerenciamento de layout, etc)."

o que vc acha que são GtkTable ou GtkBox?

"API mais poderosa = + complexidade."

bobagem. é complexidade redundante para satisfazer ego de programadores "enterprise"...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

GTK vs Swing:
O GTK tambem é MVC e o Look and Feel plugável.

Na minha opinião, Swing é muito feio e tem problemas de usabilidade (como suporte a práticas ruins, como MDI). Mas GTK pode emular a aparência e comportamento do Swing, caso seja desejo do usuário.

O GTK não implementa a MDI de propósito, é uma diretiva de projeto não implementar práticas ruins de interface.

Sim:
>bobagem. é complexidade redundante para satisfazer ego de programadores "enterprise"...

Exatamente. Esses foi um dos motivos porque eu larguei o tal "enterprise" e fui trabalhar com sistemas da área cientifíca / engenharia. E me livrei do J2EE tambem.

MDI como prática ruim: Você pode citar algum livro ou site sobre esse assunto?

--
[]s,
Emerson
JID: emerson.pardo

Swing :-): Em outras palavras: um toolkit de widgets com suporte ao modelo MVC. Hmm, surpreendentemente, praticamente qualquer toolkit gráfico permite um bom suporte a MVC, já que este modelo foi criado exatamente para se modelar GUIs! Entretanto, algumas preferem simplicidade ao invés de masturbação mental. :)

Eu não lembro de suporte para criar objetos de controle reutilizáveis em toolkits de Widgets. Não lembro da possibilidade de utilizar o mesmo modelo de dados para exibir em widgets diferentes, etc. Dá uma olhada séria no swing para ver a diferença antes de se precipitar.

"Look And Feel plugável,"

em outras palavras: temas, como o de GTK.

De jeito nenhum. "Temas" atende apenas ao "Look" da fórmula. PLAFs podem alterar profundamente o comportamento dos componentes visuais (até mesmo torná-los não-visuais! Para tornar a sua aplicação manipulável por uma pessoa cega, basta trocar o PLAF para um especializado na tarefa. Existe um dispositivo que "fala" a tela...
;-P ).

Para trocar o PLAF, vc. não precisa de nenhum esforço de codificação. É, tão fácil quanto trocar o tema, mas faz muito mais que isso.

o que vc acha que são GtkTable ou GtkBox?

Vc. não quer realmente comparar o que existe em Swing/AWT com isso, quer? :=P

bobagem. é complexidade redundante para satisfazer ego de programadores "enterprise"...

Pra começo de conversa, apenas uma fração dos programadores Swing são programadores "enterprise".

Para terminar, meus alunos que aprenderam swing agora não conseguem achar a complexidade de que vc. fala. E eu, que já conheço + fundo, enxergo apenas o poder. Que eu não tenho em GTK+, SWT, etc.

A maioria dos meus projetos teria uma GUI bem mais pobre se eu usasse essas coisas.

bastante emocional de sua parte: O GTK não implementa a MDI de propósito, é uma diretiva de projeto não implementar práticas ruins de interface.

Bastante emocional de sua parte, emu caro. Mas eu também estou curioso para saber como vc. obteve essa informação fascinante.

Seu esforço é louvável, mas vc. tem que fazer isso com base. Afinal, tem muita aplicação MDI com usabilidade excelente por aí, nem vou precisar citar.

O único bom substituto para MDI é o Docking (que o GTK+ também não implementa).

Ou vc. acha que a interface do GIMP é um trinufo da usabilidade?

Vamos lá, estou realmente curioso...

Copérnico: vc me lembra um velho camarada meu, daqui -- Patola. especialmente na defesa apaixonada do Java. vc apareceu por aqui depois que ele andou meio fulo com o Ananias...

mas...

"Eu não lembro de suporte para criar objetos de controle reutilizáveis em toolkits de Widgets."

Não entendi exatamente o que vc quis dizer com isso. Está falando na criação de novos widgets a partir de herança? De qualquer modo, GTK + GLib tão plena liberdade para o cara derivar novos widgets a partir de outros. Não acho que é por isso que o Swing é complexo, na verdade, com a hereditariedade OO típica é até um pouco mais fácil que em GTK.

"Não lembro da possibilidade de utilizar o mesmo modelo de dados para exibir em widgets diferentes"

Há o famoso GtkTreeModel, que é usado em alguns widgets.

"Dá uma olhada séria no swing para ver a diferença antes de se precipitar."

não costumo criticar o que não conheço.

"PLAFs podem alterar profundamente o comportamento dos componentes visuais (até mesmo torná-los não-visuais! Para tornar a sua aplicação manipulável por uma pessoa cega, basta trocar o PLAF para um especializado na tarefa. Existe um dispositivo que 'fala' a tela..."

GTK suporta isso plenamente via ATK. E se é preciso codificar, o é apenas por ainda não se haver desenvolvido um formato semelhante a temas para essa funcionalidade.

"o que vc acha que são GtkTable ou GtkBox?

Vc. não quer realmente comparar o que existe em Swing/AWT com isso, quer?"

Graças a Deus, não! :)

"Pra começo de conversa, apenas uma fração dos programadores Swing são programadores 'enterprise'."

verdade. Os outros são aspirantes. :)

"Para terminar, meus alunos que aprenderam swing agora não conseguem achar a complexidade de que vc. fala."

deixa eu adivinhar: é o único toolkit que eles usaram até hoje, não? Se tivessem começado com Delphi ou VB, já estariam reclamando de ter que fazer na mão. E se conhecessem GTK ou Tcl/tk, estariam reclamando da complexidade redundante, como eu, aliás. :)

" E eu, que já conheço + fundo, enxergo apenas o poder."

As pessoas são facilmente impressionáveis por números e quantidade. Um exemplo claro em Informática mesmo: a métrica comum de linhas-de-código/Lines-Of-Code. O cara escreve mil linhas de código e dá a impressão de que trabalhou feito um condenado. Mas a maior parte é copiar e colar demente, em C++. Um sujeito, fazendo o mesmo programa em Python, digamos, com funções ao invés de copiar e colar, de repente faz o mesmo em meras 20 linhas. Não tão impressionante quanto seu colega imbecil, pelo menos aos olhos do chefe.

Assim também é com APIs: coisas gigantescas passam a impressão de poder e funcionalidade incomensuráveis. Nem uma sombra de dúvida passa que muito daquilo é redundante e feito para lidar com as próprias limitações induzidas por outras partes da arquitetura...

"A maioria dos meus projetos teria uma GUI bem mais pobre se eu usasse essas coisas."

é uma opinião válida, eu acho. Claro, a minha é contrária a sua. :)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

:
Nada emocional. Eu apenas li na internet (estou procurando o link para mostrar para voces). Só estou querendo que voce não (man)tenha seu preconceito em relação GTK.

>Ou vc. acha que a interface do GIMP é um trinufo da usabilidade?

Não. Interfaces mal projetadas podem ser feitas com qualquer tecnologia, certo?

Continuando...:
Voce pode usar o MDI no GTK, só que são necessários bibliotecas de terceiros (LGPL)

O GTK implementa docking, está nos "extras".

OBS: Eu prefiro usar o GtkNotebook.

MDI:
Oi Emerson,

Não encontrei ainda o link aonde eu tinha lido sobre o assunto, mas encontrei outras coisas interessante:

- o debate sobre MDI na lista dos desenvolvedores GTK/GIMP:

http://www.mail-archive.com/gimp-developer@lists.xcf.berkeley.edu/msg06993.html

- a opinião dos desenvolvedores do Abiword:

http://www.abisource.com/twiki/bin/view/Abiword/FaqMultipleWindowsVsSubwindows

- uma página sobre design de interfaces (que tem recomendação número 1 não usar MDI):

http://www.pixelcentric.net/x-shame/docs.html

E na Wikipedia explica bem as avantagens e desvantagens do MDI:

http://en.wikipedia.org/wiki/Multiple_document_interface

Acho que aí já tem um bom material sobre o tema. Mas vou continuar procurando.

RE: Copernico: vc me lembra um velho camarada meu, daqui -- Patola. especialmente na defesa apaixonada do Java. vc apareceu por aqui depois que ele andou meio fulo com o Ananias...
Eu lembro do Patola aqui no BR-Linux faz tempo. Tive altas discussões com o cara a respeito da abertura do Java (logo depois daquele artigo "The Java Trap" do RMS.

Mas minha defesa aqui não é genericamente sobre Java, mas do Swing em particular. Em Java existem outras opções de design gráfico: SWT e o próprio GTK+ (a versão Java da API GTK padrão).

Não entendi exatamente o que vc quis dizer com isso. Está falando na criação de novos widgets a partir de herança? De qualquer modo, GTK + GLib tão plena liberdade para o cara derivar novos widgets a partir de outros. Não acho que é por isso que o Swing é complexo, na verdade, com a hereditariedade OO típica é até um pouco mais fácil que em GTK.

Não, eu não estava falando de Herança... Sou até contra ela muitas vezes, pq aumenta a complexidade do objeto. Geralmente acho válido substituir herança por agregação. O que eu quis dizer é que um componente de interface precisa ser versátil, exigindo uma implementação mais elaborada. Componentes Swing, por exemplo, são implementados de forma a poderem ser criados por reflexão, são passíveis de transformação em fluxo de byte (para serem enviados via rede ou ter seu estado armazenado no disco) com muito pouca codificação extra, tem seu próprio mecanismo de controle de versão, atuam eles mesmos como conteiner (possibilitando colocar botôes em células de uma tabela, por exemplo) e podem trabalhar com uma miríade de modelos de dados diferentes. Como esses últimos são acessados pelos componentes através de suas interfaces, não de suas implementações, o acoplamento com o resto da API é mantido baixo e é possível modificar radicalmente a forma como um componente conhecido funciona. Eu posso criar uma tabela que exibe dados vindos de um Web Service, por exemplo, com poucas linhas de código.

Esse é um poder que eu não encontro em nenhuma outra API, inclusive as outras alternativas existentes em Java!

Há o famoso GtkTreeModel, que é usado em alguns widgets.

Esse eu até já tinha ouvido falar. Mas não muda o fato de que a API do GTK não foi projetada para esse tipo de coisa.


GTK suporta isso plenamente via ATK. E se é preciso codificar, o é apenas por ainda não se haver desenvolvido um formato semelhante a temas para essa funcionalidade.


Ei, eu não conhecia isso! Pra você ver como esses debates são muito positivos como disseminadores de conhecimento.


"o que vc acha que são GtkTable ou GtkBox?

Vc. não quer realmente comparar o que existe em Swing/AWT com isso, quer?"

Graças a Deus, não! :)



Eu fico "mal educado" quando estou com pressa... :-) O que quis realmente dizer é que as opções de gerenciamento de layout disponíveis ao GTK não são tão numerosas ou elaboradas quanto as existentes em Swing/AWT (que foram projetadas desde o início para suportá-las).

As pessoas são facilmente impressionáveis por números e quantidade. Um exemplo claro em Informática mesmo: a métrica comum de linhas-de-código/Lines-Of-Code. O cara escreve mil linhas de código e dá a impressão de que trabalhou feito um condenado. Mas a maior parte é copiar e colar demente, em C++. Um sujeito, fazendo o mesmo programa em Python, digamos, com funções ao invés de copiar e colar, de repente faz o mesmo em meras 20 linhas. Não tão impressionante quanto seu colega imbecil, pelo menos aos olhos do chefe.

Assim também é com APIs: coisas gigantescas passam a impressão de poder e funcionalidade incomensuráveis. Nem uma sombra de dúvida passa que muito daquilo é redundante e feito para lidar com as próprias limitações induzidas por outras partes da arquitetura...


Não é assim, acredite! Embora Swing tenha muito caminho ainda por percorrer (e possa até dar origem a um outros frameworks no futuro),
maior parte da quantidade de código nessa API é *realmente* justificável. Após um pouco de estudo dela, o tamanho da API não é mais um problema, pois tudo é organizado em cima dos mesmos princípios, sendo simples localizar a estratégia perfeita para se fazer o que quer.


"Pra começo de conversa, apenas uma fração dos programadores Swing são programadores 'enterprise'."

verdade. Os outros são aspirantes. :)


Nada mais longe da verdade. Muita gente (todos os iniciantes e muita gente experiente tb.) acredita que há uma relação de hierarquia entre o Java padrão e o J2EE ("Enterprise"). Quem trabalha com J2EE é "superior" a quem trabalha com Java Fundamental (Desktop, por exemplo). Mentira. Existem muitos profissionais (principalmente lá fora, pq aqui no Brasil o pessoal ainda é muito "deslumbrado") extremamente competentes que não atuam no segmento corporativo e pouco usam do J2EE, se é que o fazem.

Por outro lado, já trabalhei com muito programador "enterprise" que se formou em cursinhos de 40 horas e não sabe coisas fundamentais, como usar I/O sem "muletas", avaliar o melhor tipo de coleção para uma situação específica, como fazer da melhor forma o parsing de um arquivo XML, ou mesmo como configurar corretamente o ambiente de execução e o coletor de lixo... :-)


é uma opinião válida, eu acho. Claro, a minha é contrária a sua. :)


Se a sua funciona para você, e a minha funciona para mim, então estamos bem! :-D

O que eu não posso deixar é de estar presente na discussão, e divulgar que a minha opinião funciona para mais alguém, e como fazer funcionar :-)

preconceito:
Nada emocional. Eu apenas li na internet (estou procurando o link para mostrar para voces). Só estou querendo que voce não (man)tenha seu preconceito em relação GTK.



Não é preconceito, rapaz. GTK é um trabalho livre e todo trabalho é válido. Eu só testei o GTK (que tem uma API para Java, que é a plataforma em que trabalho), para minhas necessidades, e ele não atendeu.

E essa questão de achar o visual dos widgets feio, é só questão de gosto pessoal, reitero isso. Existe um "Look And Feel" GTK+ (que aliás é o padrão dentro do Linux) e eu também não gosto dele.

Não. Interfaces mal projetadas podem ser feitas com qualquer tecnologia, certo?

Sim, mas a falta de opções em uma tecnologia podem incentivar isso.

Fica mais tedioso fazer uma interface tipo GIMP no Swing (gerenciar muitas janelas e diálogos), que usar MDI, por exemplo.

Já no caso do GTK+, a opção mais direta seria essa mesmo... Eu acho a solução MDI a "menos pior".

MDI: Bom, com bibliotecas de terceiros, é possível fazer qualquer coisa, certo? ;-)

Ah, a título de informação: Swing implementa MDI por padrão, mas realmente não o docking.

Para isso vc. pode escolher (por enquanto) usar um framework de terceiros. O que eu mais gosto (e uso) é o VLDocking. Quem quiser, pode dar uma olhada na página da empresa que o faz: http://www.vlsolutions.com/en/index.php. A licença é a Cecil, que é uma variante LGPL compatibilizada para a legislação francesa. Dê uma olhada nas funcionalidades e se impressione! :-P

GTK:
> Sim, mas a falta de opções em uma tecnologia podem incentivar isso.

Sim, e a falta de conhecimento sobre a tecnologia tambem pode incentivar isso.

> Já no caso do GTK+, a opção mais direta seria essa mesmo... Eu acho a solução MDI a "menos pior".

Orelhas tipo "Firefox" são uma opção melhor (e acho que é a mais direta, pois o esforço para implementar é mínimo - basta dois clicks no Glade) e o GTK suporta diretamente (sem extras ou pacotes de terceiros)

MDI:
> Bom, com bibliotecas de terceiros, é possível fazer qualquer coisa, certo? ;-)

Sim. Mas acho bom assim, pois a inclusão no GTK poderia estimular o uso do MDI. Ao contrário do Linus Torvalds, acho positiva a atitude de desenvolvedores do GNOME e do GTK que tentam evitar os vícios. Por isso, hoje o GNOME requer menos suporte do KDE para end user.

> Dê uma olhada nas funcionalidades e se impressione!

Se eu trabalhasse com Java, eu olharia, mas não é o caso. E atualmente, por causa de 2 projetos que estou envolvido, eu me impressiono mais com componentes para computação distribuida.

objeções: Como seu espectador, na minha opinião, descarto as seguintes fontes, para o escopo dessa discussão:

o debate sobre MDI na lista dos desenvolvedores GTK/GIMP

O GTK Group não implementou o MDI, com 90% de certeza, devido à dificuldades técnicas. Isso pq eu lembro dos meus tempos de C++ e MFC, que implementar MDI (que alia desenho de componentes a eventos de usuário e depois tem que encapsular tudo isso em um componente), com eficiência é um "pesadelo".

Devido a isso, é fácil dizer que uma coisa difícil é "não recomendada". Não levo a opinião deles em conta.


- a opinião dos desenvolvedores do Abiword:

http://www.abisource.com/twiki/bin/view/Abiword/FaqMultipleWindowsVsSubwindows


Opinião de um grupo de desenvolvedores de um produto.

Vc. certamente vai encontrar, se procurar, outros grupos de desenvolvedores defendendo MDI. Toda técnica tem seu partidários e desafetos. Isso não é o suficiente para encarar uma técnica como "ruim".

Já análises imparciais são de mais valia. A pixelcentric e a Wikipedia tem estudos interessantes. Essas fontes eu considero válidas.

Agora, pessoalmente (sim, pq a sua opinião como *usuário* é mais valiosa que a de qualquer catedrático), qual a interface mais confortável: GIMP (Janelas e Diálogos) ou Photoshop (MDI?)??

O que me deixa mais chateado é que o pessoal do GIMP/GTK não implementa corretamente MDI tentando vender a idéia de que janelas avulsas e diálogos são melhores. Isso não é verdade.

Não acho MDI a interface ideal, mas é suficiente para uma interface simples com o mínimo de qualidade. Se quiser subistiuí-la, que seja por uma solução melhor, não pior.

Atualmente, acho que docking é a melhor opção de interface.

Orelhas: "Orelhas" de pastas (tabs) são realmente um recurso melhor.

O que vc. não reparou é que a interface do Firefox é a solução que ambos concordamos ser a mais confortável: Docking. Analise não só a área de documentos, mas toda a interface... Repare como é possível ao usuário reorganizar as áreas da GUI, redimensionando-as ou configurando-as para trocar de lugar.

A única funcionalidade de Docking que o Firefox não implementa é a alternância de áreas de GUI pelo usuário usando "arraste e clique".

GTK+ suporta abas, mas abas por si só não resolvem o problema.

Vc. pode fazer uma interface como a do Firefox em GTK+, mas isso vai exigir muito mais codificação manual (e/ou trabalho no Glade) do que usar um framework de Docking, e os resultados possivelmente serão inferiores.

vícios: > Bom, com bibliotecas de terceiros, é possível fazer qualquer coisa, certo? ;-)

Sim. Mas acho bom assim, pois a inclusão no GTK poderia estimular o uso do MDI. Ao contrário do Linus Torvalds, acho positiva a atitude de desenvolvedores do GNOME e do GTK que tentam evitar os vícios. Por isso, hoje o GNOME requer menos suporte do KDE para end user.


Eu sou de opinião que, para evitar vícios vc. deve substituí-los por uma virtude. Se o vício atende e não há virtude disponível, fico com o que funciona.


Se eu trabalhasse com Java, eu olharia, mas não é o caso.

Não estamos falando de "java" ou "não-java" e sim de usabilidade, independente de plataforma e tecnologia. VLDocking é escrito em java mais poderia ser para outra coisa. Vc. não precisa olhar a API da biblioteca, apenas ver o que é oferecido visualmente.

E atualmente, por causa de 2 projetos que estou envolvido, eu me impressiono mais com componentes para computação distribuida.

Cuidado para o "Nêmesis da Luz" não te chamar de "programador enterprise e seu Ego" ;-)

Mas bem, computação distribuída está fora do nosso escopo nesse tópico. Mas com certeza eu debateria esse assunto com vc. com prazer em uma oportunidade melhor.

> Cuidado para o "Nêmesi:
> Cuidado para o "Nêmesis da Luz" não te chamar de "programador enterprise e seu Ego" ;-)

Hahaha!!! Essa eu queria ver! :^D

O encontro entre o Nemesis da Luz e o Nemesis das Trevas pode resultar no Fim do Mundo do Trolls :))

Nemesis X Nemesis: Espero que não resulte no fim de todos os outros mundos tb... :-))

Cara, esse último dialogo nosso não tem a ver com o tema. Vou moderar essa sua última, modera essa minha mensagem tb.?

vlw

As Orelhas da Raposa de Fogo:
> GTK+ suporta abas, mas abas por si só não resolvem o problema.

Depende do problema.

O GTK tem docking e tem o GtkNotebook (que são as orelhas já prontas para uso). Até agora, não precisei do docking, as orelhas bastaram e os usuários gostaram - e se eles estão felizes, eu fico tambem! :o)

Quando eu encontrar uma App em que orelhas não forem adequadas, eu posso passar para o docking. Mas prefiro continuar evitando MDI e janelas soltas, pois considero tais soluções confusas para o usuário.

Até agora o GTK tem me atendido. Eu testei 4 toolkits antes de homologa-lo.

Orelhas e Docking: O uso de abas faz parte do conceito de Docking.

Entendeu agora?

Os outros aspectos são "glue vertex" (aquela capacidade das janelas de "colarem" umas nas outras para formar a janela maior), minimizar para os cantos da tela, redimensionar as áreas e drag'n drop.

Mas, se vc. usa qquer um desses conceitos de UI, está usando o "novo" conceito que é melhor que MDI e janelas soltas.

Mas entre janelas soltas e MDI, eu fico com MDI.

Até agora o GTK tem me atendido. Eu testei 4 toolkits antes de homologa-lo.

Conhecendo melhores alternativas, eu as uso, ué. ;-)

maníacos: "Eu lembro do Patola aqui no BR-Linux faz tempo"

sei.

"Componentes Swing, por exemplo, são implementados de forma a poderem ser criados por reflexão"

GTK+ implementa, via GLib, um versátil sistema de tipos em tempo de execução, uma espécie de RTTI. Isso quer dizer que, dentre outras coisas, você pode criar widgets em tempo de execução, obter informações sobre determinado componente, e por aí vai. Em outras palavras, por "reflexão".

"são passíveis de transformação em fluxo de byte"

ué, não é pra isso que serve o formato xml de glade em conjunto com libglade?

"tem seu próprio mecanismo de controle de versão,"

ué, qual a surpresa? Java é um sistema operacional completo.

"atuam eles mesmos como conteiner (possibilitando colocar botôes em células de uma tabela, por exemplo)"

desde que um widget derive de GtkContainer ou de seus derivados, essa funcionalidade está presente.

"Eu posso criar uma tabela que exibe dados vindos de um Web Service, por exemplo, com poucas linhas de código."

fantástico! famoso databinding...

"Ei, eu não conhecia isso!"

pois, é. outra razão pra dar uma segunda olhada...

"as opções de gerenciamento de layout disponíveis ao GTK não são tão numerosas ou elaboradas quanto as existentes em Swing/AWT"

novamente, Graças a Deus! :)

Pois como eu disse anteriormente: "As pessoas são facilmente impressionáveis por números e quantidade."

"maior parte da quantidade de código nessa API é *realmente* justificável."

sem dúvida: lucro com cursos para aprender a lidar com a complexidade, lucro com projetos grandes e demorados etc...

"o tamanho da API não é mais um problema, pois tudo é organizado em cima dos mesmos princípios, sendo simples localizar a estratégia perfeita para se fazer o que quer."

do jeito que estou falando, dá até pra pensar que as APIs de GTK/GLib/Atk e companhia são muito menores. Não são, são de tamanho bem razoável, apesar de que boa parte são apenas getters e setters para atributos comuns a alguns widgets. No entanto, como eu disse no início, a API me parece bem mais sã e menos complexa do que Swing. Swing é repleta de redundância e interfaces que não acabam mais.

"extremamente competentes que não atuam no segmento corporativo e pouco usam do J2EE, se é que o fazem."

só os mais loucos, ou deslumbrados, o fazem.

"Por outro lado, já trabalhei com muito programador "enterprise" que se formou em cursinhos de 40 horas e não sabe coisas fundamentais"

é exatamente minha crítica a programadores "enterprise". :)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

matéria x anti-matéria : matéria x anti-matéria

mas não sou materialista, seu programador enterprise! :P

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Moderação:
> Espero que não resulte no fim de todos os outros mundos tb... :-))

Não espalhe, mas o Mundo dos Trolls é o br-linux :/

> modera essa minha mensagem tb.?

Desculpe, mas sou um Troll não registrado :o)

Então, alguem me modere! Valeu!

Luz X Trevas:
Agora o mundo vai acabar! :P

> mas não sou materialista, seu programador enterprise! :P

Eu não trabalho na nave de StarTrek, Luz! Voce está falando do Copérnico :o)

E eu trabalho com a sua linguagem favorita, num lugar aonde voce trabalhou... Portanto, se eu sou, voce tambem é!

que raio de "Maniacos" é esse, seu Nemesis?: ué, não é pra isso que serve o formato xml de glade em conjunto com libglade?

Ei, persiste-se o *estado* dos dados associados ao componente?

ué, qual a surpresa? Java é um sistema operacional completo.

Java não é um sistema operacional, mas sim um ambiente de execução. O mecanismo de controle de verão de swing nada tem a ver com recursos providos pela JVM.

desde que um widget derive de GtkContainer ou de seus derivados, essa funcionalidade está presente

Em Swing, *todos* os componentes são também containers. Não há "desde que".

"as opções de gerenciamento de layout disponíveis ao GTK não são tão numerosas ou elaboradas quanto as existentes em Swing/AWT"

novamente, Graças a Deus! :)

Se eu tiver que, ao usar um framework, tiver que implementar "no braço" alguma funcionalidade *tão fundamental* como gerenciamento de layout, eu desisto do framework. E os gerenciadores no GTK+ não são suficientes para mim.


sem dúvida: lucro com cursos para aprender a lidar com a complexidade, lucro com projetos grandes e demorados etc...


Eu acho *impressionante* que exista alguém na comunidade Linux, que gosta de instalar seus aplicativos em tarball, usar Emacs e linha de comando, passar dias lendo o Linux From Scratch, virar noites assistindo o Gentoo baixar e compilar os pacotes durante a instalação (para detectar e resolver inevitáveis problemas de compilação - pq o make não é o gênio da lâmpada) ou recompilando seu kernel para ter 10% de performance, se intimidar com a "complexidade" do Swing :-))

Swing é repleta de redundância e interfaces que não acabam mais
Vamos sair do reino das suposições e entrar no reino dos fatos? Cite algumas "redundâncias" e vamos analisá-las!

só os mais loucos, ou deslumbrados, o fazem.
Então a maior parte dos desenvolvedores do www.clientjava.com são doidos e deslumbrados. Esse trecho em especial da sua resposta foi trollice. Tem certeza de que é mesmo o nosso colega Nemesis? Ou é + um doppleganger?

é exatamente minha crítica a programadores "enterprise".

Então certamente vc. não está falando dos programadores reais que trabalham com J2EE, que são a maioria dos que atuam no mercado corporativo. A maioria dos que sobram, está desempregada ou mudou de ramo :-)

Tem gente rançosa na comunidade java, principalmente em J2EE? Tem sim.

Da mesma forma que existem os réquers no mundo linux (aliás, grupo formado em sua maioria de falsos "Slackers"). Gente que acha q o conhecimento específico que têm os faz superioes aos outros. Eu procuro manter esse tipo de gente fora dos meus debates e raramente os uso como exemplos de alguma coisa.

são "eles" :): "Ei, persiste-se o *estado* dos dados associados ao componente?"

felizmente, os desenvolvedores do GTK fizeram a sensata opção por separar o modelo de dados subjacente de sua representação enquanto widgets. :)

se vc quer persistir os dados, sugiro BDs, arquivos ou coisa do gênero...

"Java não é um sistema operacional, mas sim um ambiente de execução."

tem certeza? Ele têm seu próprio gerenciamento de memória e de "processos" (threads), como uma CPU. Mas também tem sua própria GUI, seu próprio virtual file system, sua própria interface com BDs etc...

é um sistema operacional, redundante, rodando em cima de outro...

"Em Swing, *todos* os componentes são também containers."

ah, que bom! Sempre pode surgir aquela necessidade de que um label tenha uma tabela integrada...

"E os gerenciadores no GTK+ não são suficientes para mim."

Gozado, para mim eles são uma das maiores razões para eu preferir GTK do que Swing: os gerenciadores do Swing, numerosíssimos e redundantes, são complexos de usar e na maioria das vezes mais atrapalham do que ajudam.

Eu já vi inúmeros programadores java, inclusive experientes, mas principalmente novatos, optando por simplesmente usar null no lugar do gerenciador, pq é um porre tentar fazer o negócio funcionar direito.

FlowLayout, TableLayout... nenhum funciona de forma tão adequada e com tanta facilidade como GtkBox ou GtkTable... e não estou trollando, estou dando minha sincera opinião pessoal.

"Eu acho *impressionante* que exista alguém na comunidade Linux, que gosta de instalar seus aplicativos em tarball, usar Emacs e linha de comando...se intimidar com a "complexidade" do Swing :-))"

vc está me confundindo. Emacs, linha-de-comando ou instalação do fonte são ferramentas para facilitar o uso de recursos do sistema e aumentar a produtividade de usuários avançados. LFS, Gentoo, recompilação de kernel por pouca performance, KDE e Java são perda de tempo , coisa de quem gosta de configurações sem outro motivo...

ok, isso foi um troll. :P

"Vamos sair do reino das suposições e entrar no reino dos fatos? Cite algumas 'redundâncias' e vamos analisá-las!"

Ok. Só pra começar, todas as classes implementando LayoutManager ou LayoutManager2.

Mesmo os básicos -- FlowLayout, BoxLayout, GridLayout -- nunca se comportam exatamente da forma como esperamos. É preciso um bocado de paciência e trabalho pra fazer os ajustes necessários com bordas, espaçamento entre os widgets contidos e coisa e tal. A impressão que tenho é que toda essa tralha que visa dar a sensação de poder e flexibilidade só vem atrapalhar, pq nem os mais simples funcionam adequada ou intuitivamente.

Estava lembrando de outra coisa: como é fácil especificar padding ( espaço livre no interior de um widget ) com toolkits como GTK ou Tcl/Tk e como é terrível ou impossível com Swing.

"Tem certeza de que é mesmo o nosso colega Nemesis? Ou é + um doppleganger?"

sim, estou certo de que sou eu. e não faço idéia do que seja isso.

"Gente que acha q o conhecimento específico que têm os faz superioes aos outros. Eu procuro manter esse tipo de gente fora dos meus debates e raramente os uso como exemplos de alguma coisa."

magoei... :(

"eles" -> programadores "enterprise"

;)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Reino dos fatos: felizmente, os desenvolvedores do GTK fizeram a sensata opção por separar o modelo de dados subjacente de sua representação enquanto widgets. :)

Então vc. admite que o que eu disse láhhh no início, sobre a difeença entre toolkit de widgets e framework completo de apresentação é correto, certo? GTK *não tem* uma estrutura de dados dos widgets, baseada em modelo de delegação.

se vc quer persistir os dados, sugiro BDs, arquivos ou coisa do gênero...

Isso significa que se eu quiser pegar todos os valores dos componentes de uma tela e enviar via rede para outro nó na rede (esse exemplo vem de um sistema de educação a distância que eu estou escrevendo), eu vou ter que escrever uma grande quantidade de código para gravar um arquivo, mandar por ftp, etc.... Entendi. Mas prefiro Swing, graças a ele eu não preciso escrever tudo isso. Basta serializar (2 linhas), pegar o XML e enviar.


tem certeza? Ele têm seu próprio gerenciamento de memória e de "processos" (threads), como uma CPU. Mas também tem sua própria GUI, seu próprio virtual file system, sua própria interface com BDs etc...

é um sistema operacional, redundante, rodando em cima de outro...


Esclarecendo:

Java só implementa gerência de processos para suportar threads quando o SO subjacente não o faz. Caso contrário, usa o q já existe (pthreads, etc).

"Sua própria GUI" (???) Vc. quer dizer frameworks como Swing?

"Seu próprio Virtual File System" - Ei, isso não existe!

"Sua própria interface com BDs" - Não vejo a relação disso com SO, pois isso não é atributo de um. Acho q c ouviu o galo cantar mas não sabe onde...

Ou seja, VM (tal como existe em Java, Smalltalk, .NET) é diferente de "SO". Não vejo nada de "reduntante" nisso. É apenas uma camada de abstração, nada mais.

ah, que bom! Sempre pode surgir aquela necessidade de que um label tenha uma tabela integrada...

Divertido! :-D Mas a utilidade atrás disso é que eu posso escrever códigos com polimorfismo onde trato qualquer componente como JComponent. Nesse caso, eu não vou querer que um componente tenha funcionalidades que o outro não tem. Nem que existam hierarquias paralelas de componentes, etc.

Eu já vi inúmeros programadores java, inclusive experientes, mas principalmente novatos, optando por simplesmente usar null no lugar do gerenciador, pq é um porre tentar fazer o negócio funcionar direito.

"Usar null layout" = "não sabe usar gerenciadores, nem quis aprender e nem sequer sabe dos problemas que terá ao portar para outras plataformas." E que me perdoem seus amigos "experientes": isso mostra que o cara não sabe trabalhar. Quando não se sabe fazer, tudo é impossível. Que nem no Linux. ;)

Ok. Só pra começar, todas as classes implementando LayoutManager ou LayoutManager2.

Não precisa linkar as classes. Eu conheço a API de cabeça... :-P

Mesmo os básicos -- FlowLayout, BoxLayout, GridLayout -- nunca se comportam exatamente da forma como esperamos.

Eu não sei o que vc. espera, mas FlowLayout dispõe componentes em linha reta com o espaçamento e o alinhamento que vc. especifica ao criar o objeto FlowLayout.

BoxLayout dispõe "caixas" (não vou comentar pq quem trabalha com widgets está acostumado a esse conceito)

GridLayout dispoe numa grade de células iguais (novamente, com o espaçamento que vc. informa na criação do Grid).

A impressão que tenho é que toda essa tralha que visa dar a sensação de poder e flexibilidade só vem atrapalhar, pq nem os mais simples funcionam adequada ou intuitivamente.

Eu não sei o que a sua intuição diz, mas pra mim seria intuitivo vc. olhar a api direito antes de sair fazendo! :P

Estava lembrando de outra coisa: como é fácil especificar padding ( espaço livre no interior de um widget ) com toolkits como GTK ou Tcl/Tk e como é terrível ou impossível com Swing.

É fácil e rápido. Basta RTFM!!! Se tu tiver interesse e dúvidas, manda pra mim por e-mail que eu explico.

sim, estou certo de que sou eu. e não faço idéia do que seja isso.

Doppleganger é um troll que se finge de usuário pra ganhar atenção. Tá acontecendo muito aqui ultimamente.

"eles" -> programadores "enterprise"

Se vc. está falando do mesmo grupo que eu, não vejo pq citá-los no seu título. Eu não sou, vc. não parece ser e 80% das comunidades Java e Linux não são "Eles". ;)

há algo de podre no reino...: "Então vc. admite que o que eu disse láhhh no início, sobre a difeença entre toolkit de widgets e framework completo de apresentação é correto, certo?"

certo. Vamos pôr nesses termos: framework é um toolkit realmente grande e incomensurável. :)

"GTK *não tem* uma estrutura de dados dos widgets, baseada em modelo de delegação."

não, não tem. É apenas um simplório toolkit de widgets, a anos-luz de distância da magnificência e funcionalidade da arquitetura Swing do SO Java.

"Isso significa que se eu quiser pegar todos os valores dos componentes de uma tela e enviar via rede para outro nó na rede (esse exemplo vem de um sistema de educação a distância que eu estou escrevendo),"

Eu ainda não estou certo sobre o que exatamente vc está falando: vc está serializando a tela inteira, enviando por uma rede e remontando a tela do outro lado? é isso? Se for isso, talvez já tenha ouvido falar em html, ou talvez de clientes X?... ;)

"eu vou ter que escrever uma grande quantidade de código para gravar um arquivo, mandar por ftp, etc...."

Eu acho mais correto, para fins de persistência, sim. E os dados que estão lá armazenados ficam independentes de "framework", linguagens ou plataformas. Não acredito que um usuário java possa ser preguiçoso! :P

"Basta serializar (2 linhas), pegar o XML e enviar."

e se algum problema ocorrer durante o envio, chorar por não ter persistido os dados de forma adequada...

"Java só implementa gerência de processos para suportar threads quando o SO subjacente não o faz. Caso contrário, usa o q já existe (pthreads, etc)."

Mas vc não entendeu: o programador java acessa tais recursos, nativos ou não da plataforma, por uma mesma API -- a API Java para tais recursos típicos de SO, como threads ou acesso a canais de IO. Ele não usa a API Unix ou Windows. Por isso considero Java um SO. E redundante, pois replica recursos existentes no SO subjacente.

"Vc. quer dizer frameworks como Swing?"

frameworks, toolkits, é tudo API. O que quis dizer é que Swing e AWT são o sistema gráfico nativo do Java e independentes de plataforma. Algo como XLib ou MFC...

"Seu próprio Virtual File System - Ei, isso não existe!"

tá, tá: sua própria API para acesso a recursos de IO.

"Sua própria interface com BDs - Não vejo a relação disso com SO, pois isso não é atributo de um."

é um SO mais completo do que a maioria, em sua sanha de agradar a gregos e troianos. :)

"Mas a utilidade atrás disso é que eu posso escrever códigos com polimorfismo onde trato qualquer componente como JComponent."

ora, e não é que eu posso tratar qualquer widget GTK como GtkWidget?! :P

"Quando não se sabe fazer, tudo é impossível."

haha, até parece que vc nunca fez! :P

não é questão de não saber ou não querer aprender: a questão é que é complicado, mesmo.

"Não precisa linkar as classes. Eu conheço a API de cabeça... :-P"

eu imaginei.

"Eu não sei o que vc. espera"

eu espero que eles façam exatamente o esperado. de preferência -- mas acho que é pedir muito para um tecnologia java -- de forma simples. :)

"É fácil e rápido. Basta RTFM!!!"

Se é tão fácil e tão rápido, pq não postou algum exemplo ao invés me mandar reler a porra do manual monstruoso? Poderia ao menos informar em qual parte do manual se encontra informações sobre como ajustar padding de componentes, já que tem tudo de cabeça?

Eu não acho que é tão fácil assim ajustar o padding interno dos componentes. Com o GridLayout até dá pra ajustar o espaçamento, já que é homogêneo, minha picuinha com ele é que ele nem sempre respeitava as linhas e colunas que eu tinha dito para usar a medida que eu adicionava componentes -- era meio incoerente.

mas a dúvida quanto ao padding é séria. Meus designs usando FlowLayout ou BoxLayout ficam terríveis, por exemplo, porque não encontrei em lugar algum do manual como fazer para especificar o espaçamento entre os componentes filhos.

Em gtk, basta fazer, com GtkBox pai, digamos, gtk_box_set_spacing ou na hora de "empacotar" (pack) o widget filho, com gtk_box_pack_start( pai, filho, bool expand, bool fill, int padding )...

simples, nada de ficar horas destrinchando hierarquias e mais hierarquias para tentar achar uma coisa tão básica e necessária em criação de GUIs.

Meu último apelo, então: mostre como se faz em Swing. Se for simples, eu nunca mais ataco Java nesse fórum. ;)

"Doppleganger é um troll que se finge de usuário pra ganhar atenção."

ah! eu não! eu sou só um usuário que se finge de troll. :)

"80% das comunidades Java e Linux não são 'eles'"

não é o que parece na comunidade Java. A maioria que conheço são realmente arrogantes e ingênuos...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Limpando...: certo. Vamos pôr nesses termos: framework é um toolkit realmente grande e incomensurável. :)

Não. A diferença entre um framework e um toolkit é que em um framework os componentes são criados para se relacionarem fortemente entre si de uma forma específica e coesa. Se o framework é de "caixa preta" (blackbox framework), a interação entre seus componentes é mais transparente para o usuário, que o personaliza com herança mais que com composição (ex. em Java: Servlets, Swing). Se o framework é de aberto, ou de "caixa branca" (whitebox) ele é formado de um conjunto de componentes que se relacionam entre si de forma livre e o usuário emprega mais agregação e composição que herança (ex. em Java: JCF - API de coleções - onde cada uma pode ser criada a partir de outra, java.io, java.nio, etc.)

Toolkit é só um conjunto de bibliotecas que trabalham no mesmo escopo, mas os elementos não dependem conceitualmente uns dos outros. Em Java, Swing é um Framework completo, AWT é um Toolkit, assim como SWT.

Então, posso colocar o GTK+ ao lado do AWT e ao SWT, mas não do Swing.

Eu ainda não estou certo sobre o que exatamente vc está falando: vc está serializando a tela inteira, enviando por uma rede e remontando a tela do outro lado? é isso? Se for isso, talvez já tenha ouvido falar em html, ou talvez de clientes X?... ;)

HTML não tem o poder necessário, e clientes X têm uma performance muito menor, pois trafegam mais dados pela rede... Quero transportar só o estado, não o desenho da tela! Seria estúpido fazer isso. ;-)

e se algum problema ocorrer durante o envio, chorar por não ter persistido os dados de forma adequada...

"Persistir de forma adequada" dados que só têm validade em tempo real é burrice! Se o Godzilla pisar nos cabos de rede meus dados continuam a salvo no ponto de origem e serão transmitidos atualizados, quando a conexão voltar. Eu nem precisava responder a isso!

Ele não usa a API Unix ou Windows. Por isso considero Java um SO. E redundante, pois replica recursos existentes no SO subjacente.

tá, tá: sua própria API para acesso a recursos de IO.

Dããããã.... Qualquer linguagem de programação (excetuando Assembly) acessa os recursos de SO através de sua própria API de alto nível, certo? Isso não faz delas um "Sistema Operacional".

é um SO mais completo do que a maioria, em sua sanha de agradar a gregos e troianos.

Não. É apenas uma plataforma de desenvolvimento que tem um framework de acesso a banco, oras.

Acho melhor abandonar essa linha de raciocínio Java == SO. Não tá funcionando!:-P Se vc. quiser *realmente* ver um SO escrito em Java, visite www.jnode.org e veja a diferença.

ora, e não é que eu posso tratar qualquer widget GTK como GtkWidget?! :P

Não para o que eu estou dizendo. JComponent é um container, GtkWidget não é.

Se é tão fácil e tão rápido, pq não postou algum exemplo ao invés me mandar reler a porra do manual monstruoso? Poderia ao menos informar em qual parte do manual se encontra informações sobre como ajustar padding de componentes, já que tem tudo de cabeça?

Pq isso aqui não é um forum sobre Java. Vai em www.javafree.org e posta suas dúvidas que eu respondo com prazer. Ou me manda e-mail (copernico.vespucio.publico@gmail.com). Ou sugere pro Augusto abrir um fórum sobre Java aqui no br-linux. Postar código aqui não tem cabimento, oras!

Com o GridLayout até dá pra ajustar o espaçamento, já que é homogêneo

Todos os gerenciadores de layout básicos são homogêneos quanto ao espaçamento. Se vc. quiser especificar espaçamentos diferentes é que vc. vai precisar de outros mais elaborados, como SpringLayout, GridBagLayout ou JGoodies FormLayout.

Se é tão fácil e tão rápido, pq não postou algum exemplo ao invés me mandar reler a porra do manual monstruoso?

Não é assim que a "elite" faz com os newbies? Mas sério, não é monstruoso. É só acessar o javadoc e prestar atenção... :-P

Meu último apelo, então: mostre como se faz em Swing. Se for simples, eu nunca mais ataco Java nesse fórum. ;)

Hehe... Pode continuar atacando se quiser, não me intimido :-D. Mas não respondo aqui, é sair muito do tema inicial (lembra dele?). Até colar o link da resposta em um fórum qualquer, mas aqui não.

não é o que parece na comunidade Java. A maioria que conheço são realmente arrogantes e ingênuos...

Acho que vc. começou com o pé esquerdo e conheceu os desenvolvedores Java errados (os 20% que faltam). Entra no javafree.org.

polindo: "Não. A diferença entre um framework e um toolkit é que em um framework os componentes são criados para se relacionarem fortemente entre si de uma forma específica e coesa."

Os widgets GTK também "se relacionam fortemente entre si de uma forma específica e coesa". Eu disse que framework é um toolkit realmente grande, pq inclui muitas coisas a mais que toolkits mais simples esnobam, como serialização, por exemplo.

"Em Java, Swing é um Framework completo, AWT é um Toolkit, assim como SWT."

falho em notar a diferença, tirando funcionalidade a mais que nem sempre é necessária.

"Quero transportar só o estado, não o desenho da tela!"

ah, agora sim! Estado dos checkboxes e radiobuttons, certo? E os textos de caixas texto e a cor do label de alerta e a seleção atual do combobox e o menu dropdown selecionado, né?

É, não consigo imaginar um cenário em que seria útil eu enviar tais informações em tempo real para outro ponto -- excetuando talvez aplicações como terminal server para controle remoto de um aplicativo -- mas reconheço que não há uma forma simples de fazê-lo com GTK.

"'Persistir de forma adequada' dados que só têm validade em tempo real é burrice!"

não tinha entendido o que vc queria dizer ou fazer.

"Qualquer linguagem de programação (excetuando Assembly) acessa os recursos de SO através de sua própria API de alto nível, certo? Isso não faz delas um 'Sistema Operacional'."

De certa forma faz sim: um programador Delphi só enxerga o sistema subjacente através da VCL, o mesmo para um programador Python ou .NET. O ambiente de desenvolvimento é o ambiente operacional do programador. Porém, Delphi produz um executável que roda utilizando os recursos nativos, ao passo que com .Net, Java, Python e afins, há um "SO" em tempo de execução também, fazendo todo o gerenciamento de memória e usando seus próprios recursos redundantes por cima do SO real.

"Não tá funcionando!"

tá, sim. Não para linguagens com compiladores para código nativo, mas para linguagens rodando em VMs o raciocínio é perfeito, ainda mais com uma VM e milhões de bibliotecas que rodam em cima dessa VM, formando uma plataforma completa, com seu próprio sistema de IO, sua própria GUI etc...

"Não para o que eu estou dizendo. JComponent é um container, GtkWidget não é."

vc pode armazenar qualquer em um GObject, com g_object_set_data (GObject *object, const gchar *key, gpointer data). Sim, qualquer GtkWidget é também um GObject. :)

"Postar código aqui não tem cabimento, oras!"

deixa eu ver se entendi: parece que é mais fácil postar parágrafos e mais longos parágrafos de desculpas do que simplesmente ajustar padding no Swing. Por isso eu digo que o Swing não é simples.

"como SpringLayout, GridBagLayout ou JGoodies FormLayout."

é, por isso que Swing precisa de tanta redundância e uma API tão grande: é especialização demais e generalização e flexibilidade de menos. FlowLayout, por exemplo, me parece completamente inútil, quando não dá pra especificar espaçamento entre seus componentes. É horrível ver eles todos juntinhos, comprimidos.

prefiro a maneira simples de GTK, especificando o espaçamento na mão, na hora de empacotar na tela.

"É só acessar o javadoc e prestar atenção..."

lamento, mas nada ainda.

"Pode continuar atacando se quiser, não me intimido :-D. Mas não respondo aqui, é sair muito do tema inicial (lembra dele?)."

certo, pode continuar com suas desculpas que eu prometo que continuo no pé do java. ;)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Guardando...: Mais curto agora, pq o "limite vertical" chegou...
há um "SO" em tempo de execução também, fazendo todo o gerenciamento de memória e usando seus próprios recursos redundantes por cima do SO real.

SO não, pelamordedeus... Camada de abstração! Não existem recursos de SO, nem forçando *muito* a barra. Se houvessem os recursos de SO nas VM, elas poderiam acessar diretamente o hardware, coisa que não ocorre (com exceção de algumas KVM que rodam em celulares sem SO).

longos parágrafos de desculpas do que simplesmente ajustar padding no Swing. Por isso eu digo que o Swing não é simples.

Já falei que concordo em te ajudar, cara. Mas aqui não. Tem um fórum aqui no BR-Linux. Abre um tópico e me avisa. Aí vc. pode ser + claro sobre o que precisa e eu posso ser claro em responder.

FlowLayout, por exemplo, me parece completamente inútil, quando não dá pra especificar espaçamento entre seus componentes. É horrível ver eles todos juntinhos, comprimidos.

Seta o alinhamento e o espaçamento dele, qual é o problema? Só um snipet:

//Alinha a esquerda, 10 pixels de espaçamento vertical e horizontal.
FlowLayout fw = new FlowLayout(FlowLayout.LEFT, 10, 10);
seuContainer.setLayout(fw);

Complicado d+ pra você? Só que eu quero q vc. me diga a tela que quer fazer e eu mostro como se faz, ok? Mas *não* aqui! Já tô sentindo claustrofobia!

Resposta curta, pv.

ok: "Não existem recursos de SO, nem forçando *muito* a barra. Se houvessem os recursos de SO nas VM, elas poderiam acessar diretamente o hardware, coisa que não ocorre"

Ela acessa o "hardware" de baixo: o SO subjacente. Não é forçar, é reconhecer que a VM Java tem sua própria gerência de memória, de threads, seus próprios mecanismos de IO etc, que são recursos básicos de qualquer SO.

"Complicado d+ pra você?"

ok, desisto. Não estou mais programando em Java recentemente e não me lembro exatamente de quais partes mais me irritavam. Lembro que tentar ajustar padding com LayoutManagers me enjoava, principalmente com BoxLayout. Além, é claro, da verbosidade e grandiloqüência da linguagem, de suas APIs e ferramentas... :)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

hum!: Lerei todos! :-)

--
Direito de escolha combina com software livre. (Augusto Campos)
JID: emerson.pardo

Câmbio, Desligo: Sobre a semelhança Java X SO:

Não reconheço.

Sobre padding, BoxLayout tb. é mole (e bem menos verborrágico do que c mostrou no GTK). Te mostrei uma coisa que esteve na sua cara o tempo todo, na API do FlowLayout, era só ler.

Se vc. não lembra mais o que te "irritava", aceito aquele seu oferecimento de "não atacar mais o Java nesse fórum", o que acha? LoL!!!