GTK 2.24.31 static library barebone

As a prior reference https://code.google.com/archive/p/static-gtk2-mingw32/
the thing is no patch provided but hints, that's enough though.

So why GTK2? well, after maintaining pygi-aio for several years, nothing really that good.. honestly
There is rough edges, regressions and more importantly it feel less responsive (with slower start-up). Overall GTK 3.x was turbulent version.

Just FYI, it's possible make GTK3 static build, especially prior to GDK's switch to adwaita as default theme, that is GTK 3.6.x where you get "somewhat" native theme, GTK 3.22 also have "somewahat" native theme returned and  it break XP compatibility Well duh.

I made a mod of vispdisp (a streaming image viewer powered by VIPS) and make single exe with GTK 3.6
https://github.com/tumagonx/XPitory/raw/master/static_port/vipsdisp/vipsdisp.exe support huge tiff/jpg/png image (upx'ed 1.56MB)
That's just to prove I'm not making excuse for choosing GTK2 over GTK3 :)

The goal here is to make it barebone otherwise you may as well use the dll version, no?
Considerations:
1 the focus is GTK alone, the rest isn't that important
2 dependencies will be trimmed down until it become what's GTK only really can use from
3 optimization flags

1) With version 2.24.31 I choose Glib 2.34.x which is the minimum to build the latest librsvg (more about it later), Glib also getting bloated too overtime and there are some regressions I don't want to mess with in more recent versions. Supposedly the officially supported static build for Glib was version 2.28-2.30 but it seems my workaround is fine for 2.34. With this other dependencies are pretty much settled:

zlib 1.2.11
win-iconv 0.6
gettext 0.18.3.2
libffi 3.2.1
pixman 0.34
cairo 1.12.18 (I have crash with cairo 1.14.10)
glib 2.34.3
atk 2.8.0
pango 1.40.12 (1.40.14 claim need glib 2.34, but actually it need quite recent one)
gdk-pixbuf 2.26.5
gtk+ 2.24.31

2) Several libraries to be trimmed down:
pixman : has big chunk of SIMD code, configure with --disable-sse2 --disable-ssse3
cairo : only few features that needed by GTK2, configure with --enable-pthread --disable-interpreter --disable-fc --disable-ft --disable-gobject --disable-png --disable-svg --disable-script --disable-ps (note: pthread is needed for static build to avoid mutex crash)
glib : disabling debugging make it smaller, configure with --enable-debug=no
pango : ditto
gdk-pixbuf : only use gdiplus, configure with --with-included-loaders=gdip-png,gdip-gif,gdip-bmp,gdip-tiff,gdip-emf,gdip-jpeg,gdip-wmf,gdip-ico --without-libpng --with-gdiplus --without-libjasper --without-libtiff --without-libjpeg --disable-modules --enable-debug=no
gtk : --disable-modules --with-included-immodules=ime,ipa --enable-debug=no

Do we need svg support? hint: it was one of format that MS really "hate" and hey Qt has it.
if so things get complicated as there is circular dependencies between gdk-pixbuf and librsvg, to solve that merge librsvg objects into libgdk_pixbuf-2.0.a and pass all librsvg dependencies through LIBS that is libcroco and libxml2, overall adds 500KB.

Do we need fontconfig/freetype? it will solve problem of "complex/unusual" font rendering that plagued win32 backend, but it also add almost 700KB (including several config files) and annoying font caching startup once in a while... frankly for most of case it's redundant.

Do we need full jpeg, png and tiff support? gdiplus backend provide less feature for these formats: no progressive mode, no png metadata, incomplete tiiff format/compression and so on. but this will add even more weight 1-1.5MB depends on configuration. Furthermore there is psd, webp, and raw modules that can be enabled

