cmdline mode is text mode only, so that's why this patch only touches the tui code. --- pyanaconda/ui/tui/__init__.py | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/pyanaconda/ui/tui/__init__.py b/pyanaconda/ui/tui/__init__.py index 9f34c4a..56791ba 100644 --- a/pyanaconda/ui/tui/__init__.py +++ b/pyanaconda/ui/tui/__init__.py @@ -21,6 +21,7 @@
from pyanaconda import ui from pyanaconda.ui import common +from pyanaconda.flags import flags import simpleline as tui from hubs.summary import SummaryHub from hubs.progress import ProgressHub @@ -183,6 +184,9 @@ class TextUserInterface(ui.UserInterface): times where anaconda cannot make a reasonable decision. We don't want to overwhelm the user with choices. """ + if flags.automatedInstall and not flags.ksprompt: + # If we're in cmdline mode, just say no. + return False question_window = YesNoDialog(self._app, message) self._app.switch_screen_modal(question_window) return question_window.answer
On Thu, 2012-10-25 at 22:43 -0700, Jesse Keating wrote:
cmdline mode is text mode only, so that's why this patch only touches the tui code.
pyanaconda/ui/tui/__init__.py | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/pyanaconda/ui/tui/__init__.py b/pyanaconda/ui/tui/__init__.py index 9f34c4a..56791ba 100644 --- a/pyanaconda/ui/tui/__init__.py +++ b/pyanaconda/ui/tui/__init__.py @@ -21,6 +21,7 @@
from pyanaconda import ui from pyanaconda.ui import common +from pyanaconda.flags import flags import simpleline as tui from hubs.summary import SummaryHub from hubs.progress import ProgressHub @@ -183,6 +184,9 @@ class TextUserInterface(ui.UserInterface): times where anaconda cannot make a reasonable decision. We don't want to overwhelm the user with choices. """
if flags.automatedInstall and not flags.ksprompt:
# If we're in cmdline mode, just say no.
return False question_window = YesNoDialog(self._app, message) self._app.switch_screen_modal(question_window) return question_window.answer
Do we really want to just say no in every case this code is used in cmdline mode? It looks to me as a potential source of more bugs. I'm afraid callers should take care of the check and not call showYesNoQuestion in case it cannot be answered (helper function for this can be easily created). Or maybe adding a 'default_answer' parameter defaulting to False that will be returned in case the answer cannot be obtained from the user? This would, however, need a change in the UserInteraface and GraphicalUserInterface too.
On 10/26/2012 01:41 AM, Vratislav Podzimek wrote:
On Thu, 2012-10-25 at 22:43 -0700, Jesse Keating wrote:
cmdline mode is text mode only, so that's why this patch only touches the tui code.
pyanaconda/ui/tui/__init__.py | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/pyanaconda/ui/tui/__init__.py b/pyanaconda/ui/tui/__init__.py index 9f34c4a..56791ba 100644 --- a/pyanaconda/ui/tui/__init__.py +++ b/pyanaconda/ui/tui/__init__.py @@ -21,6 +21,7 @@
from pyanaconda import ui from pyanaconda.ui import common +from pyanaconda.flags import flags import simpleline as tui from hubs.summary import SummaryHub from hubs.progress import ProgressHub @@ -183,6 +184,9 @@ class TextUserInterface(ui.UserInterface): times where anaconda cannot make a reasonable decision. We don't want to overwhelm the user with choices. """
if flags.automatedInstall and not flags.ksprompt:
# If we're in cmdline mode, just say no.
return False question_window = YesNoDialog(self._app, message) self._app.switch_screen_modal(question_window) return question_window.answer
Do we really want to just say no in every case this code is used in cmdline mode? It looks to me as a potential source of more bugs. I'm afraid callers should take care of the check and not call showYesNoQuestion in case it cannot be answered (helper function for this can be easily created). Or maybe adding a 'default_answer' parameter defaulting to False that will be returned in case the answer cannot be obtained from the user? This would, however, need a change in the UserInteraface and GraphicalUserInterface too.
Right now this code (the showYesNoQuestion) only appears to be used by errors.py to handle a variety of error states. In all cases it appears to be that if we get a false from the question we raise the error.
I could go through each caller of showYesNoQuestion and skip the code path if flags.automatedInstall and not flags.ksprompt, but that would be adding more code.
I'm open to either that or leaving it as it is with the assumption that a negative answer is just erroring out the install.
On Mon, Oct 29, 2012 at 03:59:58PM -0700, Jesse Keating wrote:
On 10/26/2012 01:41 AM, Vratislav Podzimek wrote:
On Thu, 2012-10-25 at 22:43 -0700, Jesse Keating wrote:
cmdline mode is text mode only, so that's why this patch only touches the tui code.
pyanaconda/ui/tui/__init__.py | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/pyanaconda/ui/tui/__init__.py b/pyanaconda/ui/tui/__init__.py index 9f34c4a..56791ba 100644 --- a/pyanaconda/ui/tui/__init__.py +++ b/pyanaconda/ui/tui/__init__.py @@ -21,6 +21,7 @@
from pyanaconda import ui from pyanaconda.ui import common +from pyanaconda.flags import flags import simpleline as tui from hubs.summary import SummaryHub from hubs.progress import ProgressHub @@ -183,6 +184,9 @@ class TextUserInterface(ui.UserInterface): times where anaconda cannot make a reasonable decision. We don't want to overwhelm the user with choices. """
if flags.automatedInstall and not flags.ksprompt:
# If we're in cmdline mode, just say no.
return False question_window = YesNoDialog(self._app, message) self._app.switch_screen_modal(question_window) return question_window.answer
Do we really want to just say no in every case this code is used in cmdline mode? It looks to me as a potential source of more bugs. I'm afraid callers should take care of the check and not call showYesNoQuestion in case it cannot be answered (helper function for this can be easily created). Or maybe adding a 'default_answer' parameter defaulting to False that will be returned in case the answer cannot be obtained from the user? This would, however, need a change in the UserInteraface and GraphicalUserInterface too.
Right now this code (the showYesNoQuestion) only appears to be used by errors.py to handle a variety of error states. In all cases it appears to be that if we get a false from the question we raise the error.
I could go through each caller of showYesNoQuestion and skip the code path if flags.automatedInstall and not flags.ksprompt, but that would be adding more code.
I'm open to either that or leaving it as it is with the assumption that a negative answer is just erroring out the install.
Putting the check inside the method is better than wrapping every single call to it. Maybe add a note to the docstring that describes the behavior.
anaconda-patches@lists.fedorahosted.org