Giters

GSConnect / gnome-shell-extension-gsconnect

KDE Connect implementation for GNOME

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

GTK4 & LibAdwaita Migration

Doomsdayrs opened this issue · comments

commented

Describe your request

GSConnect is out of sync with the rest of the GNOME ecosystem.

There is no issue on this repository tracking work, sentiments, or efforts in GTK4 migration.

Proposed solution

  1. Migrate to GTK4
  2. Migrate to LibAdwaita

Alternatives

  1. Migrate to GTK4

GSConnect version

56

Installed from

OS package manager

GNOME Shell version

45.3

Linux distribution/release

Fedora 39

Additional context

No response

commented

There is no issue on this repository tracking work, sentiments, or efforts in GTK4 migration.

True, though it's been discussed in the context of some PRs.

The main issue, last I briefly looked at it, is that GSConnect is using a lot of features that aren't available in Gtk4.

Granted, that primarily refers to the backend daemon, which does things like clipboard manipulation, input device mirroring/relaying, and consumes other somewhat low-level APIs that were (intentionally) left behind in the transition from Gtk3 to Gtk4.

In theory, the actual extension code and the Preferences could be ported to Gtk4/Adw and modernized.

But then we'd have a split codebase that would require both Gtk3 and Gtk4 as dependencies. It would also probably require some duplication and migration of code that's currently shared between the frontends and backend.

...It appears I also have a set of data/ui_gtk4/ files in my local clone of the repo (not published to any branch), that contain the results of attempting auto-conversion of the UI definitions from Gtk3 to Gtk4 with gtk4-builder-tool simplify --3to4. It didn't go great.

commented

The main issue, last I briefly looked at it, is that GSConnect is using a lot of features that aren't available in Gtk4.

Let's list them out!

Granted, that primarily refers to the backend daemon, which does things like clipboard manipulation, input device mirroring/relaying, and consumes other somewhat low-level APIs that were (intentionally) left behind in the transition from Gtk3 to Gtk4.

So we need to figure out alternatives & solutions to.

  1. Backend Daemon
  • Clipboard Sync
  • Input Device Manipulation
  • (list here?)

But then we'd have a split codebase that would require both Gtk3 and Gtk4 as dependencies. It would also probably require some duplication and migration of code that's currently shared between the frontends and backend.

Most unacceptable!

...It appears I also have a set of data/ui_gtk4/ files in my local clone of the repo (not published to any branch), that contain the results of attempting auto-conversion of the UI definitions from Gtk3 to Gtk4 with gtk4-builder-tool simplify --3to4. It didn't go great.

Sounds about right for an automatic code generator!