Reworking Fildem's architecture.

[Weather-OS]

Currently, Fildem works by moving the entire menu bar onto the panel, and creating and overlay on top of it. While this method works, It's not practical and it creates a lot of issues within the program.

Issues like:

1. Buggy behavior
2. Miss-aligned buttons
3. Crashing on incorrect parse
4. Because the Menu is now controlled by Fildem, Sometimes, Crashing can result in mutter breaking substantially.

This page aims to rework and potentially make a better method at creating a Global menu for GNOME.

[jrvgr]

May i suggest also implementing lazy loading of some sort, a friend of mine constantly experienced crashes when trying to open Fildem with Firefox because of all his bookmarks being loaded instantly.

[echeoquehaii]

I have to agree, that is the only issue I have with Fildem. Sometimes (for some reason not always) clicking outside of a drop down menu doesn't hide the menu, I have to go back to the top bar to close the drop down menu, which makes it a bit sluggish to use. I think this depends on how it is implemented as you said, but wouldn't know how to do it differently.

If it can be of any inspiration lestcape had made a similar extension with another approach. I have used that for a while but I recall it being pretty heavy on resources and not as convenient as Fildem's I have to say.

IMHO apart from fixing the small issues the extension has, the most important thing would be to keep the extension alive, maintain and fix it whenever Gnome's updates break stuff, which is kinda often sadly.

[chaudharyjatin115]

hey whats the update on this im currently using it with gnome 43 but it dosent works with Android Studio and some other intellij app

[Fsouza1997]

I thought that instead of moving the apps menu bar, it could work by identifying the app that has focus, and in the code have a package that has all the menu code, that is, it already has that menu, for the program just remove the native menu of the app in focus and load the menu already made, maybe it would not be the most practical way but I think it would solve many bugs, maybe the biggest problems of this type of implementation would be: the heavier application (which could be "solved" with the user choosing the menu configuration packages for the apps he wants to have the menu ), a package would have to be made for each menu (the developer would have to make each menu for each program) what could help is to maintain an architecture that makes the implementation of these menus as simple as possible so that the community could help implement menus for some programs, making the job of the main programmer easier. but as I said, I don't know if it would be the best way to implement

[Neuron-Group]

When running on a Wayland interface with fractional scaling, Fildem experiences blurriness. Additionally, several issues frequently occur, including:

• Applications closing but their menu buttons remaining visible.
• Menu buttons disappearing, yet still responding when hovered over with the mouse.
• The menu switching to another application and displaying different buttons, but hovering over the original location still opens the previous application's menu (this almost always happens when shifting focus away from the GNOME Terminal).
• Full black rectangles appearing directly within the menu area.

If it's helpful, I'm wondering if it's possible to separate each button of the global menu into individual widgets within ui.main.panel._leftBox and implement multi-level dropdown menus in a more native manner, similar to other plugins with dropdown menus (such as Clipboard Indicator).