[Libreoffice-bugs] [Bug 153899] Clone format of unmerged cells breaks up merging, applies to first unmerged cell only
https://bugs.documentfoundation.org/show_bug.cgi?id=153899 --- Comment #18 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #17) > (In reply to Eyal Rozenberg from comment #16) > > The merged state is - AFAIK and correct me if I'm wrong... > > You are wrong. Please read the documentation, try yourself, and follow the > comments here again I have, and I have, and I have, and it's all consistent with my assumption. For example, I I merge two cells with "a" and "b" respectively, or one cell with "ab" and an empty cell - with "move the contents to the first cell" - unmerging in both cases results in the first cell having "ab" and the second cell being empty. So the merge state does not seem to include how the merge was performed. > we provide an exceptional and outstanding feature. I'm not sure I understand what you mean by this. > (In reply to Heiko Tietze from comment #11) > > => NAB That's not an option IMNSHO. Users - most or nearly-all of them, I would argue - expect clone-formatting applied to a merged cell to format that entire area. And their expectation is perfectly justified. If they don't get a dialog for selecting the kind of action they want - then it has to be one of the two alternatives: Either format the broken-up cells, overwriting their pre-merge formats (Q1: No Q2: Yes); or don't break up the merged cell (Q1: Yes). The current behavior (Q1: No Q2: No) does absolutely not make sense and interrupts users' work, making them correct this gaffe of a behavior they did not want. If you're worried about the non-first cells' format not being re-applied on unmerge - then you should probably support the Q1-Yes option. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153899] Clone format of unmerged cells breaks up merging, applies to first unmerged cell only
https://bugs.documentfoundation.org/show_bug.cgi?id=153899 --- Comment #17 from Heiko Tietze --- (In reply to Eyal Rozenberg from comment #16) > The merged state is - AFAIK and correct me if I'm wrong... You are wrong. Please read the documentation, try yourself, and follow the comments here again - we provide an exceptional and outstanding feature. (In reply to Eyal Rozenberg from comment #16) > What do you think? (In reply to Heiko Tietze from comment #11) > => NAB -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153899] Clone format of unmerged cells breaks up merging, applies to first unmerged cell only
https://bugs.documentfoundation.org/show_bug.cgi?id=153899 --- Comment #16 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #15) > It depends on how you merge cells. It cannot depend on how the cells were originally merged; because the choices you mention are possible actions, not choices between different kinds of merged-state. The merged state is - AFAIK and correct me if I'm wrong - made up of only the set of cells the current cell is merged into. So, once the cell is merged - LO has no information regarding how the user chose to merge it. It will have some implicit information via whether or not the cells other than the first have any contents. Are you saying that this information is taken into consideration? > we apply the format as done for hidden > columns/rows: if the surrounding cells are selected it applies to the hidden > too. Select the cell left or right of the merged cells and apply the direct > formatting to see the difference. Ah, now that's an interesting point! The minutes did not mention that. Was this discussed? Anyway, here I disagree that this should be the behavior. Why? Because the principle should be taking hints of the user's intent from their action. If clone-formatting is applied to a certain cell, with the cell next to it being hidden - the user has given no indication that they are interested in formatting the adjacent hidden cell. But in the case of selecting a merged cell as the target of clone-formatting, the user _does_ indicate they want that area to be formatted a certain way. Even if we're breaking up the cell - which is not obviously what the user wants, but let's say it's kind of acceptable - we can't go yet another step in countermanding their expressed intent, and only apply formatting to the first of the unmerged cells. > [1] The merge option dialog shows up when the cells contain content. See > also https://help.libreoffice.org/latest/en-US/text/scalc/01/0506.html This brings up an interesting possibility which we have not discussed. Why does that dialog exist? Because we could not reconcile different and contradictory possible user intents when merging a cell. We (must have) identified at least two common intents, and perhaps added another possibility - and since we couldn't always choose one over the other, we opted for the cumbersome and flow-interrupting behavior of opening up a dialog. Perhaps we need to do the same thing here? If you ask me, I would be willing to assume the intent of not breaking up the cell at all; or of breaking up and formatting all broken up cells - but I absolutely am not willing to accept the assumption of the user wanting to break up the cells and formatting just one of them. That seems to me like the more esoteric use case. But if you or others believe that this is a common intent - we could instead bring up a dialog, and offer several options: * Keep merged cell, apply formatting other than merge state * Break cells up, format all of them * Break cells up, format the first What do you think? -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153899] Clone format of unmerged cells breaks up merging, applies to first unmerged cell only
https://bugs.documentfoundation.org/show_bug.cgi?id=153899 --- Comment #15 from Heiko Tietze --- (In reply to Eyal Rozenberg from comment #14) > Ok, that address Q1. But now please address Q2. It depends on how you merge cells. Assuming you keep the default [1] you keep the content of hidden cells. And we apply the format as done for hidden columns/rows: if the surrounding cells are selected it applies to the hidden too. Select the cell left or right of the merged cells and apply the direct formatting to see the difference. [1] The merge option dialog shows up when the cells contain content. See also https://help.libreoffice.org/latest/en-US/text/scalc/01/0506.html -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153899] Clone format of unmerged cells breaks up merging, applies to first unmerged cell only
https://bugs.documentfoundation.org/show_bug.cgi?id=153899 --- Comment #14 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #13) > Merged state is a direct formatting and copied with clone formatting. It is > not an attribute of the cell style. Ok, that address Q1. But now please address Q2. > Please don't add UX keyword when a topic has been discussed. It's sufficient > to reopen the ticket. Ok. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153899] Clone format of unmerged cells breaks up merging, applies to first unmerged cell only
https://bugs.documentfoundation.org/show_bug.cgi?id=153899 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists | |.freedesktop.org| --- Comment #13 from Heiko Tietze --- Merged state is a direct formatting and copied with clone formatting. It is not an attribute of the cell style. => NAB Please don't add UX keyword when a topic has been discussed. It's sufficient to reopen the ticket. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153899] Clone format of unmerged cells breaks up merging, applies to first unmerged cell only
https://bugs.documentfoundation.org/show_bug.cgi?id=153899 Eyal Rozenberg changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED CC||libreoffice-ux-advise@lists ||.freedesktop.org Resolution|NOTABUG |--- Keywords||needsUXEval --- Comment #12 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #11) > We discussed the topic in the design meeting. Please read my last comment. > LibreOffice offers the outstanding feature to merge cells in three different > ways. ... not relevant to this bug. > If you copy a merged cell you expect the merged state to be taken into > account. The same is true for clone format that takes the merge state as a > formatting attribute and applies it to the target. It's a convenience > feature in alignment to the copy function. All features are convenience features. One can always edit an ODF file manually. The use of this term is suspicious. > Cell formatting is preferably done per cell style. Cell formatting is application of style + DF. When you clone-format, you clone the style and the DF. > The style with all > defined attributes will be applied to the merged cells without affecting the > state. (facepalm!) 1. This bug was opened about the fact that clone-formatting _does_ affect the merged state - it breaks up the cells. You're claiming that it doesn't? That's nonsensical. In fact, in the design meeting, the conclusion was that the clone-formatting _should_ affect the merged state. 2. This bug is about cloning DF, not cloning styles. Given that the cells are broken up, the complaint is that the DF is applied to just one of them. 3. No, the style is _not_ applied to all of the cells! Just to the first one. If you change the style of D3 in the reproduction instruction to some other style (e.g. "my_style" with a blue background) - only the first of the broken-up cells will get "my_style" and the blue background; the rest will remain in Default Style. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153899] Clone format of unmerged cells breaks up merging, applies to first unmerged cell only
https://bugs.documentfoundation.org/show_bug.cgi?id=153899 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Resolution|--- |NOTABUG Status|UNCONFIRMED |RESOLVED --- Comment #11 from Heiko Tietze --- We discussed the topic in the design meeting. LibreOffice offers the outstanding feature to merge cells in three different ways. Either the content if the cells to merge is collected into the new cell (eg. A1=1, B1=2 => A1 = 12), the cell content is kept hidden (and unmerging is possible), or only the content of the first cell is kept. If you copy a merged cell you expect the merged state to be taken into account. The same is true for clone format that takes the merge state as a formatting attribute and applies it to the target. It's a convenience feature in alignment to the copy function. Cell formatting is preferably done per cell style. The style with all defined attributes will be applied to the merged cells without affecting the state. => NAB -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153899] Clone format of unmerged cells breaks up merging, applies to first unmerged cell only
https://bugs.documentfoundation.org/show_bug.cgi?id=153899 --- Comment #10 from Eyal Rozenberg --- This was discussed in the design meeting this evening, but - not in a satisfactory manner IMHO. Here's what the minutes say: > + merging cells with the keep option does exactly this, we > must not format hidden cells this bug does not regard the merging action, so either this sentence is incorrect or I misunderstand it. > + copying/cloning merged cells takes merge state into account, > however, applying a format via cell style, which is the supposed > workflow does not I'm sorry, that does not make sense. This bug is about "clone formatting". If it takes the merge state into account, the answer to Q1 is affirmative. Now, what about Q2? > + cloning the merged state is a convenience feature I don't understand this sentence. Cloning is a feature in LO calc, and you guys decided it also applies the merged or unmerged state. What does it matter whether cloning is a "convenience feature" or not? Given your position, the obvious decision is for the format to apply to all unmerged cells. I haven't read any argument for the alternative in the minutes. And thus I don't understand why you concluded > => WF/NAB rather than will-fix, is-a-bug. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153899] Clone format of unmerged cells breaks up merging, applies to first unmerged cell only
https://bugs.documentfoundation.org/show_bug.cgi?id=153899 --- Comment #9 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #8) > Which has been done on bug 89951. But Eyal has for sure an opinion what > makes this ticket special... Heiko, please read my comment #6 which explains why these are quite distinct issues. So, no, this has not gotten the UX team input. And - yes, I checked the comments on bug 89951 to make sure they don't address this one. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153899] Clone format of unmerged cells breaks up merging, applies to first unmerged cell only
https://bugs.documentfoundation.org/show_bug.cgi?id=153899 --- Comment #8 from Heiko Tietze --- (In reply to eisa01 from comment #7) > ... as it was deduplicated need UX team input again Which has been done on bug 89951. But Eyal has for sure an opinion what makes this ticket special... -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153899] Clone format of unmerged cells breaks up merging, applies to first unmerged cell only
https://bugs.documentfoundation.org/show_bug.cgi?id=153899 eisa01 changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval OS|macOS (All) |All --- Comment #7 from eisa01 --- I take it this is not a macOS bug then, and as it was deduplicated need UX team input again -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153899] Clone format of unmerged cells breaks up merging, applies to first unmerged cell only
https://bugs.documentfoundation.org/show_bug.cgi?id=153899 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists | |.freedesktop.org| -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153899] Clone format of unmerged cells breaks up merging, applies to first unmerged cell only
https://bugs.documentfoundation.org/show_bug.cgi?id=153899 Eyal Rozenberg changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|UNCONFIRMED --- Comment #6 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #5) > Many duplicates Such as? > all combined at bug 89951. That bug is about how to format the merged cell given the pre-merge cell formats. This bug is not about that; nor would resolving any of the two bugs resolve the other. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153899] Clone format of unmerged cells breaks up merging, applies to first unmerged cell only
https://bugs.documentfoundation.org/show_bug.cgi?id=153899 Heiko Tietze changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #5 from Heiko Tietze --- Many duplicates all combined at bug 89951. Consider cell A having a format different from cell B, but both set to something. *** This bug has been marked as a duplicate of bug 89951 *** -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153899] Clone format of unmerged cells breaks up merging, applies to first unmerged cell only
https://bugs.documentfoundation.org/show_bug.cgi?id=153899 Eyal Rozenberg changed: What|Removed |Added Summary|Clone format does not work |Clone format of unmerged |with joined cells |cells breaks up merging, ||applies to first unmerged ||cell only -- You are receiving this mail because: You are the assignee for the bug.
