hi all
there has been many good ideas about usability features, so here come my most beloved ones:
multiple undo be a great improvement.
would that be difficult?
eni
On Sat, 31 Jan 2009, Enrique Erne wrote:
there has been many good ideas about usability features, so here come my most beloved ones: multiple undo be a great improvement. would that be difficult?
When I originally harassed Miller so that he implements undo, I thought he'd go for multiple undo. Instead, he went for single. Basically there's not much more you have to do to get multiple undo if the single undo was done "right", but that means "if the single undo has been implemented with a future multiple undo in mind". The undo-system is one of the rare parts of pd source-code that I haven't read, because I wanted to reimplement it from scratch anyway. So I can't really tell you right away whether Miller's system could be adapted or not.
My own multiple-undo code doesn't really work well, but that's not because it's multiple, it's because it's implemented in the client instead, and there were too many things that had to be changed in the server to get that working, and I have other excuses as well ;)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
I know that the Ableton programmers have joked about the challenges of designing their endless undo system. I am guessing that it relies upon keeping track of every change between state saves, since they also have a nifty feature that will rescue unsaved changes if the system crashes for some reason. This is stored in a temporary file location specified in the preferences menu of the program.
So basically the multiple undo system would have to keep a running log in some temporary file, documenting each state change in the software. Beyond me, but I agree that this feature is much-desired!
~Kyle
On Sat, Jan 31, 2009 at 10:04 AM, Mathieu Bouchard matju@artengine.cawrote:
On Sat, 31 Jan 2009, Enrique Erne wrote:
there has been many good ideas about usability features, so here come my
most beloved ones: multiple undo be a great improvement. would that be difficult?
When I originally harassed Miller so that he implements undo, I thought he'd go for multiple undo. Instead, he went for single. Basically there's not much more you have to do to get multiple undo if the single undo was done "right", but that means "if the single undo has been implemented with a future multiple undo in mind". The undo-system is one of the rare parts of pd source-code that I haven't read, because I wanted to reimplement it from scratch anyway. So I can't really tell you right away whether Miller's system could be adapted or not.
My own multiple-undo code doesn't really work well, but that's not because it's multiple, it's because it's implemented in the client instead, and there were too many things that had to be changed in the server to get that working, and I have other excuses as well ;)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sat, 31 Jan 2009, Kyle Klipowicz wrote:
So basically the multiple undo system would have to keep a running log in some temporary file, documenting each state change in the software. Beyond me, but I agree that this feature is much-desired!
Plain multiple undo does not imply that it gets saved. In DesireData, the multiple undo is not saved, but if the server crashes, then it would be possible to restart the server while not restarting the client, and thus restart the server using the same unsaved patches and preserve the undo-stack as well. It's not implemented but it's not far from being able to do it.
It would be also possible to save the undo-stack in a file, be it separately or within the .pd file itself.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
One thing I like about Emacs a lot is that it remembers the undo/redo
states across saves. I think that saving should not wipe out the undo
possibilities. Didn't Photoshop go back to single undo? I think they
replaced multiple undo with a sort of editable history log. I think
that would be even better than multiple undo.
.hc
On Jan 31, 2009, at 11:57 AM, Kyle Klipowicz wrote:
I know that the Ableton programmers have joked about the challenges
of designing their endless undo system. I am guessing that it relies
upon keeping track of every change between state saves, since they
also have a nifty feature that will rescue unsaved changes if the
system crashes for some reason. This is stored in a temporary file
location specified in the preferences menu of the program.So basically the multiple undo system would have to keep a running
log in some temporary file, documenting each state change in the
software. Beyond me, but I agree that this feature is much-desired!~Kyle
On Sat, Jan 31, 2009 at 10:04 AM, Mathieu Bouchard
matju@artengine.ca wrote: On Sat, 31 Jan 2009, Enrique Erne wrote:there has been many good ideas about usability features, so here
come my most beloved ones: multiple undo be a great improvement.
would that be difficult?When I originally harassed Miller so that he implements undo, I
thought he'd go for multiple undo. Instead, he went for single.
Basically there's not much more you have to do to get multiple undo
if the single undo was done "right", but that means "if the single
undo has been implemented with a future multiple undo in mind". The
undo-system is one of the rare parts of pd source-code that I
haven't read, because I wanted to reimplement it from scratch
anyway. So I can't really tell you right away whether Miller's
system could be adapted or not.My own multiple-undo code doesn't really work well, but that's not
because it's multiple, it's because it's implemented in the client
instead, and there were too many things that had to be changed in
the server to get that working, and I have other excuses as well ;)_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
Yeah that would be nice to have a little history inspector in Pd that would label each task by name and allow you to click to it directly rather than cycling through.
~Kyle
On Sat, Jan 31, 2009 at 11:01 PM, Hans-Christoph Steiner hans@eds.orgwrote:
One thing I like about Emacs a lot is that it remembers the undo/redo states across saves. I think that saving should not wipe out the undo possibilities. Didn't Photoshop go back to single undo? I think they replaced multiple undo with a sort of editable history log. I think that would be even better than multiple undo.
.hc
On Jan 31, 2009, at 11:57 AM, Kyle Klipowicz wrote:
I know that the Ableton programmers have joked about the challenges of designing their endless undo system. I am guessing that it relies upon keeping track of every change between state saves, since they also have a nifty feature that will rescue unsaved changes if the system crashes for some reason. This is stored in a temporary file location specified in the preferences menu of the program.
So basically the multiple undo system would have to keep a running log in some temporary file, documenting each state change in the software. Beyond me, but I agree that this feature is much-desired!
~Kyle
On Sat, Jan 31, 2009 at 10:04 AM, Mathieu Bouchard matju@artengine.cawrote:
On Sat, 31 Jan 2009, Enrique Erne wrote:
there has been many good ideas about usability features, so here come my
most beloved ones: multiple undo be a great improvement. would that be difficult?
When I originally harassed Miller so that he implements undo, I thought he'd go for multiple undo. Instead, he went for single. Basically there's not much more you have to do to get multiple undo if the single undo was done "right", but that means "if the single undo has been implemented with a future multiple undo in mind". The undo-system is one of the rare parts of pd source-code that I haven't read, because I wanted to reimplement it from scratch anyway. So I can't really tell you right away whether Miller's system could be adapted or not.
My own multiple-undo code doesn't really work well, but that's not because it's multiple, it's because it's implemented in the client instead, and there were too many things that had to be changed in the server to get that working, and I have other excuses as well ;)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore