So the session restores now that you have the patched gnome-session installed and blocaled removed? What you wrote wasnt clear to me so please confirm.

On a related note about startup delay: I have seen gnome take a minute or two to start up, if the system-tray extension isn't installed. What happens in slackware is that the xdg-autostart system tries to start hplip and whatever else daemons at login, but these hang the system for a few minutes because no system tray is found. I dont know why gnome removed the system tray, but you can add one back in with an extension. This is the one I use: https://extensions.gnome.org/extensi...cator-support/

If you dont have that extension installed then please try it out and see if the gnome session starts faster.

I cannot confirm if have something connected with blocaled usage, because right now I observed the behavior.

So, with that particular option activated via DConf, when you login to GNOME, it shows the desktop. It's functional desktop, where you can start programs imediatelly.

This time, doing something else, I leaved alone the computer several minutes after login. AND, it restored the session (Firefox and SMPlayer - I tested with the famous Big Bunny) as should do it. BUT, not immediately.

I will try.

BTW, what version I should download? I seen that you queue is a mix of 41 with 42.

I just install the browser extension and toggle the on/off switch on that page to install the extension automatically. I attached a screenshot to show what I mean.

The version that it installed is 42, if you choose to do it manually.

BTW, I just tried that dconf editor setting and restoring a session in wayland happened immediately on login. On X11 it seems to be slower. I'm not sure why yet.

Attached Thumbnails

 

Well, I for one, I was habituated with gnome-extensions - that's why I asked about the compatible version.

Still, my session restoring is delayed. Time to check the installation.

EDIT: Nope, no fish in this pound. Tomorrow I will do a full rebuild.

Something I just found that is interesting:

My laptop restores the session instantly, in either wayland or Xorg modes. My desktop on the other hand has a delay of a minute or so before restore. The desktop can only do Xorg, wayland isn't supplied as an option, due to gnomes udev rule for its nvidia card.

The only other difference between the two installs is that the desktop is using pipewire, the laptop pulseaudio. The delay seems to me like some asynchronous dbus sh*t is going on and somethings waiting for comminication. We have pipewire starting via xdg autostart, which does give it a delayed start with respect to the rest of the session. I wonder if this would make a difference.

Maybe I'm grasping but are you running pipewire by any chance? Could you test switching back to pulse? I appreciate all the testing you've been doing

Tomorrow. Now is very late for me - think that I'm somewhere right in far north of Poland. Or Germany. I think it's Poland. Anyway, is near of the east of Finland.

And yes, I use exclusively the Pipewire.

The build succeeded in around 27 hours, but I did not used a way to maximize the compilation power by using runlevel 3. While compiling, I leaved open the Plasma5 and I did some small browsing, visiting LQ and news sites.

1 members found this post helpful.

So, I switched to PulseAudio server, no changes. Looks like the used audio server does have no impact to this issue.

I also did a new build, in a system fresh installed and then updated with the packages from /patches. Also no changes.

This also apply to the Terminal issue, but this is rather obnoxious, because anyway I use a custom color set, which I use to set immediately after the first start of desktop.

However, I would have loved to have a functional session restore, because I have the habit to leave open a series of applications, to be reopened after the next desktop login. And yes, I do the same also in Ubuntu and also in Slackware with its Plasma5.

1 members found this post helpful.

Great!

I can ask you IF you observed something strange with the Gnome Terminal?

See for reference the Terminal issue described in my other posts.

1 members found this post helpful.

Thanks!

Yes, it does the same. It's like it's undefined the background color.

On both my systems, the gnome session starts faster when pulseaudio is used (tray icons appearing and firefox restoring quickly). Using pipewire works, but takes up to a minute for the session to completely start. I'm still looking into whats going on with that.

The restore function enabled in dconf-editor only seems to work with firefox from what I have tested, but it does work for that. I'll probably just leave it disabled, since it doesnt seem too useful as is. I have tried the gnome versions in fedora and artix and dont recall them having that functionality by default. I guess I'll have to download and try ubuntu one of these days to see what they all do to modify gnome.

I'm not sure what to make of your gnome-terminal problem. I am using that same gnome build, built against slackware64-15.0 and the latest patches. Gnome terminal appears fine and follows the light/dark theme from the gnome shell as expected. I tried in a few other locales just to make sure and nothing unexpected happened with its appearance. The themes in gnome-terminal also work as expected for me. Did you try a fresh user account? I had some gtk configs from plasma that messed up gnome's themes when I tried it with my old plasma user account. I had to clean up some of the old dotfiles that were left behind.

1 members found this post helpful.

I think the pipewire issue is due to the xdg autostart system starting all three pipewire daemons at the same time. These daemons depend on each other and should be started in the order of pipewire, then pipewire-pulse, then pipewire-media-session. I tried a test where I removed the three autostart entries for pipewire and replaced it with a single entry that runs a script containing:
This still gets pipewire started, with the gnome session, restore, and tray also appearing quicker, just like with pulseaudio. I suspect its to do with the respawning that daemon is set to use. If the pipewire daemons are started in the wrong order they can fail which would trigger respawning from daemon.

1 members found this post helpful.

Yes, I confirm that this delay on session restore is generated by the way are started the PipeWire daemons. In fact, looks like they works well with removing the --foreground / -f option of daemon(s) on .desktop files, like

This setup of PipeWire daemons also work well with Plasma5, then I believe that should be proposed in the requests thread.

In other hand, I can confirm that the Terminal issue was generated by the Plasma5 local generated files (I think). Even when I created a brand new user account, ironically I started first the Plasma5 on this account, then I seen no differences. Go figure!

On a clean user account, the Terminal non presents that console issue.

2 members found this post helpful.

For my shame, also myself I used a "dirty" account. Seems like the Terminal has a correct behavior in a new created account.

1 members found this post helpful.

I just tested removing the -f option from the daemon/pipewire lines as you suggest and can confirm that also starts the session as fast as the other solution I posted about.

I'm not an expert on that daemon program (honestly I've only looked at its man page this week). Was there a good reason that the -f option was used? I can make the request, but I'm not certain on what is happening to cause it to start so slow with the current setup using that option.