As mentioned in the blog post of Mike already, last month we were allowed to hack on anything we want in LibreOffice for a few days. I used this time to progress with 3 different topics.
Given that a Writer shape with a TextBox is internally two shapes, this needed explicit support. After my TextBox bugfix it’s possible to have two such shapes in a document, and once you select one of them, tab properly jumps between the two shapes; previously nothing happened.
What did happen is we tried to activate the TextBox of the selected shape, which selected the shape itself, so at the end nothing happened.
Last, I’ve started working on upstreaming
external/libxmlsec/xmlsec1-noverify.patch.1. xmlsec has no ability to
disable the verification of certificates (think of
curl -k or
wget -k), so
in LibreOffice currently we just patch out that code as we don’t need it. So I
wanted to add a new verification flag to avoid patching, but it turns out that
in the NSS case xmlsec didn’t do the verification, so as a first step I fixed
that instead in this xmlsec GitHub
pull request. Now that it’s merged, the next step will be to add such a flag,
and then LibreOffice can get rid of the patch after the next xmlsec release.
Introduced recently with the MUFFIN concept, the Notebookbar is a blank canvas where controls can be placed and arranged freely. It offers all freedom to users who are not afraid to fiddle around with an integrated development environment (IDE). Here we explain how to start from scratch.
Notebookbars are ui files, which are just XML-formatted text files. Changing the files in any text editor is possible but quite tedious. The supposed way to modify ui files is to use Glade. (This may change in the future.)
After installing Glade, you have to add the LibreOffice catalog in order to use specific controls. Go to Edit > Preferences, click Add and search for the path <libreoffice>/share/glade. If all goes smoothly the LibreOffice controls will be listed in the left sidebar after restarting Glade.
Now you are able to modify existing toolbars. For Writer it is notebookbar_groups.ui or notebookbar_simple.ui at <libreoffice>/share/config/soffice.cfg/modules/swriter/ui/. Calc’s ui files are located at <libreoffice>/share/config/soffice.cfg/modules/scalc/ui/, Impress at …simpress/ui etc. Just load the ui file into Glade, modify as you like, save and switch the used toolbar in LibreOffice (no full restart needed).
But if you are afraid of messing around with the shipped files it is also possible to start from scratch. First you need to add a reference to your new ui file in <libreoffice>/share/registry/main.xcd. Unfortunately, this XML file is created during the build process without any line breaks, which hinders editing. Luckily there is the small tool called tidy that helps with formatting XML files. Rename the file main.xcd first to main.bak and run:
cat main.bak | tidy -utf8 -xml -w 255 -i -c -q -asxml > main.xcd
Now you can open the file in your preferred text editor. Search for the line with notebookbar_groups and copy/paste the complete section to duplicate it:
<node oor:name="Groups" oor:op="replace"> <prop oor:name="Label"> <value xml:lang="en-US">Contextual groups</value> </prop> <prop oor:name="File"> <value>notebookbar_groups.ui</value> </prop> <prop oor:name="HasMenubar"> <value>true</value> </prop> </node>
There is more than one occurrence of notebookbar_groups.ui, one for every application. Make sure you change the section below:
<oor:component-data xmlns:install="http://openoffice.org/2004/installation" oor:name="Notebookbar" oor:package="org.openoffice.Office.UI"> //... <node oor:name="Applications"> <node oor:name="Writer" oor:op="replace">
Now you change the node name from “Groups” to “MyMuffin”, the label from “Contextual groups” to “My Muffin”, and the file reference from notebookbar_groups.ui to notebookbar_mymuffin.ui.
Create the actual file notebookbar_mymuffin.ui at <libreoffice>/share/config/soffice.cfg/modules/swriter/ui/ and enter the basic stuff:
<?xml version="1.0" encoding="UTF-8"?> <interface> <requires lib="gtk+" version="3.12"/> <requires lib="LibreOffice" version="1.0"/> </interface>
You can also use Glade to create a new file or duplicate one of the other Notebookbar files and delete the content. Start Writer to see a beautiful blank canvas waiting for your creativity.
To start with a very simple implementation we construct a “classic” toolbar. Run Glade and open the ui file. Click the Box symbol (first item in the section Containers) and drag it onto the blank canvas. In the pop-up dialog change the number of items to 1 (you can modify all properties later). Now add a Notebookbar toolbox (in the section LibreOffice one of the last items; the common toolbar under Containers will not work) and drop it into the GtkBox. You can resize all controls as you like, but the final alignment is done by LibreOffice.
Right click the sfxlo-NotebookbarToolbox and click Edit… In the dialog go to the tab Hierarchy and click Add. In the right hand area with properties look for Action name and enter .uno:Open there. For easy identification you can use Open at ID and delete the predefined text under Label. That would be enough to show the open icon with all the functionality in Writer.
Toolbar items are defined by default as buttons and in contrast to the normal Open function you will not have menu with the additional features. You can easily change this property under Hierarchy: Tool item > Type from Button to Menu.
You may want to add more functions, so the question arise how all the functions are called and where to get help from.
The .uno: commands contain all information of an entity such as name and tooltips including translation, the icon depending on the selected theme, enabled/disabled status, the actual function, etc. into a generic model. For example, .uno:Bold means the button toggles the text property bold/not bold. If you know the function by name you can find the right .uno: command in the main menu specification (menubar.xml) at <libreoffice>/share/config/soffice.cfg/modules/swriter/menubar/ (respectively for other modules in scalc/menubar, simpress/menubar etc).
And of course it makes sense to have a look at the other Notebookbars. It shows how to deal with context depending sections, how to use tabs, and how to use big buttons instead of the very simple toolbar.
You can modify existing Notebookbars at <libreoffice>/share/config/soffice.cfg/modules/<module>/ui using Glade, or add your own after editing the file <libreoffice>/share/registry/main.xcd. The Notebookbar is a blank canvas where controls can be added.
Be aware that this modifications are quite hacky and will be overridden with the next update. We are aware that this procedure is not user-friendly. The current implementation is experimental and in a very early stage. But it gives an idea what is possible.
More important is that you can also fix or improve the existing Notebookbar variants that are shipped with LibreOffice. So when you see something that can be done better, we welcome improvements as patches!
I added a site-feed to the new LibreOffice extensions and templates website today. You could get the list of new extensions and templates published on the site via rss-feed. The url for the feeds in the format Atom is e.g.: https://extensions.libreoffice.org/atom.xml
The site also provides links for feeds in the format RSS 1.0, RSS 2.0 and iTunes.
Recently, TDF has published its new MUFFIN concept. This publication has provoked a mixed response, with many negative reactions.
When we deal with UI, any possible change brings controversy, and it’s always very aggressive when someone finds that a function they are used to use some way had changed its position. OTOH, there is always a substantial part of community that aggressively promotes “modernization” of current UI.
We all remember how different projects made their UI changes. We remember cases when programs with huge user base made radical changes without an option to keep old UI for those who prefer it. And it forces many of us to resist any sign of possible UI changes in software we use.
Many believe that “design” and “marketing” are swearwords that are used when a company tries to make “purchasers” believe they need something they actually don’t. So, any use of these words in a press release makes yet another chunk of user base to get angry.
There are people that don’t care of UI changes, but have strong opinions that there are much higher-priority tasks to do, like improving stability, compatibility and so on. And when they hear of an effort in an area they regard as unimportant, they get upset. Some of them even have donated to TDF with hopes that donations would go to those goals, and now “see” that TDF wastes their money to pay some designers/marketologists instead of doing Right Things (TM).
Many see the news about UI and immediately realize that there’s indeed something new in UI that is announced. They don’t care to read (let alone comprehend), and so skip any text for screenshots/mockups, and get their views on the matter based on their perception of the graphics. And many of them are angry because they see something that disappoints their expectations of e.g. “ribbon-like” interface. Or they suppose that TDF fools them trying to make believe that there’s something new in the UI options (besides NotebookBar) when actually all that is presented is already possible for long time. “Ah, they try to show to you something old, and pretend that it recently have made a great work to create something new! Smart move!”
Some think that new UI elements are not ready for use and need to be polished in a different branch before inclusion into a LO release.
Many believe that UI changes must begin with UI implementation being rebased to some other library like QT, and that any effort that doesn’t do this is waste of time.
People seem to misunderstand what MUFFIN is.
Thankfully, there are some people in LO community who feel interested in design issues. They form our Design team. Those people are not necessarily developers, and if they are, they have their own interests and priorities, independent of TDF’s or some specific user’s. That’s a great feature of open source community, where each one is able to find an area of interests to apply their effort. And it doesn’t matter if you want LO to get a bug-fix/compatibility feature, and it doesn’t matter if I do some work on those fixes/features: those other people don’t need and aren’t forced to wait for me or help me; they volunteer to do their own contribution in their area in their spare time, and announce their results when they feel appropriate. So anyone who argues that some other things should have been done instead of this work, is misguided. If we would prevent the Design team from doing this, we wouldn’t get more man-power dedicated to your preferred tasks; rather, we would just had lost the man-power (and more important, we would loose those contributors, because there wouldn’t be any reason for them to stay with the project).
The Design team clearly sees the challenges that LO faces with regards to UI changes. On one hand, many want some “refresh”; on the other, many deny the very possibility of it and are afraid of it. There are issues in UI not following different OSes/DMs conventions (making LO to feel not native to these OSes/DMs). And with MUFFIN, the team had IMO made a very smart move.
MUFFIN isn’t a new interface itself. It is even not an interface concept in a usual sense of the term! What it actually is is a public statement, a promise made by LO to its users; and this statement and promise is that: LibreOffice believes that it should be pleasant and easy to use by anyone; and it will never take steps (like other softwares sometimes do) that will sacrifice one group of users’ preferences just to please another – instead, it promises to make its UI as much configurable and modular as it required to allow you, me and anyone to build their own UI of choice. The message is that LO will e.g. continue to provide toolbars: this is not a “first step after which some evil designer will inevitably drop support for good old UI”! And in the same time, LO will not ignore those numerous current and potential users that want another interface: their interests aren’t of lower importance.
If someone still believes in a conspiracy theory that will eventually deprive you from your dear toolbars, remember that LO is being developed by those developers who prefer toolbars themselves, and there’s no ultimate authority to make decision to drop it regardless of those developers’ PoV.
So, MUFFIN is not a NotebookBar or a Single Toolbar. It is a message to users, and a guideline to developers who make UI-related changes. MUFFIN is not the four presented UI options; rather, they are just demonstration of commitment to make it easy to any group to customize.
The four presented UI options are not meant to be necessarily something new. Of course, you can use standard toolbars, or customize them to let only one custom toolbar visible, or use sidebar with any combination of toolbars: the UI components and their combinations aren’t new. The UI components aren’t perfect, and the concept doesn’t claim they are. The concept is orthogonal to any framework used to implement UI components. So, those who are not pleased because the UI isn’t new or isn’t perfect aren’t right when they blame MUFFIN for that. MUFFIN is a promise – so it’s not something to be kept in a separate development branch; and it’s not something that needs screenshots. I’d say that providing screenshots in the press release actually distracted and misguided many readers from the real message.
TDF didn’t spend money to make this happen. It used a research that is publicly available. It doesn’t spend your money to pay some greedy designers: it uses its community’s great power. So no need to get angry that your money are wasted. (As a side note, I’d suggest people to get familiar with TDF role and understand that it doesn’t develop LO itself; instead, it provides home and shelter to community, and promotes the software. Understanding this can help you avoid disappointment when you find out that your donations go to other needs that you imagined.)
I believe that MUFFIN is a great message if you make an effort to hear it. Please do. And if you believe that there’s something to improve, please contribute and become part of community!
In terms of marketing and PR, a large free software project is quite similar to a large corporation. In fact, activities are following each other without interruption: major and minor product announcements, global events and local events, community fostering projects, and day to day activities (such as working with journalists).
In addition, there are the so called back office activities, which are instrumental for the success of the main ones but are less visible (and usually tedious). For instance, a major announcement has a burst of PR activities during the last week, which are based on a careful check of journalists’ email addresses, and on a thorough read of articles published during the last few months.
July is the month of a major announcement, which happens either at the end of July or during the first week of August. In 2016, we have announced LibreOffice 5.2, a feature rich major release, introducing – amongst a wealth of interesting novelties – document classification, a significant new feature for enterprise deployments.
August is usually the month before the LibreOffice Conference, and as such is spent finalizing the event schedule, and putting the finishing touches to the program.
September is the conference month. In 2016, the community has gathered in Brno, the second largest city in the Czech Republic and a technology hub, at the local IT university. The event was organized by OpenAlt and backed by Red Hat, which has a large software dev facility in the city. During the conference, we have announced LibreOffice 5.2.1 and LibreOffice 5.1.5.
October is usually the month when we start planning the next major announcement. In 2016 we have worked together with the Design Team at the new user interface concept, which will be affecting not only LibreOffice 5.3 but also the following major release, and possibly even the next one.
We have discussed extensively the concept, because we wanted to provide users a clear path forward without leaving behind those loyal to the traditional LibreOffice UI, which will not be abandoned.
LibreOffice will offer a flexible user interface, where each user will be able to configure the UI to fit his working habits. In fact, with millions of users, it would be impossible to please everyone by offering only one option in term of user interface.
In November, during the Month of LibreOffice, we have prepared the UI announcement, while working at media mailing lists and monitoring articles about LibreOffice 5.2 (which have reached the record amount of over 2,000 in less than six months).
We have also improved the results, in terms of clicks, of our Google sponsored AdWord account. This is a fine tuning activity, based on the mix of keywords and the bid value associated to each keyword.
In December, we have announced the MUFFIN – My User Friendly & Flexible Interface – with a record number of over 20,000 visits (and over 80,000 page views) to TDF blog. It is an unexpected success, which confirms that we have chosen the right approach to an issue affecting a large number of LibreOffice users.
At the end of the semester, we are ready for a new exciting year (and another semester of ongoing marketing and PR activities, which will start in early January with the first draft of the documents for the announcement of LibreOffice 5.3).
I added some smaller fixes to the Plone add-ons for the new LibreOffice extensions and templates website. I rearranged e.g. the file uploads for releases and added the name of the file next to the download. I will continue with such small modifications during the next days.
You’ll find the new website at https://extensions.libreoffice.org
A new year begins, and we kick off with our first LibreOffice contributor interview of 2017. This time we’re talking to Hazel Russman who helps out with documentation and translations…
Where do you live, and are you active on social media?
I’m British and live in North London. I don’t do social media but I have a web page at www.hrussman.entadsl.com.
Do you work for a LibreOffice-related company or just contribute in your spare time?
I’m retired. I help out the documentation team mainly as a translator and proofreader.
How did you get involved with LibreOffice?
I wrote a novel some years ago and used OpenOffice.org to get it into shape for self-publishing. I wanted to give something back, and the OOo site suggested that time might be more valuable than money. When LibreOffice forked off, I moved over to their team.
What areas of the project do you normally work on? Anything else you want to tackle?
I’ve done quite a bit of translation from German into English, especially for Base, which has an excellent German handbook. Until I translated it, there was hardly anything on Base in English. English is my native language, but I grew up in a German-speaking home. My parents were refugees from Hitler. I’m also quite well known on the team as a proofreader.
What was your initial experience of contributing to LibreOffice like?
Interesting and very satisfying. But I’ve never been much interested in socialising online.
Which is your preferred text editor, and why?
For plain text, I like gVim. It has all the Vim keyboard commands but also graphical controls. The best of both worlds, you might say. I do a bit of coding in my spare time and for that I use Geany. Both Vim and Geany do syntax checking, which is a great help.
What do you do when you’re not working on LibreOffice?
Lots of things! I have a dog who takes up a lot of my time. I am active in my local church and play the cello as part of an instrumental group attached to the church’s gospel choir. I am also quite active on Linux Questions, which is the only social networking that I can be bothered with.
Thanks Hazel! We’ll be posting more interviews over the coming weeks and months, so if you want to join the LibreOffice community, pop over to tdf.io/joinus and choose how you want to get involved. We look forward to your input and contributions!
In 2016, donations have been 82,036 (a 14.2% increase over 2015).
In 2015, donations have been 71,839 (a 9.5% increase over 2014).
In 2014, donations have been 65,579.
Donations are key to our project, as they provide the economic resources to keep the organization and the infrastructure running, to fund activities such as participation of volunteers to FOSDEM and the LibreOffice Conference, and to help local activities organized locally by native language projects.
You can find examples of activities funded by donations money in the annual report: http://tdf.io/report2015.
Without donations, The Document Foundation could not be an independent community led project. Thanks again to all donors.
A color palette is an arrangement of a limited set of colors resembling a painter’s palette. Some collections are officially standardized, others are individually assembled to serve, for instance, a branding purpose or to convey a certain mood.
Among many other things, good design means to have a limited number of colors that work well together. For example, a pale blue can harmonize with a muted red and it makes sense to combine night blue with a fluorescent yellow. Colors influence emotions and perceptions and carry a specific meaning according color psychology.
While our prototypical user Benjamin might be satisfied with a small palette that consists of well harmonizing colors it’s not sufficient for expert users such as Eve. Professional desktop publishing requires more elaborated palettes since certain colors need to be reproduced independently from the output target such as web, CMYK print, digital print etc. Different color models exist requiring a conversion between them, which may not always be perfect, depending on the respective gamut.
Another important aspect of palettes is the naming of colors. Large color collections require that each color can be identified with a unique and descriptive color name. That’s also true for color palettes with only tiny variations between two similar shades of gray, for instance, or when color blindness comes into play and the user cannot easily discriminate between red and green.
LibreOffice shipped releases prior to 5.3 with the color palettes:
Additionally there are document colors, where the colors used in the current document are listed (unfortunately it is buggy), and recently used colors, which is actually a swatch listing what has been selected before (unfortunately it is also buggy).
It was possible to individually change the standard color palettes per Tools > Options > Colors.
With the Google Summer of Code project Area Fill Style (planning was introduced here), the palette handling underwent a revision. Firstly, the recent colors are fully functional now, so the most important use case of having the same color on repeated actions is covered well with this feature.
Newly introduced was the custom palette, which allows to add colors directly in the area style dialog. The custom palette serves the purpose of user customized collections.
This custom palette makes the manipulation of factory settings via Tools > Options > Colors obsolete ‒ and hence we deleted this option. Expert users who want to modify a predefined palette need to edit the file directly. The palettes are files with the extension *.SOC located at <libreoffice>/share/palette. The content is an XML formatted list of hexadecimal color values like
<draw:color draw:name="Azure" draw:color="#f0ffff"/>
Furthermore, we reduced the set of palettes. The palettes gallery, web, cmyk, and scribus were removed because of the non-standard and rather arbitrary collections with inappropriate names. Tango and html received minor updates for labels and arrangement of colors.
The standard palette was also refreshed. The first row starts now with 12 shades of gray followed by 12 basic colors from the HSV color wheel. The next rows are variations of these basic colors in respect to saturation and luminance by 66%, 50%, and 25%. The final 12×8 arrangement fits perfectly into our color picker grid.
The palette breeze has been added to the default set. It comprises all values known from the KDE human interface guidelines as an alternative to tango.
Completely new is the tonal palette. It aims to provide a set of colors with the same luminance respective color contrast. It starts with 10% saturation (named accordingly such as ‘Violett 10%’ or ‘Chartreuse Green 10%’) and continues in 10% steps. Above ‘medium saturation’ the steps are 58, 65, 73, 82%, if possible. Colors that cannot have a higher hue saturation are added as whitespace and named ‘Out of Gamut’. We greatly appreciate the initial work by Wade D. Peterson.
In order to integrate LibreOffice into professional graphics and layout workflows the palette freecolour-hlc based on the CIELAB color model has been added. Its purpose is to provide a cross-media safe set of colors targeting expert publishers. The palette contains a range of muted RGB colors that can be replicated in CMYK and is perfectly suited for those who need a maximum of color correctness across media and platforms. The palette has been created by the non-profit association freieFarbe e.V. (freeColour).
As discussed in a former blog post about LibreOffice Additions we should make customization easier by using extensions, and with version 5.3 you can install color palettes via extensions. For those who want to share their collections it shouldn’t be too difficult to become familiar with the format.
Extensions are basically ZIP files renamed to OXT. Within the archive the file config.xcu defines the path where the palette has to be placed (no need to change this) and the file description.xml with all information about the extension.
<?xml version="1.0" encoding="UTF-8"?> <description xmlns="http://openoffice.org/extensions/description/2006" xmlns:d="http://openoffice.org/extensions/description/2006" xmlns:lo="http://libreoffice.org/extensions/description/2011" xmlns:xlink="http://www.w3.org/1999/xlink"> <!-- any unique identifier, e.g. my.fancy.palette --> <!-- extension not hosted in the LibO repos shouldn't have an identifier starting with org.libreoffice --> <identifier value="org.libreoffice.breeze"/> <!-- version numbers are usually in major.minor.patch scheme --> <version value="1.0.0"/> <!-- extensions with palettes need minimal 5.3 --> <dependencies> <lo:LibreOffice-minimal-version d:name="LibreOffice 5.3" value="5.3"/> </dependencies> <!-- reference to the publisher here --> <publisher> <name xlink:href="https://wiki.documentfoundation.org/Design" lang="en">LibO Design Team</name> </publisher> <!-- how the extension will be called in the extension manager --> <display-name> <name lang="en">Breeze palette</name> </display-name> <!-- optionally an unique icon for the extension manager --> <icon> <default xlink:href="images/logo.png"/> </icon> </description>
The last update has been a while, so with the new year around the corner and sitting in c-base @ 33c3, I’ll do my best to sum up what’s been going on in Rapicorn and Beast development since the last releases.
Now both projects make use of extended instruction sets (SIMD) that have been present in CPUs for the last 8 – 10 years, such as MMX, SSE, SSE2, SSE3 and CMPXCHG16B. Also both projects now support easy test builds in Docker images, which makes automated testing for different Linux distributions from travis-ci much simpler and more reproducible. Along the way, both got finally fixed up to fully support clang++ builds, although clang++ still throws a number of warnings. This means we can use clang++ based development and debugging tools now! A lot of old code that became obsolete or always remained experimental could be removed (and still is being removed).
Beast got support for using multiple CPU cores in its synthesis engine, we are currently testing performance improvements and stability of this addition. Rapicorn gained some extra logic to allow main loop integration with a GMainContext, which allows Beast to execute a Gtk+ and a Rapicorn event loop in the same thread.
Rapicorn widgets now always store coordinates relative to their parents, and always buffer drawings in per-widget surfaces. This allowed major optimizations to the size negotiation process so renegotiations can now operate much more fine grained. The widget states also got an overhaul and XML nodes now use declare=”…” attributes when new widgets are composed. Due to some rendering changes, librsvg modifications could be obsoleted, so librapicorn now links against a preinstalled librsvg. RadioButton, ToggleButton, SelectableItem and new painter widgets got added, as well as a few convenience properties.
After setting up an experimental Rapicorn build with Meson, we got some new ideas to speed up and improve the autotools based builds. I.e. I managed to do a full Rapicorn build with meson and compare that to autotools + GNU Make. It turns out Meson had two significant speed advantages:
Meson also has/had a lot of quirks (examples #785, #786, #753) and wasn’t really easier to use than our GNU Make setup. At least for me – given that I know GNU Make very well. The number one advantage of Meson was overcome with migrating Rapicorn to use a non-recursive Makefile (I find dependencies can still be expressed much better in Make than Meson), since parallel GNU Make can be just as fast as Ninja for small to medium sized projects.
The number two issue is harder to beat though. Looking at our configure.ac file, there where a lot of shell and compiler invocations I could remove, simply by taking the same shortcuts that Meson does, e.g. detect clang or gcc and then devise a batch of compiler flags instead of testing compiler support for each flag individually. Executing ./configure takes ca 3 seconds now, which isn’t too bad for infrequent invocations. The real culprit is autoreconf though, which takes over 12 seconds to regenerate everything after a configure.ac or related change (briefly looking into that, it seems aclocal takes longer than all of autoconf, automake, autoheader and libtoolize together).
PS: I’m attending 33C3 in Hamburg atm, so drop me a line (email or twitter) if you’re around and like to chat over coffee.
Berlin, December 27, 2016 – Effective from January 1st, 2017, access to LibreOffice Certification will be extended to volunteers active at global and local levels, members of not-for-profit bodies sitting in the Advisory Board (namely, FSF, FSFE, Gnome Foundation and KDE), and for individuals whose competence and commitment are demonstrated by facts (successful migrations and trainings). In addition, Members of the Certification Committee can invite people to apply for certification, even if they do not belong to the approved categories, based on their direct relation, and to the competence and commitment of these individuals.
So far, LibreOffice Certification was limited to TDF Members who were active on a regular basis, in order to test the process with candidates already acquainted with the project.
In any case, every individual who applies will have to go through the same certification process, based on a first analysis of pre-requisites and documents, a second optional written questionnaire, and a third face-to-face discussion with the Certification Committee. The second optional written questionnaire is at the sole discretion of the Certification Committee.
“LibreOffice Certification for Migrations and Trainings has been received in a different way in different geographies. In Italy, where it has been more successful, the availability of certified professionals has triggered a number of migrations in public administrations and enterprises”, says Italo Vignoli, Chairman of the Certification Committee.
Lothar Becker, Eliane Domingos de Sousa, Sophie Gautier, Olivier Hallot, Thomas Krumbein, Marina Latini, Gustavo Pacheco and Italo Vignoli have been renewed as members of the Certification Committee. In addition, Franklin Weng – a certified professional from Taiwan – has been added to the Certification Committee, with the objective of helping to increase the number of LibreOffice certified professionals in Asia.
The LibreOffice Certification website is available at the following link: http://www.documentfoundation.org/certification/program/.
In the last months I have a short time period fixing accessibility issues mainly on Linux. LibreOffice has a bunch of this kind of issues (fdo#36549). This metabug is about those bugs which makes it difficult for Orca screen reader to make LO usable for visually impaired users. As I see Orca has a few workarounds in it's LO related code to handle these issues (e.g. ignoring false or duplicated events), but some times there is no such solution and we need to add improvements on LO side.
So I did some bug fixing on this area. Most of the bugs were about missing accessibility events, which are needed for Orca to handle events which are visible on the screen and so users should notice these changes. For example when the selection is changed on a Calc sheet (fdo#93825) or when the cursor moves inside a text portion (fdo#99687, fdo#71435). These issues can be frustrating for users who used to get feedback about the effect of their keyboard key pressing.
Fixing these issues needed small code changes, which shows LO accessibility code has a good structure in general, but as the code changes in time, some parts of this code just becomes broken, without maintanance.
A bit bigger change, I added, was related to the spellcheck dialog (fdo#93430). Spellcheck dialog shows the errors spellcheck algorithms find and shows some options to handle these errors (e.g. suggestions for correction). The problem with this dialog was with the text entry which shows the misspelled word. This text entry contains a small part of the text and highlights the misspelled word with red text color. Orca tried to get this small text part and find out which word is the erroneous one, but LO did not return the right text attributes and so Orca did not have the necessary information to handle this situation.
Now, after fixing this issue text color and also the boundaries of misspelled word are accessible for Orca. Great to see that Orca's developer, Joanmarie Diggs already adapted the code to handle these new information and so reading of this spellcheck dialog will be better in the next versions of the two softwares.
I added these accessibility improvements working for IT Foundation for the Visually Impaired. One project of the Foundation is an Ubuntu based operating system for visually impaired users called BeLin ("Beszélő Linux", which is "Speaking Linux" in English). Since it's an Ubuntu based distribution it has LibreOffice as default office suite and uses Orca as screen reader.
Hopefully these change will make more comfortable to use LibreOffice and Orca both on BeLin and on other Linux distributions.
Toolbars are a common toolkit control that have been around since the dawn of GUI applications, providing direct access to an application’s most frequently used functions. But with increasing scope, the number of frequently used functions grows to an extent that can have a detrimental impact on quickly locating a particular item.
Human perception is limited, but we are perfect in the processing of information. Pieces of information are stored together and build a mental model. In case of the classic toolbars, you likely know where to look for the Undo and Redo buttons, not precisely but approximately, and also remember a few functions next to these buttons. This ‘chunking’ is supported by the elaborated grouping of buttons and with separators between them. But sometimes those tiny features are not enough to convey useful information to the user.
Some attempts have been made to overcome this problem; for example LibreOffice has done it before with the Sidebar and is doing it again with another approach. We’ve implemented a toolbar, that we call the Notebookbar, as a blank canvas where designers have all the freedom to do whatever they want with the space.
With a blank canvas, a designer can place any UI widget on it, including the usual buttons with or without a label, a section label to identify the group of controls, or more advanced widgets like tabs. They also have the ability to define any dimension for buttons, so they serve as a visual attractor, and all together have a larger catalog of controls to choose from than couldn’t be found in classic toolbars. Furthermore, they can define that the main menu can be hidden, or whether it should have a particular icon theme, for instance.
Of course the classic toolbars will still remain and are enabled by default, so don’t be afraid of radical changes. Users interested in trying out the Notebookbar will be able to opt-in and will be able to try out multiple different implementations.
For the contextual groups implementation, the Notebookbar is split into labeled sections (similar to classic toolbar separators but more prominent), i.e. file operations, clipboard interactions, text formatting functions, and a context dependent section. Last but not least a small section for configuration of the toolbar itself at the right.
Three icon sizes are utilized: large icons with a label below being a perceptual attractor for the most important section interactions. Furthermore medium sized icons, two in a column, and small icons with three positioned together. Since this layout targets beginners, we label all buttons.
The contextual groups Notebookbar aims for consistency, which means also that it has to be as static as possible. Thus, Formatting remains available in all contexts, but gets disabled for objects like images. We also want to promote styles as the primary formatting tool. Having large icons for this leads the user to this function, which is not only valid for text (big A in the mockup at the formatting section) but also other objects such as tables (big T for table styles which have been introduced recently). To bring this idea more forward, we added an image style here having color modes like grayscale or watermark in mind.
Of course, the price to pay for various sized icons and text labels is limited space, and we had to remove some functions. That includes, among others, Find and Replace, Spellchecking, Non-Printing Characters, as well as Insert page breaks, Fields, and Special characters. Some could be added into the tools section, wherein the chevron indicator (») exemplifies how small screens or resized main window would behave in case of more content. But basically this variant of the Notebookbar is designed for beginners or simple tasks and should be as plain as possible.
Another challenge is to find good labels that are short enough to fit into the section. In the Chart contextual section, some labels were shortened, for instance Horizontal Grid, Data Table, or Format Selection. This section also has chart styles in a similar place as the Table and Image sections.
The goal is to have various toolbars for different users and scenarios, at best easily user-editable, and the user choose the appropriate at the right hand configuration section. It has (unlabeled) access to the configuration, a drop-down selection with a label below what is active.
Not only consistency at the different contexts is our goal but also familiarity over the programs. The Notebookbar for Calc and Impress looks very similar compared to Writer.
Likely a context dependent section is not necessary for Calc and Impress – chart manipulation, for instance, is available in the sidebar. The idea of animation and transition for Impress is to show the recently used options in this drop-down only, five or so, that overrides the factory setting.
In case of Draw the focus is not the formatting of text but to position objects. While text can be added to almost all objects, the formatting is rather relevant for a text box. And even when a text box has no styling capability today the context dependent section would ideally correspond to what is known from Writer.
As discussed in the introduction, we can also place tabs on the Notebookbar. This layout occupies a similar space as the main menu (which is hidden with this layout) and classic toolbars and organizes all menu functions across the tabs. An implementation similar to the single line toolbar is also possible, which can be contextual and horizontally centered.
And of course it should also be possible to set-up configurations where the Notebookbar focuses on a special workflow like scientific writing.
Some crazy ideas were made in the community how the UI may look in a bright future. While it was far-fetched at the time being created the Notebookbar allows also these fancy configurations now.
The only limit is your creativity and the available list of functions known as ‘uno:commands’.
At this year’s Google Summer of Code, the Notebookbar was worked on by Szymon Kłos (aka eszka), continuing the development begun by Jan Holešovský (aka Kendy) and Samuel Mehrbrodt. We also made some configurations, that is the contextual group presented here as well as a contextual single line variant and the tabbed version. The flexibility of its development will allow the easy creation and testing of multiple implementations during the development cycle, something that wasn’t possible during OpenOffice.org’s Project Renaissance days.
The current implementation is in an experimental state, which means that you will have to unlock the menu entry first. This allows to switch the toolbar mode under View > Toolbar layout to Notebookbar. While the mockups have a dedicated section for the configuration that also allows to quickly switch the mode, this feature has not been finished yet. The modes are switched under View > Notebookbar.
Some of the implemented controls do not work perfectly, in particular that toggle buttons don’t appear toggled unless they are hovered over, drop-down menu lists are sometimes not filled or have entries that don’t function, section headers can’t be styled to have a good background color, and accessibility needs improvements (tdf#102059).
The classic toolbars are customizable and users can add or delete items from the pool of functions. This option is not available for the Notebookbar in this first stage of development; the only means of configuration is to deal with the Glade UI files. Eventually we hope to have a similar customization option like we have in Tools > Customization or we may possibly have an inline UI edit mode similar to what Mozilla allows for Firefox.
We are looking forward to your comments and ideas on how to configure a collection of toolbars. With a good set of options the individual configuration is less relevant.
Building on top of the previously mentioned signing of existing PDF files work, one more PDF feature coming in LibreOffice 5.3 is initial support for the PDF Advanced Electronic Signatures (PAdES) standard. First, thanks to the Dutch Ministry of Defense in cooperation with Nou&Off who made this work possible.
PAdES is an extension of the ISO PDF signature with additional constraints, so that it conforms to the requirements of the European eIDAS regulation, which in turns makes it more likely that your signed PDF document will be actually legally binding in many EU member states.
The best way to check if LibreOffice produces such PDF signatures is to use a PAdES validator. So far I found two of them:
As it can be seen above, the PDF signature produced by LibreOffice 5.3 by default conforms to the PAdES baseline spec.
I implemented the followings in LO to make this happen:
PDF signature creation now defaults to the stronger SHA-256 (instead of the previously used weaker SHA-1), and the PDF verifier understands SHA-256
the PDF signature creation now embeds the signing certificate into the PKCS#7 signature blob in the PDF, so the verifier can check not only the key used for the signing, but the actual certificate as well
the PDF signature import can now detect if such an embedded signing certificate is present in the signature or not
|Don’t get confused, LO does signature verification (checks if the digest matches and validates the certificate) and now shows if the signing certificate is present in the signature or not, but it doesn’t do more than that, the above mentioned DSS tool is still superior when it comes to do a full validation of a PAdES signature.|
As usual, this works both with NSS and MS CryptoAPI. In the previous post I noted that one task was easier with CryptoAPI. Here I experienced the opposite: when writing the signing certificate hash, I could provide templates to NSS on how the ASN.1 encoding of it should happen, and NSS did the actual ASN.1 DER encoding for me. In the CryptoAPI case there is no such API, so I had to do this encoding manually (see CreateSigningCertificateAttribute()), which is obviously much more complicated.
Another pain was that the DSS tool doesn’t really separate the validation of the signature itself and of the certificate. The above screenshot was created using a non-self-signed certificate, hence the unclear part in the signed-by row.
If you want to try these out yourself, get a
daily build and feel free to play
with it. This work is part of both
libreoffice-5-3, so those
builds are of interest. Happy testing! :-)
Die LibreOffice-Community ist wie eine große Familie, die rund um den Globus verteilt an einem gemeinsamen Ziel arbeitet. So vielfältig die Aufgaben, so vielfältig sind auch die Mitwirkenden – vom Schüler und Studenten über den Angestellten bis hin zum freischaffenden Künstler und Rentner, sie alle sind bei uns vertreten.
Während Open-Source-Projekte klassischerweise über IRC und Mailinglisten, mitunter aber auch per Telefon kommunizieren, steht seit einigen Jahren das Thema Social Media hoch im Kurs – Facebook, Google+, Twitter, Instagram, wer neue Leute erreichen will, der muss auch neue Kanäle ausprobieren und so sind auch wir vielerorts vertreten.
Populär sind in der letzten Zeit die zahlreichen Handy-Messenger geworden, die die Kommunikation grundlegend verändert haben. Um dem Rechnung zu tragen, haben wir jüngst einen Versuch gewagt, und beim Messenger Telegram eine englischsprachige Gruppe sowie einen Kanal eingerichtet, die sehr gut angenommen werden. Entstanden aus der Gruppe zur LibreOffice Conference 2016 ist das erklärte Ziel, der Community eine Plattform zu geben um insbesondere diejenigen ins Projekt zu integrieren, die sich mit den bestehenden Kommunikationskanälen nicht anfreunden können.
Nach positiver Rückmeldung zahlreicher Sprachprojekte haben wir nun auch in Deutschland eine eigene Telegram-Gruppe ins Leben gerufen, die du unter
(alternativ per Direktlink:
findest. Ziel der Gruppe ist der Austausch der Anwender und Mitwirkenden untereinander. Für Supportanfragen sind andere Kanäle besser geeignet.
Gerade für ein Open-Source-Projekt ist das zweifelsohne ein ähnlicher Balanceakt wie die Nutzung sozialer Netzwerke: diejenigen, die populär sind, die sind in der Regel nicht komplett frei, und diejenigen, die als Open Source zum Selberhosten zur Verfügung stehen, werden meist nur von denjenigen Nutzern frequentiert, die man auch auf den bestehenden Kanälen bereits erreicht. Wichtig ist meiner Meinung nach, dass relevante Diskussionen und Entscheidungen stets auf den primären Kommunikationskanälen – insbesondere die Mailinglisten – stattfinden und Arbeiten innerhalb der Infrastruktur des Projekts erfolgen, die jeweils auf freier Software basieren. Plattformen bei Dritten können das Angebot stets nur ergänzen, jedoch nicht ersetzen.
Zur generellen Nutzung noch zwei Hinweise aus der Praxis:
In diesem Sinne: Wir lesen uns!
Starting Thursday morning at 10:00 UTC, our instance of pootle will be upgraded. The server will not be available for translators during that time.
While we plan for the upgrade to be done within a few hours, don't be alarmed if pootle is not available.
See also the announcement to the l10n list.
TL;DR: see above — it’s now possible signing existing PDF files and also verify those signatures in LibreOffice 5.3.
LibreOffice already made it possible to digitally sign PDF files as part of the PDF export, so in case you had e.g. ODF documents and exported them to PDF, optionally a single digital signature could be added as part of the export process. This is now much improved. First, thanks to the Dutch Ministry of Defense in cooperation with Nou&Off who made this work possible.
A user can already use an other application to verify that signature or sign an already existing PDF file. The idea is to allow doing these from inside LibreOffice, directly.
As it can be seen above, now the Digital Signatures dialog not only works for ODF and OOXML files, but also for PDF files. If the file has been signed, then the dialog performs verifications of that signature. Signatures are also verified on opening any signed PDF file.
I’ve also extended the user interface a bit, so that signing an existing PDF file is easy, similarly how exporting to PDF is easier than exporting to a random other file format. There is now a new File → Digital signatures → Sign exiting PDF menu item to open a PDF file for signing:
When that happens the infobar has a dedicated button to open the Digital Signatures dialog, and also going into editing mode triggers a warning dialog, as going read-write is not needed to be able to sign a document:
And that’s basically it, after you open a PDF file in Draw, you can do the usual digital signature operations on the file, just like it already works for previously supported file formats.
What follows is something you can probably skip if you’re a user — however if you’re a developer and you want to understand how the above is implemented, then read on. ;-)
The signing feature in ODF/OOXML is implemented by working directly on the ZIP
xmlsecurity/. This means that in the PDF case it’s necessary to
work on the PDF file directly, except that we had no such PDF tokenizer
ready to be used.
xmlsecurity/source/pdfio/ now is such a tokenizer that can
extract info from PDF files and can also add incremental updates at the end of
the file, this way we can make sure adding a signature to a file won’t loose
existing content in the file. This is fundamentally different form the usual
load-edit-save workflow, when we convert the file into a document model, and
work on that.
Previously LO was only able to generate signatures, not verify them. I’ve implemented PDF signature verification using both NSS and CryptoAPI, so all Windows, Linux and macOS are covered. I have to admit that the initial verification was much easier with CryptoAPI. Until I hit corner-cases, I could use an API that’s well-documented and is higher level than NSS. (I don’t have to support different hash types explicitly, for example.)
When I added support for non-detached signatures, that changed the situation a bit:
1 file changed, 15 insertions(+), 11 deletions(-)
was the NSS patch, and
1 file changed, 104 insertions(+), 8 deletions(-)
was the CryptoAPI patch.
Signing an existing file means tokenizing a document, figuring out how an incremental update should look like for that file, writing an incremental update that has a placeholder for the actual signature (a PKCS#7 blob, where the input is just the non-placeholder parts of the document as binary data), and finally filling in the placeholder with the actual signature.
For the last step, I could reuse code from the PDF export (modulo fixing bugs like tdf#99327). For the other steps, the tokenizer remembers the input offset / length for the given token, this way it’s relatively easy to create incremental updates. You can add new objects or update new objects in such an incremental update, and this source tracking feature allows copying even the unchanged parts of updated objects verbatim.
Everything becomes a bit more complicated once I started to handle not only LO-generated PDF-1.4, but also newer PDF versions. I think this is important, as Adobe Acrobat creates PDF 1.6 by default today, which has a number of new features (I think all of them were actually introduced in PDF-1.5) that affects the tokenizer:
xref stream: instead of an ASCII xref table ("table of contents") at the end of the file, it’s now possible to write the binary equivalent of this as an xref stream. Because the binary version can describe more features we must also write an updated xref stream (and not an xref table) when the import already had an xref stream.
object streams: it’s now possible to write multiple objects inside the stream section of a single object in binary form. The tokenizer is necessary to be able to read these objects and also roundtripping (source tracking) should work not only with physical file offsets, but also inside such compressed streams where the offset is no longer just a number inside the input file. (It’s OK to write the updated objects outside object streams, still.)
stream predictors: this is a concept from the PNG format, but also used in PDF when compressing the xref stream. See the spec for the gory details, but in short it’s not enough that instead of plaintext you have to deal with binary compressed data, you also have to filter the data before actually parsing the file offsets, and the filter is defined not in terms of object IDs and file offsets, but in terms of adjacent pixels, since it’s documented in the PNG spec. :-) (To be close to the Adobe output, we also apply such predictors when writing compressed xref streams.)
In addition to be UI changes already mentioned above, one more improvement I did is that now the Digital Signatures dialog has a new column to show the signature type. This is either XML-DSig (for ODF/OOXML) or PDF.
I’ve added an integration test in the existing
CppunitTest_xmlsecurity_signing to have coverage for the small new code that
sfx2/ in case of PDF files. But fortunately
because all other code in
xmlsecurity/ was new, I could do unit testing in
CppunitTest_xmlsecurity_pdfsigning for the rest of the features.
Needless to say that invoking the PDF tokenizer + signature creator/verifier directly is much quicker than loading a full PDF file into Draw, just to see the signature status. ;-)
If you want to try these out yourself, get a
daily build and play with it! This
work is part of both
libreoffice-5-3, so those builds are of
interest. Happy testing! :-)
I must say that I’ve been attentive reader of TDF feeds almost from the very beginning of its history, when I couldn’t think to develop for LibreOffice. And reading posts of developers, where they described what they had done at their hack-weeks at SUSE, made me really envy them…
So here is my first hack-(rest-of-the)-week at Collabora Productivity! That’s cool!
And when it happened, it turned out that I need to finish a work that I started this week. What a pity! Well, the task itself was really interesting, and I’m glad that it is in a close-to-be-finished form in gerrit… but still. So, only hack-weekend
As I didn’t have that much time, I couldn’t afford doing something big and lengthy. So I turned to my favorite topic: SAXParseException.
Here I need to tell you what is it. Until LibreOffice 5.0.4, many errors in XML that LibreOffice reads were simply silently ignored. Note that both LO’s native format, ODF, as well as its most popular competitor, OOXML, are XML formats. It means that the file could be read incorrectly, some data could be dropped, some bugs could go unnoticed, but file opened as if everything was OK. Data loss could go unnoticed.
In January 2015, two days before my daughter’s 3rd birthday , a named hero Michael Stahl took required steps and committed a patch that put that madness to end. Now every error in the XML data that LO reads is reported to user as famous SAXParseException. This annoys users, but it yells loudly “Fix me!”, and it has already enabled us to find and fix quite a number of errors that previously went unnoticed.
So, I must say that I like to hack on these bugs. But since I started to work full-time as developer, I had not that much time for them. And now I took bug 99227 for the rest of my hack-week.
It turned out to be LibreOffice OOXML export filter fault, that caused loss of drawings in footnotes/endnotes. It also created an invalid XML, which was caught on following import, telling that it found “Extra content at the end of the document”.
I’m happy to say that the patch is on its way (it’s on review, and after some rounds of fixing my evident mistakes pointed out by merciless reviewers, it will be pushed).
It may seem odd that I feel so enthusiastic about changing hacking on LO by … hacking on LO. But actually, my daily work is so great, I really love it! and being able to choose tasks myself is the only part that I miss sometimes… and that I get now.
Thanks to Collabora Productivity, to all fellow hackers, and thank you for reading this
There is one particular moment in every Free and Open Source Software project: it’s the time when the software is about to get released. The software has been totally frozen of course, QA tests have been made, all the lights are green; the website still needs to be updated with the release notes, perhaps some new content and of course the stable builds have to be uploaded. The release time is always a special one.
The very day of the release, there is some excitement and often a bit of stress. The release manager(s), as well as everyone working on the project’s infrastructure are busy making sure everything is ready when the upload of the stable version of the software, binaries and source, has been completed. In many cases, some attention is paid to the main project’s mirror servers so that the downloads are fluid and work (mostly) flawlessly as soon as the release has been pushed and published.
The LibreOffice project has released it’s latest incarnation from its Fresh branch, the 5.2.3 somewhat recently and it is amazing to see the pace of improvements and changes that have been taking place not just since the beginning of the project in 2010, but from one major release to another. Needless to say, there’s always much excitement going on on a LibreOffice release day. Recently the project decided to communicate more about the upcoming changes and features in its next majro branch, the 5.3.x. It is a smart move, and it will be useful as it seems that we need to reinforce our message about new features and changes in user interface.
Here again, one is amazed by looking at the sheer amount of changes and improvements brought by one major version to another. It is not only new features, interface changes, it is also an important number of bugs that have been squashed. On a more human point of view, this is also the collective adventure of a community of contributors that culminates the day of a release. To experience such a day is quite unique.
Yet the joys and excitement of releasing a new version are not confined to the LibreOffice project. It really is a shared experience across the Free and Open Source world. This week for instance, the mu email “client” and indexer have been released in a new stable version. Many improvements both in the search and indexing capabilities as well as the interface have been integrated. The release is technically easier than LibreOffice. There is less code and disk space of course, but everything pretty much happens on GitHub. Then it is a matter of publishing the news and the release notes. But the excitement is stil there, still the same for the contributors. And to make before Christmas does also add something special to the season.
“The Release date is coming, let it snow let it snow let it snow!”
The last part of the UI test tutorial introduced the python part of the UI testing framework. In general most times you only need to care about the python part of the test but sometimes you actually need to extend the introspection part of the framework inside of the LibreOffice code. Many UI elements are already supported in the introspection library either directly or through one of its parent classes.
This blog post will give a short summary of how the introspection code works and how support for new elements can be added. In contrast to the other three parts this blog post requires some understanding of the LibreOffice source code and an idea about VCL, our window toolkit.
The introspection library provides two simple UNO interfaces to the outside world. The XUITest interface provides access to static data in VCL. Currently this is limited to executing UNO commands and getting access to the current top level window. Access to this object is provided by UITestCase.xUITest in the python test code. In the future we might extend this interface to provide access to more VCL data that is not otherwise available and is useful for the UI testing.
The more interesting one and the one that abstracts all the different UI objects is the XUIObject interface with the corresponding implementation on the LibreOffice side through UIObjectUnoObj, which just wraps a virtual class called UIObject.
The two important methods are get_state and execute. The get_type and get_name methods should also be overridden but the other methods can often just be taken from the base class.
For now we are just going to talk about UI elements that inherit from vcl::Window, so basically most of our GUI elements. On the introspection side the corresponding class is WindowUIObject, which provides the base class for all vcl::Window based introspection abstraction. All classes inheriting from vcl::Window provide the virtual method GetUITestFactory that returns a factory function for the introspection library.
Adding support for a previously not well covered UI object – all have basic coverage through at least the WindowUIObject – normally requires three steps: First adding a GetUITestFactory method to the UI object class, secondly adding the corresponding factory method and finally implementing the introspection wrapper class.
Most of the time the factory method just casts the passed in vcl::Window pointer to the correct type and create the introspection wrapper object. The actual work is in implementing the actual introspection class for the UI element, which should expose the properties that the tests need as well as the operations that can be done on the UI element.
The inheritance from WindowUIObject or one of its subclasses already provides a number of properties as well as some common operations like typing text.
An example for adding support for a previously unsupported object can be found at . This one has a slightly more complicated factory method but does not add more than a basic property.
Sometimes there are non-vcl::Window UI objects that need to be wrapped which makes everything a bit more complicated. Examples for this are e.g. tree lists or tables where we want to expose elements of the vcl::Window UI object like single tree entries as own objects. As these objects don’t correspond to actual UI objects in our code we have to employ some tricks to provide them to the introspection library. The basic idea behind supporting such pseudo objects is to hold a pointer to the corresponding vcl::Window based UI object through a VclPtr and a way to get the correct property that represents the object we want to cover. Additionally as these objects don’t have an ID we need to override the get_child and get_children methods inside of the the wrapper class for the vcl::Window. The get_children method should return all the IDs of descendants, and the get_child method should return for each of these IDs the corresponding wrapper object.
As has been mentioned in the first part we identify UI elements through a locally unique ID. Normally this ID is loaded from the UI files that describe our dialogs. However for UI elements that are dynamically generated in the code we need to set the ID in the code. For this case the vcl::Window provides the set_id method.
Hopefully this gave a short overview over the C++ part of the UI testing. The next tutorial will cover the directory layout of the python code together with some information about adding normal UNO code to the python tests.
Jedes Jahr kurz vor Weihnachten, meistens am Samstag vor dem ersten Advent, findet in Dornbirn der LinuxDay Vorarlberg statt, der zahlreiche Besucher aus Deutschland, Österreich, der Schweiz und aus Liechtenstein anzieht.
Auch LibreOffice war in diesem Jahr natürlich wieder mit einem eigenen Stand von der Partie, betreut von Robert, Alex, Lothar und mir. Neben der aktuellen LibreOffice-Version hatten wir auch Bücher, Broschüren, Flyer, Sticker, unseren Jahresbericht und zahlreiche weitere Materialien im Gepäck. Insbesondere die Kulis rissen uns die Besucher förmlich aus der Hand, manch einer nicht ohne die Frage, ob man damit auch im OpenDocument-Format schreiben kann.
Stefan hat zudem einen Workshop abgehalten, bei dem er Anwender in die Tiefen der Textverarbeitung eingeführt hat.<figure class="wp-caption aligncenter" id="attachment_291" style="width: 840px"><figcaption class="wp-caption-text">LibreOffice-Stand am LinuxDay Vorarlberg 2016</figcaption></figure>
Für mich gehört der LinuxDay zum Jahresausklang mittlerweile einfach dazu und ich bin jedes Jahr gerne in Dornbirn zu Gast. Vielen Dank an alle Organisatoren für euren großartigen Einsatz und eine tolle Veranstaltung und natürlich an alle Helfer am Stand für euer Engagement – es war ein toller Tag!
Ich freu mich schon darauf, 2017 wieder in Dornbirn zu Besuch zu sein.
I worked with a Plone service provider on the setup of a new LibreOffice extensions and templates website and the migration of the content from the current site to the new site. We are currently short before we will move over to the new website. The new site will contain extensions and templates. We will not have to Plone sites for this purpose. Thus LibreOffice extension or/and template contributors will need only one account in the future. We migrated the user account from the current sites to the new one too. Thus all contributors will be able to login with their current credentials to the new website.
Above the home page of the new LibreOffice extensions and templates website.
More news on the new LibreOffice extensions and templates website will follow here during the next days.