Hi, I've found a bug when changing a various pref setting in the prefs dialog, then cancelling the dialog without applying the changes. Next time the dialog is shown the edited values are still present.
Could cause the user to then apply the unwanted changes without realizing, so it's quite a nasty bug.
Nick
On Thu, 15 Sep 2011 17:45:25 +0100 (BST) Nick Treleaven nick.treleaven@btopenworld.com wrote:
I've found a bug when changing a various pref setting in the prefs dialog, then cancelling the dialog without applying the changes. Next time the dialog is shown the edited values are still present.
Yes, for the integer values. We (me and Colomban) know, and discussed it on the patch tracker page. IIRC, it's a bug in the spin renderer - if you click outside the entry, it generates an editing done signal instead of editing cancelled. Fixing it required nasty hacking, and/or was dependent on the gtk+ version...
The other option is to use the text renderer for integers (as you can see, the statusbar_template is OK). As a side effect, the initial page creation will be about 20% faster. But we'll lose the cute arrows. :)
On Thu, 15 Sep 2011 17:45:25 +0100 (BST) Nick Treleaven nick.treleaven@btopenworld.com wrote:
I've found a bug when changing a various pref setting in the prefs dialog, then cancelling the dialog without applying the changes. Next time the dialog is shown the edited values are still present.
You are right, the problem is that cancelling will not reset the internal stash tree values (the spin renderer is an unrelated bug).
How about adding a PREF_CANCEL action to prefs.c only that will call a stash_group_cancel() to reset the values? The other option is to clear the store, but that means recreating the various list [a visibly slow process] each time Edit -> Preferences is invoked, while traversing the model is fast.
Le 15/09/2011 19:59, Dimitar Zhekov a écrit :
On Thu, 15 Sep 2011 17:45:25 +0100 (BST) Nick Treleaven nick.treleaven@btopenworld.com wrote:
I've found a bug when changing a various pref setting in the prefs dialog, then cancelling the dialog without applying the changes. Next time the dialog is shown the edited values are still present.
You are right, the problem is that cancelling will not reset the internal stash tree values (the spin renderer is an unrelated bug).
Ah right, good catch.
How about adding a PREF_CANCEL action to prefs.c only that will call a stash_group_cancel() to reset the values? The other option is to clear the store, but that means recreating the various list [a visibly slow process] each time Edit -> Preferences is invoked, while traversing the model is fast.
What about traversing the model on reshow to reset it to the default values? (though honestly building the view don't seem any slow to me)
--- On Thu, 15/9/11, Colomban Wendling lists.ban@herbesfolles.org wrote:
How about adding a PREF_CANCEL action to prefs.c only
that will call a
stash_group_cancel() to reset the values? The other
I don't think that's a good design, the stash group settings should not actually be changed until ok/apply.
Perhaps you meant stash_tree_cancel(), but see below.
option is to clear
the store, but that means recreating the various list
[a visibly slow
process] each time Edit -> Preferences is invoked,
while traversing the
model is fast.
What about traversing the model on reshow to reset it to the default values?
Yes, that would be best. (This would be similar to how all stash prefs work with stash_group_display - the widgets are updated with the current settings).
(though honestly building the view don't seem any slow to me)
I didn't notice any slowness, but it would be interesting to know why if it is.
Nick
On Fri, 16 Sep 2011 11:33:31 +0100 (BST) Nick Treleaven nick.treleaven@btopenworld.com wrote:
How about adding a PREF_CANCEL action to prefs.c only that will call a stash_group_cancel() to reset the values?
I don't think that's a good design, the stash group settings should not actually be changed until ok/apply.
On Thu, 15 Sep 2011 22:48:06 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
What about traversing the model on reshow to reset it to the default values?
Yes, that would be best.
Of course, PREF_CANCEL was stupid. Actually, it should create the StartTreeValue entries on _setup, set them on PREF_DISPLAY, and get them on PREF_UPDATE (the latter is currently implemented).
(This would be similar to how all stash prefs work with stash_group_display - the widgets are updated with the current settings).
Almost identical. I'll try to write it today.
--- On Fri, 16/9/11, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
What about traversing the model on reshow to
reset it to
the default values?
Yes, that would be best.
Of course, PREF_CANCEL was stupid. Actually, it should create the StartTreeValue entries on _setup, set them on PREF_DISPLAY, and get them on PREF_UPDATE (the latter is currently implemented).
(This would be similar to how all stash prefs work
with
stash_group_display - the widgets are updated with the
current
settings).
Almost identical. I'll try to write it today.
Great, thanks :)
Hi,
Attached is the stash_tree_display(). I thought that a row changed signal will be needed, but it works without it. The renreders always reget their data when the tree is shown.
No string changes. _append_pref() ignores the new action argument.
On 16/09/2011 18:11, Dimitar Zhekov wrote:
Attached is the stash_tree_display(). I thought that a row changed signal will be needed, but it works without it. The renreders always reget their data when the tree is shown.
No string changes. _append_pref() ignores the new action argument.
Thanks, hopefully I'll commit it soon.
On 21/09/2011 16:31, Nick Treleaven wrote:
On 16/09/2011 18:11, Dimitar Zhekov wrote:
Attached is the stash_tree_display(). I thought that a row changed signal will be needed, but it works without it. The renreders always reget their data when the tree is shown.
No string changes. _append_pref() ignores the new action argument.
Thanks, hopefully I'll commit it soon.
Committed, thanks.