While I'm +1 to this, I would like to know if these are created by a package. There is also an icon for each one of those, so it would be interesting to know if we include an icon package currently or if it's installed when a file browser is installed

These cannot be created by a rpm package during its installation phase, as =
rpm cannot touch anything under /home/=2E But it could be that a desktop en=
vironment creates these directories on first login=2E

On December 17, 2020 1:59:28 AM UTC, Eduard Lucena pagure@pagure=2Eio wr=
ote:

x3mboy added a new comment to an issue you are following:
While I'm +1 to this, I would like to know if these are created by a pack= age=2E There is also an icon for each one of those, so it would be interest= ing to know if we include an icon package currently or if it's installed wh= en a file browser is installed

To reply, visit the link below or just reply to this email
https://pagure=2Eio/i3-sig/Fedora-i3-Spin/issue/26

it would be interesting to know if we include an icon package currently or if it's installed when a file browser is installed

If I remember right, these directories and images come from the gnome-shell or the file manager, like Nautilus. I'd have to double-check to be sure though, it has been some time.

I'm in favor of a handful of default directories:

• Documents
• Downloads
• Music
• Photos
• Videos

Since there is no desktop, we don't need Desktop. Since we are not shipping a Samba configuration or a WebDAV directory setup, we do not need Public. I am ambivalent about Templates since it depends on the file manager you use.

I'm with @jwflory7 here, but I'd suggest a online accounts centric Folder created for those wishing to connect as a mount point. Not a full on WebDAV but similar (thining more a sshfs style directory)

@linuxmodder What about ~/mnt/? I think it is neutral enough where it could fit a number of use cases for external or remote media.

https://src.fedoraproject.org/rpms/xdg-user-dirs

https://wiki.archlinux.org/index.php/XDG_user_directories

should be able to use this to create user directories

• edit: i believe icons is gtk / file manager specific though

We'd need to run that on first login for every new user though?

My understanding is that we need to run xdg-user-dirs-update on the kickstart file so the directories appear in the live image. But this is tricky because we need to modify the default i3 config in order to get this to persist for all users.

I suggest pushing this to Fedora 35. Our main focus for F34 is to build a basic i3 Spin using existing packages. We could add a custom patch to Fedora's i3 package with the help of @defolos, but we need to come up with a workflow of deciding when to upstream a change and when to carry a downstream patch.

Ideally we upstream changes wherever possible; it is the Fedora way.

Thoughts on postponing to F35?

Justin W. Flory pagure@pagure.io writes:

jflory7 added a new comment to an issue you are following:
` My understanding is that we need to runxdg-user-dirs-update` on the kickstart file so the directories appear in the live image. But this is tricky because we need to modify the default i3 config in order to get this to persist for all users.

I suggest pushing this to Fedora 35. Our main focus for F34 is to build a basic i3 Spin using existing packages. We could add a custom patch to Fedora's i3 package with the help of @defolos, but we need to come up with a workflow of deciding when to upstream a change and when to carry a downstream patch.

Ideally we upstream changes wherever possible; it is the Fedora way.

It is highly unlikely that upstream will be interested in this. I think
we'll have to create our own config and ship it as fedora-i3-config or
whatnot.

Thoughts on postponing to F35?

+1 on postponing.

I think we are complicating this too much. We should create this directories only for the "main" user, or the user that is created in installation time. For every other user, it should be done manually.

@odilhao took an action item last week, if he said that we should postpone then +1, if not, let's try to pull this off.

Eduard Lucena pagure@pagure.io writes:

x3mboy added a new comment to an issue you are following:
``
I think we are complicating this too much. We should create this directories only for the "main" user, or the user that is created in installation time. For every other user, it should be done manually.

Then we just need to figure out what the name of the new user is and run
a post install script that runs xdg-user-dirs-update.

Can we create one script inside the /etc/profile.d/ that will look for a lock file on $XDG_HOME? If the lock file is not there the xdg-user-dirs-update runs, this would solve the issue for new users.

Odilon Junior pagure@pagure.io writes:

odilhao added a new comment to an issue you are following:
``
Can we create one script inside the /etc/profile.d/ that will look for a lock file on $XDG_HOME? If the lock file is not there the xdg-user-dirs-update runs, this would solve the issue for new users.

I don't think we should do that. This should be done by a script that is
preferably run by anaconda or by some other one-shot service, that
leaves no additional unpackaged stuff on the final
installation. Especially no shell script that messes with user's $HOME.

i believe that it is possible to make a systemd service for this. I believe gnome-shell does something similar. If you delete the directory, upon reboot it should be regenerated.

Pranav Sharma pagure@pagure.io writes:

sudopluto added a new comment to an issue you are following:
``
i believe that it is possible to make a systemd service for this. I believe gnome-shell does something similar. If you delete the directory, upon reboot it should be regenerated.

Indeed, we'd have to create a oneshot service that creates these
directories, put it into /usr/lib/systemd/user/, enable it in the user
presets and add it in %post via %systemd_user_post.

Discussed in 2021-02-23 meeting.

We decided to defer this to Fedora 35, since the Fedora 34 100% Code Completion deadline is today. I think the systemd oneshot service is likely the route we will go, but need to decide if we create a new package or go some other route.

Justin W. Flory pagure@pagure.io writes:

jflory7 added a new comment to an issue you are following:
``
Discussed in 2021-02-23 meeting.

---

We decided to defer this to Fedora 35, since the Fedora 34 100% Code Completion deadline is today. I think the systemd oneshot service is likely the route we will go, but need to decide if we create a new package or go some other route.

We should create a new package for this, so that users can remove it
easily via rpm/dnf and get the non-spin behavior back.

We should create a new package for this, so that users can remove it
easily via rpm/dnf and get the non-spin behavior back.

+1

We discussed this during today's meeting and the suggested idea was to add an invocation of xdg-user-dirs-update to the fedora branded i3 config. Thereby only the spin and newcomers will get this, but advanced users who ship their own config don't.

Any objections to proceeding that way?

Unless anyone screams real loud, I'll implement this change before the end of the week.

+1 go for it!

Well, it took me a while to get to this…

I have given this another try and encountered a tiny UX issue: if a user deletes any of the xdg directories, e.g. Desktop or Public, then xdg-user-dirs-update will not recreate that folder. It will instead reassign that folder variable (e.g. XDG_DESKTOP_DIR) to $HOME.

One can force the creation the of the directories in their default location via xdg-user-dirs-update --force but I don't think that we actually want that behavior. So I think we should go with a plain xdg-user-dirs-update as originally planned.

WDYT?

One can force the creation the of the directories in their default location via xdg-user-dirs-update --force but I don't think that we actually want that behavior. So I think we should go with a plain xdg-user-dirs-update as originally planned.

+1

This has been implemented a while ago