LibreOffice Help pages can now download example files

Following the introduction of You Tube videos in our help pages, I have enabled the capability of storing OpenDocument files in the help system.

Help authors can now add <object> elements with type="application/vnd.oasis.opendocument.*" where the "*" means "text", "spreadsheet", "drawing", "presentation", "math" and "database".

Since our help pages are mostly textual, it is not the best way to show how a given feature works. By having a real opendocument file available to download directly from the Help is a step to see a real example working.

The implementation of a opendocument object is simple. Just insert an <object> tag specifying the file location in the data attribute, the right type as a valid opendocument MIME type and an id that is a random string.

<object data="media/files/scalc/imtrigon.ods"

id="ods_id61521568603544" 

type="application/vnd.oasis.opendocument.spreadsheet" /> 

The result in the rendered page is an icon with a link to donwload the page:

https://help.libreoffice.org/6.1/en-US/text/scalc/01/func_imsin.html

just click on the icon to donwload and open the file. If your browser has the right MIME type settings, it can open the file directly in LibreOffice. The file in this example (imtrigon.ods) is a simple Calc file that can be updated easily with LibreOffice.

The intent of adding multimedia and other objects files is complimentary to the precise but often cumbersome textual description. Both are important in a help page. The textual description is a way to describe how a feature does work and the object file is the implementation of the description. When there is a discrepancy, then either the software has a bug, or the page needs a description update.

The OpenDocuments inserted in the help system work in either offline and online version of the new Help pages.

Happy open documenting!

Adding multimedia to the Help pages of LibreOffice

I have patched some pages of LibreOffice Help with a new feature: You Tube videos.

Now help content authors can create a video on the subject and insert in the page. The video can he hosted in an external server such as You Tube (tested) or any other  (not tested).

The implementation was done enabling the <object> tag in the stylesheet transform. In the old and offline the <object> tag was ignored:

<!-- OBJECT (UNUSED) -->
<xsl:template match="object" />


So now I enabled it in online_transform.xsl with

<!-- OBJECT -->
<xsl:template match="object"><xsl:call-template name="insertobject"/></xsl:template>

<xsl:template match="object" mode="embedded"><xsl:call-template name="insertobject"/></xsl:template>

and I handle the <object> in the insertobject template. The template can select what to do with each object type.You can see an example in the following page:

https://help.libreoffice.org/6.1/en-US/text/simpress/main0000.html

The video is added as a companion resource of the hep page, it does not intend to replace the correct writing of the hep pages.

The implications are significant. Not only a video can support the contents of the help page, but also other kind of objects can be  acesssed in the helppages.

For example, a help page on autofilter that has a table with data serving as example, can have an object of type spreadsheet inside the page and the user can click on it to open the example spreadsheet and see the live example.

The implementation of other kind of object is not finished but can be easy. In the case of objects like spreadsheets or text documents, the files can be placed in the media/ folder of the help.

Another implication when adding such richness in our help pages is the maintenance of the multimedia, given the fast improvements of the software.  Special care is needed not to add multimedia that depends on a specific release. Instead, the multimedia in the help should focus more generic use of the modules. For example, a tutorial on how to create a pivot table or to create a table of contents in a text document.

Happy multimedia.

Changing the target path for offline new help

This weekend I worked on a patch to build the new LibreOffice help where the offline version does not have the version number in its location and the online version does.

So I had to define a new param to the XSLTs to distiguish the offline and online paths. This affects the main transformation (online_transform.xsl) but also the get_tree.xsl and get_bookmark.xsl transforms.

Some tweaks on the makefiles, hacking existing ones. Module /sfx2/ had to be adapted to detect the right help available.

With the new patch, the version upgrade of the offline help will overwrite the current version, as it is wiith the old help. We keep the version in the path for the online help because we need to serve more than one version, so the server will have 6.0, 6.1, 6.2 ...

I still  look at the main stylesheet transform (online_transform.xsl) and want to refactor it by removing a lot of cruft from the old help ages.

Happy hacking.

Resuming blogging on my activities.

Last Friday I patched the new help of LibreOffice to fix a bug about the correct detection of the operating system passes as &System= in the URL.

It affects the usage of <switch> and <switchinline> with consequences on <case> and <caseinline> as well as the <default> and <defaultinline> inside the help pages (the xhp files).

I had to change the default / defaultinline to an new entity named DEFAULTSYS, shown every time the OS is not specified.

The logic is that is there is a specific usage of &System=, then the page must display the options of the parameter specified by &System=. It must also hide all option of DEFAULTSYS in the page.

If the page has option for <case select='sys'> but the OS passed is not an option of <case>/<caseiniline> then the DEFAULTSYS options must be shown.

For example, the URL pass &System=WIN and the options are for UNIX, then the contents displyed must be DEFAULTSYS.

Patch is: https://cgit.freedesktop.org/libreoffice/help/commit/?id=13098ccef163c813ae3e196511f44a16a6e73fdd

Apache OpenOffice: quem sabe onde o tempo nos leva?

