 |
gildot |
 |
| |
| | Sugestão de Pauta: 2º Encontro Nacional BrOffice. | | |  | Contribuído por scorpio em 01-10-07 13:16
do departamento eventos | |  | |  | | |  João Fernando Costa Júnior escreve "No dia 26 de outubro será realizado o maior evento do BrOffice.org/OpenOffice.org da América Latina.
Serão apresentados vários painéis nacionais e internacionais onde sobre o BrOffice.org/OpenOffice.org no mundo, o que as pretensões da SUN para a versão 3.0, como são organizadas outras comunidades internacionais, porque o ODF é uma padrão ISO e o que isso significa para os documentos dos governos e empresas, como o BrOffice.org se comporta com aplicações de missão critica e muito mais.
John McCreesh (Escócia/Reino Unido), Sun, Frco. Javier Rial Rodríguez (Galícia/Espanha), Marcos Mazoni (Presidente do SERPRO), Claudio F Filho (Presidente da ONG BrOffice.org), Jomar Silva (Diretor Geral da ODF Alliance Chapter Brasil), Claudemir Ivan (Desenvolvedor de Aplicações com Software Livre) são apenas alguns nomes do evento.
Então anotem em suas agendas: O evento acontecerá 26 de outubro de 2007 das 8h às 19h.
Você poderá assistir ao evento em sua cidade, onde será transmitido ao vivo com interatividade. Estados Já confirmados: AC, AL, AM, BA, CE, DF, ES, GO, MG, MT, PA, PE, PR, RJ, SC, SE, SP.
Lista completa com endereços:
página
Site do evento: página
Apoio: SENAI-CE, Ministério do Planejamento, Orçamento e Gestão, Interlegis.
Realização: Ong BrOffice.org " | | | | | | < Internet em Portugal... | | gildot Login | | | Referências | | |
| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | | Teve mais relevo para portugueses a Conferência do OpenOffice que ocorreu já aqui ao lado, em Espanha (ok, no outro lado da peninsula, Barcelona). Foi algo bem maior, contando com muitos engenheiros da Sun e da Novell, as empresas que "fazem" o OpenOffice. Achei um pouco chatas as palestras... Eram focadas ora para empresas/burocratas (formato ODF, scripting), ora para os engenheiros que trabalham na coisa (modularização e outros melhoramentos na infra-estrutura do código), ora work-shops básicos para os alunos da universidade (a conferência teve lugar no edifício histório da Universidade de Barcelona). A mais interessante acho que foi a da empresa chinesa RedFlag, que mostrou o novo interface da sua suíte de office, o RedOffice (scan da shot do panfleto). Infelizmente, o código é fechado, e parece que eles se estão a focar apenas no mercado chinês. Aprensentei com o Michael Meeks, uma camada, desenvolvida em conjunto, que os diálogos podem usar para construir a interface a partir de ficheiros XML. Uma vantagem é que o layout seria feito por construções lógicas (como tabelas, caixas, etc), em vez de posicionamento absoluto, que resulta em muito trabalho para modificar algum aspectos num diálogo (para adicionar um widget algures é preciso andar manualmente a incrementar coordenadas), e em problemas como strings cortadas quando traduzidas. Permitiria redimensionar um diálogo, evitando bugs resultantes do facto do código dos poucos diálogos que podem ser redimensionados ser algo adhoc. Permitiria também a modificação de um interface usando um editor gráfico, abrindo competição entre as distribuições para melhorar o design dos diálogos. Também abstrai a biblioteca de interface do OOo, o que permite uma abordagem muito mais simples a projectos como o porte para Mac. (slides ) Já acabou o meu trabalho no projecto, mas gostava de ver aquilo a ir para a frente. Vou ver se faço uns melhoramente na coisa e adapto algum diálogo... O debate de fecho foi interessante. Representantes da Sun, Novell, RedOffice, Google, Uni. Barcelona e um par de outros, falaram em como melhorar o OpenOffice. Basicamente, a Google espera ver os seus esforços no Summer of Code tornarem-se autónomos, com os participantes a tornarem-se mentores, advogando o desenvolvimento de software livre nas aulas dos cursos de informática. Grande parte do tempo, a Google e outros falaram sobre a pobreza na Índia e na China e como o software livre pode ajudar. A Novell defendeu a necessidade de cooperação entre as empresas e na necessidade de contractar mais programadores, louvando o recente investimento da IBM (que disponibilizou uns 30 programadores). O representante da Sun estava satisfeito com o modelo de desenvolvimento, desvalorizando as críticas sobre o seu controlo e licenciamento do OO, descrevendo-as como política (parece que a Novell e a IBM têm brigas com a Sun porque querem manter-se detentores do licenciamento de trabalho que façam de raíz, e a Sun rejeita a sua inclusão, mesmo que LGPL, no OOo porque quer usar o código para o StarOffice, que é um produto de código fechado). Houve apenas duas perguntas do público, que foram a respeito do atraso do OpenOffice em relação a outras solução no mercado (online e offline).
|
| | | | | | eu só me pergunto, para quando deixarem de reinventar a roda e utilizarem a biblioteca gtk e acessórios nativamente, como todas as aplicações normais.
é que cada camada de abstracção, cada widget especialíssima que criam, conseguem 2 feitos:
- que o openoffice seja cada vez maior, sem acrescentar nada de novo
- que o openoffice fique estremamente bonito em windows ... mas uma lástima em gnome (já não falo linux, mas sim num ambiente puro gtk).
é que a implementação do openoffice é anterior à versão 2.0 do gtk (correcto?) e em parte tiveram que implementar muito daquilo que o gtk implementa hoje em dia ... penso que esteja correcto.
E porque não uma auditoria ao código para "deitar fora" código velho e obsoleto e emagrecer o bicho?
Além de adoptar um look mais standard com os desktop linux ... é que nem os atalhos de teclado são similares, nem a posição de icones ... uma pessoa abre o openoffice e tem um desktop totalmente diferente de um gnome ou kde.
Infelizmente o openoffice não tem rival no momento. E um fork é improvável. Reescrevê-lo deverá ser um pesadelo. Mas como está actualmente não me parece uma excelente base para a continuação.
Será que o planeamento do 3.0 irá incluir uma análise profunda ao código, ou apenas mais umas ferramentas de alto nível?
são algumas questõezitas ...
ps: eu sei a importância do ooo em windows e tal, mas chateia-me que projectos oss, amplamente apoiados pela comunidade *nix (como os mozilla e o ooo) sejam direccionados para windows, com detrimento da sua prestação em linux.
Cumps-
Gass |
| | | | é que a implementação do openoffice é anterior à versão 2.0 do gtk Não exactamente... O OpenOffice tem a sua própria biblioteca gráfica. Chama-se VCL e usa as bibliotecas de baixo nível nos vários sistemas suportados (Xlib para X11, Win32 para Windows, etc). Depois, tal como o GTK+, Qt, etc, existe um módulo de Estilo que as widgets usam para se desenharem. Este módulo pode ser extendido, quer para artistas fazer uns estilos bonitos, ou, apenas no caso do OOo, para se fazer desenhar de acordo com a plataforma (usando normalmente chamadas ao sistema de mais alto nível). Na integração do GTK+, parece que há política ali (este trabalho é feito pelo Novell, que tem vários departamentos, que contractam independentemente, e vamos ficar por aqui... :)), mas também há problemas técnicos. O GtkStyle não foi pensado para este propósito (nem para muitos outros... :))... A sua semântica não é totalmente explicita, e algumas variáveis que o são, não têm um significado preciso. O que acontece é que é seria preciso um trabalho contínuo para ir adaptando a integração às novas versões do GTK. (código em questão -- repara como são criadas instâncias de uma série de widgets, e todas as chamdas ao X :P)
O QStyle também não é pêra dôce, mas os problemas que tem são diferentes dos do GTK. Os problemas dele são sobretudo na implementação, devido a uma interface muito completa e com muita redundância, devido a compromissos para suportar melhor as plataformas. Daí que os estilos do KDE são geralmente mais feios que os do GTK. Nenhum deles suporta coisas como animação, embora seja possível "hackar" isso no Qt. Portanto, quanto à questão, ele usa a versão do GTK+ 2.x que tens no sistema, mas usa-a de uma forma diferente, não é implementado nela. Dito isto, de facto o VCL talvez devesse ser abandonado. É aproximadamente, ou ainda maior, que o GTK+, sendo necessários vários programadores para o manter, e nunca será igual à plataforma. A camada que apresentei foi escrita por cima dos interfaces XToolkit que fazem a ponte entre o VCL e a infra-estrutura de componentes UNO (que te permite escrever um interface na linguagem IDL, e depois a implementação em (quase) qualquer linguagem que te apetecer -- e claro depois usar o código, através da interface, doutra linguagem qualquer -- mas o melhor é a abstração que te oferece, nomeadamente usando beans para propriedades). Mas o código dos diálogos usa a API do VCL directamente, então criamos uma camada por cima do XToolkit compatível com o VCL. :P Ou seja, o VCL torna-se dispensável. Os engenheiros da Sun não gostaram da ideia. :) E existem de facto boas razões para manter o VCL: widgets embebidas em documentos, usadas em contextos diferentes que o ecrã como a impressão, e parece que algumas widgets das plataformas terão limitações que teriam que ser resolvidas. O FireFox usa uma infra-estrutura diferente para as widgets embebidas, o que acho que não é muito do agrado dos utilizadores, mas faria o trabalho. Etc, etc para o resto das críticas, mas o facto é que não existe nenhuma bala mágica para o problema. Será que o planeamento do 3.0 irá incluir uma análise profunda ao código, ou apenas mais umas ferramentas de alto nível? Não ouvi planos nenhuns para uma versão 3.0 -- acho que isso é apenas especulação, não existe nada definido. Sei que um gajo da Novell, que mantém a infra-estrutura do go-oo (para compilar o OpenOffice), quer trabalhar melhor as dependências e dividir melhor os módulos para poderes ter o OpenWriter, OpenCalc, etc em separado, tal como o Mozilla foi divido em FireFox, e o resto. As distribuições eram capazes de compilar tudo na mesma junto, mas seria bastante bom para corrigir bugs, pois os programadores poderiam dizer a quem relata bugs, e ao pessoal de Q.A., para tentar a versão CVS do Calc, sem ter que compilar tudo (o que demora várias horas). Pelo que me apercebi, tanto a Sun, como a Novell, trabalham basicamente a nível empresarial. Uma das queixas é a velocidade do OpenOffice, bastante pior no Linux, devido a problemas com a toolchain do OpenOffice, nomeadamente o linker do Linux parece ineficiente para C++, fazendo pesquisas sequenciais -- segundo um engenheiro da Sun, é mais rápido arrancar o OpenOffice a partir do Wine, do que a versão nativa (alguém quer experimentar? :)). Contudo, parece que a RedHat tem tido mais avanços nisto, porque tem lá pessoal mais especializado no gcc e co. (por causa da aquisição da Cygnus). Um problema é não quebrar a toolchain do KDE. Trabalhando com os engenheiros no campo, a maioria da equipa foca-se em corrigir problemas. A Novell tem também pessoal a trabalhar na interoperabilidade com o Microsoft Office, pois é um compromissos que têm com os clientes, assim como para a Microsoft, com quem têm um acordo em que esta lhes oferece apoio em troca de parte dos lucros. A Novell também tem pessoal a trabalhar na versão do OpenOffice do Windows, pois um dos passos da migração para Suse, é pôr as aplicações a correr em Windows. A Sun tem trabalhado muito na abstração do OpenOffice no sistema de componentes UNO, que permite a ISVs, extender o OpenOffice, e usar o OpenOffice como ferramenta de input, ou tranformação, de dados. Mas não tive tanto com esse pessoal... Quanto a análises de código, uma das palestras foi sobre uma equipa de uma universidade da Europa de Leste, que recebeu meio milhão de euros da União Europeia para durante dois anos analisar o código do OpenOffice. Parece que lançaram uns patches para 150 bugs, e têm um sistema que lança relatórios, para quem os quiser ler, sobre possíveis bugs (ou código suceptível a ser introduzido um bug -- por exemplo, eles advogam a que o último case num switch termine num break, pois se o switch for aumentado, o programador pode não reparar que tem que acrescentar o break), e outros, como avisos sobre a complexidade das classes.
|
| | | | Muito obrigado por este comentário técnico.
Eu li alguns blocos de código do ooo e vi lá realmente implementações de gtk ... mas aquilo eram implementações bastante complexas que usvam e abusavam das directivas de style (gtkStyle).
Sei que há algumas pessoas (vi, por exemplo um patch do fedora) que querem implementar gtk nativo (como por exemplo o filechooser - já comum - e gtkPrint).
Mas isto é apenas o mais high end ...
A minha questão então torna-se ainda mais grosseira... Penso que suportar um toolkit gráfico não se comporta, ainda para mais quando o gtk está até bastante portável.
Hoje também, li que o go-oo.org irá tomar medidas mais drásticas dadas as dificuldades de patches serem aceites e de melhorias a nível de código para linux. No fundo, será um fork sem ser um fork.
Continuando nos toolkits ... Existem já implementações de offices, tais como o koffice ou o gnome-office (abiword e a spreadsheet), por exemplo), que com certeza já renderizam grande parte daquilo que o openoffice renderiza.
O openoffice, além de ser grande, é complexo e não é facil gastar 1 dia ou 2 a ler código e ter um patch pronto. Quando estiver nesse ponto, aí sim teremos melhorias.
Quem não se lembra dos problemas da passagem de 32 para 64 bits? Em que pura e simplesmente tiveram "medo" de mexer demasiado no código. Por essa altura, andei a ler alguma documentaçao que relatava que existiam partes com vários anos que ninguém ousava tocar.
bem ... não batamos mais no ceguinho! Esperemos e contribuamos para as melhorias.
Cumps-
Gass |
| | | | | Quanto ao go-oo, deve ser dito que o artigo do slashdot é demasiado sensionalista. Eles vão continuar a enviar patches para o OpenOffice, e a juntar patches do mesmo.
Para quem não sabe, o oobuild, mantido pela Novell, é o que as distribuições (Suse, Debian, Gentoo, Red Hat, etc) usam há já imenso tempo (apenas a Mandriva e pouco mais usa o OpenOffice da Sun). É também aqui que a maioria do pessoal contribue para o OpenOffice (a nível do código). A grande diferença na direcção do Go-oo, é a sua imagem. Modificaram o site para ser mais apelativo a utilizadores, e, mais importante, disponibilizam agora versões Windows do oobuild. -> Go-oo.org
|
| | | | blacksheep ... caso passes por aqui, podes comentar?
http://rss.slashdot.org/~r/Slashdot/slashdot/~3/169756179/article.pl
segundo o artigo, o ooo 3.0 irá incluir o thunderbird ... sendo um concorrente ao outlook.
Acontecendo isto. Somando a má performance das aplicações mozilla (e ooo) em linux e que existem excelentes opções e mais evoluídas (como o evolution) ... que raio anda a fazer o grupo OOO?????????????????
(existe o evolution para windows, caso queiram dizer que não é multi-plataforma).
Cumps-
Gass |
| |
|
