-
-
Notifications
You must be signed in to change notification settings - Fork 78
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
Make compile #2225
Conversation
@@ -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)); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
@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 |
@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 |
@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. |
@jeremypw sounds like a plan! Thanks for your effort here. I know it's a complicated port! |
@danirabbit Sorry for an off-topic message but I cannot seem to log into |
@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! |
Closing as too much conflict. |
This based on
gtk4
branch up to commit "First compilable lint-free version"(be0ce20d8679315424f58b88dff93e225ddce861)` rebased onmain
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