|
From: Flavio A. <fla...@te...> - 2007-09-20 12:11:04
|
A libglade =E9 mais um exemplo de implementa=E7=E3o da id=E9ia do Wesle=
y do que uma id=E9ia de uso espec=EDfico, o
problema neste caso =E9 que a libglade =E9 totalmente atrelada ao GTK que=
apesar de ser um framework fant=E1stico n=E3o
sei se =E9 indicado para a aplica=E7=E3o desejada justamente pela falta d=
os widgets espec=EDficos para esta aplica=E7=E3o,
uma sugest=E3o seria a implementa=E7=E3o de "widgets" num framework qualq=
uer escolhido em algum momento e usando as
t=E9cnicas que a libglade usa para fazer a carga destes "objetos".
Outra id=E9ia seria modificar o glade de forma a receber novos widgets =
feitos em Gtk mesmo, pode ser mais
f=E1cil, mas =E9 uma quest=E3o de estudo.
Sucesso
Fl=E1vio
---------- Cabe=E7alho original -----------
De: "Wesley Dal'Col" bl...@gm...
Para: "Geraldo Netto" ger...@gm...
C=F3pia: ext...@li...,"Flavio Alberto Lopes =
Soares"
fla...@te...,"Fernando Oliveira" fer...@gm...,"=
profburian" pro...@uo...
Data: Thu, 20 Sep 2007 01:13:09 -0300
Assunto: Re: supervis=F3rio baseado em python e glade, quem topa?
> N=E3o me comprometa, eu sugeri apenas a libglade ;),
> que ali=E1s =E9 sugest=E3o do fl=E1vio...
>
> Na verdade a id=E9ia que eu tive era baseada diretamente na dlopen,
> s=F3 que algu=E9m foi mais esperto e fez a libglade antes...
>
> O problema original era: como criar um mecanismo capaz de gerar
> uma tela ( viewer ), que rode em qualquer plataforma?
>
> Solu=E7=F5es propriet=E1rias, hoje no mercado utilizam controles active=
X
> e sua incestuosa rela=E7=E3o com o IE em ambientes windows (r).
>
> Neste caso, a apica=E7=E3o fica dependente do IE, e sua plataforma.
>
> Na minha concep=E7=E3o, se as telas fossem XML bastaria portar uma
> "engine" que criasse os objetos dinamicamente via dlopen, lendo
> as especifica=E7=F5es de um XML. Com um set definido de objetos e
> eventos, ligar os sinais =E0s callbacks seria moleza (!!!). Foi ent=E3o=
que
> o fl=E1vio me falou da libglade, que seria essa "engine".
>
> De qualquer forma, um processo viewer ainda teria que ser portado.
>
> O interessante ainda, =E9 que com o uso de XML, e as telas sendo
> "renderizadas" num processo =E0 parte abre-se a op=E7=E3o de ter in=FAm=
eros
> viewers simult=E2neos para uma mesma aplica=E7=E3o, n=E3o necessariamen=
te
> rodando numa mesma m=E1quina.
>
> Isso lembra umas tecnologias muuuuuuito antigas, s=F3 um pouco mais
> sofisticadas....
>
> Abra=E7os
>
>
> Geraldo Netto escreveu:
> > Senhores,
> >
> > O Wesley sugeriu o desenvolvimento de um supervis=F3rio
> > onde as interfaces gr=E1ficas ser=E3o baseadas em libglade e python
> > isso, proporciona uma velocidade brutal no desenvolvimento
> > visto que uma interface gr=E1fica(vazia) feita nesse esquema precisa
> > de apenas 3 linhas de c=F3digo:
> >
> > 1 import gtk, gtk.glade
> > 2
> > 3 gtk.glade.XML("empty.glade")
> > 4 gtk.main()
> >
> > oh, ok, 4 linhas :)
> >
> > + info em:
> > http://www.pythonbrasil.com.br/moin.cgi/LibGlade
> > http://glade.gnome.org/screenshots.html
> > http://www.pythonbrasil.com.br/moin.cgi/
> >
> > isso =E9 interessante, pq agente n=E3o vai precisar desenvolver uma i=
de
> > como tradicionalmente as solu=E7=F5es comerciais fazem, agente pode u=
sar o
> > glade(a ide da pr=F3pria biblioteca) p/ gerar os xmls que ser=E3o usa=
dos
> > pela biblioteca
> > e s=F3 se preocupar com a implementa=E7=E3o da coisa, muito + eficien=
te!
> >
> > claro, sobre esse projeto, essa =E9 s=F3 uma parte do sistema, h=E1 a=
inda outros
> > componentes cr=EDticos que precisam de estudo, por exemplo, no superv=
is=F3rio
> > =E9 melhor implementar threads(de cada fun=E7=E3o do supervis=F3rio) =
em um processo ou
> > usar o ipc e fragmentar cada um desses m=F3dulos em processo?
> > Wesley? Fl=E1vio? Fernando?
> >
> > sugest=F5es? cr=EDticas? d=FAvidas? desilus=F5es amorosas?
> >
> > Abra=E7os,
> >
> > Geraldo
> >
>
>
>
|
