Re: [gtk-osx-devel] Problems with gtk-osx-setup.sh - M1
Ah, got it. Fix pushed. Thanks. I also finally figured out the cause of "pyenv: pip: command not found" and pushed a fix for that too. BTW, I don't see ~/.pythonversion. Are you sure that's from pyenv? Regards, John Ralls > On Feb 15, 2022, at 2:08 PM, Spock wrote: > > Sorry - I did not explain myself well enough there John. > > I guess the issue that I’m pointing out is that gtk-osx-setup.sh writes the > jhbuild script but writes an absolute path for $PATH to be set to rather than > escaping so that $PATH is read from the environment when running jhbuild. > > In the code snip from gtk-osx-setup.sh below the second $PATH should be > escaped to be ‘\$PATH’ (as shown). Without this, it means that PATH only gets > set correctly if the environment $PATH when calling gtk-osx-setup.sh > contains something like “~/.new_local/bin”. > > — snip --- > cat < “$DEVPREFIX/bin/jhbuild" > #!$DEVPREFIX/bin/bash > ... > export PATH="$PYENV_ROOT/shims:$PATH” <<<<<<<- Should be …/shims:\$PATH > ... > exec $DEVPREFIX/bin/pipenv run jhbuild \$@ > EOF > — snip --- > > This explains why people with fresh machines or fresh usernames end up with > the build failing. > > So the either the instructions need to say “Set your PATH to include > ~/.new_local/bin before invoking gtk-osx-setup.sh” or the script needs to be > fixed to include the line: > > —snip— > export PATH="$PYENV_ROOT/shims:$PATH” > —snip -- > > Once I make this change, I can build a lot more of the "jhbuild build > meta-gtk-osx-bootstrap meta-gtk-osx-gtk3“ stage. > It still fails, btw, but I need to diagnose why and or ask some more > questions! > > > Hope this makes sense and is helpful? > > Regards > Paul > > > >> On 15 Feb 2022, at 18:52, john wrote: >> >> Well, it's been a requirement since forever that you put $DEVPREFIX/bin in >> your path before invoking jhbuild, but I suppose there's no harm in also >> adding it with jhbuild to prevent path pollution. I hadn't noticed >> ~/.pythonversion. That's rude of them, I'll look for a way to bury that >> somewhere so that it doesn't affect other stuff. >> >> Regards, >> John Ralls >> >>> On Feb 15, 2022, at 5:26 AM, Spock wrote: >>> >>> Hi John, >>> >>> I guess the issue with the $PYENV local 23.10.0 is that it causes >>> ~/.pythonversion to be created - which may or may not be a permanent change >>> a developer might want? >>> >>> The more serious issue is with meson not finding ninja. I think this is >>> down to jhbuild not having ~/.new_local/bin in its path. >>> >>> Here’s an example: >>> >>> — snip — >>> >>> j@pauls-mbp ~ [nobrew] % echo $PATH >>> /Users/j/.new_local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/Users/j/.cargo/bin >>> j@pauls-mbp ~ [nobrew] % jhbuild shell >>> Loading .env environment variables... >>> Found Command Line Tools 'version: 13.2.0.0.1.1638488800' >>> Command Line Tools version 13.20 >>> Prefix: /Users/j/gtk/inst >>> Entered jhbuild shell, type 'exit' to return. >>> j@pauls-mbp ~ % jhbuild >>> zsh: command not found: jhbuild >>> j@pauls-mbp ~ % >>> >>> — snip — >>> >>> I think this means that the jhbuild configuration installed by >>> gtk-osx-setup.sh does not set up jhbuild so that it uses the binaries that >>> have been installed? >>> >>> I’m not sure if the issue is with jhbuild or gtk-osx-setup.sh - but I guess >>> it’s right to start in this list before looking at what might be wrong (if >>> anything) with jhbuild? >>> >>> Regards >>> Paul Rogers >>> >>>> On 15 Feb 2022, at 01:55, John Ralls wrote: >>>> >>>> >>>> >>>>> On Feb 14, 2022, at 10:03 AM, Spock wrote: >>>>> >>>>> Hi, I’m running gtk-osx-setup.sh on an M1 Mac/MacOS 12.2 and am having a >>>>> couple of problems ... >>>>> >>>>> First off, I’m running without any homebrew paths in any of the >>>>> environment variables. >>>>> >>>>> Now, with this shell, when I run the script, I get the following: >>>>> >>>>> — snip >>>>> pyenv: pip: command not found >>>>> >>>>> The `pip' command exists in these Python versions: >>>>> 3.10.0
Re: [gtk-osx-devel] Problems with gtk-osx-setup.sh - M1
> On Feb 14, 2022, at 10:03 AM, Spock wrote: > > Hi, I’m running gtk-osx-setup.sh on an M1 Mac/MacOS 12.2 and am having a > couple of problems ... > > First off, I’m running without any homebrew paths in any of the environment > variables. > > Now, with this shell, when I run the script, I get the following: > > — snip > pyenv: pip: command not found > > The `pip' command exists in these Python versions: > 3.10.0 > > Note: See 'pyenv help global' for tips on allowing both > python2 and python3 to be found. > pyenv: pip: command not found > > The `pip' command exists in these Python versions: > 3.10.0 > > Note: See 'pyenv help global' for tips on allowing both > python2 and python3 to be found. > —- snip --- > > So I add a line to the script to allow it to find python: > > — snip — > PIP=“$PYENV_ROOT/shims/pip” > # Point pyenv at the 3.10.0 Python ... > $PYENV local 3.10.0 > $PIP install --upgrade --user pip > — snip --- > > With this line, I remove the artefacts from the previous build and re-run. > This time the script completes, so I move on to “./.new_local/bin/jhbuild > bootstrap-gtk-osx which appears to complete successfully. > > *** Was this the right thing to do? > > The final step “jhbuild meta-gtk-osx-bootstrap meta-gtk-osx-gtk3 fails due to > problems finding a version of ninja … > > — snip --- > gtk-doc 1.33.1 > > User defined options >libdir : lib >prefix : /Users/j/gtk/inst >wrap_mode : nofallback >tests : false >yelp_manual: false > > > ERROR: Could not detect Ninja v1.8.2 or newer > — snip --- > > I checked the version installed by the script … > > — snip --- > j@pauls-mbp ~ [nobrew] % ./.new_local/bin/ninja —version > 1.10.2 > — snip --- > > *** So what is happening with ninja? Is there a setup step I’m missing? > > Any help much appreciated! Your fix for pip seems reasonable. Did you remember to add ~/.new_local/bin to $PATH? Regards, John Ralls ___ gtk-osx-devel-list mailing list gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
[gtk-osx-devel] Python3 and jhbuild
I learned a couple of weeks ago that sometime in the last 9 months or so jhbuild had grown the ability to use python3 and that as of a month ago it's required on master. As a temporary workaround I froze checkouts to the last release (mid-March). Temporary time is over and I'm about to push changes to jhbuildrc-gtk-osx and gtk-osx-setup.sh that will run jhbuild with the venv's python3 instead of /usr/bin/python and I"ll remove the freeze on the jhbuild version. That won't affect existing installations unless you run gtk-osx-setup.sh to replace ~/.config/jhbuildrc. If you do be sure to also remove $DEVPREFIX/libexec/jhbuild.py so that it gets restored with the python3 changes. This has the salutary side effect of fixing the broken distutils build module. The basic example jhbuildrc-custom doesn't need any changes, but if you have a more sophisticated one you might want to run 2to3 on it. The 2to3 shipped with Catalina is from 2.7 (and named /usr/bin/2to3-) so you might prefer to use the one in the venv: PYENV_ROOT=$HOME/.local/share/pyenv pipenv run 2to3 ~/.config/jhbuildrc- Some other changes coming shortly: It's time to bump the minimum macOS version again, to 10.11 El Capitan. The only place this is enforced is jhbuildrc-gtk-osx, so it's easy enough to change if you want to keep working on an older version. I've got an Apple Hardware Developer Transition Kit and have been testing. I'm happy to report that everything works so far and that I've already pushed some changes to jhbuildrc-gtk-osx that support the new architecture. For those of you who've been around long enough to remember ppc and universal builds, they're back. I've no idea if gtk-osx can build one. Regards, John Ralls ___ gtk-osx-devel-list mailing list gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Re: [gtk-osx-devel] stability problems with gsequencer
> On Jul 5, 2020, at 3:49 AM, Joël Krähemann via gtk-osx-devel-list > wrote: > > hi all, > > Recently, I encountered stability problems on Apple OS X, especially > since MacOS 10.15. Prior versions worked perfect for me. > > Can you share your expertise with me? Do you have the same problems? > > My application `gsequencer` crashes often when adding ladspa cmt > plugin "feedback delay line (maximum delay 0,1s)" or related. > > I have attached a log file of crash. > > You can download the application from: > > https://sourceforge.net/projects/ags/ > https://www.pling.com/p/1290114/ > > From my experience I would say there is somewhere an integer overflow > or alike ... > What can tool you recommend me to debug? I have no idea what you're talking about, but I don't think that it has anything to do with gtk-osx or gtk-mac-integration. Try asking on Gnome discourse (https://discourse.gnome.org/). Regards, John Ralls ___ gtk-osx-devel-list mailing list gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Re: [gtk-osx-devel] Broken link in site
> On May 28, 2019, at 12:29 PM, Stefanos Mitropoulos via gtk-osx-devel-list > wrote: > > Hello > > I just wanted to let you know that the link for gtk-osx-build-setup.sh > (https://gitlab.gnome.org/GNOME/gtk-osx/raw/master/gtk-osx-build-setup.sh) > returns 404 Yes, it's been replaced with https://gitlab.gnome.org/GNOME/gtk-osx/raw/master/gtk-osx-setup.sh. If you found it via https://wiki.gnome.org/Projects/GTK/OSX/Building I just updated it. If you found it somewhere else, where? Regards, John Ralls ___ gtk-osx-devel-list mailing list gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Re: [gtk-osx-devel] Building GTK3 on OSX
> On May 22, 2019, at 3:10 PM, Matthew Allen via gtk-osx-devel-list > wrote: > > I've got the boot strap now working. > > The next issue is that when running: > jhbuild build python meta-gtk-osx-bootstrap meta-gtk-osx-gtk3 > I get: > configure: error: Python module libxml2 is needed to run this package. > > Looking for that with find it seems to be there: > ./gtk/inst/lib/python3.6/site-packages/libxml2mod.so > ./gtk/inst/lib/python3.6/site-packages/libxml2mod.a > ./gtk/inst/lib/python3.6/site-packages/libxml2.py > ./gtk/inst/lib/python3.6/site-packages/drv_libxml2.py > ./gtk/inst/lib/libxml2.dylib > > Not sure why it can't find it. Its in the context of configuring itstool. > > Is this a known issue? That's from itstool, right? Drop to a shell and make sure that /inst/lib/python3.6/site-packages is in PYTHONPATH and that `which python` points to the one in the virtenv. Regards, John Ralls ___ gtk-osx-devel-list mailing list gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Re: [gtk-osx-devel] Gtk OSX build not working for me
> On May 21, 2019, at 4:21 AM, Matthew Allen via gtk-osx-devel-list > wrote: > > I'm trying to follow the build guide here: > https://wiki.gnome.org/action/show/Projects/GTK/OSX/Building > > But it seems to be broken. Firstly the download link to > 'gtk-osx-build-setup.sh' is broken. Not a good omen. I'm assuming that maybe > that file is here instead? > https://gitlab.gnome.org/GNOME/gtk-osx/blob/master/gtk-osx-setup.sh > > Anyway I tried running that and it eventually worked. The next command is: > jhbuild bootstrap > > And that gets as far as: > (build) bash-3.2$ jhbuild bootstrap > Loading .env environment variables… > *** Checking out m4 *** [1/29] > jhbuild bootstrap: failed to unpack > /Users/build/gtk/source/pkgs/m4-1.4.18.tar.xz > > I did previously add some paths to my profile: > export > PATH=/Users/build/.new_local/share/pyenv/versions/3.6.8/bin:/Users/build/.new_local/bin:$PATH > > And I've checked that my python version is actually 3.6.8. The system python > is 2.7. > > Running from a new user account. I do have macports on my main account, but > none of those paths are available on the build account. > > I wish I could just download a complete pre-built version of Gtk3 for mac. Sorry, I'm delinquent in updating the wiki page. The current build instructions are in the README at https://gitlab.gnome.org/GNOME/gtk-osx underneath the file listing. One major change is that you should run `jhbuild bootstrap-gtk-osx` instead of `jhbuild bootstrap`. Regards, John Ralls ___ gtk-osx-devel-list mailing list gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Quartz Coordinates
I’m working on GdkQuartz to bring it up to date with the rest of Gdk. I’m starting with GdkDisplay and GdkMonitor mostly because of https://gitlab.gnome.org/GNOME/gtk/issues/1312 <https://gitlab.gnome.org/GNOME/gtk/issues/1312>. This question may also bear upon https://gitlab.gnome.org/GNOME/gtk/issues/1029 <https://gitlab.gnome.org/GNOME/gtk/issues/1029> as well as other pointer coordinate issues some users have reported on downstream applications. Under the old GdkScreen regime Gdk had a “root window” with 0,0 in the upper left corner of the upper-left-most monitor and all point values are unsigned, increasing down and to the right. Quartz uses a different coordinate system with the origin at the bottom-left corner of the “primary” monitor with point values increasing up and to the right. Monitors placed below or to the left of the “primary” monitor will have negative coordinates. gdkscreen-quartz and gdkwindow-quartz have conversion code to create a fake root window and to translate between the two coordinate systems. The new GdkDisplay/GdkMonitor regime does away with the root window and introduces gdk_display_get_monitor_at_point and gdk_display_get_monitor_at_window that iterate over the list of active monitors testing for whether the coordinates of the point or window lie inside each monitor’s work area. That’s great, it’s similar to the way Quartz works... but are there any assumptions made about coordinates that need translation between Gdk and Quartz? Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-osx-devel] gtk-quartz-engine removed from gtk-osx-themes.modules
> On Sep 12, 2018, at 3:14 AM, Calum Lind via Gtk-osx-devel-list > wrote: > > I am following somewhat older instructions to package a pygtk > application for macos and found that `gtk-quartz-engine` has been > removed from gtk-osx-themes.modules last year but there appear to be > no details as to why though: > > https://gitlab.gnome.org/GNOME/gtk-osx/commit/eef92a1d23e08b4fb07b35c5f1e8c462798aef62#cb231ea9df6ccb1f59163579b4c65ae85c30e644_121_121 > > <https://gitlab.gnome.org/GNOME/gtk-osx/commit/eef92a1d23e08b4fb07b35c5f1e8c462798aef62#cb231ea9df6ccb1f59163579b4c65ae85c30e644_121_121> Because it never really worked and hadn’t been maintained for many years. There are several Clearlooks themes that gave a reasonable approximation of Mac UI elements and were more or less stable, but Clearlooks hasn’t been maintained much lately either. Regards, John Ralls ___ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
[gtk-osx-devel] Revised build system
I’ve got a working Pyenv/Pipenv build wrapper and I’ve pushed it to https://github.com/jralls/gtk-osx-build <https://github.com/jralls/gtk-osx-build> in branch “pipenv”. So far I’ve just tested through building meta-gtk-osx-gtk3 and meta-gtk-osx-themes. There’s a new Readme.md there with configuration details, but one can just checkout the branch and run `new-setup.sh` to take the defaults, which keep everything in your home directory. You’ll want to rename ~/.local/bin/jhbuild because new-setup.sh will overwrite it with a new one that starts a virtual environment. It mostly works, though there are a few issues that I haven’t yet figured out how to fix automatically, largely because I don’t have a solid handle on meson yet: The first problem has nothing to do with meson, it’s the long standing bug in Python that adds ‘-Wl,-stack_size, 100’ to LINKFORSHARED even though that argument is only for executables. The workaround is still to edit $PYENV_ROOT/versions/3.6.6/lib/python3.6/_sysconfigdata_m_darwin_darwin.py and remove the argument. Next, Pango’s meson.build sets a bogus '-framework CoreFoundation ApplicationServices’ on the end of the g-ir-introspection args. Drop to the shell and edit pango/meson.build around line 144 to remove it from “extra args”. Finally, gdk-pixbuf doesn’t set -module on the loaders build and so builds them with .dylib instead of .so, and then gdk-pixbuf-query-loaders can’t find them. That breaks the Gtk3 build, so rename them and run `gdk-pixbuf-query-loaders --update-cache` to fix it. So give it a try on your favorite builds. Tell me about any problems and if you come up with better fixes for the problems above tell me about them too. Regards, John Ralls ___ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
[gtk-osx-devel] Gtk-mac-integration-2.1.2 Released
I discovered to my chagrin that I'd left src/gettext.h out of the 2.1.1 dist tarball and so it wouldn't build. While I was back at it I decided to clean up some compiler warnings as well. Regards, John Ralls ___ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Re: g_stat() In src/glade3-3.8.5/gladeui/glade-utils.c At Line 1865 Causes SIGSEGV in strlen () from C:\Windows\System32\msvcrt.dll When Saving File
> On May 22, 2018, at 7:27 AM, LRN <lrn1...@gmail.com> wrote: > > On 22.05.2018 15:02, gtk-devel-l...@talkvideo.net wrote: >> When running: /mingw64/bin/glade-3.exe >> >> And I try to save a file, after selecting or entering a filename, and >> clicking Save in the File Chooser Dialog, the program crashes, (segfaults), >> and the file size is zero. > > I can reproduce this crash. Will look into it soon. You’ll want to start with glib/gstdio.c, particularly https://gitlab.gnome.org/GNOME/glib/commit/53bd6a359f2c48e7729f89902097c892c8aa6fea <https://gitlab.gnome.org/GNOME/glib/commit/53bd6a359f2c48e7729f89902097c892c8aa6fea> and following. See also https://bugzilla.gnome.org/show_bug.cgi?id=795153 <https://bugzilla.gnome.org/show_bug.cgi?id=795153>. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-osx-devel] making gtk applications accessible with VoiceOver
> On May 19, 2018, at 10:03 AM, Eric Le Lay <kerik...@users.sourceforge.net> > wrote: > > Hi, > > does anybody know if there has been attempts at bridging ATK to > VoiceOver for screen reading the contents of Gtk apps on macOS (at > least with the Quartz backend)? > I couldn't find any ticket about it on gitlab.gnome.org. ISTR some discussion about that several years ago. Try searching the list archives for gtk-de...@lists.gnome.org. You might also search bugzilla.gnome.org. Most bugs that hadn't had any activity in the last few months were closed as obsolete and not transferred. Regards, John Ralls ___ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Re: GitLab CI runners for non-Linux systems
> On May 19, 2018, at 5:55 AM, xclae...@gmail.com wrote: > > Le vendredi 18 mai 2018 à 23:38 -0400, philip.chime...@gmail.com a > écrit : >> On Fri, May 18, 2018 at 10:15 PM <xclae...@gmail.com> wrote: >>> Le vendredi 18 mai 2018 à 10:52 +0100, Philip Withnall a écrit : >>>> • macOS (ideally several versions, since we support from OS X >>> 10.7 >>>> upwards[2]) >>> >>> I did a quick test on a macmini (macOS 10.13.4) we have in >>> Collabora >>> office, and it's almost too easy to setup, not even a challenge! >>> >>> Well... except that glib fails to build with meson because libffi >>> subproject does not support darwin. I'll try to investigate that. >> >> I've been building http://mirrors.kernel.org/sources.redhat.com/libff >> i/libffi-3.2.1.tar.gz on macOS with no problems since at least 10.9. >> I think maybe just the meson fork (https://github.com/centricular/lib >> ffi/commits/meson) of libffi has this problem. >> >> You could try pre-installing libffi from the tarball on the image, >> then it wouldn't use the wrapped subproject, I think? > > "brew install libffi" did the trick, I've got a working CI for macos > \o/ > > Well... now... > > FAILED: glib/glib@@glib-2.0@sha/gatomic.c.o > cc -Iglib/glib@@glib-2.0@sha -Iglib -I../glib -I. -I../ > -I/usr/local/Cellar/pcre/8.42/include -Xclang -fcolor-diagnostics -pipe -Wall > -Winvalid-pch -Werror -std=gnu89 -O0 -g -D_GNU_SOURCE -fno-strict-aliasing > -DG_ENABLE_DEBUG -Wall -Wstrict-prototypes > -Werror=declaration-after-statement -Werror=format=2 -Werror=format-security > -Werror=implicit-function-declaration -Werror=init-self > -Werror=missing-include-dirs -Werror=missing-prototypes -Werror=pointer-arith > -pthread '-DG_LOG_DOMAIN="GLib"' -DGLIB_COMPILATION -fvisibility=hidden -MD > -MQ 'glib/glib@@glib-2.0@sha/gatomic.c.o' -MF > 'glib/glib@@glib-2.0@sha/gatomic.c.o.d' -o > 'glib/glib@@glib-2.0@sha/gatomic.c.o' -c ../glib/gatomic.c > ../glib/gatomic.c:399:10: error: incompatible integer to pointer conversion > passing 'gssize' (aka 'long') to parameter of type 'gpointer' (aka 'void *') > [-Werror,-Wint-conversion] > return g_atomic_pointer_add ((volatile gpointer *) atomic, val); > ^~~~ > ../glib/gatomic.h:227:46: note: expanded from macro 'g_atomic_pointer_add' >(gssize) __sync_fetch_and_add ((atomic), (val)); \ That conversion is so integral to Glib and Gobject that there are macros for it: https://developer.gnome.org/glib/stable/glib-Type-Conversion-Macros.html <https://developer.gnome.org/glib/stable/glib-Type-Conversion-Macros.html>. You’ll just have to set -Wno-int-conversion in CFLAGS. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Devmapper insufficient thin pool free data blocks.
I just pushed a very small MacOS change (https://gitlab.gnome.org/GNOME/gtk/commit/828f634d5c08b9c39626dd1512ec7a1af4800f3d) and got a CI failure (https://gitlab.gnome.org/GNOME/gtk/-/jobs/31820). I compared that with the previous push to gtk-3-22, which passed. The failing log begins: "Running with gitlab-runner 10.7.0 (7c273476) on progress.gnome.org f23948e6 Using Docker executor with image registry.gitlab.gnome.org/gnome/gtk/gtk-3-22:v2 ... ERROR: Preparation failed: Error response from daemon: devmapper: Thin Pool has 155512 free data blocks which is less than minimum required 163840 free data blocks. Create more free space in thin pool or use dm.min_free_space option to change behavior" While the passing one begins: "Running with gitlab-runner 10.7.1 (b9bba623) on jenkins.gnome.org 9b338874 Using Docker executor with image registry.gitlab.gnome.org/gnome/gtk/gtk-3-22:v2 ... Pulling docker image registry.gitlab.gnome.org/gnome/gtk/gtk-3-22:v2 ..." So a different gitlab-runner version on a different host. Is that the root of the problem? Is there anything I can do about it? Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-osx-devel] python3 modules
> On Jan 6, 2018, at 4:48 AM, Antoine Martin <anto...@nagafix.co.uk> wrote: > > Hi, > > The xpra project is finally trying to migrate from GTK2 to GTK3, and > also making the jump to Python 3 whilst we're at it. > We have a fairly large number of python module dependencies for which we > have created a moduleset: > http://xpra.org/trac/browser/xpra/trunk/osx/jhbuild/xpra-python.modules > > What is the recommended way to build the same module for both python2 > and python3? > I was hoping to minimize the moduleset duplication, but the python3 > version needs to depend on "python3" so they need a different XML node. > Unless we can just remove the python dependency altogether and always > ensure it is built early? > > Then I was hoping to use the distutils "python3" attribute to avoid > having to mess with symlinks from python to python3, but that didn't > seem to have the desired effect. Am I missing something? > > Another problem with building them twice is that jhbuild will keep the > existing checkout directory since the path is the same, and the source > doesn't get cleaned automatically so it seems quite easy to get things > messed up. > > Are there any better solutions? > > > BTW, I believe there's a mistake on the home page: > https://wiki.gnome.org/Projects/GTK+/OSX/Building > It should say: > ln -sf python3-config python-config > Instead of: > ln -sf python3-config python You can set up the dependencies to build for *either* Py2 or Py3 by putting both in an block instead of a block. The caveat is that you must then include one or the other in the list of modules to build, either directly or indirectly via a meta-module. For a module to be built for both, put both in the dependencies. In that case the underlying project must be written to work with two versions of python at once. That’s easy for a cmake, meson, or autotools project but is beyond the abilities of waf and distutils. No, you’re not missing anything about the distutils python3 attribute, but unfortunately a couple of projects are: They insist on using the python and python-config symlinks regardless of what we tell distutils or set in the environment. Jhbuild always builds clean if you build out-of-tree (set ‘buildroot in your jhbuildrc-custom)’ , but some projects do dumb things in their build system that makes it not work. In those cases you can pass --clean to jhbuild on the command line or setting “makeclean” in your jhbuildrc-custom. I recommend that you build out-of-tree as much as possible. Set supports-out-of-tree-builds=“false” in any modules where the underlying project requires building in source. You’re right about the wiki page. Fixed, thanks. Regards, John Ralls ___ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Re: [gtk-osx-devel] [PATCH] Update location of gstreamer and plugins
Don’t send patches to the list. File a bug with the patch attached or make a Github PR. Patches attached to bug reports should be created from a git commit using git format-patch. Regards, John Ralls > On Oct 23, 2017, at 9:09 PM, Matthew Francis <mjay.fran...@gmail.com> wrote: > > --- > modulesets-stable/gtk-osx-gstreamer.modules | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/modulesets-stable/gtk-osx-gstreamer.modules > b/modulesets-stable/gtk-osx-gstreamer.modules > index 693eb01..02eef52 100644 > --- a/modulesets-stable/gtk-osx-gstreamer.modules > +++ b/modulesets-stable/gtk-osx-gstreamer.modules > @@ -24,7 +24,7 @@ > >supports-non-srcdir-builds="no" > makeargs="ERROR_CFLAGS=" autogen-sh="configure"> > - + > hash="sha256:50c2f5af50a6cc6c0a3f3ed43bdd8b5e2bff00bacfb766d4be139ec06d8b5218"> > > > @@ -34,7 +34,7 @@ > >makeargs="ERROR_CFLAGS=" autogen-sh="configure"> > - + version="1.10.4" > > hash="sha256:f6d245b6b3d4cb733f81ebb021074c525ece83db0c10e932794b339b8d935eb7"/> > > @@ -47,7 +47,7 @@ > >makeargs="ERROR_CFLAGS=" autogen-sh="configure"> > - + version="1.10.4" > > hash="sha256:8a86c61434a8c44665365bd0b3557a040937d1f44bf69caee4e9ea816ce74d7e"/> > > -- > 2.7.4 > > ___ > Gtk-osx-devel-list mailing list > Gtk-osx-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list ___ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Re: [gtk-osx-devel] Unable to build pygobject with latest updates.
> On Sep 18, 2017, at 11:47 AM, Stephen Gauthier <co...@eveny.net> wrote: > > When running "jhbuild build meta-gtk-osx-python" I get this failure from > pygobject. > > unix.override:27:10: fatal error: 'gio/gdesktopappinfo.h' file not found > > I found a related open bug over at macports which leads me to believe it is > because of newer versions of glib. > https://trac.macports.org/ticket/53911 > > Any help is appreciated. What moduleset are you building? I just did a build of modulesets-stable and didn’t encounter that. Regards, John Ralls ___ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
[gtk-osx-devel] Removal of support for obsolete MacOS X Versions and global module update.
I've completed the removal of support for versions of MacOS X earlier than 10.8 from gtk-osx. If you still need to build for 10.4u or 10.5, or on 10.4-10.7, I've tagged the last commit that supports that with "Last-Lion" to make it easy to have a jhbuildrc and modulesets to support your needs. I've also gone through all of the modulesets and updated everything. I've tested most of the modules with macosx-version-min=10.9 on Sierra with Xcode 8.3. I set up an ElCap test machine with command-line tools and noted a few problems, so I'll have a follow-on commit to get that working in a day or two. Regards, John Ralls ___ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
MacOS Text Scaling
> On Apr 27, 2017, at 3:58 PM, Emmanuele Bassi <eba...@gmail.com> wrote: > > On 27 April 2017 at 22:56, Brion Vibber <br...@pobox.com> wrote: >> GTK+3 added native support for user interface scaling to support HiDPI >> displays with consistently sized resources and widgets, with the limitation >> that the scaling factor is an integer (1x, 2x, 3x...) > > It's not really a "limitation": it's purposefully designed that way, > for windowing system surfaces and graphical assets. Font sizes support > fractional values, and have been doing so for a long while (since the > GTK+ 2.x days) > > In general, the toolkit has no code to detect scaling factors at all, > and it relies on the system to convey meaning to those values. This might be a bit of a digression, sorry. Gdk has several scaling-dependent functions: gdk_screen_(set|get)_resolution(), gdk_monitor_get_scale_factor, and gdk_(screen|monitor)_get_(height|width)_mm() and I'm trying to figure out how to get the right behavior on MacOS HiDPI (aka retina) monitors. A couple of weeks ago I replaced an obsolete function ([NSScreen userSpaceScaleFactor]) [1] with a more-correct implementation that effectively does what it's supposed to, return 144dpi for retina and 72 for normal. Doing so causes the font-size to double; i.e. a 12-point font displays at 24-points. I suspect that's because Pango calls gdk_screen_get_resolution(), but it also uses Apple's CoreText for rendering and layout on MacOS and I suspect that CoreText is already compensating for the retina screen, resulting in the doubled font scaling. Does that make sense? Is the correct solution to have Pango ignore resolution on MacOS or to always set GdkScreen resolution to 72? If the latter, what about the other functions that use scaling information and how to communicate to applications that they need to use larger icons and such? Regards, John Ralls [1] https://bugzilla.gnome.org/show_bug.cgi?id=765883 <https://bugzilla.gnome.org/show_bug.cgi?id=765883> [2] https://bugzilla.gnome.org/show_bug.cgi?id=781118 <https://bugzilla.gnome.org/show_bug.cgi?id=781118> ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-osx-devel] Native look and feel via GTK+ CSS
> On Jan 16, 2017, at 1:25 AM, Марко М. Костић <marko.m.kos...@gmail.com> wrote: > > GTK+3 Python3 programs with headerbars look out of place on macOS Sierra. > > I thought about using new GTK+ CSS system for styling them to look more like > other > native macOS programs. > > Is this a good idea? > Anybody else did anything similar already? What do you mean by "headerbars"? Yes, it's been done. Google for "gtk3 themes mac". Regards, John Ralls ___ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Re: Reinstate support for OS X versions older than 10.9
> On Sep 22, 2015, at 3:47 PM, Ryan Schmidt <g...@ryandesign.com> wrote: > > Hello, I'm the maintainer of glib2 in the MacPorts package management system. > > glib 2.46.0 was recently released, and attempting to configure it produces > this error: > > checking OSX version >= 10.9.0... no > configure: error: OSX version is too old! > > glib 2.45.2 and earlier worked fine on older versions of OS X, but 2.45.3 and > later claim to require 10.9. > > My understanding is that the implementation of GNotification support for OS X > [1] necessitated this increase in minimum OS version. But this huge jump in > minimum OS version makes glib unusable on hundreds of older Mac models [2] > that cannot be upgraded to OS X 10.9 that were previously able to use glib. I > urge you to reconsider this action and reinstate support for older versions > of OS X by making the GNotification support optional. Clearly, since > GNotification support was just added, no existing apps that used glib and > that already worked on OS X can have required this functionality. > > I originally expressed this concern in the issue tracker [1] but was advised > to bring it up on the mailing list for discussion instead. > > In response to my comment in that ticket, doubt was expressed as to the > usability of glib on older systems, even prior to this. I can at least tell > you that Graphviz, which uses glib, worked fine all the way back to OS X > 10.4, which is the earliest system I tested. I'm happy to run your test suite > on older systems and report bugs for any problems found. > I’m a bit conflicted about this. Yes, 10.9 is a bit new for a cutoff, but on the other hand upgrades to 10.10 are free and run on any machine that can run 10.7 so there’s not much of an excuse and considerable security risk for anyone with such a machine not to be running the latest release. That still leaves all of those folks with PPC and 32-bit Intel Macs who are stuck at 10.5 and 10.6 respectively. Yeah, it’s nice to support them with Gnome applications — I’m among those who do, providing 32-bit PPC and Intel bundles for GnuCash and Gramps. OTOH it’s not really reasonable for them to expect to be supported forever, and I bet they can’t get many new native applications for their obsolete hardware either. All of which said, it does seem unreasonable that a very minor feature implementation in a dark corner of GIO should block building all of GLib. On the bug Emmanuelle asks whether GLib runs on those older OSes and how much of the API is used. The answer is yes, absolutely, and all of GLib and GObject are used pretty extensively by many Gnome apps ported to Mac and Windows. The apps I maintain don’t use a lot of the newer GIO features like notifications or even the GApplication stuff intended to make Gnome apps more portable simply because no-one has made the effort to redesign the applications to use them. (It’s in my to-do list for Gramps, but it’s *way down* that list.) I can’t speak for other projects, but I suspect that the same is true for many. There’s always the option of sticking with the last releases of GLib and Gtk+ if you want to build/run on older machines. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] filechooser: restore pre-3.16 type-ahead-find with setting (off by default)
On Aug 29, 2015, at 4:50 AM, Thomas Martitz ku...@rockbox.org wrote:
The previous type-ahead-find was loved by many people, so removing it without
possibility to restore was not nice to them. This commit re-introduces it
again
with a default-off seting so that the new default search-as-you-type is
untouched, for those who don't consider the new search a viable replacement.
---
gtk/gtkfilechooserwidget.c | 35 +---
gtk/org.gtk.Settings.FileChooser.gschema.xml | 7 ++
2 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/gtk/gtkfilechooserwidget.c b/gtk/gtkfilechooserwidget.c
index 94d051f..8d41775 100644
--- a/gtk/gtkfilechooserwidget.c
+++ b/gtk/gtkfilechooserwidget.c
@@ -354,6 +354,7 @@ struct _GtkFileChooserWidgetPrivate {
guint show_size_column : 1;
guint create_folders : 1;
guint auto_selecting_first_row : 1;
+ guint use_type_ahead_find : 1;
[Snip]
Don’t post patches to the list, they just get lost. Open a bug at
https://bugzilla.gnome.org and attach your patch.
To create a patch (or series of patches) commit your changes in your local git
repo (ideally in a feature branch) and use `git format-patch` to generate the
patches from the commit(s). If that doesn’t instantly make sense there’s an
excellent and free git book at http://git-scm.com/documentation.
Regards,
John Ralls
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-osx-devel] jhbuild problem
On Jun 22, 2015, at 1:58 PM, Miguel Angel kmsi...@gmail.com wrote: Hi there I have a problem with jhbuild I follow the instructions for install jhbuild here https://wiki.gnome.org/Projects/GTK+/OSX/Building, but when I try to build gnome-builder with this command jhbuild -m gnome-world build gnome-builder it shows the following message: jhbuild build: failed to parse gnome-world: [Errno 2] No such file or directory: 'gnome-world’ I can´t figure out why this problem happened, it works ok on fedora but on mac does´t work I have a macbook pro with Yosemite, any ideas? I want to develop some vala projects. Gk-OSX doesn't use the standard Gnome modulesets, it has its own. TingPing has some instructions at https://wiki.gnome.org/Projects/Jhbuild/Mac_OS for using the mainstream modulesets. If you’d prefer to stick with Gtk-OSX you can build vala with `jhbuild build vala`. You may or may not find the other dependencies you need for your project in the Gtk-OSX moduleset. If they’re not there it’s not hard to create a new moduleset for your project that builds those and includes the Gtk-OSX modulesets for the core stuff. Regards, John Ralls ___ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Re: Outdated win32 bundle
On Jun 11, 2015, at 6:22 AM, Emmanuele Bassi eba...@gmail.com wrote: Hey; On 11 June 2015 at 14:19, Ignacio Casal Quinteiro nacho.r...@gmail.com wrote: For the record following Emmanuele mail, you can find an example on how to create an installer for your application using msys2 here: https://git.gnome.org/browse/gedit/tree/win32 We really need to get a GTK-based installer, so you guys can stop using the Competition. ;-) If you object to using Qt’s installer there’s Inno-setup, http://www.jrsoftware.org/isinfo.php. GnuCash has been using it for many years. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-osx-devel] [PATCH 3/3] Moduleset-stable: fixing the repository link of cups module
On May 10, 2015, at 1:43 AM, Kirill Moizik kir...@daynix.com wrote: Thanks for your reply John, i sent pull request with the fix, please review it Thanks in advance, Please remember to copy the list on all replies, using “reply all”. I don’t see any PRs on https://github.com/jralls/gtk-osx-build https://github.com/jralls/gtk-osx-build. Where did you send it? Regards, John Ralls ___ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
GL and libepoxy
It looks like we've committed to using libepoxy[1] as a shim for GL support. It looks quite nice, but there's a catch: In spite of the claim in our INSTALL that it's cross-platform, it actually depends on X11. I think that means that we need to have a separate GL interface per-backend. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GL and libepoxy
On Mar 7, 2015, at 1:49 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: Are you sure? This shouldn't be the case since https://github.com/anholt/libepoxy/commit/e3051481cc9f5b7b36b317aff1454ee16ea9cdb9 https://github.com/anholt/libepoxy/commit/e3051481cc9f5b7b36b317aff1454ee16ea9cdb9 On Fri, Mar 6, 2015 at 7:54 PM, John Ralls jra...@ceridwen.us mailto:jra...@ceridwen.us wrote: It looks like we've committed to using libepoxy[1] as a shim for GL support. It looks quite nice, but there's a catch: In spite of the claim in our INSTALL that it's cross-platform, it actually depends on X11. I think that means that we need to have a separate GL interface per-backend. Regards, John Ralls No,I'm not sure. It failed on xorg-macros and I relied on the README file, which says that it requires XQuartz. I guess that's not true, because after I supplied xorg-macros it built and installed fine. Thanks, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-osx-devel] Libsoup Introspection (was Bison 3 and WebKit)
On Dec 27, 2014, at 9:55 AM, Philip Chimento philip.chime...@gmail.com
wrote:
I still get an error building libsoup, only on modulesets-unstable. I worked
around it by adding --disable-introspection to libsoup's autogenargs in my
local configuration file, since I assume it's a temporary problem. I haven't
yet had time to pinpoint where it came from, though. Have you seen this
before at all?
GISCAN Soup-2.4.gir
Traceback (most recent call last):
File /Users/fliep/gtk/inst/bin/g-ir-scanner, line 55, in module
sys.exit(scanner_main(sys.argv))
File
/Users/fliep/gtk/inst/lib/gobject-introspection/giscanner/scannermain.py,
line 517, in scanner_main
ss = create_source_scanner(options, args)
File
/Users/fliep/gtk/inst/lib/gobject-introspection/giscanner/scannermain.py,
line 430, in create_source_scanner
ss.parse_files(filenames)
File
/Users/fliep/gtk/inst/lib/gobject-introspection/giscanner/sourcescanner.py,
line 256, in parse_files
self._parse(headers)
File
/Users/fliep/gtk/inst/lib/gobject-introspection/giscanner/sourcescanner.py,
line 302, in _parse
proc.stdin.write('#ifndef %s\n' % (define, ))
IOError: [Errno 32] Broken pipe
make[3]: *** [Soup-2.4.gir] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Well, I finally needed to fix this, since we’re about to do a Gramps release.
It was more involved than I thought, too: The broken pipe turned out to be from
Popen getting a SIGSEGV; I’m not able to tell if it’s from the fork or the
exec. Here’s the weird part, and the work-around. They’re the same:
Select 4 to open a shell. cd to glib-networking. Run
make uninstall make install
Quit the shell and select 1, rerun build. All will be well.
How’s that for weird?
Regards,
John Ralls
___
Gtk-osx-devel-list mailing list
Gtk-osx-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Re: New GTK+ Binding
On Jan 3, 2015, at 5:14 PM, Nandakumar Edamana nandakuma...@gmail.com wrote: Hello, I am trying to implement a new programming language. The work is progressing successfully. Now I have started to write GTK+ 3 binding for it and it works! I write this mail just to inform you this. Hope I'll get your guidance in case I need. That's ambitious! Is there a source repo? Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-osx-devel] Bison 3 and WebKit
On Dec 27, 2014, at 9:55 AM, Philip Chimento philip.chime...@gmail.com
wrote:
On Mon, Dec 22, 2014 at 11:28 AM, John Ralls jra...@ceridwen.us
mailto:jra...@ceridwen.us wrote:
On Dec 22, 2014, at 9:11 AM, Philip Chimento philip.chime...@gmail.com
mailto:philip.chime...@gmail.com wrote:
On Mon, Dec 22, 2014 at 9:04 AM, John Ralls jra...@ceridwen.us
mailto:jra...@ceridwen.us wrote:
On Dec 21, 2014, at 9:09 PM, Philip Chimento philip.chime...@gmail.com
mailto:philip.chime...@gmail.com wrote:
On Tue, Dec 16, 2014 at 12:39 PM, John Ralls jra...@ceridwen.us
mailto:jra...@ceridwen.us wrote:
On Dec 16, 2014, at 12:25 AM, Philip Chimento philip.chime...@gmail.com
mailto:philip.chime...@gmail.com wrote:
On Mon, Dec 15, 2014 at 11:01 AM, John Ralls jra...@ceridwen.us
mailto:jra...@ceridwen.us wrote:
On Dec 14, 2014, at 10:14 PM, Philip Chimento
philip.chime...@gmail.com mailto:philip.chime...@gmail.com wrote:
On Mon, Dec 8, 2014 at 8:15 PM, John Ralls jra...@ceridwen.us
mailto:jra...@ceridwen.us wrote:
On Dec 8, 2014, at 3:37 PM, Philip Chimento
philip.chime...@gmail.com mailto:philip.chime...@gmail.com wrote:
On Sun, Dec 7, 2014 at 5:05 PM, John Ralls jra...@ceridwen.us
mailto:jra...@ceridwen.us wrote:
The upgrade of Bison to version 3 which you graciously provided
breaks the WebKit build, which you also graciously provided. ISTR
that you mumbled something about working on building a newer WebKit
version. Are you?
Yes! It's been a bit pre-empted by other stuff, but I am still
working on building WebKit 2.4.7. [...]
[...] should I perhaps keep the old WebKit 1.x module intact, and instead
add a new one for webkitgtk 2.x? I might have to add a new one anyway
since webkitgtk 2.x has discontinued the old WebKit 1 single-process API,
and a lot of apps still depend on it. How about two new modules named
webkit1gtk and webkit2gtk?
Yes, I think that would be wise.
How about just “webkit” and “webkit2” so that app modulesets don’t break
gratuitously?
Actually what I meant was keeping the existing one, and adding two more.
All the APIs and version numbers are confusing but here's everything I'm
proposing in a nutshell:
- WebKit - WebKitGTK 1.x, WebKit 1 API, works with GTK 2.x (could be built
for GTK 3.x but let's not bother)
- webkit1gtk - WebKitGTK 2.4.x, WebKit 1 API, works with GTK 3.x
- webkit2gtk - WebKitGTK 2.6, WebKit 2 API, works with GTK 3.x
I picked webkit2gtk because that's what the pkg-config file calls itself
and webkit1gtk in analogy to that. (Actually webkit1gtk's pkg-config file
is called webkitgtk so that might be better for consistency but a more
confusing name.)
Ah, got it.
Could we use ‘webkit[12]gtk3’ to make it clear that they’re gtk3-only?
That aside, the only way to deal with the confusion is to comment each module
with what it’s for.
Done, pull request here: https://github.com/jralls/gtk-osx-build/pull/32
https://github.com/jralls/gtk-osx-build/pull/32
Yeah, saw that, I’ll make comments on the pull request.
I still get an error building libsoup, only on modulesets-unstable. I worked
around it by adding --disable-introspection to libsoup's autogenargs in my
local configuration file, since I assume it's a temporary problem. I haven't
yet had time to pinpoint where it came from, though. Have you seen this
before at all?
GISCAN Soup-2.4.gir
Traceback (most recent call last):
File /Users/fliep/gtk/inst/bin/g-ir-scanner, line 55, in module
sys.exit(scanner_main(sys.argv))
File
/Users/fliep/gtk/inst/lib/gobject-introspection/giscanner/scannermain.py,
line 517, in scanner_main
ss = create_source_scanner(options, args)
File
/Users/fliep/gtk/inst/lib/gobject-introspection/giscanner/scannermain.py,
line 430, in create_source_scanner
ss.parse_files(filenames)
File
/Users/fliep/gtk/inst/lib/gobject-introspection/giscanner/sourcescanner.py,
line 256, in parse_files
self._parse(headers)
File
/Users/fliep/gtk/inst/lib/gobject-introspection/giscanner/sourcescanner.py,
line 302, in _parse
proc.stdin.write('#ifndef %s\n' % (define, ))
IOError: [Errno 32] Broken pipe
make[3]: *** [Soup-2.4.gir] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
No, but I haven’t tried building libsoup in unstable recently. Looks like a
g-ir-scanner bug, though. Someone changed the format to use only one arg and
screwed up by forgetting to remove the comma in the now-single-member tuple.
Regards,
John Ralls
___
Gtk-osx-devel-list mailing list
Gtk-osx-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Re: [gtk-osx-devel] Bison 3 and WebKit
On Dec 14, 2014, at 10:14 PM, Philip Chimento philip.chime...@gmail.com wrote: On Mon, Dec 8, 2014 at 8:15 PM, John Ralls jra...@ceridwen.us mailto:jra...@ceridwen.us wrote: On Dec 8, 2014, at 3:37 PM, Philip Chimento philip.chime...@gmail.com mailto:philip.chime...@gmail.com wrote: On Sun, Dec 7, 2014 at 5:05 PM, John Ralls jra...@ceridwen.us mailto:jra...@ceridwen.us wrote: The upgrade of Bison to version 3 which you graciously provided breaks the WebKit build, which you also graciously provided. ISTR that you mumbled something about working on building a newer WebKit version. Are you? Yes! It's been a bit pre-empted by other stuff, but I am still working on building WebKit 2.4.7. What is it about Bison 3 that breaks the old build? [log] Moving ~/.local/bin/bison out of the way, so that it uses the one Apple ships (v.2.3), clears the problem. I've got something almost working for modulesets-stable on the update-webkit branch of ptomato/gtk-osx-build: https://github.com/ptomato/gtk-osx-build/tree/update-webkit https://github.com/ptomato/gtk-osx-build/tree/update-webkit There's one thing left I can't figure out. The build stalls while linking libWebCoreSVG.la. ranlib prints out reams of complaints about object files having no symbols, although, that seems to be normal in itself. Then it stalls at a point where the last two are repeats of the two before that: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .libs/libWebCoreSVG.a(libWebCoreSVG_la-CachedSVGDocumentReference.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .libs/libWebCoreSVG.a(libWebCoreSVG_la-JSSVGZoomAndPan.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .libs/libWebCoreSVG.a(libWebCoreSVG_la-CachedSVGDocumentReference.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .libs/libWebCoreSVG.a(libWebCoreSVG_la-JSSVGZoomAndPan.o) has no symbols And sits there for 25 minutes, maxing out one CPU - at that point I killed it. Restarting the build completed with no problem. If you wipe the source directory and build again from scratch, it stalls again. I'm curious if anyone else has this problem. Also, if you're waiting on this module to be buildable again, I can submit a pull request that only updates modulesets-stable while I work on the other two modulesets. Does using `make -j1` change anything? I’ll pull it and give it a try later today. If all else fails we can just disable SVG. I just deleted Bison 3 after bootstrapping, so it’s not holding anything up for me. That doesn’t help anyone who needs both gstreamer and WebKit, though. Maybe bison 2.7.1 would work for both. Regards, John Ralls ___ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Re: atk 'missing symbols' problem since gnome-3-14
On Sep 26, 2014, at 7:17 PM, Fan Chun-wei fanc...@yahoo.com.tw wrote: Hi, This situation would have been hit by GLib and GTK+, if not done properly, as they use things like _GLIB_EXTERN (for glib, gobject, gio) and _GDK_EXTERN (for GDK, gtk) and they also export public variables (data)--but they build and link just fine. In fact the work on using __declspec(dllexport) for ATK is modeled on them. There is a ATK_VAR macro that is used to export (and import using __declspec(dllimport) the public variables, for example, and similar macros are used in GLib and GTK+, since the days of using .symbols/.def files. It might be worth it to see whether we can use __declspec(dllimport) for the functions as well for better efficiency, though, but this would be something we can look into a bit later. For the -mm libraries though, I think it might be good if we use dllimport and dllexport all around, rather than using gendef that makes use of dumpbin, as many other symbols are exported unnecessarily during the process. Sounds like something that should be in GLib, G_EXTERN. Oddly, there isn't one already. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pygtk version
On Nov 16, 2013, at 12:09 PM, Rudra Banerjee bnrj.ru...@gmail.com wrote: Hi, do pygtk still use gtk2.x? The tutorial in pygtk shows, that is the case (http://www.pygtk.org/tutorial.html ). Though I have found another site (non gnome, http://python-gtk-3-tutorial.readthedocs.org/en/latest/ ) I am still to find the official gnome document, ala pygtk. Any idea please? https://python-gtk-3-tutorial.readthedocs.org/en/latest/index.html Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk 3.10 compiling failed on Mac OS X
On Nov 17, 2013, at 4:01 AM, cee1 fykc...@gmail.com wrote: Hi, https://git.gnome.org/browse/gtk+/tree/gdk/quartz/gdkevents-quartz.c#n1683 there misses a right brace. Already reported: https://bugzilla.gnome.org/show_bug.cgi?id=712514 Thanks. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gl_GLIBC21 and charset.alias
On Oct 4, 2013, at 10:22 AM, Dan Winship d...@gnome.org wrote: On 10/03/2013 04:18 PM, John Ralls wrote: In https://git.gnome.org/browse/glib/commit/?id=d2bb019533bbcbd1cee3891822ac7ba6ff55ad3d , Colin removed the call to gl_GLIBC21 from configure.ac, which breaks the installation of charset.alias because clause in glib/libcharset/Makefile.am which installs it depends upon @GLIBC21@ which is no longer defined. My inclination is to just remove the condition, since charset.alias gets built anyway; the test only stops it being installed. Is there any harm in having charset.alias installed if the system has glibc-2.1 or later? If so, is there something to test for that's preferable over the gl_GLIBC21 autoconf macro? There's a section of configure.ac with tests specifically for libcharset, so you can just add it back there instead. (We didn't remove the call because it's evil or anything, we just removed it because we thought it wasn't needed any more.) Dan, Thanks for the guidance. Pushed to master glib-2-38. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
gl_GLIBC21 and charset.alias
In https://git.gnome.org/browse/glib/commit/?id=d2bb019533bbcbd1cee3891822ac7ba6ff55ad3d , Colin removed the call to gl_GLIBC21 from configure.ac, which breaks the installation of charset.alias because clause in glib/libcharset/Makefile.am which installs it depends upon @GLIBC21@ which is no longer defined. My inclination is to just remove the condition, since charset.alias gets built anyway; the test only stops it being installed. Is there any harm in having charset.alias installed if the system has glibc-2.1 or later? If so, is there something to test for that's preferable over the gl_GLIBC21 autoconf macro? Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-osx-devel] [gtk-osx-users] New Modulesets and gtk-mac-integration-2.0.3
On Sep 30, 2013, at 2:02 PM, Ronan Waide wai...@gmail.com wrote: On 30 Sep 2013, at 22:01, Ronan Waide wai...@gmail.com wrote: Hi John, seeing a failure in building berkleydb: Ah, sorry, this is Gramps -specific, should not have wound up on gtk-osx lists. Waide, No, it's in gtk-osx-python.modules. This is the right place. Looks like bdb 4.8 isn't going to work with clang. No need to copy the script in this case. modules-unstable has a module for bdb-5.2. Can you see if that works? Regards, John Ralls ___ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Re: [gtk-osx-devel] [gtk-osx-users] New Modulesets and gtk-mac-integration-2.0.3
On Sep 30, 2013, at 2:12 PM, Ronan Waide wai...@gmail.com wrote: On 30 Sep 2013, at 22:09, John Ralls jra...@ceridwen.us wrote: On Sep 30, 2013, at 2:02 PM, Ronan Waide wai...@gmail.com wrote: On 30 Sep 2013, at 22:01, Ronan Waide wai...@gmail.com wrote: Hi John, seeing a failure in building berkleydb: Ah, sorry, this is Gramps -specific, should not have wound up on gtk-osx lists. Waide, No, it's in gtk-osx-python.modules. This is the right place. Looks like bdb 4.8 isn't going to work with clang. No need to copy the script in this case. modules-unstable has a module for bdb-5.2. Can you see if that works? I'll give it a go and let you know how I get on. Might not happen immediately though - limited hacking time :) Pretty busy myself, but I can fire off a test-build this afternoon. Regards, John Ralls ___ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
[gtk-osx-devel] New Modulesets and gtk-mac-integration-2.0.3
I've just pushed new modulesets for Gnome-3.10. Well, except for unsupported and random. I also had to modify gtk-mac-integration and release 2.0.3 because I messed up and used some 10.6 API in 2.0.2. That's reflected in the new modulesets. Regards, John Ralls ___ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
[gtk-osx-devel] Gtk-mac-integration-2.0.2 Released
I'm happy to announce the release of gtk-mac-integration version 2.0.2. This is primarily a bug-fix release, but there are a few small enhancements: * Ready for Mavericks and Xcode 5.0 * Makes the App(le) Menu more Mac-like, with the App-name appended to Hide, Quit, and any items added to the zeroth entry (normally About). * Suppress leading, trailing, and consecutive separators in menus I'll update the stable modulesets shortly to reflect this along with the release of Gnome 3.10. There's a slight delay because the Glib maintainer messed up the tarball. See https://bugzilla.gnome.org/show_bug.cgi?id=708972 Regards, John Ralls ___ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Re: Mac OSX 10.7+ fullscreen handling - first little patch
On Aug 18, 2013, at 7:04 PM, rf...@tbrf.net wrote: Hi, I'm interested in bringing support for true OSX fullscreen windows to GTK+ - standard system decoration in the top right corner of the window, correct Spaces handling, etc. Still finding my way around everything here, but this is the first atomic part for review: responding to the NSWindowDelegate windowDidEnterFullScreen and windowDidExitFullScreen notifications by synchronizing the GDK_WINDOW_STATE_FULLSCREEN bit, causing the window-state-event signal to be sent. (Apologies if I screwed up the submissions process...) It would be better if you'd file a bug with the patch as an attachment. Use a git master checkout to develop against, commit your changes with a good commit message (don't forget to set up your real name and email in ~/.gitconfig) and use git format-patch to create the patch set. That has two benefits: It helps save us from forgetting about it, and it's much easier to provide focused feedback. I'll give it a try regardless in a day or two. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Github mirror script broken
I've gotten the following error on my last couple of pushes -- and they don't seem to have gone through to Github: remote: Traceback (most recent call last): remote: File /home/admin/bin/git/post-receive-mirror-github, line 161, in module remote: raise e remote: Exception: Gtk+ has a '+' character in it which is unsupported by Github. remote: You have to add it to the exception maps in the post-update hook. Did somebody mess with the post receive hook? The mirrored repo on Github is called gtk for just this reason. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Documentation website throwing SSL errors
https://developer.gnome.org/ is failing to connect for me, reporting the following error: Secure Connection Failed An error occurred during a connection to developer.gnome.org. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long) Connecting with http works fine, but some of the links are https, so it breaks until I edit the url in the address-bar. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: _gtk_quartz_framework_init
On May 2, 2013, at 7:29 AM, Michael Natterer mi...@gimp.org wrote: On Thu, 2013-05-02 at 15:41 +0200, Benjamin Otte wrote: Hey, I recently found this magic call to _gtk_quartz_framework_init() in the Quartz initialization code and after asking people on IRC it seems it's no longer used by anyone (was it ever?). So in my pursuit of code clarity I was wondering if I can just remove it. Can I? I have never noticed this before, but a framework is a programming API and library packed up as a proper bundle, and known to the compiler on a higher level than just -L or -I. The call was added by Richard, and iirc he also did a framework, haven't heard about that in a while though. He did a sort-of framework, but it was a bitch to maintain, so I didn't. Besides, it didn't work in that one couldn't put -framework Gtk on the compile line and get your app to build. Instead you had to pass horrible fixed-path -I and -L directives, and there is no m4 macro to discover them. If you want to look at at, it's at https://github.com/jralls/gtk-osx-framework Benjamin, I have no problem with you deleting those calls. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Git repo wedged. How do I get it fixed?
On Mar 29, 2013, at 12:57 AM, Florian Müllner fmuell...@gnome.org wrote: On Mar 29, 2013 4:53 AM, John Ralls jra...@ceridwen.us wrote: I'm unable to push a commit to gtk-osx. How do I get a git.gnome.org admin to unwedge it? Sounds like https://mail.gnome.org/archives/devel-announce-list/2013-March/msg6.html, which is being worked on. It does indeed, and it's working this morning. Thanks. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Git repo wedged. How do I get it fixed?
I'm unable to push a commit to gtk-osx. How do I get a git.gnome.org admin to unwedge it? The error is: Counting objects: 10, done. Delta compression using up to 2 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 1.42 KiB, done. Total 6 (delta 5), reused 0 (delta 0) fatal: Unable to create '/git/gtk-osx.git/refs/heads/master.lock': Permission denied fatal: The remote end hung up unexpectedly fatal: The remote end hung up unexpectedly Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GUI Testing (was: Some shortcomings in gtestutils)
On Feb 20, 2013, at 6:46 PM, Federico Mena Quintero feder...@gnome.org wrote: * Now that the a11y infrastructure is included in-the-box with GTK+, it sounds like a good idea to start putting an a11y-based testing infrastructure in GTK+ itself. For the file chooser's tests, I had to do some manual hacks to simulate, click this button, find the dialog, click the dialog's button... this is tricky C code that assumes too much knowledge of the internals of the toolkit, and I'd love to write some higher-level stuff instead for such tests. (Feel free to reply about this in a different thread - this could derail *this* thread pretty fast) :) There are two ways to go about GUI testing. One is to retrieve the coordinates of a control and inject a mouse or keyboard event at those coordinates, the other is to give every control an id that can be used to send events to. The first is incredibly brittle and the second is AFAIK supported only by wxWidgets. [1] ISTR that there was an implementation of the coordinate-tracking sort for Gtk1, but I've lost track of it. It would be a pretty big change to Gtk to introduce control ids and event injectability. Regards, John Ralls [1] http://wxguitest.sourceforge.net/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib-mkenums in glib 2
On Feb 19, 2013, at 8:22 AM, John Emmas john...@tiscali.co.uk wrote: On 19 Feb 2013, at 15:37, Bernhard Schuster wrote: I would like to see that information - even if I have no instant use for it - but I am pretty sure it will help a lot of people digging for information. No problem. At the moment, I've made a couple of dozen changes in my efforts to track this down. I need to start backing them out now until I arrive at the minimum changes needed for making the build work. Might have something in the next day or two. Might I suggest a wiki page on GnomeLive, perhaps linked to https://live.gnome.org/GTK+/Win32? Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk-osx-devel] [gtk-osx-users] gtk-mac-bundler: Unable to load image-loading module ...
On Feb 12, 2013, at 8:37 AM, Christophe c...@heonium.com wrote:
Le Tuesday 29 Jan 2013 à 11:28:22 (-0800), John Ralls a écrit :
On Jan 29, 2013, at 10:02 AM, Christophe c...@heonium.com wrote:
Le Tuesday 29 Jan 2013 à 08:49:39 (-0800), John Ralls a écrit :
On Jan 29, 2013, at 7:32 AM, Christophe c...@heonium.com wrote:
Le Tuesday 29 Jan 2013 à 06:55:40 (-0800), John Ralls a écrit :
On Jan 29, 2013, at 4:53 AM, Christophe c...@heonium.com wrote:
Hello,
I am new to gtk-mac-bundler, and it seems to have followed the
documentation to the letter but when I run the generated
package i have the following error message:
CRITICAL:init:Unable to load image-loading module:
@executable_path/../Resources/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so:
dlopen(@executable_path/../Resources/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so,1):
image not found
I specify the image file it tries to open is present in bunble. I
googling for several days but I have not found anything relevant.
Can you give a link or a track to solve this problem
Assuming you've checked the bundle to ensure that libpixbufloader-png.so
is in fact in that path, the usual cause of this problem is attempting
to run an auxiliary program from Contents/Resources/bin instead of
Contents/MacOS. @executable_path starts from the path of the binary that
starts the linker-chain.
Ok I understand, but I followed the sample: 'pygtk-demo' and I set the
entry 'launcher_script' which copied the script in the 'Contents/MacOS'.
This script calls the python script in the same directory which starts
the application that it is in 'Contents/Resources/bin'. The only
difference is that in this sample the final script is in
'Contents/Resources/lib/pygtk/2.0'.
You advise me to the Python application being in 'Contents/Resources/bin'
in 'Contents/MacOS'? In this case i need to modify a lot a things in the
application.
So this is python. That changes things a bit.
The location of the python script doesn't matter, the executable (as far
as the linker and dlopen are concerned) is the python interpreter, which
is why it is in Contents/MacOS.
If you shell out to another program, though, (os.spawn, popen2,
subprocess.call, etc.), that creates a new executable for linking and
loading, and the easiest thing to do is to put any program that you need
in Contents/MacOS as well.
I have put python interpreter and the python script in the bundle
(Contents/MacOS) but i have exactly the same error when i try to run it.
It appears that you *don't* understand. So long as you stay in the python
script, python is the executable, the location of the script isn't
important. That's they way pygtk-demo works -- and it does work, I just
tested it. So either you've screwed something up in converting the example
to your script or your script is calling another program which isn't in
Contents/MacOS.
You have to figure out which is the problem, I can't without reviewing your
code, and I'm not interested in doing that.
Hello
I understand that you do not want to see my code and I do not ask you,
however i did a little test from 'pygtkdemo' and I'd like your opinion.
I add the following line to the file ~/gtk/inst/lib/pygtk/2.0/pygtk-demo.py ':
...
import gdk
...
Gtk.gdk.pixbuf_new_from_file ICON =
('/Users/gtkosx3/Desktop/PyGtkDemo.app/Contents/MacOS/icon.png')
...
and the following lines in the file 'pygtk-demo.bundle':
...
!-- binary Dest=${bundle}/Contents/MacOS
${prefix}/bin/python
/binary --
binary dest=${bundle}/Contents/MacOS
/usr/bin/python
/binary
binary dest=${bundle}/Contents/MacOS
/usr/bin/python2.7
/binary
binary
${prefix}/lib/gdk-pixbuf-2.0/${pkg:gdk-pixbuf-2.0:gdk_pixbuf_binary_version}/loaders/*.
*
/ binary
...
I run the bundle generation and when I excute it I still have the same
error message. I do not see how I can know what is called external
library.
Thank you for your time and your answer.
Please keep this on the list.
I don't think that putting the Apple-supplied python in the bundle is going to
work. When I try that I get
Fatal Python error: PyThreadState_Get: no current thread
Desktop/PyGtkDemo.app/Contents/MacOS/PyGtkDemo: line 65: 26075 Abort trap: 6
$EXEC $PYTHON $bundle_contents/MacOS/pygtk-demo
But perhaps that's because PyGtk is built with ${prefix}/bin/python. It's much
cleaner to do it that way as well.
So after fixing that and your mistakes in selecting the loaders and the syntax
errors and all of that, it loads up just fine.
Regards,
John Ralls
___
Gtk-osx-devel-list mailing list
Gtk-osx-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Re: [gtk-osx-devel] [Gtk-osx-devs] patches to GTKOSXApplication
On Jan 26, 2013, at 1:01 AM, Eric Le Lay kerik...@users.sourceforge.net wrote: Hi John, hi list, here are the patches we applied to GTKOSXApplication 2.0.1 to distribute it in MacPorts: https://trac.macports.org/browser/trunk/dports/devel/gtk-osx-application/files Would you consider applying them? I can't apply the Makefile.in patches. Makefile.in is a generated file. You'll have to convert that into something that autoconf and automake can digest... but you need to open a bug and explain why you can't just set libdir at configure time and adjust $PYTHONPATH. The patch to cocoa-menu-item.c is just wrong. That's objective-c, and @ introduces string constants in objective-c. Regards, John Ralls -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ Gtk-osx-devs mailing list gtk-osx-d...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-osx-devs ___ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Re: building gtk+ 3 on rhel6
On Jan 13, 2013, at 5:25 PM, Ted Toth txt...@gmail.com wrote: I'm trying to build gtk+ 3 on RHEL6 but have run into a problem while following the instruction on http://developer.gnome.org/gtk3/stable/gtk-building.html when building pango. The glib build went fine but pango is a problem: ./configure --prefix=/opt/gtk : checking for CoreText availability... no checking for CAIRO... yes checking which cairo font backends could be used... none configure: Disabling cairo support configure: error: *** Could not enable any backends. *** Must have at least one backend to build Pango. cairo and cairo-devel are installed and as best I can tell the font backends are included. Anyone done this yet? If so what did you have to do to get by this issue. Dif you build harfbuzz, freetype, and fontconfig? Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib-mkenums in glib 2
On Jan 1, 2013, at 8:11 PM, John Emmas john...@tiscali.co.uk wrote: On 1 Jan 2013, at 15:54, John Emmas wrote: If anyone has a flash of inspiration, please let me know. I had a flash of inspiration myself... Traceback (most recent call last): File F:/+GTK-SOURCES/gnu-win32/src/glib/gio/gdbus-2.0/codegen/gdbus-codegen.in, line 39, in module from codegen import codegen_main File F:\+GTK-SOURCES\gnu-win32\src\glib\gio\gdbus-2.0\codegen\codegen.py, line 26, in module from . import config ValueError: Attempted relative import in non-package Might this be a 'cascading' problem? e.g. 'codegen' imports 'codegen_main' which (along the way) imports 'config' which fails - thereby causing them both to fail? In other words, there might be nothing wrong in the 'codegen_main' package - except that something further down the line is failing to import 'config' Well, yes, of course. In fact, there's a whole raft of cascading imports: gdbus-codegen: from codegen import codegen_main from . import config from . import utils from . import dbustypes from . import utils from . import parser from . import dbustypes from . import codegen from . import config from . import utils from . import dbustypes from . import codegen_docbook from . import config from . import utils from . import dbustypes from . import parser What fails? codegen.py, halfway down the list. Try renaming codegen.py to codegenerator.py and change the import statement in codegen_main.py. Maybe it's a namespace issue. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib-mkenums in glib 2
On Dec 30, 2012, at 3:47 AM, John Emmas john...@tiscali.co.uk wrote: On 29 Dec 2012, at 21:12, John Emmas wrote: On 29 Dec 2012, at 16:41, John Ralls wrote: That's because gio/gdbus-2.0/codegen/config.py doesn't exist, but config.py.in does -- another file that needs to have its @variables@ substituted -- in this case @datarootdir@, @prefix@, and @VERSION@. This one *is* done by configure, which treats it like a Makefile.in; those are all AC_SUBST values. That prolly doesn't make any sense to you, don't worry about it. @prefix@ is the root of the directory tree where glib is getting installed: /usr/local by default on a Unix/Linux box. @datarootdir@ is where various data files (man pages, translation files, etc.) go, normally prefix/share on a Unix/Linux box. @VERSION@ is the Glib version, currently 2.35.4. So you need to figure out how to fill in those values and create config.py from MSVS. Many thanks for your help, John. It's getting later here now but I'll give that some further thought tomorrow. Hi John, This morning I tried manually replacing @VARIABLE_NAME@ with sensible values and I created the missing config.py file (note that I didn't modify config.py.in - I just copied it, replacing those particular values). However, when I run my python command I still get the same error message:- Traceback (most recent call last): File F:/+GTK-SOURCES/gnu-win32/src/glib/gio/gdbus-2.0/codegen/gdbus-codegen.in, line 39, in module from codegen import codegen_main File F:\+GTK-SOURCES\gnu-win32\src\glib\gio\gdbus-2.0\codegen\codegen.py, line 26, in module from . import config ValueError: Attempted relative import in non-package Note that these lines seem to be the ones causing the error:- from whatever import something Python doesn't seem to know what to do when it encounters that instruction. Hmm. Your python doesn't seem to agree that codegen is a package, in spite of being imported into gdbus-codegen. Try changing the line to just import config. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib-mkenums in glib 2
On Dec 30, 2012, at 8:40 AM, jose.ali...@gmail.com wrote: I don't know if this is related, but It seems you are missing the empty __init__.py in the codegen/ directory. This is a requirement for a directory so python may consider it as a package. That would indeed cause the problem, but it seems unlikely: __init__.py isn't empty (4 LOC + copyright) and under version control. Regards, John Ralls On Sun, Dec 30, 2012 at 5:36 PM, John Ralls jra...@ceridwen.us wrote: On Dec 30, 2012, at 3:47 AM, John Emmas john...@tiscali.co.uk wrote: On 29 Dec 2012, at 21:12, John Emmas wrote: On 29 Dec 2012, at 16:41, John Ralls wrote: That's because gio/gdbus-2.0/codegen/config.py doesn't exist, but config.py.in does -- another file that needs to have its @variables@ substituted -- in this case @datarootdir@, @prefix@, and @VERSION@. This one *is* done by configure, which treats it like a Makefile.in; those are all AC_SUBST values. That prolly doesn't make any sense to you, don't worry about it. @prefix@ is the root of the directory tree where glib is getting installed: /usr/local by default on a Unix/Linux box. @datarootdir@ is where various data files (man pages, translation files, etc.) go, normally prefix/share on a Unix/Linux box. @VERSION@ is the Glib version, currently 2.35.4. So you need to figure out how to fill in those values and create config.py from MSVS. Many thanks for your help, John. It's getting later here now but I'll give that some further thought tomorrow. Hi John, This morning I tried manually replacing @VARIABLE_NAME@ with sensible values and I created the missing config.py file (note that I didn't modify config.py.in - I just copied it, replacing those particular values). However, when I run my python command I still get the same error message:- Traceback (most recent call last): File F:/+GTK-SOURCES/gnu-win32/src/glib/gio/gdbus-2.0/codegen/gdbus-codegen.in, line 39, in module from codegen import codegen_main File F:\+GTK-SOURCES\gnu-win32\src\glib\gio\gdbus-2.0\codegen\codegen.py, line 26, in module from . import config ValueError: Attempted relative import in non-package Note that these lines seem to be the ones causing the error:- from whatever import something Python doesn't seem to know what to do when it encounters that instruction. Hmm. Your python doesn't seem to agree that codegen is a package, in spite of being imported into gdbus-codegen. Try changing the line to just import config. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib-mkenums in glib 2
On Dec 29, 2012, at 7:20 AM, John Emmas john...@tiscali.co.uk wrote: On 29 Dec 2012, at 09:55, David Nečas wrote: Anything ending with .in is usually processed by configure (config.status) which you obviously don't have so you must replace @VARIABLE@s with the corresponding values using whatever you have. But the only two variables present there are unused on MS Windows anyway – MS Windows neither recognise shbangs nor is the fixed datadir code path useful there. Thanks for the suggestion David but in this case (gdbus-codegen.in) it seems to be a python script that needs to get processed. Yes, it's a python script that needs to get processed, replacing the two items David mentioned to produce gdbus-codegen. He' mistaken in this case, though: It's done by make, and you'll find the script in Makefile.am Looking in makefile.am suggests that this command line would be right for my particular machine (imagine that this is all on one line) :- python F:/+GTK-SOURCES/gnu-win32/src/glib/gio/gdbus-2.0/codegen/gdbus-codegen.in --interface-prefix org. --generate-c-code gdbus-daemon-generated --c-namespace _G F:/+GTK-SOURCES/gnu-win32/src/glib/gio/dbus-daemon.xml However, that only seems to produce this error output:- Traceback (most recent call last): File F:/+GTK-SOURCES/gnu-win32/src/glib/gio/gdbus-2.0/codegen/gdbus-codegen.in, line 39, in module from codegen import codegen_main File F:\+GTK-SOURCES\gnu-win32\src\glib\gio\gdbus-2.0\codegen\codegen.py, line 26, in module from . import config ValueError: Attempted relative import in non-package So I'm currently stumped! Like last time, it'll probably be something quite obvious that I've overlooked. That's because gio/gdbus-2.0/codegen/config.py doesn't exist, but config.py.in does -- another file that needs to have its @variables@ substituted -- in this case @datarootdir@, @prefix@, and @VERSION@. This one *is* done by configure, which treats it like a Makefile.in; those are all AC_SUBST values. That prolly doesn't make any sense to you, don't worry about it. @prefix@ is the root of the directory tree where glib is getting installed: /usr/local by default on a Unix/Linux box. @datarootdir@ is where various data files (man pages, translation files, etc.) go, normally prefix/share on a Unix/Linux box. @VERSION@ is the Glib version, currently 2.35.4. So you need to figure out how to fill in those values and create config.py from MSVS. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib-mkenums in glib 2
On Dec 26, 2012, at 10:18 AM, John Emmas john...@tiscali.co.uk wrote:
As many of you will know, GTK's MSVC project files have gotten quite a long
way out of date now (presumably since Tor's departure, which was a great
pity). I'm trying to bring mine up-to-date so that they'll build from the
latest GIT sources. I'm starting with glib which is currently at version
2.35 I believe.
Along the way I thought I might as well make use of MSVC's ability to launch
external programs and scripts which can be run before (and even during) the
build process. My hope was that I'd be able to make a Visual Studio project
file that would do everything needed to build glib - including building those
files that need to be auto-generated. Everything seems to have worked fine,
except for glib-mkenums. glib-mkenums is a perl script that needs to get run
from time to time to ensure that gio/gioenumtypes.c and gio/gioenumtypes.h
are up-to-date.
Taking he header file as an example, it seems as if this command line should
work:-
perl glib-mkenums --template path_to_gioenumtypes.h.template
path_to_gioenumtypes.h
Obviously, in the real example, those paths are the actual paths. However,
in fact, it consistently gives me this error output:-
/* Generated data (by glib-mkenums) */
Use of uninitialized value $_[0] in substitution (s///) at E:/Program
Files/Perl/lib/File/Basename.pm line 338.
fileparse(): need a valid pathname at glib-mkenums line 259
I'm not sure where Perl is up to these days but I'm running version 5.12.1.
Do I need to update Perl to a newer version or can anyone suggests anything
else that might be causing this error?
I'm not hugely familiar with Perl but FWIW, here's how the script looks
around line 259 of glib-mkenums:
if (length($fhead)) {
my $prod = $fhead;
my $base = basename ($ARGV[0]); /* --- THIS IS LINE 259 !! */
$prod =~ s/\@filename\@/$ARGV[0]/g;
$prod =~ s/\@basename\@/$base/g;
$prod =~ s/\\a/\a/g; $prod =~ s/\\b/\b/g; $prod =~ s/\\t/\t/g; $prod =~
s/\\n/\n/g;
$prod =~ s/\\f/\f/g; $prod =~ s/\\r/\r/g;
chomp ($prod);
print $prod\n;
}
ARGV should be a hint: It means the same thing in perl as it does in C. It
seems that glib-mkenums either isn't getting an @ARGV or it's somehow getting
cleared before that line.
It's certainly not a perl version problem.
Try running the command from a cmd shell and see if you get the same error. If
it works from the shell, then there's something about the way MSVS is launching
perl that's causing the problem.
Regards,
John Ralls
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib-mkenums in glib 2
On Dec 26, 2012, at 11:48 AM, John Emmas john...@tiscali.co.uk wrote: On 26 Dec 2012, at 19:20, John Ralls wrote: ARGV should be a hint: It means the same thing in perl as it does in C. It seems that glib-mkenums either isn't getting an @ARGV or it's somehow getting cleared before that line. Thanks John. I think the fact that ARGV[0] is involved might be significant. From my hazy recollection, argv[0] is normally the path to the app that got launched (in this case, the path to perl.exe). There's nothing particularly unusual about that path:- E:\Program Files\Perl\bin\perl.exe although it does contain a space. I wonder if that's the issue?? It's certainly not a perl version problem. Try running the command from a cmd shell and see if you get the same error. If it works from the shell, then there's something about the way MSVS is launching perl that's causing the problem. I'm ahead of you there! I've already tried it from a command prompt but the result is the same :-( That's good, actually. That takes MSVS out of the equation so you can focus on what's going on with perl. In C, you're absolutely right that argv[0] is the program name. However perl does a $0 = shift; before passing control to your program, which moves the program name to $0 and removes it from @ARGV (in perl a variable name beginning with $ is a scalar and one beginning with @ is an array. The first element of the array @ARGV is $ARGV[0]). That means that $ARGV[0] should be --template, but for some reason is being stripped. If you run: perl -e 'print(join(\n, @ARGV));' foo bar you should get the output foo bar Do you? Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
[gtk-osx-devel] gtk-mac-bundler 0.7.3
This should be good. Note that it's necessary to update to this version in order to bundle applications built with the newly-released stable moduleset because of changes in Pango. About gtk-mac-bundler = Gtk-mac-bundler creates an OS X Application Bundle from a Gtk+ Quartz application, automatically retrieving all shared library dependencies of the application and any designated executables or loadable modules, converting the rpaths to the bundle locations for all binaries. Data files, translations, and themes are also installed. Gtk-mac-bundler is licensed under the Gnu General Public License Version 2. Resulting bundles carry whatever licenses govern their contents. News - Another minor bugfix, in this case causing some binary dependencies to not be found. NEW IN 0.7.2 - Mnor bugfix fixed crash during pango module processing. Download http://download.gnome.org/sources/gtk-mac-bundler/0.7/gtk-mac-bundler-0.7.3.tar.xz (27.8K) sha256sum: 799d8d2bbd747ba55d32b7c9f08116e5f2b349358175b05544a4baa91365 ___ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Re: notifications in gtk
On Nov 6, 2012, at 8:01 AM, Kristian Rietveld k...@loopnest.org wrote: On Nov 6, 2012, at 4:23 PM, Matthias Clasen wrote: Problems with GtkStatusIcon - It is really centered around the idea that apps just export a small bit of their UI into the 'panel' - It assumes that all desktops want to offer a permanent place (system tray) for applications to present a clickable icon with a context menu - It requires the application to be running as long as its icon is present, essentially forcing a daemon mode onto applications (eg evolution-alarm-notify) - The X implementation uses XEmbed and can't really be made to work nicely in a composited environment - The win32 implementation is also problematic I would argue the OS X implementation is also problematic. Showing the icon in the OS X menu bar is quite easy, however, in response we currently typically pop up a GtkMenu. This gives interesting problems with grabs/event handling. Also, it looks quite out of place because native applications show a native menu. The current GtkStatusIcon makes it close to impossible to automatically convert a GtkMenu into a native menu (e.g. custom menu items) and there's also the case where the status icon pops up something that's not a menu. All very true. This *helps* Matthias's case to get rid of GtkStatusIcon. Another point in favor of Matthias's proposal is dbus-independence. Dbus is great on Linux, but is a poor fit for OSX, and Win32. Dunno about Android, but iOS is decidedly daemon-hostile, so dbus isn't likely to happen there. As an aside, has anyone ever gotten a Gtk-based program into the iTunes Store -- or the App Store, for that matter? Anyway, all-in-all this looks very good to me. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
[gtk-osx-devel] gtk-mac-bundler 0.7.2
But I found another problem almost immediately, so I'll release 0.7.3 tomorrow. About gtk-mac-bundler = Gtk-mac-bundler creates an OS X Application Bundle from a Gtk+ Quartz application, automatically retrieving all shared library dependencies of the application and any designated executables or loadable modules, converting the rpaths to the bundle locations for all binaries. Data files, translations, and themes are also installed. Gtk-mac-bundler is licensed under the Gnu General Public License Version 2. Resulting bundles carry whatever licenses govern their contents. Download http://download.gnome.org/sources/gtk-mac-bundler/0.7/gtk-mac-bundler-0.7.2.tar.xz (26.0K) sha256sum: 74dedb55ed07dc610932e487482faaf9884e03151131ea0af5fd54bf857abc95 ___ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Re: [gtk-osx-devel] Previous method for building gtkmm3
On Oct 21, 2012, at 9:35 AM, Jim Charlton j...@jimc.dyndns.org wrote: Here is my previous method for building gtkmm3 on LION jhbuild bootstrap --skip libiconv edited .jhbuildrc to change modulesets-stable to modulesets-unstable Don't edit .jhbuildrc. You can set moduleset = foo (with whatever value of foo you like) in .jhbuildrc-custom. added os.environ[ARCHFLAGS] = -arch x86_64 to .jhbuildrc-custom jhbuild build meta-gtk-osx-bootstrap jhbuild build meta-gtk-osx-gtkmm (it will halt on errors) independently build/install mm-common and meta-gtk-osx-freetype and put a link between .../gtk/inst/lib/freetype and .../freetype2. Since you're building from unstable, and so using Pango git master, you shouldn't need Freetype anymore. I (just) added mm-common as a dependency of libsig++, so you won't need to build it after I push the commit. jhbuild build --skip=atk-bridge gtk+-3.0 Probably better to build meta-gtk-osx-gtk3. The atk-bridge module has been removed, and the gtk3 module's autogen-args includes --without-atk-bridge, the skip isn't needed. got atkmm-2.22.6.tar from gnome.org and unpacked it, started a jhbuild shell and ./configure, make, make install I've just added that to the moduleset as well. continue building meta-gtk-osx-gtkmm That worked a few months ago and I never got the gobject-introspection error. I will try again from scratch and see how it now works. Better to wait a little while, I'm testing my additions to the moduleset and I'll push it when I'm done. Regards, John Ralls ___ Gtk-osx-devel-list mailing list Gtk-osx-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
Re: Introspecting Pango
On Sep 13, 2012, at 10:56 AM, Mike Dupont jamesmikedup...@googlemail.com wrote: see this example: https://mail.gnome.org/archives/commits-list/2012-August/msg00770.html type name=TestTypeGUInt64 c:type=RegressTestTypeGUInt64/ it seems that you are missing the name attribute. mike Correct. But foo.gir files aren't made by people, they're made by g-ir-scanner. g-ir-scanner isn't creating the name attribute from the #defines. The question is, what hint (i.e. annotation) to I pass to g-ir-scanner to get it to do the right thing? Regards, John Ralls On Tue, Sep 11, 2012 at 8:41 PM, John Ralls jra...@ceridwen.us wrote: I'm trying to make Pango introspect on OSX, and The following defines are giving me trouble: #define PANGO_GLYPH_EMPTY ((PangoGlyph)0x0FFF) #define PANGO_GLYPH_INVALID_INPUT ((PangoGlyph)0x) #define PANGO_GLYPH_UNKNOWN_FLAG((PangoGlyph)0x1000) Produce the following in Pango-1.0.gir: constant name=GLYPH_EMPTY value=268435455 c:type=PANGO_GLYPH_EMPTY type c:type=PangoGlyph/ /constant Which dependent introspections (including PangoCairo) reject with the following: Pango-1.0.gir:40:34: error: Line 40, character 34: The attribute 'name' on the element 'type' must be specified error parsing file Pango-1.0.gir: Line 40, character 34: The attribute 'name' on the element 'type' must be specified make[4]: *** [Pango-1.0.typelib] Error 1 No doubt there's some magic annotation to fix that, but I can't see it from the annotations page on GnomeLive [1]. What is it? Regards, John Ralls [1] https://live.gnome.org/GObjectIntrospection/Annotations ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org Saving wikipedia(tm) articles from deletion http://SpeedyDeletion.wikia.com Contributor FOSM, the CC-BY-SA map of the world http://fosm.org Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Introspecting Pango
I'm trying to make Pango introspect on OSX, and The following defines are giving me trouble: #define PANGO_GLYPH_EMPTY ((PangoGlyph)0x0FFF) #define PANGO_GLYPH_INVALID_INPUT ((PangoGlyph)0x) #define PANGO_GLYPH_UNKNOWN_FLAG((PangoGlyph)0x1000) Produce the following in Pango-1.0.gir: constant name=GLYPH_EMPTY value=268435455 c:type=PANGO_GLYPH_EMPTY type c:type=PangoGlyph/ /constant Which dependent introspections (including PangoCairo) reject with the following: Pango-1.0.gir:40:34: error: Line 40, character 34: The attribute 'name' on the element 'type' must be specified error parsing file Pango-1.0.gir: Line 40, character 34: The attribute 'name' on the element 'type' must be specified make[4]: *** [Pango-1.0.typelib] Error 1 No doubt there's some magic annotation to fix that, but I can't see it from the annotations page on GnomeLive [1]. What is it? Regards, John Ralls [1] https://live.gnome.org/GObjectIntrospection/Annotations ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Adding gtkparasite to gtk?
On Feb 16, 2012, at 9:00 AM, Colin Walters wrote: On Tue, 2012-02-14 at 16:25 +, Richard Hughes wrote: and the upstream seems unwilling to port to GTK3, Why? [Snip] It depends on pygtk, You answered your own question. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: How GTK styling works
On Jan 16, 2012, at 1:04 PM, Benjamin Otte wrote: CSS goes in, styled windows come out. You can't explain that. And quite frankly, that sucks. So here's a high-level overview of how the GTK CSS machinery works in master. [SNIP] Benjamin, That's a great write-up. Thanks for the great explanation. There's one thing that could make it better: Put it on GnomeLive! so that it's easy to find, even for people who don't read this list. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Jan 12, 2012, at 3:32 AM, Paolo Borelli wrote: Benjamin Otte otte at gnome.org writes: One thing I've been wondering about is what features GTK is missing. This is mostly about developer-visible APIs, ie new widgets, and not about internal changes. I have some ideas from IRC discussions, mails and applications, but of course there might be big things I'm missing. UNDO A full undo/redo stack may belong in glib, but I'd be happy enough if TextView and TextEntry supported it SPELL CHECKING Once again, a full spell checking api may belong in glib, but I'd be happy enough to have it in gtk and easily enabled for TextView and TextEntry It already exists as an add-on package: http://gtkspell.sourceforge.net It works quite well, and has recently been revived under a new maintainer after languishing for a couple of years. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMenuModel has landed
On Dec 8, 2011, at 4:58 PM, Ryan Lortie wrote: hi, On Fri, 2011-12-09 at 01:34 +0100, Andrea Bolognani wrote: Does this mean different windows belonging to the same application will not be able to have different per–window menubars? I’m thinking about Empathy here, with its Buddy List and Conversation windows having different menubars, but it’s not an uncommon scenario. I guess a reasonable question to ask here is what empathy would look like if it were an application designed for mac os. I think that you misunderstand how mac os works. Yes, a single menu bar is displayed at the top of the screen. This is correct behavior according to Fit's Law, because you can bang the pointer to the top of the screen and it can't overshoot. No, applications are not limited to having a single menu bar. It's a one-liner to switch menubars when different window (or notebook tab, for that matter) gets focus. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject-introspection broken (?) on quartz ?
On Nov 18, 2011, at 6:53 AM, Kristian Rietveld wrote: On Nov 18, 2011, at 2:03 PM, Paul Davis wrote: On Fri, Nov 18, 2011 at 7:56 AM, Paul Davis p...@linuxaudiosystems.com wrote: On Fri, Nov 18, 2011 at 3:18 AM, Kristian Rietveld k...@loopnest.org wrote: Which machine is this on? If this is on Tiger, you need to build yourself a newer make (3.71, it's in MacPorts) because things break with the (old) make 3.70 that's shipped with latest XCode for Tiger. did you mean GNU Make? which is at version 3.82 now? My apologies (I didn't have my Tiger machine handy), I meant that Tiger ships with GNU make 3.80 and you need at least GNU make 3.81. This is due to usage of $(or ...) and/or $(and ...) which are only available in 3.81 onwards. Interesting. I hadn't encountered that problem before. I'll add a newer make to the bootstrap module and skip it for later OSX versions. For future reference, please use gtk-osx-users-l...@gnome.org for gtk-osx build problems. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject-introspection broken (?) on quartz ?
On Nov 18, 2011, at 7:02 AM, John Ralls wrote: On Nov 18, 2011, at 6:53 AM, Kristian Rietveld wrote: On Nov 18, 2011, at 2:03 PM, Paul Davis wrote: On Fri, Nov 18, 2011 at 7:56 AM, Paul Davis p...@linuxaudiosystems.com wrote: On Fri, Nov 18, 2011 at 3:18 AM, Kristian Rietveld k...@loopnest.org wrote: Which machine is this on? If this is on Tiger, you need to build yourself a newer make (3.71, it's in MacPorts) because things break with the (old) make 3.70 that's shipped with latest XCode for Tiger. did you mean GNU Make? which is at version 3.82 now? My apologies (I didn't have my Tiger machine handy), I meant that Tiger ships with GNU make 3.80 and you need at least GNU make 3.81. This is due to usage of $(or ...) and/or $(and ...) which are only available in 3.81 onwards. Interesting. I hadn't encountered that problem before. I'll add a newer make to the bootstrap module and skip it for later OSX versions. For future reference, please use gtk-osx-users-l...@gnome.org for gtk-osx build problems. I should also have mentioned that in general MacPorts isn't compatible with gtk-osx. Their set up pollutes the global environment, so the linker will often find their libraries instead of the ones built with gtk-osx. I know that you two (Kris and Paul) are expert enough to fix that, but there are lots of folks out there who aren't -- hence the warning on the Building page Paul referenced. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
On Oct 11, 2011, at 3:18 PM, Paul Davis wrote: On Mon, Oct 10, 2011 at 4:11 PM, John Ralls jra...@ceridwen.us wrote: Please have a look and comment either here or directly to me. I'd like to merge this into gtk-web master by Thursday. looks good to me. we should also get ardour onto the ported-app list somehow. It's a wiki. Just do it. ;-) Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
I've made a lot of progress on this in the last few weeks. The wiki pages are transferred, the gtk-osx, gtk-mac-integration, gtk-mac-bundler projects are in git.gnome and ftp.gnome, and Kris has gotten most of the patches reviewed and I've pushed them. Now to the web page. I've written a replacement for www.gtk.org/downloads/macos.php with a lot of editorial help from Martyn, and it's now ready for you all to review. Martyn has put up a preview at http://curlybeast.net:8080/download/macos.php Please have a look and comment either here or directly to me. I'd like to merge this into gtk-web master by Thursday. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: SF Bay Area GNOME Hackers
On Sep 15, 2011, at 4:46 PM, Bob Murphy wrote: Some of the SF Bay Area GNOME hackers will be getting together for beer and hackish discussion on September 22. I've been working on documenting the WebKitGTK DOM API, and will bring along copies for review. If you're interested in attending, check out the event page at http://www.meetup.com/Bay-Area-GNOME-Developers/events/33740822/ Sorry, it's my sister's birthday and we're doing a family dinner. Maybe next time. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
On Sep 7, 2011, at 7:26 AM, Federico Mena Quintero wrote:
Now, on technical matters:
I looked quickly at git diff origin/master..origin/quartz-integration
and the diff is very simple:
* A bunch of changes to gdk-quartz and gtk*-quartz.c - I imagine that
these can be merged just as they are, since they don't touch the
platform-independent code at all. I'm sure some of these bits could be
reviewed / prettified by someone who knows a lot of OSX idioms, but it's
better to have them in *now* and polish them later.
* This bit:
--- a/gdk/x11/gdkdevicemanager-xi2.c
+++ b/gdk/x11/gdkdevicemanager-xi2.c
@@ -417,10 +417,6 @@ gdk_x11_device_manager_xi2_constructed (GObject *object)
for (i = 0; i ndevices; i++)
{
dev = info[i];
-
- if (!dev-enabled)
- continue;
-
add_device (device_manager, dev, FALSE);
No idea what that's about.
Not mine, likely due to my having turned off the nightly merges/builds/pushes
until this matter gets sorted.
* Some Makefile.am changes; these could use a quick sanity check.
* Some additions to gtkprivate.h, analogous to what it has for win32 right
now.
* A bunch of #ifndef GDK_WINDOWING_QUARTZ in gtkselection.c, so that
those functions can be implemented in gtkselection-quartz.c instead.
This can probably be made prettier by moving the original functions to a
gtkselection-x11.c or something like that.
Or I could duplicate the whole file, as was done with gtkdnd-quartz.c and
gtkclipboard-quartz.c. I prefer not to do that because any maintenance on the
primary file will cause problems unless it's quickly noticed and the
quartz-specific file is also updated.
There's a larger problem with this, though, worthy of its own thread: Compile
time OS/GDK_WINDOWING checks break the multiple-backend architecture of Gtk3.
Quartz is the worst offender, but there are ifdef OS_WIN32 blocks floating
around too.
* An unused variable in gtkthemingengine.c; should be removed.
* Inconsequential whitespace changes in some .po files; should be
removed.
More out-of-sync-with-master differences.
* A tests/testundecorated.c - no idea.
Related to a crash in Lion with undecorated windows. See bug 655079. There's no
patch to add this to master; I'm not sure whether or not it should be. The fix
has already been committed to master and backported to 2.24, and the bug closed.
In all, it sounds like you could merge all the changes to *quartz*.[ch]
files as they are, and just give a quick look to the rest of the
changes.
As to what is in Bugzilla, is there a quick way to find all the Quartz
bugs to speed up their review? (Or are those patches already in the
quartz-integration branch? I didn't look at individual commits to see
if they had bug numbers.)
I rebased a local branch off quartz-integration against master and carefully
went through all of the changes. There were indeed a couple that didn't have
bugs, so I created the bugs and attached the relevant patches. There were some
others that were quite old, so I updated the patches on the bugs. The bugs in
question are:
514843: gtkfilechooser should be more robust
571582: GtkSelection implementation for quartz.
628936: Minimal change to pass introspection.
657770: Write releaseed memory in gtkdnd-quartz.c
607115: _gtk_key_hash_lookup fails to handle modifiers
658722: Drag and Drop sometimes stops working
658767: Drag and Drop NSEvent is Racy
658772: Directory paths for resource directories are hard coded.
Regards,
John Ralls
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
On Sep 8, 2011, at 4:55 AM, Olav Vitters wrote: On Wed, Sep 07, 2011 at 05:28:21PM -0700, John Ralls wrote: The rest of Gtk-OSX isn't Gtk. It's a build system using jhbuild with its own modulesets, The moduleset could just be in jhbuild? Not moduleset, modulesets. Three sets of 9 modulesets. Also 36 patches, some of which are obsolete and could be deleted (and a bunch more that could become obsolete if they were approved for committing to Gtk), a customized jhbuildrc and several examples for further customization. Yes, it could be integrated into the jhbuild repo, but it would take some discussion with the jhbuild maintainers to work out how to lay it out. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
On Sep 7, 2011, at 2:10 AM, Milan Bouchet-Valat wrote: Le mardi 06 septembre 2011 à 16:34 -0700, John Ralls a écrit : I'm not going to respond to most of that. I think you shouldn't take Emmanuele's tone so bad. ;-) He's always very direct, but his point is right, and his suggestions are actually the acknowledgment that your work is worth being part of core GTK - they are meant to help you. I'm going to try telling things in a slightly nicer fashion... Suffice it to say that building gtk-osx is largely automated, and there are well-tested instructions at http://sourceforge.net/apps/trac/gtk-osx/wiki/Build That's not the question. This page should be on live.gnome.org, because that's where we assume docs are, and people with an account there can give a hand. Well, you know what they say about assume, but OK. That's probably the easiest task on the list, though I think GnomeLive and Trac Wiki use some different notation so there would be some work reformatting unless someone knows of a ready-made translation program somewhere. I didn't get commit privs at Gnome.org until just under a year ago, 18 months after I took over from Richard. I still don't have privs on any of the other facilities except Bugzilla, and there only because I'm a Gnucash Dev. (That turns out to be sufficient for almost everything.) Maybe it took some time, but in my experience getting privileges is very fast. Anyway, now you have everything you need to work on gnome.org, don't you? No. I have commit privs on git.gnome.org, and dev privs on bugzilla (not through Gtk+, though). I would need to make binaries available on ftp.gnome.org and to have a support mailing list (which I haven't requested, so that's not anyone's fault. I did request privs for ftp.gnome.org at the same time I requested git commit privs, but that wasn't granted.) Gtk-OSX needs its own mailing list because it provides jhbuild modules for over 100 separate projects, not all of which are even Gnome. It's not feasible for me to monitor all of them for support, nor is it reasonable for users of my build scripts to have to figure out which one to use for any particular problem. So maybe you need a separate mailing list for helping building these programs, but it could live on gnome.org. For GTK+ development itself , the present list is the natural place, like Emmanuele said. And the fact that I'm here shows that I agree. Shawn was here (until Olaf kicked him off this morning) for the same reason. I'm quite aggressive about pushing problems about whatever module to the appropriate bug tracker or mailing list. (In most cases, that's gtk-app-devel rather than gtk-devel for gtk.) It's not a fork of Gtk+ (yet, though on days like this one I get really tempted). I actually revived the gtk-osx project on SF; the previous version was an actual fork of Gtk1. So let's improve things a step more, and completely merge the project. Sounds like the natural end of the story. :-) Merge which project with what? The actual build project could be merged with jhbuild, but it's not a simple dropin and would need to be discussed. Where should that discussion take place? Here? I could create projects for ige-mac-bundler and ige-mac-integration (though they should probably be renamed to gtk-mac-foo) on git.gnome.org, but unless I can upload the tarballs it doesn't do me much good. gtk-quartz-engine is already on git.gnome. On the other hand, bundling is part of building, so bundler could be folded into jhbuild. Ige-mac-integration is an add-on to Gtk that (rather tortuously) puts the menus on the mac menu bar and provides access to the Dock menu for Gtk applications. I think it could be integrated into Gtk+ (I haven't tried) but since some app devs like to keep the menus on the windows, it should probably be a runtime option. Two other pieces, gtk-osx-docbook and gnome-doc-utils-fake, could be combined under a mac support directory of jhbuild. They don't need much maintenance (I haven't needed to touch either of them since I got them from Richard), but their tarballs need to be hosted somewhere. Bugs are another issue. If the build portion gets merged with jhbuild, then I'd say there should be an osx component there to receive gtk-osx bugs. (There haven't been many.) The webpage could be moved into gtk.org, though I don't think it should go under downloads as that conveys rather the wrong impression. Some assembly (no, not that kind ;-) ) definitely required. It would take a bit of cleanup to make it look like the rest of the Gtk website; more important, it would need to be converted to php, and I have zero knowledge about how to do that. As I explained earlier, the changes *are* patches, they *are* attached to bugs in Bugzilla, and Kris Reitveld *has* promised to review them. When he has had time to do so and they have been polished to his high standards, they will be committed into mainline. If you need
Re: GTK and OSX: a call to sanity
On Sep 7, 2011, at 7:26 AM, Federico Mena Quintero wrote: On Wed, 2011-09-07 at 08:25 +0100, Emmanuele Bassi wrote: Windows and Linux build issues and support are handled on gnome.org: the Quartz backend of gtk is not in any regard special and it should not need separate resources. One thing we have been bad at is learning to accept that sometimes, our Gnome ecosystem breeds little niches of their own, and then some of them turn into rightful ecosystems that *don't really need* much communication with the mainline - they can exist on their own, with occasional re-syncs, and with occasional pain. I imagine that the Quartz backend is such a case: it probably started as a let's port this and see where it takes us exercise, and then people started writing jhbuild modulesets for apps, integration patches, etc. It started growing and generating its own gravity and it didn't really need to share much with Gnome or GTK+ proper - it would have been nice to keep everything integrated from the start, in both code and infrastructure, but it would probably have implied a lot of extra work for both parties. *Now* it seems to be the time where the cost of keeping things separate is greater than just re-syncing periodically - so let that be; do the integration and forget about the temporary split. You can think of this work of merging as the necessary work to meld two ecosystems together - you can't put a desert next to a jungle without a savannah in the middle. Okay, bad analogy, but I'm only on my first coffee today. It's important not to confuse Gtk-OSX with Gtk's quartz backend. The latter is completely part of Gtk, and I use Gtk's facilities exclusively for working on it... except for ige-mac-integration, a library which allows Gtk applications to use the Mac menu bar and Dock menus, and is still a separate project because I haven't mad time to integrate it. OTOH, I wrote the gtkselection implementation 2 years ago and the patch [1] is still in the review hopper, so I'm not the only one short on time. The rest of Gtk-OSX isn't Gtk. It's a build system using jhbuild with its own modulesets, a python script for making application bundles, and a few other bits and pieces, including gtk-quartz-engine, a Cocoa HIT theme engine which I haven't touched since Richard Hult left it to me except to ensure that the github and git.gnome.org repos are the same. I don't even know if it works with Gtk3. What's the cost of keeping those bits on Sourceforge vs. Gnome.org? ISTM it will cost me a lot of time and effort to move them into gnome.org with no real benefit to anyone except Emmanuele who can't seem to get an SF account. (Emmanuele, if you really want to sort that out, email me directly and I'll see what I can do to help.) Regards, John Ralls [1] https://bugzilla.gnome.org/show_bug.cgi?id=571582 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Alt and Command keys in the quartz backend
On Sep 6, 2011, at 1:27 AM, Michael Natterer wrote: Hi all, Currently, the mapping of the Alt and Command keys on the mac is completely screwed: - The key labeled Command maps to GDK_MOD1_MASK (which is essentially interpreted as Alt by all existing code) - The key labeled Alt isn't mapped to any modifier at all Now there is a lot of discussion in these bug reports: https://bugzilla.gnome.org/show_bug.cgi?id=607115 https://bugzilla.gnome.org/show_bug.cgi?id=605799 but at the bottom of all that is the above mentioned problem. After it's fixed we can fix whatever keymap issues in GTK on top. It seems pretty obvious to me that the key labeled Alt should produce GDK_MOD1_MASK because all existing code considers that being the Alt key. The only question is what to map Command to, and we are free to choose whatever, since the behavior will change away from the current one of producing GDK_MOD1_MASK anyway. I personally prefer GDK_META_MASK because it's what the Windows key is mapped to on PC keyboards, but that's not a strong reason (and it is, as saidm completely arbitrary anyway). Opinions? I volunteer to patch up all 3 branches once we come to an agreement. How long have you been using a Mac as your primary computer? On what mac-native programs that you use daily is the alt/OPTION key used as a stand-alone modifier for shortcuts with default settings (any preference changes you've made don't count)? How does the code know what key produces the mod1 bit? Why would it care? Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Alt and Command keys in the quartz backend
On Sep 6, 2011, at 6:53 AM, Michael Natterer wrote: On Tue, 2011-09-06 at 06:37 -0700, John Ralls wrote: On Sep 6, 2011, at 1:27 AM, Michael Natterer wrote: Hi all, Currently, the mapping of the Alt and Command keys on the mac is completely screwed: - The key labeled Command maps to GDK_MOD1_MASK (which is essentially interpreted as Alt by all existing code) - The key labeled Alt isn't mapped to any modifier at all Now there is a lot of discussion in these bug reports: https://bugzilla.gnome.org/show_bug.cgi?id=607115 https://bugzilla.gnome.org/show_bug.cgi?id=605799 but at the bottom of all that is the above mentioned problem. After it's fixed we can fix whatever keymap issues in GTK on top. It seems pretty obvious to me that the key labeled Alt should produce GDK_MOD1_MASK because all existing code considers that being the Alt key. The only question is what to map Command to, and we are free to choose whatever, since the behavior will change away from the current one of producing GDK_MOD1_MASK anyway. I personally prefer GDK_META_MASK because it's what the Windows key is mapped to on PC keyboards, but that's not a strong reason (and it is, as saidm completely arbitrary anyway). Opinions? I volunteer to patch up all 3 branches once we come to an agreement. How long have you been using a Mac as your primary computer? On what mac-native programs that you use daily is the alt/OPTION key used as a stand-alone modifier for shortcuts with default settings (any preference changes you've made don't count)? I don't see how this is relevant, but i bow to your experience. How does the code know what key produces the mod1 bit? Why would it care? Code *knows* that MOD1 is Alt, and there is a key named Alt on the keyboard. Therefore it must produce MOD1. There is nothing to argue here. There is no reason to not use that consistency across 3 platforms when we can get it for free. Really? Gtk+ is activating the camera in my Macbook and watching me push the alt/option key? Your argument is absurd on its face, as I said in the discussion on bug 607119. As for why using a Mac is relevant, the object of the exercise is to produce programs which are as well-integrated as possible into the Mac user experience. If mac users want to run programs that behave like X11, they run them under X11 (which is provided by Apple as part of the OS, and which initializes automatically when the machine receives an X11 connection request). Users of Gtk programs with the quartz backend want their programs to behave like native programs. Since you don't actually use a Mac, and apparently haven't surveyed mac users, why do you think that you should be able to dictate how they use their computers, or how the Quartz maintainers configure Gtk to work on a Mac? By the way, the key you claim is named Alt is in fact named option; it has a smaller label alt in the upper left corner of the key, just as the command key has a quatrefoil symbol in the upper left corner (older keyboards had an Apple logo on that key as well, and it was often referred to as the Apple key). It is sometimes referred to as the alt/option key, and while it's true that the enum name for it in Cocoa is NSAlternateKey, that's invisible to users. As I've also explained more than once in the long running discussion on 607119, the primary function of the option key is to extend the keyboard for i18n, a feature upon which many European users depend, and which conflicts with using option as a naked accelerator (i.e., without command or control as additional modifiers) in text context -- meaning at all in practice. In other words, you're right that there's nothing to argue, but you're wrong that option should be mapped to Mod1. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Alt and Command keys in the quartz backend
On Sep 6, 2011, at 9:58 AM, Paul Davis wrote: On Tue, Sep 6, 2011 at 12:49 PM, Michael Natterer mi...@gimp.org wrote: On Tue, 2011-09-06 at 08:27 -0700, John Ralls wrote: [ ... imminent turf war ... ] this seems to be about two different things, neither of which are in conflict (and i think john actually agrees with this). 1) whether or not the Alt key should generate MOD1 as a modifier 2) whether or not code that wants to be cross-platform can assume that they can use MOD1 with its own chosen semantics the problem is that (2) includes GTK, not just applications, and GTK already makes this assumption. as a result, john changed the modifier that alt/option generates on OS X, because (2) is not true for OS X. if (2) was fixed so that GTK was not an example of code that assumes that MOD1 is free for any interpretation on any platform, then (1) is moot, and it really doesn't matter what the Alt key generates on OS X (hence, it could be MOD1). but as long as (2) remains an issue within GTK itself, its hard to argue that a key that has clearly different purposes for a large body of platform users of OS X should be handled by GTK as if it had some different meaning based on another platform. Actually, that was last changed by Richard Hult in 2008 [1], about 6 months before I got involved. I think I'd go further and require that the MODX masks be made private to GDK before I'd agree that it's moot. Even with the MOD1 hardcoding in Gtk removed there are still lots of other cases running around, and we'd still get complaints like Michael's that it's somehow broken. Regards, John Ralls [1] http://git.gnome.org/browse/gtk+/commit/gdk?id=31357d3cc7d37e5b0fe674835406c255a961a358 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Alt and Command keys in the quartz backend
On Sep 6, 2011, at 10:42 AM, Michael Natterer wrote: On Tue, 2011-09-06 at 12:58 -0400, Paul Davis wrote: On Tue, Sep 6, 2011 at 12:49 PM, Michael Natterer mi...@gimp.org wrote: On Tue, 2011-09-06 at 08:27 -0700, John Ralls wrote: [ ... imminent turf war ... ] this seems to be about two different things, neither of which are in conflict (and i think john actually agrees with this). 1) whether or not the Alt key should generate MOD1 as a modifier 2) whether or not code that wants to be cross-platform can assume that they can use MOD1 with its own chosen semantics the problem is that (2) includes GTK, not just applications, and GTK already makes this assumption. as a result, john changed the modifier that alt/option generates on OS X, because (2) is not true for OS X. if (2) was fixed so that GTK was not an example of code that assumes that MOD1 is free for any interpretation on any platform, then (1) is moot, and it really doesn't matter what the Alt key generates on OS X (hence, it could be MOD1). but as long as (2) remains an issue within GTK itself, its hard to argue that a key that has clearly different purposes for a large body of platform users of OS X should be handled by GTK as if it had some different meaning based on another platform. That's not what I'm asking for. The only special meaning of Alt in GTK is to invoke mnemonics. Other than that, it's simply a modifier. Same on the Mac, it's just a modifier. Let's just disable the mnemonics on the Mac then. The fact that the OS uses it to generate special characters is not really relevant here. One X11 window manager steals key combo A from the app, the other one key combo B, there is nothing I can do about this. Turning Alt into Alt fixes more than it breaks. It fixes e.g. configuring GTK keybindings (you can easily make Alt-cursor do word navigation then, the config file says alt, it's all correctly mapped, the modifier says alt, and it just works). And it's not just key bindings. Alt-click should be alt-click, there is nothing wrong about that. If the OS decides to use it for its own purposes, then it's the job of higher-level code to be aware of that. If we need to change something in GTK as a consequence of that change, then so be it, but please let's not do strange stuff to the quartz' backend's modifier mapping just to accommodate some code in GTK that was never meant to handle the Mac, but can easily be changed to simply do it. It's not really different. Getting rid of the hard-coded association between alt in an accelerator map or key binding and GDK_MOD1_MASK is part of Paul's (2). I'd map it to GDK_META_MASK, but I'm open to super, hyper, or a new GDK_ALT_MASK (bit 25, perhaps). It *is* the right thing to do, I think, but it's not a quartz-only change and it probably would not be welcome in gtk+-2.24. This doesn't have anything to do with being able to map option-d to an accelerator map item altd and have it work. It won't. (At present in master altd will map to command-d, which works fine and presents only a documentation problem to the app developer.) Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
On Sep 6, 2011, at 11:12 AM, Emmanuele Bassi wrote: okay, I've tried to get ahold of the gtk-osx project for a while, now, but since sf.net is just a joke and decided to reject my @gmail.com emails, let's try here. can we *please* stop this madness: 17:05 CIA-8 jralls quartz-integration * r7e37d94f2178 gtk+/ (10 files in 4 dirs): Merge branch 'master' into quartz-integration 17:05 CIA-8 jralls quartz-integration * rf75a882670a8 gtk+/ (9 files in 4 dirs): Merge branch 'master' into quartz-integration 17:05 CIA-8 jralls quartz-integration * r8c288f0f890e gtk+/ (24 files in 7 dirs): Merge branch 'master' into quartz-integration 17:05 CIA-8 jralls quartz-integration * r41abe4a72f16 gtk+/ (4 files in 3 dirs): Merge branch 'master' into quartz-integration 17:05 CIA-8 jralls quartz-integration * r964b25d17b45 gtk+/ (35 files in 3 dirs): Merge branch 'master' into quartz-integration if there are patches for gtk-quartz, why are these inside at least three branches instead of being committed to corresponding main line one? why are these branch continuously being merged instead of being rebased, if they are personal branches? why are the tools to make bundles and modulesets hosted on github instead of being on gnome.org? why is gtk-osx a separate project, with mailing lists hosted on sourceforge, instead of being on gnome.org? every time that a project maintainer decides to use sourceforge, the Universe kills a puppy. can we please, *please*, for the love of all that's nice and pure in this Universe, stop killing puppies? Emmanuele, You could have written me directly: my email address is in the git repositories, attached to the commits that you're complaining about. The tools and modulesets are on GitHub because that's where Richard Hult put them when he started 5 or 6 years ago and I haven't had time to change that since getting commit privs on git.gnome.org last year. What bothers you about it? Gtk-OSX is a separate project hosted on Sourceforge because Richard was using the facilities of his company, Imendio, which he had just dissolved. Those resources weren't available to me. The barriers to setting up a full project on Gnome including mailing lists, a bugtracker, web fora, source repositories, web pages, and ftp downloads seem daunting and time consuming -- while I (or anyone else) can have it set up on Sourceforge in a few hours with a single request. Sourceforge is working well hosting all of that stuff and no puppies are being killed -- nor is anything else bad happening. I'm sorry that you're irritated by the noise of the daily merges between master and quartz-integration, and between gtk-2.24 and gtk-2.24-quartz. Those tracking branches exist because I want to make it easy for application developers to use my changes to quartz, synchronized with the latest changes on the masters of each branch. Kris Reitveld asked me to wait until he reviews the patches to commit them to the mainline branches, and since his review is very valuable (he has a much deeper knowledge of the codebase than I do) I am complying with his request. If the noise from the merges is really that annoying I can easily move the quartz branches to Github and delete them from git.gnome.org. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Alt and Command keys in the quartz backend
On Sep 6, 2011, at 12:10 PM, Michael Natterer wrote: On Tue, 2011-09-06 at 11:57 -0700, John Ralls wrote: On Sep 6, 2011, at 10:42 AM, Michael Natterer wrote: On Tue, 2011-09-06 at 12:58 -0400, Paul Davis wrote: On Tue, Sep 6, 2011 at 12:49 PM, Michael Natterer mi...@gimp.org wrote: On Tue, 2011-09-06 at 08:27 -0700, John Ralls wrote: [ ... imminent turf war ... ] this seems to be about two different things, neither of which are in conflict (and i think john actually agrees with this). 1) whether or not the Alt key should generate MOD1 as a modifier 2) whether or not code that wants to be cross-platform can assume that they can use MOD1 with its own chosen semantics the problem is that (2) includes GTK, not just applications, and GTK already makes this assumption. as a result, john changed the modifier that alt/option generates on OS X, because (2) is not true for OS X. if (2) was fixed so that GTK was not an example of code that assumes that MOD1 is free for any interpretation on any platform, then (1) is moot, and it really doesn't matter what the Alt key generates on OS X (hence, it could be MOD1). but as long as (2) remains an issue within GTK itself, its hard to argue that a key that has clearly different purposes for a large body of platform users of OS X should be handled by GTK as if it had some different meaning based on another platform. That's not what I'm asking for. The only special meaning of Alt in GTK is to invoke mnemonics. Other than that, it's simply a modifier. Same on the Mac, it's just a modifier. Let's just disable the mnemonics on the Mac then. The fact that the OS uses it to generate special characters is not really relevant here. One X11 window manager steals key combo A from the app, the other one key combo B, there is nothing I can do about this. Turning Alt into Alt fixes more than it breaks. It fixes e.g. configuring GTK keybindings (you can easily make Alt-cursor do word navigation then, the config file says alt, it's all correctly mapped, the modifier says alt, and it just works). And it's not just key bindings. Alt-click should be alt-click, there is nothing wrong about that. If the OS decides to use it for its own purposes, then it's the job of higher-level code to be aware of that. If we need to change something in GTK as a consequence of that change, then so be it, but please let's not do strange stuff to the quartz' backend's modifier mapping just to accommodate some code in GTK that was never meant to handle the Mac, but can easily be changed to simply do it. It's not really different. Getting rid of the hard-coded association between alt in an accelerator map or key binding and GDK_MOD1_MASK is part of Paul's (2). I'd map it to GDK_META_MASK, but I'm open to super, hyper, or a new GDK_ALT_MASK (bit 25, perhaps). It *is* the right thing to do, I think, but it's not a quartz-only change and it probably would not be welcome in gtk+-2.24. It is not the right thing to do. Why do you insist on that, and what is wrong about the hard-coded association between ALT and MOD1_MASK? What is the problem about fixing GDK to map Alt to what is globally considered Alt, and then fix the platform-specific things in GTK+ afterwards? For one thing, the platform-specific stuff belongs in Gdk. That's why there's gdk/broadway, gdk/quartz, gdk/wayland, gdk/win32, and gdk/x11. Yes, there are gtkdnd-quartz, gtkclipboard-quartz, gtkstatusicon-quartz, and (in quartz-integration) gtkselection-quartz. That's an unfortunate side effect of the main implementations being so closely tied to the X11 model that they couldn't be integrated with quartz at the gdk level, and it breaks the multiple-backend feature of Gtk+-3. For another, key-mapping is done in gdk as the very first step in processing a native key-down/up event (well, OK, the second step, the first being to decide that it's a key-down/up event and to dispatch it to the key-mapping routine). That is, of course, in a virtualized gdk function call. You're proposing to then reinterpret those key-down/up events in gtk? That seems rather complicated. Nothing is wrong with alt being mapped to GDK_MOD1_MASK so long as NSCommandKey is also mapped to GDK_MOD1_MASK. Why do you object to that? Is it that the GIMP documenters don't want to write (Command-foo on Macs) next to every occurrence of The accelerator for Bar is Alt-foo? Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Alt and Command keys in the quartz backend
On Sep 6, 2011, at 1:13 PM, Michael Natterer wrote: On Tue, 2011-09-06 at 21:51 +0200, Kristian Rietveld wrote: On Sep 6, 2011, at 6:58 PM, Paul Davis wrote: this seems to be about two different things, neither of which are in conflict (and i think john actually agrees with this). 1) whether or not the Alt key should generate MOD1 as a modifier 2) whether or not code that wants to be cross-platform can assume that they can use MOD1 with its own chosen semantics I have typically avoided the debate on modifiers/etc. since I am not very familiar with the X11 background of them either. The two things you set out indeed seem to make much sense to me. The big question to me is around (2), if MOD1 is passed by GDK, should GTK+ or an application still include cross-platform handling or should the cross-platform handling already been taken care of? I get the impression that given that keybindings still need cross-platform porting at the GTK+ level, the former is perhaps not a strange assumption. For the former, having modifiers bound to keys with similar labels is, I *think*, helpful for implementing the cross-platform handling in GTK+ and/or applications. I agree, and I would argue like this about ALT/MOD1: - on GTK+, ALT/MOD1 are used for mnemonics, which are typically translatable, which means unforeseeable, so cannot really be used for apps. - on the Mac, ALT/Option is used for generating special chars, which are different per keyboard layout, which means unforeseeable, so cannot really be used for apps. So there is no conflict here, see below. if (2) was fixed so that GTK was not an example of code that assumes that MOD1 is free for any interpretation on any platform, then (1) is moot, and it really doesn't matter what the Alt key generates on OS X (hence, it could be MOD1). but as long as (2) remains an issue within GTK itself, its hard to argue that a key that has clearly different purposes for a large body of platform users of OS X should be handled by GTK as if it had some different meaning based on another platform. My impression is that GTK+ has to be fixed first here before we can consider binding the key labeled with Alt to MOD1 like is done on other platforms. IMHO for the ALT/MOD1 mapping to work nicely, we simply need to hardcode gtk-enable-mnemonics to FALSE and we're done. Apps are used to have Alt-foo being taken by the system in an unpredictable way, and Alt-mouse interaction will just start working on the Mac too, so will keybindings that use Alt. Note that key bindings don't have above being taken problem, since they will typically modify a widget's key binding to do exactly what the respective Mac control does, so there should be no conflict. Did I miss anything here? Uh, won't hard coding gtk-enable-mnemonics=FALSE (I suppose you mean the GtkSettings property, and that you propose to do it inside of some sort of a runtime check for the quartz backend) mean that all keybindings, regardless of what modifier keys they use, *don't* work? Have you actually tried any of these things? On a Mac? With the deadkeys patch [1]? No? Why don't you, and when you get it working post your patch on Bug 607115 [2]? You might find the test program I posted there [3] helpful in understanding how the Apple keyboard differs from the Microsoft one. It should compile in a gtk-osx or macports-quartz environment with 'gcc -o keytest keytest.c `pkg-config --cflags --libs gtk+-3.0`' Regards, John Ralls [1] https://bugzilla.gnome.org/attachment.cgi?id=175439 [2] https://bugzilla.gnome.org/show_bug.cgi?id=607115 [3] https://bugzilla.gnome.org/attachment.cgi?id=175074 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
On Sep 6, 2011, at 3:07 PM, Emmanuele Bassi wrote: On 2011-09-06 at 13:32, John Ralls wrote: if there are patches for gtk-quartz, why are these inside at least three branches instead of being committed to corresponding main line one? why are these branch continuously being merged instead of being rebased, if they are personal branches? why are the tools to make bundles and modulesets hosted on github instead of being on gnome.org? why is gtk-osx a separate project, with mailing lists hosted on sourceforge, instead of being on gnome.org? every time that a project maintainer decides to use sourceforge, the Universe kills a puppy. can we please, *please*, for the love of all that's nice and pure in this Universe, stop killing puppies? The tools and modulesets are on GitHub because that's where Richard Hult put them when he started 5 or 6 years ago and I haven't had time to change that since getting commit privs on git.gnome.org last year. What bothers you about it? that something that should be in a central location is not. in order to build gtk on OSX I have to hunt down various bits and blobs, and the barrier to contribution from me, a gtk developer, is higher. Gtk-OSX is a separate project hosted on Sourceforge because Richard was using the facilities of his company, Imendio, which he had just dissolved. Those resources weren't available to me. The barriers to setting up a full project on Gnome including mailing lists, a bugtracker, web fora, source repositories, web pages, and ftp downloads seem daunting and time consuming -- while I (or anyone else) can have it set up on Sourceforge in a few hours with a single request. Sourceforge is working well hosting all of that stuff and no puppies are being killed -- nor is anything else bad happening. sourceforge is working so well that it bounces and rejects my emails to the mailing lists for days. their bug tracking system is the scourge of the earth, and the mailing list archives are a joke. but those are moot points: the gtk resources *are* on gnome.org. why you need a separate mailing list and forum and bug tracker is beyond me: • once you have a Git account you can create repositories on git.gnome.org in 30 seconds; • the gtk bug tracking system in bugzilla.gnome.org; the Quartz backend specific bugs have a component under the gtk+ product; • the separate tools for OS X integration can get a separate product just by opening a bug on bugzilla.gnome.org; • the gtk website is hosted in git.gnome.org; the OS X integration should be part of that website; • downloads are available from download.gnome.org; • gtk has three mailing lists already: gtk-list, gtk-app-devel-list and gtk-devel-list; application and toolkit development on OS X is on topic on those three lists. there is no time consumption — just the willingness to cooperate in an open source project according to the rules of said open source project. I'm sorry that you're irritated by the noise of the daily merges between master and quartz-integration, I'm moderately irritated by the fact that the branch's history is immensely fucked up — but that's just because I'm OCD on the history in a revision control system. that is, however, *not* my issue. the issue is that those branches should *not* exist, unless they are personal development branches. if you plan on letting other users target them then you should get those commits merged into the main line and keep the patches in bugzilla, where the review for gtk fixes and enhancements happens. otherwise you're just forking gtk, and using the resources of the gtk project to give an aura of officiality to what is essentially your own personal project. I'm not going to respond to most of that. Suffice it to say that building gtk-osx is largely automated, and there are well-tested instructions at http://sourceforge.net/apps/trac/gtk-osx/wiki/Build I didn't get commit privs at Gnome.org until just under a year ago, 18 months after I took over from Richard. I still don't have privs on any of the other facilities except Bugzilla, and there only because I'm a Gnucash Dev. (That turns out to be sufficient for almost everything.) Gtk-OSX needs its own mailing list because it provides jhbuild modules for over 100 separate projects, not all of which are even Gnome. It's not feasible for me to monitor all of them for support, nor is it reasonable for users of my build scripts to have to figure out which one to use for any particular problem. It's not a fork of Gtk+ (yet, though on days like this one I get really tempted). I actually revived the gtk-osx project on SF; the previous version was an actual fork of Gtk1. As I explained earlier, the changes *are* patches, they *are* attached to bugs in Bugzilla, and Kris Reitveld *has* promised to review them. When he has had time to do so and they have been polished to his high standards
Re: Alt and Command keys in the quartz backend
On Sep 6, 2011, at 3:46 PM, Michael Natterer wrote: On Tue, 2011-09-06 at 14:30 -0700, John Ralls wrote: On Sep 6, 2011, at 12:10 PM, Michael Natterer wrote: On Tue, 2011-09-06 at 11:57 -0700, John Ralls wrote: On Sep 6, 2011, at 10:42 AM, Michael Natterer wrote: On Tue, 2011-09-06 at 12:58 -0400, Paul Davis wrote: On Tue, Sep 6, 2011 at 12:49 PM, Michael Natterer mi...@gimp.org wrote: On Tue, 2011-09-06 at 08:27 -0700, John Ralls wrote: [ ... imminent turf war ... ] this seems to be about two different things, neither of which are in conflict (and i think john actually agrees with this). 1) whether or not the Alt key should generate MOD1 as a modifier 2) whether or not code that wants to be cross-platform can assume that they can use MOD1 with its own chosen semantics the problem is that (2) includes GTK, not just applications, and GTK already makes this assumption. as a result, john changed the modifier that alt/option generates on OS X, because (2) is not true for OS X. if (2) was fixed so that GTK was not an example of code that assumes that MOD1 is free for any interpretation on any platform, then (1) is moot, and it really doesn't matter what the Alt key generates on OS X (hence, it could be MOD1). but as long as (2) remains an issue within GTK itself, its hard to argue that a key that has clearly different purposes for a large body of platform users of OS X should be handled by GTK as if it had some different meaning based on another platform. That's not what I'm asking for. The only special meaning of Alt in GTK is to invoke mnemonics. Other than that, it's simply a modifier. Same on the Mac, it's just a modifier. Let's just disable the mnemonics on the Mac then. The fact that the OS uses it to generate special characters is not really relevant here. One X11 window manager steals key combo A from the app, the other one key combo B, there is nothing I can do about this. Turning Alt into Alt fixes more than it breaks. It fixes e.g. configuring GTK keybindings (you can easily make Alt-cursor do word navigation then, the config file says alt, it's all correctly mapped, the modifier says alt, and it just works). And it's not just key bindings. Alt-click should be alt-click, there is nothing wrong about that. If the OS decides to use it for its own purposes, then it's the job of higher-level code to be aware of that. If we need to change something in GTK as a consequence of that change, then so be it, but please let's not do strange stuff to the quartz' backend's modifier mapping just to accommodate some code in GTK that was never meant to handle the Mac, but can easily be changed to simply do it. It's not really different. Getting rid of the hard-coded association between alt in an accelerator map or key binding and GDK_MOD1_MASK is part of Paul's (2). I'd map it to GDK_META_MASK, but I'm open to super, hyper, or a new GDK_ALT_MASK (bit 25, perhaps). It *is* the right thing to do, I think, but it's not a quartz-only change and it probably would not be welcome in gtk+-2.24. It is not the right thing to do. Why do you insist on that, and what is wrong about the hard-coded association between ALT and MOD1_MASK? What is the problem about fixing GDK to map Alt to what is globally considered Alt, and then fix the platform-specific things in GTK+ afterwards? For one thing, the platform-specific stuff belongs in Gdk. That's why there's gdk/broadway, gdk/quartz, gdk/wayland, gdk/win32, and gdk/x11. Yes, there are gtkdnd-quartz, gtkclipboard-quartz, gtkstatusicon-quartz, and (in quartz-integration) gtkselection-quartz. That's an unfortunate side effect of the main implementations being so closely tied to the X11 model that they couldn't be integrated with quartz at the gdk level, and it breaks the multiple-backend feature of Gtk+-3. For another, key-mapping is done in gdk as the very first step in processing a native key-down/up event (well, OK, the second step, the first being to decide that it's a key-down/up event and to dispatch it to the key-mapping routine). That is, of course, in a virtualized gdk function call. You're proposing to then reinterpret those key-down/up events in gtk? That seems rather complicated. I have no idea what you are talking about. Nothing is wrong with alt being mapped to GDK_MOD1_MASK so long as NSCommandKey is also mapped to GDK_MOD1_MASK. Why do you object to that? Is it that the GIMP documenters don't want to write (Command-foo on Macs) next to every occurrence of The accelerator for Bar is Alt-foo? Why on earth would you want to map both keys to the same modifier? Nobody uses Alt for accelerators, I don't think we are talking about the same things here, in GTK+: - Accelerator is the thing to invoke actions (menu shortcuts) - invoked by Command on the mac, and by Control on != Mac. - Mnemonic is the thing that invokes
Re: [g-a-devel] GTK and ATK
On May 12, 2011, at 5:25 AM, Piñeiro wrote: On 05/11/2011 02:57 PM, Benjamin Otte wrote: Well most of the paragraphs were already answered by Brian, but I would like to add a comment here.What concerns me a lot is that there is only very few applications that actually make use of this huge abstraction layer that is AT-SPI. I'm often thinking that we would have less code to maintain if we indeed wrote Orca code once for every toolkit we target Orca at instead of having to maintain a big ATK interface for every toolkit. (And the same for the other few applications that have accessibility requirements.) But of course I have no idea if that is actually true, Well, there are some issues with this proposal: * It is true that right now the AT more mature and maintained is Orca, but we still have other AT tools, like Caribou, Dasher (if it migrates to libatspi), MouseTrap/OpenGazer, Gnome Shell magnifier (Joseph is planning to use some AT-SPI features). * And although that would be true, I think that our target is GNOME being accessible, and provide a proper framework to do that. Just providing support to Screen Readers are limited. * In fact, improving the a11y general support would allow to create new ATs easily. * As you said, one of the current problems on the ATK-toolkit relation is that the implementor requires to know both in order to do a good work here. But with this proposal you are just moving from need to know about an abstract accessibility toolkit and an specific toolkit to need to know about screen readers and an specific toolkit. Screen readers can be tricky. * A lot of people working on those toolkits already know about abstract accessibility toolkits. IE: LibreOffice and Gecko has also support for IA2. Most of the people that are already implementing support for IA2 are also implementing ATK support. I just wouldn't rule it out from the start like you seem to do. Well, sorry if thats what you extracted from my comments. It is clear that current accessibility status is not good enough. Thats a fact. And we all are open to proposals to solve that. I was just trying to discuss your proposals in a constructive way. Sorry if I failed at that. What remains is that we have a problem: The AT code in GTK is so bad that it is off by default and nobody is in sight that wants to fix it. And that is bad. Well, just a comment here. As Brian said one of the reason is that a lot of effort these years were used on the at-spi IPC switch. During those years we were in a situation were nobody put a lot of effort on at-spi as it was using an deprecated technology, and at-spi2 was in a work in progress status. Mike Gorse was starting to try to solve the just on the last iterations. (And DBUS is still, in general, less performant that CORBA). Anyway, one of the big problems in performance preventing to having by default the a11y on is related to the treeview. Specifically the adding/removing a lot of rows on the model means a performance penalty [1]. As Li said a11y treeview implementation is really complex because the lacking way to expose the internal information of the treeview. I hope that this gail-to-gtk move could help to improve this, and mainly, simplify gailtreeview implementation. Right now it is mostly an gtktreeview replication. I would like to inject into this discussion the point that however a11y is implemented there need to be hooks to integrate it with the native a11y features of all platforms that Gtk supports, not just Linux. It rather misses the point of a11y to force users who depend upon it to use an a11y tool for the Gtk applications on their systems different from the one provided by the OS. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Make a UML model from GObject-Introspection Gir files
On Apr 26, 2011, at 1:11 PM, Stefan Kost wrote: Hi, Am 15.04.2011 03:01, schrieb John Ralls: I don't know if anyone else will find this useful, but I've written a perl program to translate gir files into xmi files which can be imported into ArgoUML or KDE Umbrello. It follows include elements, putting each Gir namespace into a separate package in the UML model. Sounds interesting. When running it I got a couple of Type resolution failure on property name=resolver introspectable=0 writable=1 transfer-ownership=none type/ /property Failed to find type name in element type/ at ./gir2xmi line 145. When I loaded the generated xmi into umbrello I got quite a few items in the logical view, but no single diagram. Should there be one? Yes, it doesn't silently ignore empty type elements. I think that more of a girscanner bug than a gir2xmi bug; the property should have a type. No, there's no diagram generated. Just drag the classes that you're interested in over to the diagram space. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
directory) and ask the OS for the path (CFBundle and NSBuncle provide interfaces for querying the bundle in C and Objective-C respectively). There is a plugin registration facility [3] that can be used for loadable modules, but is intended for third-party plugins of the sort common for web browsers. There's also some environment variables (which can be set with an Info.plist key or with a launcher script), LD_LIBRARY_PATH, DYLD_LIBRARY_PATH, and DYLD_FALLBACK_LIBRARY_PATH which control both the loading of dynamic libraries and dlopen. Dbus works just fine on OSX. There's nothing wrong with the well known place approach for system services; Apple's own services use it extensively. There's no real need for dbus, of course; OSX has its own, better, notification, configuration management, and resource location facilities. I hope to find time this summer to write gdbus and gsettings backends that use them. That said, Damjan's basic point that application directories work very well in OSX is absolutely correct. Regards, John Ralls [1]Services Implementation Guide [2]Information Property List Key Reference [3]Plug-ins ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
On Apr 15, 2011, at 6:01 AM, Alexander Larsson wrote: On Fri, 2011-04-15 at 14:18 +0200, Damjan Jovanovic wrote: Of course, some files are inherently made to be external, read by other applications. Such files are hard to relocate, like application icons, desktop files, icon themes, widget themes, plugins, custom mimetype descriptions, dbus service files. I don't really know what to do with these. A library can discover its current path by calling dladdr() on *nix and MacOS X, and GetModulePath() on Windows. The library then loads resources relative to that path. Yes, thats is doable on many OSes, but its still kinda ugly, as it implies that the relative paths to the files are kept, and thus implies that things are stored in typical unix style hierarchies, etc. It is much cleaner to just have a single file. It doesn't solve the inherently hard things listed above though, because the problem for them is that *other* things than the library itself loads these files. ISTM that it's cleaner and more broadly applicable to use something like binreloc (sadly no longer being developed, but widely copied and used in unix applications), where the paths to various resources can be configured at runtime in whatever way is appropriate for the system. We do this with Gnucash and it works well, though some of our dependencies don't and we have to resort to hacks to work around their limitations. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
On Apr 15, 2011, at 10:45 AM, Alexander Larsson wrote: On Fri, 2011-04-15 at 08:49 -0700, Kevin Fox wrote: On Fri, 2011-04-15 at 06:01 -0700, Alexander Larsson wrote: On Fri, 2011-04-15 at 14:18 +0200, Damjan Jovanovic wrote: Of course, some files are inherently made to be external, read by other applications. Such files are hard to relocate, like application icons, desktop files, icon themes, widget themes, plugins, custom mimetype descriptions, dbus service files. I don't really know what to do with these. A library can discover its current path by calling dladdr() on *nix and MacOS X, and GetModulePath() on Windows. The library then loads resources relative to that path. Yes, thats is doable on many OSes, but its still kinda ugly, as it implies that the relative paths to the files are kept, and thus implies that things are stored in typical unix style hierarchies, etc. It is much cleaner to just have a single file. It doesn't solve the inherently hard things listed above though, because the problem for them is that *other* things than the library itself loads these files. Usually the tool used to solve this problem though is a file system. An appdir like structure is a good compromise between other things needing to easily access the data and having all the stuff in one location that can be easily copied and moved around. Another option might be to simply tar (but not [bg]zip) up the library and related files and change the dynamic linker to mmap the correct subsection of the file instead of the whole thing. An appdir doesn't solve the issue here. Its not that its hard to load the file from the relocated file that makes it problematic. Its the fact that the other app doesn't even know about the existance of the file. For instance, let us take a desktop file as an example. Applications typically install their desktop files in /usr/share/applications. That way other applications like the panel, the open with dialog, etc will find it, because they all look in that directory. There are some env vars you can set globally to manually make other apps look in a some specific other directory, but this is quite limited and doesn't work for random relocation of apps. The same thing happens for the other types of files i mentioned above. dbus looks only for service files in /usr/share/dbus-1/services, gtk looks for themes in /usr/lib64/gtk-3.0/3.0.0/theming-engines, etc, etc. So, anything that has a file of this type is hard to relocate. Also, apps that consume such files are also hard to relocate. Take nautilus for instance, it looks for extensions in /usr/lib64/nautilus/extensions-3.0/, but if you relocate it, how does extensions know where to install extensions? At some point some system-level facility has to provide a way of registering such locations. M$Win and MacOSX provide both well known places and a facility for programs to let the system and other apps know where things are if the user put something somewhere else. Linux does too, it just that it's a bit clumsy: Environment variables. The problem for Glib isn't creating such a thing for Gnome (assuming Gnome doesn't already have one), but providing a uniform interface that all GLib-based applications and libraries can use to find their resources regardless of which platform they're running on. Gtk simply needs to use that interface. At the app level, it's up to app developers to use the interface (and to select dependencies that do, too) if they want good portability. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Make a UML model from GObject-Introspection Gir files
I don't know if anyone else will find this useful, but I've written a perl program to translate gir files into xmi files which can be imported into ArgoUML or KDE Umbrello. It follows include elements, putting each Gir namespace into a separate package in the UML model. You can find it at https://github.com/jralls/gir2xmi. You'll also find there a RelaxNG compact schema for the gir format of a couple of weeks ago, tested by validating most of the contents of share/gir-1.0. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Newbie question about gtk
On Feb 27, 2011, at 3:44 PM, tam2000k2 wrote: I am trying to go through some steps to get gtk-osx on my G4 PPC and when I run the script gtk-osx-build-setup.sh I receive the following error -- gtk-osx-build-setup.sh: line 65: /usr/local/bin/git: Bad CPU type in executable Failed to clone jhbuild I then searched on the internet for a universal binary of git and it installed without errors. What can I do to remedy this situation? This list isn't for support, and it isn't for gtk-osx. Try https://lists.sourceforge.net/lists/listinfo/gtk-osx-users But before you do, consider that gtk-osx-build-setup.sh doesn't install git, so it would seem that your situation is of your own making and is in any case resolved. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-2.24.0 tarball doesn't build on quartz
On Jan 30, 2011, at 8:47 PM, Matthias Clasen wrote: On Sun, Jan 30, 2011 at 11:25 PM, John Ralls jra...@ceridwen.us wrote: Undefined symbols: _gtk_combo_box_text_new, referenced from: _create_combo_box in sizegroup.o _attach_widgets in textview.o _gtk_combo_box_text_new_with_entry, referenced from: _do_combobox in combobox.o _gtk_combo_box_text_append_text, referenced from: _do_combobox in combobox.o _do_combobox in combobox.o _do_combobox in combobox.o _do_combobox in combobox.o _create_combo_box in sizegroup.o _attach_widgets in textview.o _attach_widgets in textview.o _attach_widgets in textview.o Something went wrong during autogen so that gtk/gtkcomboboxtext.lo isn't included with its gtkcombobox friends in am__objects_17. Building quartz from git works fine, and has done for several weeks. Not sure what to say... it built fine here. Since autogen.sh isn't included in the tarball this isn't easily repairable by users. autogen is just aclocal libtoolize gtkdocize autoheader automake autoconf ./configure with suitable arguments. In practice, autoreconf is probably enough to fix the problem, if it is fixable this way. Ah, good thought. `Autoreconf -fis` does indeed fix it. Thanks. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Gtk-2.24.0 tarball doesn't build on quartz
Undefined symbols: _gtk_combo_box_text_new, referenced from: _create_combo_box in sizegroup.o _attach_widgets in textview.o _gtk_combo_box_text_new_with_entry, referenced from: _do_combobox in combobox.o _gtk_combo_box_text_append_text, referenced from: _do_combobox in combobox.o _do_combobox in combobox.o _do_combobox in combobox.o _do_combobox in combobox.o _create_combo_box in sizegroup.o _attach_widgets in textview.o _attach_widgets in textview.o _attach_widgets in textview.o Something went wrong during autogen so that gtk/gtkcomboboxtext.lo isn't included with its gtkcombobox friends in am__objects_17. Building quartz from git works fine, and has done for several weeks. Since autogen.sh isn't included in the tarball this isn't easily repairable by users. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gobject-Introspection and CMPH
On Dec 16, 2010, at 9:47 AM, Colin Walters wrote: On Wed, Dec 15, 2010 at 8:43 PM, John Ralls jra...@ceridwen.us wrote: Okay well, I *think* you answered my question, which is that you want the stack to build with c99. No, but Emmanuele did: It should be c89. Gobject-introsopection has been failing that for some time, but before you added cmph, it built with c99. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gobject-Introspection and CMPH
On Dec 15, 2010, at 9:21 AM, Colin Walters wrote: On Mon, Dec 13, 2010 at 1:35 PM, John Ralls jra...@ceridwen.us wrote: One of the files in the new (to introspection) cmph directory, chd_ph.c, includes an anonymous union which requires -std=gnu99 to compile. Is that OK? This would have been better as a bug. However, if what you're *really* asking here is: * What's the gtk+/GNOME policy on compilers that we should build with? That would be a good subject for a list discussion =) What's the actual problem you ran into that caused you to make this post (hypothetical example: You are trying to build the stack with LLVM, and it doesn't support anonymous unions (it may actually, i'm just making this up)). Now, if we're trying to say that GTK+/GNOME only requires C89, strictly speaking, we have work to do: $ metabuild CFLAGS='-Wall -std=c89' metabuild: logging to '/tmp/build-gtk3.log' metabuild: Detected Makefile, using it metabuild: Running: ['chrt', '--idle', '0', 'nice', 'ionice', '-c', '3', '-t', 'make', 'CFLAGS=-Wall -std=c89', '-j', '24'] make all-recursive make[1]: Entering directory `/src/checkout/gtk3' ... make[2]: Entering directory `/src/checkout/gtk3/gdk' make[3]: Entering directory `/src/checkout/gtk3/gdk' make[4]: Entering directory `/src/checkout/gtk3/gdk/win32' make[4]: `.gitignore' is up to date. make[4]: Leaving directory `/src/checkout/gtk3/gdk/win32' make[4]: Entering directory `/src/checkout/gtk3/gdk/quartz' make[4]: `.gitignore' is up to date. make[4]: Leaving directory `/src/checkout/gtk3/gdk/quartz' make[3]: Leaving directory `/src/checkout/gtk3/gdk' make all-recursive make[3]: Entering directory `/src/checkout/gtk3/gdk' Making all in x11 make[4]: Entering directory `/src/checkout/gtk3/gdk/x11' CC gdkapplaunchcontext-x11.lo CC gdkasync.lo CC gdkcursor-x11.lo CC gdkdevice-core.lo CC gdkdevicemanager-core.lo CC gdkdevicemanager-x11.lo CC gdkdisplay-x11.lo CC gdkdnd-x11.lo CC gdkeventsource.lo CC gdkgeometry-x11.lo CC gdkeventtranslator.lo CC gdkglobals-x11.lo CC gdkim-x11.lo CC gdkinput.lo CC gdkkeys-x11.lo CC gdkmain-x11.lo CC gdkproperty-x11.lo CC gdkscreen-x11.lo CC gdkselection-x11.lo CC gdkspawn-x11.lo CC gdktestutils-x11.lo CC gdkvisual-x11.lo CC gdkwindow-x11.lo CC gdkxftdefaults.lo CC gdkxid.lo CC checksettings.o checksettings.c: In function ‘main’: checksettings.c:43:7: error: expected expression before ‘/’ token make[4]: *** [checksettings.o] Error 1 make[4]: *** Waiting for unfinished jobs make[4]: Leaving directory `/src/checkout/gtk3/gdk/x11' Now, obviously C++ comments in C files are pretty easy for other compilers to implement. But it's hard to know what other GNU C extensions the GTK+ stack uses with without fixing those. Are there any nested functions for example in GTK+? I'd be surprised, but you never know... The CMPH situation for g-i is special in a few ways because it's an import of sort-of-maintained code, and I really don't want to be in the business of diverging too far. I should probably invest in axing out a lot of the code that isn't used, but it's nontrivial. Bottom line here - if there's a use case you think should be supported, *explain what it is*, and let's discuss getting a buildbot set up. I wanted to know whether I should file a bug on cmph not compiling when I feed it -std=c99 (almost everything else, including gtk+, builds happily with c89, so no, it doesn't have nested functions) or just change the gtk-osx jhbuild module to use gnu99. I guess you answered the question, so I'll write a patch and file a bug... but probably not till early next week, as we're releasing Gnucash 2.4.0 this weekend and I've some work to do there first. But since you bring it up, what is the official policy? Is it C89? Is it published somewhere? Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gobject-Introspection and CMPH
On Dec 15, 2010, at 5:54 PM, Matthias Clasen wrote: On Wed, Dec 15, 2010 at 8:43 PM, John Ralls jra...@ceridwen.us wrote: But since you bring it up, what is the official policy? Is it C89? Is it published somewhere? For GTK+, we're generally avoiding C++ comments, since they cause problems for the compilers that are used on win32. What other non-C89 features do you have in mind ? Nested functions are not really worth discussing, thats just a historical accident on the part of the gcc team... Actually, I don't have anything in mind. Although I like C++ comments (and C++ in general) I have no issues writing C89 (or KR for that matter) code. I just want to know what constitutes breaking the build so that I do the right thing when it happens. (I don't know why Colin went off on C++ comments. My original post was about an anonymous union.) Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Gobject-Introspection and CMPH
One of the files in the new (to introspection) cmph directory, chd_ph.c, includes an anonymous union which requires -std=gnu99 to compile. Is that OK? Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Building multiple backends on on same system
On Dec 10, 2010, at 9:37 AM, Benjamin Otte wrote: While we're talking about getting rid of stuff, I'd like to get rid of gdk_utf8_to_string_target gdk_string_to_compound_text_for_display gdk_utf8_to_compound_text_for_display gdk_free_text_list gdk_free_compound_text But I lack enough clue about selections to do that. Is there anyone with enough clue that could find an API that can do this? The biggest problem I have with these APIs is that either they should be used (in which case we need to make sure people actually use them when they have to by introducing GdkCompoundText etc types) or they should not be used and the gdk selection code should take care of them. But the current situation is that even people who worked on the DND code have no idea what it's for. (I asked in #gtk+ and nobody had any clue.) GdkSelection is a wrapper around the X11 selection functions. It's not used by Gtk, which has its own higher-level selection object which ties into GtkClipboard and GtkDnd... which is why almost nobody knows about GdkSelection any more. I only know about it only because I implemented GtkSelection for quartz last summer. It probably should be dropped completely, but if that's too radical, by all means banish it to the X11 backend. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
