Bug 62595 - Make Edits to Charts Undoable outside of edit mode (or merge with main undo/redo stack)
Summary: Make Edits to Charts Undoable outside of edit mode (or merge with main undo/r...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Chart (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 90648 105958 123376 138763 142434 158415 (view as bug list)
Depends on:
Blocks: 82535 Undo-Redo
  Show dependency treegraph
 
Reported: 2013-03-21 15:17 UTC by Clemens Eisserer
Modified: 2024-06-12 06:45 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Clemens Eisserer 2013-03-21 15:17:26 UTC
The insertion of error bars is not recorded as an edit-event in the history.
When pressing Ctrl+Z to undo the most recent edit operation, the error bars stay in place. Instead the edit operation which was performed before the error bars were inserted is reversed.
Comment 1 Joel Madero 2013-04-17 18:57:35 UTC
This issue is a wider problem than just with error bars, apparently any edits to the chart are not reversible. For instance go into the chart and move the title around, then click out and do ctrl + z, it will not work. 

Changing title, and marking:

New (confirmed)
Enhancement - this isn't a bug per say, it's just never been implemented but it is probably expected to work.

Highest - would benefit anyone using charts, being able to undo changes to charts is very important. I would suspect there are multiple bugs that are basically asking for the same thing and would be solved if this was implemented.


Adding:

Kohei - I know you're overwhelmed but do you have code pointers for this and anyone in mind that might be able to get this done?
Comment 2 Kohei Yoshida 2013-04-17 19:24:03 UTC
This is one of the hardest ones even for veteran core developers, and no pointers since I don't even have enough clue to advise others.
Comment 3 Kohei Yoshida 2013-04-17 20:09:44 UTC
The only thing I know is that SfxUndoManager is the shared undo manager for all apps, but each app maintain its own undo redo stack.  The chart and calc apps are technically separate "apps" hence calc has no access to chart's undo stack and vise versa.

To fix this, we need to re-architect the current undo mechanism to allow nested undo stacks across multiple apps.  And that's a big task.
Comment 4 Dan Dascalescu 2013-07-01 02:38:00 UTC
At least make the very fact of inserting a chart undoable?

I.e. Insert -> Chart
Ctrl+Z should delete the chart
Comment 5 Joel Madero 2013-07-01 02:46:19 UTC
This is already possible, must click off of the OLE object (chart) and then do ctrl + z, I just did a test and it "deleted" (ie. undid)
Comment 6 Björn Michaelsen 2014-01-17 00:43:53 UTC Comment hidden (obsolete)
Comment 7 szotsaki 2015-12-20 11:43:23 UTC
This is still valid in version 5.0.2.4. It's also not possible to undo a chart resize.
Comment 8 Joel Madero 2015-12-20 16:02:31 UTC
(In reply to szotsaki from comment #7)
> This is still valid in version 5.0.2.4. It's also not possible to undo a
> chart resize.

Yes it's likely to be valid for some years to come. Kohei is one of our most experienced experts with Calc and he said it would be quite a chore to implement this. It would take a very knowledgeable developer quite a bit of time to do. Unlikely to happen any time soon.
Comment 9 Jean-Baptiste Faure 2017-02-12 15:52:25 UTC
*** Bug 105958 has been marked as a duplicate of this bug. ***
Comment 10 Gavin D 2017-02-21 21:57:02 UTC
If the Chart and Calc apps are technically individual programs, why not allow direct access to the Chart app, where users may create their charts, taking data from other apps like Calc, while running its own undo/redo stack? In much the same as a one may create a drawing in Draw, and import it into Writer, it would be great to create a graph in Chart, and import it into Calc. This would eradicate the need for nested undo stacks.
Comment 11 Yousuf Philips (jay) (retired) 2017-05-10 12:51:26 UTC
*** Bug 90648 has been marked as a duplicate of this bug. ***
Comment 12 hoffman9417calvin@gmx.com 2019-11-20 05:13:19 UTC Comment hidden (spam)
Comment 13 Xisco Faulí 2019-11-29 13:28:46 UTC
Changing priority back to 'medium' since the number of duplicates is lower than 5
Comment 14 m_a_riosv 2020-10-11 12:18:09 UTC
*** Bug 123376 has been marked as a duplicate of this bug. ***
Comment 15 Stéphane Guillou (stragu) 2023-09-12 23:22:26 UTC
Same in OOo 3.3, so inherited.
Comment 16 Stéphane Guillou (stragu) 2023-09-12 23:26:33 UTC
*** Bug 142434 has been marked as a duplicate of this bug. ***
Comment 17 Stéphane Guillou (stragu) 2023-09-12 23:53:51 UTC
*** Bug 138763 has been marked as a duplicate of this bug. ***
Comment 18 m_a_riosv 2023-11-28 10:53:59 UTC
*** Bug 158415 has been marked as a duplicate of this bug. ***
Comment 19 David García 2023-11-28 11:12:13 UTC
Hi,

Bug number 158415, which has just been marked as a duplicate, is mine. Sometimes it's hard to find a duplicate, especially when English isn't your first language.

In any case, this still happens in LibreOffice 7.6.3.2. It's a bit frustrating that, if you make some changes to your chart and you leave the edit mode, you're stuck with these changes in case you have second thoughts. So far, the only thing you can do is close the document without saving anything, but then you can lose something else apart from your changes to your chat.

The previous message on this thread dates back to 2017. I wonder if something has been planned to fix it.

Thanks!
Comment 20 Clemens Eisserer 2023-11-28 11:15:18 UTC
@David: being an open-source project I guess the main issues here are available developer time and finding someone interrested in fixing a "bug" which is most likely a ton of work to get right but barely visible to the outside...
Comment 21 Clemens Eisserer 2023-11-28 11:16:40 UTC
@ Xisco Faulí: this report now has 6 duplicates, could be change back to "high"?
Comment 22 David García 2023-11-28 11:51:02 UTC
(In reply to Clemens Eisserer from comment #20)
> @David: being an open-source project I guess the main issues here are
> available developer time and finding someone interrested in fixing a "bug"
> which is most likely a ton of work to get right but barely visible to the
> outside...

I understand, and I do appreciate the developers' hard work.