[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Screen support (was: Next d-i alpha release: late June)


Cyril Brulebois wrote:
> > During RFC stage of adding screen-udeb, firstly I though it's not
> > necessary for normal PC, which is not exact the same with "everyone"
> > you mentioned but should be close to, however a few feedbacks
> > convinced me that normal PC still need screen-udeb [0][1][2].
> > I think the solution below is a middle ground, which I guess it can be
> > accepted by everyone.
> > - Keep screen-udeb in "common" for everyone, but don't start it
> > automatically on i386/amd64.
> It'd be nice if Ben, Axel, Philipp (cc'd) could share whether they
> expect screen to start automatically, with text and/or graphical
> installer, or whether they would be OK to opt in for that (and if so,
> how).

I have no strong preference here. My imagination is the following:

* Start screen by default if there's no virtual console available,
  i.e. over serial console and SSH console.
* Don't start screen by default if there's a virtual console
* Having a screen-udeb for i386/amd64/powerpc/etc. available shouldn't
  hurt though.
* Screen in combination with the graphical D-I doesn't make sense to
  me, i.e. we shouldn't run it there.

I though can also imagine and am fine with the following setup:

* Only start screen on demand via menu on every platform.

There are though a few workflow questions in mind which I haven't
noticed yet in this thread (but I might have overseen or forgotten

* If D-I is running inside screen, there should be an outside-screen
  D-I menu entry to reattach the running session on the current
  terminal device.


  + Starting D-I inside screen via serial console and then switching
    to SSH as soon as network has been setup.

  + Running D-I inside screen via SSH and then loose the network
    connection and wanting to reconnect.

* The user should be informed if his D-I is running under screen to
  know that the Ctrl-A prefix is active. (Maybe the presence of the
  status line already suffices here.)

* What happens if the screen session ends?

* What happens if the user (accidentially) presses Ctrl-A Ctrl-X (e.g.
  locks the session). Maybe this should be added to the list of
  "stupid / dangerous key bindings" in

  (Yes, that will be my job, but I'd prefer to here some other opinion
  on this first before implementing it.)

> Please note I mostly disagree with the UI (= User Interface) changes it
> imposes on users. I'm fine with it being around for people who would
> like to have it, and maybe automatically started (see above); but the
> extra bar at the top is a big no for me. Cc-ing Christian to get his
> opinion on this matter as he's been taking care of “user interface vs.
> users” matters for a long time.

See my comment above. I think that this status bar is a very good way
to tell the user that his D-I is running in a screen session. If we
agree to get rid of it (which I don't recommend), we should make some
dialog pop up telling the user that D-I now runs under screen. This
could be also done, by enabling screen's startup message again in


Alternatively the hack to start window numbering with 1 instead of 0
could also be used to show an individual initial message.

> Also, I'm not sure whether we have any input methods which might be
> confused by ^A being “eaten” by screen. Does anyone know?

I (as package maintainer of screen) are not aware of any such issues.
But then again, I don't use any non-latin input methods other than the
compose key.

The most common usability issue is "Go to beginning of line" being
bound to Ctrl-A in Emacs and emacs-ish UIs like (b)ash in emacs-mode.
(But Ctrl-B of tmux or Ctrl-T of ratpoison isn't better: It's bound to
"cursor left" and "transpose characters" in most emacs-ish
applications. I definitely recommend to stay with Ctrl-A if there are
no real input-method blockers.)

		Regards, Axel
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Reply to: