Quantcast

RFC: Improving report options

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RFC: Improving report options

Brian Matherly
Lately I have felt inspired to try to make it easier to write new reports. One thing that I find cumbersome is adding options to a report. To me, it doesn't make sense for a report plug-in to require GTK. Douglas Blank inspired me with his widgets in the calendar report. So I'm trying something out that I think will make things easier:

http://gramps.svn.sourceforge.net/viewvc/gramps?view=rev&revision=8926

Fundamentally, I have created a new options class called MenuOptions. It inherits from ReportOptions but does all the work of generating the graphical elements and parsing them out. The report writer just has to implement the add_menu_options() function and add the appropriate options to the menu.

Here is the _MenuOptions.py file which includes the MenuOptions class and all the types of options that can be added:

http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/src/ReportBase/_MenuOptions.py?view=markup

Here is an example of how the AncestorChart report changed when using the MenuOptions functionality:

http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/src/plugins/AncestorChart.py?view=diff&pathrev=8926&r1=8884&r2=8926&diff_format=h

I don't see this as a final solution. I see it as a phase in a master plan to clean up the report interface. If this works out, the goal would be for all reports to eventually use this interface and do away with the old way.

So I'm looking for feedback. Is this a good idea? Any ideas of how to do it better? All comments are welcome.

Thanks,

~Brian





-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC: Improving report options

Don Allingham
Since "RFC" stands for "Request For Comments", my comment would be "Good
job".

On Tue, 2007-09-04 at 20:29 -0700, Brian Matherly wrote:

> Lately I have felt inspired to try to make it easier to write new reports. One thing that I find cumbersome is adding options to a report. To me, it doesn't make sense for a report plug-in to require GTK. Douglas Blank inspired me with his widgets in the calendar report. So I'm trying something out that I think will make things easier:
>
> http://gramps.svn.sourceforge.net/viewvc/gramps?view=rev&revision=8926
>
> Fundamentally, I have created a new options class called MenuOptions. It inherits from ReportOptions but does all the work of generating the graphical elements and parsing them out. The report writer just has to implement the add_menu_options() function and add the appropriate options to the menu.
>
> Here is the _MenuOptions.py file which includes the MenuOptions class and all the types of options that can be added:
>
> http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/src/ReportBase/_MenuOptions.py?view=markup
>
> Here is an example of how the AncestorChart report changed when using the MenuOptions functionality:
>
> http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/src/plugins/AncestorChart.py?view=diff&pathrev=8926&r1=8884&r2=8926&diff_format=h
>
> I don't see this as a final solution. I see it as a phase in a master plan to clean up the report interface. If this works out, the goal would be for all reports to eventually use this interface and do away with the old way.
>
> So I'm looking for feedback. Is this a good idea? Any ideas of how to do it better? All comments are welcome.
>
> Thanks,
>
> ~Brian
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC: Improving report options

bm-5
In reply to this post by Brian Matherly
Looks great.

First a general comment. I find the naming strange, the placement in
files/directories strange, as well as having the idea we start to have things
popping up that do a bit the same in all places.

Concrete:
1/Why the name MenuOptions ? I do not see a Menu, or am I missing something as
non native speaker? I would suggest to move all classes from ReportOptions
except ReportOptions to a file OptionHandling.py, and then everything from
MenuOptions in ReportOptions, merging the MenuOptions class with ReportOptions
class.

2/Having Options of which ReportOptions are derived, and a class Option, is
confusing to me. By lack of better idea, why not BaseOption, or Setting.

3/I find the fact that _Options is in PluginUtils and these in
ReportBase a bit
strange. Could it not be usefull to also offer these classes for use in the
Tools. That is, how much is actually depending on the ReportOptions, as
opposed
to the Options class.

4/Don is making ExportOptions. Not really related, but some functionality will
be the same: add a filter to the dialog of the exporters, store it in
options/config, .... I just mean, some of this stuff is report related, other
parts are options related, and perhaps usefull in other places.

Some comment on anchestor chart (I know, you mean it as just an
example, but it
might give some ideas on how to continue):

1/please, take this chance to improve the disp tooltip in ancestorchart.
disp.set_help(_("Display format for the outputbox."))
Really doesn't tell the user what he can do, or how he can find info on
what he
can do.

2/I find this textoption not such a good way of having users enter options. I
like the approach in Family Lines, plugin, see People of interest or Family
Colours. In this case, a table would be nice with first entry Line number,
second entry Text. Inline editing of the text. A nice Option class for that
perhaps?

3/Concerning the reportdialog, in the action bar, a button 'set
defaults' would
be very welcome. I'm sure many users really bork their report settings, and
would love the ability to reset. Especially here with the display format.
For that, after set_help, one would need also set_default, even if not used at
the moment. Defaults cannot be saved to xml file, as we want on upgrade to be
able to change the defaults (good for debugging too, we know what happens then
and that bug reporter runs with same options), so they must be
registered every
time in the code without ever being overwritten.

4/You probably want to add other widgets to this class. Consider the color
widget of Family Lines (in category persons calling the color chooser).
And the
tabled entry I mentioned before

5/I understand the first option, paper options, is driven by the top of the
report dialog (selection of filename), but still, it would be nice if also
those options are handled by this new class. So in _ReportDialog.py, function
setup_paper_frame(self), to also use _MenuOptions.py classes. That would be
consistent

7/scaling/alignment. the new options you added have good alignment.
Perhaps you
can fix the alignment of the paper options (distance between boxes increases)
so it works like other options. Also the top part (Document options), scales
badly in my opinion, becoming larger without need (better to expand the
options
at the bottom, especially as one might add a table there).

Just some comments. Do with them as you please.

Benny

Quoting Brian Matherly <[hidden email]>:

