Re: New macOS build coming soon

[Kai <kai willadsen gmail com>]

On Mon, 13 Apr 2020 at 04:07, Youssef A. Abukwaik <youssef adnan gmail com> wrote:

Ops! I had already pushed a release before I received your response - about two hours earlier in fact. The good news is that it is pretty stable and given the underlying libraries condition, it is better than the previous macOS release. I guess we're about to get about 200k of testers for an unstable release. It would be great if you can make an unstable release that I can match indeed, but note that this current release is working for most use cases and is performing well as far as I can tell. We'll see if users start reporting anything out of the ordinary.

I'll try to do that this weekend coming!

 

As for upstream help, I have two things that can make life easier for me:
1. Hooks: Mainly for MeldApp & MeldWindow -
   post_init, (MeldApp, MeldWindow)
   will_become_visible, did_become_visible, (MeldWindow)

   menu_items_changed
   post_destroy & pre_destroy (MeldApp, MeldWindow)

This would cleanup the code considerably. I don't like how my code looks one bit at the moment.

I've just spent some time checking out the diff to master, and I think I can see some possible hook points... but also I feel like we might be able to do this more cleanly if you were able to cleanly subclass MeldApp and MeldWindow for the customisations. I feel like MeldApp should probably be subclassable as-is (though obviously I haven't tried) and that would be much easier to merge upstream.

MeldWindow is a little tricky because of the limitations of GtkTemplate in Python. I *think* I could create some kind of MeldWindowBase subclass and have MeldWindow be just:

@Gtk.Template(resourcepath)

class MeldWindow(MeldWindowBase):

    ...

which would then make it a bit easier for you to do some of  the OSX-specific overrides. If you think this makes sense, let me know and I'll take a look at the details.

Regarding some of the specific hooks:

  * post_init: pretty easy to do I think, but I also feel like subclassing here might be a better option

  * will_become_visible, did_become_visible: I don't think there's any way of doing this with GTK+, unless you want these on first visibility, in which case I would look at subclass + overriding do_realize(). I'm happy to add that hook if overriding do_realize in the subclass ends up being messy though.

  * menu_items_changed: we don't actually change menus any more, because without GtkUIManager (which is deprecated and has several long-standing issues) we'd have to roll our own menu state handling or pick up another library.
  * post_destroy & pre_destroy: I'm not sure whether this is possible in GTK+ lifecycle, but maybe we can figure out what hooks could actually be provided to help you.

2. This is perhaps a discussion rather than request. For UI files, do you think it would be better if I create a different UI file for any customization (which are usually small) or would it be better if we pass a variable from the application and include conditional statements within the ui file?

I'm not sure whether you mean actual `widget.ui` files here, or Python files in the `ui` subpackage. Looking at the branch, there's not much of either. I feel like the statusbar change should *probably* be doable with a platform-specific CSS change; shipping OSX-specific CSS should be fairly easy and I'm happy to help with those hooks.

For the UI file changes like appwindow.ui, it depends. I think that customisations like showing the window manager buttons are doable (and probably easier to handle) in code. Having the additional menu definitions is more difficult, and I think should probably be broken out to its own UI file.

cheers,

Kai