Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PanelMenu Button for compatibility and for using Menus when needed #76

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

neuromorph
Copy link

Hello,

This PR replaces St.BoxLayout with a standard Gnome Top Panel PanelMenu.Button and its container Bin. This allows compatibility with other extensions like Open Bar and with custom user themes expecting standard buttons layout.
Also, it takes steps towards building a Menu as discussed in this issue. I have currently created PanelMenu Button with a DummyMenu set to true (meaning no menu exists) which can be set to false when needed and Menu items can be added.

Cheers.

Replace StBoxLayout with a standard Top Panel PanelMenu.Button and its container.
This allows compatibility with other extensions like Open Bar and with custom user themes. Also, takes steps towards building a Menu as discussed in an issue.
@raujonas
Copy link
Owner

Thanks for your work, I appreciate it. Just wanted to let you know that I will look at the changes eventually, I have not forgotten it. Thanks for your patience!

The panel button is updated to have a menu. The menu opens on left click as is the default behavior for all panel menus. It currently contains only one item for "Settings" which upon click opens settings page as before.
@neuromorph
Copy link
Author

Thank you for the update. I have added another commit for the menu. So now, clicking on executor buttons opens a menu with one item in it for the Settings. More items can be added as needed.
It also standardizes the button further using the addToStatusArea API of main, else input handling does not work well.

You can try it out as per your convenience, leaving it here for whenever you are ready.

- The indicator needed to be destroyed in disable().

- Also, the GLib timeout Ids are stored in an array and remain there even after they expire. Thus, when disabling, it complains that the timeout Ids are not found on GLib Remove. They need to be null'ed out when the timeout expires and in disable we check if the timeout Id still exists and only then remove it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants