openbar icon indicating copy to clipboard operation
openbar copied to clipboard

[BUG]: theme not applies at startup?

Open droz76 opened this issue 1 year ago • 42 comments
trafficstars

Describe the bug theme does not apply at startup To Reproduce Steps to reproduce the behavior: restasrt os

Relevant Specs:

  • Open Bar version:
  • 36
  • Gnome version: -46
  • OS/Distribution:
  • fedora
  • Other installed extensions if interference is expected [Optional]:

Screenshots none no error but not applied? maybe I have something messed up..

droz76 avatar Jul 22 '24 14:07 droz76

Gnome automatically loads all enabled extensions at startup so this is unexpected. More inputs are needed to figure out what's wrong. After restarting:

  • Please check in Extension Manager app if Open Bar is enabled or was it disabled for some reason.
  • Does it show any error there in the manager app?
  • If enabled, try opening the Open Bar settings and changing something. Does it work?
  • You can also run the journalctl monitoring command and enable/disable Open Bar through extension manager to see if any errors pop up in the terminal. SHELL_DEBUG=all journalctl /usr/bin/{gjs,gnome-shell} -fo cat

neuromorph avatar Jul 22 '24 14:07 neuromorph

--checked extension manager. It is enabled at startup. -- no errors shown in the extension app --clicking the apply dark or light theme buttons do work. Changing backgrounds do work

I'm sorry if I do not understand... I am new to linux. I like the open bar look, but I have to apply it every time at startup..

I am running nobara 40..

Thank you..

SHELL_DEBUG=all journalctl /usr/bin/{gjs,gnome-shell} -fo cat meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed clutter_actor_insert_child_at_index: assertion 'child->priv->parent == NULL' failed meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed Received error from D-Bus search provider org.gnome.Terminal.desktop: Gio.IOErrorEnum: Cannot invoke method; proxy is for the well-known name org.gnome.Terminal without an owner, and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag Received error from D-Bus search provider org.gnome.Terminal.desktop: Gio.IOErrorEnum: Cannot invoke method; proxy is for the well-known name org.gnome.Terminal without an owner, and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag JS LOG: Characters Application started Received error from D-Bus search provider org.gnome.Terminal.desktop: Gio.IOErrorEnum: Cannot invoke method; proxy is for the well-known name org.gnome.Terminal without an owner, and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed JS LOG: Characters Application exiting Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.Failed: error occurred in AboutToShow

Stack trace: _promisify/proto[asyncFunc]/</<@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:453:45 @resource:///org/gnome/shell/ui/init.js:21:20

Promise created here:

sendAboutToShow@file:///usr/share/gnome-shell/extensions/[email protected]/dbusMenu.js:501:48 sendAboutToShow@file:///usr/share/gnome-shell/extensions/[email protected]/dbusMenu.js:198:22 _onMenuOpened@file:///usr/share/gnome-shell/extensions/[email protected]/dbusMenu.js:932:28 _callHandlers@resource:///org/gnome/gjs/modules/core/_signals.js:130:42 _emit@resource:///org/gnome/gjs/modules/core/_signals.js:119:10 open@resource:///org/gnome/shell/ui/popupMenu.js:984:14 _changeMenu@resource:///org/gnome/shell/ui/popupMenu.js:1407:17 _onCapturedEvent@resource:///org/gnome/shell/ui/popupMenu.js:1431:22 @resource:///org/gnome/shell/ui/init.js:21:20

SHELL_DEBUG=all journalctl /usr/bin/{gjs,gnome-shell} -fo cat meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed clutter_actor_insert_child_at_index: assertion 'child->priv->parent == NULL' failed meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed Received error from D-Bus search provider org.gnome.Terminal.desktop: Gio.IOErrorEnum: Cannot invoke method; proxy is for the well-known name org.gnome.Terminal without an owner, and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag Received error from D-Bus search provider org.gnome.Terminal.desktop: Gio.IOErrorEnum: Cannot invoke method; proxy is for the well-known name org.gnome.Terminal without an owner, and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag JS LOG: Characters Application started Received error from D-Bus search provider org.gnome.Terminal.desktop: Gio.IOErrorEnum: Cannot invoke method; proxy is for the well-known name org.gnome.Terminal without an owner, and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed JS LOG: Characters Application exiting Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.Failed: error occurred in AboutToShow

