Weekly Status Update 13
Aung Khant Oo Gu Gu
wildgugu2020 at gmail.com
Wed Aug 7 11:09:29 UTC 2024
Hi,
This is my weekly status update for gsoc improving experience around
windows.
Currently, persistentwindowstate.cxx stores the windowstate when the frame
is closed.
If the user had cancelled to save the document when closing and we add
window states within the document, unless we save the window state data
alongside the modified data, that the user had cancelled to save, the
windowstate won't be persistent. (Eg. apis such as viewdatasupplier,
model->save()) This led to learning about manipulating xml files to store
the windowstate separately.
This documentation [1] explains working with the file (stored on disc such
as .odt) separately from the model (in memory) and this
Open Office Macros Explained (OOME) book explains about reading and writing
xml files with a dom builder.
This was the first idea which didn't fully work out but useful for the
understanding about the approach. When the frame is closed (detached), we
still have access to the document model (memory). At this point,
adding/modifying data to the xml file (disc) should not affect the
currently opened document which is in memory. Also, since the frame is
already detaching (after close), we don't have to worry about the user
saving again and overriding the new data in the disc. So, the first idea
was to add the window state at this point in time when the frame is closed
and access the window state again when the document is loaded/opened. We
don't need to care when the user saves the document, if the existing
filters will override and erase the added data in between since we only add
data after the frame is closed. At that time, I thought it would be
possible to manipulate only the settings xml file directly by accessing it
from the document root as in [2] xml specification.
After I started learning about filters, so far, I only found to work with
the whole document for import/export instead of just settings file and that
I need to export again after adding data. This led to the following
approach.
Upon implementing, I have realized that I can't directly use the path to
the plain document for the creation of the document builder. It has to be a
xml file.
So, I need to create a temporary xml file, manipulate it and serialize it
on the disk. I found an important example for serialzing in that we have to
remove/erase the
original file when we are exporting to the same url. (backupfilehelper.cxx)
For creating a temporary xml file, it should be loaded from an existing
file on disk instead of creating a new one because we also need to export
all the original data from the document.
So, currently, I will need to find existing import filters from their
document types to xml (their document type interface can be queried from
the model), add window state data to settings and export to their original
file format. There are a few examples in tutorials to get filters from the
service factory by their name. Since filters have different implementations
to import/export, I might also have to add some implementations to existing
filters to add support for importing/exporting extra windowstate tag
element. As an example, the writer already has SwXMLExport::GetViewSettings
to get the window state in sw/source/filter/xml/xmlexp.cxx, which is around
the filter/xml.
In the next week, I will try to understand filters and to add in the
existing implementations of import/export xml-filters one by one.
Since I am new to filters, I apologize if I had made some mistakes.
Best,
Aung
[1] https://www.openoffice.org/xml/filter/
[2] https://www.openoffice.org/xml/xml_specification.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20240807/b3773a5a/attachment.htm>
More information about the LibreOffice
mailing list