Re: revamping the undo infrastructure in Dia
- From: "Sameer Sahasrabuddhe" <sameerds gmail com>
- To: "discussions about usage and development of dia" <dia-list gnome org>
- Subject: Re: revamping the undo infrastructure in Dia
- Date: Sat, 20 Oct 2007 11:44:12 +0530
On 10/20/07, Lars Clausen <lars raeder dk> wrote:
1) The _Change struct in app/undo.h should have a facility to track
side-effects. For example, when changing a text-object results in a
resizing of the object, the resize should be recorded as a side-effect
of the main text-related Change.
Sounds necessary, given that many different objects use the same text
change object. Alternatively, they could come as a chain of changes,
since the prev/next links are right there.
Dunno what you mean by prev/next links ... but I suppose I'll see that
when I take a better look at things related to undo and text objects.
Also there is a hidden problem with the way the properties dialog
tracks undo history. It records the previous state of _all_ known
properties, whether or not they are changed. This can lead to
scalability problems if we dare to think of huge groups of objects
with a huge list of properties.
That could take a fair amount of space, yes. We haven't seen it as a
problem I think mostly because mass change of properties has had the
problems of actually unifying all properties, and only now that you've
done the group properties update fixing are people likely to try
changing a large number of objects at the same time.
I suppose you are hinting at this bug:
http://bugzilla.gnome.org/show_bug.cgi?id=481979
Shape property dialog needs reordering
This also becomes important, especially with support for properties of
grouped objects. There are lots of smaller bugs related to the
property dialog, which can have visible effect on the user experience.
I already posted a patch on one, about the dialog popping up when you
undo something.
Also, this cannot handle side-effects
to the object that do not involve properties. For example, changing
the font of a text object changes its size, but this is not tracked by
undo.
Any changeable aspect of an object should be derivable from its
properties, otherwise it doesn't survive saving.
I don't understand what you mean here. For example, I create a a
flowchart object and save the file. Then I change the font size for
the text in it and then save it again. What will not survive saving in
this case? Also, I might choose to expand the object manually, which
means this property of the object is not strictly derivable from the
text content.
This can only be fixed if the Undo/Redo infrastructure guarantees that
side-effects are efficiently handled elsewhere. But the improvements
required for Undo are quite extensive, and would require lots of
planning as well as sufficient blessings from the gods of Dia.
I bless the change as such, but I'm not sure it'd be a good idea to
start on it now. We have three major improvements in that should get
out to people, adding this would delay it yet further. Time has already
flown much faster on getting things fixed than I was hoping for.
Yeah, I agree that we can't just start doing this right away. My
posting is just an initial RFC to attract attention. I intend to just
chip away on this problem in my spare time, with git-svn to help
separately maintain my changes in a sane manner. I could keep that git
repository publicly available with the hope that some kindred soul out
there might decide to take a look and contribute. There could even be
an SVN branch for "redoing undo", but I believe that's an unnecessary
hassle for the maintainers.
In the mean time, I would like to help with the current release, since
my work on the group properties is as good as done now. Extending this
work in terms of "selected objects" is in itself a big task, not
considering the possibility of introducing "open groups". I don't mind
working on whatever the maintainers think is desirable at this stage.
So far I have been hopping all over the Dia code, hoping to find a fix
for whatever bugs me the most.
Also, a question about future plans, just out of curiosity ... is
there a vision in place about 1.0, vague or detailed as it may be?
There are loads and loads of small bugs and enhancement requests that
can have a great impact on the user experience. Is there any plan to
schedule a release that focuses only on this?
Sameer.
--
Research Scholar, Department of CSE, IIT Bombay
http://www.it.iitb.ac.in/~sameerds/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]