Stack trace: _promisify/proto[asyncFunc]/</<@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:453:45 @resource:///org/gnome/shell/ui/init.js:21:20

Promise created here:

sendAboutToShow@file:///usr/share/gnome-shell/extensions/[email protected]/dbusMenu.js:501:48 sendAboutToShow@file:///usr/share/gnome-shell/extensions/[email protected]/dbusMenu.js:198:22 _onMenuOpened@file:///usr/share/gnome-shell/extensions/[email protected]/dbusMenu.js:932:28 _callHandlers@resource:///org/gnome/gjs/modules/core/_signals.js:130:42 _emit@resource:///org/gnome/gjs/modules/core/_signals.js:119:10 open@resource:///org/gnome/shell/ui/popupMenu.js:984:14 _changeMenu@resource:///org/gnome/shell/ui/popupMenu.js:1407:17 _onCapturedEvent@resource:///org/gnome/shell/ui/popupMenu.js:1431:22 @resource:///org/gnome/shell/ui/init.js:21:20

droz76 avatar Jul 23 '24 07:07 droz76

I have to apply it every time at startup

So on startup, Open Bar is indeed enabled and settings can also be applied but you need to apply it manually. That should not happen. On startup, Open Bar itself generates and applies the style with a stylesheet.

  • On startup, when styles are not applied, do you at least have the stylesheet and assets at this location: /run/user/1000/io.github.neuromorph.openbar/ Note: the user Id '1000' in the path could be something else for you, that's fine.
  • Please share screenshot of how it looks on startup and how it looks after you apply the styles manually

I am thinking maybe the Open Bar stylesheet is not getting loaded at startup but not sure why that would happen.

I'm sorry if I do not understand... I am new to linux

No worries. It was about getting the log that you already shared. Though it does not show anything relevant for Open Bar.

I like the open bar look

Thank you, hope the issue reveals the cause so you can have a seamless experience.

neuromorph avatar Jul 23 '24 09:07 neuromorph

i'm having the same problem on ubuntu, the extension used to work flawlessly but suddenly it stopped working at startup, i have to turn off and turn on the extension everytime i turn on the computer

homiebriu avatar Jul 27 '24 06:07 homiebriu

I was having this issue too and managed to fix it by disabling some extensions:

  • user-theme
  • unlockDialogBackground

So issue may be conflicts with other extensions.

Relevant Specs: OS: Ubuntu 24.04 Open Bar: Version 36

amyvibritannia avatar Jul 27 '24 07:07 amyvibritannia

Thank you for the update guys!

I would certainly like to fix the issue but I am not able to reproduce it and I am also on Ubuntu 24.04. Thus, it is likely to do with particular setup including other installed extensions that may have some conflict as mentioned by @amyvibritannia . In this case, what maybe be happening is that on startup when Open Bar is enabled, it applies the styles but they are then overridden by some other extension afterwords. Gnome has its own way of deciding the order in which extensions are enabled at startup.

Can you all try it with other extensions disabled and see if the issue persists. If that fixes it then we can try to find which other extension has conflict. I was using "user-themes" extension earlier without issue but not using anymore, currently all shell/Gtk theming is through Open Bar. I have never tried "unlockDialogBackground". I will also give them a try to see if it can be replicated but ideally they should not cause this.

Let me know if you find ways to reproduce it as in with a specific other extension or maybe with some other configuration that you maybe using. In case of user themes, is it for a specific theme or all user themes?

Thanks.

neuromorph avatar Jul 27 '24 09:07 neuromorph

Same here, and I tried disabling most of my gnome extensions but still I cannot find one that conflicts and make OpenBar not work... Currently running GNOME 46 (with X11 and Mutter) on Arch 6.10.2 For now I patched it with a simple bash script running at startup:

#!/bin/bash

# ----------- DECLARATION ----------- 
# Define log file
LOG_FILE="$HOME/startup-fix.log"
# Define sleep time amount in seconds
RETRY_SLEEP_TIME=15

