From: Doug B. <dou...@gm...> - 2010-08-09 21:11:37
|
Devs, I've just committed some code that allows control+c in any navigation view (all views except html, geo, and gramplet) to copy the currently selected item to the clipboard. For example, on the person view, control+c will open the clipboard and put the current person on it. control+v currently just opens up the clipboard. Please let me know how this works for you, and if it causes any copy/paste operations not to work. (I know control+c does not work on the non-navigation pages listed above... working on that). But it should work in all of the editors (except when on the above pages). It would be great if we can get paste to work. Looking for a way for the gtk widget to be able to handle the control+v. Not sure if a "cut" makes sense... what would it do? Remove the object, but allow for it to be recreated? How important is that to people? Anyone know if gtk supports text editor undo/redo? That would be handy to turn on. -Doug |
From: Benny M. <ben...@gm...> - 2010-08-13 16:05:57
|
2010/8/9 Doug Blank <dou...@gm...> > Devs, > > I've just committed some code that allows control+c in any navigation > view (all views except html, geo, and gramplet) to copy the currently > selected item to the clipboard. For example, on the person view, > control+c will open the clipboard and put the current person on it. > control+v currently just opens up the clipboard. > > Please let me know how this works for you, and if it causes any > copy/paste operations not to work. (I know control+c does not work on > the non-navigation pages listed above... working on that). But it > should work in all of the editors (except when on the above pages). > The orginal idea was to also allow it in the displaytabs, eg on the eventlist of person. We proposed putting a copy button there too and a paste button, but this ideas was not worked out. > It would be great if we can get paste to work. Looking for a way for > the gtk widget to be able to handle the control+v. > An eventbox under the existing elements should be able to grab all keys that are not handled by the existing widgets and do something usefull with it. > > Not sure if a "cut" makes sense... what would it do? Remove the > object, but allow for it to be recreated? How important is that to > people? > Don't think cut makes sense. > > Anyone know if gtk supports text editor undo/redo? That would be handy > to turn on. > I mentioned this when the note editor was done, but unfortunately it is not a switch to just turn on. Benny > > -Doug > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Doug B. <dou...@gm...> - 2010-08-14 19:12:11
|
On Fri, Aug 13, 2010 at 12:05 PM, Benny Malengier <ben...@gm...> wrote: > > > 2010/8/9 Doug Blank <dou...@gm...> >> >> Devs, >> >> I've just committed some code that allows control+c in any navigation >> view (all views except html, geo, and gramplet) to copy the currently >> selected item to the clipboard. For example, on the person view, >> control+c will open the clipboard and put the current person on it. >> control+v currently just opens up the clipboard. >> >> Please let me know how this works for you, and if it causes any >> copy/paste operations not to work. (I know control+c does not work on >> the non-navigation pages listed above... working on that). But it >> should work in all of the editors (except when on the above pages). > > The orginal idea was to also allow it in the displaytabs, eg on the > eventlist of person. We proposed putting a copy button there too and a paste > button, but this ideas was not worked out. Ok, making some progress on this front. Control+c will now copy selected main objects on navigation views, and can be used for text on the other views. The only limitation that I couldn't figure out was how to get them to show on the menu (if I did that, then the accelerator would handle it, rather than the keypress handlers.) Next, I'll take a look at paste into the display tabs. >> >> It would be great if we can get paste to work. Looking for a way for >> the gtk widget to be able to handle the control+v. > > An eventbox under the existing elements should be able to grab all keys that > are not handled by the existing widgets and do something usefull with it. Right. The trick was to get away from the action group... that doesn't seem to be integrated into the gtk keypress handling stack. >> >> Not sure if a "cut" makes sense... what would it do? Remove the >> object, but allow for it to be recreated? How important is that to >> people? > > Don't think cut makes sense. Agreed. Removed. >> >> Anyone know if gtk supports text editor undo/redo? That would be handy >> to turn on. > > I mentioned this when the note editor was done, but unfortunately it is not > a switch to just turn on. Too bad. That is really a needed feature in a system designed to do large amounts of text-based editing. -Doug > Benny >> >> -Doug >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Benny M. <ben...@gm...> - 2010-08-15 11:48:09
|
2010/8/14 Doug Blank <dou...@gm...> > > > >> > >> Anyone know if gtk supports text editor undo/redo? That would be handy > >> to turn on. > > > > I mentioned this when the note editor was done, but unfortunately it is > not > > a switch to just turn on. > > Too bad. That is really a needed feature in a system designed to do > large amounts of text-based editing. > > Yes. Googling brings up this: http://bitbucket.org/tiax/gtk-textbuffer-with-undo/ If time, you should have a look if it is easy to integrate with our code. Main problem is our special handling of italic, links, .... One would have to group those things so as to have them together in the undo buffer. Eg not every character typed should go in the undo buffer, but just the situation of eg every space press. Then pressing space sends data to the undo buffer, and we can undo to the previous space press. Benny > -Doug > > > Benny > >> > >> -Doug > >> > >> > >> > ------------------------------------------------------------------------------ > >> This SF.net email is sponsored by > >> > >> Make an app they can't live without > >> Enter the BlackBerry Developer Challenge > >> http://p.sf.net/sfu/RIM-dev2dev > >> _______________________________________________ > >> Gramps-devel mailing list > >> Gra...@li... > >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > > |
From: Doug B. <dou...@gm...> - 2010-08-15 14:12:20
|
On Sun, Aug 15, 2010 at 7:48 AM, Benny Malengier <ben...@gm...> wrote: > > > 2010/8/14 Doug Blank <dou...@gm...> >> >> >> >> >> >> Anyone know if gtk supports text editor undo/redo? That would be handy >> >> to turn on. >> > >> > I mentioned this when the note editor was done, but unfortunately it is >> > not >> > a switch to just turn on. >> >> Too bad. That is really a needed feature in a system designed to do >> large amounts of text-based editing. >> > > Yes. Googling brings up this: > http://bitbucket.org/tiax/gtk-textbuffer-with-undo/ > > If time, you should have a look if it is easy to integrate with our code. > Main problem is our special handling of italic, links, .... One would have > to group those things so as to have them together in the undo buffer. Eg not > every character typed should go in the undo buffer, but just the situation > of eg every space press. Then pressing space sends data to the undo buffer, > and we can undo to the previous space press. Nice find! I've begun to look at this, and have a basic version working with Gramps. Should be able to have it even deal with markup, I think. Where should we put a LGPL (Lesser GPL) python file, undobuffer.py? It has the LGPL license header in the file, but also should probably have the LICENSE file somewhere in Gramps distribution. Options: 1) put it in a new src/misc/undobuffer/ directory with all necessary LICENSE files, etc. 2) put it in, say, src/gui/widgets/ and put the LICENSE with the GPL license file COPYING -Doug > Benny > >> >> -Doug >> >> > Benny >> >> >> >> -Doug >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> This SF.net email is sponsored by >> >> >> >> Make an app they can't live without >> >> Enter the BlackBerry Developer Challenge >> >> http://p.sf.net/sfu/RIM-dev2dev >> >> _______________________________________________ >> >> Gramps-devel mailing list >> >> Gra...@li... >> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > >> > > > |
From: Benny M. <ben...@gm...> - 2010-08-16 07:59:30
|
2010/8/15 Doug Blank <dou...@gm...> > On Sun, Aug 15, 2010 at 7:48 AM, Benny Malengier > <ben...@gm...> wrote: > > > > > > 2010/8/14 Doug Blank <dou...@gm...> > >> > >> > >> >> > >> >> Anyone know if gtk supports text editor undo/redo? That would be > handy > >> >> to turn on. > >> > > >> > I mentioned this when the note editor was done, but unfortunately it > is > >> > not > >> > a switch to just turn on. > >> > >> Too bad. That is really a needed feature in a system designed to do > >> large amounts of text-based editing. > >> > > > > Yes. Googling brings up this: > > http://bitbucket.org/tiax/gtk-textbuffer-with-undo/ > > > > If time, you should have a look if it is easy to integrate with our code. > > Main problem is our special handling of italic, links, .... One would > have > > to group those things so as to have them together in the undo buffer. Eg > not > > every character typed should go in the undo buffer, but just the > situation > > of eg every space press. Then pressing space sends data to the undo > buffer, > > and we can undo to the previous space press. > > Nice find! I've begun to look at this, and have a basic version > working with Gramps. Should be able to have it even deal with markup, > I think. > > Where should we put a LGPL (Lesser GPL) python file, undobuffer.py? It > has the LGPL license header in the file, but also should probably have > the LICENSE file somewhere in Gramps distribution. Options: > > 1) put it in a new src/misc/undobuffer/ directory with all necessary > LICENSE files, etc. > 2) put it in, say, src/gui/widgets/ and put the LICENSE with the GPL > license file COPYING > This is not needed, you can mix LGPL with GPL and you can relicense LGPL as GPL (http://drupal.org/node/163887). So, just take the file you copy, and change the license to GPL, leaving the copyright. Add a notice that this is copied from .... which is LGPL and that bug fixes should also go upstream to the LGPL project. As a courtesy, mail the author you use his code in Gramps under the GPL. Benny > > -Doug > > > Benny > > > >> > >> -Doug > >> > >> > Benny > >> >> > >> >> -Doug > >> >> > >> >> > >> >> > >> >> > ------------------------------------------------------------------------------ > >> >> This SF.net email is sponsored by > >> >> > >> >> Make an app they can't live without > >> >> Enter the BlackBerry Developer Challenge > >> >> http://p.sf.net/sfu/RIM-dev2dev > >> >> _______________________________________________ > >> >> Gramps-devel mailing list > >> >> Gra...@li... > >> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > >> > > >> > > > > > > |
From: Doug B. <dou...@gm...> - 2010-08-16 11:57:22
|
On Mon, Aug 16, 2010 at 3:59 AM, Benny Malengier <ben...@gm...> wrote: > > > 2010/8/15 Doug Blank <dou...@gm...> >> >> On Sun, Aug 15, 2010 at 7:48 AM, Benny Malengier >> <ben...@gm...> wrote: >> > >> > >> > 2010/8/14 Doug Blank <dou...@gm...> >> >> >> >> >> >> >> >> >> >> Anyone know if gtk supports text editor undo/redo? That would be >> >> >> handy >> >> >> to turn on. >> >> > >> >> > I mentioned this when the note editor was done, but unfortunately it >> >> > is >> >> > not >> >> > a switch to just turn on. >> >> >> >> Too bad. That is really a needed feature in a system designed to do >> >> large amounts of text-based editing. >> >> >> > >> > Yes. Googling brings up this: >> > http://bitbucket.org/tiax/gtk-textbuffer-with-undo/ >> > >> > If time, you should have a look if it is easy to integrate with our >> > code. >> > Main problem is our special handling of italic, links, .... One would >> > have >> > to group those things so as to have them together in the undo buffer. Eg >> > not >> > every character typed should go in the undo buffer, but just the >> > situation >> > of eg every space press. Then pressing space sends data to the undo >> > buffer, >> > and we can undo to the previous space press. >> >> Nice find! I've begun to look at this, and have a basic version >> working with Gramps. Should be able to have it even deal with markup, >> I think. >> >> Where should we put a LGPL (Lesser GPL) python file, undobuffer.py? It >> has the LGPL license header in the file, but also should probably have >> the LICENSE file somewhere in Gramps distribution. Options: >> >> 1) put it in a new src/misc/undobuffer/ directory with all necessary >> LICENSE files, etc. >> 2) put it in, say, src/gui/widgets/ and put the LICENSE with the GPL >> license file COPYING > > This is not needed, you can mix LGPL with GPL and you can relicense LGPL as > GPL (http://drupal.org/node/163887). > So, just take the file you copy, and change the license to GPL, leaving the > copyright. > Add a notice that this is copied from .... which is LGPL and that bug fixes > should also go upstream to the LGPL project. > As a courtesy, mail the author you use his code in Gramps under the GPL. Ah, didn't know that. I've added as src/gui/widgets/undoablebuffer.py. I've added UndoableBuffer as a drop-in replacement for gtk.TextBuffer in the note editor. Control+z is bound to undo, and Control+shift+z is bound to redo. That could be changed to the same keys we use for db undo/redo; need to check on windows/mac to see how that works. Changing of style is not an undoable action, only deletes. Please report any issues or comments. I tried for a while to make it work with StyledText, but couldn't figure it out. If anyone is interested, see the FIXME comments in src/gui/widgets/undoablebuffer.py to remove string conversions. Then make it so that you can buffer.insert() StyledText. Probably other things would have to change --- for example, to use the change merge, but maybe not. If this works well, we can add to other places---everywhere where we use TextBuffer. Maybe even have a gtk.Entry() version, and make other edits undoable. -Doug > Benny >> >> -Doug >> >> > Benny >> > >> >> >> >> -Doug >> >> >> >> > Benny >> >> >> >> >> >> -Doug >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> >> This SF.net email is sponsored by >> >> >> >> >> >> Make an app they can't live without >> >> >> Enter the BlackBerry Developer Challenge >> >> >> http://p.sf.net/sfu/RIM-dev2dev >> >> >> _______________________________________________ >> >> >> Gramps-devel mailing list >> >> >> Gra...@li... >> >> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> > >> >> > >> > >> > > > |
From: Doug B. <dou...@gm...> - 2010-08-16 16:34:10
|
On Mon, Aug 16, 2010 at 7:57 AM, Doug Blank <dou...@gm...> wrote: > On Mon, Aug 16, 2010 at 3:59 AM, Benny Malengier > <ben...@gm...> wrote: >> >> >> 2010/8/15 Doug Blank <dou...@gm...> >>> >>> On Sun, Aug 15, 2010 at 7:48 AM, Benny Malengier >>> <ben...@gm...> wrote: >>> > >>> > >>> > 2010/8/14 Doug Blank <dou...@gm...> >>> >> >>> >> >>> >> >> >>> >> >> Anyone know if gtk supports text editor undo/redo? That would be >>> >> >> handy >>> >> >> to turn on. >>> >> > >>> >> > I mentioned this when the note editor was done, but unfortunately it >>> >> > is >>> >> > not >>> >> > a switch to just turn on. >>> >> >>> >> Too bad. That is really a needed feature in a system designed to do >>> >> large amounts of text-based editing. >>> >> >>> > >>> > Yes. Googling brings up this: >>> > http://bitbucket.org/tiax/gtk-textbuffer-with-undo/ >>> > >>> > If time, you should have a look if it is easy to integrate with our >>> > code. >>> > Main problem is our special handling of italic, links, .... One would >>> > have >>> > to group those things so as to have them together in the undo buffer. Eg >>> > not >>> > every character typed should go in the undo buffer, but just the >>> > situation >>> > of eg every space press. Then pressing space sends data to the undo >>> > buffer, >>> > and we can undo to the previous space press. >>> >>> Nice find! I've begun to look at this, and have a basic version >>> working with Gramps. Should be able to have it even deal with markup, >>> I think. >>> >>> Where should we put a LGPL (Lesser GPL) python file, undobuffer.py? It >>> has the LGPL license header in the file, but also should probably have >>> the LICENSE file somewhere in Gramps distribution. Options: >>> >>> 1) put it in a new src/misc/undobuffer/ directory with all necessary >>> LICENSE files, etc. >>> 2) put it in, say, src/gui/widgets/ and put the LICENSE with the GPL >>> license file COPYING >> >> This is not needed, you can mix LGPL with GPL and you can relicense LGPL as >> GPL (http://drupal.org/node/163887). >> So, just take the file you copy, and change the license to GPL, leaving the >> copyright. >> Add a notice that this is copied from .... which is LGPL and that bug fixes >> should also go upstream to the LGPL project. >> As a courtesy, mail the author you use his code in Gramps under the GPL. > > Ah, didn't know that. I've added as src/gui/widgets/undoablebuffer.py. > > I've added UndoableBuffer as a drop-in replacement for gtk.TextBuffer > in the note editor. Control+z is bound to undo, and Control+shift+z is > bound to redo. That could be changed to the same keys we use for db > undo/redo; need to check on windows/mac to see how that works. > Changing of style is not an undoable action, only deletes. Deletes and inserts are undoable, and a series of inserts/deletes are merged together into a single undoable action. svn up. Alas, if I understood how copy and paste works regularly in gtk.TreeBuffer, I could have probably figured out how to make this work with StyledText. I hope someone can look at that someday. -Doug > Please > report any issues or comments. > > I tried for a while to make it work with StyledText, but couldn't > figure it out. If anyone is interested, see the FIXME comments in > src/gui/widgets/undoablebuffer.py to remove string conversions. Then > make it so that you can buffer.insert() StyledText. Probably other > things would have to change --- for example, to use the change merge, > but maybe not. > > If this works well, we can add to other places---everywhere where we > use TextBuffer. Maybe even have a gtk.Entry() version, and make other > edits undoable. > > -Doug > >> Benny >>> >>> -Doug >>> >>> > Benny >>> > >>> >> >>> >> -Doug >>> >> >>> >> > Benny >>> >> >> >>> >> >> -Doug >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> ------------------------------------------------------------------------------ >>> >> >> This SF.net email is sponsored by >>> >> >> >>> >> >> Make an app they can't live without >>> >> >> Enter the BlackBerry Developer Challenge >>> >> >> http://p.sf.net/sfu/RIM-dev2dev >>> >> >> _______________________________________________ >>> >> >> Gramps-devel mailing list >>> >> >> Gra...@li... >>> >> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >> > >>> >> > >>> > >>> > >> >> > |
From: Benny M. <ben...@gm...> - 2010-08-16 17:25:16
|
2010/8/16 Doug Blank <dou...@gm...> > > > > > I've added UndoableBuffer as a drop-in replacement for gtk.TextBuffer > > in the note editor. Control+z is bound to undo, and Control+shift+z is > > bound to redo. That could be changed to the same keys we use for db > > undo/redo; need to check on windows/mac to see how that works. > > Changing of style is not an undoable action, only deletes. > > Deletes and inserts are undoable, and a series of inserts/deletes are > merged together into a single undoable action. svn up. > > Alas, if I understood how copy and paste works regularly in > gtk.TreeBuffer, I could have probably figured out how to make this > work with StyledText. I hope someone can look at that someday. > > Doug, I can add icons for this, but some bugs are present. I can undo on an existing note and have all text disappear, just open a note and do undo, and text goes away. This is a bug. Text comes back without markup, but that is the limitation you talked about. I also had once a text appear after undo in a color on a note with some colored text. Cannot reproduce however. Benny |
From: Doug B. <dou...@gm...> - 2010-08-16 18:38:57
|
On Mon, Aug 16, 2010 at 1:25 PM, Benny Malengier <ben...@gm...> wrote: > > > 2010/8/16 Doug Blank <dou...@gm...> >> >> > >> > I've added UndoableBuffer as a drop-in replacement for gtk.TextBuffer >> > in the note editor. Control+z is bound to undo, and Control+shift+z is >> > bound to redo. That could be changed to the same keys we use for db >> > undo/redo; need to check on windows/mac to see how that works. >> > Changing of style is not an undoable action, only deletes. >> >> Deletes and inserts are undoable, and a series of inserts/deletes are >> merged together into a single undoable action. svn up. >> >> Alas, if I understood how copy and paste works regularly in >> gtk.TreeBuffer, I could have probably figured out how to make this >> work with StyledText. I hope someone can look at that someday. >> > > Doug, I can add icons for this, but some bugs are present. > I can undo on an existing note and have all text disappear, just open a note > and do undo, and text goes away. This is a bug. Text comes back without > markup, but that is the limitation you talked about. > > I also had once a text appear after undo in a color on a note with some > colored text. Cannot reproduce however. Yes, please file the first one as a bug. I think we just need a method like a reset() that we call after loading the initial text (or a way of initially setting text without invoking the undo stack). There may be some boundary case interaction between markup and regular text, or there may be bugs in the original code. I hope that we can refine this because I really hope that we can get a nice redo/undo. But if it is too flakey, we can just pull it out easily, as it is just a gtk.TreeBuffer. -Doug > Benny > |
From: Benny M. <ben...@gm...> - 2010-08-16 19:54:11
|
2010/8/16 Doug Blank <dou...@gm...> > On Mon, Aug 16, 2010 at 1:25 PM, Benny Malengier > <ben...@gm...> wrote: > > > > > > 2010/8/16 Doug Blank <dou...@gm...> > >> > >> > > >> > I've added UndoableBuffer as a drop-in replacement for gtk.TextBuffer > >> > in the note editor. Control+z is bound to undo, and Control+shift+z is > >> > bound to redo. That could be changed to the same keys we use for db > >> > undo/redo; need to check on windows/mac to see how that works. > >> > Changing of style is not an undoable action, only deletes. > >> > >> Deletes and inserts are undoable, and a series of inserts/deletes are > >> merged together into a single undoable action. svn up. > >> > >> Alas, if I understood how copy and paste works regularly in > >> gtk.TreeBuffer, I could have probably figured out how to make this > >> work with StyledText. I hope someone can look at that someday. > >> > > > > Doug, I can add icons for this, but some bugs are present. > > I can undo on an existing note and have all text disappear, just open a > note > > and do undo, and text goes away. This is a bug. Text comes back without > > markup, but that is the limitation you talked about. > > > > I also had once a text appear after undo in a color on a note with some > > colored text. Cannot reproduce however. > > Yes, please file the first one as a bug. I think we just need a method > like a reset() that we call after loading the initial text (or a way > of initially setting text without invoking the undo stack). > > There may be some boundary case interaction between markup and regular > text, or there may be bugs in the original code. I hope that we can > refine this because I really hope that we can get a nice redo/undo. > > But if it is too flakey, we can just pull it out easily, as it is just > a gtk.TreeBuffer. > Filed as http://www.gramps-project.org/bugs/view.php?id=4178 Benny > > -Doug > > > Benny > > > |
From: Doug B. <dou...@gm...> - 2010-08-17 06:41:35
|
On Mon, Aug 16, 2010 at 3:54 PM, Benny Malengier <ben...@gm...> wrote: > > > 2010/8/16 Doug Blank <dou...@gm...> >> >> On Mon, Aug 16, 2010 at 1:25 PM, Benny Malengier >> <ben...@gm...> wrote: >> > >> > >> > 2010/8/16 Doug Blank <dou...@gm...> >> >> >> >> > >> >> > I've added UndoableBuffer as a drop-in replacement for gtk.TextBuffer >> >> > in the note editor. Control+z is bound to undo, and Control+shift+z >> >> > is >> >> > bound to redo. That could be changed to the same keys we use for db >> >> > undo/redo; need to check on windows/mac to see how that works. >> >> > Changing of style is not an undoable action, only deletes. >> >> >> >> Deletes and inserts are undoable, and a series of inserts/deletes are >> >> merged together into a single undoable action. svn up. >> >> >> >> Alas, if I understood how copy and paste works regularly in >> >> gtk.TreeBuffer, I could have probably figured out how to make this >> >> work with StyledText. I hope someone can look at that someday. >> >> >> > >> > Doug, I can add icons for this, but some bugs are present. >> > I can undo on an existing note and have all text disappear, just open a >> > note >> > and do undo, and text goes away. This is a bug. Text comes back without >> > markup, but that is the limitation you talked about. >> > >> > I also had once a text appear after undo in a color on a note with some >> > colored text. Cannot reproduce however. >> >> Yes, please file the first one as a bug. I think we just need a method >> like a reset() that we call after loading the initial text (or a way >> of initially setting text without invoking the undo stack). >> >> There may be some boundary case interaction between markup and regular >> text, or there may be bugs in the original code. I hope that we can >> refine this because I really hope that we can get a nice redo/undo. >> >> But if it is too flakey, we can just pull it out easily, as it is just >> a gtk.TreeBuffer. > > Filed as http://www.gramps-project.org/bugs/view.php?id=4178 Thanks! I also found a little bug in the way that we were handling keypresses; undo/redo seems pretty stable now. Added it to text-based gramplets, too. -Doug > Benny >> >> -Doug >> >> > Benny >> > > > |
From: Benny M. <ben...@gm...> - 2010-08-19 16:10:14
|
2010/8/17 Doug Blank <dou...@gm...> > On Mon, Aug 16, 2010 at 3:54 PM, Benny Malengier > <ben...@gm...> wrote: > > > > > > 2010/8/16 Doug Blank <dou...@gm...> > >> > >> On Mon, Aug 16, 2010 at 1:25 PM, Benny Malengier > >> <ben...@gm...> wrote: > >> > > >> > > >> > 2010/8/16 Doug Blank <dou...@gm...> > >> >> > >> >> > > >> >> > I've added UndoableBuffer as a drop-in replacement for > gtk.TextBuffer > >> >> > in the note editor. Control+z is bound to undo, and Control+shift+z > >> >> > is > >> >> > bound to redo. That could be changed to the same keys we use for db > >> >> > undo/redo; need to check on windows/mac to see how that works. > >> >> > Changing of style is not an undoable action, only deletes. > >> >> > >> >> Deletes and inserts are undoable, and a series of inserts/deletes are > >> >> merged together into a single undoable action. svn up. > >> >> > >> >> Alas, if I understood how copy and paste works regularly in > >> >> gtk.TreeBuffer, I could have probably figured out how to make this > >> >> work with StyledText. I hope someone can look at that someday. > >> >> > >> > > >> > Doug, I can add icons for this, but some bugs are present. > >> > I can undo on an existing note and have all text disappear, just open > a > >> > note > >> > and do undo, and text goes away. This is a bug. Text comes back > without > >> > markup, but that is the limitation you talked about. > >> > > >> > I also had once a text appear after undo in a color on a note with > some > >> > colored text. Cannot reproduce however. > >> > >> Yes, please file the first one as a bug. I think we just need a method > >> like a reset() that we call after loading the initial text (or a way > >> of initially setting text without invoking the undo stack). > >> > >> There may be some boundary case interaction between markup and regular > >> text, or there may be bugs in the original code. I hope that we can > >> refine this because I really hope that we can get a nice redo/undo. > >> > >> But if it is too flakey, we can just pull it out easily, as it is just > >> a gtk.TreeBuffer. > > > > Filed as http://www.gramps-project.org/bugs/view.php?id=4178 > > Thanks! I also found a little bug in the way that we were handling > keypresses; undo/redo seems pretty stable now. Added it to text-based > gramplets, too. > Ok, I updated the code, so now applied style also tracks undo/redo, so you do not loose your style changes. Doug, I do have a bug in note gramplet: Traceback (most recent call last): File "/home/benny/.gramps/gramps33/plugins/NoteGramplet/NoteGramplet.py", line 246, in save_data_edit self.note.set_styledtext(text) AttributeError: 'NoteGramplet' object has no attribute 'note' This is on clicking save, not related to the undo/redo code. Do test this, the undo/redo on gramplets should remain the same. Another small issue: on note gramplet, CTRL+B does not activate bold, but instead shows the clipboard. Benny > -Doug > > > Benny > >> > >> -Doug > >> > >> > Benny > >> > > > > > > |
From: Doug B. <dou...@gm...> - 2010-08-19 18:48:57
|
On Aug 19, 2010, at 12:10 PM, Benny Malengier <ben...@gm...> wrote: > > > 2010/8/17 Doug Blank <dou...@gm...> > On Mon, Aug 16, 2010 at 3:54 PM, Benny Malengier > <ben...@gm...> wrote: > > > > > > 2010/8/16 Doug Blank <dou...@gm...> > >> > >> On Mon, Aug 16, 2010 at 1:25 PM, Benny Malengier > >> <ben...@gm...> wrote: > >> > > >> > > >> > 2010/8/16 Doug Blank <dou...@gm...> > >> >> > >> >> > > >> >> > I've added UndoableBuffer as a drop-in replacement for gtk.TextBuffer > >> >> > in the note editor. Control+z is bound to undo, and Control+shift+z > >> >> > is > >> >> > bound to redo. That could be changed to the same keys we use for db > >> >> > undo/redo; need to check on windows/mac to see how that works. > >> >> > Changing of style is not an undoable action, only deletes. > >> >> > >> >> Deletes and inserts are undoable, and a series of inserts/deletes are > >> >> merged together into a single undoable action. svn up. > >> >> > >> >> Alas, if I understood how copy and paste works regularly in > >> >> gtk.TreeBuffer, I could have probably figured out how to make this > >> >> work with StyledText. I hope someone can look at that someday. > >> >> > >> > > >> > Doug, I can add icons for this, but some bugs are present. > >> > I can undo on an existing note and have all text disappear, just open a > >> > note > >> > and do undo, and text goes away. This is a bug. Text comes back without > >> > markup, but that is the limitation you talked about. > >> > > >> > I also had once a text appear after undo in a color on a note with some > >> > colored text. Cannot reproduce however. > >> > >> Yes, please file the first one as a bug. I think we just need a method > >> like a reset() that we call after loading the initial text (or a way > >> of initially setting text without invoking the undo stack). > >> > >> There may be some boundary case interaction between markup and regular > >> text, or there may be bugs in the original code. I hope that we can > >> refine this because I really hope that we can get a nice redo/undo. > >> > >> But if it is too flakey, we can just pull it out easily, as it is just > >> a gtk.TreeBuffer. > > > > Filed as http://www.gramps-project.org/bugs/view.php?id=4178 > > Thanks! I also found a little bug in the way that we were handling > keypresses; undo/redo seems pretty stable now. Added it to text-based > gramplets, too. > > Ok, I updated the code, so now applied style also tracks undo/redo, so you do not loose your style changes. Cool! I'll have to look to see how you did that. > > Doug, I do have a bug in note gramplet: > Yes, I want to refractor that code to me this less hackie. Should take of both of the issues you raise. -Doug > Traceback (most recent call last): > File "/home/benny/.gramps/gramps33/plugins/NoteGramplet/NoteGramplet.py", line 246, in save_data_edit > self.note.set_styledtext(text) > AttributeError: 'NoteGramplet' object has no attribute 'note' > > > This is on clicking save, not related to the undo/redo code. > > Do test this, the undo/redo on gramplets should remain the same. > > Another small issue: on note gramplet, CTRL+B does not activate bold, but instead shows the clipboard. > > Benny > > > -Doug > > > Benny > >> > >> -Doug > >> > >> > Benny > >> > > > > > > |
From: Benny M. <ben...@gm...> - 2010-08-19 21:51:23
|
2010/8/19 Doug Blank <dou...@gm...> > > Ok, I updated the code, so now applied style also tracks undo/redo, so you > do not loose your style changes. > > > Cool! I'll have to look to see how you did that. > > > I did it in a way that can exhaust memory when writing notes :-) I think we need to make the undo buffer limited, I don't see any limit to it now. What I do is keep the style tags together with the text buffer. The text undo buffer is a diff of the text however, while the style tag buffer is the entire styledtext.get_tags() result. Hence, an improvement would be to diff the two tag lists, and somehow only store the diff in the tags. I did not think about this problem however, as I think most people will have tags=None, so keeping all tags is then not such a problem Nevertheless, making the undo buffer limited in size, eg 200 undo's is probabably something we should consider, after all, some people might feel inclined to write complete disertations with style in the notes. Benny |
From: Doug B. <dou...@gm...> - 2010-08-20 02:16:36
|
On Thu, Aug 19, 2010 at 5:51 PM, Benny Malengier <ben...@gm...> wrote: > > > 2010/8/19 Doug Blank <dou...@gm...> >> >> Ok, I updated the code, so now applied style also tracks undo/redo, so you >> do not loose your style changes. >> >> Cool! I'll have to look to see how you did that. >> > > I did it in a way that can exhaust memory when writing notes :-) > I think we need to make the undo buffer limited, I don't see any limit to it > now. This is very nice! Would be great to have on all Entries... As for a limit, I think we only need to replace the stacks implemented as lists with something like: class Stack(list): def __init__(self, stack_size=None): super(Stack, self).__init__() self.stack_size = stack_size def append(self, item): if self.stack_size and len(self) == self.stack_size: self.pop(0) return super(Stack, self).append(item) There seems to be a little offset bug when you redo a delete which inserts text, the following markup is offset by the length of the insert, I believe. For example, if you: 1) type "testing 123456789" and bold the 45 2) go to the beginning and type "this " 3) then press control+z control+z (fine so far) 4) now press control+shift+z control+shift+z The first redo will move the bold to the left 4, and the second redo moves it to the right 3, so that 34 is now bold. A comment below: > What I do is keep the style tags together with the text buffer. The text > undo buffer is a diff of the text however, while the style tag buffer is the > entire styledtext.get_tags() result. > > Hence, an improvement would be to diff the two tag lists, and somehow only > store the diff in the tags. I did not think about this problem however, as I > think most people will have tags=None, so keeping all tags is then not such > a problem > > Nevertheless, making the undo buffer limited in size, eg 200 undo's is > probabably something we should consider, after all, some people might feel > inclined to write complete disertations with style in the notes. It looks like every space between a word is an undo, and so is every typed word. So, a limit of 200 is only the last 100 words you type. Maybe a bit bigger limit would be fine. -Doug > Benny > > |
From: Benny M. <ben...@gm...> - 2010-08-30 19:35:06
|
2010/8/20 Doug Blank <dou...@gm...> > On Thu, Aug 19, 2010 at 5:51 PM, Benny Malengier > <ben...@gm...> wrote: > > > > > > 2010/8/19 Doug Blank <dou...@gm...> > >> > >> Ok, I updated the code, so now applied style also tracks undo/redo, so > you > >> do not loose your style changes. > >> > >> Cool! I'll have to look to see how you did that. > >> > > > > I did it in a way that can exhaust memory when writing notes :-) > > I think we need to make the undo buffer limited, I don't see any limit to > it > > now. > > This is very nice! Would be great to have on all Entries... > But not easy > > As for a limit, I think we only need to replace the stacks implemented > as lists with something like: > > class Stack(list): > def __init__(self, stack_size=None): > super(Stack, self).__init__() > self.stack_size = stack_size > def append(self, item): > if self.stack_size and len(self) == self.stack_size: > self.pop(0) > return super(Stack, self).append(item) > > I'll look at it now > There seems to be a little offset bug when you redo a delete which > inserts text, the following markup is offset by the length of the > insert, I believe. For example, if you: > > 1) type "testing 123456789" and bold the 45 > 2) go to the beginning and type "this " > 3) then press control+z control+z (fine so far) > 4) now press control+shift+z control+shift+z > > The first redo will move the bold to the left 4, and the second redo > moves it to the right 3, so that 34 is now bold. > > Not little offset bug, but a complete design bug :-D I redesigned it completely, should now handle everything you throw at it. It is so however that the last applied style to the last redo does not happen when typing while a style is active, but that is a minor issue to keep complexity down Well, probably there will be other issues, but this covers the biggest original problems. Benny > A comment below: > > > What I do is keep the style tags together with the text buffer. The text > > undo buffer is a diff of the text however, while the style tag buffer is > the > > entire styledtext.get_tags() result. > > > > Hence, an improvement would be to diff the two tag lists, and somehow > only > > store the diff in the tags. I did not think about this problem however, > as I > > think most people will have tags=None, so keeping all tags is then not > such > > a problem > > > > Nevertheless, making the undo buffer limited in size, eg 200 undo's is > > probabably something we should consider, after all, some people might > feel > > inclined to write complete disertations with style in the notes. > > It looks like every space between a word is an undo, and so is every > typed word. So, a limit of 200 is only the last 100 words you type. > Maybe a bit bigger limit would be fine. > > -Doug > > > Benny > > > > > |
From: Benny M. <ben...@gm...> - 2010-08-30 20:03:45
|
2010/8/30 Benny Malengier <ben...@gm...> > > >> As for a limit, I think we only need to replace the stacks implemented >> as lists with something like: >> >> class Stack(list): >> def __init__(self, stack_size=None): >> super(Stack, self).__init__() >> self.stack_size = stack_size >> def append(self, item): >> if self.stack_size and len(self) == self.stack_size: >> self.pop(0) >> return super(Stack, self).append(item) >> >> > I'll look at it now > Ok, did the above for the undo buffer. It is now hard coded to 700, we can make that a config option, but I think not many people are interested in clicking 700 times undo... Clicking 700 spaces or enters does mean the buffer holds no interesting information. Benny > >> > >> > > |
From: Doug B. <dou...@gm...> - 2010-08-30 20:48:29
|
On Mon, Aug 30, 2010 at 3:34 PM, Benny Malengier <ben...@gm...> wrote: > > > 2010/8/20 Doug Blank <dou...@gm...> >> >> On Thu, Aug 19, 2010 at 5:51 PM, Benny Malengier >> <ben...@gm...> wrote: >> > >> > >> > 2010/8/19 Doug Blank <dou...@gm...> >> >> >> >> Ok, I updated the code, so now applied style also tracks undo/redo, so >> >> you >> >> do not loose your style changes. >> >> >> >> Cool! I'll have to look to see how you did that. >> >> >> > >> > I did it in a way that can exhaust memory when writing notes :-) >> > I think we need to make the undo buffer limited, I don't see any limit >> > to it >> > now. >> >> This is very nice! Would be great to have on all Entries... > > But not easy >> >> As for a limit, I think we only need to replace the stacks implemented >> as lists with something like: >> >> class Stack(list): >> def __init__(self, stack_size=None): >> super(Stack, self).__init__() >> self.stack_size = stack_size >> def append(self, item): >> if self.stack_size and len(self) == self.stack_size: >> self.pop(0) >> return super(Stack, self).append(item) >> > > I'll look at it now > >> >> There seems to be a little offset bug when you redo a delete which >> inserts text, the following markup is offset by the length of the >> insert, I believe. For example, if you: >> >> 1) type "testing 123456789" and bold the 45 >> 2) go to the beginning and type "this " >> 3) then press control+z control+z (fine so far) >> 4) now press control+shift+z control+shift+z >> >> The first redo will move the bold to the left 4, and the second redo >> moves it to the right 3, so that 34 is now bold. >> > > Not little offset bug, but a complete design bug :-D > I redesigned it completely, should now handle everything you throw at it. It > is so however that the last applied style to the last redo does not happen > when typing while a style is active, but that is a minor issue to keep > complexity down > > Well, probably there will be other issues, but this covers the biggest > original problems. Thanks, Benny, for this! The note editor, with styles, undo/redo, copy/paste, and links to objects is really starting to a be a good place for keeping track of our genealogical data. One little issue: 418388: ERROR: gramps.py: line 140: Unhandled exception Traceback (most recent call last): File "/home/dblank/gramps/trunk/src/gui/widgets/undoablestyledbuffer.py", line 99, in on_tag_insert_undoable self.__empty_redo_stack() AttributeError: 'UndoableStyledBuffer' object has no attribute '_UndoableStyledBuffer__empty_redo_stack' I looked at the code, and it looks correct. Although there may be an issue with using the super().__init__() perhaps calling the wrong super. -Doug > Benny >> >> A comment below: >> >> > What I do is keep the style tags together with the text buffer. The text >> > undo buffer is a diff of the text however, while the style tag buffer is >> > the >> > entire styledtext.get_tags() result. >> > >> > Hence, an improvement would be to diff the two tag lists, and somehow >> > only >> > store the diff in the tags. I did not think about this problem however, >> > as I >> > think most people will have tags=None, so keeping all tags is then not >> > such >> > a problem >> > >> > Nevertheless, making the undo buffer limited in size, eg 200 undo's is >> > probabably something we should consider, after all, some people might >> > feel >> > inclined to write complete disertations with style in the notes. >> >> It looks like every space between a word is an undo, and so is every >> typed word. So, a limit of 200 is only the last 100 words you type. >> Maybe a bit bigger limit would be fine. >> >> -Doug >> >> > Benny >> > >> > > > |
From: Benny M. <ben...@gm...> - 2010-08-30 23:00:43
|
Fixed this, should not be private member but a protected member Benny 2010/8/30 Doug Blank <dou...@gm...> > On Mon, Aug 30, 2010 at 3:34 PM, Benny Malengier > <ben...@gm...> wrote: > > > > > > 2010/8/20 Doug Blank <dou...@gm...> > >> > >> On Thu, Aug 19, 2010 at 5:51 PM, Benny Malengier > >> <ben...@gm...> wrote: > >> > > >> > > >> > 2010/8/19 Doug Blank <dou...@gm...> > >> >> > >> >> Ok, I updated the code, so now applied style also tracks undo/redo, > so > >> >> you > >> >> do not loose your style changes. > >> >> > >> >> Cool! I'll have to look to see how you did that. > >> >> > >> > > >> > I did it in a way that can exhaust memory when writing notes :-) > >> > I think we need to make the undo buffer limited, I don't see any limit > >> > to it > >> > now. > >> > >> This is very nice! Would be great to have on all Entries... > > > > But not easy > >> > >> As for a limit, I think we only need to replace the stacks implemented > >> as lists with something like: > >> > >> class Stack(list): > >> def __init__(self, stack_size=None): > >> super(Stack, self).__init__() > >> self.stack_size = stack_size > >> def append(self, item): > >> if self.stack_size and len(self) == self.stack_size: > >> self.pop(0) > >> return super(Stack, self).append(item) > >> > > > > I'll look at it now > > > >> > >> There seems to be a little offset bug when you redo a delete which > >> inserts text, the following markup is offset by the length of the > >> insert, I believe. For example, if you: > >> > >> 1) type "testing 123456789" and bold the 45 > >> 2) go to the beginning and type "this " > >> 3) then press control+z control+z (fine so far) > >> 4) now press control+shift+z control+shift+z > >> > >> The first redo will move the bold to the left 4, and the second redo > >> moves it to the right 3, so that 34 is now bold. > >> > > > > Not little offset bug, but a complete design bug :-D > > I redesigned it completely, should now handle everything you throw at it. > It > > is so however that the last applied style to the last redo does not > happen > > when typing while a style is active, but that is a minor issue to keep > > complexity down > > > > Well, probably there will be other issues, but this covers the biggest > > original problems. > > Thanks, Benny, for this! The note editor, with styles, undo/redo, > copy/paste, and links to objects is really starting to a be a good > place for keeping track of our genealogical data. > > One little issue: > > 418388: ERROR: gramps.py: line 140: Unhandled exception > Traceback (most recent call last): > File "/home/dblank/gramps/trunk/src/gui/widgets/undoablestyledbuffer.py", > line 99, in on_tag_insert_undoable > self.__empty_redo_stack() > AttributeError: 'UndoableStyledBuffer' object has no attribute > '_UndoableStyledBuffer__empty_redo_stack' > > I looked at the code, and it looks correct. Although there may be an > issue with using the super().__init__() perhaps calling the wrong > super. > > -Doug > > > Benny > >> > >> A comment below: > >> > >> > What I do is keep the style tags together with the text buffer. The > text > >> > undo buffer is a diff of the text however, while the style tag buffer > is > >> > the > >> > entire styledtext.get_tags() result. > >> > > >> > Hence, an improvement would be to diff the two tag lists, and somehow > >> > only > >> > store the diff in the tags. I did not think about this problem > however, > >> > as I > >> > think most people will have tags=None, so keeping all tags is then not > >> > such > >> > a problem > >> > > >> > Nevertheless, making the undo buffer limited in size, eg 200 undo's is > >> > probabably something we should consider, after all, some people might > >> > feel > >> > inclined to write complete disertations with style in the notes. > >> > >> It looks like every space between a word is an undo, and so is every > >> typed word. So, a limit of 200 is only the last 100 words you type. > >> Maybe a bit bigger limit would be fine. > >> > >> -Doug > >> > >> > Benny > >> > > >> > > > > > > |