After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 482490 - Undo & redo menu labels need detail I.e. "Undo move", "Undo delete"
Undo & redo menu labels need detail I.e. "Undo move", "Undo delete"
Status: RESOLVED OBSOLETE
Product: dia
Classification: Other
Component: general
0.96.1
Other All
: Normal enhancement
: ---
Assigned To: Dia maintainers
Dia maintainers
Depends on:
Blocks:
 
 
Reported: 2007-10-02 08:05 UTC by Brian Remedios
Modified: 2019-03-20 11:35 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
introduces a TransactionPoint struct that can hold tooltips for undo/redo (13.40 KB, patch)
2008-11-29 18:45 UTC, Sameer D. Sahasrabuddhe
none Details | Review
a regression due to the previous patch (9.82 KB, patch)
2008-11-29 19:00 UTC, Sameer D. Sahasrabuddhe
needs-work Details | Review

Description Brian Remedios 2007-10-02 08:05:25 UTC
The undo & redo menu options in the Edit menu could be more helpful if they provided more detail as to what they would do when invoked. I think this should be fairly simple to expand the change structures to include the additional labels.

Other information:
Comment 1 Hans Breuer 2007-10-02 22:08:41 UTC
feel free to provide a working patch ;)
Comment 2 Lars Clausen 2007-10-28 07:14:36 UTC
Not entirely trivial, actually.  Each kind of undo would have to provide appropriate (i18n'ed) labels, which requires adding a field to the Change struct -- thus breaking binary compatibility with objects having their own changes.  This probably should be done before 1.0 anyway, doing something akin to the objects ops  struct, which would also save us two pointer's worth of memory per undo item at the cost of one extra indirection.  I don't feel that this bug is cause enough for breaking ABI, but if other reasons start accumulate, we certainly should bite.
Comment 3 Sameer D. Sahasrabuddhe 2008-11-29 18:45:47 UTC
Created attachment 123654 [details] [review]
introduces a TransactionPoint struct that can hold tooltips for undo/redo


The problem with this bug is that there is no place to store the undo/redo tooltips, because transaction points are just dumb little Change objects. Instead I have introduced a struct called TransactionPoint and redefined UndoStack as a stack of these structs. This makes place for the tooltips while also cleaning up the concept of a transaction point.
Comment 4 Sameer D. Sahasrabuddhe 2008-11-29 19:00:21 UTC
Created attachment 123655 [details] [review]
a regression due to the previous patch

Posting this patch here although it is not directly related to this bug. The problem is that undo_is_saved() compares the top of the stack with the last saved transaction point. In most places in the current code, diagram_modified() is called before the current transaction is pushed on the stack. When it calls undo_is_saved(), FALSE is returned because the top of the stack has not been updated yet. This patch introduces a better way of handling diagram->mollified.

This was not a problem in the earlier code because lots of changes were pushed on the stack even if the transaction point was not pushed. Hence undo_is_saved() always returned TRUE.
Comment 5 Hans Breuer 2009-01-31 20:36:27 UTC
The second patch needs an update to file renaming and to apply without failed hunks

patching file app/commands.c
Hunk #1 succeeded at 205 (offset -2 lines).
Hunk #2 succeeded at 311 (offset -2 lines).
Hunk #3 succeeded at 359 (offset -2 lines).
Hunk #4 succeeded at 401 (offset -2 lines).
Hunk #5 FAILED at 425.
Hunk #6 succeeded at 448 with fuzz 2 (offset -3 lines).
Hunk #7 succeeded at 536 (offset -3 lines).
Hunk #8 succeeded at 581 (offset -3 lines).
Hunk #9 succeeded at 599 (offset -3 lines).
Hunk #10 succeeded at 614 (offset -3 lines).
Hunk #11 succeeded at 1148 (offset -4 lines).
Hunk #12 succeeded at 1194 (offset -4 lines).
1 out of 12 hunks FAILED -- saving rejects to file app/commands.c.rej
patching file app/create_object.c
Hunk #1 succeeded at 197 (offset 8 lines).
patching file app/diagram.c
Hunk #4 succeeded at 1112 (offset 17 lines).
Hunk #5 succeeded at 1142 (offset 17 lines).
Hunk #6 succeeded at 1176 (offset 17 lines).
Hunk #7 succeeded at 1251 (offset 17 lines).
Hunk #8 succeeded at 1295 (offset 17 lines).
Hunk #9 succeeded at 1312 (offset 17 lines).
Hunk #10 succeeded at 1334 (offset 17 lines).
Hunk #11 succeeded at 1355 (offset 17 lines).
Hunk #12 succeeded at 1397 (offset 17 lines).
Hunk #13 succeeded at 1443 (offset 17 lines).
patching file app/disp_callbacks.c
Hunk #1 succeeded at 75 (offset 1 line).
Hunk #2 succeeded at 1044 (offset 78 lines).
patching file app/find-and-replace.c
patching file app/modify_tool.c
can't find file to patch at input line 301
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|
|=== modified file 'app/properties.c'
|--- app/properties.c	2008-07-18 21:00:55 +0000
|+++ app/properties.c	2008-11-29 18:39:51 +0000
--------------------------
File to patch: app/properties-dialog.c
patching file app/properties-dialog.c
Hunk #1 FAILED at 140.
1 out of 1 hunk FAILED -- saving rejects to file app/properties-dialog.c.rej
Comment 6 GNOME Infrastructure Team 2019-03-20 11:35:13 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/dia/issues/217.