Re: [python-brasil] Imprimir em uma folha!
Rodrigo
"Joao S. O. Bueno Calligaris" <gwi...@mpc.com.br> wrote:
> On Wednesday 29 September 2004 10:41, Fabio Rizzo Matos wrote:
> > > Oi Fábio..
> > > Eu brinqueium pouco com isso ontem a noite (uma hora alguém vai
> > > ter que escrever um tutorialzinho e colocar na nossa página, nao
> > > é? ) E 1) Nao consegui cehgar no ponto de de fazer a impressao
> > > sem criar pelo menos uma janela do Tkinter na tela - mas já
> > > disseram aqui que tem jeito.
> > > 2) Infelizmente a impressão do TKinter nao embute as fontes
> > > utilizadas no arquivo de postscritp - usando as fotnes padrão da
> > > impressora (ou do ghostview).
> > >
> > > --
> > > Acho o seguinte: precisamos encontrar uma forma legal de fazer a
> > > impressão em python. Eu tenho algum conhecimento de postscript.
> > > Será que o pessoal da lista poderia comenatr algo a respeito dos
> > > metodos que sugeri,ou outros, para que possamos desenvolver mais
> > > funcionalidades para um deles? Ai já fica pronto pra todo mundo!
> > >
> > > Um abraço,
> >
> > Vc poderia mandar o código para eu ver?
>
> Tava brincando no modo interativo ... na verdade, nao passei muito do
Quanto sacrificio!!! Eu andei pesquisando e não descubri nenhum metodo legal pra gerar postscript(tem umas bibliotecas mas a melhor que eu encontrei não consegui instalar direito pq é meio doidona)
Ai eu decidi usar PDF mesmo( a formatação é a mesma e o resultado impresso é bem confiavel), bom com PDF o trabalho é simples, você pega o reportlab (www.reportlab.org) e usa ele pra gerar pdf e depois faz o que quiser com ele(a vantagem do postscript é que no Linux ele imprime direto , mas no Windows você nem nota a diferença alem disso quase todo mundo tem o acrobat reader)
A vantagem do reportlab é que você não precisa fazer tudo na mão ,ele tem um modulo que permite o uso de templates e tabelas pra gerar os pdf e é escrito totalmente em python e orientado a objetos, ou seja facíl de expandir(Não que você vá expandi-lo diretamente mas com certeza vai querer criar objetos como cabeçalhos e footers alem dos seus própios templates pra reutilizar sempre) e é totalmente portavel (ele tem um modulo em C mas parece que ele somente aumenta a performance do modulo ele parece rodar sem o mesmo)
--
,= ,-_-. =.
((_/)o o(\_))
`-'(. .)`-'
\_/
* Antes de enviar a sua pergunta procure por uma solução em:
http://pythonbrasil.com.br/
http://python.org
http://google.com
* Não envie e-mails HTML para a lista.
* Evite mensagens off-topic
Links do Yahoo! Grupos
<*> Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/python-brasil/
<*> Para sair deste grupo, envie um e-mail para:
python-brasi...@yahoogrupos.com.br
<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html
Juracy Filho
Roberto, eu também sou programador Delphi, e entendo seus problemas,
mas se analisarmos bem veremos as seguintes justificativas:
1 - Python é multiplataforma, o que por si só já complica
procedimentos deste tipo.
2 - O próprio delphi não possui nativamente suporte avançado a
impressão, o que você pode fazer é usar a classe TPrinter e desenhar
no canvas dele e depois ele manda para o subsistema de impressão do
Windows. As soluções que vem no pacote (até o delphi 6, QuickReport e
a partir do 7 Rave) são de terceiros e são altamente amarradas ao
sistema operacional.
3 - Soluções de impressão multiplataforma são dificies por que não
existe uma API padronizada para acesso ao sub-sistema de impressão nos
diversos SO's, restando então ao programa fazer vários IF's para
tratar cada SO em especifíco.
4 - Sempre existe a opção de definir uma plataforma de destino (Unix,
Windows, etc.) e escrever código usando API própria, por exemplo no
Windows você pode até usar automação no Microsoft Word e montar seu
relatório como um DOC e imprimir ou criar um PDF e controlar o Adobe
Acrobat (via DCOM, acredito ser possível) e imprimir
transparentemente.
Não desanime. :D
On Thu, 30 Sep 2004 20:33:09 -0000, Roberto Bechtlufft
<oraki...@yahoo.com.br> wrote:
> Eu passei uma época super-empolgado com Python, mas esses problemas
> para imprimir foram um tremendo balde de água fria...
>
> Tem esse negócio de gerar PDF, postscript, esse rolo todo... acho tudo
> isso muito complicado. Por quê é tão difícil fazer o python imprimir
> os resultados da mesma forma que, por exemplo, um delphi é capaz de
> fazer? Será que nunca vai haver uma solução desse tipo para python?
>
--
Juracy Filho
Joao S. O. Bueno Calligaris
> Eu passei uma época super-empolgado com Python, mas esses problemas
> para imprimir foram um tremendo balde de água fria...
>
> Tem esse negócio de gerar PDF, postscript, esse rolo todo... acho
> tudo isso muito complicado. Por quê é tão difícil fazer o python
> imprimir os resultados da mesma forma que, por exemplo, um delphi é
> capaz de fazer? Será que nunca vai haver uma solução desse tipo
> para python?
>
Por que?
Porque o Delphi nao é uma "linguagem de programação".
Delphi é um aplicativo gráfico capaz de gerar progrmas executaveis,
que sua como linguagem de programação Pascal Orientado a Objeto.
Mais ainda, Delphi é para uma única plataforma, que usa um único tipo
de widgets e tem uma API unificada para impressão. (O Kylix usa
recursos de emulação da API do Windows em outros ambientes - uma
camada de tradução)
Python é uma solução de programação genérica - ele faz computação:
manipula dados e strings. Os ambientes gráficos em geral fornecem a
API para impressão que estamos procurando - não vi ninguem nessa
lista falar em usar Python QT ou Python KDE por exemplo - a solução
de impressão está no QT/KDE - como no caso do TKinter que vinhamos
discutindo - a API de impressão está no TKinter. A geração de
postscript é apenas uma camada e uma solução multiplataforma de
impressão.
Eu diria que certamente existe uma biblioteca python "windows only"
que use a API de impressão do windows - (/me chamando google: a
solu;ção é usar o pywn32 e com ele, a apinativa de impressão) mas ai,
como a impressão do QT, não seria uma solução multiplataforma..
Ese reportlabs estaremos testando agora - de repente é algo simples.
De repente é algo que com mais 1 linha de código - para chamar o
ghostscript para imprimir, se tenha uma soluçao genérica de
impressão: ou seja uma funçãozinah de 5linhas que qualquer um pode
por em qualquer porgrama.
mAs python é uma linguagem de programação genérica multiplataforma -
não um aplicativo gráfico. Tanto é que não há um padrãopara criar
aplicações gráficas - nessa lista fala-se bastante em python+GTK,
WxPython e python pra Web - ainda existem Pywin, PyQt, TKinter,
Jython + Swing, Pygame, Curses -- ou seja, vários framworks
diferentes para se desenhar na tela os controles e interfaces
gráficas.
A solução unificada de impressão é algo provido pelo sistema
operacional. E no caso dos sistemas POSIX, essa solução é o CUPS que
usa como entrada o postscript - no caso do windows é uma API, que,
salvo engano, usa chamadas semelhantes ao Windows MEta FIle. Alguém
poderia fazer um acesso direto a um edterminado modelo de impressora
pela porta paralela e gerar código pra impressora diretamente - como
os antigos programas pré-windows tinham que fazer. A linguagem provê
flexibilidade para isso.
Ninguém teria menos "trabalho" para imprimir se estivesse usando
qualquer outra linguagem de programação: tente achar exemplos de
impressão em "C", ou mesmo em pascal Oritnado a Objeto, sem usar
Delphi.
Espero que essa questão tenha ficado clara.
JS
-><-
cpsribeiro
<gwidion@m...> escreveu
> On Thursday 30 September 2004 17:33, Roberto Bechtlufft wrote:
> > Eu passei uma época super-empolgado com Python, mas esses problemas
> > para imprimir foram um tremendo balde de água fria...
> >
> > Tem esse negócio de gerar PDF, postscript, esse rolo todo... acho
> > tudo isso muito complicado. Por quê é tão difícil fazer o python
> > imprimir os resultados da mesma forma que, por exemplo, um delphi é
> > capaz de fazer? Será que nunca vai haver uma solução desse tipo
> > para python?
> >
>
> Por que?
>
> Porque o Delphi nao é uma "linguagem de programação".
> Delphi é um aplicativo gráfico capaz de gerar progrmas executaveis,
> que sua como linguagem de programação Pascal Orientado a Objeto.
> Mais ainda, Delphi é para uma única plataforma, que usa um único tipo
> de widgets e tem uma API unificada para impressão. (O Kylix usa
> recursos de emulação da API do Windows em outros ambientes - uma
> camada de tradução)
Esse é meu primeiro 'post' no grupo, mas eu fico à vontade para
responder, porque já usei Delphi desde o beta (antes do 1.0, em
disquete!), e uso Python já fazem uns quatro anos. Mas atenção,
mensagem longa!
Na minha opinião, a diferença é a seguinte: Delphi é uma *plataforma*
completa, um conjunto de linguagem de programação, ambiente de
desenvolvimento, e bibliotecas extremamente bem integradas. Quando
você usa Delphi, você acaba usando de forma implícita uma outra coisa:
a arquitetura do VCL, que quase obrigatoriamente permeia todas as
aplicações escritas em Delphi. O ambiente de programação (IDE) gera
automaticamente o código básico necessário para "juntar " as peças.
Por exemplo, seja para abrir um form, ou para criar um relatório, é
necessário um conjunto mínimo de código, chamando as coisas na ordem
correta, de acordo com o modelo ditado pela biblioteca. Mas o
programador não precisa dominar estes detalhes, porque o ambiente gera
este código automaticamente, seja na forma de código fonte (em
Delphi), ou seja na forma da linguagem de recursos (os arquivos de
descrição de forms, relatórios, etc.).
Python é uma linguagem de programação com um conjunto de bibliotecas
extremamente poderoso e portável, mas que ainda não tem a mesma
abrangência da VCL. Por exemplo: existem muitas APIs gráficas, mas
nenhuma que se possa dizer que faça parte do "kit básico da
linguagem". Com relatórios é a mesma coisa. A parte de banco de dados
é apenas um pouquinho melhor --- pelo menos a API está padronizada
(DB-API 2.0), mas ainda fica longe do Delphi por causa da falta de
controles de edição 'data-aware'.
Por outro lado, se você vai escrever código para rodar em rede a
nível TCP/IP, Python oferece recursos muito superiores, tanto para
desenvolvimento rápido (prototipagem) como para o código final. A
diferença é que esta parte da API está madura e muito bem consolidada.
O que falta para que Python possa ser usada no lugar do Delphi? Na
minha opinião, não é um problema da linguagem em si, e nem mesmo das
bibliotecas. Falta um "framework", uma arquitetura básica para
aplicações comerciais, que funcione como um ponto de partida para
escrever programas comerciais simples.
No Delphi, ao abrir o IDE e criar um novo projeto, a organização
básica do código já foi feita para o programador. Criou-se um programa
principal, que inicializa automaticamente os forms, abre o form
principal, e transfere o controle para a aplicação (através do objeto
Application). Se o programador tivesse que fazer esse pequeno trecho
de código manualmente, ele teria provavelmente que ler vários manuais,
para entender como é que os forms se relacionam com a aplicação, etc.
Mas o template de código já está pronto, e o programador simplesmente
o utiliza. Apesar de super simplificado, o processo traz dois
benefícios importantes.
1. O programador se sente produtivo logo no primeiro momento, e isso é
importante para manter a sua motivação.
2. A estrutura básica do código fica padronizada, o que facilita a
troca de trechos de código entre programas, e também a troca de idéias
entre programadores.
Com Python, tudo é diferente. Mesmo que dois programadores usem a
mesma API gráfica -- wxPython, por exemplo -- é provável que eles
estruturem se código de forma totalmente diversa. Isso torna mais
difícil a integração, e obriga o programador a gerenciar manualmente
partes do seu código que poderiam ser facilmente gerenciadas pelo
ambiente de desenvolvimento.
A abordagem do Python tem suas vantagens, no sentido em que dá mais
controle ao programador. Mas no caso de aplicações simples, o processo
é desnecessariamente trabalhoso. Imagino que um programador Python que
já esteja trabalhando com a linguagem há alguns anos, e gerando código
comercial, tenha à sua disposição sua própria arquitetura pessoal. No
entanto, transferir este know how para terceiros, mesmo com código
aberto e gratuito, é difícil. A forma 'correta' de usar a biblioteca
muitas vezes fica implícita, e sem uma boa documentação, é difícil
fazer com que um novato se torne produtivo com ela.
Finalmente, acho que concordo com a afirmação original -- é uma pena
que dê tanto trabalho para fazer coisas básicas em Python. A linguagem
merece um destino melhor...
Carlos Ribeiro
carri...@gmail.com
Osvaldo Santana
Quanto você pagou pelo Delphi e quanto você pagou pelo Python? (não
vale usar Delphi pirata ou aquelas versões antigas que vinham e
revistas)
Python é uma linguagem de programação livre e aberta. Qualquer um,
inclusive você, pode desenvolver um mecanismo de impressão para
incluir na biblioteca padrão do Python. Se o seu mecanismo realmente
for bom você ainda corre o risco de ficar famoso e ajudar muita gente.
Outra coisa importante a ser dita é: Delphi tem um mecanismo de
impressão, mas ObjectPascal não tem. Como a filosofia da linguagem
Python é "Batteries Included" foi adicionado à linguagem um suporte a
impressão no módulo Tkinter. Pode não ser um mecanismo tão completo
quanto o do Delphi mas pode ser melhorado por qualquer um (repito:
inclusive você)
Pra piorar mais ainda as coisas: Você pode imprimir coisas em Python
usando postscript, pdf, html, system('lpr'), win32api, Tkinter, ....
em Delphi... bem, em Delphi você tem *o* mecanismo dele e ponto final.
E se precisar de outros provavelmente você tem sorte de achar um
componente de $30 que faça isso.
Agora falando sobre a dificuldade de se implementar um esquema de
impressão para o Python:
Diferente do Delphi que só funciona no Windows (o Kylix existe ainda?)
a linguagem Python é multiplataforma. Impressão no windows funciona de
um jeito, nos Unixes (Linux) funciona de outro, e no MacOS de uma
terceira forma (ou agora é compatível com o Linux?). Se você for fazer
um módulo de impressão que pode se tornar o padrão do Python você tem
que fazer ele funcionar em todas as plataformas onde Python funciona.
Sentiu o tamanho do drama?
Valeu,
Osvaldo
On Thu, 30 Sep 2004 20:33:09 -0000, Roberto Bechtlufft
<oraki...@yahoo.com.br> wrote:
> Eu passei uma época super-empolgado com Python, mas esses problemas
> para imprimir foram um tremendo balde de água fria...
>
> Tem esse negócio de gerar PDF, postscript, esse rolo todo... acho tudo
> isso muito complicado. Por quê é tão difícil fazer o python imprimir
> os resultados da mesma forma que, por exemplo, um delphi é capaz de
> fazer? Será que nunca vai haver uma solução desse tipo para python?
>
> --- Em python...@yahoogrupos.com.br, Fabio Rizzo Matos
> <fabiorizzo@g...> escreveu
> > Vou tentar usando a biblioteca da reports labs. Não consegui com o
> > tkinter. Alguem ja usou? Tem alguma manha?
> >
> > valeus
--
Osvaldo Santana Neto (aCiDBaSe)
icq, url = (11287184, "http://www.pythonbrasil.com.br")
Rodrigo Dias Arruda Senra
[ "cpsribeiro" <carri...@gmail.com> ]
-----------------------------------------------
| Esse é meu primeiro 'post' no grupo, mas eu fico à vontade para
| responder, porque já usei Delphi desde o beta (antes do 1.0, em
| disquete!), e uso Python já fazem uns quatro anos. Mas atenção,
| mensagem longa!
Pena que é o primeiro ;o)
Já poderia estar dando bizzus a mais tempo hehehe.
Valeu Carlos
| Python é uma linguagem de programação com um conjunto de bibliotecas
| extremamente poderoso e portável, mas que ainda não tem a mesma
| abrangência da VCL.
Não é o Python, mas a Standard Library. O Andrew (amk) levantou esse
problema recentemente em sue blog, e acredito que veremos progressos
nessa área logo.
| Por exemplo: existem muitas APIs gráficas, mas
| nenhuma que se possa dizer que faça parte do "kit básico da
| linguagem".
Eu não tenho o que reclamar do wxPython.
| mas ainda fica longe do Delphi por causa da falta de
| controles de edição 'data-aware'.
É verdade.
| Por outro lado, se você vai escrever código para rodar em rede a
| nível TCP/IP, Python oferece recursos muito superiores,
Isso sem nem mencionar o Twisted, pois aí já vira covardia =)
| Com Python, tudo é diferente. Mesmo que dois programadores usem a
| mesma API gráfica -- wxPython, por exemplo -- é provável que eles
| estruturem se código de forma totalmente diversa.
Aqui eu discordo um pouco. Isso pode acontecer no Delphi também.
| sem uma boa documentação, é difícil
| fazer com que um novato se torne produtivo com ela.
Acho que isso é válido para qualquer tecnologia: Python, Pascal,
C, Java, Perl, Ruby, Smalltalk, e vai ...
| Finalmente, acho que concordo com a afirmação original -- é uma pena
| que dê tanto trabalho para fazer coisas básicas em Python.
Vc acha que dá tanto trabalho ? Que coisas ? Tirando interfaces
gráficas (e isso porque ainda não comprei o wxDesigner, mas vou)
acho que o Python bate o Delphi em qualquer outro nicho.
[]s
Senra
,_
| ) Rodrigo Senra <rsenra |at| acm.org>
|(______ -----------------------------------------------
_( (|__|] GPr Sistemas http://www.gpr.com.br
_ | (|___|] IC - Unicamp http://www.ic.unicamp.br/~921234
___ (|__|]
L___(|_|] -----------------------------------------------
Carlos Ribeiro
On Fri, 01 Oct 2004 23:53:44 -0300, henrique paiva
<paivah...@terra.com.br> wrote:
> > Bom, muito bom. Só duas sugestões:
> > a) faça apenas uma interface sobre as várias maneiras de imprimir que há
> > - não deixe a interface muito presa ao reportlab, de modo que seja
> > impossível reimplementá-la usando cups ou API do Windows.
> > b) tire umas férias, trabalhe como um louco e volte daqui a dois meses
> > com uma parte do seu módulo minimamente funcional. Como dira o
> > subcomandante Marcos: "Começar algo é trabalho de poucos; terminar é
> > trabalho de todos"[1]. Projetos que começam com mutirão normalmente não
> > dão serto, mas os que andam sobre algo já feito (mesmo que muito pouco
> > feito) têm mais chances de ir para a frente.
> >
> > [1] Desculpe, a minha professora de filosofia repete tanto isto que tive
> > de citar :D
> é impressão minha ou tem uma influência Zapatista na sua citação.
> ótimo.
Que ficou Zapatista, ficou! Mas independente de política, a citação
descreve muito bem s projetos de código livre que deram certo. É
importante que haja uma liderança forte e uma base de código funcional
para que o projeto decole.
Aliás, já que estamos falando de Python, provavelmente todos conhecem
a alcunha associada ao Guido -- "BDFL", ou "Benevolent Dictator For
Life". Pois é, ditaduras funcionam em código livre :-) Mas é claro que
há uma diferença fundamental, chamada *livre escolha* -- em código
livre, pode até existir um "ditador", mas qualquer um é livre para
fazer o que quiser - usar ou não usar, ou até mesmo pegar o projeto no
ponto em que estiver e dar um "fork", o que já aconteceu até com
projetos grandes. Isso mantém o "ditador" honesto e coíbe os arroubos
de grandeza das ditaturas reais...
--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carri...@gmail.com
mail: carri...@yahoo.com
Rodrigo Dias Arruda Senra
[ Carlos Ribeiro <carri...@gmail.com> ]
-----------------------------------------------
| Acho a documentação do wxPython terrível. Tem muita coisa que ainda só
| está documentada em C++, o que torna desnecessariamente complicadas as
| coisas. Também falta uma documentação básica, introdutória, que mostre
| como começar novos projetos com o wxPython, etc. (esse negócio de
| mostrar samples e falar para o pessoal editar o sample é coisa para
| 'hacker', não para usuário normal).
Eu me dou bem com o esquema de exemplos ;o)
Mas concordo que falta ainda chão pro wxPython no quesito documentação.
| > | Por outro lado, se você vai escrever código para rodar em rede a
| > | nível TCP/IP, Python oferece recursos muito superiores,
| >
| > Isso sem nem mencionar o Twisted, pois aí já vira covardia =)
|
| Eu não tive paciência de tentar entender o Twisted. Mas que o projeto
| é bem estruturado, e poderoso, isso é.
Tenho certeza que vai tirar de letra se brincar com ele por umas duas
horas. E vale à pena.
| > | Com Python, tudo é diferente. Mesmo que dois programadores usem a
| > | mesma API gráfica -- wxPython, por exemplo -- é provável que eles
| > | estruturem se código de forma totalmente diversa.
| >
| > Aqui eu discordo um pouco. Isso pode acontecer no Delphi também.
|
| No Delphi é mais difícil, porque o IDE na prática conduz o
| programador, fazendo com que ele utilize certos 'idiomas' comuns.
Vc está falando dos templates gerados para os event-handlers ou da
estrutura natural de programas em Pascal var,const,interface,implementation ?
No Delphi o caboclo também pode usar uma estrutura complexa de classes, ou
de procedures+funções, ou criar um código tão macarrônico quanto se queira.
Ou seja, dois programadores podem criar códigos object-pascal bem diferentes
para resolver o mesmo problema. Eu sei pois usamos Delphi da 1.0 até a 4.0,
e dei manutenção em código de muita gente :o(
Mas em útlima instância estamos falando da mesma coisa =)
| Não sei as versões mais recentes -- essas já devem ter ficado complicadas demais
| -- mas os manuais do VB 2.0 e do Delphi 2.0/3.0 eram muito bons,
| especialmente porque não se limitavam a ser um índice de funções, mas
| porque explicavam claramente a filosofia da ferramenta, e falavam omo
| é que certas coisas deveriam ser feitas, e por quê deveriam ser feitas
| daquela forma.
Bom, é uma questão de alguém se voluntariar para escrever. No caso do
Delphi e do VB tinha gente sendo paga para escrever. Python tem uma documentação
excelente na minha opinião, acho que o wxPython chega lá.
|
| > | Finalmente, acho que concordo com a afirmação original -- é uma pena
| > | que dê tanto trabalho para fazer coisas básicas em Python.
| >
| > Vc acha que dá tanto trabalho ? Que coisas ? Tirando interfaces
| > gráficas (e isso porque ainda não comprei o wxDesigner, mas vou)
| > acho que o Python bate o Delphi em qualquer outro nicho.
|
| Não é só a questão da interface gráfica. A falta de um sistema de
| edição 'data-aware' pega *muito*.
Touché. Veja que componentes data-aware estão diretamente relacionados com
a interface gráfica. Mas vc levantou uma questão interessante, não sei se
algum dos toolkits gráficos para o Python (PyQt, PyGtk, wxPython, PyhtonCard,
Tkinter3000, etc) possuim uma implementação de data-aware componentes em andamento.
É sem dúvida um projeto útil e interessante.
Alguém se habilita ?
Abração
Rodrigo
>
> > | Por exemplo: existem muitas APIs gráficas, mas
> > | nenhuma que se possa dizer que faça parte do "kit básico da
> > | linguagem".
> >
> > Eu não tenho o que reclamar do wxPython.
>
> Acho a documentação do wxPython terrível. Tem muita coisa que ainda só
> está documentada em C++, o que torna desnecessariamente complicadas as
> coisas. Também falta uma documentação básica, introdutória, que mostre
> como começar novos projetos com o wxPython, etc. (esse negócio de
> mostrar samples e falar para o pessoal editar o sample é coisa para
> 'hacker', não para usuário normal).
Diferencie o hacker do usuario normal no quesito programação.
No meu entender se você esta programando ja não pode se considerar um usuario, e ler codigos fonte é uma maneira pratica de se aprender, não que eu discorde no quesito falta de documentação do wx, os samples não exploram nem metade dos recursos da bilioteca e falta algo mais avançado, esse problema alias acontece em outros também, eu terminei um programinha em wx, mas como ficou muito pesado eu preciso passar ele pra Gtk, o programa usa um TreeView e eu to quase ficando louco por causa do infeliz( o do wx é umas duzentas vezes mais simples)
> Aqui eu discordo um pouco. Isso pode acontecer no Delphi também.
>
> No Delphi é mais difícil, porque o IDE na prática conduz o
> programador, fazendo com que ele utilize certos 'idiomas' comuns.
O Delphi amarra você , ele gera quase todo o codigo sozinho,mas usar o Qt é bem parecido, aliais os componentes de banco de dados que você comentou ele tem também.
> A maior diferença, no caso do Delphi, ou do VB, é justamente a
> qualidade da documentação voltada para meros mortais. Não sei as
> versões mais recentes -- essas já devem ter ficado complicadas demais
> -- mas os manuais do VB 2.0 e do Delphi 2.0/3.0 eram muito bons,
> especialmente porque não se limitavam a ser um índice de funções, mas
> porque explicavam claramente a filosofia da ferramenta, e falavam como
> é que certas coisas deveriam ser feitas, e por quê deveriam ser feitas
> daquela forma.
Você acha a documentação do Delphi boa? Eu achava no começo só que é só você precisar de uma coisa um pouco mais elaborada (como OpenGl por exemplo) pra ela simplesmente virar um lixo, correto mais inutil.
--
,= ,-_-. =.
((_/)o o(\_))
`-'(. .)`-'
\_/
Carlos Ribeiro
On Sat, 2 Oct 2004 23:39:57 -0300, Rodrigo Dias Arruda Senra
<rse...@acm.org> wrote:
> | No Delphi é mais difícil, porque o IDE na prática conduz o
> | programador, fazendo com que ele utilize certos 'idiomas' comuns.
>
> Vc está falando dos templates gerados para os event-handlers ou da
> estrutura natural de programas em Pascal var,const,interface,implementation ?
Um pouco de cada coisa. Os templates de classe ajudam um bocado. Os
nomes automáticos são infelizes, mas mesmo assim, eles tem uma certa
lógica que ajuda a ler programas feitos por outras pessoas. A
estrutura natural também ajuda muito, principalmente quando o problema
são os 'packages' em Python. Finalmente, tem outra coisa que é uma
'birra' particular minha, que é a falta de uma noção de 'arquivo de
projeto' listando tudo que faz parte do mesmo. Isso é uma função do
IDE, não do interpretador Python, mas no caso do Delphi ajuda, porque
facilita a administração dos arquivos. Tente achar arquivos 'perdidos'
em projetos grandes e você vai entender o que eu quero dizer.
> No Delphi o caboclo também pode usar uma estrutura complexa de classes, ou
> de procedures+funções, ou criar um código tão macarrônico quanto se queira.
> Ou seja, dois programadores podem criar códigos object-pascal bem diferentes
> para resolver o mesmo problema. Eu sei pois usamos Delphi da 1.0 até a 4.0,
> e dei manutenção em código de muita gente :o(
> Mas em útlima instância estamos falando da mesma coisa =)
Estamos sim -- com a única diferença da minha ressalva acima, que é um
atributo do IDE (o Delphi é uma referência incontestável a esse
respeito).
> Touché. Veja que componentes data-aware estão diretamente relacionados com
> a interface gráfica. Mas vc levantou uma questão interessante, não sei se
> algum dos toolkits gráficos para o Python (PyQt, PyGtk, wxPython, PyhtonCard,
> Tkinter3000, etc) possuim uma implementação de data-aware componentes em andamento.
Que eu saiba, não tem. E o problema não é só esse. Vou comentar sobre
dois temas logo adiante...
> [sobre documentação]
> Bom, é uma questão de alguém se voluntariar para escrever. No caso do
> Delphi e do VB tinha gente sendo paga para escrever. Python tem uma documentação
> excelente na minha opinião, acho que o wxPython chega lá.
> [sobre componentes data-aware]
> É sem dúvida um projeto útil e interessante.
> Alguém se habilita ?
Para os dois temas, o que falta é uma visão única do que deve ser
feito. No caso do Delphi, não me lembro o nome do arquiteto
responsável, mas que ele é muito bom, é. Tanto que acabou indo para a
Microsoft, onde se tornou responsável pelo C# e também por boa parte
da CLR que é a base do .NET.
Para se ter um exemplo do que eu quero dizer: o caso dos componentes
data-aware implica todo um framework de suporte para comunicação entre
os componentes. Fazer um modelo simples, funcional e eficiente não é
moleza. Se não tiver alguém compentente que possa assumir a
responsabilidade integral pelo projeto, então ele falha. Em open
source, isso requer alguém do porte do Linus Torvalds ou do Guido van
Rossum -- pessoas capazes de liderar uma equipe, mas acima de tudo, de
tomar as decisões certas com relação à arquitetura de um sistema (isso
é mais importante do que a qualidade do código em si!!!). Se deixar
por conta de um comitê, vira uma colcha de retalhos e não dá em nada.
--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carri...@gmail.com
mail: carri...@yahoo.com
Rodrigo Dias Arruda Senra
[ Carlos Ribeiro <carri...@gmail.com> ]
-----------------------------------------------
| Finalmente, tem outra coisa que é uma
| 'birra' particular minha, que é a falta de uma noção de 'arquivo de
| projeto' listando tudo que faz parte do mesmo. Isso é uma função do
| IDE, não do interpretador Python,
Que bom que mencionou isso. Recomendo dar uma olhadela em Leo
http://webpages.charter.net/edreamleo/front.html. Ainda estou
engatinhando, mas ele resolve este problema e muito mais.
| Para os dois temas, o que falta é uma visão única do que deve ser
| feito. No caso do Delphi, não me lembro o nome do arquiteto
| responsável, mas que ele é muito bom, é. Tanto que acabou indo para a
| Microsoft, onde se tornou responsável pelo C# e também por boa parte
| da CLR que é a base do .NET.
Tô sabendo. O nome do caboclo é Anders Hejberg. E já deu uma baita discussão sobre
esse cara aqui na lista. Admiro muito esse indivíduo desde o saudo Turbo Pascal,
com o qual começou sua carreira.
| Para se ter um exemplo do que eu quero dizer: o caso dos componentes
| data-aware implica todo um framework de suporte para comunicação entre
| os componentes.
Tenho um colega de doutorado trabalhando nisso.
| Fazer um modelo simples, funcional e eficiente não é
| moleza. Se não tiver alguém compentente que possa assumir a
| responsabilidade integral pelo projeto, então ele falha. Em open
| source, isso requer alguém do porte do Linus Torvalds ou do Guido van
| Rossum -- pessoas capazes de liderar uma equipe, mas acima de tudo, de
| tomar as decisões certas com relação à arquitetura de um sistema (isso
| é mais importante do que a qualidade do código em si!!!). Se deixar
| por conta de um comitê, vira uma colcha de retalhos e não dá em nada.
Concordo em gênero, número e grau.
[]s
Senra
,_
| ) Rodrigo Senra <rsenra |at| acm.org>
|(______ -----------------------------------------------
_( (|__|] GPr Sistemas http://www.gpr.com.br
_ | (|___|] IC - Unicamp http://www.ic.unicamp.br/~921234
___ (|__|]
L___(|_|] -----------------------------------------------
Carlos Ribeiro
On Sat, 2 Oct 2004 13:56:35 -0300, Rodrigo Dias Arruda Senra
<rse...@acm.org> wrote:
> Já poderia estar dando bizzus a mais tempo hehehe.
Obrigado pelas boas vindas!
> | Python é uma linguagem de programação com um conjunto de bibliotecas
> | extremamente poderoso e portável, mas que ainda não tem a mesma
> | abrangência da VCL.
>
> Não é o Python, mas a Standard Library. O Andrew (amk) levantou esse
> problema recentemente em sue blog, e acredito que veremos progressos
> nessa área logo.
Bom, foi mais ou menos isso que eu disse :-) (comparando a VCL com o
conjunto de bibliotecas do Python). Eu também li o comentário do AMK,
e só achei estranho que ele não tivesse postado nada ainda nem na
python-dev, nem na c.l.py. (Aliás eu postei um comment no blog dele a
respeito do assunto).
> | Por exemplo: existem muitas APIs gráficas, mas
> | nenhuma que se possa dizer que faça parte do "kit básico da
> | linguagem".
>
> Eu não tenho o que reclamar do wxPython.
Acho a documentação do wxPython terrível. Tem muita coisa que ainda só
está documentada em C++, o que torna desnecessariamente complicadas as
coisas. Também falta uma documentação básica, introdutória, que mostre
como começar novos projetos com o wxPython, etc. (esse negócio de
mostrar samples e falar para o pessoal editar o sample é coisa para
'hacker', não para usuário normal).
> | mas ainda fica longe do Delphi por causa da falta de
> | controles de edição 'data-aware'.
>
> É verdade.
:-(
> | Por outro lado, se você vai escrever código para rodar em rede a
> | nível TCP/IP, Python oferece recursos muito superiores,
>
> Isso sem nem mencionar o Twisted, pois aí já vira covardia =)
Eu não tive paciência de tentar entender o Twisted. Mas que o projeto
é bem estruturado, e poderoso, isso é.
> | Com Python, tudo é diferente. Mesmo que dois programadores usem a
> | mesma API gráfica -- wxPython, por exemplo -- é provável que eles
> | estruturem se código de forma totalmente diversa.
>
> Aqui eu discordo um pouco. Isso pode acontecer no Delphi também.
No Delphi é mais difícil, porque o IDE na prática conduz o
programador, fazendo com que ele utilize certos 'idiomas' comuns.
> | sem uma boa documentação, é difícil
> | fazer com que um novato se torne produtivo com ela.
>
> Acho que isso é válido para qualquer tecnologia: Python, Pascal,
> C, Java, Perl, Ruby, Smalltalk, e vai ...
A maior diferença, no caso do Delphi, ou do VB, é justamente a
qualidade da documentação voltada para meros mortais. Não sei as
versões mais recentes -- essas já devem ter ficado complicadas demais
-- mas os manuais do VB 2.0 e do Delphi 2.0/3.0 eram muito bons,
especialmente porque não se limitavam a ser um índice de funções, mas
porque explicavam claramente a filosofia da ferramenta, e falavam como
é que certas coisas deveriam ser feitas, e por quê deveriam ser feitas
daquela forma.
> | Finalmente, acho que concordo com a afirmação original -- é uma pena
> | que dê tanto trabalho para fazer coisas básicas em Python.
>
> Vc acha que dá tanto trabalho ? Que coisas ? Tirando interfaces
> gráficas (e isso porque ainda não comprei o wxDesigner, mas vou)
> acho que o Python bate o Delphi em qualquer outro nicho.
Não é só a questão da interface gráfica. A falta de um sistema de
edição 'data-aware' pega *muito*. Ela torna qualquer aplicativozinho
simples de edição de tabelas um exercício de codificação manual
repetitiva. Sem falar nos relatórios, que foram o tema inicial dessa
discussão.
--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carri...@gmail.com
mail: carri...@yahoo.com
Carlos Ribeiro
On Sat, 2 Oct 2004 23:56:35 -0300, Rodrigo <hso.s...@ig.com.br> wrote:
> Diferencie o hacker do usuario normal no quesito programação.
Talvez a minha nomenclatura tenha sido infeliz. Não estava pensando em
usuários normais, do tipo que nunca viramuma linha de código. Entendo
que há uma diferença entre um programador 'comercial' e um
programador, digamos, 'completo'. Acho que um programador comercial
prefere sistemas mais simples -- VB, Delphi, Access, e ferramentas
desse tipo. Esta divisão não tem caráter pejorativo. Muitos
programadores 'comerciais' são excelentes profissionais, bastante
produtivos, mesmo que tenham um conhecimento técnico limitado e
escrevam um código sem muito refinamento. Até mesmo um programador de
alto nível -- um 'hacker', por assim dizer -- pode sentir a
necessidade de usar uma ferramenta desse tipo, seja por imposição do
cliente, seja porque ele prefere simplificar seu próprio trabalho no
caso de algumas atividades, digamos, 'menos nobres'.
> No meu entender se você esta programando ja não pode se
> considerar um usuario, e ler codigos fonte é uma maneira pratica
> de se aprender, não que eu discorde no quesito falta de
> documentação do wx, ...
Como eu disse, nem todos os programadores são iguais. Concordo que ler
código é uma das melhores formas de aprender -- assim como ler os
melhores livros da literatura mundial é importante para um escritor,
ou estudar as provas dos teoremas clássicos é importante para um
matemático.
Já a documentação do wx é um caso à parte -- ela se resume a uma
relação de classes, constantes, e métodos, e exemplos que o
programador precisa ler e tentar entender sozinho. Se ele já tem
experiência com outros kits, ok. Se não tiver, não vai entender
absolutamente nada.
> O Delphi amarra você, ele gera quase todo o codigo sozinho,
> mas usar o Qt é bem parecido, aliais os componentes de
> banco de dados que você comentou ele tem também.
Às vezes, estar amarrado é importante. Mantém você concentrado no
problema, e evita que aquela 'coceira' de reinventar a roda que
costuma beliscar muitos programadores (eu, por exemplo :-).
Especialmente no caso de frameworks complexos, como o Delphi, esta
'amarração' surge como uma consequência direta da abrangência e da
complexidade do próprio sistema. É dificil usar qualquer uma das
partes sem respeitar a estrutura do todo. Neste caso, acho que é um
mal necessário.
> Você acha a documentação do Delphi boa? Eu achava no começo
> só que é só você precisar de uma coisa um pouco mais elaborada
> (como OpenGl por exemplo) pra ela simplesmente virar um lixo,
> correto mais inutil.
A documentação avançada não é boa. Mas a documentação básica é
excelente, e é ela que conduz os programadores iniciantes, ou
'comerciais', suavizando sua curva de aprendizado. Faz falta uma
documentação semelhante para Python. (Aliás, o tutorial é
*excelente*, mas falta algo que introduza mais conceitos da biblioteca
padrão).
--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carri...@gmail.com
mail: carri...@yahoo.com