Step to reproduce: 1. Create a new Draw files 2. Rename existing first page (e.g. Test) 3. Create a new page (Page > New Page, or in the page left side panel right click > New Page)) 4. Rename the new page with the same name as the first page (e.g. Test) (Page > Rename page, or in the page left side panel right click > rename page) Actual result: The OK button disabled but there's no warning tell me that renaming with already used name is not allowed. Expected result: there's warning (a dialog?) tell me that renaming with already used name is not allowed.
Thank you for reporting the bug. I can not reproduce this bug in Version: 6.4.0.0.alpha1+ (x86) Build ID: ec7374ff84c71edfbb30d6e4dc5b486b6df7107f CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-11-10_21:37:30 Locale: en-US (en_US); UI-Language: en-US Calc: threaded and in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
Thank you for reporting the bug. To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
I can reproduce it in Version: 6.5.0.0.alpha0+ Build ID: 3a6f270edfffb97763927b2732feacedbdac1e80 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded but let the UX Team decide whether we want to show the warning. Do we show this warning in other dialogs ?
> Do we show this warning in other dialogs ? In Impress, this issue is happen as Draw and Impress shares the same based code (CMIIW) I have checked similar step in Calc, after trying to rename a new sheet with existing name, there's dialog appears.
Created attachment 156158 [details] A dialog warning in Calc after trying to renaming with same name sheet
Disabling the action when requirements are not fulfilled (see bug 62851) is the correct way to go. While this behavior is common (and IMHO easy to grasp), we could show a warning like "Name has been assigned to another slide" (or page). I would rather change Calc to not interrupt the workflow (as done in bug 128521).
(In reply to Heiko Tietze from comment #6) > Disabling the action when requirements are not fulfilled (see bug 62851) is > the correct way to go. While this behavior is common (and IMHO easy to > grasp), we could show a warning like "Name has been assigned to another > slide" (or page). I agree that disabled action is also easy to grasp, but a warning will provide better understanding, user would now what really happen. > I would rather change Calc to not interrupt the workflow (as done in bug > 128521). +1 for your propose just like tdf#128521, it would reduce action since an another dialog required another action button (e.g. "OK"). My Nautilus 3.26.x (Ubuntu 18.04) has similar approach.
We discussed the topic in the design meeting. Three options are feasible: background of the edit field becomes red (as known from Calc, conditional formatting with wrong range values). some text, a tooltip and an icon. The last two are most common: set_message_type(weld::EntryMessageType::Error) adds a tiny icon to the input and the tooltip should explain why the button is disabled.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a4f5c8d38e307bb37f08e8f6ef3cfc9ffac84304 Resolves tdf#129032 - Missing warning when renaming page It will be available in 7.0.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.
I've found this same issue happens in Impress, should I file a new bug report?
(In reply to Rizal Muttaqin from comment #10) > I've found this same issue happens in Impress, should I file a new bug > report? Are you sure it's not fixed with the patch? IIRC I double checked Impress since the patch affects cui/... And checking again now the tooltip shows up for both Draw and Impress.
(In reply to Heiko Tietze from comment #11) > (In reply to Rizal Muttaqin from comment #10) > > I've found this same issue happens in Impress, should I file a new bug > > report? > > Are you sure it's not fixed with the patch? IIRC I double checked Impress > since the patch affects cui/... And checking again now the tooltip shows up > for both Draw and Impress. Ah sorry I forgot if we implement the tooltip. But this made me aware another issue, the tooltip is not visible if the cursor is not near the window dialog e.g when renaming the slide/page, the cursor left in the slides pane. Should we go with a text below the box?
(In reply to Rizal Muttaqin from comment #12) > Should we go with a text below the box? Current solution is the best. You edit the field and any key stroke has an effect. So users are aware of the reason, though not exactly and therefore can get further info per tooltip.
(In reply to Heiko Tietze from comment #13) > Current solution is the best. You edit the field and any key stroke has an > effect. So users are aware of the reason, though not exactly and therefore > can get further info per tooltip. Make sense, though I prefer more visible warning just like the illegal char case (tdf#128521). Let's it as is.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0108ed5cefdf259f5374d6c6aaf7ae14fea16181 related: tdf#129032: uitest: check ok button is disabled It will be available in 7.2.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.