https://bugs.documentfoundation.org/show_bug.cgi?id=165474
--- Comment #26 from Eyal Rozenberg <eyalr...@gmx.com> --- (In reply to Heiko Tietze from comment #25) > Gtk3 draws natively with large margins leading to more aggressive overflow > (but properly adds controls to scroll through the list). We cannot change > this behavior except by enlarging the whole dialog, in theory. Of course we can change it. * We can draw the dialog differently on GTK3. Specifically, we can use a control similar to the one we use in Tools > Options, which has little vertical padding/margins. * We could use that control for this dialog, and other overflowing dialogs - on all VCLs - which would be less visually pleasing perhaps, but would forego the need for VCL-specific dialog layout if that's an issue. * Even easier - we could render all overflowing dialogs with horizontal rather than vertical tabs. And at least one, if not two, of these stop-gap solutions are easy to implement. (Actually, I also suspect that the vertical spacing of the tab headers we have now can in fact be manipulated with some programming effort, although that's only speculation.) This serious problem was reported well before 25.8 was released, and that release should absolutely not have taken place with vertical tabs enabled where they must not be. This frivolous attitude reminds me of the active cell rectangle situation: Massive UI degradation being adopted with nothing but a shrug, with people having to clamor and make a fuss afterwards to get that retracted or fixed. > The Gtk > design was build for less complex dialogs and considering alternative input > methods. You can start the application with the generic VCL or for Qt, Heiko, we've been over this endless times in many bugs. It is entirely irrelevant to tell a bug reporter that "you can do X" or "you can do Y". The bug is in the how LibreOffice behaves when the typical user runs it; it is not about the workflow of a power-user who knows about VCLs and switching them can arrange for more convenient settings. The only situation in which you can dismiss bugs with a certain VCL by saying "use another VCL", is if that VCL is not intended for public use. You can say this (maybe) about issues with QT6, or GTK4, or gen; not about GTK3. We cannot legitimize an introduction of a massive, critical degradation in the UI by the fact that only 10% or 8% of users experience it. Please don't wait for other users to come shouting about this (like with the active cell rectangle situation). > => NAB/NOB You made no argument for "not a bug", so how can you even suggest that? As for "Not our bug" - we chose, or rather you chose, to have this dialog look this way. We can draw it differently. So it is our bug. -- You are receiving this mail because: You are the assignee for the bug.
