Conversation
It's used to manage X windows and workspaces, and we can't use it in wayland, I've commented most of the code here out and would remove them later. Signed-off-by: Chihurumnaya Ibiam <ibiam@sugarlabs.org>
It directly uses x11, so this is a test to see how sugar would respond without it. Signed-off-by: Chihurumnaya Ibiam <ibiam@sugarlabs.org>
I've replaced every use of Gtk.Settings with Gio.Settings as in Wayland, the settings are obtained from a settings portal or by reading the desktop settings from Gio. I've moved adding the sugar icons path to IconTheme into homewindow as I changed from using the default as trying to get the default earlier seems not to work as it returned None. I'll see if I need to revert this later. Use Gdk.Seat for input device handling in cursortracker as in Gtk4, input handling has been factored into Gdk.Seat and this prepares us for that. I did this because I ran into issues when trying to get the default Gdk.Display, and this was an attempt to fix it, I'm yet to test if it works as intended as I ran into another issue which I'll be fixing next. The issue is with initializing Gtk as in Wayland Gtk seems not to be initialized, a possible fix for this is looking at using Gtk.Application as it doesn't require you calling Gtk.init directly - which did me no good - as the Gtk.Application startup signal handler calls it for you. Signed-off-by: Chihurumnaya Ibiam <ibiam@sugarlabs.org>
I decided to make the Sugar shell because it's the point of registration for all running activities within Sugar, and it makes sense to have this be the main application that keeps track of windows to activity mapings which it already did. I've also removed the use of SugarExt.wm* to get activity related data like bundle_id and activity id and directly set this data as attributes in the window itself in sugar-toolkit-gtk3. Wnck is no longer used as window management is now being handled by Gtk.Application, so every Wnck related functionality has been removed or replaced. Every use of xid to identify windows have been removed and replaced with bundle_id as that's now set on each window, xids were how X got window IDs and we no longer need to do that. My use of the shell in jarabe.main isn't pretty at the moment and might change, that seems a great place to actually start the shell before its use anywhere. Some functions in jaraba.main are no longer needed and I've removed them and moved any functionality that's needed to other functions, there was a lot of checking which we don't need to do anymore. Signed-off-by: Chihurumnaya Ibiam <ibiam@sugarlabs.org>
Haven't figured how to reproduce this without Wnck, so I'm skipping it for now and will come back to it later. Signed-off-by: Chihurumnaya Ibiam <ibiam@sugarlabs.org>
I've replaced more use of GdkX11.X11Window with a Gdk.Window while setting the foreign attribute on the window, I haven't passed a parent because in most cases the default Gdk.Display is used and it automatically becomes the parent if None is passed as the parent. This also included removing any xid related use, although I've replaced it with bundle_id, I'm yet to test if that's the best replacement and will change it if I see it's not. I've also removed the use of process_updates to force expose events to be delivered immediately which is useful for updating the UI. Signed-off-by: Chihurumnaya Ibiam <ibiam@sugarlabs.org>
This has been replace by bundle_id so I'm removing its uses. I've also removed the use of SugarExt in journal and the launcher and directly set the needed properties on their respective Gdk.Windows. In the shell, I accessed the necessary attributes through Gdk.Window as that's where they're set now. Signed-off-by: Chihurumnaya Ibiam <ibiam@sugarlabs.org>
|
Hey @chimosky, I'd like to help continue this port Should I submit this as a commit to your branch? or would you prefer I open a separate PR that you can select from? |
|
Firstly, I'd love if you have a development environment setup - sugar live build -, if you don't then please go do that. We can use this branch as the base for the Gtk4 port, so you can open PRs to this branch. |
I've only moved the use of sugar3 to sugar4. I'm thinking of using Casilda as a compositor, so I've imported it here and will test it. Signed-off-by: Chihurumnaya Ibiam <ibiam@sugarlabs.org>
Gtk4 moved to GdkClipboard from GtkClipboard, this is moving away from GtkClipboard. Signed-off-by: Chihurumnaya Ibiam <ibiam@sugarlabs.org>
Referencing dbus.service after importing dbus doesn't seem to work, importing service directly from dbus works. Signed-off-by: Chihurumnaya Ibiam <ibiam@sugarlabs.org>
Gtk.Menu is no longer supported in Gtk and PopoverMenu replaces it. I've also imported service directly from dbus, because using it via dbus throws an AttributeError. Instances of Gtk.MenuItem have also been replaced with Gio.MenuItem, or Gio.Menu when that makes more sense. Signed-off-by: Chihurumnaya Ibiam <ibiam@sugarlabs.org>
I've replaced Gtk.ToolItem with Gtk.Box as ToolItem is no longer supported in Gtk4. Drawing is also handled with snapshot, as that's how Gtk4 implements drawing. Signed-off-by: Chihurumnaya Ibiam <ibiam@sugarlabs.org>
|
Understandable, found the Nix flake and Flatpak setup in gtk4 for testing the toolkit, but i don't see any documented setup for running the full Sugar shell with GTK4 and Casilda. How do you have your dev environment set up for testing shell changesbefore opening PRs? |
|
I talked about using the live build, if you looked, you'd have found it - I'm currently running Debian 13, so you might have to upgrade yours -. The build commands for the core Sugar APIs can be run there, you can look here to see all of them, the Python paths change when you upgrade so you'll have to take note of that. You should also run The Casilda Readme shows you how to install it, every other sugar related package you'll need to build and install is in the links above including how to build and install these packages. Be sure to read the information in the live build section of the docs. Hope this helps. |
2 participants
I'm pushing because I want to take a break from looking at this, anyone is welcome to build on this.
I've also used casilda as a wayland compositor, wanted to test it with Sugar as it's a lightweight compositor we can use.
If you intend to continue this, you should have the sugar-live-build setup as that's how you can test changes to Sugar and its core APIs.