restart_gnome_openbar_ext() {
	# Run the commands
	echo "Open Bar extension restarting..."
	gnome-extensions disable openbar@neuromorph
	gnome-extensions enable openbar@neuromorph	
}

# ----------- EXECUTION -----------
# Clear log file
> "$LOG_FILE"

# Redirect stdout and stderr to log file
exec > >(tee -a "$LOG_FILE") 2>&1

echo -e "Time: $(date)\n#-- -- --#"
echo "First attempt to restart OpenBar extension"
restart_gnome_openbar_ext

echo "Sleeping for $RETRY_SLEEP_TIME before last attempt"
sleep $RETRY_SLEEP_TIME

echo "Last attempt to restart OpenBar extension"
restart_gnome_openbar_ext

echo "Startup OpenBar GNOME extension fix completed."

For me 15 seconds is good amount to wait since the first attempt to restart the extension doesn't make it, change it if needed.

But it would be really nice to find out what is causing the problem with Open Bar not loading / getting overwritten by other changes...

Sh04Un avatar Jul 31 '24 17:07 Sh04Un

Actually found a faster way of patching this till the bug is found and fixed, using a lightweight package like xdotool that simulate user inputs in CLI and sleeping way less than the previous script (also checking XDG to see if the desktop session is fully started)):

#!/bin/bash

# ----------- DECLARATION ----------- 
# Define log file
LOG_FILE="$HOME/startup-openbar-gnome-ext-fix.log"
# Define sleep time amount in seconds
ATTEMPTS=0
MAX_RETRIES=15

restart_gnome_openbar_ext() {
	# Run the commands
	echo "Open Bar extension restarting..."
	gnome-extensions disable openbar@neuromorph
	gnome-extensions enable openbar@neuromorph	
}

# ----------- EXECUTION -----------
# Clear log file
> "$LOG_FILE"

# Redirect stdout and stderr to log file
exec > >(tee -a "$LOG_FILE") 2>&1

echo -e "Time: $(date)\n#-- -- --#"

# Check if gnome-shell is running and desktop is fully loaded
echo "Checking if XDG is fully loaded"
until [[ "$XDG_CURRENT_DESKTOP" == *"GNOME"* ]]; do
	echo "Start check for XDG.."
	if [ $ATTEMPTS -eq $MAX_RETRIES ]; then
		echo "Stopping GNOME wait loop as max retries limit has been reached"
		break
	fi
	
	echo "Waiting for GNOME Shell to start (attempt $ATTEMPTS)..."
    	sleep 1
    	((ATTEMPTS++))
done

sleep 2
echo "Exiting GNOME overview with Super key"
xdotool key Super
echo "Attempt to restart OpenBar extension"
restart_gnome_openbar_ext
echo "Startup OpenBar GNOME extension fix completed."

GNOME (at least 46 version) start from the "Overview" mode (like when you press Super key, it shows the Dock), I found out that if Overview mode is exited you can straight disable and enable the extension and it will work, while the previous script failed if it wasn't sleeping for at least 15-20 seconds (this one only sleep two seconds to ensure full initialization)

In the few tests I made this works flawlessly both on logout and on restart so it seems more reliable and even faster

EDIT: An alternative to using xdotool key Super in the script above is to use Just Perfection GNOME extension that allows you to start GNOME session directly on desktop instead of overview mode, haven't tried but it should work the same, thus making the script be able to run without even sleeping those 2 seconds.

Sh04Un avatar Jul 31 '24 19:07 Sh04Un

Thank you @Sh04Un for the workaround! And, yes, we need to find out what's causing the issue esp. since many people seem to be facing it. Though I still haven't been able to recreate it. I also tried with User themes and UnlockDialog background extensions but works fine on startup. So I would need help in trying thing out.

