It would improve consistency and clear understanding/learning for users to have the lists formatted and presented to them when choosing a default file format in Load/Save Options as well as the Save As format list. Right now the Save As format list offers the actual extension (e.g. .odt, .doc, .rtf) while the Default Format list does not display the file extension.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
This is still an issue in LODev-3.5Beta2 for Win32. The file format extensions still do not appear in the "Load/Save Options" but do appear in the "Save As type" list.
I think it's been implemented now. I'm using LO 4.0.4.2 (Win7 32bit) Please REOPENED if that UI on latest stable release still doesn't fit your need (also provide detailed explanation & screenshot if possible)
Created attachment 81016 [details] dialog from Options window showing format list
Created attachment 81017 [details] dialog from Save As window showing format list LO-Dev 4.0b2
(In reply to comment #3) > I think it's been implemented now. I'm using LO 4.0.4.2 (Win7 32bit) > > Please REOPENED if that UI on latest stable release still doesn't fit your > need (also provide detailed explanation & screenshot if possible) What I'm looking for is the file format list to have a continuity between the two lists. I've attached screenshots here from LO-Dev 4.0b2 I'm using on Win8_x64. The dialog in the Options does not display the format extensions, yet the Save As dialog does, and the order between the two is not the same. I think we can provide clarity better for the user by making the the lists _exactly_ the same. Does that make sense? Please let me know if you need more explanation, or if there is a reason for this I'm missing--thanks.
> The dialog in the Options does not display the format extensions, yet the > Save As dialog does, and the order between the two is not the same. I think > we can provide clarity better for the user by making the the lists _exactly_ > the same. Oo..I understand now. You have requested file format/extensions to be shown on: Menu: Tools > Options > Load/Save (General) > Always save as Also as a better clarity you want that lists ordered exactly the same as 'Save As' dialog box. I think those should be an enhancement request
Never independently confirmed by QA team - moving to UNCONFIRMED.
(In reply to ign_christian from comment #7) > Oo..I understand now. You have requested file format/extensions to be shown > on: > Menu: Tools > Options > Load/Save (General) > Always save as Good idea. > Also as a better clarity you want that lists ordered exactly the same as > 'Save As' dialog box. Consistency, consistency, consistency. I'm a big fan :-) > > I think those should be an enhancement request And I think the status should be 'NEW'. This seems related to UX and good design/layout, so I'll toss it over there.
To clarify what is requested: For the sake of consistency the list of formats under (now) Tools > Options > Load/Save General should have the same look and feel as the format list in file dialogs. That means 'ODF Text Document' should become 'ODF Text Document (.odt)' and the order of items has to get harmonized. This is clearly an EASYHACK. NEEDINFO for the codepointers.
(In reply to Heiko Tietze from comment #10) > To clarify what is requested: > > For the sake of consistency the list of formats under (now) Tools > Options > > Load/Save General should have the same look and feel as the format list in > file dialogs. That means 'ODF Text Document' should become 'ODF Text > Document (.odt)' and the order of items has to get harmonized. > > This is clearly an EASYHACK. NEEDINFO for the This search will catch all places where "ODF Text Document" is used, however it does not seem to find the menu in question http://opengrok.libreoffice.org/search?q=%22ODF+Text+Document%22&project=core&defs=&refs=&path=&hist=
Removing keyword 'needsDevEval' as this bug is an easyHack
A polite ping still working on this bug ?
I modify the files under /filter/source/config/fragments/filters/, for example modifying the file called 'writer8.xcu'. http://opengrok.libreoffice.org/search?q=%22ODF+Text+Document%22&project=core&defs=&refs=&path=&hist I changed the string <value xml:lang="en-US">ODF Text Document</value> in <value xml:lang="en-US">ODF Text Document (.odf)</value> and so on for all type of files extension. It worked! If I went to 'Tools->Option->Load/Save->General', I can saw correctly the name of the type and the extention (ex: "ODF Text Document (.odf)"). But whene I open the normal 'Save As' UI I found the double extension on my pulldown menu (ex:"ODF Text Document (.odf) (.odf)"). Does anyone can help me to find the right way?
I have solved the issue but due to some issue with my laptop will only be able to submit the patch after 28th Jan. Hence I assigned it to myself.
Still working on it. Progress till date: Added manual recognizing Doing right now Will be adding automatic reorganizing.
A long way to do that: https://gerrit.libreoffice.org/#/c/33655/ Making status NEW again.
Code pointers: sfx2/source/dialog/filtergrouping.cxx:897, sfx2::appendFiltersForSave() shows how to get the UI name and the extension of an SfxFilter sfx2/source/dialog/filtergrouping.cxx:1150, sfx2::addExtension() can create a string with both the filter name and the extension included, would be good to not duplicate that. It is probably necessary to change the reference parameter there to be an optional pointer instead, to be general. sfx2/source/bastyp/fltfnc.cxx:171, SfxFilterContainer::GetFilter4FilterName() can give you an SfxFilter just based on the internal (unique) filter name. I think based on those it should be put together a patch to provide extensions next to filters in the dialog.
Assigned state without assignee, let's fix that. :-)
Gian Domenico Ceccarini committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ccd8f402a79cbb43aa5bae7a11d3fcae92971c75 tdf#36747 Add extension in Tools > Options > Load / Save > General It will be available in 5.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
A polite ping, still working on this bug
James Raykowski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=343d40206a929969e1755b073edae91cc4bd9751 tdf#36747 add sort to match format list in file dialogs It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks so much for your work addressing this!