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




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

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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]