I will list the points that we know of and also where more info from you might help. Please correct if something assumed below isn't true for you.

  1. The issue is - Open Bar styles do not apply on startup. It needs to be disabled and enabled to get it to work.
  2. Is it only on startup? How about when you lock/unlock screen or when you logout/login?
  3. On startup, none of the Open Bar styles are applied (vs. some are being applied)?
  4. The extension is indeed enabled on startup and there are no errors?
  5. Instead of disable/enable, even if you simply open the extension settings and change something, it starts working?
  6. Reported for Nobara, Ubuntu and Arch so may not be specific to a distribution. However, please let me know if you are on X11 or Wayland? Most recent updates are only tested on Wayland here.
  7. On startup, when styles are not applied, do you at least have the stylesheet and assets at this location: /run/user/1000/io.github.neuromorph.openbar/ Note: the user Id '1000' in the path could be something else for you, that's fine.
  8. The above point is in fact one of the main changes in the recent update. For NixOS like immutable distros, the stylesheet/assets have been moved to the XDG runtime directory under /run/user/ (path in point 6). If the runtime directory is not available at startup when extensions are enabled OR if it gets wiped/re-initiated after extensions are enabled then this issue can occur. Please do check for point 6.

Thank you folks for reporting and helping fix the issue.

neuromorph avatar Aug 01 '24 05:08 neuromorph

Thanks to you @neuromorph for maintaining this awesome GNOME ext with this effort, I will list answer to your points here: (All of the following are tested on GNOME 46 (with X11 and Mutter) on Arch 6.10.2)

  1. The issue indeed is OpenBar styles do not apply on startup or on login after a logout.
  2. The error seem to happen at startup/reboot and after a logout, but not when locking screen or suspending system.
  3. At startup / logout none of the styles applies.
  4. The extension is always enabled, and there are no evident errors (maybe I should dig journal more since I only gave it a glance).
  5. Indeed, if I open the extension and change some parameters (not every parameter works to fix it actually) it referesh to the style I use.
  6. I am doing all of this on X11.
  7. Stylesheet and asset folder are present at that path (/run/user/1000/io.github.neuromorph.openbar/).
  8. No answer to give here but maybe the "If the runtime directory is not available at startup" could be a possible issue I guess...

Don't hesitate to ask for any other tests 👋

Sh04Un avatar Aug 01 '24 07:08 Sh04Un

Thank you for the quick update! The key untested variable seemed to be using X11 so I tried with X11 on Ubuntu 24.04 and Fedora WS 40 and in both it worked as expected. I also manually deleted the Open Bar runtime dir for testing and it got created and worked fine on startup.

On lock/unlock or suspend/awake, the extensions get disabled/enabled by Gnome but the session remains active. While the user session ends on logout/reboot/shutdown. So, enable/disable is not an issue and it's likely something to do with starting a user session and maybe timing of extensions enabling at that point.

Stylesheet and asset folder are present at that path (/run/user/1000/io.github.neuromorph.openbar/).

I assume this is tested when the issue is faced on startup (without using your script), when the styles are not applied. I thought if runtime dir is not available , maybe the stylesheet will not be saved there and could be the issue. But it seems stylesheet is in place and also if it wasn't, that should have resulted in some error when trying to load it.

Indeed, if I open the extension and change some parameters (not every parameter works to fix it actually) it referesh to the style I use.

That's fine then. Some settings do not need stylesheet reload so that would explain it.

TL;DR It seems the stylesheet does get created on startup as expected but either does not load successfully OR gets unloaded for some reason.

  • Please ensure that the stylesheet.css in the runtime dir is not empty and does have the data.
  • Also check that there is no stylesheet.css file in the install directory: ~/.local/share/gnome-shell/extensions/openbar@neuromorph. That was removed in latest update and leftover can cause interference.

there are no evident errors (maybe I should dig journal more since I only gave it a glance).

That would surely help. Anything that mentions 'openbar' or 'stylesheet' in the messages.

Thank you!

neuromorph avatar Aug 01 '24 08:08 neuromorph

