Steps to Reproduce: 1. Click any paragraph style from the sidebar; 2. Right-click and click "Modify". Current Result: Dialog is is too tall: OK/Cancel buttons are not visible. Expected: OK/Cancel buttons are not visible. Fedora 32, Gnome 3.36.8, Wayland. 1366*768 laptop display.
Bisected to the following commit: author Miklos Vajna <vmiklos@collabora.com> 2020-05-25 21:03:56 +0200 committer Miklos Vajna <vmiklos@collabora.com> 2020-05-26 10:20:19 +0200 commit 5202771939da66ac85ca3221d69e7e5f5cca8da7 tdf#130456 sw: enable semi-transparent text for char style dialog That commit added SVX_ENABLE_CHAR_TRANSPARENCY on this dialog. With this control, the dialog grows taller and thus the OK/Cancel buttons are not visible on small displays. A solution may be putting the "Transparency" control to the right of "Font Color".
Adding Miklos Vajna to cc: would you please take a look? Thanks.
Created attachment 168657 [details] screenshot: bad after commit 5202771939da66ac85ca3221d69e7e5f5cca8da7
Created attachment 168658 [details] screenshot: good before commit 5202771939da66ac85ca3221d69e7e5f5cca8da7
Created attachment 168659 [details] paragraph style in gtk3
(In reply to paulo g. from comment #5) paulo g: Do you know which commit has fixed this issue?
Also, the version field should be the earliest libreoffice version this bug appears, not the version you have tested to have fixed this issue. You may not reproduce this this on your machine if you have a larger display, but this issue may still exists on small displays like a laptop.
Set back to unconfirmed.
Font effects tab has the Transparency option below Font color, but maybe it could be positioned next to it. Anyway, we are breaking our promise of 1024x768 resolution minimum. Arch Linux 64-bit Version: 7.3.0.0.alpha1+ / LibreOffice Community Build ID: 8c66455df8f6a26c314290f252bedbc19db6b327 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 25 November 2021
HIG [1] says: "Dialogs should work with a size of 800x600 pixels..." In my system with kf5 VCL the dialog takes 839x690px so we need to save a few pixels. Version: 7.2.2.2 / LibreOffice Community Build ID: 20(Build:2) CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (en_US.UTF-8); UI: en-US 7.2.2-4 Calc: threaded [1] https://wiki.documentfoundation.org/Design/Guidelines/PropertyDialog
Created attachment 176518 [details] Screenshot with new layout Using master/7.4 I get 972x599px for gtk3 (depends on theming as well) and 846*690 in case of native kf5. Moving the spinbox does not solve the issue since two controls follow underneath Relief: Emphasis Mark and Position (no idea under what circumstances those are shown).
(In reply to Heiko Tietze from comment #11) > (no idea under what circumstances those are shown). In case of CTL/CJK (tools > options > language: Asia/Complex).
Moving position to the right of Emphasis would save a few pixels but the Font tab takes a lot of space with CJK and CTL enabled. So still 690px for me. Trying to move controls next to the labels (not below as today)...
Created attachment 176527 [details] Screenshot #2 (In reply to Heiko Tietze from comment #13) > Trying to move controls next to the labels (not below as today)... Still no luck
Seems like playing whack-o-mole with these dialog heights with gtk3 backend. Caolán fixed bug 139332 by reducing height (row count of dialog); Daiwanshu fixed bug 128176 by enabling vertical scrollbar for the OT Features. See also bug 146675 affects the Customize dialog on Wayland w gtk3 backend. What are you thinking here Heiko? Seems more than a cosmetic issue in that the gtk3 (and gtk4?) buttons are sized differently; the other vcl backends seem unaffected.
The dialog is badly sized in case CTL/CJK languages are enabled. My patch solves this by moving the languages into tabs. Asked in the CTL/CJK Telegram channel about opinions and while it was necessary in the past to have different fonts this is not necessary anymore with Noto, for example. But that's off-topic here. Gtk3/4 sized buttons will always be an issue as long we don't start the development from scratch with Qt. Challenge for UX is to find good places for controls. And I doubt there is a final state.
The original report was just because of the additional line, the reporter was happy before that extra line was added. So I don't know why just putting the new widget in the free space in the first line isn't good enough?
(In reply to Caolán McNamara from comment #17) > The original report was just because of the additional line, the reporter > was happy before that extra line was added. So I don't know why just putting > the new widget in the free space in the first line isn't good enough? Moving one control has not much effect. Please check with CTL/CJK enabled in tools > options.
Created attachment 177546 [details] for me, before
Created attachment 177547 [details] how it looks after for me on a default fedora install (similar to the original reporter I think) it just about squeaks in under the 768 size with the minimal change.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d73602dc51aa8829fc88e5e67e2b0c4da6b8f715 Resolves tdf#139395 - Redesign of font name and effects pages It will be available in 7.4.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.
The current fix is not that good in my opinion. It is not intuitive. People who uses both Western, CJK and Complex fonts always need to look into the "Font" tab to see what the font is used for each of them, and to see whether the font size, font weight etc are the same between Western, CJK and Complex. Previously those three are within the same page, but now they are separated into three different sub-tabs. Now we need extra clicks into each tab to do such observation. Actually it is not three more clicks: When I click on western and see the font size is 12pt, then I switch to CJK and see the font size is 10.5pt, then I may not remember what was the font size for Western and then I switch back to Western. When I need also to switch back and forth to make sure the font weight for each of the tab are all non-bold.... It makes more sense to keep them on the same page.
(In reply to Kevin Suo from comment #22) > The current fix is not that good in my opinion. It is not intuitive. > > It makes more sense to keep them on the same page. I agree with that. At last week's Japan team meeting, the new UI was unpopular with all three participants.
(In reply to Kevin Suo from comment #22) > The current fix is not that good in my opinion. (In reply to Shinji Enoki from comment #23) > I agree with that. Please file a new ticket with a proposal other than reverting the patch. The introduced tabs give more space and make the dialog fit into small screens.
In this issue, first reporter Suo pointed out the problem on the "Font Effects" tab page. I wonder that there were no need for the "Font" tab page layout to be changed in the first place. As reported in Bug 146928, the current changes to the "Font" tab page hurt UX for CJK users, and possibly CTL users. Also Suo pointed out that in Comment 22. At least for the "Font" tab page, I hope to be returned to the previous layout. The other day, I commented in Teleglam related to this fix. The focus of my comment was "use the same font as Wetern". At that time, I thought that the tab notebook UI might be possible if that was the premise, but my thought might has been poor. "Use the same font as Wetern" was discussed in Bug 146910, and it seems that no support has been obtained so far. Therefore, it can not be the premise. As mentioned in Comment 16, I think it's off-topic here.
Personally I'd prefer the sections made collapsible, remember their collapsed state, and make all dialogs have scrollbars. [/rant off]
> Personally I'd prefer the sections made collapsible, remember their collapsed state, and make all dialogs have scrollbars. [/rant off] If scrollbars are allowed, I think it's an idea. I don't know if it's the best. I think it's better to look for a layout that fits three language groups compactly in one pane. For example, if we could stop adding frame headings for each language group, it would be much more compact. I drew a sloppy test layout on pages 8 and 9 of Bug 146928 attachment 178567 [details]. Please take a look if you like. The interface of users who use only Western seems to be quite different from what we are discussing now. This seems to complicate the situation.