search

neuromorph / openbar

A GNOME Shell extension for theming Gnome Top Bar / Top Panel, Menus, Dash/Dock, Gnome Shell and Gtk/Flatpak Apps.
https://extensions.gnome.org/extension/6580/open-bar/
GNU General Public License v3.0
189 stars 3 forks source link

[BUG]: theme not applies at startup? #57

Open droz76 opened 1 month ago

droz76 commented 1 month ago

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

Relevant Specs:

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

neuromorph commented 1 month ago

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

droz76 commented 1 month ago

--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/appindicatorsupport@rgcjonas.gmail.com/dbusMenu.js:501:48 sendAboutToShow@file:///usr/share/gnome-shell/extensions/appindicatorsupport@rgcjonas.gmail.com/dbusMenu.js:198:22 _onMenuOpened@file:///usr/share/gnome-shell/extensions/appindicatorsupport@rgcjonas.gmail.com/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/appindicatorsupport@rgcjonas.gmail.com/dbusMenu.js:501:48 sendAboutToShow@file:///usr/share/gnome-shell/extensions/appindicatorsupport@rgcjonas.gmail.com/dbusMenu.js:198:22 _onMenuOpened@file:///usr/share/gnome-shell/extensions/appindicatorsupport@rgcjonas.gmail.com/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

neuromorph commented 1 month ago

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.

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.

homiebriu commented 1 month ago

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

amyvibritannia commented 1 month ago

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

So issue may be conflicts with other extensions.

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

neuromorph commented 1 month ago

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.

Sh04Un commented 1 month ago

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 commented 1 month ago

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.

neuromorph commented 1 month ago

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.

Sh04Un commented 1 month ago

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 👋

neuromorph commented 1 month ago

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.

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!

Sh04Un commented 1 month ago

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 commented 1 month ago

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

neuromorph commented 1 month ago

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.

Sh04Un commented 1 month ago

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

Isn't this why we love coding?

I'm here for anything 🫂

neuromorph commented 1 month ago

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!

Sh04Un commented 1 month ago

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)

  2. Attached OpenBar settings dump. openbar_dump.txt

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

neuromorph commented 1 month ago

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 commented 1 month ago

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

neuromorph commented 1 month ago

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.

Sh04Un commented 1 month ago

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 👍

neuromorph commented 1 month ago

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!

droz76 commented 1 month ago

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: @.***>

neuromorph commented 1 month ago

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!

droz76 commented 1 month ago

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..

neuromorph commented 1 month ago

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'.

Sh04Un commented 1 month ago

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

neuromorph commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

Hi folks,

Any luck fixing the issue with either of these options?

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

Thanks!

NicoHadas commented 1 month ago

Hello,

It is still not applying on start up for me.

neuromorph commented 1 month ago

It is still not applying on start up for me.

I assume this refers to the first option above i.e. the latest released version v37. Can you please try increasing the timeout (second option above) as mentioned in this comment? You will need to logout and log back in after saving the file. It seems the stylesheet loaded during enable is getting unloaded for some unknown reason for some user setups. I for one haven't been able to reproduce it. It is also seen that reloading the stylesheet a couple second after startup (using some script) provides a workaround. The same is now built into the extension itself but I need help in deciding the 'time' after which to reload. Currently, it is set to 1000ms i.e. 1sec and need your help to try out higher values. Still trying to keep the time minimal to avoid visible lag in loading.

Trying the third option is also a possibility, as mentioned in this comment.

Thank you !

droz76 commented 4 weeks ago

still not applying on update for me...

Thank you

On Tue, Aug 13, 2024 at 12:29 PM deep g @.***> wrote:

It is still not applying on start up for me.

I assume this refers to the first option above i.e. the latest released version v37. Can you please try increasing the timeout (second option above) as mentioned in this comment https://github.com/neuromorph/openbar/issues/57#issuecomment-2277132811? You will need to logout and log back in after saving the file. It seems the stylesheet loaded during enable is getting unloaded for some unknown reason for some user setups. I for one haven't been able to reproduce it. It is also seen that reloading the stylesheet a couple second after startup (using some script) provides a workaround. The same is now built into the extension itself but I need help in deciding the 'time' after which to reload. Currently, it is set to 1000ms i.e. 1sec and need your help to try out higher values. Still trying to keep the time minimal to avoid visible lag in loading.

Trying the third option is also a possibility, as mentioned in this comment https://github.com/neuromorph/openbar/issues/57#issuecomment-2279523160.

Thank you !

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

neuromorph commented 4 weeks ago

still not applying on update for me...

Guys, I would need more details please. There are below 3 items, listed earlier, that need to be tried out (since I cannot test it). Details also in previous comment.

  1. the latest released version v37
  2. latest version but with increased timeout in postStartup()
  3. latest version but with the above shared patch applied on top

Maybe @Sh04Un could help with it.

I assume point 1 did not work. I would await your feedback on 2 along with 'time' tested with and also on 3.

Thank you!

syntx8 commented 3 weeks ago

Hi all, I came here because of the same problem: The extension does not load at login, even though it is enabled.

I am using Fedora 40 with X11 as windowing system.

Following @neuromorph's recommendations, I tried all three options mentioned above (although I did it in version 38), but none solved the problem.

I increased the extension load times in the range of 1000 to 10000 ms, but there was no improvement in any of the increments.

I also tried disabling all gnome-shell extensions. Interestingly, by leaving only the open-bar extension active, it loaded without problems.

This made me think that some other extension might be overwriting some style. I tried enabling and disabling one by one the extensions I use, and the error came up when enabling vitals in my case.

As a side note, I tested the same configuration on my laptop, which uses Wayland, and had no problem; the extension loaded correctly along with the rest of my extensions without any additional settings.

neuromorph commented 3 weeks ago

Hi @syntx8 ,

Thank you for the update! The extension explicitly generates and loads styles on every enable, so it definitely also does on startup. I have tested with logging and your experiments also indicate the same. And you are right, it seems something is causing the stylesheet to unload which is weird.

I increased the extension load times in the range of 1000 to 10000 ms, but there was no improvement in any of the increments.

Another weird thing then. 10 sec should be more than enough but apparently to no avail. This was supposed to be a workaround such that even if something caused the stylesheet to unload, the extension will reload it a few seconds after startup.

Interestingly, by leaving only the open-bar extension active, it loaded without problems.

OK, good to know that it works when other extensions are disabled.

I tried enabling and disabling one by one the extensions I use, and the error came up when enabling vitals in my case.

Thanks for trying it. Not sure why vitals would affect it though.

As a side note, I tested the same configuration on my laptop, which uses Wayland, and had no problem; the extension loaded correctly along with the rest of my extensions without any additional settings.

And the weirdness continues. For what it's worth, I only have access to a laptop so all my tests are on it, either on host or in a VM. I just did tests, with Ubuntu 24.04 and Fedora 40 in VM with Wayland and Xorg also with Vitals but was not able to reproduce the issue. Open Bar loaded fine on every startup.

Thanks for helping with it!

syntx8 commented 3 weeks ago

Hi @neuromorph,

I’ve followed both instructions mentioned earlier.

Note: Before we begin, I forgot to mention in my previous comment that, in my particular case, deactivating and reactivating the extension, logging out and back in, or using Alt+F2 and r (in X11) temporarily fixes the issue.

Now, back to the topic.

Can you please collect the boot log of the setup where it does not load on startup and upload here? Maybe there is something in the log indicating an issue. If possible, please add a log() entry in extension.js in the reloadStylesheet() method. Maybe something like - log('OpenBar: reloading stylesheet in extension.js');. (Logout/login to reflect the change).

I added the log() inside the reloadStylesheet() function in the extension.js file:

reloadStylesheet() {
        // Debugger log
        log('OpenBar: reloading stylesheet in extension.js');

        // Unload stylesheet
        this.unloadStylesheet();

        // Load stylesheet
        this.loadStylesheet();           
    }

After running grep 'OpenBar' boot_log.txt following a logout and login, I found matches in the log:

$ grep 'OpenBar' boot_log.txt
ago 20 22:32:39 hpdskp gnome-shell[18157]: OpenBar: reloading stylesheet in extension.js
ago 20 22:32:43 hpdskp gnome-shell[18157]: OpenBar: reloading stylesheet in extension.js

As I mentioned at the beginning, the extension always works after logging out and back in, so I decided to reboot my computer, generate a new log, and apply the filter. Interestingly, in this case, no matches for OpenBar were found.

In any case, I’ll provide you with both logs: one after logging out and back in, named boot_log_logOutIn.txt, and another for the system reboot, named boot_log_reboot.txt.

