We probably back it into the wrong box.

*** Bug 708323 has been marked as a duplicate of this bug. ***

I've done a few experiments to see how we can fit in a banner with everything else on screen. It becomes a bit difficult with the user list and the distributor logo.

There are probably three options here:

 1. Ensure that the banner scrolls if there isn't enough space for it, and maybe adjust its placement depending on the height of the list and the presence of a distributor logo.

 2. Force the user list to off when a banner is enabled.

 3. Force the user list to off when there is a banner and a distributor logo.

Created attachment 256162 [details]
mockup experiments

A couple of visual experiments.

not that my opinion matters much, but those look nice to me!

I agree those look very nice. However, can the banner text be displayed on top?

(In reply to comment #6)
> I agree those look very nice. However, can the banner text be displayed on top?

Why? Please explain if you have any issues with the design.

I did try having the banner text above the login, but found that it threw the screen off-balance.

I work for the government, DOE, and the first thing they want the users to see is the government banner. And if at all possible disable the user list.

login-screen is split in two parts :  

 the user list, banner etc...
and
 the authprompt for name and password

The code for the banner is actually only in the first part.

Waiting for design decision to add it to second part

( and after Bug 703107 - User list > login screen transition is commited,
 because before patch in bug 703107, we have a different layout in both parts )

Alan, it's in your hands, and actual design ( i mean code ) is with banner on top, not bottom like in the mockup.

See procedure in  Bug 708323 to make it appear.

i looked into this off and on the last couple of days and have a patch i'll post.  I actually found it really hard to place the message centered between the user list and bottom of the screen, while adding scrollbars when necessary.
I sort of got the behavior I wanted by laying out the login screen to use an StTable and nested box layouts.

I think, though, maybe a better approach is a custom layout manager, though I haven't investigated doing that sort of thing here, yet.

Created attachment 259235 [details] [review]
loginDialog: display banner message when disable-user-list=true

The login screen supports showing a banner message which admins
can use to mention login rules or disclaimers.

This message only shows up currently if the user list is enabled.
Most people who want to show a banner message also want to disable
the user list.

This commit moves the banner message to display when prompting to
the user instead of when showing the user list.

It also moves the banner to a more aesthetically pleasing location
on screen, and adds a scrollbar if the message is too long.

Review of attachment 259235 [details] [review]:

::: js/gdm/loginDialog.js
@@ +447,3 @@
+        this._authPrompt.actor.y_expand = false;
+        table.pack(this._authPrompt.actor, 0, 0);
+        table.set_span(this._authPrompt.actor, 1, 3);

Ah, I was wondering how you would achieve centering using a table ...

However, there's a serious regression here: as you add authPrompt and userSelectionBox first, the banner (with the reactive ScrollView) now overlaps them partially and blocks events - "Not listed?", "Sign in" etc are only reachable by keynav, but no longer respond to clicks.

Either reorder the code appropriately, or do something like

  this.actor.set_child_above_sibling(this._userSelectionBox, null);
  this.actor.set_child_above_sibling(this._authPrompt.actor, null);

at the end of the function.

A small comment would be good as well I guess, to avoid this trap in the future.

I think I'll look into using a custom layout manager instead of using this.  I'm not sure happy with the way the code looks.

I am in the process of configuring systems using GNOME 3.12 for use by engineers on a United States Government contract. We are required by NIST Special Publication 800-53A, Appendix F-AC, Section AC-8.1 to provide a login banner to users accessing the system. Appendix F-IA, Section IA-5 contains the guidelines that eventually lead to disabling a user list, even though it isn't specifically stated in those items.

Not being able to display a login banner while disabling a user list makes GNOME 3 unusable for secure United States Government use.

Created attachment 290734 [details] [review]
loginDialog: allocate children manually

The login screen is pretty custom full screen container and the standard
layout managers aren't really a good fit for the kind of layout that's
happening. This will be even more problematic with upcoming changes
to login banners, so we need to switch techniques.

This commit moves login dialog over to using a custom allocate handler
that has specific domain knowledge of the parts of the login screen
and where they go.

Created attachment 290735 [details] [review]
loginDialog: display banner message when disable-user-list=true

The login screen supports showing a banner message which admins
can use to mention login rules or disclaimers.

This message only shows up currently if the user list is enabled.
Most people who want to show a banner message also want to disable
the user list.

This commit moves the banner message to display when the user is
prompted for login credentials instead of when showing the user
list. It also adds a scrollbar if the message is too long.

Created attachment 290736 [details] [review]
loginDialog: use two column view if banner message long

Frequently banner messages are longer than can reasonable
fit in a one column view, which leads to a smooshed layout.

This commit changes the layout to a two column view, with the
banner on the left and the prompt on the right, if the banner
message is long enough that it can't fit well above the prompt.
If there isn't enough space for two columns then we keep the
one column layout but add scrollbars.

These are the patches I came up with for RHEL.

attachment 290734 [details] [review] switches the layout logic to happen in an allocate handler.  I think that's more appropriate for this kind of custom layout rather than abusing tables.

attachment 290735 [details] [review] makes the banner message show up when asking for the password, instead of at the user list.  This makes more sense, since there's more room on screen then and almost everyone who wants this feature also wants the user list disabled.

attachment 290736 [details] [review] makes the screen use an alternative layout if the banner messages is a full legal tome, in an effort to prevent squashed views with scrollbars.

Review of attachment 290734 [details] [review]:

Can you use a custom ClutterLayoutManager?

I thought about it (see comment 13), but after thinking about it, I decided it wasn't the best idea.  Having a layout manager makes sense when it can be generic without a lot of domain knowledge of what's getting laid out. If I factored this, as is, into a layout manager then the layout manager would need to have specific domain knowledge of the items "add_banner, add_auth_prompt, etc". It would just add a chunk more boilerplate code, have the same allocate handler but moved to the layout manager instead.  There would be no real benefit.

Now what would be cool is a generic layout manager that could accommodate the layout needs of the login screen.  I did spend a little time trying to go that route, but it gets very complicated very quickly. It would be hard to write, hard to debug and add a ton more code.

Middle ground would be to modify one of the existing layout managers to be more flexible and a slightly better fit.  (maybe add a concept like GtkBox's "center widget" that got added in 3.12).  That would require getting changes into clutter and still some contortions in the shell code to do dynamic relayout when the banner gets big. 

I think having a custom allocate handler for specialized, very custom layouts is fine. It's the most concise way to achieve the desired result, and there's a bunch of prior art in the shell source already.

I've gone ahead and pushed these. If we end up doing follow up changes, no biggie.

Attachment 290734 [details] pushed as 522fe8e - loginDialog: allocate children manually
Attachment 290735 [details] pushed as 117a81e - loginDialog: display banner message when disable-user-list=true
Attachment 290736 [details] pushed as 7b9be21 - loginDialog: use two column view if banner message long

What released version was this fixed in? I'm using Fedora 21, with GDM 3.14.1-2.fc21, and I can successfully set a banner message with /etc/dconf/db/gdm.d/01-banner-message, but as soon as I set disable-user-list to true, the banner disappears as well.

It's not in a stable release yet, it was first included in 3.15.3, so the upcoming 3.16/F22 will have it.