> On Jun 12, 2020, at 11:25 AM, Pascal <p....@orange.fr> wrote: > >> >> Le 11 juin 2020 à 02:49, John Ralls <jra...@ceridwen.us> a écrit : >> >>> On Jun 10, 2020, at 12:33 PM, Pascal <p....@orange.fr> wrote: >>> >>> Hello John, >>> >>>> Le 9 juin 2020 à 17:47, John Ralls <jra...@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 _______________________________________________ gtk-osx-users-list mailing list gtk-osx-users-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
