Re: Outdated win32 bundle
Hi, On 06/11/2015 05:19 PM, Ignacio Casal Quinteiro wrote: Here you have: https://bugzilla.gnome.org/show_bug.cgi?id=620566 Please consider my patches on that bug report as superseded by the work in this mingw-w64 branch: https://github.com/dieterv/gobject-introspection/tree/mingw-w64 That branch basically makes g-i work reasonably well with MSYS2 (even make check passes on windows, yay). I am blocked on the scanner: pass arguments through a file patch though, as it breaks make distcheck on my linux machine with what seems to be a simple VPATH build issue. Haven't found a solution in over a month's free time of hacking though :/ Any insights, pointers, appropriate doses of cluebat (please do avoid the head though) will be most appreciated ;) mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSourceFuncs not fully documented
On 2013-09-20 11:29, Zoltan Boszormenyi wrote: Hi, If you read https://developer.gnome.org/glib/2.36/glib-The-Main-Event-Loop.html#GSourceFuncs [1] you may notice the last statement about prepare() is prematurely terminated: Since 2.36 this may be NULL [2], in which case the effect is as if the function always Filed https://bugzilla.gnome.org/show_bug.cgi?id=708445 with a patch to fix above issue. mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Reg. modifying GTK+ to add menu option
On 2013-04-10 19:52, Sindhu S wrote:
I want to add this to GTK+ because it will automatically benefit
every GNOME Application, and have consistency for the user.
Hi Sindhu,
Just some thoughts:
* It might be possible to do this as a GNOME Shell extension, where I
can imagine pressing some keyboard combination or whatever to activate
the query. Then, by using the accessibility framework a look-up
would not be limited to applications using GTK+ but you'd get support
for LibreOffice, Firefox, QT and anything else talking AT-SPI basically
for free.
As an example, attached is a standalone (very incomplete and not very
well tested) Python script using Atspi, Wnck and Gdk via
gobject-introspection
(originally based on code from Accerciser) that retrieves the word
under the mouse pointer (if any) using AT-SPI.
To test the script:
- open a terminal,
- type get_text_under_pointer.py
- put the mouse pointer somewhere, for example point at a word in a
GEdit or LibreOffice Writer document or web page in Firefox or
Epiphany etc
- your terminal still having focus, hit enter
* Maybe a translate option in addition to look up in dictionary
might be useful for some people too?
mvg,
Dieter
#!/usr/bin/python3
import os
from gi.repository import Atspi, Gdk, Wnck
my_pid = str(os.getpid())
def is_my_app(acc):
'''
Based on isMyApp() from https://git.gnome.org/browse/accerciser/tree/src/lib/accerciser/tools.py
'''
if not acc:
return False
else:
pid = str(acc.get_application().get_process_id())
if pid == my_pid:
return True
else:
return False
def inspect_under_pointer():
'''
Based on _inspectUnderMouse() from https://git.gnome.org/browse/accerciser/tree/plugins/quick_select.py
'''
gdk_display = Gdk.Display.open(Gdk.get_display())
screen, x, y, flags = gdk_display.get_pointer()
wnck_screen = Wnck.Screen.get_default()
wnck_screen.force_update()
wnck_workspace = wnck_screen.get_active_workspace()
window_order = [w.get_name() for w in wnck_screen.get_windows_stacked()]
top_window = (None, -1)
desktop_acc = Atspi.get_desktop(0)
desktop_acc_child_count = desktop_acc.get_child_count()
for desktop_acc_child in range(0, desktop_acc_child_count):
app_acc = desktop_acc.get_child_at_index(desktop_acc_child)
if not app_acc or is_my_app(app_acc):
continue
else:
app_acc_child_count = app_acc.get_child_count()
for app_acc_child in range(0, app_acc_child_count):
frame_acc = app_acc.get_child_at_index(app_acc_child)
if not frame_acc:
continue
else:
child_acc = get_component_at_coords(frame_acc, x, y)
if child_acc:
try:
z_order = window_order.index(frame_acc.get_name())
except ValueError:
pass
else:
if z_order top_window[1]:
top_window = (child_acc, z_order)
if top_window[0]:
return top_window[0], x, y
def get_component_at_coords(parent, x, y):
'''
Based on _getComponentAtCoords() from https://git.gnome.org/browse/accerciser/tree/plugins/quick_select.py
'''
container = parent
inner_container = None
while True:
container_role = container.get_role()
if container_role == Atspi.Role.PAGE_TAB_LIST:
try:
si = container.get_selection()
container = si.get_selected_child(0)
except NotImplementedError:
pass
try:
ci = container.get_component()
except:
break
else:
inner_container = container
acc_at_point = ci.get_accessible_at_point(x, y, Atspi.CoordType.SCREEN)
if acc_at_point is not None:
container = acc_at_point
else:
break
if not container or container.get_component() == ci:
# The gecko bridge simply has getAccessibleAtPoint return itself
# if there are no further children
break
if inner_container == parent:
return None
else:
return inner_container
def get_text_under_pointer():
acc, x, y = inspect_under_pointer()
if acc:
text = acc.get_text()
if text:
offset = text.get_offset_at_point(x, y, Atspi.CoordType.SCREEN)
text_range = text.get_text_at_offset(offset, Atspi.TextBoundaryType.WORD_START)
text_value = Atspi.Text.get_text(text, text_range.start_offset, text_range.end_offset)
return text_value
return None
if __name__ == '__main__':
text = get_text_under_pointer()
if text:
print(text.strip())
else:
print('No text found :(')
Re: GTK+3 win32/64 build environment
On 2013-04-10 10:41, Marc-André Lureau wrote:
I believe some work is needed to be able to reuse cross-compiled
projects under Windows. For example, the .pc file path will need to be
adjusted etc.
I you mean the paths stated inside .pc files, then pkg-config on
windows should be able to automatically deduce the correct value for
${prefix} based on the location where said package is installed [1]
and ignore whatever is stated as ${prefix} inside the .pc file.
No adjustments should be needed.
This was made so by tml way back, when he used to ./configure
and make install each package into a separate prefix, stringing
things together (both for build and runtime usage) as needed
using PATH, PKG_CONFIG_PATH, ACLOCAL_FLAGS and other env vars.
Quite elegant, one can test (build and/or use) different versions
of packages fast, without having to go and build a complete
bundled distribution for each test (unless there's ABI breaks off
course).
Afaik, no other (meta) build system I've seen up until now is capable
of doing that. Didn't know about Cerbero though, added that to my
already long list of things to look into.
I you mean something else, then please ignore me :)
mvg,
Dieter
[1]
http://cgit.freedesktop.org/pkg-config/tree/parse.c?id=7328e6fc9ec4191105cd4433320ea585d8f95d97#n970
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On 2013-04-10 15:03, Marc-André Lureau wrote:
Interesting, I didn't know (and I wouldn't try, I am cross-compiling
guy :) However, this isn't going to be enough, there are many
variables in .pc which may contain path.
Yeah, projects not re-using the prefix variable when defining other
paths in their .pc files probably need to be fixed. For example
a .pc.in file having:
prefix=@prefix@
exec_prefix=@exec_prefix@
libdir=@libdir@
includedir=@includedir@
which after evaluation by autoconf's config.status produces
the following .pc file:
prefix=/c/some_project/prefix
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
is OK.
Also projects not using
pkg-config have the same problems.
Those should obviously be fixed to use pkg-config, right? ;)
Doing a grep under fedora-mingw
sys-root reveals that there are many binaries that refer to hardcoded
path too.
Also needs to be fixed imho... One issue like this I never got to
resolve was hardcoded paths in perl scripts (for GTK-Doc iirc). Python
makes this easy by providing the __file__ builtin, but how to do
something like that in perl has been evading me...
Oh well, nobody said supporting relocatable installs for software
usually only expecting to be installed in / was going to be
easy :P
In general, it's not going to work if I try to reuse those
cross-builds for doing native build. Fortunately, by now, most of the
runtime is working natively, but there are still corner-cases (this is
still one of the first thing you need to fix when porting a lib/app)
Yeah, it seems there will always be corner-cases, unfortunately...
mvg,
Dieter
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On 2013-04-10 20:19, Marc-André Lureau wrote:
You said, should first try checking for an environment variable and
then a path relative to the executable., what environment variable?
PKGDATADIR? Who set it? Is it only for the developper? If you have a
good case for that extra environment variable, I would suggest to
submit a patch to g_get_system_data_dirs(), It does the later, giving
you a list of where to look for the data. So it could easily be
tweaked to look for more locations.
g_get_system_data_dirs() on win32 should simply honor XDG_DATA_DIRS
like it does on any other platform/OS and fall back to
FOLDERID_ProgramData
or CSIDL_COMMON_APPDATA (depending on windows version).
Something like what I tried to do a year ago [1], before I got
a) much less time to hack on things and b) distracted with g-i
stuff which I'm now desperately trying to finish before working
on anything else.
From what I remember: I stopped working on the branch when embarking
on an attempt to write a KnownFolders.h implementation for MinGW's
win32api package and mingw-w64 equivalent (attached), eventually
to be #included in glib/gutils.c [2]. The being stuck part was properly
testing for the header in configure.ac with AC_CHECK_HEADER, which
I've not yet figured out how to do (include test passes, compile
test fails, so apparently the header alone is not enough and there's
something else missing wrt the INITGUID stuff)...
If anybody feels like making the KnownFolders.h stuff work (and
getting it in mingw mingw-w64) and un-bit-rotting that branch (and
getting it in glib proper), please feel free to do so. Don't think I'll
be able to go back working on that for at least another couple of
months...
mvg,
Dieter
[1]
https://github.com/dieterv/glib/commit/57c184e66bab81470ae3768330088ef113e3d750
[2]
https://github.com/dieterv/glib/commit/0462418592ee1df93f251772d9bdcd3f6ca13f68
/*
* KnownFolders.h
*
* KNOWNFOLDERID constants
*
* This file is part of the w32api package.
*
* Contributors:
* Created by Dieter Verfaillie diet...@optionexplicit.be
*
* Provenance:
* - File structure and include guards based on /mingw/include/ddk/ndisguid.h
* - EXTERN_C preprocessor macro copied from /mingw/include/basetyps.h
* - DEFINE_FOLDERID_GUID preprocessor macro based on DEFINE_GUID
* from /mingw/include/basetyps.h
* - FOLDERID_* names and values as documented on:
* http://msdn.microsoft.com/en-us/library/windows/desktop/dd378457.aspx
* Note that this page lacks information on FOLDERID_Documents, but:
* - FODERID_Documents name and value and other FOLDERID_* names and values
* verified against the remarks section of:
*
http://msdn.microsoft.com/en-us/library/windows/desktop/dd940483(v=vs.85).aspx
*
* THIS SOFTWARE IS NOT COPYRIGHTED
*
* This source code is offered for use in the public domain. You may
* use, modify or distribute it freely.
*
* This code is distributed in the hope that it will be useful but
* WITHOUT ANY WARRANTY. ALL WARRANTIES, EXPRESS OR IMPLIED ARE HEREBY
* DISCLAIMED. This includes but is not limited to warranties of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*
*/
#ifndef __KNOWN_FOLDERS_H
#define __KNOWN_FOLDERS_H
#if __GNUC__ =3
#pragma GCC system_header
#endif
#ifndef _OBJC_NO_COM_
# ifdef __cplusplus
# define EXTERN_C extern C
# else
# define EXTERN_C extern
# endif
#endif
#ifdef INITGUID
# define DEFINE_FOLDERID_GUID(n,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) \
EXTERN_C const GUID n = {l,w1,w2,{b1,b2,b3,b4,b5,b6,b7,b8}}
#else
# define DEFINE_FOLDERID_GUID(n,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) \
EXTERN_C const GUID n
#endif
#ifdef __cplusplus
extern C {
#endif
DEFINE_FOLDERID_GUID(FOLDERID_AddNewPrograms,
0xde61d971, 0x5ebc, 0x4f02, 0xa3, 0xa9, 0x6c, 0x82, 0x89, 0x5e, 0x5c, 0x04);
DEFINE_FOLDERID_GUID(FOLDERID_AdminTools,
0x724ef170, 0xa42d, 0x4fef, 0x9f, 0x26, 0xb6, 0x0e, 0x84, 0x6f, 0xba, 0x4f);
DEFINE_FOLDERID_GUID(FOLDERID_AppUpdates,
0xa305ce99, 0xf527, 0x492b, 0x8b, 0x1a, 0x7e, 0x76, 0xfa, 0x98, 0xd6, 0xe4);
DEFINE_FOLDERID_GUID(FOLDERID_CDBurning,
0x9e52ab10, 0xf80d, 0x49df, 0xac, 0xb8, 0x43, 0x30, 0xf5, 0x68, 0x78, 0x55);
DEFINE_FOLDERID_GUID(FOLDERID_ChangeRemovePrograms,
0xdf7266ac, 0x9274, 0x4867, 0x8d, 0x55, 0x3b, 0xd6, 0x61, 0xde, 0x87, 0x2d);
DEFINE_FOLDERID_GUID(FOLDERID_CommonAdminTools,
0xd0384e7d, 0xbac3, 0x4797, 0x8f, 0x14, 0xcb, 0xa2, 0x29, 0xb3, 0x92, 0xb5);
DEFINE_FOLDERID_GUID(FOLDERID_CommonOEMLinks,
0xc1bae2d0, 0x10df, 0x4334, 0xbe, 0xdd, 0x7a, 0xa2, 0x0b, 0x22, 0x7a, 0x9d);
DEFINE_FOLDERID_GUID(FOLDERID_CommonPrograms,
0x0139d44e, 0x6afe, 0x49f2, 0x86, 0x90, 0x3d, 0xaf, 0xca, 0xe6, 0xff, 0xb8);
DEFINE_FOLDERID_GUID(FOLDERID_CommonStartMenu,
0xa4115719, 0xd62e, 0x491d, 0xaa, 0x7c, 0xe7, 0x4b, 0x8b, 0xe3, 0xb0, 0x67);
DEFINE_FOLDERID_GUID(FOLDERID_CommonStartup,
0x82a5ea35, 0xd9cd, 0x47c5, 0x96, 0x29, 0xe1, 0x5d, 0x2f, 0x71, 0x4e, 0x6e);
DEFINE_FOLDERID_GUID
Re: GTK+3 win32/64 build environment
On 2013-04-10 21:04, Dieter Verfaillie wrote: g_get_system_data_dirs() on win32 should simply honor XDG_DATA_DIRS like it does on any other platform/OS and fall back to FOLDERID_ProgramData or CSIDL_COMMON_APPDATA (depending on windows version). Hit send a bit too soon, that should be: honor XDG_DATA_DIRS if set else $glib_runtime_prefix/share + $exe_runtime_prefix + FOLDERID_ProgramData or CSIDL_COMMON_APPDATA (depending on windows version) mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Regarding resurrecting distutils support in PyGObject
On 2012-12-24 12:09, Fan Chun-wei wrote:
I am currently looking at trying to resurrect the distutils support
for building PyGObject
Ah, yes, removed in
http://git.gnome.org/browse/pygobject/commit/?id=8d3125c8ce9890c70400dd8a3ac273b590fe6a31
I'll point to the state of those files in the pygobject-2-28 branch as
iirc those had a few fixes that where never needed in pygobject 3.
Note that at the time I removed those files, mvsc support had already
been
bit-rotting for years and the distutils machinery was only used to
create win32 binaries with MinGW GCC afaik.
As I am not that familiar with the distutils mechanism, I thought it
might be helpful to me if I can find out:
-Any things I need to look out for when I try port the distutils
items from 2.28.6 to the current/master branch, perhaps in particular
the codegen items?
dsextras.py
===
http://git.gnome.org/browse/pygobject/tree/dsextras.py?h=pygobject-2-28#n20
Codegen is no longer used. This block of imports and anything
using it can be removed.
http://git.gnome.org/browse/pygobject/tree/dsextras.py?h=pygobject-2-28#n80
Building with MinGW GCC now (hopefully still) works with
./autogen.sh ./configure make install so this and
anything using it can be removed.
http://git.gnome.org/browse/pygobject/tree/dsextras.py?h=pygobject-2-28#n153
init_extra_compile_args() and init_extra_compile_args() methods can
be removed as we just removed have_gcc() above. build_extensions()
still needs
to call build_ext.build_extensions(self), remove the first two lines
of the build_extension() method but keep the rest.
http://git.gnome.org/browse/pygobject/tree/dsextras.py?h=pygobject-2-28#n288
3.0
http://git.gnome.org/browse/pygobject/tree/dsextras.py?h=pygobject-2-28#n394
http://git.gnome.org/browse/pygobject/tree/dsextras.py?h=pygobject-2-28#n472
If all goes well both these classes can be removed, we're not
building
anything from .defs files anymore (as there is no more codegen). The
interesting bits we're left with is the PkgConfigExtension class.
setup.py
http://git.gnome.org/browse/pygobject/tree/setup.py?h=pygobject-2-28#n34
Keep this but maybe change the message so it is clear that it's for
MSVC only.
Historically the autotools where the only 'supported' way of building
pygobject/pygtk/...
and we don't want to start giving people the wrong impression just
because there
is a setup.py file present ;)
http://git.gnome.org/browse/pygobject/tree/setup.py?h=pygobject-2-28#n41
Maybe this can be done via get_m4_define('python_min_ver'), or
'python3_min_ver depeding
on your interpreter version?
http://git.gnome.org/browse/pygobject/tree/setup.py?h=pygobject-2-28#n63
http://git.gnome.org/browse/pygobject/tree/setup.py?h=pygobject-2-28#n70
These will need to be adjusted ...
http://git.gnome.org/browse/pygobject/tree/setup.py?h=pygobject-2-28#n71
http://git.gnome.org/browse/pygobject/tree/setup.py?h=pygobject-2-28#n72
http://git.gnome.org/browse/pygobject/tree/setup.py?h=pygobject-2-28#n73
... and these removed, unless somebody has revived the GTK-Doc
reference,
but I don't think that's the case :(
Everything beyond will most likely need to be heavily
modified/rewritten as the
structure of the Python C extension modules has been significantly
changed.
-Any other things that might be pointers or items of interest in the
process?
As usual, ensure pkg-config.exe is on PATH and the required .pc files
on PKG_CONFIG_PATH
before running setup.py.
With blessings, thank you!
Good luck and a Merry Christmas !
mvg,
Dieter
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Python3 + gtk3 on windows
On Thu, 16 Aug 2012 17:12:23 +1000, Jared Henley wrote: I've finally turned up some useful information in the archive for this list. I've downloaded the gtk+ and pygobject binaries from http://optionexplicit.be/projects/gnome-windows/GTK+3/ and also installed python 3.2 using the msi installer on the Python site. But I don't know where to copy the gtk+ and pygobject files to the right places to make it all work. Can someone tell me what to do? 1) those pygobject binaries (and the bundle in gtk+/git/) are linked against 32 bit Python 2.7, so you'd need to install that first 2) make sure Python27/Lib/site-packages/pygtk.pth is renamed to something else as the Gtk3 bundle does not agree with the PyGTK aio installer's way of ensuring PATH is set to something sane) 3) get the bundle from http://optionexplicit.be/projects/gnome-windows/GTK+3/gtk+/git and extract it to C:\Gtk3 4) create a C:\Gtk3\bin\pygi.cmd file containing the following: 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 @echo off set PATH=C:\Gtk3\bin;C:\Python27\;%PATH% set PYTHONPATH=C:\Gtk3\lib\site-packages set GI_TYPELIB_PATH=C:\Gtk3\lib\girepository-1.0 C:\Python27\python.exe %* 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 Adjust paths to match your installation directories but note you should avoid spaces in paths completely for both the location of the bundle and the installation location of Python. If you want to test pygobject's demos/gtk-demo/gtk-demo.py, you'll need to patch is like this: 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 from gi.repository import GLib, GObject, Gio, Pango, GdkPixbuf, Gtk #ugly win32 hack GLib.file_test = GLib.file_test_utf8 GLib.file_get_contents = GLib.file_get_contents_utf8 GdkPixbuf.Pixbuf.new_from_file = GdkPixbuf.Pixbuf.new_from_file_utf8 #end ugly hack DEMOROOTDIR = os.path.abspath(os.path.dirname(__file__)) 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 Note that these binaries: - are not intended to be used in production systems - are built with debug symbols (mingw.org's gdb works well) - are built from the experimental windows branches of various forks on my github page, which are in various stages of not yet ready or good enough for upstream - do not come with any warranty whatsoever, etc mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fully winding down my involvement in GTK+
On 22/07/2012 16:02, Michael Torrie wrote: On 07/22/2012 04:20 AM, John Emmas wrote: That's been my experience anyway. With no facts stated to support your response, it is merely your opinion. My opinion is also just an opinion, however I believe the points in support of my opinion are factual and logical (which you haven't refuted). Calling for a forum because it makes you feel warm and fuzzy is nice but it doesn't prove anything. I'm not opposed to a forum provided that it a) has a full threaded structure like e-mail has, and b) has a good gateway for e-mail or nntp. In general I mean. How about a forum-ish web interface on top of the mailing lists we already have? Would give us the best of both worlds (more manageable for the slightly more technical user and more approachable for everyone else). mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: EXTERNAL: Re: win32 installer?
On Wed, 18 Jul 2012 08:46:59 +0200, Thomas H.P. Andersen wrote:
I see ffi.h and ffitarget.h in lib\libffi-3.0.10\include\ but e.g.
glib expects those in include\ instead.
lib/pkgconfig/libffi.pc claims
includedir=${libdir}/libffi-3.0.11/include
and afaik when building glib pkgconfig is used to find libffi.
Also lib\ has libffi.dll.a instead of the needed libffi.lib
Would you happen to be using msvc? If yes, then sorry but I'm not
generating msvc compatible import libraries for the experimental
bundle (as is done for the stable gtk 2.24 bundle on ftp.gnome.org).
Honestly I'm not even sure why we should even continue bothering
with those now that there's
https://live.gnome.org/GTK%2B/Win32/MSVCCompilationOfGTKStack ?
mvg,
Dieter
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: EXTERNAL: Re: win32 installer?
On Tue, 17 Jul 2012 12:30:11 +0200, John Stowers wrote: There's a couple of patches you need that are not yet upstreamed (due to their ugly hack/wip status) in this branch: https://github.com/dieterv/gobject-introspection/commits/windows But then I saw https://mail.gnome.org/archives/windows-devel-list/2012-July/msg0.html Which confused me, are these on top of your branch? Yep, they are. Had a quick look: - the first patch I can understand, but still need to test, have been running make without -jx up until now - the second patch I'd probably ask for more info, it's working fine with MinGW/MSYS from mingw.org and the gettext packages from ftp.gnome.org over here, maybe required with mingw-w64 or TDM or some other win32 gcc distro - the third patch looks a bit hackish and thus would be hell to get accepted ;) mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: EXTERNAL: Re: win32 installer?
On Tue, 17 Jul 2012 13:14:08 +0200, Murray Cumming wrote: Yes, I just want the built libraries and bits, ideally put in the right place automatically. I don't have the time or enthusiasm to build everything on Windows myself. I can just about bear to build my application on Windows if GTK+ is available. I basically just need what we had for GTK+ 2 on Windows. Yup, that's the bundle (a first step towards a proper sdk), which I'm uploading to http://optionexplicit.be/projects/gnome-windows/GTK+3/ from time to time... For now at least, once stable it'll go to ftp.gnome.org :) mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: EXTERNAL: Re: win32 installer?
On 17/07/2012 16:43, Thomas H.P. Andersen wrote: On Tue, Jul 17, 2012 at 1:58 PM, Dieter Verfaillie diet...@optionexplicit.be wrote: Yup, that's the bundle (a first step towards a proper sdk), which I'm uploading to http://optionexplicit.be/projects/gnome-windows/GTK+3/ from time to time... For now at least, once stable it'll go to ftp.gnome.org :) Would it be possible to have libffi added to the bundle as well? Oops! IIRC, that was fixed the day after releasing that version and it seems I forgot to upload it. Which is now done. Fresh builds will be done once I'm happy with my patchset intended to fix g-i's annotationparser (which is somewhat unrelated to win32). So, real soon now (tm)... Thanks, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: EXTERNAL: Re: win32 installer?
On 17/07/2012 13:14, Damon Register wrote:
On 7/16/2012 3:25 PM, Dieter Verfaillie wrote:
https://github.com/dieterv/gobject-introspection/commits/windows
Thanks. I downloaded last night. I hope you don't mind me asking
but I guess I don't totally understand what I read at the site.
Is this a complete snapshot of the gobject-introspection project
with your changes
Yes, it's a branch (in git) in a forked repository (the original
repository lives on git.gnome.org). You can get at it from a
windows machine using http://code.google.com/p/msysgit/
or does this only represent the files that are
changed.
I'm sure it's possible to extract those with some arcane git
incantation...
I tried building this windows version from you and got a fail saying
that gtk-doc.mak was missing. I thought that perhaps the windows
bundle includes only files that are different so I copied all the
missing ones from the latest release (is this a correct assumtion?)
This can be worked around by either
http://www.go-evolution.org/Building_Evolution_on_Windows#Fake_gtk-doc
or maybe http://git.gnome.org/browse/gtk-doc-stub/
I've also attached the script I've been using to build g-i binaries.
Maybe it contains some tidbits of information that might help you...
autoreconf and configure seemed to work ok but make failed with this
output
e/glib-2.0/gobject/glib-types.h gir/glib-2.0.c g-ir-scanner g-ir-compiler.exe
--output GLib-2.0.gir
g-ir-scanner.args
GISCAN GLib-2.0.gir
make[2]: *** [GLib-2.0.gir] Error 5
and a Python crash
Sorry, not enough information in there to tell what went wrong...
Which is used to produce the experimental GTK+ bundle (including
g-i and pygobject for Python 2.7) on:
http://optionexplicit.be/projects/gnome-windows/GTK+3/
I will have to try this.
Installers are for end user product (GIMP, Gedit, Inkscape, etc)
but not for libraries and components used to build such end user
products. An installer for some sort of an SDK however would a
I understand your point but I have to admit that the gtkmm installer
that I have used in the past was very handy. I suppose all that is
really needed is to copy those libraries and components to a chosen
directory and maybe setup a few environment variables?
come to think of it, isn't that (SDK) what we normally think of
when talking installers?
I've seen requests for a shared GTK+ installation, which would be
insane, given the myriad of incompatible code generated by
different mingw gcc distributions out there. Let alone the horrors
of ApplicationX installing an updated GTK+, breaking ApplicationY...
That last one is also why we'll never have .msm windows installer
merge modules distributed on gtk.org/ftp.gnome.org btw...
So, it doesn't hurt being specific ;)
Even a folder of files with some instruction
for setting environment variables would be great.
There is no (and there should never be any) need to abuse
environment variables, unless you rely on PATH for some
binary to be able to find libgtk and friends, which would
be a bug with the way said binary is installed imho. Things
get harder with language bindings though (ie integrating with
python.org's win32 interpreter installations, which doesn't
follow the unix-ish folder hierarchy used by the GTK bundle,
meaning python.exe lives in /and libgtk and friends in /bin)
That leaves just a folder, which is exactly what the bundle is
and always has been (for example:
http://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.24/)
An SDK, in my mind, adds all the tools, sources, patches, scripts,
etc used to build that bundle (or to be correct, the packages making
up the bundle) and a way for application writers to integrate with
that system (so they don't have to reinvent the wheel). Versions of
tools would be set in stone for a given branch (let's say gcc 4.6 for
whatever packages are considered part of GNOME 3.4 and it's maintenance
releases, 4.7 for GNOME 3.6 etc). Not limited to gcc off course, but
*everything*. Application writer integrating with this system would
be able to generate their own bundle (think glade, gedit, whatever)
which can then be used to build real installers (using WiX,
NSIS, InnoSetup, whatever).
Doing all this is the only way we can guarantee end users (of the
SDK) in the distant future will be able to patch say a 3 year old
GTK+ branch when nobody is left around to maintain it, provided said
user can get at a sufficiently old windows version (let's not pretend
current mingw build envs will just work on future windows versions,
see what happened when vista got released for example)...
mvg,
Dieter
#!/bin/sh
PATH=.:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem
PYTHON_DIR=/c/bin/Python27
CHECKOUT_DIR=/c/dev/gnome.org/gnome-windows/checkout
MOD=gobject-introspection
VER=1.33.0
REV=git
ARCH=win32
THIS=${MOD}-${VER}-${REV}-${ARCH}
ROOT_DIR=${CHECKOUT_DIR}/${MOD}/git
SRC_DIR=${ROOT_DIR}/src
BUILD_DIR=${ROOT_DIR}/build
DIST_DIR
Re: EXTERNAL: Re: win32 installer?
On 17/07/2012 14:23, John Stowers wrote: Yup, that's the bundle (a first step towards a proper sdk), which I'm uploading to http://optionexplicit.be/projects/gnome-windows/GTK+3/ from time to time... For now at least, once stable it'll go to ftp.gnome.org :) aside #1: Did you/anyone check out the jhbuild-like build system the gstreamer folks created to build the gstreamer SDK on windows/other? It looks quite nice (and obviously worked as recently as 1 month ago...) I just wrote a couple of notes in this mail (towards the end of the message): https://mail.gnome.org/archives/gtk-devel-list/2012-July/msg00027.html Which lists a couple of things jhbuild is not (yet?) capable of doing. Above all, I don't like it not building out of tree though :P aside #2: Getting a windows built SDK working is on my TODO for GUADEC (at least a python + gobject-introspection one at the pygobject hackfest). pygobject should be good to go (unless regressions snuck in while I wasn't looking). g-i has my branch which depends on the XDG_DATA_DIRS fix from https://github.com/dieterv/glib/commits/windows There's a couple of questions left to solve there too... Then we have to devise a way to get rid of all those _utf8 backward compatibility defines. Otherwise, on all platforms you'd be able to use in python gdk_pixbuf_new_from_file() except on 32 bit windows where it would be gdk_pixbuf_new_from_file_utf8()... For example see: http://git.gnome.org/browse/gdk-pixbuf/tree/gdk-pixbuf/gdk-pixbuf-io.c#n1160 (over here, cgit line numbers do not correspond with their respective source lines so search for #undef gdk_pixbuf_new_from_file). I've spent some time thinking on this and it seems to me we can safely remove all of them (in gtk, gdk-pixbuf, glib, etc) without risking breakage because these where introduced to ensure abi compatibility with some ancient glib (2.12 iirc) 32 bit win32 binaries. Now, some changes broke abi anyway somewhere between glib 2.24 (corresponds with gtk bundle 2.16) and glib 2.28 (corresponds with gtk bundle 2.24) so there's no longer any reason to keep these old g_locale_to_utf8 (filename, alternatives around. Does this sound sane? Would it even be acceptable? It sure would be the easiest way out. Note: somebody should at least independently check these facts before anybody goes further down this road though, I might have misunderstood the intent of those alternatives, who knows ;) Anyone else interested in hacking on this with me? Yes! Unfortunately I won't be at GUADEC :( mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: building gobject-introspection with Mingw
On Mon, 16 Jul 2012 18:40:12 +0100, Lionel Landwerlin wrote: On Mon, 2012-07-16 at 13:29 -0400, Colin Walters wrote: There's outstanding work on gobject-introspection/win32 that will hopefully land in the near future, but for now, I'd recommend just copying the m4 file. Is this work going to enable gir/typelib files generation when doing cross compilation as well? No, it's limited to MinGW/MSYS atm. mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: EXTERNAL: Re: win32 installer?
On Mon, 16 Jul 2012 11:55:51 -0400, Damon Register wrote: On 7/13/2012 3:21 AM, Ignacio Casal Quinteiro wrote: There is some beta one that you can ask to dieter. That takes all the fun out of trying to build it from source :-) For the last few weeks I have been experimenting with trying to build using Mingw and have made some progress but an stuck on gobject-introspection. There's a couple of patches you need that are not yet upstreamed (due to their ugly hack/wip status) in this branch: https://github.com/dieterv/gobject-introspection/commits/windows Which is used to produce the experimental GTK+ bundle (including g-i and pygobject for Python 2.7) on: http://optionexplicit.be/projects/gnome-windows/GTK+3/ Having an installer would certainly make it much easier. Installers are for end user product (GIMP, Gedit, Inkscape, etc) but not for libraries and components used to build such end user products. An installer for some sort of an SDK however would a different matter... Maybe someday I (or somebody else) will even find the time to get that done ;) mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: How to recreate GLib binary bundle for Windows
On Wed, 04 Apr 2012 16:29:22 +0200, Matteo Pampolini wrote: I'm currently working on a GStreamer-based Windows application, until now the binary version of GLib that comes with the GTK+ binary bundle was OK for me, but then I had to recompile GLib itself. With some issues I was finally able to recompile GLib with both MinGW and MSVC 10, this because I'm using MinGW to recompile GStreamer but I also have an MSVC project that refers to GLib through GStreamer. Everything seems fine, but when I start my application I get an error on a libffi missing symbol. My suspect is that I probably made some confusion with the two sets binaries: which one should I use, the runtime DLLs generated by MinGW or the ones generated by MSVC? In simple words, which of them are distributed inside GTK+ binary bundle? The win32 gtk+-bundle and separate per package binaries on http://ftp.gnome.org/pub/gnome/binaries/win32/ are built with a MinGW/MSYS installation on a window xp machine. Those packages also include msvc compatible import libraries built with the lib.exe version included with the Windows Server 2003 R2 Platform SDK from http://www.microsoft.com/download/en/details.aspx?id=12675 The original maintainer used msvc 6 which is next to impossible to get these days and msvc 9 for some modules, but I lack a visual studio license, hence the SDK. I'm currently keeping track of the scripts used to build the packages and bundle plus an informative description of the setup provided by the original maintainer here: https://github.com/dieterv/legacynativebuilds/ Please don't hesitate to ask if something should be unclear, mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk-2-24-win32 branch merged into gtk-2-24
On Sun, 29 Jan 2012 21:48:51 +0100, Murray Cumming wrote: On Thu, 2012-01-19 at 12:53 +0100, Dieter Verfaillie wrote: I maintain http://www.optionexplicit.be/projects/gnome-windows/GTK+3/ which is built from ATK, Pango, GLib, GTK+, GObject-Introspection, etc master branches. For some modules with highly experimental patches that have not yet been accepted upstream even. [snip] Thanks, but are people generally working on getting the GTK+ 2 Windows improvements into GTK+ 3? I'd like a general sense of how it is going. Yes. Alex' work was done on both gtk-2.24 and master branches, but due to differences between the two lines of development happened at a different time IIUC. For the (smaller) bugfixes I've been doing, I make sure all of them written for the gtk-2-24 branch are ported -if still applicable- to master and vice versa *before* pushing the patches, just so we don't get bug reports on GTK+3 for something already solved in 2.24 :) mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+-2.24.8 became the current maintained version on win32 ??
On Thu, 19 Jan 2012 10:58:56 +0100, Alexander Larsson wrote: On Thu, 2012-01-19 at 11:47 +0800, jun louis wrote: I found this BUG: I directly run gtk-demo.exe on win7 x64, use locale=zh_CN, texts disappear when switch page. I use msys, use LC_ALL=C then run gtk-demo, texts works fine! $ export LC_ALL=C $ ./gtk-demo.exe I use msys, use LC_ALL=zh_CN then run gtk-demo, texts disappear~~~ $ export LC_ALL=C $ ./gtk-demo.exe This is just a guess, but perhaps this is font related? Maybe it doesn't find the chinese fonts? Maybe the attached pango.aliases can help. Copy it as etc/pango/pango.aliases and it will be picked up automatically when you next execute you app. There might be something missing for Chinese (don't have the means to test myself), but I think the list is fairly complete. mvg, Dieter pango.aliases Description: Binary data ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: experimental gtk+ 3.3.2 win32 build
On Thu, 27 Oct 2011 09:25:37 -0400, Ryan Lortie wrote: In general, we are interested in improving the situation with respect to Windows builds. We'd like to do this in a more robust way (ie: done with every version and posted on gtk.org). Ideally, this would be automated. It's worth noting that it's already relatively easy for us to do mingw builds and indeed we have a full set of them in the Fedora archive. What we really lack is a good method of doing regular builds using Visual Studio (which is necessary to get the correct debugging symbols into the libraries). MinGW/MSYS too, please :) Do you have any ideas how we could possibly automate this process? MinGW/MSYS: C:/path/to/msys/sh.exe -c /path/to/script args might be worth a try too (from a .bat or better yet a .cmd file): set COMSPEC=C:/path/to/MSYS/1.0/bin/sh.exe C:/path/to/script args Visual Studio: devenv solution.sln /build configuration Although it now seems to be recommended to use MSBuild (presumably starting with VS 2010?): http://msdn.microsoft.com/en-us/library/xee0c8y7%28v=VS.90%29.aspx There's jhbuild, but that would probably lead to trouble building different configurations of the same module: MSYS+MinGW, MSYS+mingw-w64 32/64 bit both preferably with detached debug symbols (if possible) and one or more VS versions each in Release and Debug mode? There's also the OSSBuild project that might be worthy of some attention: http://code.google.com/p/ossbuild/ Sounds like a huge amount of work before we'd even be able to think about integrating such a build tool with GNOME's buildbot (build.gnome.org). Not to mention who'd be provided the necessary infrastructure and required licenses, as it would probably be advisable not to rely on a single person for all this? mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ win32 fixes, please test
On Thu, 20 Oct 2011 08:37:35 +, Andy Spencer wrote: First off, when using the MS-Windows theme, some widgets don't render correctly and show up as black boxes. For example, notebooks with tab position set to GTK_POS_LEFT don't render. http://andy753421.ath.cx/linked/aweather-gtk-2.24-test.png To clarify: this happens with the Windows Classic theme which doesn't use uxtheme.dll for rendering. I'm hunting this one down as we speak, together with https://bugzilla.gnome.org/show_bug.cgi?id=650300 and https://bugzilla.gnome.org/show_bug.cgi?id=552681 mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ win32 fixes, please test
On Thu, 20 Oct 2011 09:39:44 +0200, Alexander Larsson wrote: I've not really used Gtk+ on windows for real, so I was mainly working from first principles in the code fixing stuff that was obviously wrong. Do you know of any other outstanding win32 bugs that I can look at? It would be nice if you could take a look at this: https://bugzilla.gnome.org/show_bug.cgi?id=552041 Have had this patch applied on 2.20, 2.22, 2.24 and now master and have not yet encountered any problems with it. It sure wouldn't hurt having another set of brains thinking this over though. Also, this could eventually help with fixing https://bugzilla.gnome.org/show_bug.cgi?id=137968 Just so you're aware, I've been working on notebook themeing: - https://bugzilla.gnome.org/show_bug.cgi?id=650300 - https://bugzilla.gnome.org/show_bug.cgi?id=552681 and GTK_POS_LEFT and GTK_POS_RIGHT tabs being rendered as a black rectangle when using the classic theme instead of uxtheme. These should be finished relatively soon I hope. Stuff I have yet to properly look into but would be nice to have fixed: - https://bugzilla.gnome.org/show_bug.cgi?id=643138 - https://bugzilla.gnome.org/show_bug.cgi?id=644286 mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ win32 fixes, please test
On Wed, 19 Oct 2011 22:53:49 +0200, Alexander Larsson wrote: I just pushed a bunch of changes to how grabs and crossing events work in the win32 backend to the gtk-2-24-win32 branch, and I want to fix any other leftover bugs from the client side windows conversion. From my first tests (on Windows XP), this looks good. Even better, it's amazing to see some long standing bugs finally squashed. Thank you! Can any people interested in the win32 code please try this out and report any issues, regressions against gtk-2-24 or just things that are broken on windows related to windows and events. To hopefully make this a bit easier on other people interested in testing, I've (hastily!) constructed a gtk+-bundle based on this branch. A word of warning is in order though: ! this bundle is *not* to be used in any kind of production environment ! this bundle is for testing purposes only ! this bundle is entirely unsupported ! there is no warranty whatsoever ! if this bundle breaks your favorite toy, you get to keep the pieces Now we've gotten that out of the way, note that this bundle is a bit special compared to the gtk+-bundles usually available on gtk.org in that: - not all locales are included (saved me a bit of time) - no documentation is included (saved me a bit of time) + all 64 test programs not usually distributed are included in the bin directory http://www.optionexplicit.be/projects/gnome-windows/20111020/gtk+-bundle_test_gtk-2-24-win32_branch.zip mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: A little help with a Win32 GDK problem please
On Mon, 10 Oct 2011 16:46:30 +0200, Kean Johnston wrote: So the obvious root cause is why display-device_manager is NULL. I have already verified that that line is in fact being called (i.e, it is not because g_return_val_if_fail() is returning NULL). The only location device_manager is set (that I know of) is in _gdk_input_init() in gdk/win32/gdkinput.c 1) is _gdk_input_init() called before you hit this problem? 2) Does the g_object_new (GDK_TYPE_DEVICE_MANAGER_WIN32, ...) call in there return something sensible? mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: A little help with a Win32 GDK problem please
On 10/10/2011 21:32, Kean Johnston wrote: Actually I found the root of the problem (I just haven't figured out how to fix it yet, other than a hack). The problem is I have a Wacom Cintiq so I have the tablet library. When the tablet library is present and it is being initialized, it tries to create a small window to capture events. gdkdevicemanager-win32.c:450. That function (_gdk_input_wintab_init_check) is being called while the main GDK context is being created. It is during that call to create the wintab window that it is getting the NULL, because initialization of GdkDisplay hasn't finished yet. Sounds like that's related to D) No input devices are detected from https://bugzilla.gnome.org/show_bug.cgi?id=653437#c4 I'll be getting a tablet (hopefully) soon, so until then I won't be able to help out much I'm afraid... mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: A little help with a Win32 GDK problem please
On 10/10/2011 21:55, Kean Johnston wrote: Sounds like that's related to D) No input devices are detected from https://bugzilla.gnome.org/show_bug.cgi?id=653437#c4 Sadly, making it just load the DLL without a full path didn't fix this problem. This really is a sequencing problem. That wintab initialization is simply happening too early. Or, at the very least, it's creation of a new GDK window to capture events is happening too early. Oh well, it was worth a try. Hmmm, I wonder if the new GdkDeviceManager stuff may have anything to do with this. Would seem natural that support for multiple input devices has changed the rules of the game a bit... I'll tinker with this some more when I can focus on it but I may have some questions for you :) Sure, np :) mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Grip Size
On 26/09/2011 21:21, Matthew Bucknall wrote: I'm working on a custom container class using GTK+ 3.0 which has some similarities with GtkPaned but supports more than two child widgets. Got something something similar working nicely some time ago, but targeting GTK+ 2 through PyGTK: https://github.com/dieterv/etk.docking/blob/master/lib/etk/docking/dockpaned.py I can install a style property to specify the size of the grips used for resizing child widgets, however it is not likely that any theme will ever support the property for my class. Is it possible for my container class to get at the handle-size property for GtkPaned without having to instantiate a GtkPaned object? Would be interested to learn the same as we're simply defaulting to 4 pixels in the code linked above. gtkpaned.c's handle-size style property seems to default to 5 these days: http://git.gnome.org/browse/gtk+/tree/gtk/gtkpaned.c#n369 mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: Plans for GTK+ Bundles for win32 and win64?
On 08/09/2011 12:24, Olav Vitters wrote: On Thu, Sep 08, 2011 at 12:09:55PM +0200, dieterv wrote: I've given you the required permissions to SSH to master.gnome.org. Everything is in /ftp/pub/GNOME/binaries, etc. Recommend using sftp to upload stuff (note: this procedure is only for binaries). For binaries: Just upload, then run signal-ftp-sync afterwards to update ftp.gnome.org. Thank you! mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: Plans for GTK+ Bundles for win32 and win64?
On Thu, 8 Sep 2011 14:18:41 +0100, Sam Thursfield wrote: Let me first remind everyone that https://live.gnome.org/Windows/Discussion has a good summary of all things that are being discussed here. We're kind of heading in four different directions at once (fedora-mingw, MSVC, native mingw, OBS) so it's important we keep track :) Maybe it would be a good idea to stop insisting our beloved GNOME platform should only have 1 blessed set of binaries for Windows altogether and embrace the diversity that has been created. All these options are there for a reason. All of them. At the end of the day, Free Software development and GNOME are all about choice, right? I mean, we can continue this holy war on what's going to be the next official set of binaries ad infinitum. And never reach any consensus. It's like forcing distroX down the throat of an avid distroY user, or forcing Vim onto a follower of the Church of Emacs. There's little chance anybody will succeed at any of that... So then it comes down to properly advertising and documenting the choices we have. Something along the lines of What's the right option for my situation? on live.gnome.org and www.gtk.org. Intended audience being application developers and packagers, off course. For example: - I can't or don't want to write a native windows port for my application, but still want it to work on Windows: It must be your lucky day! Go have a look at Cygwin, it provides a POSIX emulation layer on top of Windows. Best bet for support is some place Cygwin related ! Note downsides here == Happy customer :) - I want or have to use Visual Studio on Windows: Sure, here's how to build GTK+ with Visual Studio Solution files. And here you can learn how to build your own applications with Visual Studio. These binaries are linked against msvcrA.dll, for use with Visual Studio B. And here's binaries that are linked against msvcrC.dll for use with Vidual Studio D. Best bet for support is ??? ! Make sure you are allowed to redistribute msvcr?.dll. Consult ??? for more information. ! Note other downsides here. == Have a blast! - I don't have/want Visual Studio. gcc on windows? No problem. There's a complete Free toolchain called MinGW that can function together with a minimal POSIX emulation layer called MSYS. mingw-get update mingw-get install gnome-sdk These binaries are linked against msvcrt.dll and can be used with mingw.org's compiler. These binaries come with gobject-introspection support out of the box. Well, not yet, but real soon now ;) Best bet for support is ??? ! Only works on Windows XP or newer. ! Note other downsides here. == Have fun! - Hey, I want to cross compile my stuff from Linux? Cool, have a look at OBS and this script that automatically downloads everything you've ever dreamed of. These binaries are linked against msvcrt.dll and can be used with mingw-w64's compilers Best bet for support is ??? ! Note downsides here. == Happy hacking! Or have a look at fedora-mingw These binaries are linked against msvcrt.dll and can be used with mingw.org's compilers (for now, but there's a message somewhere about migrating to mingw-w64 whenever mingw-w64 has passed Redhat's legal audit). Best bet for support is ??? ! Note downsides here. == Happy hacking! Or have a look at (Debian's||Gentoo's||...) MinGW environment: List specifics here ... - All good and well, but I don't want to bundle a complete and private set of dependencies of the GNOME platform? No problem. Here's how to use a shared version of the platform. Linked against msvcr10, for use with Visual Studio and the DDK. Best bet for support is ??? ! Note downsides here. = Good luck! What do you think? Can we try and collaborate on such a text on live.gnome.org and/or windows-devel-list or something? With that out of the way, we can finally all focus on getting the GNOME Platform back on track on Windows and start coming up with patches :) On Thu, Sep 8, 2011 at 1:12 PM, John Stowers john.stowers.li...@gmail.com wrote: Cool! note: these are my uninformed ideas, I have not actually seen the implementation for the methods you describe... I think JHBuild is *almost* able to do this itself. If the binary/zip module type patch was applied to JHbuild then I think this would not be too much work to complete. I'm actually not sure the binary module type is such a good idea any more. It used to be the case that in my windows fork of jhbuild the binary module type was used to upgrade and patch various parts of MSYS and get hold of deps like libpng, zlib, etc. Since then, mingw-get has arrived and the general state of MSYS is a lot stronger, to the point where it doesn't really need patching
Re: Fwd: Plans for GTK+ Bundles for win32 and win64?
On 08/09/2011 18:47, Jernej Simončič wrote: On Thu, 08 Sep 2011 14:49:55 +0200, dieterv wrote: No, Gimp definitely isn't a good example - just try dropping an old version of intl.dll to your System32 directory (like a certain well-known antivirus seems to do). If you do it before you ran Gimp for the first time, you'll get to click away some 150 message boxes complaining about missing exports. Ah yes. That about the only problem left with the way Gimp (and the PyGTK AIO installer) is packaged for windows that I'm aware of. Thanks for reminding me! Care to disclose the name of that certain antivirus? We've been looking for possible sources of this for ages over @PyGTK (the Gramps devs even wrote a sanity checking script to detect this and other weird situations). It is strange that with both SafeDllSearchMode enabled and disabled, %WINDIR%\system32 takes precedent over the directory from which the application loaded. Haven't yet found out why unfortunatly... mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: Plans for GTK+ Bundles for win32 and win64?
On 08/09/2011 21:21, Kean Johnston wrote: so even if we named the DLL's a bit less specifically (and just used, for example, glib2.dll) that still shouldn't be a problem. And how exactly is doing that different from what we already have today: libglib-2.0-0.dll? mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: Plans for GTK+ Bundles for win32 and win64?
On 08/09/2011 20:15, Jernej Simončič wrote: On Thu, 08 Sep 2011 19:55:27 +0200, Dieter Verfaillie wrote: Care to disclose the name of that certain antivirus? We've been looking for possible sources of this for ages over @PyGTK (the Gramps devs even wrote a sanity checking script to detect this and other weird situations). I think it's Norton (but I'm not entirely sure - I don't use it, and it's just what one of the people who had the problem mentioned). It is strange that with both SafeDllSearchMode enabled and disabled, %WINDIR%\system32 takes precedent over the directory from which the application loaded. Haven't yet found out why unfortunatly... System32 doesn't have precedence over the .exe directory, Yeah, checked msdn yet again just to be sure. Got me worried there for a second ;) however in Gimp's case, the plug-ins are stored separately from the main executable, and System32 is searched before %PATH%. The only way to work around the problem would be by using assemblies, but that's a whole different can of worms. Saying this without knowing much about how Gimp plugins function exactly: Is the path where plugins' .dll files live known before loading the plugin's .exe? For example the lib\gimp\2.0\plug-ins\ directory of the respective plugin? If so, a well placed SetDllDirectory(lpPathName) [1] before loading the plugin could solve that as it places lpPathName between the main executable and the system directory in the dll search order. SetDllDirectory(NULL) can be used to restore the search order to it's default again. But that would only work for Windows XP SP1 and newer... mvg, Dieter [1] or the SetDllDirectoryW variant ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: make glib-2.29.16 fails on codegen_main.py
Quoting George Brink siberian...@yahoo.com: On 8/16/2011 3:31 PM, Dieter Verfaillie wrote: You seem to be hitting the same stuff I have already encountered, so you might also be interested in my windows branch here: https://github.com/dieterv/glib/tree/windows Yes, I am trying to build GTK+3 on Windows... without any luck for now. Hang in there, it's possible. Have had it working (even with introspection support) for some time now. The mswindows theme engine is broken though... Your branch also is not very easy to use. You did not published ready to use configure script, and automake from MSYS does show a lot of errors while attempting to make a new configure. Well, it's a branch, not a source tarball so you are indeed expected to either: - fix MSYS (haven't had time yet to build a mingw-get-able repo for this) or; - you can also simply NOCONFIGURE=1 ./autogen on a Linux box/vm and do everything else with MinGW/MSYS. mvg, Dieter This message was sent using IMP, the Internet Messaging Program. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: make glib-2.29.16 fails on codegen_main.py
On 16/08/2011 20:12, George Brink wrote: Environment: WinXP, MinGW+MSYS, Python 2.7 make[6]: Entering directory `/c/Dev/gtk+/glib-2.29.16/gio/tests/gdbus-object-manager-example' GEN gdbus-example-objectmanager-generated-org.gtk.GDBus.Example.ObjectManager.Animal.xml Traceback (most recent call last): File ../../../gio/gdbus-codegen/codegen_main.py, line 200, in module codegen_main() File ../../../gio/gdbus-codegen/codegen_main.py, line 171, in codegen_main parsed_ifaces = parser.parse_dbus_xml(xml_data) AttributeError: 'module' object has no attribute 'parse_dbus_xml' make[6]: *** [gdbus-example-objectmanager-generated-org.gtk.GDBus.Example.ObjectManager.Animal.xml] Error 1 make[6]: Leaving directory `/c/Dev/gtk+/glib-2.29.16/gio/tests/gdbus-object-manager-example' Any ideas? Yep, that's https://bugzilla.gnome.org/show_bug.cgi?id=650763 Apply the patches in order and you're good to go. I hope Colin or somebody else can get back to reviewing them now that the Desktop Summit is over... You seem to be hitting the same stuff I have already encountered, so you might also be interested in my windows branch here: https://github.com/dieterv/glib/tree/windows Note that I don't care about non-fast-forward updates on that branch (it's only goal is to get stuff in glib proper)... That branch is maintained as part of my gobject-introspection windows port which is also slowly starting to function :) See here for more info: http://mail.gnome.org/archives/python-hackers-list/2011-August/msg4.html mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Unable to compile glib 2.29.12 in MinGW/MSYS
Quoting George Brink siberian...@yahoo.com: My environment: MinGW+MSYS on WinXP/SP3. make fails on glib/gatomic.c: That's https://bugzilla.gnome.org/show_bug.cgi?id=652827 I'm using the patch proposed in comment 4 until a proper solution is found. mvg, Dieter ps. I noticed that bug report was still marked as NEEDINFO ever since comment 2. That info has already been provided so I changed it back to UNCONFIRMED now... This message was sent using IMP, the Internet Messaging Program. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLIB, libffi and Windows
On 07/08/2011 19:33, Kean Johnston wrote: I am trying to compile master on Windows. gclosure.c doesn't compile due to not having ffi.h. The presence of this is not tested in configure, and there is no mention of it being a requirement in INSTALL. Having taken a look at the offending file would it be a big loss if we just didn't provide g_cclosure_marshal_generic() on Win32? Yeah, for one thing, you'd be breaking PyGObject which checks for libffi's presence and if it's there uses g_cclosure_marshal_generic (in gobjectmodule.c). Maybe you can reuse PyGObject's ffi detection method from it's configure.ac for GLib instead? mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Updated GTK+ 2.24.5 binaries (and bundle)
On 23/07/2011 00:27, Maarten Bosmans wrote: 2011/7/23 Andrea Bolognani e...@kiyuko.org: The gnome-win32 (or whatever it ends up being called) mailing list somebody was proposing eariler in the thread would probably speed up the process of reaching a consensus about similar issues. Hear, hear. This has now been requested. See https://bugzilla.gnome.org/show_bug.cgi?id=655283 mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Updated GTK+ 2.24.5 binaries (and bundle)
On 22/07/2011 12:11, Sam Thursfield wrote: It's a small step but I just added a page to the wiki: https://live.gnome.org/Windows/Discussion Since there's a few of us all doing different things in this area I think it would be helpful if we at least all kept that up to date with what we are doing and why, and hopefully it can be the first step to a bit more collaboration. More collaboration would indeed be a very good thing. Maybe reviving some form of the old gtk-win32-list mailing list could be helpful in discussing these long-term matters? Something like gnome-windows-list to reflect the interest in a more complete set of the GNOME platform than only GTK+ (just take a look at the nice image on http://developer.gnome.org/ for example). Also, to clarify why I've started updating Tor's scripts: - He used to make the binaries that are available on www.gtk.org and ftp.gnome.org, but has recently announced he is no longer interested in doing so [1]. This is fine, we all owe him at least a couple of beers for the service he has provided all those years! - But some of us have loads of software using these builds that suffer from bugs in GLib, GTK+ 2, etc from time to time - Being able to just drop an updated version of these platform libraries in place when it is know to fix a bug is a good thing So my intent is to continue to update Tor's scripts and the good old gtk+-bundle for as long as relevant GTK+ 2.X releases are made. What's going to be accepted as the official builds for GTK+ 3, I have no idea. Now, after all this discussing about build systems and what-not, my question still stands: is there interest in keeping the binaries on www.gtk.org and ftp.gnome.org/pub/GNOME/binaries/win32/ up to date for the remainder of GTK+-2.X's useful life? Thanks, Dieter [1] http://tml-blog.blogspot.com/2011/03/gtk-on-windows-i-am-not-really-doing-it.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Updated GTK+ 2.24.5 binaries (and bundle)
On 22/07/2011 17:12, Andrea Bolognani wrote: Speaking as an application developer, I’m more interested in ready–to–deploy binaries for GTK+ 3.0. A nice bundle like the one Tor provided for GTK+ 2.X would be a neat plus. Something like that is certainly possible and I think with time is an obvious thing to do. Be it created with Tor's gtk-bundle script or repackaging the work from the Open Build Service or something else. Who knows... The problem is that GTK+ 3 will need some porting effort. It currently builds just fine but, from what I've seen, the themeing engine (wimp) will need to be ported to use gsettings, there's still work to be done to catch up with the csw changes done in 2.18 etc. Until that condition is met, I’m not going to port my applications to GTK+ 3.0, which I would really love to do, just because I need them to run on Windows. Yep, I'm in a comparable situation... So I very much welcome the ones who, unlike me, have both the time and the expertise needed to advance the status of GTK+ on win32; but I think they should put less effort in keeping GTK+ 2.X alive and more effort in making GTK+ 3.0 on win32 a viable solution. Just my 0.2€ ;) Don't worry, about 10% of the time I can invest in these things is going into keeping what I already have (and uses GTK+ 2.X) alive. Every other moment I can spare is spent getting GLib, gobject-introspection, pygobject an GTK+ 3 going on Windows and patches are slowly starting to trickle to the various bugzilla components... I'm sure others already have adopted a similar policy or will do so soon too... mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Updated GTK+ 2.24.5 binaries (and bundle)
Quoting Krzysztof Kosiński tweenk...@gmail.com: Maybe I wasn't clear enough. I worked on *getting rid* of this Windows-only build tool, but didn't succeed yet. FWIW, Waf appears to work best for me. Apologies, I misunderstood... mvg, Dieter This message was sent using IMP, the Internet Messaging Program. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Updated GTK+ 2.24.5 binaries (and bundle)
Hi, Looks like I screwed up yesterday, so I've updated the packages on [1] to now *really* include the MSVC-compatible import libraries. Sorry for the inconvenience... Thanks, Dieter [1] https://www.github.com/dieterv/legacynativebuilds/downloads ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Updated GTK+ 2.24.5 binaries (and bundle)
Quoting Sam Thursfield sss...@gmail.com: On Mon, Jul 11, 2011 at 9:22 PM, Dieter Verfaillie It's great that you've taken on to do this work, many thanks! I've done some work on windows builds myself[1], Ah, yes. I've stumbled across your page multiple times already :) and in fact there's more people interested than it might appear so feel free to bring issues up on this list. The more we coordinate our effort the better. Agreed. You can get the Visual C++ toolchain for free from the Windows SDK[2], if you're interested in making these. Generating the import libs for VC is super easy, you just need the .def file for the DLL (and not even the actual DLL). Hmm, I thought lib.exe was no longer available in the Windows 7 SDK? I did discover yesterday evening, a couple of hours after sending my original message, that what I suppose is the last version of lib.exe still available for download can be found in the Windows Server 2003 R2 Platform SDK: http://www.microsoft.com/download/en/details.aspx?id=12675 [1] So, if all goes well, I'll be uploading new packages to github this evening. This time _fully compatible_ with those already on ftp.gnome.org :) As such, is there any interest in hosting these files on ftp.gnome.org/www.gtk.org? If there is, I'll gladly do the work and also provide a patch for http://www.gtk.org/download/win32.php I'm sure there is, I don't know who is the person to give you access Let's hope this thread get's noticed by whoever it is that get's to decide... That's a whole new can of worms :) I share the dream that one day it would be great to use the mingw cross compiler and an automated build service Agreed, but python.org not officially supporting cross-compilation does not combine with me primarily working on Python bindings. I'd need Python 2.7, 3.2, 3.2+ etc and the ability to build for example PyGObject or Glade with Python Widgets Support for each Python version for such a build service to be useful. I won't attempt to contribute cross-compilation support towards python.org, many have tried that already... but I think it's important to get native builds working more reliably to begin with .. I have been dreaming of having an msys-python port though (considered by most to be even more exotic than cross-compiling Python itself, I guess). Would make jhbuild, but also other tools written in Python that need to run at build-time like gi-scanner, much more reliable. And we'd be able to get rid of loads of subprocessing workarounds/bugs... Thanks, Dieter [1] No need to burn the image to a cd, just extract it with 7-zip and install from that. You only need the Microsoft Windows Core SDK, the rest is not needed so the resulting installation is quite small, for a Platform/Windows SDK, that is ;) When installed, lib.exe hides itself in Bin\win64\x86\AMD64\ and unlike the directory name implies, the -machine:X86 flag still seems to work fine. This message was sent using IMP, the Internet Messaging Program. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Updated GTK+ 2.24.5 binaries (and bundle)
Quoting Sam Thursfield sss...@gmail.com: On Tue, Jul 12, 2011 at 1:10 PM, Dieter Verfaillie I have been dreaming of having an msys-python port though (considered by most to be even more exotic than cross-compiling Python itself, I guess). Would make jhbuild, but also other tools written in Python that need to run at build-time like gi-scanner, much more reliable. And we'd be able to get rid of loads of subprocessing workarounds/bugs... actually not such a crack idea, there's a lot of hacks in different apps that could go in there. But why not just put them in mainline? If you mean getting the various workarounds into python.org's Windows builds: Well, they'd still be workarounds. An msys-python port would be aware of the POSIX-y environment it runs in (MSYS being based on an old Cygwin version). If you mean contributing patches to enable an msys-python port to python.org: Well, I've been dreaming about it. But looking at how in the past MinGW and MinGW cross-compiling efforts have been handled I'm not really confident actually doing so is worth my time. Well, I'll give Python's configure script a shot in an MSYS bash session configured in MSYS System Builder mode. Maybe it'll be less work than I imagined. Or more than I ever feared. Who knows? ;) mvg, Dieter This message was sent using IMP, the Internet Messaging Program. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Updated GTK+ 2.24.5 binaries (and bundle)
On 12/07/2011 18:02, Krzysztof Kosiński wrote: I worked on a cross platform build system for Inkscape. Currently we use Autotools on Unix-like platforms and a custom build tool on Windows. because we decided that we cannot depend on MSYS. Here are my $0.02: The whole raison d'etre of MSYS is to allow Autotools to work. Observing mingw-users list I'm getting the impression the mingw.org (and thus MSYS) devs are slowly starting to change their worldview on that. There's even an effort to build a real msys-git port going on... Once you get rid of Autotools, you no longer need MSYS. Fair enough, using a custom build tool on Windows is your choice, not mine ;) And to be clear, for those of us that do not get to choose their OS (but thank $DEITY are free to choose their tools) MinGW/MSYS at least provides something of a sane environment... And if you are serious about portability, you need to get rid of Autotools anyway, I prefer to think that there's a reason nobody seems to be in a hurry to port the whole of GNOME's platform away to cmake, waf, scons, etc... because the last available version of MSYS Perl can no longer run the recent automake releases. Comparing... (both from an MSYS bash session in MinGW mode and MSYS System Builder mode): $ automake --version automake (GNU automake) 1.11.1 snipped ...with ftp://ftp.gnu.org/gnu/automake/ leads me to believe that 1.11.1 is indeed the most recent version of automake? Also msys-perl has been updated. Check this thread: http://article.gmane.org/gmane.comp.gnu.mingw.user/36263 There a good chance most intltool vs (Active)Perl hacks/workarounds described all over the net to get a working MinGW/MSYS build system for the GNOME platform going are no longer valid. At least I didn't need any of those intltool vs Perl hacks any more and have not encountered any trouble with automake building these GTK+ 2.24.5 packages nor while building libffi-3.0.10rc8, pkg-config-0.25, glib master, gobject-introspection master, py2cairo via autotools now that it's setup.py has been removed and it's waf system refuses to cooperate and pygobject with gi support again via autotools. This makes building from a source checkout (not a tarball) on Windows impossible. Read above. No offense but either your information is seriously outdated, you used an ancient version (the old automated installer?) or you had a flaw in your MinGW/MSYS setup somewhere. Anyway, this is getting off-topic. I'm going back to my original question now... mvg, Dieter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Updated GTK+ 2.24.5 binaries (and bundle)
Hi, I've updated the packages on [1] to now include the MSVC-compatible import libraries (built with the version of lib.exe included with the Windows Server 2003 R2 Platform SDK (5.2.3790.2075.51) available from [2]. The only difference remaining between these and those already on ftp.gnome.org/www.gtk.org is intentional: gtk+_2.24.5-2_win32.sh and gtk+_2.24.5-2_win32.log (included with gtk+-dev_2.24.5-2_win32.zip) live in src/dieterv/packaging instead of src/tml/packaging in the hopes of making it clear Tor has not built these (so users of these don't go bugging him for support); So, getting back to my original question: is there any interest in hosting these files on ftp.gnome.org/www.gtk.org? If there is, I'll gladly do the work and also provide a patch for [3]. Thanks, Dieter [1] https://www.github.com/dieterv/legacynativebuilds/downloads [2] http://www.microsoft.com/download/en/details.aspx?id=12675 [3] http://www.gtk.org/download/win32.php ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Updated GTK+ 2.24.5 binaries (and bundle)
Hi, Some time ago I've asked Tor how his Windows build environment looked like and he shared everything to be able to recreate it (thanks again!). The various mails we exchanged and the resulting directory structure and scripts can be found here: https://www.github.com/dieterv/legacynativebuilds [1] I've used this information to build updated packages of GTK+-2.24.5 and a GTK+-bundle [2] that goes with it, in response to for example: - https://bugzilla.gnome.org/show_bug.cgi?id=653995 coming from https://bugs.launchpad.net/zim/+bug/783388 - this thread on PyGTK's mailing list: http://www.daa.com.au/pipermail/pygtk/2011-May/019755.html The only differences between these and the packages already on ftp.gnome.org/www.gtk.org are: - gtk+_2.24.5-1_win32.sh and gtk+_2.24.5-1_win32.log (included with gtk+-dev_2.24.5-1_win32.zip) live in src/dieterv/packaging instead of src/tml/packaging in the hopes of making it clear Tor has not built these (so users of these don't go bugging him for support); - the MSVC-compatible import libraries are missing from gtk+-dev_2.24.5-1_win32.zip (lib/gailutil.lib, lib/gdk-win32-2.0.lib and lib/gtk-win32-2.0.lib), I simply don't own a copy of Visual Studio 6 so these files have not been generated during build... Other than that, these are drop-in updates compatible with what's already on ftp.gnome.org/www.gtk.org. As such, is there any interest in hosting these files on ftp.gnome.org/www.gtk.org? If there is, I'll gladly do the work and also provide a patch for http://www.gtk.org/download/win32.php After that, I can go ahead and build an updated PyGTK All-in-one installer (see www.pygtk.org or ftp.gnome.org/pub/GNOME/binaries/win32/pygtk/2.24/) and glade3-bundle_3.8.0 (https://bugzilla.gnome.org/show_bug.cgi?id=634978). And before someone asks, both are *not* compatible with the binaries provided on build.opensuse.org (due to intl.dll/libintl-8.dll differences). Thanks, Dieter [1] I'm struggling to pour the information into a text suitable for live.gnome.org (help appreciated)!, but the information in this repo combined with the .sh script included with the binaries on ftp.gnome.org are enough to replicate a working build environment by anyone motivated enough to actually do so :) [2] https://github.com/dieterv/legacynativebuilds/downloads ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