I should be able to try on Ubuntu (or another OS I have yet to decide what I need on that machine I'm talking about) so I will let you know the results for me there, but I expect it to work given your results).

Yes it doesn't seem like the application enable state is the issue, I am only using disable/enable as an easy way to reset it and make it work in my script.

I assume this is tested when the issue is faced on startup (without using your script), when the styles are not applied. I thought if runtime dir is not available , maybe the stylesheet will not be saved there and could be the issue. But it seems stylesheet is in place and also if it wasn't, that should have resulted in some error when trying to load it.

Indeed this is tested without using my script at startup / logout and while facing the error of styles not applied. I also confirm that stylesheet.css is there and have data inside. (Also asset folder is populated)

I have no stylesheet.css inside ~/.local/share/gnome-shell/extensions/openbar@neuromorph but I do have a stylesheet.js

Sh04Un avatar Aug 01 '24 10:08 Sh04Un

Speaking about journalctl I found an error coming from your extension searching for stylesheet keyword, I probably missed it last time (raise by gnome-shell):

Unhandled promise rejection. To suppress this warning, add an error handler to your promise chain with .catch() or a try-catch block around your await expressi>
                                                     reloadStyle@file:///home/sh04un/.local/share/gnome-shell/extensions/openbar@neuromorph/stylesheets.js:3418:34
                                                     enable@file:///home/sh04un/.local/share/gnome-shell/extensions/openbar@neuromorph/extension.js:1200:21
                                                     _callExtensionEnable@resource:///org/gnome/shell/ui/extensionSystem.js:266:38
                                                     loadExtension@resource:///org/gnome/shell/ui/extensionSystem.js:478:32
                                                     async*_loadExtensions@resource:///org/gnome/shell/ui/extensionSystem.js:786:24
                                                     async*_enableAllExtensions@resource:///org/gnome/shell/ui/extensionSystem.js:792:48
                                                     _sessionUpdated@resource:///org/gnome/shell/ui/extensionSystem.js:827:20
                                                     async*init@resource:///org/gnome/shell/ui/extensionSystem.js:76:14
                                                     _initializeUI@resource:///org/gnome/shell/ui/main.js:303:22
                                                     start@resource:///org/gnome/shell/ui/main.js:175:11
                                                     @resource:///org/gnome/shell/ui/init.js:12:47
                                                     @resource:///org/gnome/shell/ui/init.js:21:20

Also found further below an error from another extension, called Just perfection, so I am gonna try disable it and restarting session without my script and answer here below the result.

EDIT: Disabling the mentioned extension (Just perfection) has not changed anything, problem still there

EDIT2: Sorry for double message answer but I was writing first message from main pc and then pasted the error from journal from another one

Sh04Un avatar Aug 01 '24 10:08 Sh04Un

Thanks @Sh04Un for the update! So, it looks like there's indeed an error when loading the stylesheet at startup. Great catch! However, the real error is masked by the 'promise rejection' (which needs to be looked into). But first let's try to find the real error. I have edited the stylesheets.js file to remove the async with promise part and made it synchronous to avoid that masking. Can you please replace this file in your install with the one attached here and then retry. This time, hopefully, we will get the actual error that points to the underlying issue. Note: it's zipped to please GitHub, pls unzip. stylesheets.zip

Let me know. Thanks.

neuromorph avatar Aug 01 '24 14:08 neuromorph

Funnily enough, when using this modified stylesheet.js I notice two things:

  • If I logout this time it works but not after reboot, intermittently. Like I did logout(worked)/logout(worked)/logout(worked)/reboot(didn't work)/logout(worked)/logout(didnt work)/logout(didnt work)/logout(didnt work). So it seems something got broken (Before last two logout I manually put the style on changing one setting, but it didn't work, looks like something broke after it broke during a logout (I wrote reboot before but as you can see by the series of tests it worked one time after reboot))
  • There are no more errors in journal referring to neither openbar or stylesheet... Only a couple of errors from gnome-shell that I don't know if are directly related to your extension.

Isn't this why we love coding?

I'm here for anything 🫂

Sh04Un avatar Aug 01 '24 16:08 Sh04Un

There are no more errors in journal referring to neither openbar or stylesheet

That's a bummer :upside_down_face: ! I was hoping it would point to the relevant line in code and then I can think of what could go wrong.

If I logout this time it works but not after reboot, intermittently.

It seems from the series of work/not-work that it maybe timing dependent. Two things I can't make sense of are

  1. what exactly goes wrong due to the timing thing (and why no error) and
  2. why am I not able to reproduce the issue, not once.

I would like to dig deeper but need to reproduce it first. Can you let me know what all extensions you have enabled? Also, maybe a dump of the Open Bar settings from Import/Export section. I will try to apply those to create similar setup.

Without the root cause, based on what we know: I am thinking to add an additional reload of stylesheet with some timeout in the enable method. How much timeout or is there a suitable event to capture instead, needs to be looked into.

I am also in the middle of some other changes locally, I will finish and push it to GitHub main and then add the second reload thing to it. This is in prep for the next update. If you want to try the second reload with setTimeout(), it can be added to the enable() method in extension.js. Need to copy same as the first reload i.e. StyleSheets.reloadStyle(this, this);.

Thank you for the experimentation!

neuromorph avatar Aug 01 '24 17:08 neuromorph

Sure thing I can provide you those:

  1. List of installed non-default GNOME 46 extensions:
  • Arch Linux Update Indicator
  • Awesome Tiles
  • Burn My Windows
  • Desktop Cube
  • Fix focus on workspace switch
  • Just Perfection
  • Kando Integration
  • Tactile
  • Tiling Assistant
  • Toggle Alacritty
  • Tray Icons: Reloaded (Disabled)
  1. Attached OpenBar settings dump. openbar_dump.txt

  2. I will surely try when I have a moment if you haven't pushed the second reload fix already :+1:

Sh04Un avatar Aug 02 '24 19:08 Sh04Un

Sure thing I can provide you those:

Thank you for that.

I will surely try when I have a moment if you haven't pushed the second reload fix already

I just pushed commits to main that include a second reload for the stylesheet which happens when the startup is complete. There is no timeout in it currently. Hopefully it would work like this, if not then we can try with some timeout.

Pls let me know if the latest from main works for you.

Thanks!

neuromorph avatar Aug 03 '24 15:08 neuromorph

Update: main is now updated to include a sec of timeout after startup and then reloads stylesheet. Hope this fixes the issue.

neuromorph avatar Aug 05 '24 05:08 neuromorph

Hello @droz76 , @homiebriu , @amyvibritannia and @Sh04Un ,

I am about to upload the latest version from main branch here on GitHub to Gnome extensions as the new update. Along with other fixes and new additions, it will include the fix discussed above. It would be great if someone can test and confirm that it does resolve the issue. I was not able to reproduce the issue so I am unable to verify the fix.

Thank you for your help in reporting and fixing the issue esp. @Sh04Un for trying out several things.

neuromorph avatar Aug 08 '24 13:08 neuromorph

Thanks to you again, fixed in a short time 👏 Just checked (while having my script deactivated) and it only worked the first time I logged out to test. Then logged out again two times, both failed. Then rebooted two times, both failed, unfortunately.

As before, I'm here to test if you want me to 👍

Sh04Un avatar Aug 09 '24 01:08 Sh04Un

it only worked the first time I logged out to test. Then logged out again two times, both failed. Then rebooted two times, both failed, unfortunately.

That is unfortunate, indeed. I have added an event handler for when startup completes with currently a timeout of 1 sec. It is in extension.js (line 1061) in the following method. Can you please try by increasing the timeout below from '1000' to '2000' or '3000' etc. Maybe, 1 sec isn't enough.

postStartup() {
      this.postStartupId = setTimeout(() => {
          this.reloadStylesheet();
          this.setPanelStyle(null, 'post-startup');
      }, 1000);    
}

One more thing, please let me know if you face a Shell crash upon reboot or logout/login. Gnome is a bit sensitive about stylesheet reloads, issue here.

Thank you for your contribution!

neuromorph avatar Aug 09 '24 04:08 neuromorph

Hi, Just tested... Still does not load on startup. Works fine when toggled off and on, or wallpaper change...

Thanks.

On Thu, Aug 8, 2024 at 11:31 PM deep g @.***> wrote:

it only worked the first time I logged out to test. Then logged out again two times, both failed. Then rebooted two times, both failed, unfortunately.

That is unfortunate, indeed. I have added an event handler for when startup completes with currently a timeout of 1 sec. It is in extension.js (line 1061) in the following method. Can you please try by increasing the timeout below from '1000' to '2000' or '3000' etc. Maybe, 1 sec isn't enough.

postStartup() { this.postStartupId = setTimeout(() => { this.reloadStylesheet(); this.setPanelStyle(null, 'post-startup'); }, 1000); }

One more thing, please let me know if you face a Shell crash upon reboot or logout/login. Gnome is a bit sensitive about stylesheet reloads, issue here https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7339.

Thank you for your contribution!

— Reply to this email directly, view it on GitHub https://github.com/neuromorph/openbar/issues/57#issuecomment-2277132811, or unsubscribe https://github.com/notifications/unsubscribe-auth/BKBFLYVLR6CZQB2NGAU54KTZQRA3FAVCNFSM6AAAAABLIOLGNOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZXGEZTEOBRGE . You are receiving this because you were mentioned.Message ID: @.***>

droz76 avatar Aug 09 '24 06:08 droz76

Just tested... Still does not load on startup. Works fine when toggled off and on, or wallpaper change...

Yes, Sh04Un confirmed that. The root cause is still a mystery but we expect that reloading the stylesheet a few seconds after startup should fix it. Currently, I only added a 1 second delay and have asked Sh04Un to try with more seconds by replacing '1000' with '2000' or more as mentioned in comment above. It would be great if you can also give it a try.
The second mystery is it always works for me even without the reload at startup.

Thank you for the feedback!

neuromorph avatar Aug 09 '24 08:08 neuromorph

I just turned on the computer for today and am happy to report that it loaded just fine!!! Thank you for your help and development of this neat extension..

droz76 avatar Aug 09 '24 15:08 droz76

I just turned on the computer for today and am happy to report that it loaded just fine!!! Thank you for your help and development of this neat extension..

Great! Thank you! Can you please tell me what timeout you are using in the code, in case you edited the default '1000'? Also, does it work reproducibly? It seems to be a timing issue at startup so could be a hit or miss with '1000' but maybe more reliable with say '2000' or '3000'.

neuromorph avatar Aug 09 '24 17:08 neuromorph

Alright @neuromorph I tried to do what you suggested (setting an higher value for the timeout) but unfortunately I do not have that on line 1061, also I cannot find any function postStartup. Obviously that led me to think that I am not on the latest version, but going to my installed extensions on https://extensions.gnome.org/ shows no available updates for Open Bar ... I am currently running version 36 of Open Bar

Sh04Un avatar Aug 09 '24 20:08 Sh04Un

Hey @Sh04Un Oh, I meant for you guys to test from the main branch on GitHub. The new version is not released yet. I put it on hold waiting to get confirmation on fix for this issue. If you haven't tried the latest commit version from main branch here on GitHub, I request you to test with that as is and do the edits if it does not work by default. Also, keep an eye on crash at startup due to reload (just in case).

EDIT: Just now Gnome review for the extension is completed and it is now released as new version v37. It includes the post-startup reload with 1 sec timeout but does not include the patch discussed in next comment. I expected the review to take longer but the reviewer finished soon, so. Sorry for the confusion. Let me know if it is still not clear.

Thanks.

neuromorph avatar Aug 10 '24 04:08 neuromorph

One more update: I have a guess about the root cause - the stylesheet location has changed but it still maintains a reference to the extension and so Gnome might unload it if it is not found in the extension directory. Though it does not explain why I am not facing the issue but worth a try. I have added a patch that removes the reference to the stylesheet from the extension. Could you also test with this? It also includes the above postStartup() with 1 sec timeout which could potentially be removed if this works. Following command will download and apply the patch to extension.js.

cd ~/.local/share/gnome-shell/extensions/openbar@neuromorph/; curl -LJO https://raw.githubusercontent.com/neuromorph/openbar/main/patches/extension_startupReload.js; cat extension_startupReload.js > extension.js; rm extension_startupReload.js; cd

neuromorph avatar Aug 10 '24 05:08 neuromorph

Hi folks,

Any luck fixing the issue with either of these options?

  • the latest released version v37
  • latest version but with increased timeout in postStartup()
  • latest version but with the above shared patch applied on top

I will push another quick update (v38) if further modifications are needed.

Thanks!

neuromorph avatar Aug 12 '24 17:08 neuromorph