Doug, first, your comment string for MenuReport/ToolOptions  is not correct. Reading it did not make me any wiser.

Second,

def make_gui_obj(self, gtk, dialog):
        """
        Add an FilterListOption to the dialog.
        """
        self.gobj = gtk.combo_box_new_text()
        for filter in self.get_items():
            if filter in ["person"]:
                filter_list = ReportUtils.get_person_filters (dialog.person,False)
                for filter in filter_list:
                    self.gobj.append_text(filter.get_name())
                    self.add_filter(filter)
        # FIXME: set proper default
        self.gobj.set_active(0)

Change this to


def make_gui_obj(self, gtk, dialog):
        """
        Add an FilterListOption to the dialog.
        """
        from ReportBase import ReportUtils
        self.gobj = gtk.combo_box_new_text()
        for filter in self.get_items():
            if filter in ["person"]:
                filter_list = ReportUtils.get_person_filters(dialog.person,False)
                for filter in filter_list:
                    self.gobj.append_text(filter.get_name())
                    self.add_filter(filter)
        # FIXME: set proper default
        self.gobj.set_active(0)

Like this you drop the ReportUtils dependance. Might be that this filter making would be better in a PluginUtils. Actually, is there not already another method to create list of filters, eg for use in the filter sidebars?

This leaves you with the

class MenuReportOptions(MenuOptions,ReportOptions):
    """
    The MenuOptions class implementes the ReportOptions functionality in a
    generic way so that the user does not need to be concerned with the
    graphical representation of the options.
   
    The user should inherit the MenuOptions class and override the
    add_menu_options function. The user can add options to the menu and the
    MenuOptions class will worry about setting up the GUI.
    """
    def __init__(self,name,person_id=None):
        self.menu = Menu()
        ReportOptions.__init__(self,name, person_id)

class MenuToolOptions(MenuOptions,Tool.ToolOptions):
    """
    The MenuOptions class implementes the ReportOptions functionality in a
    generic way so that the user does not need to be concerned with the
    graphical representation of the options.
   
    The user should inherit the MenuOptions class and override the
    add_menu_options function. The user can add options to the menu and the
    MenuOptions class will worry about setting up the GUI.
    """
    def __init__(self,name,person_id=None):
        self.menu = Menu()
        Tool.ToolOptions.__init__(self,name, person_id)


I would move these to the ReportUtils and the Tools directory instead of in the general PluginUtils folder.

Benny

2007/11/29, Douglas S. Blank <dblank@cs.brynmawr.edu>:
On Thu, November 29, 2007 7:40 am, Douglas S. Blank wrote:
> On Thu, November 29, 2007 3:46 am, James G. Sack (jim) wrote:
>> A side effect of a little experimenting to try to create some tests, I
>> discovered a circular reference. If you start off with an import of
>> ReportBase you get an import error
>>
>> ReportBase(__init__)
>>  from _CommandLineReport import cl_report
>>   import PluginUtils(__init__)
>>    from _MenuOptions import MenuReportOptions, ...
>>     from ReportBase import ReportUtils, ReportOptions
>>
>> but ReportUtils is unknown at within the part of ReportBase "compiled"
>> up-to the import of _CommandLineReport, hence the error.
>>
>> The import error does not occur if you import _MenuOptions first,
>> but I thought it worth pointing out.
>>
>> Circular references are sometimes hard to eliminate, but perhaps someone
>> more familiar with the module dependencies will look at this one to see
>> if there might be problems with this one.
>
> Thanks, Jim. I must have just introduced this (yeah, tests!). The problem
> is that MenuReportOptions inherits from MenuOptions and ReportOptions. I
> guess the solution would be to move it, but I'm not sure where. That would
> require two imports when writing reports and tools, but if that is
> required, ok then.
>
> Ideas?

It could be that reordering the imports in ReportBase will fix this.

But as Jim said, someone more familiar with the dependencies should have a
look.

-Doug

> -Doug
>
>>
>> Regards,
>> ..jim
>>
>> -------------------------------------------------------------------------
>> SF.Net email is sponsored by: The Future of Linux Business White Paper
>> from Novell.  From the desktop to the data center, Linux is going
>> mainstream.  Let it simplify your IT future.
>> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>> _______________________________________________
>> Gramps-devel mailing list
>> Gramps-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>
>
>
> --
> Douglas S. Blank
> Associate Professor, Bryn Mawr College
> http://cs.brynmawr.edu/~dblank/
> Office: 610 526 6501
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>


--
Douglas S. Blank
Associate Professor, Bryn Mawr College
http://cs.brynmawr.edu/~dblank/
Office: 610 526 6501

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
Gramps-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gramps-devel