View Single Post
Old 04-11-2012, 09:42 AM   #5
idea00
Junior Member
idea00 will become famous soon enoughidea00 will become famous soon enoughidea00 will become famous soon enoughidea00 will become famous soon enoughidea00 will become famous soon enoughidea00 will become famous soon enough
 
Posts: 7
Karma: 684
Join Date: Apr 2012
Device: android
Quote:
Originally Posted by kovidgoyal View Post
Don't change the Widget class. Instead implemnt get_value_handler and set_value_handler in the S&R class to special case the handling of this option. You can be as flexible as you want in those methods. A grep in that directory will show you examples of using those methods.
The methods are barely used by the classes in that directory, but looking at Widget again I see how they work. The methods still get passed a property of the main class (the g parameter) not the name of the desired option.
I'll still need the opt_sr* properties but I can get it to work by saving the name of the option in the property.

I'll revert the changes to Widget and implement: get_value_handler, set_value_handler and connect_gui_obj_handler.

Quote:
Originally Posted by kovidgoyal View Post
On the GUI:

There are two less than optimal scenarios:

1) The user enters something but does not click add. I which case his expression is ignored
2) The user enters something but does not click clear, in which case the expression is applied even though he did not intend it to be applied.

To me, scenario (1) is preferable, as it makes the feature easier to use for newbies. You can always add a popup that pops up only if there is text in those boxes and asks the user if he wants to apply that text or not. Do these by subclassing commit() in the S&R widget.
I was thinking on the lines of less damage. Scenario 1 may cause the user to loose text from books should the original be deleted after the (erroneous) conversion, scenario 2 will merely not do the job but no data will be lost.
In any case I'll go with the popup option which is the best and also clear the fields for search/replace in the RegexEdit and Textbox when the user adds or changes a S/R definition in the table.

Quote:
Originally Posted by kovidgoyal View Post
On the CLI:

...
Sorry just now the acronym CLI (Command Line Interface) clicked. I thought you where referring to something else in your previous post and hence the answer.
I'm going to restore backward compatibility so the CLI for all the original sr* options should be restored and use a single human parsable serialization scheme for both the UI saved files and the CLI.
idea00 is offline   Reply With Quote