<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 19, 2016 at 10:23 PM, Martin Bammer <span dir="ltr"><<a href="mailto:mrbm74@gmail.com" target="_blank">mrbm74@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I was playing around with extending and fixing some bugs in the usermanager. One<br>
of the bugs I would like to get fixed is setting the avatar for users.<br>
As I've seen in the code changing the avatar does not check for which user the<br>
avatar was changed. It always changes the avatar of the currently logged in<br>
user. Fixing this would mean either disable the possibility to change other<br>
user's avatar in the GUI (the easier solution) or to take care which user's<br>
avatars were changed and write the temporary files to the correct destination.<br>
As long as the home directories are not encrypted this could be done with root<br>
rights. In case of encrypted homes every user, which avatar was changed, would<br>
have to enter his password after clicking the Apply button. Not a nice solution.<br>
<br></blockquote><div>Yeah, we've got an open bug on that.<br></div><div>I've just made a patch for KUser which will allow us to get rid of saving into ~/.face </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In addition the avatar is not set for the login manager. As I've seen in the<br>
sources SDDM is just ignoring the avatars in the folder<br>
/var/lib/AccountsService/<wbr>icons. So adding this search folder as the primary<br>
source would be a good idea. Then it does not matter if the homes are encrypted<br>
or not.<br></blockquote><div><br></div><div>SDDM has a patch pending for using AccountsService<br></div><div>It should be in 0.15<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Some additional features I would like to have:<br>
- Selecting user's groups, like it is possible in Mint.<br>
- An option to show the home's encryption key. Currently the user has exactly 1<br>
chance to write down his encryption key. Later he has to google how this can be<br>
done and has to use the command line for this. Not user friendly.<br>
- An option to easily enable/disable home's encryption. Currently only the first<br>
user who installs the system can enable the encryption for him in the installer.<br>
But for every new user who want to have an encrypted home the command line is<br>
needed.<br>
- Maybe also an option to choose the user-id and group-id for new users. The<br>
current implementation has IMHO a design problem: The first user gets id 1000<br>
(on Debian based systems, on RedHat based systems 500). The second 1001 and so<br>
on. But what if we have a small home network where everyone has it's own<br>
machine, thus different users have the same id? Problems arise when sharing with<br>
NFS or when using external drives with a Linux FS. My suggestion would be to<br>
calculate hash values out of the user and group names to get the ids. Not<br>
perfect, but much better than the current implementation. But this is a topic<br>
for the base system and not for the usermanager.<br>
Here a screenshot how this could look like:<br>
<br>
<br>
Your suggestions are very welcome.<br>
<br>
Best regards,<br>
<span class="HOEnZb"><font color="#888888"> <br>
Martin Bammer<br>
<br>
</font></span></blockquote></div><br></div></div>