forked from AuroraMiddleware/gtk
GTK is a multi-platform toolkit for creating graphical user interfaces.
3f8c235593
Reuse the existing infrastructure in GtkActionMuxer for propagation of accelerator information: in particular, what accel label ought to appear on menu items for a particular action and target. This is a good idea because we want accels to travel along with the actions that they're tied to and reusing GtkActionMuxer will allow us to do that without creating another hierarchy of a different class for the sole purpose of filling in accel labels on menu items. Doing it this ways also allows those who copy/paste GtkActionMuxer to insert the accels for themselves. Add a new method on the GtkActionObserver interface to report changes. This patch introduces a new concept: "action and target" notation for actions. This format looks like so: "'target'|app.action" or for non-targeted actions: "|app.action" and it is used over a number of possible alternative formats for some good reasons: - it's very easy to get a nul-terminated action name out of this format when we need it, by using strrchr('|') + 1 - we can also get the target out of it using g_variant_parse() because this function takes a pointer to a 'limit' character that is not parsed past: we use the '|' for this - it's extremely easy to hash on this format (just use a normal string hash) vs. attempting to hash on a string plus a GVariant A close contender was to use detailed action strings here, but these are not used for two reasons: - it's not possible to easily get the action name or target out of the strings without more work than the "action and target" format requires - we still intend to use detailed action strings on API (since they are a lot nicer to look at) but detailed action strings can be given in non-canonical forms (eg: 'foo::bar' and 'foo("bar")' are equivalent) so we'd have to go through a normalisation step anyway. Since we're doing that already, we may as well convert to a more convenient internal format. This new "action and target" format is going to start appearing in a lot more places as action descriptions are introduced. I suspect that nobody is using '|' in their action names, but in case I am proven wrong, we can always switch to using something more exotic as a separator character (such as '\x01' or '\xff' or the like). |
||
---|---|---|
build | ||
demos | ||
docs | ||
examples | ||
gdk | ||
gtk | ||
libgail-util | ||
m4 | ||
m4macros | ||
modules | ||
po | ||
po-properties | ||
tests | ||
testsuite | ||
acinclude.m4 | ||
AUTHORS | ||
autogen.sh | ||
config.h.win32.in | ||
configure.ac | ||
COPYING | ||
gail-3.0.pc.in | ||
gdk-3.0.pc.in | ||
git.mk | ||
gtk-engine-check-abi.sh | ||
gtk-zip.sh.in | ||
gtk+-3.0.pc.in | ||
gtk+-unix-print-3.0.pc.in | ||
gtk+.doap | ||
gtk+.spec.in | ||
HACKING | ||
INSTALL.in | ||
MAINTAINERS | ||
makecopyright | ||
Makefile.am | ||
Makefile.decl | ||
makefile.msc | ||
NEWS | ||
NEWS.pre-1-0 | ||
README.commits | ||
README.in | ||
README.win32 | ||
sanitize-la.sh | ||
sanity_check |
The Win32 backend in GTK+ is not as stable or correct as the X11 one. For prebuilt runtime and developer packages see http://ftp.gnome.org/pub/gnome/binaries/win32/ Building GTK+ on Win32 ====================== First you obviously need developer packages for the compile-time dependencies: GDK-Pixbuf, Pango, atk, glib, gettext-runtime, libiconv at least. See http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies . For people compiling GTK+ with Visual C++ 2005 or later, it is recommended that the same compiler is used for at least GDK-Pixbuf, Pango, atk and glib so that crashes and errors caused by different CRTs can be avoided. The VS 2008 project files and/or VS Makefiles are either already available or will be available in the next stable release. Unfortunately compiling with Microsoft's compilers versions 2003 or earlier is not supported as compiling the latest stable GLib (which *is* required for building this GTK+ release) requires features from newer compilers and/or Platform SDKs After installing the dependencies, there are two ways to build GTK+ for win32. 1) GNU tools, ./configure && make install ----------------------------------------- This requires you have mingw and MSYS. Use the configure script, and the resulting Makefiles (which use libtool and gcc to do the compilation). I use this myself, but it can be hard to setup correctly. The full script I run to build GTK+ 2.16 unpacked from a source distribution is as below. This is from bulding GTK+ 2.16.5. I don't use any script like this to build the development branch, as I don't distribute any binaries from development branches. # This is a shell script that calls functions and scripts from # tml@iki.fi's personal work envíronment. It is not expected to be # usable unmodified by others, and is included only for reference. MOD=gtk+ VER=2.16.5 REV=1 ARCH=win32 THIS=${MOD}_${VER}-${REV}_${ARCH} RUNZIP=${MOD}_${VER}-${REV}_${ARCH}.zip DEVZIP=${MOD}-dev_${VER}-${REV}_${ARCH}.zip HEX=`echo $THIS | md5sum | cut -d' ' -f1` TARGET=c:/devel/target/$HEX usedev usemsvs6 ( set -x DEPS=`latest --arch=${ARCH} glib atk cairo pango libpng zlib libtiff jpeg` PROXY_LIBINTL=`latest --arch=${ARCH} proxy-libintl` PKG_CONFIG_PATH= for D in $DEPS; do PATH=/devel/dist/${ARCH}/$D/bin:$PATH [ -d /devel/dist/${ARCH}/$D/lib/pkgconfig ] && PKG_CONFIG_PATH=/devel/dist/${ARCH}/$D/lib/pkgconfig:$PKG_CONFIG_PATH done LIBPNG=`latest --arch=${ARCH} libpng` ZLIB=`latest --arch=${ARCH} zlib` LIBTIFF=`latest --arch=${ARCH} libtiff` JPEG=`latest --arch=${ARCH} jpeg` patch -p0 <<'EOF' EOF lt_cv_deplibs_check_method='pass_all' \ CC='gcc -mtune=pentium3 -mthreads' \ CPPFLAGS="-I/devel/dist/${ARCH}/${LIBPNG}/include \ -I/devel/dist/${ARCH}/${ZLIB}/include \ -I/devel/dist/${ARCH}/${LIBTIFF}/include \ -I/devel/dist/${ARCH}/${JPEG}/include \ -I/devel/dist/${ARCH}/${PROXY_LIBINTL}/include" \ LDFLAGS="-L/devel/dist/${ARCH}/${LIBPNG}/lib \ -L/devel/dist/${ARCH}/${ZLIB}/lib \ -L/devel/dist/${ARCH}/${LIBTIFF}/lib \ -L/devel/dist/${ARCH}/${JPEG}/lib \ -L/devel/dist/${ARCH}/${PROXY_LIBINTL}/lib -Wl,--exclude-libs=libintl.a \ -Wl,--enable-auto-image-base" \ LIBS=-lintl \ CFLAGS=-O2 \ ./configure \ --enable-win32-backend \ --disable-gdiplus \ --with-included-immodules \ --without-libjasper \ --enable-debug=yes \ --enable-explicit-deps=no \ --disable-gtk-doc \ --disable-static \ --prefix=$TARGET && libtoolcacheize && rm gtk/gtk.def && (PATH="$PWD/gdk-pixbuf/.libs:/devel/target/$HEX/bin:$PATH" make -j3 install || (rm .libtool-cache* && PATH="/devel/target/$HEX/bin:$PATH" make -j3 install)) && PATH="/devel/target/$HEX/bin:$PATH" gdk-pixbuf-query-loaders >/devel/target/$HEX/etc/gtk-2.0/gdk-pixbuf.loaders && grep -v -E 'Automatically generated|Created by|LoaderDir =' <$TARGET/etc/gtk-2.0/gdk-pixbuf.loaders >$TARGET/etc/gtk-2.0/gdk-pixbuf.loaders.temp && mv $TARGET/etc/gtk-2.0/gdk-pixbuf.loaders.temp $TARGET/etc/gtk-2.0/gdk-pixbuf.loaders && grep -v -E 'Automatically generated|Created by|ModulesPath =' <$TARGET/etc/gtk-2.0/gtk.immodules >$TARGET/etc/gtk-2.0/gtk.immodules.temp && mv $TARGET/etc/gtk-2.0/gtk.immodules.temp $TARGET/etc/gtk-2.0/gtk.immodules && ./gtk-zip.sh && mv /tmp/${MOD}-${VER}.zip /tmp/$RUNZIP && mv /tmp/${MOD}-dev-${VER}.zip /tmp/$DEVZIP ) 2>&1 | tee /devel/src/tml/packaging/$THIS.log (cd /devel && zip /tmp/$DEVZIP src/tml/packaging/$THIS.{sh,log}) && manifestify /tmp/$RUNZIP /tmp/$DEVZIP You should not just copy the above blindly. There are some things in the script that are very specific to *my* build setup on *my* current machine. For instance the "latest" command, the "usedev" and "usemsvs6" shell functions, the /devel/dist folder. The above script is really just meant for reference, to give an idea. You really need to understand what things like PKG_CONFIG_PATH are and set them up properly after installing the dependencies before building GTK+. As you see above, after running configure, one can just say "make install", like on Unix. A post-build fix is needed, running gdk-pixbuf-query-loaders once more to get a correct gdk-pixbuf.loaders file. For a 64-bit build you need to remove the gtk/gtk.def file and let it be regenerated by the makefilery. This is because the 64-bit GTK dll has a slightly different list of exported function names. This is on purpose and not a bug. The API is the same at the source level, and the same #defines of some function names to actually have a _utf8 suffix is used (just to keep the header simpler). But the corresponding non-suffixed function to maintain ABI stability are not needed in the 64-bit case (because there are no older EXEs around that would require such for ABI stability). 2) Microsoft's tools -------------------- Use the Microsoft compiler, cl and Make, nmake. Say nmake -f makefile.msc in gdk and gtk. Be prepared to manually edit various makefile.msc files, and the makefile snippets in build/win32. There are also VS 2008/2010 solution and project files to build GTK+, which are maintained by Chun-wei Fan. They should build GTK+ out of the box, provided that the afore-mentioned dependencies are installed. They will build GDK with the Win32 backend, GTK+ itself (with GAIL/a11y built in), the GAIL-Util library and the gtk-demo program. Please refer to the following GNOME Live! page for a more detailed ouline on the process of building the GTK+ stack and its dependencies with Visual C++: https://live.gnome.org/GTK%2B/Win32/MSVCCompilationOfGTKStack Alternative 1 also generates Microsoft import libraries (.lib), if you have lib.exe available. It might also work for cross-compilation from Unix. I (Tor) use method 1 myself. Hans Breuer has been taking care of the MSVC makefiles. At times, we disagree a bit about various issues, and for instance the makefile.msc files might not produce identically named DLLs and import libraries as the "autoconfiscated" makefiles and libtool do. If this bothers you, you will have to fix the makefiles. Using GTK+ on Win32 =================== To use GTK+ on Win32, you also need either one of the above mentioned compilers. Other compilers might work, but don't count on it. Look for prebuilt developer packages (DLLs, import libraries, headers) on the above website. Multi-threaded use of GTK+ on Win32 =================================== Multi-threaded GTK+ programs might work on Windows in special simple cases, but not in general. Sorry. If you have all GTK+ and GDK calls in the same thread, it might work. Otherwise, probably not at all. Possible ways to fix this are being investigated. Wintab ====== The tablet support uses the Wintab API. The Wintab development kit is no longer required. The wintab.h header file is bundled with GTK+ sources. Unfortunately it seems that only Wacom tablets come with support for the Wintab API nowadays. --Tor Lillqvist <tml@iki.fi>, <tml@novell.com> --Updated by Fan, Chun-wei <fanc999@yahoo.com.tw>