Created attachment 181222 [details] Shows the difference of the dialog between English and German GUI For this dialog you will need a connection to an external Firebird database (or HSQLDB - could be it works also). Open this connection, go to Tolls → User Administration. This dialog isn't resizable, but all buttons were shown in the dialog, if it is shown in English language. Now change, for example, GUI to German language. Button for deleting a user is only partly shown. You have to guess what will happen if you press this button, because dialog isn't resizable. Appears so since the dialog has been implemented, here since LO 7.0 Tested with OpenSUSE 15.3, LO 7.4.0.1
I imagine that the lack of basic resizability stems from line 9 in core/dbaccess/uiconfig/ui/useradmindialog.ui <property name="resizable">False</property> I suppose that there might be other issues to check with regard to packing of the objects in relation to the localized strings, but don't know which property this is in the UI dialog code.
Dialogs are non-resizable by design. We could adjust the width depending on content or get rid of the awkward buttons and have all in a menu button next to the dropdown. Or go with icon-only buttons.
(In reply to Heiko Tietze from comment #2) > Dialogs are non-resizable by design. We could adjust the width depending on > content or get rid of the awkward buttons and have all in a menu button next > to the dropdown. Or go with icon-only buttons. Unfortunately, this behaviour isn't consistent across the UI. For example, when comparing a Calc document, the changes dialog *is* resizable, and IMHO, it is good that it is, as trying to resize columns to get everything to fit in a preconstrained space, or else using the horizontal scroller is a PITA, especially, as in the case of the current dialog, if you move to right to see the users rights and permissions with the horizontal scrollbar, you lose sight of the table for which you are consulting/adjusting the permissions. That is not a user friendly experience at all, especially when you might have 50 or so tables with only slight variations in the table name (as is frequent in real world applications). I'm also not a big fan of simplifying down to the icon level only because this is highly dependent on how people see, visualise and understand graphical representations. I suppose having a menu button might be one way to simplify things, but I'm always concerned that the user of the interface ends up making more mouse movements than before, and would that really simplify things for keyboard only users as well? If I want to navigate that dialog with the keyboard, I can tab key through the buttons in sequence to get to where I want to and press enter on the highlighted key (or other UI component) to execute. If we add an "Action" button with a dropdown menu, then not only do I have to tab to the button, I then also have to key down (or up assuming both directions are allowed) to select the action I want to execute leading to the opening of the follow-on dialog. Honestly, I don't know what's best here, and it still doesn't solve the issue of the horizontal scrolling / absence of resizable dialog.
(In reply to Alex Thurgood from comment #3) > Unfortunately, this behaviour isn't consistent across the UI. From https://wiki.documentfoundation.org/Design/Guidelines/PropertyDialog: Dialogs should work with a size of 800 × 600 pixels and should not be resizable. Take care about high resolution displays (i.e. QXGA and more). We decided to make dialogs non-resizable as they are controlled by the content. However, if the dialog provides controls with user input that might exceed the designed width or height, eg. lists, edit fields etc., the dialog should be resizable. This particular dialog can easily have the proper size. My personal preference from c2 is to go with icon-only buttons right of the dropdown.
(In reply to Heiko Tietze from comment #4) > We decided to make dialogs non-resizable as they are controlled by the > content. However, if the dialog provides controls with user input that might > exceed the designed width or height, eg. lists, edit fields etc., the dialog > should be resizable. > > > This particular dialog can easily have the proper size. My personal > preference from c2 is to go with icon-only buttons right of the dropdown. I understand the rationale, but in this case, at least with regard to the permissions grid, we have an example of a control which exceeds the designed width. That would probably need addressing as well. Other UIs, e.g. MySQLWorkbench (not that I'm citing that as an example of best practice, but certainly an example of one current practice), proposes a grid control with vertically organized choices (tick box), rather than horizontal.
(In reply to Alex Thurgood from comment #5) > ... at least with regard to the permissions grid, we have an example > of a control which exceeds the designed width. Yes, that's true. The dialog has some other issues too such as no proper padding and the dropdown is somehow cut off at left for me (can see just *LIC).
As a first step before a full redesign, we can implement https://community.documentfoundation.org/t/proposal-remove-12-px-left-margin-from-all-gtkframes/6896 for this dialog and shave 36 pixels off the button row. https://gerrit.libreoffice.org/c/core/+/137642
Adolfo Jayme Barrientos committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d75c5c1f61a174b3b333e9db6536ab15cc37d00b tdf#149944 Do away with some excessive, unwarranted horizontal spacing It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
We discussed the topic in the design meeting. There was no objection neither to icon-only buttons (easiest way to solve the problem) not to the menu button next to the dropdown (a11y-wise the better solution).
Patch submitted https://gerrit.libreoffice.org/c/core/+/137754 but I wonder if the functions do their job as expected. I get two users, PUBLIC and SYS* and can delete both (which might lead to a crash). Adding a user has no impact on the list, and changing the password does not check the previous pw. Not many developers have touched the dialog in the past 21 years - actually no one to implemented any functionality.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/947ad25207a52d8d245a977430244cce38734b65 Resolves tdf#149944 - UI issues with Base's User Administration dialog It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Adolfo Jayme Barrientos committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/9591741dd8ae30c9bedbf3ada99730bca6180031 tdf#149944 Do away with some excessive, unwarranted horizontal spacing It will be available in 7.4.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.