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
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
