Apache OpenOffice (AOO) Bugzilla – Issue 115214
Export file picker does not remember last file type anymore
Last modified: 2017-05-20 10:55:32 UTC
In Draw, invoking "File, Export", the file picker always suggests PCT as file type. Expected behavior: The file picker should suggest the last used file type. This expected behavior got fixed in issue 103568 (integrated in OOo 3.2) and has been working fine for Draw since then, but the last used file type is not saved in Writer. Issue 109668 introduced a fix for writer by always suggesting a default file type, but corrupted the behavior for Draw. With over 20 export file types available in Draw, having the last used filter pre-selected is highly desirable.
adding CCs
Tested this on Windows and Linux. Using File/Export in Draw I always get png as file type , working in a saved or in a fresh file. This is visible in 3.2.1 and in OOO330_m12.
Oops, sorry, I was mistaken: Please check it with 3.2.0. I have been using only the PNG export recently, so I haven't noticed the change when I switched to 3.2.1. The regression was already introduced in that version.
I do not think that this issue is a showstopper. It is not a regression from the last version (3.2.1), there is no data loss and the Office does not crash. So no criteria fro a showstopper fits here...
agreed, no stopper, but shouldn't we confirm this issue and fix this for the coming release on the DEV300 code line asap ?
The definition of the default filter is that it should be taken per default. So in case one of the filter is default one it is a correct behavior to use it in the dialog. If we want to change it, we should do it as a feature change. The behavior introduced by the patch in the issue 103568 is just an implementation detail, since it let the file-picker implementation decide which filter should be taken. And I am in doubt that all the file-pickers remembered the last used filter. Additionally, the behavior of any file-picker ( especially a system file-picker ) could be changed any time. Such implementation details are OK, but it can not be expected that they will be a part of a feature set. If it should be a reliable feature, lets design and implement it as such. If it should be just an implementation that probably works somehow with some file-pickers, then it can not be really treated as a regression, if it does not work suddenly. I would like to set the issue to enhancement and implement the behavior for all the file-pickers in framework in reliable way, if nobody complains.
reassigned
Since nobody complains to my arguments, I remove the Keyword regression and set the issue type to Enchancement.
Reset assigne to the default "issues@openoffice.apache.org".