On Mon, 13 Apr 2020 at 04:07, Youssef A. Abukwaik <youssef.ad...@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
_______________________________________________
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list
