design update

[mjourdan]

Following the request for including diffuse into Circle1, here are some mockups matching GNOME standards:

Feel free to share your thoughts!

[joyously]

Are those key assignments supposed to be accurate?
Ctrl Y is listed in two different places (sort and open file).
Oh also, it says Ctrl C for Save in one place, and Ctrl S for Save in another.

[MightyCreak]

Wow, thank you @mjourdan !

This is a very good base for what Diffuse could look like in the future. This kind of changes will obviously take some time, but it's nice to have a long-term goal.

I would automatically put an empty second pane when opening a file, because it's a diff tool and not a text editor 😉

I like how the pretty big original menu is split into tiny designs, it's much more intuitive I think.

The overlay is interesting too, but I'm not yet convinced as I'm afraid it could get in the way. Maybe just shortcuts/accelerators are enough?

The only part I would let as it is (for now) are the tabs, because devs are more accustomed to tabs (as of today). Though I see the appeal in having them in a popover.

It actually makes me think about the notion of "tabs" in a diff tool. I think there could be a way to think about these "tabs" (or "merges") as a workspace to view a commit diff or to resolve conflicts. The use cases being for instance:

• You're preparing a commit and you'd like to see all the diffs in one app
• You merge master in your branch, that would create conflicts and you'd like to resolve all the conflicts in one app

Considering that, and especially for conflicts, it would be interesting to keep track of which files are resolved and which still need to be resolved.

[mjourdan]

Are those key assignments supposed to be accurate?
Ctrl Y is listed in two different places (sort and open file).
Oh also, it says Ctrl C for Save in one place, and Ctrl S for Save in another.

Fixed, thanks!

Wow, thank you @mjourdan !

This is a very good base for what Diffuse could look like in the future. This kind of changes will obviously take some time, but it's nice to have a long-term goal.

Yep. Some parts like the settings, and keyboard shortcuts windows would also need some work.

I would automatically put an empty second pane when opening a file, because it's a diff tool and not a text editor wink

Makes perfect sense.

I like how the pretty big original menu is split into tiny designs, it's much more intuitive I think.

The overlay is interesting too, but I'm not yet convinced as I'm afraid it could get in the way. Maybe just shortcuts/accelerators are enough?

Overlay would only appear on scroll, my biggest concern with it would be the proximity with the scrollbar.

The only part I would let as it is (for now) are the tabs, because devs are more accustomed to tabs (as of today). Though I see the appeal in having them in a popover.

Yeah, features aside, the main problem with tabs in gtk3 and 4 is they take the full window width. So it may be difficult to distinguish things when there are 3 tabs and 3 panes shown.

It actually makes me think about the notion of "tabs" in a diff tool. I think there could be a way to think about these "tabs" (or "merges") as a workspace to view a commit diff or to resolve conflicts. The use cases being for instance:

* You're preparing a commit and you'd like to see all the diffs in one app

* You merge master in your branch, that would create conflicts and you'd like to resolve all the conflicts in one app

Considering that, and especially for conflicts, it would be interesting to keep track of which files are resolved and which still need to be resolved.

Ok, I updated the mockups with your feedback, and keep the popover as an alternative idea for later.

[MightyCreak]

Thanks again for this work @mjourdan. With the time I can allocate for this project, right now I am focusing on having something more modular and, hopefully, easier to contribute to in the end. But haven't forgot about this fantastic work, I think this would happen after the migration to GTK 4. I don't know if libadwaita has been ported to Python yet?

About this:

Overlay would only appear on scroll, my biggest concern with it would be the proximity with the scrollbar.

I think users would want to jump between diff blocks without having to scroll. It seems more like something they'd need to trigger whenever they want. I personally prefer shortcuts in this case, but I think it's always good to have a UI item somewhere to impersonate the feature (e.g. the overlay could appear whenever you move the mouse in the window instead of when you start scrolling).

[mjourdan]

Hey @MightyCreak,

Regarding Libadwaita, GTK4 and Python, people seem to have ported their apps successfully. According to this post the biggest issue was with Flatpak.

Regarding navigation, it makes no doubt Diffuse should be fully controllable from keyboard. The keyboard shortcuts for those could be shown while hovering the jump button. If revealing the overlay on any mouse event was too frequent, one other idea could be to trigger it when moving the mouse from one panel to another (in addition to scrolling).

Thank you for the update, it's nice to hear from you!