Traduzi a matéria escrita por Richard Hillesey no LinuxUser Alguns grifos são meus.

Em março, Rob Weir escreveu um post no seu blog intitulado “Onde vai o tempo? (Um olhar na linha de tempo do apache OpenOffice)”, mostrando o lento progresso do Apache OpenOffice através do processo de aceitação da Apache. Richard Hillesey mostras os assuntos...

A Oracle anunciou a doação do código do OpenOffice.org para a Fundação Apache em junho do último ano. Por uma série de razões, principalmente por assuntos relacionados à incubação Apache, migração de código e remoção do copyleft, não houve atualização do código do OpenOffice.org desde então. 

No último mês, a IBM anunciou o lançamento do Symphony 3.0.1, que será “o último lançamento do fork feito pela IBM no código do OpenOffice.org” e declarou que as energias da IBM no futuro serão devotadas ao Apache OpenOffice, do qual a IBM espera lançar sua própria edição, que promete ser “um lançamento idêntico do Apache OpenOffice sob a licença Apache,” com extensões e plugins (principalmente para plugar em outros produtos IBM).

Vale notar que o pleito para liberar o código do Lotus Symphony para a Fundação Apache, feito em julho último, ainda não foi realizado, talvez por conta de problemas decorrentes de uma combinação de desenvolvimento em andamento com licenciamento.

Ocorreram muitas especulações sobre o papel da IBM na doação do OpenOffice da Oracle para a Fundação Apache, e sua decisão de seguir o código na Apache, ao invés de trabalhar com a comunidade no LibreOffice. Costuma-se sugerir problemas de licenciamento para explicar a decisão. Um regime liberal de licenciamento, tal como autoriza a licença Apache, permite que a suíte Office seja um repositório de componentes muito úteis para web-office, ferramentas de gestão de sistemas e data warehousing, com alcance muito além de uma singela suite office, e não há qualquer obrigação de retornar para a comunidade as modificações feitas.

O resultado infeliz é que há agora duas versões da mais famosa suíte de escritório de código aberto, desenvolvida principalmente pelos engenheiros da SUSE e da Red Hat, e um fork Apache que é efetivamente comandado pelos engenheiros da IBM.

O LibreOffice está progredindo vigorosamente, e tem muito mais comitters e commits que o projeto apache. A maioria dos contribuintes do projeto Apache são empregados da IBM, e o LibreOffice aparenta ter atraído mais do que somente os antigos empregados da Oracle/Sun. O núcleo dos contribuintes do LibreOffice que não são empregados da SUSE e Red Hat são membros de uma comunidade mais abrangente. Ao mesmo tempo, a remoção do código licenciado exclusivamente sob copyleft do Apache OpenOffice, necessitou que se remova ou substitua muitos recursos, tais como filtros (libwd), renderização de textos complexos com Graphite2, remoção do suporte ao webdav, solver do Calc, importação de PDF, importação do formato wordperfect, e o gerador de relatórios de banco de dados, a integração com os ícones do desktop está degradada e a verificação ortográfica teve de ser substituída com a perda do hunspell.

Um curioso efeito colateral desse processo é que a comunidade de desenvolvedores que licenciou seu código sob LGPL, mas atribuiu o copyright para a Sun Microsystems, se vê agora com seu código re-licenciado contra sua vontade, para a licença Apache, que pode significar que será absorvido por ofertas em código proprietário e fechado.

Em contrapartida, o pessoal IBM sugere problemas de patentes no código do LibreOffice: “Uma das coisas que não devemos esquecer é que o Symphony fez a remediação da propriedade intelectual em vários níveis... mas eu sei com certeza que consertamos coisas que o LibreOffice não viu (falo de patentes, não das dependências da licenças MPL/LGPL)”. Não há uma palavra sobre que patentes está se referindo ou possam ser, ou se os problemas são reais.

Enquanto o LibreOffice progride firmemente, é difícil antecipar quando o lançamento do Apache OpenOffice estará disponível para as pessoas brincarem, para comparar e contrastar com o projeto da comunidade.

Até foi sugerido que o OpenOffice pode falhar no processo de incubação, que induz o código para dentro da Fundação Apache. Nem todos os contribuintes do Apache estão satisfeitos com a doação da Oracle para a Apache e debandada da comunidade que trabalhou no código pelos últimos dez anos. O abandono da comunidade ecoou na doação do projeto Hudson para a o Eclipse e o abandono do fork Jenkins do Hudson - “Dos cochichos ouvidos na ApacheCon, o OpenOffice nunca deixará de ser um projeto incubado. A intenção pode ser de fazer uma auditoria em profundidade e produzir um derradeiro lançamento, limpo, que possa ser absorvido pelo LibreOffice” A divisão foi um desperdício e não favoreceu ninguém. Não será um desastre se o projeto Apache OpenOffice falhar na incubação, e a IBM se juntar com a Intel e apoiar o LibreOffice, mas ninguém está antecipando isso para breve.

Por enquanto, o LibreOffice está com vento de popa, e o projeto IBM está no seu rastro.