> Lately I have felt inspired to try to make it easier to write new
> reports. One thing that I find cumbersome is adding options to a
> report. To me, it doesn't make sense for a report plug-in to require
> GTK. Douglas Blank inspired me with his widgets in the calendar
> report. So I'm trying something out that I think will make things
> easier:
>
> http://gramps.svn.sourceforge.net/viewvc/gramps?view=rev&revision=8926
>
> Fundamentally, I have created a new options class called MenuOptions.
> It inherits from ReportOptions but does all the work of generating
> the graphical elements and parsing them out. The report writer just
> has to implement the add_menu_options() function and add the
> appropriate options to the menu.
>
> Here is the _MenuOptions.py file which includes the MenuOptions class
> and all the types of options that can be added:
>
> http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/src/ReportBase/_MenuOptions.py?view=markup
>
> Here is an example of how the AncestorChart report changed when using
> the MenuOptions functionality:
>
> http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/src/plugins/AncestorChart.py?view=diff&pathrev=8926&r1=8884&r2=8926&diff_format=h
>
> I don't see this as a final solution. I see it as a phase in a master
> plan to clean up the report interface. If this works out, the goal
> would be for all reports to eventually use this interface and do away
> with the old way.
>
> So I'm looking for feedback. Is this a good idea? Any ideas of how to
> do it better? All comments are welcome.
>
> Thanks,
>
> ~Brian
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC: Improving report options

Brian Matherly
In reply to this post by Brian Matherly
Benny,

Thanks for your comments. They are very helpful.

>First a general comment. I find the naming strange, the placement in
>files/directories strange, as well as having the idea we start to have things
>popping up that do a bit the same in all places.

>Concrete:
>1/Why the name MenuOptions ? I do not see a Menu, or am I missing something as
>non native speaker? I would suggest to move all classes from ReportOptions
>except ReportOptions to a file OptionHandling.py, and then everything from
>MenuOptions in ReportOptions, merging the MenuOptions class with ReportOptions
>class.
>
>2/Having Options of which ReportOptions are derived, and a class Option, is
>confusing to me. By lack of better idea, why not BaseOption, or Setting.

I think you are beginning to see some of the motivation behind my work. Ideally, I would just tear everything up and start from scratch. But I'm afraid I would not be done in time for a release. So I am looking for an incremental improvement instead. If this concept is widely accepted, then it will hopefully move in an orderly progression to the next logical step.

>3/I find the fact that _Options is in PluginUtils and these in
>ReportBase a bit
>strange. Could it not be usefull to also offer these classes for use in the
>Tools. That is, how much is actually depending on the ReportOptions, as
>opposed
>to the Options class.

Again, I think that would be noble long term goal. First, all the reports would have to be converted. Then MenuOptions could replace ReportOptions (and possibly be renamed). Then, the plugins could be converted (if possible). Then MenuOptions could replace Options (and possible be renamed). Then you would no longer have all this inheritance and confusing relationships.

>4/Don is making ExportOptions. Not really related, but some functionality will
>be the same: add a filter to the dialog of the exporters, store it in
>options/config, .... I just mean, some of this stuff is report related, other
>parts are options related, and perhaps usefull in other places.

Perhaps the concept could be further generalized for wider use in Gramps.

>Some comment on anchestor chart (I know, you mean it as just an
>example, but it
>might give some ideas on how to continue):

>1/please, take this chance to improve the disp tooltip in ancestorchart.
>disp.set_help(_("Display format for the outputbox."))
>Really doesn't tell the user what he can do, or how he can find info on
>what he
>can do.

I wish more people would nitpick the labels and help text in the reports. But, you have to give me credit for making it a tooltip!

>2/I find this textoption not such a good way of having users enter options. I
>like the approach in Family Lines, plugin, see People of interest or Family
>Colours. In this case, a table would be nice with first entry Line number,
>second entry Text. Inline editing of the text. A nice Option class for that
>perhaps?

Good idea.

>3/Concerning the reportdialog, in the action bar, a button 'set
>defaults' would
>be very welcome. I'm sure many users really bork their report settings, and
>would love the ability to reset. Especially here with the display format.
>For that, after set_help, one would need also set_default, even if not used at
>the moment. Defaults cannot be saved to xml file, as we want on upgrade to be
>able to change the defaults (good for debugging too, we know what happens then
>and that bug reporter runs with same options), so they must be
>registered every
>time in the code without ever being overwritten.

Another good idea. It probably wouldn't be that hard to do.

>4/You probably want to add other widgets to this class. Consider the color
>widget of Family Lines (in category persons calling the color chooser).
>And the
>tabled entry I mentioned before

You're right. We'll be adding widgets until the end of time. This could also be considered a disadvantage - if a report author wants a widget that doesn't exist, they have to change the report system to support it. But the advantage is that if they want to use a widget that does exist, it is very easy to use.

>5/I understand the first option, paper options, is driven by the top of the
>report dialog (selection of filename), but still, it would be nice if also
>those options are handled by this new class. So in _ReportDialog.py, function
>setup_paper_frame(self), to also use _MenuOptions.py classes. That would be
>consistent

You're right in sync with me on this point. This would definitely part of my master plan - if I had such a thing. I would also want each document type to be able to define it's own options as not all of them use paper options (HTML for one).

>7/scaling/alignment. the new options you added have good alignment.
>Perhaps you
>can fix the alignment of the paper options (distance between boxes increases)
>so it works like other options. Also the top part (Document options), scales
>badly in my opinion, becoming larger without need (better to expand the
>options
>at the bottom, especially as one might add a table there).

Another good idea - it could all be handled by the same code.

Thanks again, Benny. This is exactly the kind of feedback I was looking for. Your comments have reinforced my feelings on where improvements can be made.

~Brian




-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Loading...