> 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list