On Sat, 2007-10-20 at 11:44 +0530, Sameer Sahasrabuddhe wrote: 
> On 10/20/07, Lars Clausen <[EMAIL PROTECTED]> 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

_______________________________________________
Dia-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/dia-list
FAQ at http://live.gnome.org/Dia/Faq
Main page at http://live.gnome.org/Dia

Reply via email to