On Fri, Oct 4, 2019 at 3:11 PM Kai <[email protected]> wrote:
> On Tue, 1 Oct 2019 at 11:33, Youssef A. Abukwaik via meld-list
> <[email protected]> wrote:
> > During the past three weeks, I have struggled with bringing the Mac
> build to
> > sync up with upstream. JHBuild has significantly changed. Meld has also
> > significantly changed. I'm not complaining about either, but I am
> seriously
> > complaining when it comes to GTK. GTK on Mac is way behind. The stable
> > GTK/quartz implementations is slow, incomplete and has some significant
> > issues. The git GTK/quartz does not even compile.
>
> I thought that GNOME had moved away from jhbuild, but checking now I see
> that the gtk-osx project is still using it (according to
> https://gitlab.gnome.org/GNOME/gtk-osx), and looks like they're still
> maintaining independent module sets, so that at least is good.
>
> > 1. GTKHeaderBar - Meld has moved to borderless window and by using
> > GTKHeaderBar, the window controls (min/max/close) are now embedded
> > within the header bar. GTK implementation sets the flag
> > GDK_QUARTZ_BORDERLESS_WINDOW in gdkwindow-quartz.c, however, it never
> > sets the flag GDK_QUARTZ_MINIATURIZABLE_WINDOW. I'm unable to minimize
> > the app window! Take a look at this:
> > https://github.com/yousseb/meld/blob/master/meld/macwindow.py#L264
>
> I realise that this is side-stepping the problem slightly, but maybe we
> could consider special handling for the OSX build that reparents the
> header bar so that we're no longer using the borderless/client side
> decoration window?
>
> This could be as simple as:
>
> @@ -60,6 +60,10 @@ class MeldWindow(Gtk.ApplicationWindow):
> def __init__(self):
> super().__init__()
>
> + header_bar = self.get_titlebar()
> + self.set_titlebar(None)
> + self.appvbox.pack_start(header_bar, False, True, 0)
> +
> # Manually handle GAction additions
>
>
I have already figured out how to fix this from the GTK side (GTK 3.24).
I'll try this and see if it helps with performance (going back to be
windowed) - thank you.
My fix was (I'll share this with the GTK guys..):
gdkwindow-quartz.c
+ NSUInteger final_mask;
+ final_mask = new_mask;
+
+ if (decorations == 0 && GDK_WINDOW_TYPE (window) !=
GDK_WINDOW_TEMP &&
+ impl->type_hint != GDK_WINDOW_TYPE_HINT_SPLASHSCREEN )
+ {
+ final_mask = GDK_QUARTZ_BORDERLESS_WINDOW |
GDK_QUARTZ_CLOSABLE_WINDOW |
+ GDK_QUARTZ_MINIATURIZABLE_WINDOW;
+ }
+
- [(id<CanSetStyleMask>)impl->toplevel setStyleMask:new_mask];
+ [(id<CanSetStyleMask>)impl->toplevel setStyleMask:final_mask];
> I notice that your branch is using Gtk.UIManager. Migrating away
> from this to GActions is one of the huge changes in our current master
> branch. I'm not saying that your window class needs to match, but it
> might be easier in the future if it does so.
>
> Also, we don't have a menu bar option at all at the moment, mostly
> because I had thoroughly burnt out by the time I finished the GAction +
> GtkHeaderBar transition. I think maintaining a GAction-based menubar
> option probably makes sense for the OSX (and maybe Windows?) ports.
>
Agreed - OSX would make sense with menubar (native). I think Windows is
fine without menubar as there's no system-wide menubar as in OSX.
>
> > 2. Fullscreen mode: With the borderless window, I have big gaps around
> > the app from all sides.. It's much better to maximize instead of
> > entering full screen!
> >
> > 3. Fullscreen mode: To top it off, GTK cannot tell that it has entered
> > fullscreen mode on quartz. is_full = window_state &
> > Gdk.WindowState.FULLSCREEN is never true on GTK/quartz even if the app
> > is really in fullscreen
>
> These two definitely feel like outright GTK bugs that should be reported.
>
> Having said this, Meld's current fullscreen behaviour is actually very
> bad - we don't reparent the header bar and end up with no UI and no
> obvious way to exit fullscreen. I doubt that fixing that would fix the
> issues you've found however.
>
I'll work on this part on the GTK side over the weekend. Hopefully will be
easy to figure out.
>
> > 4. I was hoping to be able to use GTK with vulkan
> > (https://vulkan.lunarg.com) in order to speed things up. Vulkan is only
> > available in the git version (3.96) of GTK and the quartz backend does
> not
> > build. This is very disappointing because the GTK/quartz rendering is
> slow
> > right now (especially with the new borderless window which adds RGBA
> flag -
> > A being the issue here - to the main window making it report that
> > isOpaque = false to the OS)
>
> Meld doesn't currently support GTK 4, and honestly I'm not sure when it
> will. The experience of maintaining Meld during the GTK 3.x series with
> constant toolkit breakages was unspeakably awful, and I have no reason
> to believe that the GTK 4 series is going to be any different.
>
> In other words, I wouldn't be trying to get GTK 4 to compile right now...
> let's see if we can figure out another way around the rendering issues.
>
Thanks! I'll keep on trying with 3.24 then. I'll see if there's a way to
use OpenGL instead of Vulkan. There's this wrapper (since Mojave now
promotes METAL instead of OpenGL) https://moltengl.com but it's commercial.
I'll see if there's an open source alternative.
>
> > I should probably take this post to the GTK mailing list, but I spent
> > a significant amount of hours trying to get Meld working on Mac during
> > the past three weeks that I just had to give you guys an idea of what's
> > been happening on the Mac side. I can probably get GTK 3.96 to build
> > on Mac and create a patch. I'll give it a shot over the next weekend.
>
> Thanks for the update. If you do try to take some of these issues to
> GTK, the mailing list is now actually a Discourse instance at
> https://discourse.gnome.org/.
>
>
Thank you. I'll reach out to them.
> While it's great that you're trying to update to Meld's master branch,
> that branch is also still changing a fair bit. I'm getting used to the
> new UI, but there are several parts of it that I'm not yet happy with. If
> the recent changes end up being too much for you to migrate easily, I
> do suspect that our 3.20 branch will be maintained for a fair while.
>
It would help me so much if you make each release a branch so that I can
pull stable upstream changes instead of master as I do now.
>
> If I can help out with the (as you say, very significant) changes, then
> let me know. I still don't really have access to an OSX machine to help
> out (and don't have the spare time anyway) but I'd like your project
> to continue to be available for OSX users.
>
It would be awesome if anyone could help. I've asked for help in the issues
on github, on my Facebook with my techie friends and even in some of the
forums. Everyone is excited but not one stepped up. To be honest, building
the environment is boring, but it's pretty much done and the I have already
figured out the nasty tricks (the gir files and the typelibs were a real
challenge - I wanted one binary without a wrapper and spent days with the
linker and the typelib files till I got that right)
This part:
https://github.com/yousseb/meld/blob/master/osx/build_app.sh#L129
and this part:
https://github.com/yousseb/meld/blob/master/osx/build_app.sh#L155
Took about three weeks until I got them right..
PS: I'll record a video of how it looks/feels on Mac. You should at least
see it in action. :)
>
> cheers,
> Kai
>
Regards,
Youssef
_______________________________________________
meld-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/meld-list