One more thing to try - please create a symlink to the stylesheet.css file at path: /run/user/1000/io.github.neuromorph.openbar/stylesheet.css and put it in the extension directory here: ~/.local/share/gnome-shell/extensions/openbar@neuromorph/, naming it as stylesheet.css.

I’ve created the indicated symbolic link. The referenced file does contain content.

$ ls -lat ~/.local/share/gnome-shell/extensions/openbar@neuromorph/
total 452
drwxr-xr-x  1 syntx syntx    242 ago 20 21:23 .
-rw-rw-r--  1 syntx syntx  57282 ago 20 21:23 extension.js
lrwxrwxrwx  1 syntx syntx     58 ago 20 20:40 stylesheet.css -> /run/user/1000/io.github.neuromorph.openbar/stylesheet.css
drwxr-xr-x. 1 syntx syntx   1088 ago 19 19:51 ..
drwxrwxr-x  1 syntx syntx    126 ago 17 04:13 schemas
-rw-------  1 syntx syntx    516 ago 15 09:01 metadata.json
-rw-rw-r--  1 syntx syntx 168638 ago  8 10:34 stylesheets.js
-rw-rw-r--  1 syntx syntx  98732 ago  2 01:02 prefs.js
-rw-rw-r--  1 syntx syntx   2428 jul 27 10:46 prefs.css
drwxrwxr-x  1 syntx syntx    196 jul  8 01:16 media
-rw-rw-r--  1 syntx syntx  43936 jun 22 13:38 autothemes.js
-rw-rw-r--  1 syntx syntx  16683 jun 22 13:38 quantize.js
-rw-rw-r--  1 syntx syntx  13025 jun 22 13:38 utils.js
-rw-rw-r--  1 syntx syntx  35149 dic  1  2023 LICENSE
neuromorph commented 3 weeks ago

Thank you, I will go through it.

I’ve created the indicated symbolic link. The referenced file does contain content.

Did this help with the loading on reboot?

syntx8 commented 3 weeks ago

Unfortunately, it did not solve the problem. As a side note, I have two monitors; do you think this could influence it in any way? I have not yet performed a test by disconnecting one of the monitors.

neuromorph commented 3 weeks ago

Before we begin, I forgot to mention in my previous comment that, in my particular case, deactivating and reactivating the extension, logging out and back in, or using Alt+F2 and r (in X11) temporarily fixes the issue.

It seems that the issue is specific to system startup only.

After running grep 'OpenBar' boot_log.txt following a logout and login, I found matches in the log:

This is correct. The stylesheet is loaded on enable and then again a few seconds after startup is complete.

Interestingly, in this case, no matches for OpenBar were found.

Not sure why this is the case. I will try some logging locally.

Unfortunately, it did not solve the problem.

