Re: Screen support (was: Next d-i alpha release: late June)
Hi,
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
it):
* 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.
Examples:
+ 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
https://anonscm.debian.org/cgit/collab-maint/screen.git/tree/debian/udeb/screenrc#n20
(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
https://anonscm.debian.org/cgit/collab-maint/screen.git/tree/debian/udeb/screenrc#n7
Alternatively the hack to start window numbering with 1 instead of 0
(https://anonscm.debian.org/cgit/collab-maint/screen.git/tree/debian/udeb/screenrc#n53)
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: