Hello KDE Neon Users,

I have following situation: At work i need to build a new workspace os image.
The look and feel of KDE Neon seems to be my favorite so far. But there is an issue i need to resolve before finally deciding.

Because the workstations are connected to to an NFS share with kerberos/etc, there are >1000 users that could log in to one machine. The default desktop manager (SDDM) with the default theme only shows user icons. I don't want that.

Other themes offer the ability to type in the username but they don't fit the look of KDE Neon.

Is there a way to have an input box for the username in SDDMs default theme?

Sincerely
Daniel Laube

Under System Settings, You can select/download themes
for sddm. At least one of them seems to offer a text field
for user name. There are pictures but they are to small
for my eyes and magnifying doesn't help, too.

Nowadays, software is made by children for children.
If You get older than 40, 50, 60 years, Your eyes will hurt.
But nobody cares. That's life…

@dlaube

I recommend, You better don't use KDE neon
in a bigger network where You have to administer
several KDE Neon Users.

The Package DataBase is inconsistent. If You query
for available packages with the APT tools, You'll
get wrong answers. If You as sysadmin base your
decisions on this wrong data, people will make
You responsible. You are not. But, nonetheless…

Additionally, they save repository files in non-standard
locations. For example the 'Contents-amd64.gz' is in
the wrong directory not compatible with the APT tools.
It belongs one directory up.

The output of aptitude is often misleading because You can't
easily distinguish the archives of origin.

If You search for available versions, You have to distrust everything
and check and recheck.

For a single desktop user, who doesn't know what a command line is,
that may be fine. But otherwise, it's a nightmare.

I realized all this in September when I installed KDE Neon.
First thing I did, was checking their package management,
like I always do with a new Unix/Unix-like Distribution.
I wanted to see, how they integrated the KDE and Ubuntu
parts, and maybe learn a thing or two. But what I saw was
not as professional as I had hoped. But I thought: Give them
time. They are doing something new.

It's a great idea. Ubuntu LTS is a stable base. KDE Plasma is excellent.

But KDE Neon's integration of the two tends to break the nice, stable
Ubuntu LTS and its admin package tools.

When I installed KDE neon last year, I thought they would fix this
one step after the other.

But now I think, they don't know how to do it.
It looks a bit like copy-and-paste development to me.
It's rather sad.

Because the plan/concept/idea of KDE Neon is right/excellent.

They should have taken Debian as a base. Then they would have
had a community that knows what they are doing.

As I already mentioned: It makes me sad.

If I had worked like them for over a year in my computer jobs,
I would have been 'replaced'.

Only thing one can do: Let's wait and see.
I appreciate their effort and I think they do hard work.

dlaube wrote:Because the workstations are connected to to an NFS share with kerberos/etc, there are >1000 users that could log in to one machine. The default desktop manager (SDDM) with the default theme only shows user icons. I don't want that.

Plasma's breeze theme for SDDM does allow to switch to a username text input field (without showing icons), and it should actually switch to that automatically if more than 7 users are available. (the threshold can be changed via the DisableAvatarsThreshold option in /etc/sddm.conf)

Displaying the user icons can also be disabled completely via EnableAvatars=false.
I think the breeze theme should switch to showing a username input field then, but I'm not completely sure.

The mentioned options were introduced in sddm 0.14.0, I don't know which version is in KDE Neon.

"Displaying the user icons can also be disabled completely via EnableAvatars=false."

Seems wrong.

Because:

`EnableAvatars=`
When enabled, home directories are searched for ".face.icon" images to
display as their avatars. This can be slow on some file systems.
When disabled, all avatars will be default. Themes may choose to hide
them altogether.
Default value is true.

Source of info:

https://github.com/sddm/sddm/blob/devel ... onf.rst.in

Breeze Text Only SDDM theme

The userlist can be easily disabled and the username text filed enabled from the standard KDE Breeze SDDM theme. Main.qml:



An example from the KDE Store: https://store.kde.org/p/1186478/ .



Preview clip: https://youtu.be/mFd7DXGi8Kw .

NoNameNoBlame wrote:"Displaying the user icons can also be disabled completely via EnableAvatars=false."

Seems wrong.

Have you actually tried it?

Because:
...
When disabled, all avatars will be default. Themes may choose to hide
them altogether.

Note the last sentence.

As I wrote, I think the breeze theme will switch to a username text input field in that case.
And it definitely does this if there are more users than the DisableAvatarsThreshold value.

You write:

###

Themes may choose to hide
them altogether.

Note the last sentence.

###

I noted it when/before I posted it.

Does this 'last sentence' make Your seemingly wrong statement any more true?
Please, explain Your logic more explicitly. May be entertaining…

By the way: I don't state anything. I only quote the developers' words.
And I think, THEY say You're wrong.

Because Theming is necessary. Regardless of the option's value.
The option's value is irrelevant (according to the developer's words, not mine.)

Now, You contradict the developers' own words. Why?

NoNameNoBlame wrote:Does this 'last sentence' make Your seemingly wrong statement any more true?
Please, explain Your logic more explicitly. May be entertaining…

Easy:
"Themes may choose to hide them altogether"
*can* mean that the breeze (or any other) theme would also be able to choose to show a username text input field instead.

By the way: I don't state anything. I only quote the developers' words.
And I think, THEY say You're wrong.

Not really.

Because Theming is necessary. Regardless of the option's value.
The option's value is irrelevant (according to the developer's words, not mine.)

You are wrong here.
Because the theme can choose what to do according to the option's value, AIUI.

Now, You contradict the developers' own words. Why?

I don't.
You do apparently...

I still don't get Your point completely:

You write:

You are wrong here.
Because the theme can choose what to do according to the option's value, AIUI.

###

Now, I'd say:

Of course the theme can choose. Because it can completely override the Avatar-options.
It can make them irrelevant. And if You don't want to see Avatars, the theme even _has_to_
override the option (by not reading it, or by not using it, or by not offering a place for
avatars in its interface design).

Are we saying the same thing here? For me it's different.

###

Thanks for answering.

NoNameNoBlame wrote:Now, I'd say:

Of course the theme can choose. Because it can completely override the Avatar-options.
It can make them irrelevant.

That's a completely different story though.

The point is that the sentence basically says, the theme can choose to not display avatars at all *if* that option is set to false.

If the theme ignores the value, it won't respect it of course.
But that doesn't invalidate my point.

And if You don't want to see Avatars, the theme even _has_to_
override the option (by not reading it, or by not using it, or by not offering a place for
avatars in its interface design).

No. It just has to respect that option, AIUI.

Actually your point here doesn't make sense really, I think.
How would you tell the theme then that you don't want to see Avatars?

"How would you tell the theme then that you don't want to see Avatars? "

By not including any in the theme's definition.

NoNameNoBlame wrote:"How would you tell the theme then that you don't want to see Avatars? "

By not including any in the theme's definition.

That would be the theme's (or its author's) decision then though, not *yours*. (unless you modify the theme of course, which would basically make *you* the author actually...)
You wrote "if You don't want to see Avatars".

If the theme has a configuration interface,
I'd choose it in system settings.

If the theme developer didn't provide one,
I'd edit it by hand:
a) Comment out Avatars
b) Insert <Username>-InputField.

Edit:
Or I'd choose a theme that offers no Avatars at all, right from the start.

NoNameNoBlame wrote:If the theme has a configuration interface,
I'd choose it in system settings.

AFAIK, themes cannot provide a special "configuration interface".

If the theme developer didn't provide one,
I'd edit it by hand:
a) Comment out Avatars
b) Insert <Username>-InputField.

And we're back again at modifying the theme.

Of course, that would work in any case, but is unrelated to my statements.