Description: When you open a password-protected document, you are presented with a simple GtkDialog window that has "Enter password" as the window title and this following layout: Enter password to open file: file:///home/bob/path/to/the/file.ods [ ******************* ] ( Help ) ( Cancel ) ( OK ) The "file:///full_path_blahblah" part bugs me, because it eats 90% of the space and makes it harder to see the actual file name. The path is also irrelevant to me because I _just_ requested to open the file, which either means I tried opening it from my file browser application (and therefore know the path) or that I tried opening it with LibreOffice's file open dialog (ditto) or that I tried opening it from the "Recent Files" quick menu (in which case I clearly don't care about the file's path, since I couldn't even be bothered to use a file manager to dig it up). So I would suggest that the string becomes: 'The file "%s" is password-protected. Enter the password to open it:' Where %s is the human-readable file name. It could be without the extension (ex: "TPS report") or with the extension (ex: "<b>TPS report</b>.ods") if you're worried about non-technical users needing to be able to cite the file extension along with the filename. The "OK" button in that GtkDialog should also be "insensitive" until something has been entered in the password field. Actual Results: Expected Results: Reproducible: Always User Profile Reset: No Additional Info:
What is your LibreOffice version? In a recent version, at least since LibreOffice 6.0, this dialog can be resized, so that the length of the path does not matter. Status set to NEEDINFO, please set it back to UNCONFIRMED once requested informations are provided. Best regards. JBF
Dear Jean-François Fortin Tam, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Hi J-B, I'm running version 6.4. Sure the dialog is resizeable, but the user shouldn't have to resize it, that's a pain in the butt (and I can assure you most will not even think of this possibility, judging from the non-technical users I study), it should be easily and quickly readable in the first place.
We decided to make dialog non-resizable unless user input requires to resize. And I support the idea. Code pointer: STR_ENTER_PASSWORD_TO_OPEN and STR_ENTER_PASSWORD_TO_MODIFY in uui/inc/strings.hrc and uui/uiconfig/ui/password.ui (we have 5 different passwd dialogs!) for the UI. Code is at uui/source/passworddlg.cxx. It's a generic dialog that might be used somewhere else. => medium difficulty and Thorsten for a second opinion.
After tinkering on the code related to this there are few things I wanted to ask/say - 1> The tdf#66553 - add file name to title bar for password managers - has added the file name along with its extension in the Password title box. 2> The link to the file doesn't seem wrong in the case of if this functionality is used by some extension to open a file (in case of remote access) it will help the user to know exactly where the file is located. This is how currently the password dialog pops-up - -|-------------------------------------------------------------------|- | Enter Password - dev.odt | | | | The file is password-protected. Enter the password to open it: | | file:///home/devansh/Documents/dev.odt | | | | Help Cancel OK | | | -|-------------------------------------------------------------------|- Is this intuition okay?
(In reply to Devansh Varshney from comment #5) > Is this intuition okay? Reading c0 again sounds like the way to go. (In reply to Jeff Fortin Tam from comment #0) > 'The file "%s" is password-protected.\nPlease enter the password:' Actual issue was the potentially lengthy folder structure; sometimes it might be relevant but most often it isn't. We could show the full URI in a tooltip.
(In reply to Heiko Tietze from comment #6) > (In reply to Devansh Varshney from comment #5) > > Is this intuition okay? > Reading c0 again sounds like the way to go. > > (In reply to Jeff Fortin Tam from comment #0) > > 'The file "%s" is password-protected.\nPlease enter the password:' > Actual issue was the potentially lengthy folder structure; sometimes it > might be relevant but most often it isn't. We could show the full URI in a > tooltip. I did made changes and this is currently what we are showing - https://pasteboard.co/LL2eIt03QDA8.png I am currently tweaking the OK button disability initially till any text is entered in the box.
https://pasteboard.co/YDGqDUqbO5C6.png Working as expected - https://youtu.be/BxyGar8kPbg
What is demonstrated in the video seems like a nice improvement! If you want to go the extra mile, as Heiko suggested maybe a tooltip on hover could be attached to label (for the folder path), though I don't know if that's really considered a must-have. Personally I can't think of a case where I would care to know the folder path for a file I just opened. I guess the next step would be to send a git merge request for this, in any case.
(In reply to Jeff Fortin Tam from comment #9) > What is demonstrated in the video seems like a nice improvement! > > If you want to go the extra mile, as Heiko suggested maybe a tooltip on > hover could be attached to label (for the folder path), though I don't know > if that's really considered a must-have. Personally I can't think of a case > where I would care to know the folder path for a file I just opened. > > I guess the next step would be to send a git merge request for this, in any > case. Sorry for the delayed reply as I opened this today. I did created the PR - https://gerrit.libreoffice.org/c/core/+/163924 I am looking for the option for the tooltip on hover.
(In reply to Jeff Fortin Tam from comment #9) > What is demonstrated in the video seems like a nice improvement! > > If you want to go the extra mile, as Heiko suggested maybe a tooltip on > hover could be attached to label (for the folder path), though I don't know > if that's really considered a must-have. Personally I can't think of a case > where I would care to know the folder path for a file I just opened. > > I guess the next step would be to send a git merge request for this, in any > case. added the option of complete file path on hovering the dialog box - https://youtu.be/p1K1U1FNdns
Created attachment 193130 [details] Screnshot with https://gerrit.libreoffice.org/c/core/+/163924 PS 9 in place for discussion in the Gerrit change
(In reply to Michael Weghorn from comment #12) > Created attachment 193130 [details] > Screnshot with https://gerrit.libreoffice.org/c/core/+/163924 PS 9 in place > for discussion in the Gerrit change Have a look at this video https://youtu.be/ugqUnZI7mS0 is this now aligned with what we were looking?
(In reply to Devansh Varshney from comment #13) > (In reply to Michael Weghorn from comment #12) > > Created attachment 193130 [details] > > Screnshot with https://gerrit.libreoffice.org/c/core/+/163924 PS 9 in place > > for discussion in the Gerrit change > > Have a look at this video https://youtu.be/ugqUnZI7mS0 > > is this now aligned with what we were looking? I'll leave deciding what's the wanted design to our UX team. In my opinion: * There's extra unused space above and below the label seems unnecessary. * The placeholder text in the GtkEntry is nice, but I wouldn't drop the prompt "Enter password to open file" (or similar) from above the entry, as it's e.g. otherwise no longer to be seen when starting to type a password (-> might be considered a bit of a lack of context). FWIW, I personally prefer to see the whole file name at once, but that might be different from what most users would want.
(In reply to Michael Weghorn from comment #14) > FWIW, I personally prefer to see the whole file name at once, but that might > be different from what most users would want. "... the whole file *path* at once ..." is what I mean. (Sorry for the confusion.)
(In reply to Michael Weghorn from comment #14) > I'll leave deciding what's the wanted design to our UX team. > > In my opinion: > * There's extra unused space above and below the label seems unnecessary. > * The placeholder text in the GtkEntry is nice, but I wouldn't drop the > prompt "Enter password to open file" (or similar) from above the entry, as > it's e.g. otherwise no longer to be seen when starting to type a password > (-> might be considered a bit of a lack of context). > > FWIW, I personally prefer to see the whole file name at once, but that might > be different from what most users would want. * I thought to add those space for a better hover if someone wants to look at the complete file path and it also seems a bit spacious. * I did this as this is how most of the password forms are being used on the apps and web specially. I can revert/change these changes
Created attachment 193186 [details] message box after c#15 This is now the UI for the password dialog is shown after the suggestion from c#15
(In reply to Devansh Varshney from comment #17) > Created attachment 193186 [details] > message box after c#15 > > This is now the UI for the password dialog is shown after the suggestion > from c#15 Information text on top ending with period, buddy label for the control left of it (it's needed for a11y) ending with a colon. Distance between info label and control 6px between buddy label and control 3px. Margin around the parent frame/grid 12px. The file "Untitled 1.odt" is password protected. _P_assword: [ ] I dislike the repetition at dialog title and content and suggest to change it to "Password protection", or the like. Please test with a ridiculous long file name. But showing this once sounds okay to me.
Created attachment 193202 [details] without the Password label
Created attachment 193203 [details] with the password label
I have added two Screenshot with/out Password label. here is the video for the file opening with a really long name https://youtu.be/j5vOE3hdu9U
https://youtu.be/P_5cQJLRi0I final clip
Created attachment 193297 [details] File created after patchset 15 I created a file in the morning with the File -> Save As -> tick the checkbox to save with password and it got saved with the password.
Created attachment 193298 [details] Title is Set Password devansh 132007_improve_pswd_msg_lckd_dcmnt instdir/program/soffice --writer warn:unotools.misc:10880:10880:unotools/source/misc/mediadescriptor.cxx:372: url: 'private:factory/swriter' com.sun.star.ucb.ContentCreationException message: "No Content Provider available for URL: private:factory/swriter at /home/devansh/libreoffice/ucbhelper/source/client/content.cxx:208" eError: (com.sun.star.ucb.ContentCreationError) NO_CONTENT_PROVIDER warn:legacy.tools:10880:10880:sfx2/source/control/bindings.cxx:1770: No cache for OfficeDispatch! warn:sal.file:10880:10880:sal/osl/unx/file_misc.cxx:659: Invalid file URL warn:sal.file:10880:10880:sal/osl/unx/file_misc.cxx:659: Invalid file URL