- Mail chew, admin; team all-hands over lunch midday. Built ESC agenda, poked financials again. Looked at SPADE with the babes: perhaps avoiding Art GCSE was indeed a smart move.
Andreas Kainz
CIB News
Dennis Francis
Eike Rathke
Kohei Yoshida
LibreOffice Design Blog
LibreOffice QA Blog
Marius Popa Adrian
Michael Meeks
Mike Kaganski
Naruhiko Ogasawara
Official TDF Blog
Rizal Muttaqin
Szymon Kłos
TDF Infrastructure Status
Tamás Bunth
Tim Janik
Last updated:
March 20, 2019 10:02 PM
All times are UTC.
Powered by:
Imprint
Privacy Policy
The Call for Location for LibreOffice Conference 2020 is now open.
Background
Once a year, the LibreOffice Community gathers for a global community event: the LibreOffice Conference, or LibOCon. After a series of successful events – Paris, October 2011; Berlin, October 2012; Milan, September 2013; Bern, September 2014; Aarhus, September 2015; Brno, September 2016; Rome, October 2017; and Tirana, September 2018 – the venue for 2019 is Almeria, Spain.
To ease the organization, TDF Board of Directors has decided to open the call for location for 2020, to give the 2020 event organizers the opportunity of attending the conference in Almeria in September 2019. The LibreOffice Conference takes place between September and November, with a preference for September.
The deadline for sending in proposals is June 30, 2019.
After receiving the applications, we will evaluate if all pre-conditions have been respected and the overall quality of the proposal, and give all applicants a chance to answer questions and clarify details.
What applicants need to know
Organizing the LibreOffice Conference is a time-consuming task, where several team members are needed. Getting closer to the event, it tends to become a time consuming job, and each member of the team should be able to devote as much time as necessary. Also, dealing with finances and sponsors is a specific responsibility of conference organizers, who must be able to manage the budget according to the amount of sponsorships, and commit expenses based on the resulting amount of money. TDF will provide a list of sponsors of previous events.
In the past, we have received applications from several third parties, including casinos or professional event managers. Keep in mind that the LibreOffice Conference is a community event, by the community for the community. While we appreciate the interest of people with professional background, proposals not supported and driven by community members (not only TDF members) will not be considered as valid.
What must be covered by the proposal
IMPORTANT: Proposals missing the following information might be considered incomplete. While we try to give every applicant a chance to add or clarify missing information, there is no guarantee that the proposal will be accepted, since we have a rather short time frame. In order to enhance the chances for your proposal to be accepted, please answer as many of the following questions as possible.
The team
Only proposals with a fair amount of team members who can spend the appropriate amount of time and are part of the LibreOffice community will be considered as valid. Based on our experience, at least five team members are required, and those team members need to interact and communicate with the community. Please name all the team members, their role in the community, and their availability in term of time (especially during the month prior to the conference).
At least one team member should be working exclusively on sponsor relations, and on managing invitations for VISAs (as required for many countries). Both of these tasks require a fair amount of time, and are crucial to the organization. Based on our experience, at least a few dozen VISA requests, if not more, need to be dealt with, and you need between € 10.000 and € 20.000 in sponsorship fees. Please let us know if you have at least one team member willing to work on these topics.
The organizing entity
The Document Foundation itself will not be legally or financially responsible for organizing the event. Although it will support the organization of the conference by any possible means, it is necessary to have a local entity, an enterprise or preferably a non-profit, to take care of financial and legal requirements such as insurances and signing contractual obligations.
Another important reason for a local entity is the fact that VISA invitation letters can usually be issued only by a local entity from within the country. Please give details on the organization, its type and its leadership.
The main venue
The venue should be easily accessible from other countries, so ideally, an airport and a central train station are nearby. It should also have a good connection to the local public transportation. Please give details on the venue, its location, and its connection to public transportation.
Ideally, there is just one venue for all conference sessions. In case you distribute the conference among two venues, they should be reachable by public transportation or foot in no more than 10 minutes. Please let us know in case you plan for more than one venue (with the exception of parties and receptions).
The main venue should be partially wheelchair-accessible, with at least the opening/closing sessions and main track room fulfilling this requirement. Please let us know how accessible is the venue.
The conference itself is on 3 days, but their is an extra day before the conference dedicated to community meetings, which should be taken into account into the proposal.
Providing canvas, projectors and rooms for two to five parallel tracks, for a total of approximately 300 participants, is also required. Please let us know if your venue fulfills these requirements.
Next to the presentations, there is often the need to have private meetings. For sure, there are a TDF Board of Directors meeting, a Membership Committee meeting and a TDF Team meeting, so at least two additional rooms are required one day before and one day after the conference. These meeting rooms can also be in a different location from the main conference venue. Please let us know if you can provide these meeting rooms.
Next to conference rooms, there should also be an open space for community gatherings. Please let us know if you can provide such a space.
A publicly accessible, free wireless Internet connection is required. If the venue itself does not provide WiFi, an alternative is represented by broadband 3G/4G wireless routers.
We should also know in advance if there are firewall restrictions in place that limit or forbid the access to services like SSH, Gerrit, Git and others (including e-mail), and whether we can provide a TDF VPN to overcome such limitations. Please let us know which kind of wireless Internet connectivity will be provided to conference attendees.
Having video archives or video live streams is not a must-have, but a nice-to-have. Please let us know if you plan video archives or live streams of the presentations.
Also, if at least one of the social events will be in a wheelchair-accessible location, this will be highly appreciated and will be absolutely wonderful.
Accommodations
Since we expect around 300 visitors, the availability of three/four stars hotel rooms or equivalent accommodations (B&B, or similar) is required. Please elaborate on the hotel offerings near the venue.
Offering couch surfing, motels, youth hostels or other means of free to cheap accommodation is a nice-to-have. Please let us know if such accommodations are available at your venue.
One more thing…
Please describe in your own words why you want to host the next LibreOffice Conference, what motivates you, and what you expect from organizing the event.
Other informations
Please write anything else that can support your application, like
Providing child care would be a nice addition to the application, as there are participants with children who might be encouraged to participate if the service is available.
You may find useful information on the dedicated pad for conferences management.
How to apply
Please send your proposal as plain text e-mail, or HTML e-mail, or Open Document File to info@documentfoundation.org. Please write only in English. We will send a confirmation of your application no later than one week after we have received your proposal. In case that you have not heard back from us by then, please let us know.
Again, the deadline is June, 30 2019 24:00 UTC.
THANK YOU FOR YOUR INTEREST IN HOSTING THE LIBREOFFICE CONFERENCE!
Berlin, March 15, 2019 – MITRE announced that The Document Foundation, the home of LibreOffice, has been approved as CVE Numbering Authority (CNA). The Document Foundation is at the center of one of the largest free open source software ecosystems, where enterprise sponsored developers and contributors work side by side with volunteers coming from every continent. The nomination is the result of significant investments in security provided by the LibreOffice Red Hat team under Caolán McNamara leadership.
What is CVE?
Common Vulnerabilities and Exposures (CVE) is a reference list of public cybersecurity vulnerabilities, with entries that describe those vulnerabilities and provide references for them. These references are often used as the vulnerability names, especially in security updates. To date, LibreOffice has a track record of rapid response to all reported threats.
What is a CVE Numbering Authority (CNA)?
A CNA is an organization that can assign and announce CVE entries within a particular scope. Some CNAs are organizations providing CVEs for their products such as The Document Foundation.
How will The Document Foundation assign CVEs?
The Document Foundation Security Team provides a forum for all of the vendors and individuals who contribute to LibreOffice development to co-ordinate the work of protecting our users from threats related to the application.
As a CNA, The Document Foundation Security Team now has the ability to assign CVE IDs to vulnerabilities affecting our products, the ability to control the disclosure of vulnerability information without pre-publishing, and notification of vulnerabilities in our products by researchers who request a CVE ID from us.
We’ve finished editing and uploading almost all the videos from the second room of the LibreOffice Conference 2018 in Tirana, Albania. To view slides for the talks, find the PDFs in the program here:
As for the main room, the audio isn’t great in many cases (due to technical and acoustic limitations of the venue). Listening with headphones should improve the experience.
You can find the playlist at the following address: LibreOffice Conference 2018. To find second room videos, you should scroll down the list on the right side.
666 bugs have been reported by 379 people.
Top 10 Reporters
634 bugs have been triaged by 78 people.
Top 10 Triagers
158 bugs have been fixed by 49 people.
Top 10 Fixers
List of critical bugs fixed
List of crashes fixed
List of old bugs ( more than 4 years old ) fixed
51 bugs have been verified by 14 people.
Top 10 Verifiers
831 bugs have been categorized with a metabug by 26 people.
Top 10 Categorizers
86 bugs have been set as regressions by 22 people.
Top 10
54 bugs have been bisected by 11 people.
Top 10 Bisecters
Check the current list of unconfirmed bugs here
Check the current list of open regressions here
Check the current list of open bibisectrequests here
Check the current list of highest priority bugs here
Check the current list of high priority bugs here
Thank you all for making Libreoffice rock!
Join us and help to keep LibreOffice super reliable!
Check the Get Involved page out now!…
Yes, it’s that time again! You can improve your C++ skills with the help of LibreOffice developers: we’re running regular workshops which focus on a specific topic, and are accompanied by a real-time IRC meeting. For the next one, the topics are Classes and Arrays. Start by watching this presentation:
Please confirm that you want to play a YouTube video. By accepting, you will be accessing content from YouTube, a service provided by an external third party.
If you accept this notice, your choice will be saved and the page will refresh.
And check out these sections from C++ Annotations: Classes and Arrays.
Then join us for a discussion via our #libreoffice-dev IRC channel on Freenode. You can ask experienced LibreOffice developers questions, and learn more about the language. See you then!
Currently there are some routing/connectivity issues with our hosting provider. Nothing we (TDF) can do, see our provider's ticket for latest info.
by The Document Foundation's Infrastructure Status at March 09, 2019 02:45 PM
#BalanceforBetter #IWD2019
A balanced world is a better world. How can you help forge a more gender-balanced world? Celebrate women’s achievement. Raise awareness against bias. Take action for equality.
Service disruption (slowdown, timeout) in The Document Foundation's main infrastructure. Reason: hypervisor crash. Update 12:30 UTC: Production VMs should no longer be affected. Resolved - 12:45:00 UTC
by The Document Foundation's Infrastructure Status at March 06, 2019 11:45 AM
Resolved - 2019-03-03 17:25:08 UTC
LibreOffice check failed (server time: 2019-03-03 17:24:58 UTC)
Expected HTTP response status: 200, got: 502
by The Document Foundation's Infrastructure Status at March 03, 2019 05:24 PM
Resolved - 2019-03-03 15:16:49 UTC
LibreOffice check failed (server time: 2019-03-03 15:16:28 UTC)
Expected HTTP response status: 200, got: 502
by The Document Foundation's Infrastructure Status at March 03, 2019 03:16 PM
Resolved - 2019-03-03 15:10:30 UTC
LibreOffice check failed (server time: 2019-03-03 15:10:18 UTC)
Expected HTTP response status: 200, got: 502
by The Document Foundation's Infrastructure Status at March 03, 2019 03:10 PM
It’s time to register to the GSOC programm for the different LibreOffice tasks.
As the notebookbar is available for the regular users I hope to get students how are interested in Improve the LibreOffice notebookbar.
Open tasks are
And of corse there are some open bugs (tdf#102062) and missing uno commands that need to be done.
So join the LibreOffice GSOC project and be part of an open and helpful community.
by Naruhiko Ogasawara (noreply@blogger.com) at February 28, 2019 11:21 AM
As mentioned in my previous such report, a hack week is when we are allowed to hack on anything we want in LibreOffice for a few days at Collabora. I used this time to implement core support for the btLr text direction in Writer.
If you work with tables in Word, it’s very easy to create this writing direction: the context menu in a table cell has a menu item to set the direction of the text, where you can rotate the text by 90 degrees counter-clockwise or clockwise. The counter-clockwise btLr direction is the problematic one. Support for tbRl was fine already, since that is needed typically for Chinese/Japanese scripts as well.
Here is how the baseline, the current and the reference rendering of btLr text looks like:
btlr-cell.docx, baseline
btlr-cell.docx, current
btlr-cell.docx, reference
You can see how the second paragraph in the cell was missing from the rendered result and now we basically pixel-by-pixel match the reference.
If you would like to know a bit more about how this works, continue reading… :-)
The document model and UNO API were reasonably straightforward to implement, but the layout was much more challenging. Writer already supported 3 writing directions:
typically used for Latin (left to right, top to bottom)
Chinese/Japanese (top to bottom, right to left)
Mongolian (top to bottom, left to right) text.
This new one is also a vertical direction, also left to right, but bottom to top. The initial layout contained code to read the new enumerator from doc model, extend the SwFrame class to handle this new bottom to top mode, some handling of switching between horizontal/vertical mode and at the end mapping from Writer layout’s direction to VCL’s "900" font orientation. There are more things to handle in layout, but this was good enough to look at other areas as well.
The ODF filter required updating, which was a bit challenging as it was necessary to write different attribute names depending on which enumerator is used from an emumeration, and we don’t have good support for this. Once the filter code was in place, I could write some layout-level tests as well.
Since we have .ui files for UI descriptions, adding UI support was really easy.
Time came to step away from coding for a moment and write up paperwork to propose this feature to be part of the next ODF version (thanks to Andras for the help there!).
Finally I went back to layout, and improved things a bit more: after fixing baseline offsets, the positioning of the text was exactly matching what Word does. How do I know? I used this little script:
gs -dNOPROMPT -dBATCH -sDEVICE=jpeg -r75 -dNOPAUSE -sOutputFile=btlr.jpg btlr.pdf
gs -dNOPROMPT -dBATCH -sDEVICE=jpeg -r75 -dNOPAUSE -sOutputFile=btlr-word.jpg btlr-word.pdf
composite -compose difference btlr-word.jpg btlr.jpg out.jpgWhich allows seeing the differences between our and Word’s PDF output. Additional work was needed to handle multiple paragraphs in a table cell. At this stage I was happy enough with the rendering result, so finally pulled the trigger and replaced the old DOCX filter hack (using character-level rotation) with simple DOCX filter mapping from OOXML’s btLr direction to Writer’s btLr direction — i.e. what was already done for the tbRl case.
The feature works good enough already so that this new core feature can be used by the DOCX filter by default, but there are still a few rough edges:
the shell code (cursor travelling, selection painting, etc) only has partial support for this new direction
RTF and DOC filters are not yet updated
the ODF proposal has a list of contexts other than table cells where the new writing direction could be used, which lack UI/filter support/etc at the moment.
All this is available in master (towards LibreOffice 6.3), so you can grab a daily build and try it out right now. :-)
Recently my LibreOffice work is mostly focused on the Online. It's nice to see how it is growing with new features and has better UI. But when I was working on improving toolbars (eg. folding menubar or reorganization of items) I noticed one annoying thing from the developer perspective. After every small change, I had to restart the server to provide updated content for the browser. It takes few seconds for switching windows, killing old server then running new one which requires some tests to be passed.
Last week during the Hack Week funded by Collabora Productivity I was able to work on my own projects. It was a good opportunity for me to try to improve the process mentioned above.
I've heard previously about browsersync so I decided to try it out. It is a tool which can automatically reload used .css and .js files in all browser sessions after change detection. To make it work browsersync can start proxy server watching files on the original server and sending events to the browser clients if needed.
What is the advantage? Developer tools in the browser are not good enough?
Disadvantages
To integrate browsersync I needed to do some build system changes. First, all static files are served from 'loleaflet/dist' directory. These files are not the original sources but copies. I modified the Makefiles to create symlinks instead if the browsersync is activated. Thanks to that we can modify sources tracked by git and proxy can detect changes.
To try it out on your own:
make cleannpm install -g browser-sync--enable-browsersync argumentLOOL_SERVE_FROM_FS=1 make runmake sync-[writer|calc|impress]In the video below you can see how it works:
Next step will be to allow browsersync usage with cloud storage integrations like richdocuments, I noticed also some issues with access from other devices (app is still using original server for some resources).
by Szymon Kłos (noreply@blogger.com) at February 21, 2019 12:59 PM
by Adrian Marius Popa (noreply@blogger.com) at February 21, 2019 12:07 PM
Last week I started implementing a FOURIER() formula for LibreOffice Calc that computes Discrete Fourier Transform [DFT] of a real/complex data sequence. This is a long-time wanted feature in Calc. I’d like to thank Collabora Productivity for a fully funded hack week and lots of encouragement that enabled me to work on this feature.
The implementation is still a work in progress and current syntax of the formula is :
FOURIER(Array, GroupedByColumn, Inverse, Polar)
First argument is the data array range, but there are some restrictions on its shape. If the array is grouped by columns(rows), you need to indicate that by setting the second argument GroupedByColumns = TRUE(FALSE). In this case the array can contain 1 or 2 columns(rows), where the first column(row) contains the real part of input series and second column(row) if present contains the imaginary part of the input series. If there is only 1 column(row), the input series is treated as purely real. If the number of rows(columns) is not a power of 2, zeroes are appended to the input series internally to make the series length equal to the next nearest power of 2.
The third argument “Inverse” is a boolean flag to indicate whether an inverse DFT needs to be computed. This argument is optional and the default value is FALSE.
The fourth argument Polar is a boolean flag to indicate whether the final output needs to be in polar coordinates. This argument is optional and the default value is FALSE.
The result of this formula consists of two columns – first column contains the real parts (or the magnitudes if Polar=TRUE) and second column contains the imaginary parts (or the phases if Polar=TRUE).
Below is a screenshot of a sample usage of FOURIER() formula.
The data x[n] column was generated by the formula “=10*COS(2*PI()*COS(2*PI()*A2:A257/128))” (a typical frequency modulation example). Here I wanted to get an Phase-Magnitude spectrum and plot it, so I used “=FOURIER(B2:B257,1,0,1)” (Note that the Polar argument is set to 1).
Implementation
I made a choice to implement a radix-2 decimation-in-time Fast Fourier Transform algorithm from scratch. Of course this would mean the data length should be an even power of 2. But like Gnumeric, my implementation pads zeroes to the data sequence to round the length to the next power of 2. This is something to improve upon in the future. The current implementation is not yet merged to LibreOffice core repository, but is in review @ gerrit. A Fourier analysis tool user-interface is also in the works too.
I’d like to share the results of the quick benchmark tests I’ve done to measure the performance of the R-tree implementation included in the mdds library since 1.4.0.
R-tree is a data structure designed for optimal query performance on spatial data. It is especially well suited when you need to store a large number of spatial objects in a single store and need to perform point- or range-based queries. The version of R-tree implemented in mdds is a variant known as R*-tree, which differs from the original R-tree in that it occasionally forces re-insertion of stored objects when inserting a new object would cause the target node to exceed its capacity. The original R-tree would simply split the node unconditionally in such cases. The reason behind R*-tree’s choice of re-insertion is that re-insertion would result in the tree being more balanced than simply splitting the node without re-insertion. The downside of such re-insertion is that it would severely affect the worst case performance of object insertion; however, it is claimed that in most real world use cases, the worst case performance would rarely be hit.
That being said, the insertion performance of R-tree is still not very optimal especially when you need to insert a large number of objects up-front, and unfortunately this is a very common scenario in many applications. To mitigate this, the mdds implementation includes a bulk loader that is suitable for mass-insertion of objects at tree initialization time.
What I measured in this benchmark are the following:
I have written a specially-crafted benchmark program to measure these three categories, and you can find its source code here. The size() method is included here because in a way it represents the worst case query scenario since what it does is visit every single leaf node in the entire tree and count the number of stored objects.
The mdds implementation of R-tree supports arbitrary dimension sizes, but in this test, the dimension size was set to 2, for storing 2-dimensional objects.
Here is how I designed my benchmark tests.
First, I decided to use map data which I obtained from OpenStreetMap (OSM) for regions large enough to contain the number of objects in the millions. Since OSM does not allow you to specify a very large export region from its web interface, I went to the Geofabrik download server to download the region data. For this benchmark test, I used the region data for North Carolina, California, and Japan’s Chubu region. The latitude and longitude were used as the dimensions for the objects.
All data were in the OSM XML format, and I used the XML parser from the orcus project to parse the input data and build the input objects.
Since the map objects are not necessarily of rectangular shape, and not necessarily perfectly aligned with the latitude and longitude axes, the test program would compute the bounding box for each map object that is aligned with both axes before inserting it into R-tree.
To prevent the XML parsing portion of the test to affect the measurement of the bulk loading performance, the map object data gathered from the input XML file were first stored in a temporary store, and then bulk-loaded into R-tree afterward.
To measure the query performance, the region was evenly split into 40 x 40 sub-regions, and a point query was performed at each point of intersection that neighbors 4 sub-regions. Put it another way, a total of 1521 queries were performed at equally-spaced intervals throughout the region, and the average query time was calculated.
Note that what I refer to as a point query here is a type of query that retrieves all stored objects that intersects with a specified point. R-tree also allows you to perform area queries where you specify a 2D area and retrieve all objects that overlap with the area. But in this benchmark testing, only point queries were performed.
For each region data, I ran the tests five times and calculated the average value for each test category.
It is worth mentioning that the machine I used to run the benchmark tests is a 7-year old desktop machine with Intel Xeon E5630, with 4 cores and 8 native threads running Ubuntu LTS 1804. It is definitely not the fastest machine by today’s standard. You may want to keep this in mind when reviewing the benchmark results.
Without further ado, these are the actual numbers from my benchmark tests.
The Shapes column shows the numbers of map objects included in the source region data. When comparing the number of shapes against the bulk-loading times, you can see that the bulk-loading time scales almost linearly with the number of shapes:
You can also see a similar trend in the size query time against the number of shapes:
The point query search performance, on the other hand, does not appear to show any correlation with the number of shapes in the tree:
This makes sense since the structure of R-tree allows you to only search in the area of interest regardless of how many shapes are stored in the entire tree. I’m also pleasantly surprised with the speed of the query; each query only takes 5-6 microseconds on this outdated machine!
I must say that I am overall very pleased with the performance of R-tree. I can already envision various use cases where R-tree will be immensely useful. One area I’m particularly interested in is spreadsheet application’s formula dependency tracking mechanism which involves tracing through chained dependency targets to broadcast cell value changes. Since the spreadsheet organizes its data in terms of row and column positions which is 2-dimensional, and many queries it performs can be considered spatial in nature, R-tree can potentially be useful for speeding things up in many areas of the application.
A new edition of FOSDEM (Free and Open source Software Developers‘ European Meeting) just ended. Our CIB LibreOffice team this year was represented by Thorsten Behrens, Michael Stahl and Marina Latini. The event is held annually during the first weekend of February, at the „Université Libre de Bruxelles„. For our team, attending FOSDEM means to be … CIB visiting FOSDEM 2019 weiterlesen
Der Beitrag CIB visiting FOSDEM 2019 erschien zuerst auf CIB events.
With the release of 6.2 I read a lot of comments on the different threads. Several issues are listed. One was that Ribbons waste vertical space.
With default settings the standard toolbar need 110 px vertical space (menubar + 2 toolbar height), tabbed toolbar need 100 px and groupedbar compact 72 px. So the default toolbar need most vertical space.
Yes MSO Ribbons need a lot of vertical space, which is an issue on laptops. Therefore you can show the tabbs only. In LibreOffice we have different UI’s for different workflows, but also for different screen’s. For example on your 32 inch office screen you’d like to work with standard toolbar but on mobile you prefer tabbed compact toolbar (which will be released with 6.3).
On windows the difference between LibreOffice tabbed toolbare and MS Office ribbons is
94 px vs. 110 px
If you like my work, become a 
by Adrian Marius Popa (noreply@blogger.com) at February 09, 2019 02:49 PM
by Adrian Marius Popa (noreply@blogger.com) at February 09, 2019 01:52 PM
by Adrian Marius Popa (noreply@blogger.com) at February 09, 2019 01:20 PM
 |
