> 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 > 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. 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? - 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? Thanks, Pascal. https://blady.pagesperso-orange.fr _______________________________________________ gtk-osx-users-list mailing list gtk-osx-users-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
