-
Notifications
You must be signed in to change notification settings - Fork 130
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
Update for Gnome 45 (and all the changes that will be needed) #576
Comments
|
Is there a possibility to use something like babel to convert the gnome 45 code back to code that can run on previous versions? Or can we use something like a pre-processor to have an if at the top around the imports? This would make installing from source a bit harder. We likely can't just symlink the repo anymore. |
Unfortunately there is no way - babel doesn't know/do GJS (old GJS import approach etc.). Plus, there's actually much deeper changes that are needed - e.g. converting all modules to ESM classes and replacing quite a bit of code and implementations (many are gone and some have no provided replacements). Just in the 1.5 modules I've ported so far - had to redo implementations quite a bit. In other words, it's a very significant change that impacts all our modules (and not just the importing parts). |
After looking briefly at https://gjs.guide/extensions/upgrading/gnome-shell-45.html I think in principle I think it should be possible to write a transformer for the code (note that I haven't actually done that for JS before^^). We might require to use some specific conventions and we maybe couldn't use all module features (not sure what all is available in GJS). I think we mostly only need to remove the "export" and transform the import lines, right? We might also be able to do that much simpler by just including special comments and using a bit of bash to choose which import style to use and to remove the export keyword. E.g. with code like this: //// start legacy imports
// const GLib = imports.gi.GLib;
//// end legacy imports
//// start gnome 45 imports
import GLib from 'gi://GLib';
//// end gnome 45 imports
export function f() {} we only need to remove the "gnome 45 import" section, uncomment the "legacy import" section and remove the "export" keyword. I haven't looked too closely at your gnome 45 port PR, but it looks like we might need to provide two The question is just if it's only worth it. And I think it's only worth if there are no other big incompatible changes. And if extensions.gnome.org would permit uploading that generated code. I would maybe wait until your gnome 45 port is mostly done to decide if we want to do that or not. |
Hey @Lythenas, In essence, no. Please look at the changes needed for Gnome 45: https://github.com/paperwm/PaperWM/pull/605/files. Over Bascially, the However, I'm happy to be proven wrong! Feel free to work on this or a proof of concept for it - but this is definitely not something I myself would |
This is just to port to Gnome 45 as is. However with ESM - there is much scope to make PaperWM much simpler, idiomatic, and remove the complicated dependency ordering of modules by moving to exported parent classes for modules (for example dash-to-dock, just-perfection, and other extensions have done that for Gnome 45) - but it's pretty much a structural rewrite/redo for modules. |
Fixes #576 Gnome 45 will require every gnome extension to be updated in order to work in 45. That is, no previous extensions will work on 45 due to moving to ECMAScript modules (meaning that the previous gnome extensions imports won't work). This PR is for implementing full Gnome 45 support in PaperWM. Update: It is done - long live Gnome 45!
This Issue is to capture Gnome 45 related things.
Gnome 45 will require every gnome extension to be updated in order to work in 45. That is, no previous extensions will work on 45 due to moving to ECMAScript modules (meaning that the previous gnome extensions
imports
won't work).This also means that changes to PaperWM for Gnome 45 will not be compatible with any previous Gnome Shell version (e.g. we'll need a new branch here). This is going to make it a little more difficult to maintain PaperWM for previous gnome versions - e.g. how are we going to manage backporting fixes, new features etc. and testing across branches?
On the plus, I guess it means a cleaner slate for PaperWM (and we can remove some workarounds to address differences in 44, 43, 42)...
I'm generally on the latest gnome version quickly - and target that version for PaperWM fixes, features, etc. Then do some (light) testing on gnome 42 & 43 (using virt-manager etc.).
Given the architectural changes in GJS etc. in Gnome 45, I think we'll quickly get to the point where new features (and fixes) won't make it to prior gnome shell versions, unless others can jump in to backport those fixes (and maybe features of interest).
The text was updated successfully, but these errors were encountered: