GNOME 45 support

[yochananmarqos]

There are breaking changes which will require a separate release for 45 and <=44:

See https://gjs.guide/extensions/upgrading/gnome-shell-45.html

[scherepanov]

Great news!
At least, all old versions <=44 will be on stable code version :-) no upgrades for them.
And all code that branching based on gnome-shell version now can be removed.

When gnome-shell 45 will be available?
Can you submit PR with changes to make gTile to run on v45? Would greatly appreciate our efforts.

[yochananmarqos]

GNOME 45.beta is currently available. See the GNOME 45 Schedule for more info.

This was just a heads up. I'm only a package maintainer, not a developer.

[scherepanov]

Thanks!

[GerryT11]

FYI, here is some more information on the changes in Gnome 45 for extensions: https://blogs.gnome.org/shell-dev/2023/09/02/extensions-in-gnome-45/ Thanks for gTile!

[okoponen]

Have been using gTile for ~3 years and basically, can't live without it.

Tried to convert this to Gnome45, but seems that TypeScript is not able to resolve the new import paths e.g.

import GLib from 'gi://GLib';

For the most parts, these can be circumvented by

// @ts-ignore

but for any class, that extends anything exported, e.g. extending the class app

export default class App extends Extesion

or

const GTileStatusButton = GObject.registerClass({
    GTypeName: 'GTileStatusButton',
}, class GTileStatusButton extends PanelMenu.Button {

the extended class typing should be needed to get the super-methods, e.g. in the latter example, this.add_actor()

I suspect, that dropping the TS support would make migration to Gnome45 easier. That said, the benefits of TS are great and falling back to plain JS is something I would encourage.

Not sure, what options there are, other than trying to manually fix the remaining things on JS-converted code directly or somehow fix the imports for GJS. Seems that most GJS examples area still heavily using the "imports" pragma.

[scherepanov]

Well. That is a ¨diffucult" problem.
I really want to stay on TS (you said you want to encourage, but I assume it was a typo and you really mean you do Not want to encourage).

Hopefully gTile user community will chip in some solution to problem?

I think quite a few gnome-shell extensions are using TS, and facing exactly same problem. Will watch what solution will popup in a wild.

[okoponen]

I encourage TS usage. Use it in work and love it.

I have presented this dilemma to Gnome Discourse and tagged a previous TS in GJS evangelist to the thread. Fingers crossed...

[pavangayakwad]

I am on Gnome 45+ (OpenSUSE) and looking forward to this fix desperately!

[scherepanov]

@okoponen any words from GJS evangelist?

[okoponen]

@scherepanov

Zero answers to my post. There was another similar question, which did not get that much attention either...

Not sure if the easiest way to solve would be to build it as JS, then replicate the code in TS and spam ts-ignore like a crazy person.

[renataogarcia]

@okoponen

Maybe use paths in TS config? Something along these lines:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "gi:*": ["path/to/match/*"]
    }
  }
}

[okoponen]

@renataogarcia
Hi

Yes, fixing the import path is needed. Unfortunately, the imports used are usually on gresource-format, so even when using the path
e.g.

$ gresource list  /usr/share/gnome-shell/org.gnome.Extensions.src.gresource 
/org/gnome/Extensions/js/main.js
/org/gnome/Extensions/js/misc/config.js
/org/gnome/Extensions/js/misc/extensionUtils.js

you first need to extract these to a tmp-dir and then import from there.

AFAIK, this would solve perhaps the imports using

import {Extension, gettext as _} from 'resource:///org/gnome/shell/extensions/extension.js';

importing methods.

For the

import GLib from 'gi://GLib';

I have not yet found a viable solution, where to find these GLib etc. in TS/JS readable format. Not sure, if something like
https://github.com/gi-ts
would help here.

[HeavenVolkoff]

Maybe https://github.com/gjsify/ts-for-gir can help?

It has pre-generated gobject types for typescript available on NPM:
https://github.com/gjsify/types
https://www.npmjs.com/package/@girs/glib-2.0

[okoponen]

Maybe https://github.com/gjsify/ts-for-gir can help?

It has pre-generated gobject types for typescript available on NPM: https://github.com/gjsify/types https://www.npmjs.com/package/@girs/glib-2.0