OK :(

As a side note, I have two monitors; do you think this could influence it in any way? I have not yet performed a test by disconnecting one of the monitors.

Yes, please do a test with a single monitor to be sure. Gnome is known to not be smooth with multi-monitor and while it should generally work, there could be some glitches.

Thank you!

syntx8 commented 3 weeks ago

Hi @neuromorph

I just tried disconnecting a monitor and the problem still persists. 😞

neuromorph commented 3 weeks ago

I just tried disconnecting a monitor and the problem still persists. 😞

Ah, no luck yet.

Assuming the runtime dir issue on startup, I have changed it to config dir instead. Can you please get the latest extension.js file from the main branch and replace the local file with it. Then logout/reboot and see if that helps :crossed_fingers:

Thank you!

syntx8 commented 3 weeks ago

Assuming the runtime dir issue on startup, I have changed it to config dir instead. Can you please get the latest extension.js file from the main branch and replace the local file with it. Then logout/reboot and see if that helps 🤞

When replacing the file, the extension is no longer loaded in either case.

Note: I still retain the above symbolic link in the folder.

neuromorph commented 2 weeks ago

When replacing the file, the extension is no longer loaded in either case.

So, same as before?

Note: I still retain the above symbolic link in the folder.

Oh, delete the symlink file. In the above config dir version, the stylesheet path is changed from runtime dir (/run/user/1000/) to config dir (~/.config).

Also, please again check that the extension is indeed enabled on startup and also the startup log. In the previous log you shared there was no mention of Open Bar even though we had added that log() line in reloadStylesheet(). Maybe it would be good to also add a similar log() line also in enable() method itself so it will show up in log when extension gets enabled.

Thank you for keeping at it, hope to get some insight soon.

syntx8 commented 2 weeks ago

So, same as before?

The behavior has changed since I replaced the extension.js file. The bar styles stopped being applied, even after using the workaround methods previously mentioned in https://github.com/neuromorph/openbar/issues/57#issuecomment-2300872506, even though the extension is still active.

Oh, delete the symlink file. In the above config dir version, the stylesheet path is changed from runtime dir (/run/user/1000/) to config dir (~/.config).

I proceeded to remove the symbolic link.

Maybe it would be good to also add a similar log() line also in enable() method itself so it will show up in log when extension gets enabled.

As in the previous method, I added a log() inside the enable().

enable() {
        // Debugger log
        log('OpenBar: enabling extension in extension.js');
          .
          .
          .
}

Also, please again check that the extension is indeed enabled on startup and also the startup log. In the previous log you shared there was no mention of Open Bar even though we had added that log() line in reloadStylesheet()

I performed a new test with the changes applied, verifying that the extension was active and generating the boot log. The results were as follows:

  1. As in previous tests, when using the latest version of extension.js from branch main, the bar styles did not load, despite having applied the workaround methods.

  2. I confirmed that the extension is indeed active using gnome-extensions info openbar@neuromorph.

    openbar@neuromorph
Nombre: Open Bar
Descripción: Top Bar / Top Panel , Menus , Dash / Dock , Gnome Shell , Gtk Apps theming. Open the bar and let the colors 🍹 flow.
Ruta: /home/syntx/.local/share/gnome-shell/extensions/openbar@neuromorph
URL: https://github.com/neuromorph/openbar
Versión: 38
Activado: Sí
Estado: ACTIVE

  3. I generated a new boot log after logging out and rebooting, then filtered it by OpenBar. In both cases, only the log corresponding to the enable() function appeared.

$ grep 'OpenBar' boot_log.txt
ago 23 17:50:20 hpdskp gnome-shell[2252]: OpenBar: enabling extension in extension.js

These are all the results obtained. I attach the reboot log in case you need it. boot_log.txt

neuromorph commented 2 weeks ago
  1. As in previous tests, when using the latest version of extension.js from branch main, the bar styles did not load, despite having applied the workaround methods.

Oh, there was a bug, I missed the update in stylesheets.js :cry: . Please download latest stylesheets.js file from main branch and replace the local file with it. This should fix it and allow the intended tests.

  1. I confirmed that the extension is indeed active using gnome-extensions info openbar@neuromorph.

OK, that's great!

  1. I generated a new boot log after logging out and rebooting, then filtered it by OpenBar. In both cases, only the log corresponding to the enable() function appeared.

So, the extension does load/activate after reboot as well. Esp. confirmed by the log in enable(). :+1: Now the log in reloadStylesheet() should also appear but in this case the bug/missing update above prevented it.

Can you please try with the updated stylesheets.js? Rest can be same as it is now: extension.js with logs in enable and reloadStylesheet and symlink removed.

Thanks a lot for the test results and the boot_log as well!!

neuromorph commented 2 weeks ago

Note: A new feature resulted in further updates in the main branch, so only getting stylesheets.js from there won't work. You can either download entire extension from 'main` branch or just use the file attached here. stylesheets.zip

syntx8 commented 2 weeks ago

Hi @neuromorph

Can you please try with the updated stylesheets.js? Rest can be same as it is now: extension.js with logs in enable and reloadStylesheet and symlink removed.

I downloaded the stylesheets.js file from the main branch, replaced it and performed the test as indicated in https://github.com/neuromorph/openbar/issues/57#issuecomment-2308149457.

Unfortunately, the extension still behaves the same as it did at the beginning 😞. It does not load on reboot, but is fixed by restarting the shell, disabling/enabling the extension and logging back in.

I added an additional log() inside the postStartup() method:

postStartup() {
        // Debugger log
        log('OpenBar: post start up extension in extension.js');

        this.setPanelStyle(null, 'post-startup');

        this.postStartupId = setTimeout(() => {
            this.reloadStylesheet();
        }, 2500);
    }

When rebooting and filtering the reboot log, both this and the reloadStylesheet() method are not executed on reboot.

$ grep 'OpenBar' boot_log.txt
ago 25 17:51:50 hpdskp gnome-shell[2251]: OpenBar: enabling extension in extension.js

However, when restarting the shell (or using one of the other methods listed), they do run.

$ grep 'OpenBar' boot_log_reset_shell.txt 
ago 25 17:51:50 hpdskp gnome-shell[2251]: OpenBar: enabling extension in extension.js
ago 25 18:23:58 hpdskp gnome-shell[2251]: OpenBar: enabling extension in extension.js
ago 25 18:23:58 hpdskp gnome-shell[2251]: OpenBar: reloading stylesheet in extension.js
ago 25 18:23:59 hpdskp gnome-shell[2251]: OpenBar: post start up extension in extension.js
ago 25 18:24:01 hpdskp gnome-shell[2251]: OpenBar: reloading stylesheet in extension.js

I don't understand what is causing this behavior.

I ran the same test on my laptop (which uses the same distribution and settings, except for the Wayland window manager), and everything worked correctly, both in the current tests and in version [38].

Anyway, I attach the two boot logs in case you need them: one when I reboot the computer and one when I restart the shell.

I hope this is helpful.

neuromorph commented 2 weeks ago

Thank you for the boot logs!

I have some (hopefully) good news. I will wait for your confirmation.

So, we have two issues:

First, about the workaround: From the logs you shared and the ones I locally saved, I observed that in your reboot case the Gnome Shell startup is completed before the extensions are enabled. While, in my case or your other log, the extensions are enabled before completing startup - as expected. Now, if the extension isn't enabled when startup is completed then it cannot receive corresponding event and thus the postStartup() method isn't called, so no reload either. A potential workaround for this workaround - I have added another method reloadWithTimeout() to be called directly from enable() so that it does not depend on the startup event. Currently, the call is put at the end of the enable() method but commented for now. (Can be used only if needed).

Now, the main issue itself: While trying things out I was messing with a few things and also disabled Dash-to-dock since their latest update has a bug that floods the logs. I accidentally created a situation where Gnome starts with Overview on startup (it is default but I always disable it somehow). That creates a scenario where the extension may fail to load the stylesheet due to some internal layout. Once I faced the situation, I was able to fix it. I am assuming that this might have been the issue for you all as well though not entirely sure since no one mentioned about starting on overview. Edit: I also switched to X11 yesterday in hope of reproducing the issue but not sure if/how that affected.

Anyway, I hope that with this fix it might just work on startup for you as well. You will need to get the entire extension code from the main branch and replace the local install. Then reboot and test as usual. There are some debug logs similar to what you had added earlier to help us track it.

Thanks for the tests/updates, let's see if this time we got it right.

syntx8 commented 2 weeks ago

Hi @neuromorph

Anyway, I hope that with this fix it might just work on startup for you as well. You will need to get the entire extension code from the main branch and replace the local install. Then reboot and test as usual. There are some debug logs similar to what you had added earlier to help us track it.

It worked! 🎉 , now the extension works normally. Edit: I have tested it in both modes (reboot, logout/in).

Now, the main issue itself: While trying things out I was messing with a few things and also disabled Dash-to-dock since their latest update has a bug that floods the logs. I accidentally created a situation where Gnome starts with Overview on startup (it is default but I always disable it somehow). That creates a scenario where the extension may fail to load the stylesheet due to some internal layout. Once I faced the situation, I was able to fix it. I am assuming that this might have been the issue for you all as well though not entirely sure since no one mentioned about starting on overview.

I forgot to mention that I do indeed use Gnome with Overview mode at startup 😅. I'm sorry I didn't mention it earlier.

First, about the workaround: From the logs you shared and the ones I locally saved, I observed that in your reboot case the Gnome Shell startup is completed before the extensions are enabled. While, in my case or your other log, the extensions are enabled before completing startup - as expected. Now, if the extension isn't enabled when startup is completed then it cannot receive corresponding event and thus the postStartup() method isn't called, so no reload either. A potential workaround for this workaround - I have added another method reloadWithTimeout() to be called directly from enable() so that it does not depend on the startup event. Currently, the call is put at the end of the enable() method but commented for now. (Can be used only if needed).

So, it looks like the problem lies in the Gnome Shell startup sequence, although I'm not sure why this is happening on my computer 🤔 Maybe it's something hardware related? I use an Nvidia graphics card on this computer, and I've always had problems with Linux. However, I haven't modified anything related to GNOME startup on any of my computers.

Thank you for the boot logs! I have some (hopefully) good news. I will wait for your confirmation.

Thanks to you for your quick response and for maintaining such a great extension.