3) the flags is nothing special and for portability reason -flto is avoided (it will make your exe even smaller but you'll need gcc 4.6-4.8, I think)
cflags : -Os
add -fno-unwind-tables -fno-asynchronous-unwind-tables if EH is SJLJ, but not for DWARF or SEH
add -ffunction-sections -fdata-sections this is effective against simpleton app but lost it once app getting complex, in this case -flto is better replacement for dead code removal.
ldflags : -Os -Wl,-s
add -Wl,--gc-sections to correspond above cflags or -flto if you use it on cflags
cppflags : -DGLIB_STATIC_COMPILATION -DGOBJECT_STATIC_COMPILATION -DGDK_PIXBUF_STATIC_COMPILATION -DPANGO_STATIC_COMPILATION -DATK_STATIC_COMPILATION -DGTK_STATIC_COMPILATION -DGDK_STATIC_COMPILATION

The static library is intended for static exe, if monolithic dll desired then we need better replacement for GetModuleFileName (without relying on DllMain) such GetModuleHandleEx otherwise localization path will be unpredictable.
Produced exe for simpleton app is about 3.6MB, 3MB with LTO libraries, and a little over 1MB if compressed with 7zip.That's half of prior effort, not bad.

Downloads
Patches (including new stock icons replacement) : gtk+-2.24.31-static_patch.7z
Libraries and (flattened) headers : gtk+-2.24.31_win32_win64_sjlj.7z
add to ldflags like: -lgtk-win32-2.0 -lgdk-win32-2.0 -lpangocairo-1.0 -lpangowin32-1.0 -lpango-1.0 -latk-1.0 -lcairo -lpixman-1 -lgdk_pixbuf-2.0 -lgio-2.0 -lgmodule-2.0 -lgobject-2.0 -lglib-2.0 -lintl -liconv -lz -lffi -lws2_32 -lole32 -lwinmm -ldnsapi -lshlwapi -luuid -lgdi32 -lgdiplus -lusp10 -lmsimg32 -limm32
alternatively create text files named libgtk2.a with linker script:
GROUP(-lgtk-win32-2.0 -lgdk-win32-2.0 -lpangocairo-1.0 -lpangowin32-1.0 -lpango-1.0 -latk-1.0 -lcairo -lpixman-1 -lgdk_pixbuf-2.0 -lgio-2.0 -lgmodule-2.0 -lgobject-2.0 -lglib-2.0 -lintl -liconv -lz -lffi -lws2_32 -lole32 -lwinmm -ldnsapi -lshlwapi -luuid -lgdi32 -lgdiplus -lusp10 -lmsimg32 -limm32)
then we can just add only -lgtk2 in ldflags

Javascript, GTK and Windows

GJS (Spidermonkey) and Seed (JSCore) are two Javascript binding for GTK (and other Gnome libraries) via GObject Introspection. The former commonly used by gnome shell, while the latter is a bit dated by now.

There are good demos at https://developer.gnome.org/gnome-devel-demos/stable/js.html.en and https://git.gnome.org/browse/seed-examples/

The build also bundled in PyGObject AIO but certainly shouldn't be there. So I might remove it one day and put it elsewhere.

At the moment only GTK bundled (you could make gui, image viewer etc) though it can use others gnome libraries, but I need to think about the packaging first.

Download:
GJS-1.42_Seed-3.8.1.7z

PyGI AIO 3.12.x for Win32

With the new GObject-Introspection 1.40, gir generation now works with MinGW-W64 CRT and most docstrings issues seems been squashed too. GTK is not on Windows side though, version 3.12.1 looks buggier where an app (in this case gtk3-demo) will lose toplevel window (the one that is native and directed by OS), wish I have screenshot to show (I will). All 3.10  bugs also persist in 3.12, so despite of lots of new features it's really no good at the moment.

GTK 3.12.1 has lots of fixes in the Win32 theme (FYI, it's controlled by compiled-in css files namely gtk-win32*.css) which I tried to backport to 3.8.9 and 3.10.8 with some success, I also made correction on Windows XP specific part. But realized that perfect "theming emulation" is not possible yet with current css feature and event handling.

Overall there are new lots of libraries joined the AIO packages, with over 100 introspected libraries. The 64 bit port is not convincing... In some of my tests GI fail to resolve to existed exported functions of a dll, possibly getting skipped/mangled in the process. At C level, the libraries/apps behave just as good as 32 bit ones, so the problem is pygobject specific here.

Download for Python 32bit at:
http://sourceforge.net/projects/pygobjectwin32/files/

PyGObject homepage:
https://wiki.gnome.org/PyGObject

How to build PyGI AIO with Moluccas

Read about Moluccas first, its gcc has experimental CRT targeting for this guide.

MS CRT targeting initially laid by official mingw.org but still far incomplete. At first I thought it would be as easy as set cflag/cxxflag __MSVCRT_VERSION__=0x0900 and add -lmsvcr90 to GCC's specs file, well for a trivial program? yes it can but thats all it can get. As my experiment goes by there are many issues piling up (from incomplete msvcr implib to puzzled LFS/Y3K macros) that forcing me to modify mingw's crt and win32api files to allow a package completely linked to the new msvcrt dll. In the end I decided to add new GCC flags to simplify this: -vcr70 to -vcr110. The flags correspond msvcrt redist version bundled by each release of Visual C++. Even today it still far from complete.

What it has to do with this guide? there is an article wrote by win32 contributors of Gnome framework (or whatever you called it) that explain the concern. While my approach is far cry in comparison to use real thing (yeah I know MSVC has free express edition) it still useful in some cases at least for OSS zealot (even if they use Windoze).

This guide will focus on latest stable version of GTK-related (should be called GObject-related) libraries as this written. The main packages are Glib 2.38.1 + GTK 3.10.2 + GI 1.38.0 + PyGObject 3.10.1 and we are targeting python 3.3 (which use msvcr100.dll). I must tell you though, there is steady progress to support MSVC from upstream at least for major libraries including GI thingy.

If you don't need CRT targeting, you can use any GCC of your preference in moluccas by put it into moluccas root then switch over using setgcc [gcc folder name].

Download moluccas 0.8a, you need to download the following packages:

M08.exe
M08-basemsys.7z
M08-basetools.7z
M08-ccomp.7z and newer gcc
M08-tex.7z

1. Saves all of them in the same folder,
2. Run M08.exe and specify install path (it's a portable installation). Click OK. Correction: If you have conemu instance(s) already run you need to quit all before clicking OK, see Maximus comment.
3. The installer dialog will vanish quickly to bootstrap conemu and continue with extraction. Due to the sheer number of files, the extraction (write to harddisk) will be way slower than what the CPU capable of.
4. Once completed, run conemu.exe to start
5. Moluccas will try to detect any presence of Visual C++ and try to integrate the latest version you have. During first run it also initialize Miktex installation
6. In the end conemu panel will bring the <^> prompt
7. Type spawn to start an instance of conemu. The panel will hide and still accessible via systray icon.

edit:

I will put latest patches and buildscript at https://github.com/tumagonx/pygi-mingw-patches

PyGI 3.10 Windows

In my attempt to update MyPaint I need to update PyGI as well as GTK. During compiling there is worrying result the glib 2.38.1 failed on 7 tests! The tests a bit different from previous versions though (in he past usually it passed all tests). GTK 3.10.2 seems missing def files and the new one isn't look any stabler than 3.6, the usual crashes still there despite major win32 fixes in cairo 1.12.16. Lastly I can't use new bindings (gir/typelib) as it always throw gmem.c overflow error during initialize in addition to that I need to comment PollFD override chunk in gi\overrides\GLib.py. Anyhow the new generated girs will still need diff/merge from those linux version...

So here is the new binaries using older typelibs (from pygi aio 3.4.2). This means no new features at python level, plus bugfixes and probably new bugs in the runtime. Currently only bare gtk included if new typelibs become usable I will add others.

pygi-aio-3.10_win32.7z (python 2.6 unsupported)

EDIT: rev2 and further revisions goes here https://sourceforge.net/p/pygobjectwin32/files

Zenity 3.6.0 Portable

In Windows we can use WSH to interact with console/batch processing task, or for simple case "net send" or "msg" will suffice. Then I found zenity, a modern version of cdialog which curses based.

This tool use GTK as its gui to bridge console I/O with modern dialog window for many purpose. Its template (glade ui) can be customized too. I found it a good match for bash though I haven't try it with batch cmd (I dont see a reason why it won't work).

Here a slightly modified build (make it more Windows way as usual).

http://osspack32.googlecode.com/files/zenity.exe
modified src: http://osspack32.googlecode.com/files/zenity-3.6.0_src.7z

notes:
- consequently as this is static build, no locales/translation included (English only), but it's possible to add
- zenity.ui  is embedded in the executable, to override it put zenity.ui alongside zenity.exe (see source for zenity.ui file)
- icons are different from original version as I force it to be stocked

Enjoy!

Guide/examples are here http://help.gnome.org/users/zenity/stable/index.html.en

Edit:
Hmm I think, I have an example...
"runas" which allow to do "UAC" ala commandline usually assume you know the username of the admin account (as it don't ask you), making it uninteractive. With zenity we could do something like this:

for /f "usebackq" %s in (`zenity --entry --text="This operation need admin account, please enter username:" --hide-text`) do runas /env /noprofile /user:%s "notepad \"D:\dokumen\rahasia.txt\""

Assuming zenity.exe is avaliable in "PATH" such as C:\Windows, above example will popup for username albeit we will then need to type password from runas console, ha ha (for security reason I guess)

Edit:
It turned out to be pointless to make it static build, it still need schema file and icon db for displaying file dialog :( sorry

GTK 3.6.4 DevPack

This is actually just a re-post of PyGI AIO (see main page). Since building PyGI consequently need to build the whole things and that because PyGI have poor documentation (actually it means to be that way, so you're forced to read C documentation instead), so I build the important part of this, devhelp. Which make your life way easier (it's a kind of CHM in concept), then gedit (not my choice of editor though), then for po translation we need gtranslator too and of course glade! Yeah most are not available for Windows yet but now you could try it

There we go, a complete suite guys! BUT this of course really is PyGI oriented. a.k.a all runtime has been linked to msvcr90.dll using my mingw toolchain (special). Basically it will potentially crashed when mixed with generic dll (linked to msvcrt.dll) so you've been warned!, however it you use complete GTK c runtime package from OpenSuSe or Fedora it should work fine.

As usual this build, I think is the most feature complete yet smallest available on the net (OK that's a brave claim ha ha), no really it's (just as all of my build here, is extremely complete one). Ok maybe not smallest as possible cause I use dwarf2 gcc which have redundant debug sections than sjlj.

As you know GTK-3 is still not production ready (I even found 3.6 to be worse than 3.4 in some case). This however should not prevent you to give it a try :)

GI for windows itself is credit to Dieter Verfaillie for his yet uncommitted patch (more than a year ago) which still relevant today, although GIR generation remain unreliable and messy process under Windows. Also thanks to Helge too for pointing many issues.

Downloads:
http://code.google.com/p/osspack32/downloads/list (look for pygi-aio-3.4.2)

Overtime you will (i'm sure you will) encounter binding errors and stuff. You could fix it without having recompile everything. Just edit (say use gedit) the gir file (located in share\gir-1.0) save the edited gir alongside g-ir-compiler and invoke: "g-ir-compiler -o [binding-name].typelib [binding-name].gir" then copy the typelib into site-packages\gtk\lib\girepository-1.0 and overwrite. As a hint you could grab linux gir version and compare the error part.

I also have static build vala 0.18 to join the party though I don't remember anymore why I did that build:
http://code.google.com/p/osspack32/downloads/detail?name=vala-0.18.7z&can=2&q=

Oh yeah I'm getting nearer to release the next Tuma MinGW, it should be the biggest toolchain available too.

MyPaint and PyGI

Got several emails from mypaint users who want to know the progress of windows version. I have tidying up what I left last weekend. I hope you could participate as I lack of time nowadays.

Several days ago a user of gramps (gramps-project.org) put his interest on my PyGI build which motivated me to look at it again after I failed to get it work with mypaint. Last sunday I put new PyGI build which better than previous one (read the comments here), in short it's "somewhat" working but I still find many non-crashing errors and warnings when run Gramps 4.0a3 though. Later I tried it on mypaint and it started! but gave me loads of fatal error messages and crashes. This make me unmotivated again :(

The important thing with GTK 3.6.4 is pressure-sensitive tablet apparently working.

Downloads:
So what we got here?
GTK 3.14.8 = OK
GTK 3.10.x - 3.14.7 = completely broken (no pressure, no lag, just mouse-like) errr
GTK 3.8.x = laggy and imprecise  please compare with gtk 3.6?
GTK 3.6.x = somewhat OK
Reported working tablets = Mostly wacom tablets, Samsung ATIV SmartPC SPen, P-Active XPC-1910A LCD Tablet, Genius Mousepen, Monoprice (need latest driver, see Aroidzap's comment), LE1700 Motion Tablet
Known incompatible = Genius G-Pen

For those who want to use UC-Logic drivers see https://gna.org/bugs/?21864

note: use 7zip 9.x with lzma2 support to extract the archive

MyPaint 1.2.0 released https://github.com/mypaint/mypaint/releases/

mypaint-1.2.0b.7z (GTK 3.14.15 + Anti-Art's experimental brush settings + brushpack + dothiko enhancement, Dec 28, 2015)
mypaint-1.2.0a.7z (GTK 3.14.13 + Anti-Art's experimental brush settings + brushpack , July 3, 2015)
mypaint-1.1.1a.7z (GTK 3.14.9 + Anti-Art's experimental brush settings + brushpack , April 1, 2015)
mypaint-1.1.1a-debug_win32.7z  (GTK 3.14.8 debug, February 11, 2015)
mypaint-1.1.0+git-823aa882.7z (GTK 3.8.9, October 8, 2014)
mypaint-1.1.0+git-e06d414_rev2.7z (GTK 3.8.9, March 25, 2014)
mypaint-1.1.0+git-e06d414.7z (GTK 3.8.9, March 21, 2014)
mypaint.exe (GTK 3.6.4, December 14, 2013) Single exe, Can be manually associated wih ora, Missing icon fxed, Try tahoma font (unicode compatibility?), Enable lot more file formats to import (gdk-pixbuf testing)
mypaint-171113_3.7z (GTK 3.6.4, December 05, 2013) Try to optimize more
mypaint-171113_2.7z (GTK 3.10.4, November 17, 2013) Confirm that tablet doesn't work?
mypaint-171113.7z (GTK 3.8.6, November 17, 2013) MRU and lag workaround
mypaint-161113.7z (GTK 3.8.6, November 16, 2013)
mypaint-121013.7z (GTK 3.6.4, October 12, 2013)
mypaint_270113git_dbg_rev2.7z (old)

Please give comments at http://forum.intilinux.com/mypaint-general-discussion/mypaint-1-1-for-windows/

Some info that might be useful when reporting bugs:

blockers:
lag+break bugreport (if you find something new please post at the bugtracker to let mypaint devs know)
zoom bug, currently unreported as this is a packaging issue (will be irrelevant)

specs:
mypaint 1.1.0+git
python 2.7.5
pygtk 2.24.0
pygobject 2.28.6
pycairo 1.10.0
psyco 2.0
numpy 1.8.0rc2
pygi/pygobject 3.4.2
gobject introspection 1.34.2
gtk+ 2.24.14
gtk+ 3.6.4
atk 2.6.0
cairo 1.12.10
pango 1.32.6
glib 2.38.1
gdk-pixbuf 2.26.4

Inside the 7zip file contains:
mypaint_gtk2.bat -> run mypaint in GTK2/PyGTK mode
mypaint_gtk2_debug.bat -> run mypaint in GTK2/PyGTK mode under GDB session
mypaint_gtk3.bat -> run mypaint in GTK3/PyGI mode
mypaint_gtk3_debug.bat -> run mypaint in GTK3/PyGI mode  under GDB session

How to help?
- Report your tablet name, pressure sensitivity status, not just "it works" or "it doesn't work" or "it slow". Read comments below here, someone may give direction which driver to download.
- If you're user who use both Linux and Windows, try GTK2 and GTK3 and tells mypaint's devs if you spot a misbehaving of Windows' version.
- Tell mypaint's devs your suggestion to make Windows' version better.

Enjoy and Thank You!
More info about participating MyPaint development can be found at http://mypaint.intilinux.com/?page_id=18

A Peek at MyPaint on Windows...

Not exactly what I want to write, but I have skipped the whole month now. Last weekend I tried latest mypaint and things are out of my reach. I couldn't build it normally at all and quite lost in the scons scripts but nonetheless I managed to made it. Still http://gna.org/bugs/?19948 (I'd personally call this release blocker for Windows) is here to stay. I try read the commits which trigger this windows specific bug but it seems to be a part of larger internal changes in mypaint.

So guys it would be nice if someone step up and fix this annoying bug, your help is greatly appreciated!

mypaint

Sorry about the lame void in the shot (gosh that's XP still living?), I have made some nice technical sketches but when I hit F10 (resize to fir) all my drawing has lost in space. Current MyPaint get basic pseudo-vector ability which great for prototyping, symmetry mode and more supported colorspace. Actually there is several performance-related experimental features that can be enabled but I'm not getting there at the moment.

About the future of MyPaint well this is just an opinion, a speculation from experience. With MyPaint migrate to gtk-3 thus using pygi (and possibly python-3), It would be most tedious migration I've ever seen before for Windows platform, I meant where is PyGI now? Not even a release yet... and GTK-3? usable but not ready. Lets just hope Windows get some priority in the upstream sooner.

The dreaded question is how gtk-3 handle tablet this time? with gtk-2 there are many users complaining about their tablet which likely gdk<->wintab issue and since gtk is a gnome project (a dominant linux GUI), priority for other platform is somewhat lower than other cross-platform GUI. In the past decent releases has been fewer too. From interface point of view, last time I checked (gtk 3.4.4), it's already native themed but I can't made it work with mypaint since my experimental pygi build can't deal with gtkbuilder (maybe because I use 64bit off_t and time_t which is ABI breaking?). Anyway it still a bit early for pygi in windows...

This build here is a manual build and unlikely I will maintain that build environment anymore.

MyPaint_011212git.7z

Test and report bugs! your reports are very valuable in the release process, I believe the lag bug is workaround-able.

Static library attempt for GTK

In my previous post when I had to make rsvg-view a static build, a complete set of static GTK libraries needed. GTK known to refuse being build as static library on Windows. Obviously there is lot good reason (be it Windows or not), GTK is a library with lots of addons (theoretically a GLib based one) so a modular/extensible approach chosen, then if I recall internationalization won't work unless in dll mode, then GTK is known using lot of settings files and modules scattered in etc-lib-share folder, then in version 3 there is DBus stuff which all of these make it almost a deal breaker for static build mode. Although some modules (found in pango, gdk-pixbuf, gtk) can be statically linked to main library, others are not (need modification) such as wimp theme engine.

For this minimalistic use case (rsvg-view) where basically a window with just 2 zoom buttons, a static build would be nice eh?

Oh well let's just get it on...
Firstly this is GTK-3 that I tried which should prompt a serious warning message about stability/maturity. Historically in version 2.x IMO there is only 3 stable, good or sane version for Windows: the last 2.12.x, 2.16.x and 2.24.x. I did try make static GTK-2 (2.24.10) however almost all but three tests mysteriously crashed during startup, here is one of that survived: testtreecolumns (unfortunately not LTO optimized so it's a bit too big)

The main thing that prevented static linking is multiple definition of dllmain. In case you're not aware, GLib starting with 2.30 support static build but broken in 2.32 since glib-init introduced but is trivial to fix. So based on how this static glib work we could also do the same to gdk-pixbuf, pango and lastly to gtk itself:

- override the Windows guard in configure script which prevent static build. hint: "DLL on Windows"
- make sure all possible and desired modules being "bundled" via configure
- initialize hmodule instances as null instead of uninitialized
- prevent dllmain from being compiled by adding #ifndef DLL_EXPORT
- assign declspec instances as nothing when #ifndef DLL_EXPORT (or create your own guard) instead of dllimport/dllexport (seems GTK-3 somehow omit this already)

note: DLL_EXPORT and PIC are common flags used by libtool during compilation, they are off when configured with: --enable-static --disable-shared

This way, path finding and internationalization still works as expected. Here is example of gtk3-demo in static binary: gtk3-demo.7z

It would great to bundling it in my MinGW distro... kinda rare to see C-based GUI library, not that C is good for GUI

SVG viewer for Windows

I'm looking for a simple svg viewer for which can be invoked from command line and found some candidates:

- SVG Viewer from QT 4.8.2's example (3 MB)
- SVG test from AGG 2.5's demo (178 KB)
- RSVG View from librsvg (2 MB, explicitly need file input, otherwise will silently quit)

It should be static(standalone) as usual, preferably small and must be fast. Both from RSVG and QT are quite capable and compliant (by far compared to AGG). There is a performance issue with QT though when SVG is fairly complex, where panning and zooming become very slow despite snappy once switched to OpenGL mode. RSVG didn't have this issue and load faster but since it use static build (an unsupported mode in Windows) of GTK-3.4.4 which still not stable for Windows, is unfortunately quite a crasher, also didn't resize its window automatically.

There is one more (better) candidate from Batik's Squiggle but probably too big when compiled and too GUI-ish for a simple viewer. Finally every "sane" modern browser also SVG viewer capable :-)

Testing WebkitGTK3 1.6.3 Win32

This is a test using the supplied GTKLauncher with default settings, I have done most of these tests a year ago and found few workaround but mostly remain the same now.

Core components:
WebkitGTK 1.6.3
GTK+ 3.3.6 using adwaita theme
libsoup 2.37.3

Issue 1. 50% resources hog

When opening certain pages (in this case google.co.jp) browser will eat up 50% resources (my system is dual core).
Workaround: unfocus the window (you kidding me? that's not workaround)


Issue 2. Unicode glib, fontconfig and pango aliases.

Under Linux, baidu.com reportedly okay (glib backend) while becoming like this under windows, anyone knows why?

Workaround: build webkitgtk against ICU instead of glib, above is webkitgtk 1.2.7 with ICU (gtk2)

Wikipedia.org shown with freetype backend and default etc\fonts\fonts.conf

With freetype backend and modified etc\fonts\fonts.conf (add autohint, antialias and set tahoma as default). Here most indic languages is back, under windows 7 and pango 1.29 this should rendered near perfect like below but fonts.conf need to be set to segoe ui. Also notice dropdown list widget above is now properly rendered in GTK-3

With modified fonts.conf and modified pango.aliases (due to limitation in Win XP) also need additional unicode fonts.


Issue 3. Local file URI

Regression: webkitgtk 1.6.3 can't open windows' file URI see wikipedia, other schemes also failed

Here is how version 1.6.3 treat the triple slashed URI, it's like opening "/D:/Sources/webkit-1.6.3/html/index.html"

Application like Devhelp also affected

Webkitgtk 1.2.7 (GTK-2) correctly open local files


Issue 4. GCC miscompiles JavaScriptCore
When compiled against win32 api from mingw-w64, for example webkitgtk produce the following anomalies:

Numbered list stopped after 9th...?

Google top menu not shown in black

Workaround: use mingw32 or find the culprit?

Issue 5. Video

With gstdirectsoundsink and gstautodetect from gst-plugins-good webkitgtk3 also could play html5 video canvas and compared to 1.2.7 there is time lapse info. But other issue still the same: once volume muted sound will gone forever. Notice that fullscreen mode doesn't work in Windows so don't clicked it.

Issue 6. Printing doesn't work properly

Webkitgtk seemed to print with correct outer frame width (fitted?) and anything else is scaled down by approximately 8 times (thanks to Pawel for the report). Not an issue under linux.

Workaround: scaling up before printing

Issue 7. No plugins

And that's what youtube said

Okay that's enough with the problems :-)

Good :-)

Notes: If anyone encountered Mutex (pthreads) issue during building try to use https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/experimental/winpthreads/

PyGObject 3.0.3 MinGW

About a year ago I made a big but messy conservative PyGTK AIO now it's time for experimental stuff :-)
After testing GTK-3.3.6, I think they are much closer to a "usable" stage in win32 port. So why don't we try that in python...

Technically this pygobject-3.0.3 is more like pygi in the inside and IMO "PyGI" sounds cooler too ah well..

Here is win32 binary pygobject and pycairo for python 3.2
Downloads: http://opensourcepack.blogspot.com/p/pygobject-pygi-aio.html

Changelog:
24-01-12 Added WebkitGTK3 1.7.4 very unstable due to unstable Glib
20-01-12 Added WebkitGTK3 1.6.1 very unstable due to unstable Glib, added Clutter-1.8.2 and MX-1.4.1
17-01-12 Added GTK3 3.3.6 with broadway and Glade. to use broadway set environment variables: GDK_BACKEND=broadway and BROADWAY_DISPLAY=[some port number]

AIO runtimes for GI, GTK, Clutter/MX, Webkit, Gstreamer, GDA and Telepathy are planned later as well as supplementary apps like Glade-3 and Gtranslator.  And if I in mood maybe a win64 binary too, however installer are not planned (I'm tired of NSIS)

I already played with MX and whooah you should try this OpenGL (bitmap/css skinnable) GUI library! it's very cool, as sleek as QtQuick!

notes:
be warned that this is mingw binaries, I'll assume you know the potential issues. Last weekend I've tried to compile python 3.2 with WDK (the infamous msvcrt.dll linking trick) the whole night but given up after several unreferenced functions. OTOH tried to compile the whole GTK3 with mingw against msvcr90 but also failed.

GTK 3.3.6 GDK Test

Today I give a try on latest gtk3 (3.3.6) which according its changelog have some win32 bugfixes.
During configure I also enable GDK broadway! with a little replacement: sys/socket.h -> winsock2.h in several c files and add missing brodway function exports in gdk.symbols (patch). Also don't forget to create etc\gtk-3.0\settings.ini and fill it with at least:
[Settings]
gtk-theme-name = MS-Windows

Sadly native theme still broken.. and redraw issue like in GTK 3.0 also prevails :-(
Goodness that pango's win32 module is back so I can give a screenshot :-)

Below is two instances of gtk3-demo, one running broadway inside webkitgtk 1.6.1 (require html5 websocket) browser (two windows with oversized "x" button) and other one is the ordinary win32 backend.

Both demonstrating pixbuf animation, however the one in webkit runs very slow and webkit process hog 50% CPU during the animation :-( anyway that's one cool remote display we got here!

edit:
http://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00050.html explain the broadway win32 situation better.
Almost forgot, pygi (pygobject 3.0.3) also works too:

this was run on python 3.2

GTK3 adwaita theme engine (in gtk3-theme-standard package) can be used instead before windows native theme fixed.

PyGTK 2.24.0 GTK+-2.24.8 AIO 64bit

Portable minimal 64bit PyGTK 2.24.0 with numpy (download the unoptimized one) support, without freetype, without libglade (don't confuse it with gtkbuilder) and without libffi. This one bundled with GTK+ 2.24.8 with new icons and cairo patch. Built using mingw-w64 gcc 4.6.2.

To install just extract to site-packages folder of python 2.6.x 64bit and you're ready to go.

pygtk-2.24.0-win64-AIO-minimal.7z

enjoy!

GTK+ 2.24.8, Finally a proper successor to 2.16.6

Finally a bright future for MyPaint! (as well as Gimp and Inkscape I believe), a major bugfixes release has landed. See datails here http://ftp.acc.umu.se/pub/gnome/sources/gtk+/2.24/gtk+-2.24.8.news

All (most?) dreaded GUI and behavior issues have been swept :) tablet issues such as pressure and tilt also fixed. Hopefully they will bring GTK+ 3.x to the same level for Windows too.

MyPaint will use GTK+ 2.24.8 for the upcoming and long awaited 1.0 release! yay!

Building PyGTK for MyPaint

Continued from here. MyPaint require that PyGTK (GDK) to support numpy otherwise mypaint won't run. The debate is people said that the proper way to build python module is by using MSVC compiler since that's what python windows used with. While there is officially a library for GCC named libpythonXY.a some argue how stable a mixed build is.

IMHO gtk binding is bridging python and GTK, so what's the point using MSVC if GTK Runtime was build with GCC(MinGW)? Nah that's just my excuse because I don't know how to build it with MSVC :)

I've tested that I can use MinGW's pygtk with MSVC's pygobject with MinGW's GTK with MSVC's Python 2.6 and MinGW's MyPaint.... errr

Alright lets make it all MinGW's except for python shall we:

Building GTK2 for MyPaint Windows

This post explain more detailed Windows port of MyPaint situation. I hope my english is understandable :)


MyPaint, the package

• In windows mypaint use py2exe for bootstrapping and bundling with minor change in favor mypaint's builtin logging.
• Mypaint is currently targeted only for win32, win64 is in experimental stage
• Mypaint consist of a small portion of C++ library (which is why it need to be compiled) and the rest is in pure python. Mypaint require pygtk (with numpy support), numpy, GTK and optionally a particular version of psyco (a python accelerator)
• Mypaint is squeezed! I kind of proud with this :) I have made mypaint stay around 8MB since version 0.7. All executable is packed with UPX at brute level. Furthermore brushes preview images have been pngcrush'ed.
• Mypaint installer use NSIS with solid lzma compression. I believe this should be changed to msi

GTK 3.2 still not quite there...

In my last quick review GTK seems take major change from 2.x (or it was just old windows specific bugs?). With version 3.2 from last September, things a little bit sketchy and raw now which I do not even dare to post a screenshot. Some issues that I quickly spot (from gtk3-demo):

- It's surprising that Glib 2.30's "make check" fail in almost all tests using GCC 4.3 but build successfully with GCC 4.6.
- Pango's win32 module (2.29.4) is broken so we got no text.. umm no glyph
- GTK native win32 theme still broken too (oh yeah that's important aesthetic aspect)
- DnD not working
- Problem with clipboard? pasting empty data trigger crash...
- The dreaded gdk window toplevel issue is still there.. So I doubt if tablet is working.. too bad for MyPaint

I'm not sure if most of them were windows specific or not...

The good news is gobject introspection (1.30) is almost there, I can build it but I'm stuck with gir generation. This is cool! ever since pygi merged in pygobject, the new win32 pygobject is meaningless cause pygi isn't there. With pygobject 3.0 and proper pygi in near future (hopefully) we can finally say goodbye to pygtk and other bindings and bring python 3.x too. But right now it's not quite there...

GTK+ 3.0 Win32, not quite there

While GTK+ 3.0 has been around for almost 2 months it lacked many bugfixes from GTK+ 2.22. As a result it looked more like GTK+ 2.18 with new packed features. Below is the not so new feature  (GTK+ 2.21?) of tool palette, actually there is a lot more but most aren't available in demo yet.

flickering issue in GTK+ 3.0 Win32