When the open file dialog appears, it shouldnt be set to 'all files' but should be set to 'text documents' when i load writer, 'spreadsheets' when i load calc, etc.
Hi Jay, What is the logic in this, for a suite that serves all document types? Is it more logic that one wants to open a spreadsheet when one has a spreadsheet active, then when one has a text document open? Ciao, Cor
(In reply to comment #1) > Hi Jay, > Hi Cor, > What is the logic in this, for a suite that serves all document types? Well is there any logic behind having it default to 'all files' when it is unable to open all files (e.g. a .zip file). If anything, it should logically have an entry called 'all documents' for all the formats the suite is able to open. I think this would be the perfect setting for the Start Center. > Is it more logic that one wants to open a spreadsheet when one has a > spreadsheet active, then when one has a text document open? Yes i think it is more logical that if you have a spreadsheet active that you may want to open a spreadsheet, and if not, then you can easily set 'text documents' in the file types dropdown when you wanted to open a text document. Taken from another perspective, if i go into the menu and click 'LibreOffice Writer' and it opens and i want to open a file, would i want it to list anything but text documents.
Generally when I have a spreadsheet opened, the next file I want to open is not another spreadsheet but a text document or a presentation. So I think that the current behavior is the correct one. Where I agree with you is that "All files" shouldn't show the files that LO is unable to open. Best regards. JBF
Most end users consider each of the libreoffice components as a separate application, as libreoffice itself has entries for each of these components in the application menu. This is the normal behaviour of most office suites of having separate applications for each task. And when a user opens one of these apps, the app caters itself accordingly and one of things to cater is showing documents that app can load. Imagine opening MS Word and it showed spreadsheets in its open dialog. I am aware that libreoffice is a single application that can load all office suite documents and am happy that the option to load these are in the open dialog, but i think that file type drop down should be customized according to the application/context that it is being called. I remember not so long ago that i was going through a bug report for address book data source (bug 80741) and had to select a spreadsheet to attach to it, and still it opened the open dialog with 'All files'.
Well, 1/ LibreOffice is not a clone of MS-Office, the design of LibreOffice must not be done by Redmond. 2/ If MS-Word is not able to show spreadsheets and switch to MS-Excel to open them, I think it is a defect of MS-Office. That only proves that MS-Office is not an office suite but only a collection of office softwares. Did you find any complaint on users ML or on AskLibo against the current behavior of LibreOffice? Best regards. JBF
Hey JBF, I had made a number of arguments about the issue and its weird that you chose to only focus on the one microsoft sentence. I'm not expecting LibO to copy MS, as i had previously said, as the suggestion of this bug is focused on the behaviour of most users. Maybe we can set this as a bug for the 'all files' which you agree with and take the other suggestion of the default selecting of file type according to the application you are running to some committee or team who will make a decision about its behaviour.
See related UX Design discussion on Redmine... https://redmine.documentfoundation.org/boards/1/topics/246
It should be noted that writer and calc have their own dedicated uno commands (.uno:OpenFromWriter, .uno:OpenFromCalc), while impress, draw, base, and formula use the same command (.uno:Open).
Setting this to ux-advise, so others can weigh in on it.
Some old Mac formats don't have file extension at all (file extension is a Microsoft thing), so by making this change people that have such files won't see them. Although I'm not sure whether we should care about such uncommon formats in this regard?
(In reply to Maxim Monastirsky from comment #10) > Some old Mac formats don't have file extension at all (file extension is a > Microsoft thing), so by making this change people that have such files won't > see them. This change would be the default setting, which users can change to see things they dont see by default. This is the same as opening the insert > media > audio or video dialog and still having an 'All Files' entry at the bottom so a user can select a file that LO doesnt know is an audio or video file. Here is a typical scenario of a user opening the file dialog. 1) Benjamin has a document he wants to edit 2) He opens the start menu and click on 'LibreOffice Writer' 3) He clicks on the 'Open' button in the toolbar and navigates to 'My Documents' 4) He has a 100 files in that folder and the dialog shows him all of them If there are 30 text documents in the folder, that is all that he should be presented with and he has the option to change that default option, and ideally it should remember what that changed option is when he reopens the dialog (bug 89360).
(In reply to Yousuf (Jay) Philips from comment #9) > Setting this to ux-advise, so others can weigh in on it. I agree with having a filter set according the actual app. Perhaps we can store if someone lists all files and apply this setting next time. But I wouldn't always show documents after ODT was selected from Calc.
(In reply to Yousuf (Jay) Philips from comment #11) > This change would be the default setting, which users can change to see Ugh.. > If there are 30 text documents in the folder, that is all that he should be > presented with and he has the option to change that default option, and Utterly nonsense. Who says you Benjamin only uses text documents and is too dull to understand that you can open in Impress from Draw? (Oh sorry, simple: Calc from Writer) ?
(In reply to Cor Nouws from comment #13) > > If there are 30 text documents in the folder, that is all that he should be > > presented with and he has the option to change that default option, and > > Utterly nonsense. Who says you Benjamin only uses text documents and is too > dull to understand that you can open in Impress from Draw? (Oh sorry, > simple: Calc from Writer) ? We should have a good defaults with the ability for them to change. We shouldnt have it display all files and then a user has to change the filetype drop down to see specific types. If a user is in Writer, he will most likely want to open a document and if he is in Calc, he will most likely want to open a spreadsheet. We should cater to this behaviour, as it is good UX.
If this is only applicable to the LibreOffice file dialogs, then sure. By selecting that, i.e. Tools -> Options -> General: Use LibreOffice dialogs, the user (Benjamin, Eve, or Adrian) is already saying they want LO to be more "helpful" (or invasive). Not choosing it means the user prefers to have their DE file manager do the work--we need to respect that. So with the LibreOffice file dialogs--I agree that we could reasonably offer defaults other than "All files" for a launch from each component. The current top level selections for LibreOffice dialogs on the "File type"drop down are: All files Text documents Spread Sheets Presentations Drawings Web Pages Master documents Formulas Database documents If it can be done efficiently, replacing default "All files" for the generic for the component type would be reasonable. But just for the LO dialogs. It would be a loosing proposition to try to do it cross platform for all DE.
(In reply to V Stuart Foote from comment #15) > If this is only applicable to the LibreOffice file dialogs, then sure. You mean the dialogs that likely will be eliminated once the CMIS GSoC code is fully implemented. > By selecting that, i.e. Tools -> Options -> General: Use LibreOffice > dialogs, the user (Benjamin, Eve, or Adrian) is already saying they want LO > to be more "helpful" (or invasive). Not choosing it means the user prefers > to have their DE file manager do the work--we need to respect that. No most users go with defaults and rarely change it, so them not setting to see LO dialogs does not equal them choosing their DE for the dialogs. > It would be a loosing proposition to try to do it cross platform for all DE. Are you saying that its technically not possible to do this cross platform, or that its a bad idea?
(In reply to Yousuf (Jay) Philips from comment #16) > You mean the dialogs that likely will be eliminated once the CMIS GSoC code > is fully implemented. > Not a chance... while the CMIS work and additional "File Services" dialog support is useful for getting to remote content off system, the LO dialogs for local content aren't going to change that much. UI may change--even drastically, but they'll always be there in some form as an alternative to DE file managers. Again, showing available document choice by component, a choice other than "All files", is reasonable but just for the LO provided dialogs. > Are you saying that its technically not possible to do this cross platform, > or that its a bad idea? Possible, yes. But a major refactoring and need for integration into native dialogs across all implementations. So, yes it would be a *bad* idea as it would offer little for improved UX with potential for a whole lot of pain in making it function correctly.
(In reply to Yousuf (Jay) Philips from comment #14) > If a user is in Writer, he will > most likely want to open a document and if he is in Calc, he will most > likely want to open a spreadsheet. Prove that. IMO it's utterly nonsense.
(In reply to Cor Nouws from comment #18) > Prove that. IMO it's utterly nonsense. Ah well, I suddenly realize that this is by our (..) definition. So pls ignore my request..
(In reply to V Stuart Foote from comment #17) > Not a chance... while the CMIS work and additional "File Services" dialog > support is useful for getting to remote content off system, the LO dialogs > for local content aren't going to change that much. UI may change--even > drastically, but they'll always be there in some form as an alternative to > DE file managers. Yes i guess its worth keeping for people who wish to use it, though the one main benefit of it was that it was the only way to connect to CMIS. > Again, showing available document choice by component, a choice other than > "All files", is reasonable but just for the LO provided dialogs. Guess we wont agree there, as we shouldnt have one behaviour in the LO dialogs and another in the OS dialogs. > Possible, yes. But a major refactoring and need for integration into native > dialogs across all implementations. So, yes it would be a *bad* idea as it > would offer little for improved UX with potential for a whole lot of pain in > making it function correctly. Preselecting an entry in the filetype dialog should be a simple process, else placing that entry at the top of the list and 'All Files' at the bottom is another means of achieving it (we do this in the insert audio/video dialog).
(In reply to Yousuf (Jay) Philips from comment #16) > You mean the dialogs that likely will be eliminated once the CMIS GSoC code > is fully implemented. Unlikely. There are several use-cases where we can't use the native dialogs. One example is the infamous crash in the KDE4 dialogs, where we disable the native dialogs at runtime if unpatched Qt4 lib is detected (Qt4 should be patched by the distro, but we can't force distros to do this). Another use is in the generic vclplug (i.e. export SAL_USE_VCLPLUGIN=gen before running LO). So we can't remove these dialogs, as long as this vclplug exists.
(In reply to Maxim Monastirsky from comment #21) > One example is the infamous crash in the KDE4 dialogs... Wait a moment. You want LibO to add workarounds for every bug that occurred in the last centuries with a solution inferior to most users? I wouldn't care about KDE bugs even when Qt4 was the actual platform - and I'm coming from KDE using it daily. Admittedly, there are some distributions still on KDE4. Inferior means, big players employ hundreds of usability and design freaks. No chance to be better on such a core dialog. You make core features worse for sake of one added functionality - that we now moved somewhere else.
(In reply to Heiko Tietze from comment #22) > You want LibO to add workarounds for every bug that occurred > in the last centuries Of course not, and that's why we have NOTOURBUG status in Bugzilla. But in this case LO uses a code path that apparently not widely used elsewhere, and as a result all bug reports about it are going to *our* Bugzilla, not elsewhere. (and we got huge amount of duplicates of this.) > with a solution inferior to most users? Well, given that the KDE dialog just crashes when you move the mouse on it, I can't see how bringing something that at least works is inferior. > Admittedly, there are some distributions still on KDE4. Note that LO doesn't have KDE5 support at all. You're still using the LO's KDE4 backend, even under KDE5.
Migrating Whiteboard tags to Keywords: (needsDevEval, topicUI) [NinjaEdit]
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
What about introducing a new option into the File Type field of the File -> Open dialog? Now we have: - All files - Text Documents - Spreadsheets - ... - Database Documents I think an extra option right at the second place would solve the problem of many use cases: - All files - All LibreOffice files <--- this is the new option here - Text Documents - ... - Spreadsheets - Database Documents If the user picks the "All LibreOffice files" option then they can see all the text documents, spreadsheets, ..., database documents, everything LO can open but would not see *.zip, *.dll, etc. files. In each LO application the "All LibreOffice files" should be the default right after the installation and later on, when the user changes it in any of the LO applications then all of the applications whould keep the option the user used last time _in_that_application_. This means if you open solely drawings from Draw then you see only drawings in the dialog of Draw but you still can see "All LO files" in Writer and Calc if you frequently open texts from Calc and spreadsheets from Writer.
I'm against all attempts to obfuscate the fact that LibreOffice is a multi-module program :)
We discussed the topic in the design meeting. Balancing the pros and cons more votes agree with the idea. So we suggest to change the default entry in the file picker to list module specific files. Implementation should take care about extra content like insert images in Writer that must not be limited to text documents. .uno:OpenFromWriter should show text documents, .uno:Open should show all files Being an easy hack this topic is actually not well suited because the controversial discussion.
(In reply to Heiko Tietze from comment #28) > ... Implementation should take > care about extra content like insert images in Writer that must not be > limited to text documents. Opening an image through the file open dialog doesnt open it in writer, so not sure what this means. > .uno:OpenFromWriter should show text documents, .uno:Open should show all > files This is incorrect as we dont have dedicated uno commands for impress and draw and i would assume .uno:OpenFromWriter and .uno:OpenFromCalc are simply aliases of .uno:Open. Maxim: thoughts?
I agree with Jay. I fail to see why .uno:Open and .uno:OpenFromWriter should be different in this regard. Otherwise I'm not strongly against this change, but it would be nice to remember if a user last selected "all files", so people who depend on a large amount of files with non-standard extensions won't need to switch the filter over and over again. (In reply to Yousuf Philips (jay) from comment #29) > i would assume .uno:OpenFromWriter and .uno:OpenFromCalc are simply > aliases of .uno:Open. They are not. Try to put both on a toolbar in Writer, and use them to open html file. .uno:Open will open it in Writer/Web, while .uno:OpenFromWriter will open in ordinary Writer (and similarly .uno:OpenFromCalc will open the html in Calc).