Yes, these do help to the 'gi://' typed imports. So far, generating these myself seems to work, but managed to (quickly) generate only part of those imports (Shell, Gtk). Using the pre-defined packages did not work as per documentation and did not yet find sufficient time to troubleshoot, why those did not work.

AFAIK, this package will still leave the 'resouce:///org.gnome.shell.....' styled imports unsolved.

[mfixman]

Is there any temporary patch I can apply to make gTile compatible with GNOME 45?

[scherepanov]

It appears, we do not have any workaround. Currently it is not possible to build gTile for GNOME 45.

[sardaukar]

That's terrible news, gTile is one of my "must have" extensions to cope with Gnome's default window placement logic :(

[HeavenVolkoff]

@okoponen I think the 'resouce:///org.gnome.shell.....' imports can be solved by adapting this project: https://github.com/gjsify/gnome-shell/tree/main/packages/gnome-shell (from the same creator of ts-for-gir). Unfortunately, the package can't be used directly because the glue code present in the .ts files is using the old import syntax. But maybe it works if you copy the required typing definitions from https://github.com/gjsify/gnome-shell/tree/main/packages/gnome-shell/src in the expected hierarchy and instruct the ts-compiler to alias the 'resouce:' import using the paths config:
https://www.typescriptlang.org/tsconfig/#paths

{
  "compilerOptions": {
    "paths": {
      "resource:///org/gnome/shell/*": ["./@types/gnome/*"]
    }
  }
}

[risen]

From https://discourse.gnome.org/t/migrating-exteions-to-gnome45-in-typescript/17313/2 @ronanru said:

add this to any file with.d.ts extension.

declare module 'resource://*';

[schnz]

I think quite a few gnome-shell extensions are using TS, and facing exactly same problem. Will watch what solution will popup in a wild.

I've just read through this issue and did a bit of research on the subject. Although I've never written or contributed to a Gnome extension, I would probably refer to https://gitlab.gnome.org/BrainBlasted/gnome-typescript-template/ as a starting point, which I found referenced here. It seems to include lots of type definitions. Although I am not sure if those are the ones that are actually used by this extension.

// Edit: Sorry, nevermind. I thought I found a GNOME extension project with full TS support that could be used as starting point. But the project does not seem to be an extension after all.

---

Is anyone currently actively working on a GNOME 45 compatible release? I may find a day or two next week to look into it and would use the gnome typescript template as a starting point. But as I said, its new territory for me - so don't get your hopes up too high.

[okoponen]

@schnz

I did start the migrate, but not currently working actively with it. I made a fork
https://github.com/okoponen/gTile-gnome45-wip

Specifically, the problems I encountered, what I have done, can be found in
https://github.com/okoponen/gTile-gnome45-wip/blob/main/GNOME45-migration.txt

I am happy to help, but not sure how much help I am, having 0 knowledge of Gnome developing is surely not helping...

[schnz]

Preliminary assessment:

• I've managed to get the type completion working for both gi://* and resource://* imports.
• I've not yet managed to compile the project due to lots of (seemingly legit) errors (118 errors, to be exact)
• I could not (yet?) find all GNOME-45 equivalent imports for everything:
  • imports.signals seems to be no longer available. IMO this requires refactoring of all classes that are currently passed to Signals.addSignalMethods by extending them from GObject.Object (see also Migrating Shell Classes)
  • imports.mainloop seems to have no equivalent. It seems to be of use for one purpose only, which is here. Maybe someone more familiar with the extension can explain if/why this is needed and if its possible to implement differently. (Edit: MainLoop is still available for use)

I will give this another day of work and see where this goes. Hopefully at the very least someone else find some use in what I did. Maybe I even get it running. Lets see.

[HeavenVolkoff]

@schnz imports.signals is not exported to ESM. I am not sure if it is deprecated, but there is a notice in gjs docs:
https://gitlab.gnome.org/GNOME/gjs/-/blob/master/doc/Signals.md#import

But as you pointed out, we can replace that behavior with GObject.registerClass:
(WebArchive link because https://gjs.guide was down at the time when I was writing this)
https://web.archive.org/web/20230529160535/https://gjs.guide/guides/gobject/subclassing.html#subclassing-gobject

About the MainLoop usage, I think it should be replaced with a setInterval now that gjs supports it, and backward compatibility is being broken anyway.

I want to help with the porting, but I am very busy at work rn. However, whenever I get some free time and if this is not solved yet, I intend to attempt porting gTitle to gnome 45, because it is an exceptionally useful extension that has been a part of my workflow for some time, and I am missing it quite a lot

[schnz]

Quick update on the situation:

TL;DR I am working on a rewrite of the extension.

Rationale
My original approach was to adapt the existing code base for compatibility with Gnome 45 (see PR #340). The plan was to get it up & running first with replaced imports and no errors at compile time and then step by step refactor the remaining code until the extension is fully functional. However, even though I made a good progress in getting a compile-time error-free project, I wasn't really actually be able to compile it with the Bazel toolchain that gTile uses. I spent a fair amount of time in learning the Basics of Bazel and its rules-system but at the end of the day I was only fighting with the rules that were supposed to ease the experience in building the project (but failed to to do so, mainly because it relied on older TypeScript and pnpm versions than the current stable ones). I also failed at reproducing the build pipeline manually.

So instead, I tried to setup a minimal TypeScript project for a Gnome extension from scratch and the plan was then to copy & paste the relevant parts from gTile over to the new project. But there is some refactoring required to get the project running due to deprecation of APIs that are no longer available in GJS 1.78 (Gnome 45). So I somehow ended up simply porting gTile step by step and rewrite all the code that is either completely deprecated (and requires refactoring) or which idioms are no longer recommended to be used (and thus it should be refactored).

The good news is, that there will be a Gnome 45 compatible gTile version in hopefully a week or so. The code base will be (IMO) much more easily maintainable and also relies solely on npm (and tsc) as a build tool (at least for now). It also has phenomenal type support, thanks to the work gjsify. The bad news is that I don't know how this PR will be received by the project maintainers who will have to deal with a complete new code base in terms of its directory structure, module splitting and build system.

[ritchie888]

Much appreciated, @schnz (and anyone else working on this port)!

[scherepanov]

@schnz great news!

gTile would benefit from full re-write!

Instead of PR, create a new branch. I suggest to add you to admins of gTile, let me know.

We should try to make new gTile compatible with pre-45, but not necessary if it is too much work.

All parts of current gTile have satisfying functionality and can be ported to rewrite (of course with better refactoring). Exception is autotiling - it has to be deeply redesigned.

Autotiling is very tricky - there is a huge demand form users, but extreme variety of autotiling. gTile implement only few autotilings and it fits demands of very small fraction of users. (My estimate of gTile user base install is 35 000 - 50 000, based on downloads of new versions)

We need to completely rewrite autotiling. I had an idea for a long time how to satisfy all users demands for various autotiling. Generally speaking, I want to have plugin with code editable straight in preferences and saved in config. gTile will load plugins code from config on start, and will execute in sandbox. We will pass to plugin object with all required info for autotiling - list of windows, their sizes/position etc. Plugin will be responding with list of windows to resize and their new sizes/positions. Grand idea is to let users to edit plugin code on a fly, save to config and reload plugin, and have new code running. Plugin will be executing in sandbox, dynamic code load will not be a problem. gTile will provide keyboard binding for plugin invocation. Preferences will have per-plugin config. Goal is to let users to create autotiling, publish it (for starting to gTile repo), and all users will be able to use it.

Good goal would be to implement i3-like windowing control with plugin. And so on, there is unlimited number of possible autotiling that I can tell right now.

I am looking forward to make gTile more versatile, providing best gnome-shell autotiling capabilities.

[schnz]

As it turns out, the preference window also requires a rewrite due to a breaking API change. I just now realized that gTile happens to have what is called global hotkeys that are supposed to work even when the extension is disabled. I find that feature counterintuitive, to say the least. Is there any (valid) reason to keep them? Because I am inclined to remove this feature and make hotkeys (and everything else) only work when the extension is active.

// Edit: Oh. Nevermind. The description was a bit misleading. I thought the hotkeys were supposed to work even when the gTile extension is disabled. But it is only meant to say that there are some hotkeys that only work when the gTile overlay is shown and others that work even when the gTile overlay is hidden.

While I am at it, a little status update: The rewrite turns out to be quite time consuming. I am working full time on it and may have reached a little over ~50% progress.

[scherepanov]

Yes, gTile packs quite a lot of functionality. Will take some time to implement it all.

[SoiledBrush]

Can confirm the issue @okoponen defined.
Have to activate gTile with Super+Enter after logging in or after waking from sleep for shortcuts to start working.

[schnz]

Thanks for the reports!

@hackoder : I can confirm the issue. Will work on it. fixed.

@okoponen @SoiledBrush : Confirmed. Keyboard shortcuts were indeed not registered until the first time the overlay was opened. Fixed in the latest version.

// Edit: @hackoder It's wired. The Gnome API provides a function move_resize_frame that allows to both position and resize a window in a single operation. That's what the extension used and it seemed to work well. For no apparent reason, this fails to reposition the gVim window. I couldn't find any indication as of why gVim in particular is affected by this. The extension now first calls move_frame to relocate windows (this works for gVim as well) and only after that makes the call to move_resize_frame.

[scherepanov]

Yes, sometimes gnome-shell is not moving window for no apparent reason. Seems to be a bug in some underlying API. Yes, we had to always do move_frame and then move_resize_frame to make it working for all windows.

[marinierb]

There are two preset actions that are not working as expected for me. Not sure what their names are but in dconf, the keys are labeled action-autotile-main and action-autotile-main-inverted.

Expected behaviour
These actions are supposed to put the active window full-height on one half of the screen and then tile the remaining windows in the other half of the screen.

Observed behaviour
On the side that the windows are tiled, there is an extra empty tile that is generated for a non-existant "phantom" window.

[schnz]

@marinierb That does indeed sound like some kind of phantom window. Can you think of any application running in the background that might be detected by gTile as such? Are there any more information you can provide to reproduce the bug? Maybe a (scaled down) screenshot as well?

[marinierb]

@schnz Hah! This is the culprit: https://extensions.gnome.org/extension/2087/desktop-icons-ng-ding/
The problem goes away when I disable it.

[marinierb]

Everything else works well for me. Thanks for doing this!!

[schnz]

Glad you found the root cause. I'll take a look at the extension to see whether gTile can detect the phantom window that it seems to create.

I also just pushed a commit that fixes another problem with autotiling (the feature you refer to) on multiple monitors. It was rearanging windows from all monitors of the current workspace as opposed to only the windows on a single monitor.

[JMurph2015]

Sorry I haven't been around much recently (a lot of other code to work on 😁 ), but I just wanted to toss in that I've wanted to create an abstraction layer between gTile and the Gnome GJS API for a while. Basically restructuring the code so that there's a main controller class that works entirely in abstract terms and then have it call an API abstraction layer to move/resize windows/register hotkeys/etc. That way if Gnome changes underneath us, we just have to update the abstraction class and all feature development can go into the controller class with no baggage from Gnome.

[tun0]

I noticed one regression: when a window is maximized, resizing doesn't work. Un-maximizing the window makes the resizing work again.

Also, I always had issues with resizing urxvt: it'd leave gaps at the right & bottom due to urxvt own snap-to-font-size-during-resize feature (no idea how to properly call it 😅). With the beta it doesn't seem to work at all. The "workaround" still works though (goal: have it use it use the right two-thirds of my screen): use win-right to snap it to right half of the screen, then drag the left side to towards any window already occupying the left one-third of the screen.

[schnz]

@tun0 Regarding the issue with maximized windows that cannot be resized: Which version of the extension are you using? This should have been fixed prior to the beta (in commit hash a12c552).

I also tried to reproduce the issue with urxvt to no avail. Both moving and resizing to all screen edges works fine. I am using the extra/rxvt-unicode Arch Linux package though. I suppose you are on a different distro?

[tun0]

@tun0 Regarding the issue with maximized windows that cannot be resized: Which version of the extension are you using? This should have been fixed prior to the beta (in commit hash a12c552).

I was indeed missing a bunch of updates. My bad!

I also tried to reproduce the issue with urxvt to no avail. Both moving and resizing to all screen edges works fine. I am using the extra/rxvt-unicode Arch Linux package though. I suppose you are on a different distro?

I'm using the same package, but on Manjaro.

Notice the subtle difference between these screenshots:

Resized with gTille:

Resized using "workaround":

The gaps do seem much smaller than before though. Than again, I got used to not use gTile to resize urxvt, so been a while since I saw the previous gap-size 😉

[schnz]

@tun0: I am afraid that there is nothing I or the extension can do about that. As you already pointed out, the terminal grows in height one terminal row at a time. So pixel-perfect resizing is inherently impossible, i.e. unless you maximize the window in the vertical direction (what you essentially do with the Super+Right shortcut). For instance, you won't be able to have the terminal in the center of the screen (without touching the left or right edge of the monitor) while at the same time take the full height of the work area.

[tun0]

Figured as much. More of a Gnome restriction than gTile issue I guess. I'm already doing the workaround on auto-pilot, so it's not that much of an issue any way 😄

[schnz]

@scherepanov Do you mind if I create one (maybe two) new repositories under the gTile organization for the npm package dependencies? I had hoped that the gjsify owner would be interested in publishing an up-to-date package but I haven't heard back yet and we need publicly available npm packages to allow building the extension without a personal GitHub access token. I wouldn't yet bother to create a GitHub pipeline for publishing the packages but I would register an npm organization and invite you (+ possibly others from the GitHub gTile organization?) to it, if you give me your name.

[luksa]

@schnz Thanks so much for this rewrite. I've just tested the new insets stuff, which seems to work great, but the window-margin setting is not yet honored.

[luksa]

@schnz I went ahead and implemented support for window-margin myself. See #345. Let me know if you want me to change anything.

[kamil-karkus]

@schnz I don't know if it's a bug or not but overlay window isn't rendered correctly (look at font in the title and buttons border), but this is not a regression, since same thing happens on gnome 44 and below
https://i.imgur.com/6MkiAfd.png

[schnz]

Beta Completed

Thanks to everyone who participated during the beta phase. Many bugs that I was unaware of were fixed during that time. I just committed what I consider the final state of the rewrite. I believe its ready to be published. I apologize that the preference dialog is not part of the first public release. There is a section in the README for the time being that explains how to change settings with the DConf editor. Its less convenient but it is a workaround until the preference dialog is rewritten too (which I also plan to do but in a separate PR).

Also thanks for all the support, both verbally and even monetary from some of you! I really appreciate that and it helped me to stay motivated during the rewrite.

@scherepanov I removed the draft flag from the PR. Since I consider you the core maintainer of gTile I would like for you to have a final look at the PR and if you think it requires any changes prior to being merged. Should you be happy with its current state, feel free to merge it at your own discretion. In the most recent commit i added a GitHub workflow that is supposed to automatically create a release whenever a tagged commit is created. But I am unsure if that can be tested. I believe it has to be tested once the PR is merged.

---

@schnz I don't know if it's a bug or not but overlay window isn't rendered correctly (look at font in the title and buttons border), but this is not a regression, since same thing happens on gnome 44 and below
https://i.imgur.com/6MkiAfd.png

I also noticed that. Yet I couldn't figure out why this is the case. I also believe its not a regression because I initialize the GUI elements in the same way as the original extension did.

[scherepanov]

Good job @schnz !
In my opinion, new version of gTile should be deployed to EGO when we will have a working preferences dialog.

[marinierb]

The "phantom window" problem I was having is fixed! Thank you!

[tun0]

As you already pointed out, the terminal grows in height one terminal row at a time. So pixel-perfect resizing is inherently impossible, i.e. unless you maximize the window in the vertical direction

Could it be viable to have gTile do the maximizing vertically thing, obviously this would only apply for windows aligned to the left/right edge of a screen.

[schnz]

Could it be viable to have gTile do the maximizing vertically thing, obviously this would only apply for windows aligned to the left/right edge of a screen.

In my opinion: no. For a couple of reasons:

• The window would take the entire height of the work area, wouldn't it be for the applications itself that denies that. In my opinion, there should be an option on the application-level to opt-out from that behavior.
• A few aspects why I wouldn't wanted this to be implementing in gTile:
  • If the user configured an inset larger than 0, it would practically (yet implicitly) prevent to have vertical fullscreen windows. So the behavior would be different depending on whether an inset is configured or not - which is not intuitive.
  • To be consistent, this feature would have have to be applied for all gTile operations, not just the "window placement through grid selection"-feature. There are also shortcuts to expand window edges towards an arbitrary direction. There are shortcuts to move windows towards an arbitrary direction. And some more (such as autogrow). All of these features (IMO) should be expected to put a window to full screen as soon as it touches the edge of the screen and takes the full height of the work area. IMO that would, again, be an inconsistent behavior. Why would a window become maximized when I merely want to move it?

May I suggest to consider using a different terminal emulator? I can recommend alacritty. It allows to configure a custom opacity, custom font, even to hide window decorations if that is desired.