I've started porting python-meh to Gtk3 and the new design. There is a
mockup of the exception dialog [1]. The obvious thing is that we don't
want the users clicking the Debug button, that would switch them to tty1
running pdb, from where they cannot get back and report bug. That's why
the Debug button is only a small link button at the bottom of the
window.
We have discussed the look on the IRC and we agreed on adding a
Traceback button [2], that would switch the user to tty3 with dumped
traceback. Then Martin Sivak came with an idea of creating a new window
with a traceback instead of using tty3, because it is better usable and
can display a lot more text on the screen. [3]

However, there are some issues with the main exception dialog:
1) Since there are two rows of the buttons, standard GtkDialog cannot be
used for it, which means having GtkWindow, running a new GtkMainLoop for
the window and using buttons' callbacks to quit it and save response ID.

2) Users can still easily get confused and lost after clicking the Debug
button which looks more like a link to the debugging guidelines
somewhere on the web than like a button that will switch you to the tty1
and run pdb.

3) Since python-meh is expected to be still used also in Firstboot, its
labels shouldn't refer to the installation.

To address 1) and 2) I've added a debug option to the configuration
class (that is instantiated and passed to python-meh when registering
the handler) and the code diplaying the Debug and Traceback buttons only
when the debug option is set to True. [4][5] This way, we can use
standard buttons placed in a more natural layout (of the GtkDialog).
Since we already have such an option in Anaconda, we can easily pass it
to python-meh and do not show buttons users are not expected to click.
Note that the "Show traceback" button is intentionally placed out of the
action area row because it doesn't close the dialog.

Is that acceptable? I believe it's easy for us to add a debug=1 option
when testing changes.

As always, comments are welcome.

[1] http://beefybeliever.wordpress.com/#jp-carousel-143
[2] http://vpodzime.fedorapeople.org/python-meh_mockup.png
[3] http://vpodzime.fedorapeople.org/python-meh_show-traceback.png
[4] http://vpodzime.fedorapeople.org/python-meh_non-debug.png
[5] http://vpodzime.fedorapeople.org/python-meh_debug.png

--
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

> We have discussed the look on the IRC and we agreed on adding a
> Traceback button [2], that would switch the user to tty3 with dumped
> traceback. Then Martin Sivak came with an idea of creating a new window
> with a traceback instead of using tty3, because it is better usable and
> can display a lot more text on the screen. [3]

In general, we've tried to avoid popping up dialogs on top of dialogs.
I know mizmo has come up with UIs that involve popping up a second
dialog and then thrown those ideas away. You may recall the old
python-meh had an expander allowing for viewing of the traceback without
having to go anywhere.

I think at least, you want the traceback label to say "View Traceback".
It's not clear to me what just "Traceback" means.

> However, there are some issues with the main exception dialog:
> 1) Since there are two rows of the buttons, standard GtkDialog cannot be
> used for it, which means having GtkWindow, running a new GtkMainLoop for
> the window and using buttons' callbacks to quit it and save response ID.

That's okay, you can nest main loops as much as you want. I do that in
newui. I can see that making your own Dialog class is not ideal,
though.

> 3) Since python-meh is expected to be still used also in Firstboot, its
> labels shouldn't refer to the installation.

Agreed.

> To address 1) and 2) I've added a debug option to the configuration
> class (that is instantiated and passed to python-meh when registering
> the handler) and the code diplaying the Debug and Traceback buttons only
> when the debug option is set to True. [4][5] This way, we can use
> standard buttons placed in a more natural layout (of the GtkDialog).
> Since we already have such an option in Anaconda, we can easily pass it
> to python-meh and do not show buttons users are not expected to click.
> Note that the "Show traceback" button is intentionally placed out of the
> action area row because it doesn't close the dialog.
>
> Is that acceptable? I believe it's easy for us to add a debug=1 option
> when testing changes.

My concern is that we lose the ability to find out what happened on
those weird transient errors that aren't totally reproducible. If you
can't hit it the second time, you'll have lost the ability to do any
debugging the first time around.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Hi ,

> My concern is that we lose the ability to find out what happened on
> those weird transient errors that aren't totally reproducible. If
> you
> can't hit it the second time, you'll have lost the ability to do any
> debugging the first time around.

That is why I insisted on the traceback still to be saved as a text file (even in nondebug mode).

Regarding pdb, we removed the "start debugger" button from most of our screens and there is no trouble in starting all our test installs with debug=1 devel=1. Common user won't debug it anyway (have we ever did any phone conducted debugging?).

Devel was the option which enabled core dumps in init/loader, we might still need to backport it now that Anaconda Widgets are C based.

Martin

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

On Thu, Jun 21, 2012 at 01:07:35PM +0200, Vratislav Podzimek wrote:
> 2) Users can still easily get confused and lost after clicking the Debug
> button which looks more like a link to the debugging guidelines
> somewhere on the web than like a button that will switch you to the tty1
> and run pdb.

Explain it to them in the dialog text. 'Debug will switch to tty1 and
run pdb for advanced debugging' or something similar.

--
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Hi Brian,

that is too much text and users are known for not reading anything long So this won't probably work..

Martin

----- Original Message -----
> On Thu, Jun 21, 2012 at 01:07:35PM +0200, Vratislav Podzimek wrote:
> > 2) Users can still easily get confused and lost after clicking the
> > Debug
> > button which looks more like a link to the debugging guidelines
> > somewhere on the web than like a button that will switch you to the
> > tty1
> > and run pdb.
>
> Explain it to them in the dialog text. 'Debug will switch to tty1 and
> run pdb for advanced debugging' or something similar.
>
> --
> Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA
> (PST8PDT)
>
> _______________________________________________
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

> That is why I insisted on the traceback still to be saved as a text
> file (even in nondebug mode).

That's how python-meh has always worked. The traceback is written to
/tmp/anaconda-tb-* and then whatever UI stuff is going to happen gets
done.

> Regarding pdb, we removed the "start debugger" button from most of our
> screens and there is no trouble in starting all our test installs with
> debug=1 devel=1. Common user won't debug it anyway (have we ever did
> any phone conducted debugging?).

I've certainly told people pdb commands to type in bug reports before.

> Devel was the option which enabled core dumps in init/loader, we might
> still need to backport it now that Anaconda Widgets are C based.

I'm not so sure this will be necessary. I have not yet seen any
segfaults originating in AW, just streams of gtk assertions on tty1. We
can also likely catch any potential segfaults with advance testing since
this is a standalone blob.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Hi,

> > Devel was the option which enabled core dumps in init/loader, we
> > might
> > still need to backport it now that Anaconda Widgets are C based.
>
> I'm not so sure this will be necessary. I have not yet seen any
> segfaults originating in AW, just streams of gtk assertions on tty1.
> We
> can also likely catch any potential segfaults with advance testing
> since
> this is a standalone blob.

We have seen segfaults during lightbox and timezone widgets development. But if we write tests for it, we might be good.

Coredump support is pretty easy though, we just have to disable autoreboot and set ulimit. Shell is already handled by systemd.

Martin

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list