GNOME.org
 

Re: revamping the undo infrastructure in Dia


On Sat, 2007-10-20 at 11:44 +0530, Sameer Sahasrabuddhe wrote: 

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.


The changes are chained together in the undo stack already, using
prev/next links in the Change type.  Shouldn't actually require much
change to make it possible to return a chain of Changes always.


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


No, not really.  That bug is about the dialog.  The scalability, I'm
saying, may be a real problem, what I'm saying is that your fixes have
made is more likely to appear, since people may actually try to make
such huge changes now.


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.


Oh, good, that one always annoyed me.  If you have a bug number at hand,
I can find it and apply it.


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.


Ah, so you're not talking about the TextObject, but about any object
with editable text in it.  The size change of an object is the same case
as changing the text, really.


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.


Actually, if you use the built-in chaining, it's more of a clean-up job
than something that needs branching.  Once you make sure that returning
a chain of undo gives the expected effect, you can just go through and
fix objects, which shouldn't cause any seirous disturbance.


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.


The selected objects properties and open groups are not top priority
right now.  Getting the integrated UI finished and the edit mode into a
reasonable shape is all that I see as really required on the new feature
front.  Then there's the bugs...


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?


I made one at <URL:http://faemalia.org/wiki/view/Technical/Dia10>, which
is still mostly valid.  StdPropification depends on the PROP_LIST, which
is awaiting an insight on how to structure the property right.  My hope
is to have one or two more releases with features, then release 1.0
being only bugfixes and fine-tuning.  If that comes true, we will manage
to not have to make version 0.100!

-Lars
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]