Skip to content
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

Make compile #2225

Draft
wants to merge 109 commits into
base: main
Choose a base branch
from
Draft

Make compile #2225

wants to merge 109 commits into from

Conversation

jeremypw
Copy link
Collaborator

@jeremypw jeremypw commented Jun 30, 2023

This based on gtk4 branch up to commit "First compilable lint-free version"(be0ce20d8679315424f58b88dff93e225ddce861)` rebased on main plus a few extra commits to make it compile again.

The changes should be near the minimum to make it compile without removing widgets but still affects a large amount of code unfortunately.

The PR builds and runs (as io.elementary.files) but very little works

@@ -260,141 +265,148 @@ public class Files.View.Window : Hdy.ApplicationWindow {


button_forward.slow_press.connect (() => {
get_action_group ("win").activate_action ("forward", new Variant.int32 (1));
activate_action ("forward", new Variant.int32 (1));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't working anymore for some reason

Copy link
Collaborator Author

@jeremypw jeremypw Jul 16, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The gesture is not triggering - you seem to need to add propagation_phase = Gtk.PropagationPhase.CAPTURE to the button gesture properties. Not sure why it works in main without it, but not here though. Only the GestureClick needs this presumably because you are handling release? Strangely, if you also handle press and claim the gesture at that stage you do not need to set the propagation phase to CAPTURE 🤷 Something is handling the press gesture before the BUBBLE phase and stopping the button from working otherwise.

The ButtonWithMenu can be simplified anyway - we don't need to chain signals and focus chain/mnemonic handling is probably redundant.

@jeremypw
Copy link
Collaborator Author

@danirabbit Is it worth maintaining this branch? Or would it be best to start again once all the possible Gtk4 prep has been done in the Gtk3 branch to reduce the porting diff? All the code that could be used for reference is already in the gtk4- branches I think. There are a lot of conflicts now. Is it still the intention to have a single Gtk4 port branch once all the prep is done? What diff is acceptable?

@danirabbit
Copy link
Member

@jeremypw yeah I was thinking of starting yet another branch with just those changes that don't make sense to try to make ahead of time.

I'm not sure it's really possible to come up with a number, but at least it should be feasible to review each class file. If there's refactoring required or there's things we can do to prepare in separate branches (like using event controllers or not using run in dialogs or not subclassing widgets that are now final classes etc) then we should do those separately to try to avoid regressions and make sure we're not trying to merge a branch that it's not really reasonable to review each of the changes

@jeremypw
Copy link
Collaborator Author

@danirabbit I am concentrating on Gtk4 preparation branches at the moment - I wont be doing anymore Gtk4 branches until there isnt any more prep that can be done. If you have any suggestions as to what should (or should not) be done in Gtk4Prep PRs let me know. I guess the Gtk4 port branch can always be reviewed commit by commit provided not every commit has to compile.

@danirabbit
Copy link
Member

@jeremypw sounds like a plan! Thanks for your effort here. I know it's a complicated port!

@jeremypw
Copy link
Collaborator Author

jeremypw commented Mar 5, 2024

@danirabbit Sorry for an off-topic message but I cannot seem to log into ele.slack.com any more - it insists on using [email protected] which no longer exists.

@danirabbit
Copy link
Member

@jeremypw it looks like since we're not on a Pro plan I can't change other people's email addresses, so I sent a new invite to your gmail address. Sorry!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants