xdm looks ugly be default because it does not have a background color set. I
propose that the default Xsetup_0 file come with the background color set to
black by putting this in the file:
/usr/X11R6/bin/xsetroot -solid black
Now, instead of those confusing gray lines, you get a nice black background.
This is not a bug but a feature.
I think that means the severity should be changed to enhancement, rather than
resolving the bug altogether.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
I've made a little improovement: password can be echoed with asterisks. This feature can be enabled in Xresource file by adding line 'xlogin*echoPasswd: true'. The default value is false.
The whole widget borders width could not be set to zero. This 'bug' was fixed.
There are two patches:
1) diff -u ...: http://files.mail.ru/cgi-bin/files/fdownload?id=64537576
2) diff -c ...: http://files.mail.ru/cgi-bin/files/fdownload?id=64537561
I want to make more improovements. Todo:
1) transparency support
2) support utf-8 string in welcome messages
Sorry, wrong links
I was just about to close this bug actually as not being necessary now
that Xorg starts with black root by default.
Adding an option to show stars is something I've thought about but never
had time to tackle - however, your patches seem to be reversed, and against
the original 1.1.8 sources, and I can't tell what the difference is between
the two patch files, as they seem to have some of the same changes in.
I'm about to release 1.1.9, but patches are preferred against git master,
in git format-patch format when possible, as described at:
Attributions of who added what should be done in the git history, not the
source code (xdm unfortunately has some bad examples there that need to be
Please use the bugzilla attachment mechanism to post them or mail them to
the list instead of hosting on another site that may delete them before
someone gets a chance to apply (and which has instructions that at least
I can't read).
Created attachment 29756 [details] [review]
patch in git format
Created attachment 29780 [details] [review]
Patch for just the echoPasswd option
Thanks. I've split this into multiple parts for easier review.
I pushed the simplest one to git master already - the zero framewidth fix:
I dropped all the formatting/style changes, especially the ones that made
the new code not match the existing code (while we can debate which style
is best, mixing different styles inconsistently in the same code is
definitely worse than any single style), and have attached a patch showing
the remaining changes still needing review.
At first glance the changes seem mostly reasonable, though I'll need to
take a closer look still. We'll need to add documentation of the
"EchoPassword" option to the man page, and I'm wondering if a better name
for the user option would make it sound less like it's echoing the actual
I'm not sure about the changes to greeter/greet.c - setting the prompts to
username and password before PAM prompts for them violates the PAM
conversation design, and since the "not shown" flag is there, I don't see
what the point is. I'd also rather handle the echo_passwd option check
in Login.c itself, instead of in the PAM specific logic, so we don't have
to modify all the different authentication methods (since I can't test all
of them myself).
Created attachment 30103 [details] [review]
adding an utf8 support in messages; echoPasswd option is checked now in Login.c
Created attachment 31868 [details] [review]
adding documentation of 'echoPasswd' option to the man page
Created attachment 31874 [details] [review]
xdm: Adding an option to show stars instead of the password itself.
xdm: The behaviour can be controlled via 'xlogin*echoPasswd' option
xdm: in Xresource file. The default option value is 'false'.
Created attachment 31875 [details] [review]
Adding utf8-support in all prompt-/greeting-messages
Hi. What's up with this patches? :)
I've been busy at work getting our spring distro release completed and
haven't had time to look at them until now.
I've applied the first two, with some formatting changes, though I'm also
working on a followup patch to improve things.
I don't understand why the third patch is necessary, but as this bug has
already gone way beyond what it's described as, I'm closing it as fixed.
Please feel free to open new bugs for new patches, with more description,
such as explaining why narrowing the character sets supported by Xft from
all 8-bit charsets to just UTF-8 is an improvement.