Re: [gtk-osx-users] GTK-Mac-Bundler lib changes.

[John Ralls <jralls ceridwen us>]

> On Jun 12, 2020, at 11:25 AM, Pascal <p p14 orange fr> wrote:
>
> > Le 11 juin 2020 à 02:49, John Ralls <jralls ceridwen us> a écrit :
> >
> > > On Jun 10, 2020, at 12:33 PM, Pascal <p p14 orange fr> wrote:
> > >
> > > Hello John,
> > >
> > > > Le 9 juin 2020 à 17:47, John Ralls <jralls ceridwen us> a écrit :
> > > >
> > > > Something else is wrong. `encoding` *is* a legal parameter to `open`: 
> > > > https://docs.python.org/3/library/functions.html#open
> > >
> > > When running jhbuild shell for gtk-mac-bundler the Python is version 3.6 built in .new_local:
> > > [JH]% which python
> > > /opt/.new_local/share/venv/etc-teWAGlKT/bin/python
> > > [JH]% python --version
> > > Python 3.6.10
> >
> > Once you've started the jhbuild shell gtk-mac-bundler python should be the one in $PREFIX. Are you sure 
> > you're not getting the Apple-supplied python 2.7? That *doesn't* have an encoding argument to open().
>
> Sorry, I got confused with several dev env folders. The python used is indeed the prefix one:
> [JH]% which python                                                  
> /opt/xnadalib-2020/bin/python
> [JH]% python --version                                              
> Python 2.7.16

Well, there you go. gtk-mac-bundler requires Python 3.2 or later.

> > Yes I agree, I can't explain more what it is going on.
> > > > As for keyboard shortcuts, it depends on what shortcuts you mean. If it's something like ctrl vs. 
> > > > command make sure that you use GDK_MODIFIER_INTENT_PRIMARY_ACCELERATOR instead of GDK_CONTROL_MASK. If 
> > > > you use accelerator groups other keys can be customized with an accelerator map file; if not you'll have 
> > > > to hand-code them one by one.
> > > >
> > > > OTOH if you want to use the keybindings from system preferences you'll have to code that yourself, AFAIK 
> > > > Gtk doesn't do that.
> > >
> > > Well, I mean shortcuts with <cmd> key as <cmd>F for find.
> > > I was wondering if I were missing some keyboard mapping files in the bundle rather than source code 
> > > changes as the program is written to support macOS shortcuts (but I haven't dig in detail to that code).
> >
> > No, there's nothing in gtk-mac-bundler or gtk-mac-integration about this, it's built into Gtk since 2.10 
> > or so. Are the accelerator keys correct when run from the jhbuild install directory?
>
> It"s the same behavior.

OK, that confirms it: You need to either use the right key mask in your code or set up an accelerator map and 
override all of the <control>foo shortcuts with <primary>foo.
 
> I take the opportunity to thank you again. I've achieved to publish a very preliminary port of GNAT Studio, 
> IDE for Ada language:
> https://github.com/AdaCore/gps
>
> see announcement on Reddit:
> https://www.reddit.com/r/ada/comments/h16ek2/gnatstudio_202_for_macos/
>
> And ... I have few more questions:
> - when I was fighting against dylib I came to the linker option -headerpad_max_install_names:
> % man install_name_tool
> INSTALL_NAME_TOOL(1)                                      INSTALL_NAME_TOOL(1)
> NAME
>       install_name_tool - change dynamic shared library install names
> SYNOPSIS
>       install_name_tool  [-change  old  new  ]  ...  [-rpath  old  new  ] ...
>       [-add_rpath new ] ... [-delete_rpath new ] ... [-id name] file
> DESCRIPTION
>       Install_name_tool changes the dynamic shared library install names  and
>       or  adds,  changes  or  deletes the rpaths recorded in a Mach-O binary.
>       For this tool to work when the install names or rpaths are  larger  the
>       binary  should  be  built  with  the ld(1) -headerpad_max_install_names
>       option.
>
> What is your feedback on the use of this option?

gtk-mac-bundler uses install_name_tool to rewrite the install and dependency names to the relocatable 
@executable_path/../lib/libfoo.dylib so that the linker will find them at runtime. 
-headerpad_max_install_names ensures that there's enough room in the dylib and executable headers for the 
rewritten names.

> - I have also dylibs out of prefix lib folder. Up to now I fix them with an absolute path which force the 
> users to install them with this path. Is there a way in the bundle file to make them taken in account by 
> gtk-mac-bundler?

You can declare the additional prefix in the bundle file. That should suffice to get them bundled and the 
install names fixed up, but it's not thoroughly tested so you may have to work up a script with 
install_name_tool to fix them up. Alternatively you could move them and all of their dependencies into 
$PREFIX and run install_name_tool to change all of the paths to $PREFIX/lib ($PREFIX expanded out); then 
gtk-mac-bundler will fix them up to work from inside the bundle. To understand the process, look at 
https://gitlab.gnome.org/GNOME/gtk-mac-bundler/-/blob/master/bundler/run-install-name-tool-change.sh and 
https://gitlab.gnome.org/GNOME/gtk-mac-bundler/-/blob/master/bundler/project.py#L287.

Regards,
John Ralls