From bugzilla-daemon at bugs.documentfoundation.org Mon Jun 2 08:35:11 2025 From: bugzilla-daemon at bugs.documentfoundation.org (bugzilla-daemon at bugs.documentfoundation.org) Date: Mon, 02 Jun 2025 08:35:11 +0000 Subject: [Bug 166714] Make uno:SetOptimalColumnWidthDirect (shift+alt+left/right) consider the whole column In-Reply-To: References: Message-ID: https://bugs.documentfoundation.org/show_bug.cgi?id=166714 Heiko Tietze changed: What |Removed |Added ---------------------------------------------------------------------------- Hardware|x86-64 (AMD64) |All Summary|SHIFT + ALT + LEFT|RIGHT |Make |KEY |uno:SetOptimalColumnWidthDi | |rect (shift+alt+left/right) | |consider the whole column OS|Linux (All) |All CC| |erack at redhat.com, | |libreoffice-ux-advise at lists | |.freedesktop.org Status|NEW |NEEDINFO --- Comment #3 from Heiko Tietze --- I think this is at least worth a discussion. STR: A1 = "Lorem ipsum dolor", A2 = "Lorem ipsum dolor est" -> running the function on A1 increases the column to the with of the first string, running it on the A2 to this string. If you select A1:A2 starting from A1 it still considers the length of A1. While the function works on the current cell it might iterate through all cells and works on the whole column. But maybe it is a bug (in the documentation as well) since the fucntion SetMarkedWidthOrHeight() calls MarkToMulti(). And double click on the header calls the same function from SetEntrySize(). Eike, could you please add your wisdom. To be considered, what should happen if multiple columns are selected? If the function works not per cell but column doesn't it mean to respond to selections? Ultimately I tend to disagree with the enhancement request, if it's not a bug, and keep the function simple. Double-click on the column header works as expected. -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-daemon at bugs.documentfoundation.org Mon Jun 2 08:35:39 2025 From: bugzilla-daemon at bugs.documentfoundation.org (bugzilla-daemon at bugs.documentfoundation.org) Date: Mon, 02 Jun 2025 08:35:39 +0000 Subject: [Bug 162767] LABELS DIALOG: Allow selection of number of labels and position with label sheets In-Reply-To: References: Message-ID: https://bugs.documentfoundation.org/show_bug.cgi?id=162767 Heiko Tietze changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEEDINFO -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-daemon at bugs.documentfoundation.org Mon Jun 2 21:20:36 2025 From: bugzilla-daemon at bugs.documentfoundation.org (bugzilla-daemon at bugs.documentfoundation.org) Date: Mon, 02 Jun 2025 21:20:36 +0000 Subject: [Bug 166835] Warn when first introducing an opened-file-format-incompatible aspect into a document In-Reply-To: References: Message-ID: https://bugs.documentfoundation.org/show_bug.cgi?id=166835 Eyal Rozenberg changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |needsUXEval -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-daemon at bugs.documentfoundation.org Mon Jun 2 21:20:32 2025 From: bugzilla-daemon at bugs.documentfoundation.org (bugzilla-daemon at bugs.documentfoundation.org) Date: Mon, 02 Jun 2025 21:20:32 +0000 Subject: [Bug 166835] Warn when first introducing an opened-file-format-incompatible aspect into a document In-Reply-To: References: Message-ID: https://bugs.documentfoundation.org/show_bug.cgi?id=166835 Eyal Rozenberg changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |libreoffice-ux-advise at lists | |.freedesktop.org, | |telesto at surfxs.nl -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-daemon at bugs.documentfoundation.org Mon Jun 2 21:22:04 2025 From: bugzilla-daemon at bugs.documentfoundation.org (bugzilla-daemon at bugs.documentfoundation.org) Date: Mon, 02 Jun 2025 21:22:04 +0000 Subject: [Bug 166834] Show tracked-change comment on hover In-Reply-To: References: Message-ID: https://bugs.documentfoundation.org/show_bug.cgi?id=166834 Eyal Rozenberg changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |libreoffice-ux-advise at lists | |.freedesktop.org Keywords| |needsUXEval -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-daemon at bugs.documentfoundation.org Tue Jun 3 02:33:13 2025 From: bugzilla-daemon at bugs.documentfoundation.org (bugzilla-daemon at bugs.documentfoundation.org) Date: Tue, 03 Jun 2025 02:33:13 +0000 Subject: [Bug 166835] Warn when first introducing an opened-file-format-incompatible aspect into a document In-Reply-To: References: Message-ID: https://bugs.documentfoundation.org/show_bug.cgi?id=166835 --- Comment #1 from Telesto --- (In reply to Eyal Rozenberg from comment #0) > For that reason I suggest that, when editing a file in a given format, and > when we first introduce something into the document unsupported by the > format, we could alert the user to this through: > > * An info-bar > * A pop-up dialog > * Some kind of visual indication in the status bar > > this alert could ask the user "do you really want to do XYZ?" Or it could > just tell them that the last change breaks the file format. Pointing out differences by individual warnings is as good as pointless. At least for Writer. The document-model of LibreOffice being inherently different. There are so many area's common cases where 'conversions occur' From image an anchor conversion, styles, highlighting A nice example: bug 125268. It's including a bunch of comments of handling the compatibility matter.. Importing a file generated by MSO in LibO and saving it back to DOCX without any change does already create quite a lot of differences. -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-daemon at bugs.documentfoundation.org Tue Jun 3 07:30:52 2025 From: bugzilla-daemon at bugs.documentfoundation.org (bugzilla-daemon at bugs.documentfoundation.org) Date: Tue, 03 Jun 2025 07:30:52 +0000 Subject: [Bug 166835] Warn when first introducing an opened-file-format-incompatible aspect into a document In-Reply-To: References: Message-ID: https://bugs.documentfoundation.org/show_bug.cgi?id=166835 --- Comment #2 from Heiko Tietze --- We pondered over this in the ESC considering the warning on save. Would be nice to learn what exactly is not compatible. But it requires every single aspect to be listed somehow in a table, hard to imagine. Your proposal goes even further. You assume users load _and save_ alien formats thinking only of Microsoft's proprietary file types. But how about reading a simple text file in order to store as ODF? Or to improve an alien document and eventually saving as ODF? Or CSV => ODS, MD => ODP, etc. Sound to me like a hHuge effort with limited benefit, obviously over-engineering. -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-daemon at bugs.documentfoundation.org Tue Jun 3 07:34:09 2025 From: bugzilla-daemon at bugs.documentfoundation.org (bugzilla-daemon at bugs.documentfoundation.org) Date: Tue, 03 Jun 2025 07:34:09 +0000 Subject: [Bug 166834] Show tracked-change comment on hover In-Reply-To: References: Message-ID: https://bugs.documentfoundation.org/show_bug.cgi?id=166834 Heiko Tietze changed: What |Removed |Added ---------------------------------------------------------------------------- CC|heiko.tietze at documentfounda |rafael.palma.lima at gmail.com |tion.org | --- Comment #7 from Heiko Tietze --- Not against but the cut-off comments are likely not sufficient informative. -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-daemon at bugs.documentfoundation.org Tue Jun 3 20:47:02 2025 From: bugzilla-daemon at bugs.documentfoundation.org (bugzilla-daemon at bugs.documentfoundation.org) Date: Tue, 03 Jun 2025 20:47:02 +0000 Subject: [Bug 166835] Warn when first introducing an opened-file-format-incompatible aspect into a document In-Reply-To: References: Message-ID: https://bugs.documentfoundation.org/show_bug.cgi?id=166835 --- Comment #3 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #2) > We pondered over this in the ESC considering the warning on save. Would be > nice to learn what exactly is not compatible. But it requires every single > aspect to be listed somehow in a table, hard to imagine. ... which is exactly why I would not suggest that. > Your proposal goes even further. But it's not going in the same direction :-( > You assume users load _and save_ alien > formats thinking only of Microsoft's proprietary file types. But how about > reading a simple text file in order to store as ODF? Or to improve an alien > document and eventually saving as ODF? Or CSV => ODS, MD => ODP, etc. The question of what format will eventually be saved is something I suggest explicitly not caring about here. The reference is just the original format. So, for example, if you open a CSV and, say, change the font size or text color, - you would get notified that you won't be able to save those changes in the open file's original format. Yes, you might intend to save it as an ODS, but LO doesn't know about that while you're only editing and have not saved-as. Once you _have_ saved as - this is a non-issue. So, if you first save as ODS, then change the font size - no warning. Same for MD => ODP or any other change. So, what's the big benefit here? If we have a warning-on-save anyway? It's the fact, for at least one change - the first format-breaking change, the user will be _fully_ aware of what they're doing and what they're risking. Yes, it might not be the most critical change that might be lost, but we would not need to keep track of different kinds of changes, nor will the user need to rummage through their memory and decide what's important. The first format-breaking change is the _best_ time to warn the user, and when they are the least invested in format-breaking change and will be the least frustrated. -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-daemon at bugs.documentfoundation.org Tue Jun 3 21:25:55 2025 From: bugzilla-daemon at bugs.documentfoundation.org (bugzilla-daemon at bugs.documentfoundation.org) Date: Tue, 03 Jun 2025 21:25:55 +0000 Subject: [Bug 166835] Warn when first introducing an opened-file-format-incompatible aspect into a document In-Reply-To: References: Message-ID: https://bugs.documentfoundation.org/show_bug.cgi?id=166835 --- Comment #4 from jan d --- I would stick with warn-on-save. Aside of effort of implmentation, wanr-on-incompatible-change seems to introduce a lot of open questions like how "incompatible change" is defined, when we assume "editing" (with intent to change the file in place) and when we assume "import" (with intent do store in another format). (an alternative pattern to warn-on-save is what some image editors do ? differentiate between "save" (native format) and "export" (andthing else)) -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-daemon at bugs.documentfoundation.org Tue Jun 3 22:06:56 2025 From: bugzilla-daemon at bugs.documentfoundation.org (bugzilla-daemon at bugs.documentfoundation.org) Date: Tue, 03 Jun 2025 22:06:56 +0000 Subject: [Bug 166835] Warn when first introducing an opened-file-format-incompatible aspect into a document In-Reply-To: References: Message-ID: https://bugs.documentfoundation.org/show_bug.cgi?id=166835 --- Comment #5 from Telesto --- (In reply to Eyal Rozenberg from comment #3) > It's the fact, for at least one change - the first format-breaking change, > the user will be _fully_ aware of what they're doing and what they're > risking. Yes, it might not be the most critical change that might be lost, > but we would not need to keep track of different kinds of changes, nor will > the user need to rummage through their memory and decide what's important. > The first format-breaking change is the _best_ time to warn the user, and > when they are the least invested in format-breaking change and will be the > least frustrated. This would be the solution in the ideal world. However there is not even a list of format-breaking changes. And in case of Writer it's likely so common, that's rather absurd to do this on case basis. At least if you take full compatibility as the norm. There is so much emulation going on. So you might get file which looks the same, but acts differently compared to native generated one. Say a single style in Writer, becoming split 20 (paragraph) styles on docx export. Looks fine, but less useable. Defying the point main for using (paragraph) styles. Other alternatives * Info bar appearing when you start editing a foreign format, some general warning about non-standard file format * Foreign formats opening in read-only. Forcing/proposing to save as native format before editing. Related: Being able to (directly save (as) foreign format XYZ suggest (full) compatibility. Save as should be limited to fully supported formats. Else it would be better to put it under export. Technically speaking; not sure if this being feasible from real world perspective -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-daemon at bugs.documentfoundation.org Tue Jun 3 22:10:57 2025 From: bugzilla-daemon at bugs.documentfoundation.org (bugzilla-daemon at bugs.documentfoundation.org) Date: Tue, 03 Jun 2025 22:10:57 +0000 Subject: [Bug 166835] Warn when first introducing an opened-file-format-incompatible aspect into a document In-Reply-To: References: Message-ID: https://bugs.documentfoundation.org/show_bug.cgi?id=166835 --- Comment #6 from John Mills --- I broadly agree with the statement/request that Eyal is making, if part of your reason for using a particular file format is to ensure that any changes made to the document be compatible with the original used file format then an info bar like message could be helpful. I understand the logic of this request, as an example, if I have spent an hour working on something and then my changes made are "useless" because I will need to switch to another format that I did not intend to use. I would propose an info bar like message to explain this to the end user, if the users then does not want these further dialogs displayed in the then provide an option to dismiss them permanently. -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-daemon at bugs.documentfoundation.org Wed Jun 4 00:16:58 2025 From: bugzilla-daemon at bugs.documentfoundation.org (bugzilla-daemon at bugs.documentfoundation.org) Date: Wed, 04 Jun 2025 00:16:58 +0000 Subject: [Bug 166835] Warn when first introducing an opened-file-format-incompatible aspect into a document In-Reply-To: References: Message-ID: https://bugs.documentfoundation.org/show_bug.cgi?id=166835 --- Comment #7 from Harry --- A default pop-up warning at start up, or during the edit, would be a good thing before investing time with edits only to find out at SAVE TIME that the end result would be undesirable. -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-daemon at bugs.documentfoundation.org Wed Jun 4 08:25:48 2025 From: bugzilla-daemon at bugs.documentfoundation.org (bugzilla-daemon at bugs.documentfoundation.org) Date: Wed, 04 Jun 2025 08:25:48 +0000 Subject: [Bug 166835] Warn when first introducing an opened-file-format-incompatible aspect into a document In-Reply-To: References: Message-ID: https://bugs.documentfoundation.org/show_bug.cgi?id=166835 --- Comment #8 from Heiko Tietze --- (In reply to Eyal Rozenberg from comment #3) > It's the fact, for at least one change - the first format-breaking change, > the user will be _fully_ aware of what they're doing... Another example: You can direct format text as bold or via character style, both are saved as to HTML (and I would argue this is always DF). IOW, you have a technical perspective on data and a user POV, depending on expertise and workflow. If you warn the first time about "styles are not stored with HTML" users might not care but if it comes to another incompatibility they will for sure. So you have to do it for every single attribute. Same argument in comment 5. I doubt the use case of Benjamin loading an "extra format", something that is not primarily suited for text processors or spreadsheet apps like html, rtf, csv etc., expecting a different function set works the same way. Expert users probably not invest "hours of working" ending up in being surprised on save. When it comes to "similar formats" like odf - docx, we should rather aim for 100% compatibility - and still get into situations where the proprietary format has its limitation. More generally: Why do we always care about other applications? We should proudly present our work and only secondarily consider other tools. User running LibreOffice are supposed to work with ODF - period. -- You are receiving this mail because: You are on the CC list for the bug. From bugzilla-daemon at bugs.documentfoundation.org Wed Jun 4 09:59:11 2025 From: bugzilla-daemon at bugs.documentfoundation.org (bugzilla-daemon at bugs.documentfoundation.org) Date: Wed, 04 Jun 2025 09:59:11 +0000 Subject: [Bug 166835] Warn when first introducing an opened-file-format-incompatible aspect into a document In-Reply-To: References: Message-ID: https://bugs.documentfoundation.org/show_bug.cgi?id=166835 --- Comment #9 from Telesto --- (In reply to Heiko Tietze from comment #8) > More generally: Why do we always care about other applications? We should > proudly present our work and only secondarily consider other tools. User > running LibreOffice are supposed to work with ODF - period. I fully support this in principle. Would give more freedom, instead of constant compromising functions and such on foreign formats. And well file formats become probably less of an issue with cloud solutions. A bold move would be that instead the naging non-standard file format dialog forcing to save into native format. With some setting in the options dialog "Load and Save" to overrule this setting. This would prevent irreversibel dataloss because of file-format differences However this still doesn't fix the case of newbie opening/editing using foreign format and expecting to be able to (a) save it back into that format (b) with 100% compatibility -- You are receiving this mail because: You are on the CC list for the bug.