proposed patch (error dialogs)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

proposed patch (error dialogs)

Paul Franklin-5
I'm wondering whether anybody is interested in testing or
reviewing another proposed patch?

This feature was requested by a user (as 7305).

This patch tries to change the little dialog which pops up
if gramps crashes, with an optional stack trace you can
toggle to see, as well as offering the chance to report it
to gramps.  So the patch also tries to take care of that
second dialog, if a user chooses to report it.

But crashes can happen early, even before DisplayState is
run, so there may be no uistate instance [1].  So I couldn't
just turn both classes into a standard ManagedWindow.

But I wanted to use some ManagedWindow methods and so I made
both classes inherit it, then ran the constructor (which
wants uistate) in a variant way.  So I had to manually set a
few things which are normally set there (typically ones
conditional on self.uistate.gwm).  So it'd be nice if others
can check modality and setting the transient parent, also,
although my checks show things like that are fine.

The patch also tries to cope if DisplayState has been run.
I tried to test it both ways by inserting a line into
__init__ in EditPerson.  If I wanted it to crash early I
added a "foo =" line (with no right-hand argument) and if I
wanted it to crash after the main window had been created I
inserted a "foo = bar" line and then tried to edit a person.

If the dialog is early and doesn't have a parent I tried to
cope with that by paying attention to the screen instead.
My screen is a gtk.gdk.X11Screen (GdkX11Screen) but I tried
to only use methods which I think exist for others too.

So this proposed patch seems to work for me.  But naturally
I'm interested in hearing of any problems, or suggestions as
to how I can do it better, etc.

I wish I knew how to make the dialog smaller once again if
the user toggles Error Details twice, for instance...

Anyway, it's an important part of gramps and I don't want to
get anything wrong, due to my ignorance or because I haven't
thought of something.  So as much testing as you can give it
might be a good idea.

I'd especially like to hear from Mac and Windows testers,
that the early-crash case worked for them too.


[1] Very early when gramps is started, gui/'s
startgtkloop function is started, which calls __startgramps
in turn.  That sets up GtkHandler as one of the error
loggers, then starts the Gramps class proper.  That starts
importing things, one of which is viewmanager, which in turn
starts importing a ton of things.  But it is pretty far down
that list before DisplayState is imported, and even further
before the ViewManager is actually started, which in turn
starts DisplayState.  So only then is self.uistate defined.
A very long time after GtkHandler was set up as a logger.
Then if an error happens, GtkHandler's "emit" method is
called, which then calls ErrorView to tell the user.  But I
don't know how to check (there) whether DisplayState has
been run or not, since for some errors it won't have been.

Check out the vibrant tech community on one of the world's most
engaging tech sites,!
Gramps-devel mailing list
[hidden email]

7305=ErrorView-20170205C.patch (10K) Download Attachment