Ticket #158 (closed enhancement: fixed)

Opened 15 years ago

Last modified 14 years ago

distinguish cluster from workstation machine on login screen

Reported by: wdc Owned by: geofft
Priority: low Milestone: Fall 2009 Release
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description

This has been variously discussed in email and zephyr, but never raised as an official enhancement request.

The greeter should, if possible, display what kind of system this is:

workstation
cluster

etc. We are getting this stuff in athinfo. It is a challenge to display it, but probably worth doing.

I'm not sure what priority to give this. For now, I'll classify it as a "major" enancement because I believe it will have a good sized usability impact going forward.

Change History

comment:1 follow-up: ↓ 2 Changed 15 years ago by geofft

One simple way to accomplish this would be for -login-graphical to provide a /usr/share/gdm/themes/debathena/version.png that says e.g "Debathena with Athena logins", -workstation to divert it to a .png saying "Managed private Debathena workstation", and -cluster to divert it again to say "Standard Debathena cluster workstation" (those names probably need some work, and we probably also want to put the literal metapackage name in smaller letters there).

This has the side effect of making debathena-gdm-config depend on debathena-login-graphical. I don't know if this actually makes anyone sad, but we can work around it by having it include an "Unknown Debathena version" .png or something silly.

comment:2 in reply to: ↑ 1 ; follow-up: ↓ 4 Changed 15 years ago by broder

Replying to geofft:

One simple way to accomplish this would be for -login-graphical to provide a /usr/share/gdm/themes/debathena/version.png that says e.g "Debathena with Athena logins", -workstation to divert it to a .png saying "Managed private Debathena workstation", and -cluster to divert it again to say "Standard Debathena cluster workstation" (those names probably need some work, and we probably also want to put the literal metapackage name in smaller letters there).

Eww. Is there any way to do that that doesn't involve a version.png.debathena.debathena.debathena? I generally don't like stacking diversions. What if we divert and wrap the gdm initscript to choose which image to use when GDM starts?

comment:3 Changed 15 years ago by jdreed

  • Priority changed from major to minor
  • Milestone set to Fall Release

comment:4 in reply to: ↑ 2 Changed 15 years ago by geofft

Replying to broder:

Replying to geofft:

One simple way to accomplish this would be for -login-graphical to provide a /usr/share/gdm/themes/debathena/version.png that says e.g "Debathena with Athena logins", -workstation to divert it to a .png saying "Managed private Debathena workstation", and -cluster to divert it again to say "Standard Debathena cluster workstation" [...]

Eww. Is there any way to do that that doesn't involve a version.png.debathena.debathena.debathena? I generally don't like stacking diversions.

Actually, yes... update-alternatives. Install /usr/share/gdm/themes/debathena/{login-graphical,workstation,cluster}.png and have them register as alternatives for /usr/share/gdm/themes/debathena/version.png, with increasingly higher priority.

It's not quite what the alternatives system was meant for (since we don't expect a local syadmin to repoint version.png at a smaller metapackage's label) but it definitely should work.

comment:5 Changed 15 years ago by geofft

  • Status changed from new to accepted
  • Owner set to geofft

I'm implementing what I proposed above. It'll also include the Ubuntu/Debian? version, because you can no longer tell the version due to the stock login screen.

Per discussion on Zephyr, I'll add debathena-{login-graphical,workstation,cluster}-branding or similarly named binary packages to the debathena-gdm-config source package, which already will include the "I don't know what this is" label. We'll also do SVGs instead of PNGs, because those are way more fun to programatically generate.

comment:6 Changed 14 years ago by geofft

  • Status changed from accepted to development

I finally did this in r24025 et seq.; it's probably worth testing a good bit, especially because I'm uploading it on top of gdm-config 1.14 (moving Pre/PostSession? to .d directories). I'm intending to put this on next5 and next6, but testing on non-cluster and probably non-Ubuntu things would be great.

comment:7 Changed 14 years ago by broder

  • Status changed from development to proposed

I did some extensive testing on gdm-config and reactivate, and they seem to work for me (including the actual upgrade path, which is a hack and a half), so I've moved them to proposed.

comment:8 Changed 14 years ago by broder

  • Status changed from proposed to closed
  • Resolution set to fixed

This is now in production.

Note: See TracTickets for help on using tickets.