Meine Dokumentation zum Erstellen von LibreOffice extensions, mit denen neue Inhalte ausgeliefert werden, habe ich um einen weiteren Abschnitt zu Icon-Sets ergänzt. Die neue Fassung kann über den folgenden Link heruntergeladen werden. Die Dokumentation ist in deutscher Sprache.
I’m currently using LibreOffice with the menu, tool bar and site bar. That’s the usual interface within the stable mode. I played around a bit with the experimental mode and the new user interface. The functions are organized in menu band yet, but you could also use the current interface in different flavor. I started my play with the tool bar standard and changed over to the compact version of it. Then I activated the site bar. This were the first three views.
Then I changed over to context dependent grouped tool bar and the same in compact mode. This were the user interface style four and five. The next mode shows the tool bar in regster. This view is also available in a compact mode. I got tool bar style six and seven. And then I activated the grouped mode for the tool bar, which is available in compact mode too. Thus I had played around with at least nine different user interface styles. I could top up this with the option to show or hide the menu bar.
I imagine the question of user to the user support about a feature of the office suite, when they first have to sort out which of the different views / UI is activated at the users desk.
It’s great to improve the user interface and match it to the current technical expertise, but it’s not appropriate to delight the users with up to nine different versions of the user interface. Maybe one option would be to deliver one new UI and create one or more LibreOffice extensions with the other UI options.
But maybe the UI of the future has to be developed in diffent way, using Java Script, Angular or something similar and make it more easy to run the office suite on different platforms, different desktop environments, operating systems, mobile devices, in the cloud / browser.
It is possible to extend the office suite LibreOffice with add-ons, named Extensions. If such an Extension will be licensed as Free Software using an Open Source license, it could be published on the website https://extensions.libreoffice.org. I have a look into such extensions, regularly, that are submitted for publication on that website. Thus made me aware, that contributors (extension developers in this case) didn’t know about the need to include the license information into the Extension in the form of a text file and link to that license information from the ‘description.xml’ file inside the Extension. But without a proper license the Extension it is not appropriate to publish the Extension on the LibreOffice Extensions website.
But it is not a very difficult task to add such a license information to the Extension. Just add a text file with the license to the Extension (zipped) container (preferably in a subfolder) and update the description.xml with the following xml-tag:
<simple-license accept-by=”admin” suppress-on-update=”true” >
<license-text xlink:href=”<relative link to the license file>”
It’s also possible to add another license file to the Extension, that is localized in another language, e.g. German or French. In this case add a further xml-tag ‘license-text’ with the link to the license file in that language:, e.g.
<license-text xlink:href=”registration/license_de” lang=”de” />
If the license information is available in the users language setting, the LibreOffice extension manager will display the license in that language.
And another tripping hazard on the way to a published LibreOffice Extension project is the state of an Extension release. It’s necessary to change the initial state ‘pre-release’ to a release state from ‘alpha’ to ‘final’ correspondent to the development state of the Extension. This change could be done on the menu bar (left side of the website). It’s not appropriate to publish an Extension project without a ‘released’ Extension file.
I released my improvements on the Plone addon that is used for the extensions part of the website https://extensions.libreoffice.org. I made it possible with this release to remove older versions of LibreOffice from the compatibility list. The extension releases will show their compatibility with older versions, if the contributor choose that compatibility ever. The site will get the compatibility information of an extension from the index inside the Plone portal_catalog. The new release is available at the ‘CheeseShop’: https://pypi.org/project/tdf.extensionuploadcenter/
It’s always interesting to read about persons which call themself founder of The Document Foundation (TDF). I also found a header ‘TDF founders’ on the official webpage of TDF, where a list of natural persons were summarized under this title.
But are one natural person or some individuals the founder of TDF? Sorry, but the answer is no.
The founder of a foundation in the German law system is the natural person or legal entity that submitted the legal act ‘Stiftungsgeschäft’, including the foundation statutes, the population of the foundation bodies and the capital stock. This legal act has to be submitted to the authorities. Once they accepted it, the foundation is legally in place and the founder has to transfer the capital stock.
Thus in the case of TDF only the German association ‘Freies Office Deutschland e.V.’ was the founder. This association did the legal act and transfered the money.
I wonder about the reason for the use of the title founder from some members of the project. Maybe has to do with the need to impress others or the fear to look like the emperor without clothes 😉
If I ever would need such a title myself I Cold Calls myself ‘founding member of the founder of TDF’ or ‘TDF’s founder founder’ or just ‘007’ (because of my assoziation members number) 😉
I was a (deputy) member of the board of directors (BoD) for about six years and decided not to run again for this body at the end of last year. I followed a lot of discussions and decisions of the board during this period.
At the time I decided to not run again for the board I reflected on the topic, if I should run for the MC (Membership Commitee) this summer and came to the conclusion that this is not appropriate. The MC is not only responsible for the decision on new TDF members and renewing membership. This is the role that the most people inside TDF already know. But the MC has also another important role. it is in some kind in the position of a supervisory board. It receives complaints against the BoD the Board of Trustees and initiates a possible impeachment process against the board of directors. The MC also represents the foundation in court and out of court against the BoD (see Par. 12 I of the statutes). The latter one were the main reason for me to request a cool down period for myself [as an ex-(deputy-)member of the BoD] before I could run for another leading body of TDF. I thought that such a cooling down period should be at least one year. But maybe two years are more appropriate.
In addition I think its role as a kind of supervisory board should lead to a reflection, if it would be appropriate when members of the BoD and the MC would be personally or economical closely connected. It’s also a topic of rethinking, wether a member of the MC should be able to switch without a break into the BoD.
I worked during the last weeks further on the LibreOffice extensions and templates website. I added some improvements to the site and reviewed a lot of projects and gave some users / contributors hints about necessary changes / additions to their extensions and templates (hit-and-miss).
I got some positive response from contributors about my work. But there are some voices (from important people inside the project) that have some issues with my views and that I speak publicly about them, but are always happy to receive my voluteer work during my spare time.
I had to deal with this situation and will take a break to rethink my role and my amount of contribution of spare time to the LibreOffice project and TDF. I already unsubscribed me from some mailinglists of the project.
I made some backups of the current state of all projects on the LibreOffice extensions and templates website and also created a copy of the content of the site. This took some time because I had to fight with too little disk space on the virtual machine. Thus I had to limit the amount of backup.
Once I finished the backup I run a buildout for the LibreOffice extensions and templates website and updated the plug-ins that we use to run the site on the Content Management System Plone. The upgraded plug-ins change particularly the workflow for projects and thus led to a situation where I had to check and update the review state of every project. I finished this work, which took a longer time for the extensions projects yet. I’ll work on the state of the template projects later, because I need a break now.
The change of the workflow state (e.g. to published) will send an automatic generated message to the project owner.
I worked on a new Python script to get the current review state of all extension projects from the LibreOffice extensions website and write this state together with the project title and its url to a csv file.
I’ll work on a similar implementation for template projects next days.
Im Zusammenhang mit der Betreuung der LibreOffice webseite für Extensions (Erweiterungen) und Templates (Vorlagen) habe ich vor einiger Zeit angefangen, eine kleine Dokumentation für den Bau von LibreOffice Extensions zu schreiben, die keine Zusatzprogramme enthalten, sondern weitere Inhalte für das Office-Programm ausliefern. Dies können beispielsweise weitere Grafiken, Autokorrekturen oder Farbpaletten sein. Die Dokumentation ist ein Projekt “im Fluss”. D.h., ich werde weiter an ihr arbeiten und sie ergänzen. Hier nun die aktuelle Fassung der Dokumentation. Sie enthält auch Links zu Beispielen für die Struktur entsprechender Extensions.