| Standard Toolbar |
 |
| View Menu |
 |
| Mail Merge Toolbar |
 |
| Data Source |
 |
| Standard Toolbar |
 |
| Row Right Click Menu |
 |
| Column Right Click Menu |
 |
| Sheet Menu |
 |
| Data Tab |
 |
| Tool Tab |
 |
| Standard Toolbar |
 |
| Slide Transition |
 |
| New Tab Interface |
 |
| Shape Menu |
 |
| Table Properties |
 |
| Sidebar Component |
 |
| Flip Action |
 |
| Data Table |
by rizmut (noreply@blogger.com) at February 08, 2019 03:28 AM
Base – the database editing program of LibreOffice – offers several features when it comes to external database connection. One interesting feature is that Base lets you connect to an external database not only with ODBC and JDBC but with native connectors too. Using the native connector instead of a standard like JDBC sometimes has a positive impact on performance.
Considering that MySQL is one of the most used database management systems worldwide it is clear that the support of connecting to a MySQL database is an unavoidable part of Base. Currently there are three ways supported to connect to a MySQL database: with ODBC, JDBC and using a native connector. However, the last option was only available as an extension, and it is the part of the core project only since November 2018.
Why was it only an extension at the first place? The native connection was implemented by using the C++ connector of MySQL, which is licensed under GPL. Because of that it could not be put into the core project. So what is the solution then?
Because of the above mentioned problem we, at Collabora decided to use the connector of MariaDB instead. MariaDB is a fork of MySQL which has the same database structure and indexes as MySQL. It has a C API which can be used to connect to MySQL and MariaDB databases too. What is more, the connector is LGPL licensed, which means that it can be used in the core project too. So the next task was to use this API to implement the sdbc driver.
Some parts of the implementation is pretty straightforward. It is pretty easy to create a connection and pass options through the function “mysql_options”. It was also clear to me how to pass things like user and password to the DBMS.
There were a few things though which were a bit more challenging. The XDatabaseMetadata interface for example – which is responsible for providing information about the current state and capabilities of the database – could not be implemented with only a few function calls. In order to implement them, I had to construct SQL queries for most of the methods. Database information are available in the schema called “INFORAMTION_SCHEMA”. That task took some time since the interface has more than a hundred methods which had to be implemented.
Another challenge was a bug about parallel execution of result sets. The C API does not support the usage of two result sets simultaneously, but the sdbc standard supports it. The solution was to store the result of a query and free the mysql resources afterwards. That way a new result set can be fetched with the C API while the previously fetched data is stored in memory.
Having the native MySQL connector in the core project has several advantages. First, it is easier for the user to install it. It is bundled with the core project, there is nothing to do there. Also, it improves maintainability, because it does not have to be maintained separately as an extension. For example the automatically triggered clang plugins do not run on extensions. It can easily happen With an extension that after a few releases it is not usable anymore, because of the lack of maintenance.
Besides that, in order to improve quality and maintainability I created a test suite to test the implementation of the sdbc driver of a MySQL database. This test suite does not run automatically with each build though. In order to test it, a running MySQL or MariaDB server is needed, so only manual execution of the test suite is supported. The test suite can be triggered with the same method as the other tests, but you have to declare an environment variable as well (CONNECTIVITY_TEST_MYSQL_DRIVER). The variable should store the URL of an available MySQL or MariaDB server. It should contain a user, a password, and a schema, which can be used to test the functionality of the driver.
Although a lot of things work now, there might be some bugs hidden. Feel free to test the driver if you like, file a bug and please CC me in Bugzilla if you found something interesting.
You can also take a look at my talk on FOSDEM about the MySQL connector and other improvements of Base.
688 bugs have been reported by 351 people.
Top 10 Reporters
709 bugs have been triaged by 71 people.
Top 10 Triagers
235 bugs have been fixed by 55 people.
Top 10 Fixers
List of critical bugs fixed
List of crashes fixed
salhelper::Thread::run'::1′::catch$1, installing theme ( Thanks to Xisco Fauli )List of old bugs ( more than 4 years old ) fixed
138 bugs have been verified by 15 people.
Top 10 Verifiers
918 bugs have been categorized with a metabug by 35 people.
Top 10 Categorizers
160 bugs have been set as regressions by 23 people.
Top 10
131 bugs have been bisected by 13 people.
Top 10 Bisecters
Check the current list of unconfirmed bugs here
Check the current list of open regressions here
Check the current list of open bibisectrequests here
Check the current list of highest priority bugs here
Check the current list of high priority bugs here
Thank you all for making Libreoffice rock!
Join us and help to keep LibreOffice super reliable!
Check the Get Involved page out now!…
by Adrian Marius Popa (noreply@blogger.com) at February 06, 2019 03:16 AM
Tomorrow LibreOffice 6.2 will be released. Time to give you some information what will come in LibreOffice 6.3.
My work in process is an huge update of the sifr icon theme
Sifr icon theme todo:
If you like my work, become a
(via cor4office)
The next step in the recent SmartArt story is my Improving SmartArt import in Impress talk at FOSDEM 2019, in the Open Document Editors devroom. The room was a bit far away from the popular places, but the livestream worked out nicely.
There was also a hackfest before the conference, I looked at RTF export of rotated Writer pictures.
Well – obviously. At least, their current actions tell that: they deprecated CRT MSMs (which is reiterated in VS 2019 RC2 release notes), a technology designed to allow MSI-based installers to install the CRT libraries in a centrally-managed manner; and the only recommended way now is using vcredist executable, which is not MSI-compatible.
What else, if not deprecation, might it mean, when an installer technology made unable to deploy applications created using vendor’s own flagship development tool?
Well – I thought: maybe that was an oversight? Why not inform them about the problem that MSI-only installers would be left without any viable option?
So I did. And I got the answer that to me was a clear confirmation:
Sorry that our current plan is like this, if there are a lot of customer complain about this new change, we will revisit this issue
So – “yes, our plan is to make it impossible for MSI; this is not a problem in our eyes; only if we will experience pressure, may we re-think about it”.
Sad.
The LibreOffice Quality Assurance ( QA ) Team is happy to announce LibreOffice 6.2 RC3 is ready for testing!
LibreOffice 6.2 will be released as final in a week from now and LibreOffice 6.2 RC3 represents the last pre-release before the final release since the development of version 6.2 started in mid May, 2018. See the release plan for more information.
You can find the list of bugs fixed in this pre-release here and the list of new features included in LibreOffice 6.2 in the release notes.
LibreOffice 6.2 RC3 is already available for downloaded in this link, for Linux, MacOS and Windows.
In case you find any problem in this pre-release, please report it in Bugzilla ( You just need a legit email account in order to create a new account ).
For help, you can contact the QA Team directly in the QA IRC channel or via Telegram.
Happy testing!!
…
The keyboard layout on Apple computers is special and some keys are missing. For example there is no Insert key to toggle between insert and overtype. LibreOffice supports the function and you can switch by clicking the respective panel on the status bar.…
The post Overwrite on macOS appeared first on LibreOffice Design Team.
| Imprint Privacy Policy | |
|
The Document Foundation is not responsible for the content on planet.documentfoundation.org. However - if you have any concerns about content please contact Simon Phipps for moderation. Copyright information: Unless otherwise specified in the author's blog, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). |
 |