From: <db...@br...> - 2006-02-25 14:47:51
|
> Doug, > > I was running CLI tests before the release, and found that > options_help dict of the CalendarOptions instance in the Calendar.py > contains this: > > { > 'maiden_name': ('=3D0/1',"Use married women's maiden name.", > "Select to use married women's maiden name."), > 'anniversaries': ('=3D0/1','Include anniversaries', > 'Select to include anniversaries'), > 'title': (None, None, None), > 'text': (None, None, None), > 'text2style': (None, None, None), > 'birthdays': ('=3D0/1', 'Include birthdays', 'Select to include > birthdays'), > 'alive': ('=3D0/1', 'Include only living people', > 'Select to only include living people'), > 'holidays': ('=3D0/1', 'Include holidays', 'Select to include > holidays'), > 'text2': ('=3Dstr', 'Medium size text', 'Any text'), > 'text3': ('=3Dstr', 'Small text area', 'Any text'), > 'text1': ('=3Dstr', 'Large text area', 'Any text'), > 'numbers': (None, None, None), > 'offset': ('=3Dnum', 'Distance to move text on page', 'Any number')= , > 'year': ('=3Dnum', 'Year of calendar', 'Any year'), > 'text3style': (None, None, None), > 'text1style': (None, None, None), > 'daynames': (None, None, None), > 'border': (None, None, None) > } > > > There is a problem with options whose help values contain None. > The self-documentation system relies on help values being strings. > So, can these be changed? I am not sure that just replacing > None with empty strings is useful. It's late now and I don't > even pretend to understand what is going on with those style things. > But I'm thinking that you may be able to answer it right away :-) > > If these are indeed styles and not options, can they be removed > from the CalendarOptions? The other reports do it this way, and > the style is specified as a whole by style name, not by individual > style elements. If these are options visible from the report dialog > (as opposed to Style Editor), then can they use more meaningful > help strings? Alex, Ok, I think that this is easy to fix. The problem was that I was trying t= o make all graphical objects have the same kind of interface in reports. Whether it is a spinner, checkbox, filter, or style, they all get treated in a consistent manner. It may be that you want to have help for styles. But, I'll assume that yo= u don't. To remove them from the options_help dictionary, just change the register method of the base Widget class, around line 388: ---- def register(self): className =3D self.__class__.__name__ if className =3D=3D "FilterWidget": self.option_object.enable_dict['filter'] =3D 0 elif className =3D=3D "StyleWidget": self.option_object[self["name"]] =3D self["value"] else: self.option_object[self["name"]] =3D self["value"] self.option_object.options_help[self["name"]] =3D ( self["wtype"], self["help"], self["valid_text"]) ---- and that should be fine. I don't use the options_help for anything, so that should only effect what the CLI help system does. I tested this change and the Calendar is unaffected. I'll be out-of-town till Sunday night. I'll check back then, try everything out, see if I have SourceForge access, and see if the "and" English problem, and reversed married-name/maiden-name checkbox issues ar= e fixed (and fix them otherwise). Thanks for all the help in testing and integrating this into gramps. I hope that wrestling with the Widgets will make report writing easier (and other things possible) soon. -Doug > Thanks, > Alex > > -- > Alexander Roitman http://www.gramps-project.org > |