Make it an application rather than a Gnome extension

[probonopd]

Make it an application rather than a Gnome extension

[lestcape]

There are only one way. GNOME should provide a robust API for panels and for insert widget in the panels and the developers of extensions should follow it. For example currently is not possible that the user can decided the order of the widgets in the panel. Because of that, developers of extensions force his widget to be set in a position. That can not happens if you wanted that one extension can not break the other. But since there is no way for the user to decide the order, then they ask the developers to force their widget to appear in the position they think is correct and then this means hacking the shell to achieve this. For example, for you: should be ok if the global menu will be display arbitrary after/before the app-icon or you required it to be set always after it? This is only an example, you need an API that cover all user requirements, then the developers will follow the API, because is more easy for them also use an API that reinvent the wheel. But nothing of this happens and will never occurs. We are talking here about GNOME, not about KDE. GNOME only provide what they think is ok and instead of facilitating change they makes it increasingly complicated for everyone.

[p134c0d3]

I was thinking through this today, and what if it'd be possible to integrate this into something like dash to panel? I have my Dash to Panel set up as a top bar (more customizable than the default Shell top panel), and it shows on all monitors. Then I have Dash to Dock as the normal extension. Then it'd be less likely to break with each Gnome version update. I'll probably need to put a feature request in with Dash to Panel maintainer...

@gonzaarcr if I put this in as a feat. request with the Dash to Panel maintainer, what would I call it? That I want them to allow inserting modules/extensions/applications (<~ The name in question) into their list? Example below:

[lestcape]

@probonopd, this probably can be done, but it is a pain, specially will be a big pain in Wayland. You can not insert a GUI component inside a panel from outside the main process where the panel is created. So, the more plausible way to do that will be create your own panel and insert your global-menu there, instead of to be inserted in the GNOME shell panel. But your own panel means your own widgets also. The project that make a thing like that is ValaPanel (https://gitlab.com/vala-panel-project/). But ValaPanel is working with Gtk not with Clutter, so if you use ValaPanel in GNOME, you will have a completely different GUI than the default and will be difficult to accommodate all things together (for example: both GUI should have similar themes). Also, you need to take on account that ValaPanel work on Wayland thanks to the gtk-layer-shell library (https://github.com/wmww/gtk-layer-shell). That library at same time, works thanks to the Layer Shell protocol of Wayland , that is not included in GNOME. So, ValaPanel not work on Wayland-GNOME. If you want that it will work, you need to create a solution from scratch if you want to support create a panel in Wayland using GNOME and it's difficult to me imagine how something like that could be done.

That said, it is clear from my comment that it is actually ValaPanel and not this project that might be closer to creating something like this, but really it is still a long way from being able to actually do something like this on GNOME. GNOME should support the Layer Shell protocol of Wayland, but seem to be that they are not really motivate to do that yet. See: https://gitlab.gnome.org/GNOME/mutter/-/issues/973 and https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1141

[p134c0d3]

create your own panel and insert your global-menu there

So inserting it into the Dash to Panel wouldn't work? Sorry, I'm not too familiar with how the Gnome Shell works personally (usually run KDE), but didn't Dash to Panel just create their own GTK panel and import the widgets from the shell? If they did, what would be stopping them from importing the Global Menu as well?

[lestcape]

So inserting it into the Dash to Panel wouldn't work?

Define "not work". It will work, but Dash to Panel is already an extension of GNOME. So, it can be break with virtual every Gnome release. This is what the OP want to avoid. To be used with Dash to Panel you also will need to create an extension of GNOME also and detect if the extension Dash to Panel is already loaded or no and also resolve the problematic of what will happens if Dash to Panel is loaded after your own extension. You can not control the order of how gnome-shell load the extensions. So, in that way you have added exponentially more reasons for all of this to break after a GNOME update.

Dash to Panel just create their own GTK panel and import the widgets from the shell?

Not really. The panel is Clutter, not Gtk and Dash to Panel is an extension of GNOME that need to detect and destroy several shell default components (the Dash) and create new ones (the panel). That will be done using some of the internal implementation of the shell not creating the panel from scratch itself. And for that it will need to be loaded in the default process of the shell as an extension. So, is very easy to be break like any other extension.

what would be stopping them from importing the Global Menu as well?

Dash to Panel have not any way to import something. It's you who need to hack how Dash to Panel is implemented and find a way to insert your widget in the panel that Dash to panel create, that is as same time a panel of gnome-shell. That is why if your extension is loaded as a shell extension you can have access to that panel and can modify it. But that also means that what you do is an extension of the shell and it can break.

[lestcape]

What a gnome-shell extension do is be loaded in the same process where the shell is running, gain access to the shell implementation and use it (really hack it) to achieve what they want, using the internal functions of the shell. An extension can easy break because it used the internal shell implementation that change between releases. So, if you not update your extension to work with the next version you have a lot of probabilities that something that you used changed and cause a crash when you try to used it as it was.

What an extension do in KDE is totally different. An extension in KDE is not loaded in the same process where the KDE shell is running and it have not access to the internal implementation of the KDE shell, because the KDE extension can only use a preconceived KDE API that not change between releases. So, the KDE shell can be updated internally without to break the extension in that case. That would be the pro, but the con is that a KDE extension is limited to what the preconceived API allows, while a gnome-shell extension is practically not limited to anything.

[p134c0d3]

Well that doesn't give me a warm and fuzzy feeling about it all.

[lestcape]

It's what it's. But i will said it more clear and short: Create an extension to extend an existing extension, while can be done is just a crazy idea, that will end broken for sure every release.

[p134c0d3]

So theoretically, how can we solve it?

[p134c0d3]

Very well said the very true. Unfortunate but true. Guess I'll just stick with KDE for now since they actually listen to the community