On Tue, 1 Oct 2019 at 11:33, Youssef A. Abukwaik via meld-list
<meld-list gnome org> 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
+ 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:
and this part:
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
