> > Yes, it might be a useful thing and I might use it once or twice a > > year, but I can see that to do it properly it would have to be built > > into every operation and that is a massive task and something that > > affects the whole of the gui codebase I presume - possibly even the > > other backend components (if, in between deleting and undoing, > > another > > client expunges, then that needs to be handled and involves the > > backends). > > > > I don't think it's as easy as some of the bug comments seem to think. > > That's disappointing, but understandable. Do you think the difficulty > of implementing this is unique to Evolution's design, or is it just the > way things are in general? I only ask because of the prevalence of this > feature in other email clients I've used. > I suspect it's something that is "trivial" if it's designed into the application from the beginning, but distinctly non-trivial to bolt on afterwards. What I mean is that if it's something that is an intrinsic part of the application, then whenever a new function is implemented, some thought is put into the do-undo-redo process, and the way a function is coded may well be determined by the undo requirements. However, to retrofit it, that process has to be gone through for everything - someone has to go through and analyse the code for every function and action and work out how to do the undo, and it's not unimaginable that a whole action will have to be re-coded just to accommodate the requirements of the undo.
P. _______________________________________________ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