Sobre desenvolvimento de software livre, o caso LibreOffice

Hoje caí numa página com uma entrevista do Linus Torvalds sobre gerência de projetos em software livre. Fiquei muito satisfeito por ver que minha experiência com a industria de software e do software livre em particular está em fase com a dele.

Cito aqui os trechos mais relevantes. Diz o Linus: 

"A primeira coisa é pensar que basta jogar na rede suas coisas e pedir ajuda das pessoas". No software livre, ele afirma: "Não é assim que funciona. Você pode publicar, mas assuma que será você a fazer todo o trabalho, para depois pedir sugestões sobre o que fazer, e não o que as pessoas devem fazer. Talvez elas até ajudem, mas você deve iniciar com a premissa que será você o mantenedor, e quem fará praticamente todo o trabalho". Torvald continua: "Se você começar muito animado pensando que pessoas de todo o mundo se juntarão para fazer um mundo melhor trabalhando em seu projeto, com certeza você não irá muito longe".

Tenho quase 10 anos de vivência no software livre, e iniciei com o OpenOffice.org, na área que eu podia contribuir relacionada a localização do software para o português do Brasil. Hoje eu sei que se algo está para ser feito em software livre, melhor saber fazê-lo por conta própria do que depender da boa vontade das pessoas. Não se trata de desmerecer o colega ou o voluntário. Trata-se de ter a noção real de que software demanda muita energia e entender que é natural que as pessoas tenham suas prioridades, quando estão colaborando. Se fossem contratadas, seria outra história.

Nesse ponto seu projeto tem de acomodar os riscos de não poder contar com a mão de obra que inicialmente se ofereceu para ajudar. Trabalhar com prazos em software livre, com voluntários e sem uma gerência de projeto e de recursos que acomode a deficiência de produtividade de voluntários, é arriscado demais.

Seu projeto de software livre precisa de controlabilidade.

A segunda afirmação de Linus Torvalds refere-se aos usuários e aos desenvolvedores:

 " A outra coisa - algo relacionado - que as pessoas parecem não entender, é pensar que somente o código delas importa", diz Linus. "Não. Mesmo que você escreva 100% do código, e mesmo que você seja o melhor programador do mundo e não precisar da ajuda de mais ninguém. a coisa que realmente importa são os usuários de seu código. O código em si não importa; o projeto só é útil se as pessoas assim o acharem".

Minhas palavras para essa observação são as seguintes: O que determina o sucesso de um software livre ou fechado é sua base instalada. E sua base instalada é uma consequência do fato que seu software agradou aos usuário e agregou valor na ponta.

Interessante como esse conceito se aplica ao LibreOffice. A base instalada do LibreOffice é muito grande, prova de seu valor para os usuários. Nesse primeiro ano de existência da The Document Foundation, o LibreOffice sofreu modificações internas que o tornaram muito mais rápido e com melhorias na sua usabilidade. Mas é observando a lista dos desenvolvedores e lendo suas opiniões e trabalho que vejo as palavras de Linus mais aguçadas: temos um time de desenvolvedores de alto calibre, muito ansioso por trabalhar em detalhes, mas que vejo com preocupação o distanciamento das reais necessidades dos usuários.

Tenho visto muitas contribuições para com a velocidade e a facilidade da compilação, algo de muito complexo no processo de desenvolvimento e que visa torná-lo mais simples e acessível a desenvolvedores novatos, mas que nada acrescenta ao produto final e que não chega ao usuário, pelo menos diretamente. Outra posição um tanto mais arrogante talvez, refere-se a pedidos de melhoria ou de novas funcionalidades: os desenvolvedores terminam por chutar a bola de volta para que o usuário consiga por conta própria implementar a funcionalidade ou contratar seu desenvolvimento. Não é uma posição simpática, mesmo sendo realista.

Precisamos romper com o autismo endêmico dos desenvolvedores. Ouvir os usuários e para eles trabalhar.

http://h30565.www3.hp.com/t5/Feature-Articles/Linus-Torvalds-s-Lessons-on-Software-Development-Management/ba-p/440

Colar conteúdo no Lotus Notes

Para colar dados copiados do LibreOffice para o Lotus Notes, precisamos estar atentos a uns detalhes internos do seus sistema, caso seu padrão de edição do Lotus Notes for em texto rico (rich text).

Ao copiar e colar dados do libreOffice no Notes você perceberá que o resultado pode não ficar bom. Isso é devido a forma como os dados são enviados para a área de transferência do Windows e posteriormente colados no Lotus Notes.

Mas há como colar satisfatoriamente os dados na sua mensagem do Notes.

Basta utilizar o recurso Colar Especial do Lotus Notes. Ao acionar este comando, utilize a opção HTML ou Bitmap para colar.

A opção HTML mantém a formatação e permite editar a informação colada.

A opção Bitmap, mantém a formatação, mas o que você estará vendo é uma figura que não pode ser alterada.

Escolha a sua melhor opção.

Até mais.