RE: What does "(skip)" mean ???

[Fan, Chun-wei via gtk-devel-list]

Hi John,

Note that since a few release series ago we stopped using .symbol files to 
export symbols but instead use a __declspec(dllexport) approach to export them.

See config.h.win32.in in your checkout in the _GLIB_EXTERN part—if it is not 
defined in your build files, define it as it is in config.h.win32.in, and 
things should do.

With blessings, and cheers!

從 Windows 10 手機傳送

寄件者: John Emmas via gtk-devel-list
傳送時間: 2017年4月17日 20:47
副本: GTK Devel List
主旨: Re: What does "(skip)" mean ???

On 17/04/2017 12:16, John Emmas via gtk-devel-list wrote:
>
> my VS8 projects seem to use ".symbols" files for determining what gets 
> exported from the built DLLs.  I can't remember why I needed to do 
> that but I probably just need to amend them - or hopefully find a way 
> to stop using them now!
>

Yes - that was it.!  My ".symbols" file was getting converted into 
module definition files (".def" files).  The file was very subtly 
different for a Debug build compared to a Release build.  It looks like 
the difference was due to this function:-

   g_slice_debug_tree_statistics()

 From what I can tell, it's only supposed to be relevant in a Debug 
build.  But there must have been a time when it was somehow getting 
included in a Release build (and presumably causing some kind of 
problem).  My ".def" file just made sure that it didn't get exported 
when it wasn't needed.

Anyway... whatever the problem was, it looks like it eventually got 
fixed and I can now get rid of my def/symbols files..  Sorry for the noise.

John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

FW: multitouch support for Windows

[Fan, Chun-wei via gtk-devel-list]

(Sorry, I forgot to reply to the list)

從 Windows 10 手機傳送

寄件者: fanc...@yahoo.com.tw
傳送時間: 2016年12月29日 13:29
收件者: Yale Zhang
主旨: RE: multitouch support for Windows

Hi Yale,

This sounds quite nice.  Can you go to https://bugzilla.gnome.org and submit a 
bug there, so that someone here can take a look at your patch, so that things 
don’t get lost in the mail list.

With blessings, thank you, and cheers!

從 Windows 10 手機傳送

寄件者: Yale Zhang
傳送時間: 2016年12月29日 11:58
收件者: gtk-devel-list@gnome.org; vincar...@gmail.com
主旨: multitouch support for Windows

Greetings, I have a patch that adds the plumbing for multitouch
support on Windows.

I've tested it on testinput and the gesture demo, and they behave correctly.
I also fixed some problems with pressure pen (Wintab) support. The
tablet devices weren't showing up when calling gdk_seat_get_slaves(),
probably because it associated the wrong devices.

I'm using this for 2 finger gesture recognition in Inkscape for
zooming, scrolling, and rotating the canvas.

https://www.youtube.com/watch?v=k6qfqcroUcw


Vincenzo, you were complaining about this earlier:

https://mail.gnome.org/archives/gtk-app-devel-list/2015-July/msg00030.html

did you want to try my patch? Anyone else who can review and check in
my changes?

-Yale


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

RE: Gtk+4.x and broadway ( and other remote options )

[Fan, Chun-wei via gtk-devel-list]

Hi Daniel,

The main issue with Broadway is that:

It is considered an experimental GDK backend, and it is not really kept up to 
date with the developments in GTK-3.x

Specifically what this means is that there isn’t OpenGL support in it (we need 
OS/platform-level support for OpenGL for creating and switching (making 
current) OpenGL contexts), which likely needs to be done with WebGL, which most 
probably needs to be done in the .js file in the broadway subdir in gdk/.  
GTK+-4.x is going to switch to GL drawing, at least for the majority of the 
various components, which makes OpenGL support a requirement.

AFAIK, the backends that have the needed support are x11, Wayland, mir and 
Windows.

If you know how to do initialize OpenGL in WebGL (ie Javascript), please let 
the people know here, as this is what I think is mainly what needed for 
Broadway to stay.

With blessings, and cheers!

從 Windows 10 手機傳送

寄件者: Daniel Kasak
傳送時間: 2016年12月7日 11:18
收件者: GTK Devel List
主旨: Gtk+4.x and broadway ( and other remote options )

Hi all.

I posting here in response to comments on bug:
https://bugzilla.gnome.org/show_bug.cgi?id=775680 ( summary: broadway
support likely to be removed from Gtk+4.0 ).

I think it would be a massive pity to drop broadway support from gtk.
It's been a god-send for me and those I work with - it provides the
best remote access to gtk apps and performs way better than vnc. I've
actually been working on an authentication + transparent proxy for
broadway, so multiple users can access multiple apps all via https on
port 443: 
https://tesla.duckdns.org/transparent-proxy-for-broadway-gtk3-html5-backend/

I've dabbled in C here and there ( mainly patching minor bugs ). It's
been quite a long time since I used it at all. However I'm interested
in attempting to keep broadway support alive. I currently develop gtk
apps ( every day ) using the Perl bindings. So I'm familiar with it
from an application-developer perspective.

I have no idea how big/complex a task it is I'm talking about. Could
someone please comment on the difficulty of keeping broadway support
working, given the planned gtk+4.x changes. I guess this would be
easier if someone offers to mentor me ( please ) - though I realise we
all have busy lives.

Another option, if the task is too large or difficult for me, is to
either offer a bounty here, or to post a project on something like
freelancer. I also realise that work done via freelancer would
possibly be of questionable quality, and would quite possibly break
with later gtk+ versions again. Any comments on this option?

Another option would be another remote-desktop / remote-app
capability. I've read a little on wayland / weston and RDP. I think
RDP would be a reasonable option, though haven't managed to get it
working yet.

What does everyone think my best options are, and why?

Dan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

RE: libgio (recently added source files)

[Fan, Chun-wei]

Hi John,

Short answer is no.  These are for flatpak/portal, which is for *NIX only.

With blessings.

從 Windows 10 手機傳送

寄件者: John Emmas___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

RE: Unknown symbol in 'gio/gresource.c'

[Fan, Chun-wei]

Hi,

To fix this, we could just use g_file_test (fullname, G_FILE_TEST_IS_DIR) in 
place of the whole check that is there.

With blessings, and cheers!

從 Windows 10 手機傳送

寄件者: LRN
傳送時間: 2016年5月2日 下午 08:22
收件者: gtk-devel-list@gnome.org
副本: Fan, Chun-wei (范君維)
主旨: Re: Unknown symbol in 'gio/gresource.c'

On 02.05.2016 14:36, John Emmas wrote:
> I just hit a problem when building from git master with MSVC (32-bit 
> build). 
> 
> 'S_ISDIR' is coming up as an unknown symbol. 

fanc, care to comment?


-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

回覆: Missing #include from glib/gwin32.c ?

[Fan, Chun-wei]

Hi John,

I think winternl.h is a good bet as well.  It is used elsewhere as well in the 
code.

With blessings.  Sorry for the noise from the earlier email.
---
Hi Victor,

Can you see whether winternl.h works for you?
---
With blessings, thank you.
 

- 原始郵件 -
寄件者: "John Emmas" 
寄件日期: ‎2015/‎10/‎16 22:59
副本: "gtk-devel-list" 
主旨: Re: Missing #include from glib/gwin32.c ?

On 16/10/2015 15:21, Victor Aurélio Santos wrote:
>
> Apparently at ntdef.h, try that I didn't tested.
>

Hi Victor and thanks for the quick reply.

I think ntdef.h might be MinGW specific (I can't find it in MSVC) but 
after a bit of experimenting I found 4 other header files which fix the 
problem (if I #include any of them).  The 2 most promising are probably:-

 #include   -  or
 #include 

and these two also work:-

 #include   -  or
 #include 

Conversely of course, it's possible that some of those might be MSVC 
specific and not applicable to MinGW!  Maybe Chun-wei Fan will be able 
to help us if he's around later.  Thanks again.

John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

回覆: Missing #include from glib/gwin32.c ?

[Fan, Chun-wei]

Hi John,

Can I know what is the Windows SDK you are using?  Most probably the SDK you 
are using is too old.  If upgrading the SDK is not an option, you will have to 
define NTSTATUS as LONG (or let me know).

With blessings.

- 原始郵件 -
寄件者: "John Emmas" 
寄件日期: ‎2015/‎10/‎16 21:23
收件者: "gtk-devel-list" 
主旨: Missing #include from glib/gwin32.c ?

I just updated glib (from git) and tried to build the glib-2-44 branch, 
using MSVC8.  I'm getting a compiler error at line 568 which looks like 
this:-

   typedef NTSTATUS fRtlGetVersion (PRTL_OSVERSIONINFOEXW);

Basically, my compiler doesn't recognise NTSTATUS.  If I substitute LONG 
instead of NTSTATUS, everything builds okay, so I'm assuming there's a 
missing #include.  I tried #including  and when that didn't 
work, I tried #include  (but that didn't work either).

Can anyone advise me what needs to get #included in order for NTSTATUS 
to get recognised?  Thanks.

John
P.S. I assume the same problem might also exist in 'master' although I 
haven't had a chance to try that yet.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

回覆: MSVC build error in gdk-pixbuf

[Fan, Chun-wei]

Hi Bastien,

Thanks for the great tip and reminder.
I have just reopened the bug.

With blessings, thank you!

- 原始郵件 -
寄件者: "Bastien Nocera" <had...@hadess.net>
寄件日期: ‎2015/‎9/‎11 19:00
收件者: "Fan, Chun-wei (范君維)" <fanc...@yahoo.com.tw>; "John Emmas" 
<john...@tiscali.co.uk>; "gtk-devel-list" <gtk-devel-list@gnome.org>
主旨: Re: MSVC build error in gdk-pixbuf

On Fri, 2015-09-11 at 18:22 +0800, Fan, Chun-wei (范君維) wrote:
> Hi Bastien and John,
> 
> In fact, I have a patch for this at bug 734556 comment 7, because the
> change that brought about this issue was from that bug.
> 
> With blessings, thank you!

Don't leave patches in closed bugs. Re-open it, or file a new one if
you don't have the rights to do that.

Commenting on closed bugs is probably the best way for the fixes and
comments to be ignored/lost.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

回覆: Outdated win32 bundle

[Fan, Chun-wei]

Hi,

As Nacho mentioned in his earlier email on this topic free days ago, there is a 
bug in the introspection part that is working on getting introspection to work 
better on Windows, 728313, which I checked lady week the patches there still 
applies to the latest git master, which is still pending further review, and it 
should make introspection more portable, by using items from python 
itself(namely, distutils)

I am also working on a master solution file which contains various msvc 
projects that will build the dependencies of the GTK+ and GTK+ itself (2.x and 
3.x).  This is still wip, at github.com/fanc999/gtk-msvc-projects, and I will 
let people know when it's ready for use.

With blessings.

- 原始郵件 -
寄件者: Emmanuele Bassi eba...@gmail.com
寄件日期: ‎2015/‎6/‎19 07:24
收件者: Daniel Kasak d.j.kasak...@gmail.com
副本: Gian Mario Tagliaretti g.tagliare...@gmail.com; GTK Devel List 
gtk-devel-list@gnome.org; anatoly techtonik techto...@gmail.com; ML-gtk 
gtk-l...@gnome.org
主旨: Re: Outdated win32 bundle

Hi;

sorry to use Daniel's email, but since this thread keeps growing, I'm
just using the latest entry point to try and give some actionable
items.

It's all well and good that everybody has their own builds, and
packages, and installers — and I mean it: it's great to see so much
activity around GTK on Windows. Now, if only that translated to more
contributions to the backend code… *wink* *wink* *nudge* *nudge* ;-)

While people doing their own builds is great, I'm still going to ask
for one thing: please, help out setting up an automated builder that
takes the GTK git repository and builds it with the Windows backend.
Running the test suite would even be amazing, but I'd settle for
verifying that commits do not break the Windows backend.

Seriously: if you are an app developer that already has a build
environment for GTK, then you're already set. You don't have to change
anything in your workflow — though you'll be advantaged by a
continuous integration system that at least verifies that each release
of GTK builds on Windows (and possibly does not regress, any more that
it may regress on Linux).

The GTK team does not, currently, have the capacity to set up this CI
system. Nor it has the capacity for building binary distributions of
the libraries for Windows. That's why my strong suggestion, after
speaking with the people that are *actually* working on the Windows
backend — namely Ignacio and LRN — is to concentrate efforts in the
infrastructure to verify that the Windows backend does not break with
every release, or every commit. Application developers relying on a
binary distribution coming from gtk.org in the past have different
options for getting a replacement — they have been listed in this
thread. If you want to help the GTK in improving the Windows support
then you can:

 * work on the infrastructure, in a way that can be automated and
maintained even if you happen to leave the project
 * work on the Windows backend itself, by triaging old and new bugs;
fixing them; catching regressions during the development cycle; or
implementing new features
 * work on improving jhbuild use on Windows
 * work on improving introspection on Windows

These options are not mutually exclusive; they are *all* important.

So, let's try and get to something actionable. Can somebody try and
set up a CI for GTK that either cross-compiles GTK or compiles it
natively? Both aspects are important — as Daniel pointed out,
cross-compiling the introspection data is currently not possible, so
that leaves out dynamic languages like Python, JavaScript, and Perl;
plus, it does not allow us to run the test suite. Cross-compilation is
fine for an auto-builder that verifies that commits are not breaking
the build on Windows, which is a good start.

Another actionable point: helping out triaging the Windows-related
bugs on Bugzilla. What's still relevant? What's obsolete? If there are
patches, are those still applicable, or can they be rebased? Does a
bug filed against GTK 2.x still affect GTK 3.x?

Is anybody willing to help out Ignacio and LRN with the missing
functionality of the Windows backend?

What about jhbuild? Can somebody set it up on Windows and file bugs
whenever something breaks?

Ciao,
 Emmanuele.


On 18 June 2015 at 23:49, Daniel Kasak d.j.kasak...@gmail.com wrote:
 Hi all. I've got my own builds of Gtk+ for Windows, available at:
 http://tesla.duckdns.org/jewelkit-1-0-released/ ( I have another build
 I'm ready to upload in the next week actually ).

 This contains perl as well as Gtk+. I make regular releases (
 currently ). I also have a bunch of patches I've been meaning to
 submit ( fixing build issues ). In particular, the object
 introspection stuff is a MAJOR PITA to build on Windows, and AFAIK is
 impossible to build in Linux with a cross-compiler.

 It would be fantastic if building Gtk+ ( and bindings ) on Windows
 were far less painful ... and better yet if there were official
 installers ... though I 

Re: Using Python v3.3 while building Glib

[Fan, Chun-wei (范君維)]

Hi John,

John Emmas 於 2015/5/13 下午 04:34 寫道:
1)  For historical reasons we need to build with VC8.  That's rarely 
supported now in gtk+ libs.


Yeah, I understand this as I maintain the Visual Studio files, it's hard 
to come by with Visual Studio 2005 legally cheaply nowadays (read: 
Express).  So couldn't help with that...sorry.
I do make sure from time to time that things build with 2008 though, as 
things should more or less be the same on 2005 for the C situation.  For 
instance, when GTK+ was in the GTK+ 3.16 dev cycle, the GDKGL support 
for Windows was done with Visual Studio 2008 (and checked with the later 
versions).



c)  Debuggable Release version
It might seem like a luxury to have a debuggable Release build - but 
in fact it can be immensely useful.
I agree.  I had in the 2008-2013 projects where we now install the 
.pdb files for all builds, at least for the GNOME ones.  Visual Studio, 
for at least 2008 and later, defaults to a debuggable release build for 
Release configs when you create a project.


I am currently working on github for enabling the GTK+ stack to be 
buildable on a stock Visual Studio 2008-2013 installation out-of-the-box 
from scratch (which also includes .pdb's for all of the stack), in case 
you are interested.  The 2008 projects should not be that much different 
from the 2005 ones, in terms of format.


https://github.com/fanc999/gtk-msvc-projects

I just recently had gettext, with the tools that work on Windows, 
building with Visual Studio, using patches and MSVC projects.  I intend 
to support both GTK+-2.24.x and GTK-3.x with this all-in-one build 
mechanism, as they can co-exist from the current state of the Visual 
Studio projects.


---

From your other e-mail:
Just out of interest - what do you do about all the stuff that needs 
to get auto-generated?  aliasdefs / marshalers / gtktypebuiltins / 
gdkenumtypes / gdbus stuff etc, etc?  There's quite a lot of 
auto-generation in the normal 'C' libraries but it becomes a nightmare 
once you get to the C++ libs (glibmm / gtkmm etc, etc).  I guess one 
nice thing about my builds is that they take care of all this stuff 
automatically.


Hmm, since Nacho's nice-software wotk is derived from the MSVC project 
files upstream, this is my say...


The thing is, since the project files upstream build items from a 
release tarball, there aren't rules (i.e. Custom Build Steps) for 
generating them, unless they are not provided with the release tarball.  
This means, from what I do in the projects, I used custom build steps in 
conjunction with the property sheets, although not that elegant in the 
projects, but does the job well for generating the files that are 
necessary, and cleaning them up, and re-generating if necessary.


With blessings!

p.s. I will work on getting the libepoxy items upstream again, ASAP, by 
splitting the patches I had up there.  This work was delayed as my hard 
disk broke and I decided to re-do the build items.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 3.16.0 released

[Fan Chun-wei]

Hi Matthias,

I thought it would also be good to let people know about this, rendering 
windows using OpenGL is also implemented on Microsoft Windows as well, 
also using libepoxy.


(I didn't reply to the announcement list though-sorry if this response 
is inappropriate in any way.:))


With blessings, thank you!

Matthias Clasen 於 2015/3/23 10:53 寫道:

GTK+ 3.16.0 is now available for download at:
...
What's new in 3.16
==

Major new features include:

* GDK supports rendering windows using OpenGL; currently
   this is implemented for X11 and Wayland using libepoxy

* GtkGLArea is a new widget for rendering with OpenGL


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GWin32WinsockFuncs and other stuff

[Fan Chun-wei]

Hello John,

It seems that your compiler does not know what is NET_IFINDEX...can you 
try to add a define (i.e. preprocessor definitions) to your GIO 
project files defining NET_IFINDEX to ULONG (as that is what I see in my 
SDK 7.0 includes), and try the build again?  Apparently that is 
something introduced with Visual Studio 2008 (Windows SDK 7.0) and 
later-perhaps can you do a search in your Visual Studio SDK includes and 
look for NET_IFINDEX?


With blessings.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: libglib - Newly introduced build issue with MSVC8

[Fan Chun-wei]

Hello John,

Can you apply the 2 patches in bug 743640 titled:

gmacros.h: Add Private Macro for use in gtype.h to conditionally define items
for __attribute__((cleanup)) on GCC only

gtype.h: Fix G_DECLARE_FINAL_TYPE and G_DECLARE_DERIVABLE_TYPE definitions on
non-GCC

and see whether the build works for you?

(The patch in bug 743827, if not yet applied, is also needed, as Ryan 
mentioned.)

With blesings, thank you!

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: File monitor rewrite: Solaris (and other) help wanted

[Fan Chun-wei]

Hi,

I think I can also take a look at the Windows backend for this as well, 
since we are actually using the same Windows API for monitoring file and 
directory changes, ReadDirectoryChangesW(), as I was trying to get file 
monitoring to work on Windows in bug 730116 a while ago (we only had 
directory monitoring for Windows-probably that bug would go obsolete as 
a result).


With blessings.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: File monitor rewrite: Solaris (and other) help wanted

[Fan Chun-wei]

Hi,

Fan Chun-wei 於 2015/1/15 08:13 寫道:

...bug 730116


Perhaps, since this will cover the work for adding file monitoring 
support for Windows, I am making bug 730116 the tracking bug for this 
drive for the file monitor rewrite for Windows, to let people know.


With blessings, thank you!

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Should We Start Dropping Windows XP Support?

[Fan Chun-wei]

Hi,

Happy Holidays and Happy New Year!

I understand that this has been brought up before, but I think probably 
it's time to gather views on whether we should start to drop XP support, as:


-There are some things that required specialized implementations for XP, 
for example, SRWLock in GLib and networking items in GIO, which may or 
may not work well.
 (for example, by using inet_pton() directly in ginetaddress.c for 
Windows Vista and later enabled many of the network-address.c tests to pass)
-We often needed to do GetProcAddress() to check the availability of 
system-level funtionalities, which would probably need a clean-up.
-As people may know, Microsoft ended support for XP this past April, and 
it is found that maintaining support for XP is becoming a bigger and 
bigger maintenance burden.
-There is likely the need to move forward to use newer system APIs and 
features, which were only available after XP (such as desktop/window 
composition)

-Other reasons that people might bring up for this.

I understand that it might be late in this dev cycle to drop XP support, 
but I do hope to do it (or at least take part in it) in the next cycle, 
so I am writing here to see how people think about this before going 
into this.


Any insight into this part would be really appreciated.

With blessings, thank you!


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building gdk-pixbuf loaders as static libs

[Fan Chun-wei]

Hello John,

The Visual Studio 2008+ builds (in build\win32) do that, so let's take a 
look in build\win32\vs9\gdk-pixbuf-build-defines.vsprops in your git 
checkout:


Find the tags parts that is like GDIP_MACROS, NOGDIP_MACROS and 
MODULAR_MACROS, you will see a bunch of INCLUDE_xxx's there where xxx is 
the module that you want to build directly into your GDK-Pixbuf DLL 
build.  Normally you would want to

include modules as much as possible in your build, but note the following:

-For INCLUDE_png, INCLUDE_jasper, INCLUDE_jpeg, INCLUDE_tiff you will 
need the libpng, jasper (JPEG 2000 library), IJG JPEG (or libjpeg turbo) 
and libtiff libraries respectively.  Those aren't hard to build with 
Visual Studio.
-Although there is an INCLUDE_gdiplus option, I would recommend not 
using it as the progression of Windows itself caused it to not to work 
very well (GDI+ is deprecated by Microsoft), plus you will definitely 
need to use the PNG module anyways.
-The INCLUDE_gdiplus option should not be defined with any of these: 
INCLUDE_bmp, INCLUDE_gif, INCLUDE_ico, INCLUDE_jasper, INCLUDE_jpeg, 
INCLUDE_tiff, if you still decide to use the GDI+ module.
-If you are planning to build with jasper support, you need to define 
JAS_WIN_MSVC_BUILD as well.
-Do a search in gdk-pixbuf\Makefile.am for the complete list of 
INCLUDE_xxx's, in case not everything you need is listed in 
build\win32\vs9\gdk-pixbuf-build-defines.vsprops.


Hope this helps.

With blessings
---
Hi,

Just wondering, is there any chance that 
https://bugzilla.gnome.org/show_bug.cgi?id=739778 can be looked at so 
that builds on Visual Studio can continue as usual?


And, in commit 852234f, I think the problem is only partially fixed, I 
think we also need to #include glib/gi18n.h for the i18n macros to be 
found and compiled properly.


With blessings, thank you!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

回覆: help wanted for implementing GdkGLContext on Windows and MacOS X

[Fan, Chun-wei]

Hello Emmanuele,

I am looking into getting GdkGLContext getting supported on Windows, so 
hopefully I can get a patch series for this soon.

With blessings

- 原始郵件 -
寄件者: Emmanuele Bassi eba...@gmail.com
寄件日期: ‎2014/‎11/‎16 22:33
收件者: GTK Devel List gtk-devel-list@gnome.org
主旨: help wanted for implementing GdkGLContext on Windows and MacOS X

hi all;

I posted this on my blog, which is syndacated on Planet GNOME, but I
thought about trying to reach out to more people by using the GTK+
mailing list as well.

GTK+ 3.16 will have OpenGL support out of the box — at least on X11 and Wayland.

if you are using GTK+ 3.x on Windows and/or MacOS X, or if you're
using external libraries like GtkGLExt and GtkGLArea with GTK+ 2.x or
3.x, then I'm asking you to help out with patches and testing the
OpenGL support in the master branch of GTK+. we'd really like to have
OpenGL support working on all the major backends in GDK by the time we
release GTK+ 3.16.0, next February.

ciao,
 Emmanuele.

-- 
http://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

回覆﹕ Re: atk 'missing symbols' problem since gnome-3-14

[Fan Chun-wei]

Hi,

This situation would have been hit by GLib and GTK+, if not done properly, as 
they use things like _GLIB_EXTERN (for glib, gobject, gio) and _GDK_EXTERN (for 
GDK, gtk) and they also export public variables (data)--but they build and link 
just fine.  In fact the work on using __declspec(dllexport) for ATK is modeled 
on them.  There is a ATK_VAR macro that is used to export (and import using 
__declspec(dllimport) the public variables, for example, and similar macros are 
used in GLib and GTK+, since the days of using .symbols/.def files.

It might be worth it to see whether we can use __declspec(dllimport) for the 
functions as well for better efficiency, though, but this would be something we 
can look into a bit later.  For the -mm libraries though, I think it might be 
good if we use dllimport and dllexport all around, rather than using gendef 
that makes use of dumpbin, as many other symbols are exported unnecessarily 
during the process.

With blessings.___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: atk 'missing symbols' problem since gnome-3-14

[Fan Chun-wei]

Hello John,

I was able to get these symbols from the atk-2.14.0 release tarball from 
the GNOME FTP, and was able to build atkmm without any problems.


Probably you will need to look at your atk/atk-enum-types.h and 
atk/atk-enum-types.c-these symbols are indeed annotated in 
atk-enum-types.h, which is a generated file that is generated by 
glib-mkenums.h and included in the release tarball during 'make dist'.  
You can either:


-Re-generate atk-enum-types.h/atk-enum-types.c by deducing the process 
from atk/Makefile.am  Notice that that rule changed a bit during the 
last dev cycle because we are using __declspec (dllexport)
-Grab the atk-2.14.0 tarball which contains atk-enum-types.h and 
atk-enum-types.c which the correct decorations
-Edi atk-enum-types.h to include config.h before everything else, and 
put a ATK_AVAILABLE_IN_ALL before the prototypes in atk-enum-types.h


Then re-do your build.  These symbols should be exported then.

Hope this helps, with blessings.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: atk 'missing symbols' problem since gnome-3-14

[Fan Chun-wei]

Hello John,

Sorry for the bunch of bad english and info here (late night reply here 
for me):


-glib-mkenums.h should read glib-mkenums (which is a PERL script)
-Edi atk-enum-types.h to include config.h... should read Edit 
atk-enum-types.c to include config.h...

-put a ATK_AVAILABLE_IN_ALL should be put ATK_AVAILABLE_IN_ALL

Please make sure your config.h(.win32) is up-to-date, as _ATK_EXTERN is 
defined in there to do the __declspec(dllexport) work.


With blessings.

Fan Chun-wei 於 2014/9/26 01:38 寫道:

Hello John,

I was able to get these symbols from the atk-2.14.0 release tarball 
from the GNOME FTP, and was able to build atkmm without any problems.


Probably you will need to look at your atk/atk-enum-types.h and 
atk/atk-enum-types.c-these symbols are indeed annotated in 
atk-enum-types.h, which is a generated file that is generated by 
glib-mkenums.h and included in the release tarball during 'make 
dist'.  You can either:


-Re-generate atk-enum-types.h/atk-enum-types.c by deducing the process 
from atk/Makefile.am  Notice that that rule changed a bit during the 
last dev cycle because we are using __declspec (dllexport)
-Grab the atk-2.14.0 tarball which contains atk-enum-types.h and 
atk-enum-types.c which the correct decorations
-Edi atk-enum-types.h to include config.h before everything else, and 
put a ATK_AVAILABLE_IN_ALL before the prototypes in atk-enum-types.h


Then re-do your build.  These symbols should be exported then.

Hope this helps, with blessings.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: _gdk_win32_selection_convert_to_dib

[Fan Chun-wei]

Hi John,

I took a quick look at this, the reason is because the line occurred 
before the variable decalarations (this is something Visual C++ before 
version 2013 doesn't like), so if you declare the variables first (don't 
do anything to them), then do the check, then assign these variables, 
then this would be fixed.


Sorry, I don't have time to post a patch/commit for this until tomorrow, 
but if anyone does that before me, I'd be quite happy as well.


It does seem that this fix is needed for gtk-3-12 and master as well.

With blessings!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Regarding theWin32/Visual C++ project completion items

[Fan Chun-wei]

於 2013/11/14 01:24, Colin Walters 提到:

My main concern here is about what kinds of additional restrictions this
might add to the Makefile.am files we are using.  For example, would
this script support nested conditionals like:

if BUILDOPT_FOO
if BUILDOPT_BAR
blah_SOURCES += foo-and-bar.c
endif
endif
In the form of the patch that I posted in bug 711047 (attachment 
259242), this is supported.  I have enhanced Shixin's scripts a bit to 
support this.
I have quickly tested this under Python 2.7.5 in Windows using this 
patch by updating the line in glib_msvc_files.py:

gio_test_filters_conds = {'OS_WIN32': True}
-to-
gio_test_filters_conds = {'OS_WIN32': True, 'OS_UNIX': True, 
'HAVE_DBUS_DAEMON': True, 'HAVE_DBUS1': True}
which indeed added the *NIX and d-bus test programs into the list of 
programs to build, for example (it's obviously not fully buildable for 
MSVC, but this is to verify things :) ).


I don't think this should impose any restrictions on the Makefile.am's 
that are being used at all.

etc.  Basically there will be an ongoing cost of having two independent
programs parsing the same Makefile.am files - we'll have to identify a
subset that works for both.
As Shixin mentioned, this basically reads the various Makefile.am's to 
get the strings (i.e. source files) based on the conditions that was 
passed in and to fill them into the MSVC files.  These Python 2/3 
scripts do nothing more than that.


I used msvcfiles.py to contain most of the functions that would be 
shared between projects, and glib_msvc_files.py for items that are 
specific to the GLib package, for references.



-Whether this is a viable approach-i.e. whether Python 2/3 is readily
available on the Linux systems which people use to generate dist
tarballs

Yes, I think that's fine.

Thanks!  I really appreciate this piece of info.

List: are there other views about the Python situation on the Linux systems?

With blessings, thank you!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Regarding theWin32/Visual C++ project completion items

[Fan Chun-wei]

Hello Arnavion,

Speaking as a consumer of the MSVC project files, is it too much to
ask for contributors to maintain the project files statically and
update them whenever they update the makefiles? There is no need to do
this in VS or even Windows; the vcxproj file is easy to maintain via a
text editor.
As the maintainer of the MSVC project files, these are some reasons why 
I (and previously Tor) wanted to keep the Project Files done in a 
dynamic way:


-Sources get added/removed/changed (i.e. renamed/moved/split) every now 
and then, and updates to Makefile.am may slip pass me until after a 
release.  For updating the MSVC projects for one project with a text 
editor (BTW this is what I use though) may not seem much, but currently 
I maintain the MSVC projects for GLib, ATK, Pango, GDK-Pixbuf, GTK+ (2.x 
 3.x), Cogl, JSON-GLib, Clutter and GObject-Introspection, and 
co-maintaining the ones for glibmm, pangomm, atkmm and gtkmm, and the 
source listings need to be updated for both vs9 and vs10, so doing it 
this way will ease the process significantly.  Note that the MSVC 
projects for the -mm packages are currently done statically, and I think 
if it is okay with the people there, I think it would be best to make it 
done in a way like what is being proposed (or even what is now done).


-The property sheets used to install the headers are currently done 
statically, but like the last point, it would be easier to maintain in 
the long run by doing them dynamically


-I would also like to have more time to invest in the continual 
improvement/maintenance of these GNOME libs (and possibly other GNOME 
libs/apps) on Windows (and possibly attract more Windows devs, as I've 
mentioned in my original post)


-Having the project files done dynamically is also the preferred way to 
do this for the maintainers, at least for the GTK+/Clutter stack.

It seems to me, Fan, that you're suggesting a (perhaps limited)
autotools simulator in Python to convert the original makefile into a
MSVC project file? It sounds like it would be very error-prone and
require a lot of special-casing for individual projects (as Shixin's
e-mail seems to suggest also).
No, this is not an autotools simulator as Shixin mentioned.  This is 
mainly meant to get the strings (i.e. source files listings) with the 
appropriate conditions to put into the MSVC files.


For references, you can take a look at my patch in bug 711047 
(attachment 259242, Add NMake Makefiles to build the GLib unit tests 
(take ii, automation added)) as an example...


I've isolated the project-neutral parts from the GLib-specific parts, as 
far as possible into msvcfiles.py and glib_msvc_files.py respectively.  
So I would, after checking whether the caller calls glib_msvc_files.py 
correctly, set up the strings to look for and the special cases (e.g. 
Win32-specific sources, ...) in glib_msvc_files.py, to read the correct 
Makefile.am's to get the correct sources/files to be put into the 
individual MSVC project files/NMake Makefiles.  You are right that I 
have to be careful about the filters and cases to check, but it's not 
that much of an issue as changes in the cases occur far less often than 
the addition/removal/changes to the sources themselves.


Hope this explains this a bit.

With blessings.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: non-Linux OSes

[Fan Chun-wei]

Hi,

As we look further into making GLib (and most probably the GTK+/Clutter 
stack) work better on Windows, here are some of my further thoughts 
about it:


As neither of the MSVC-based build approaches (the Visual Studio 
Projects nor Han's NMake Makefiles) support building the unit tests, I 
am currently doing some NMake Makefiles for building the unit tests of 
GLib at least, and hopefully for the GTK+/Clutter stack. Those NMake 
Makefiles would obviously depend on the build of GLib that was built by 
Visual Studio 2008~2012 (and 2013 Desktop, as I think we can support the 
2013 project files without much effort, just like the 2012 project files 
we have now[1]).  The main reasons I am not planning to build the unit 
tests directly from the Project Files is because (i.e. I will likely 
change the JSON-GLib project files to do the same thing):
1. They would add lots of stuff to the Project Files, which I don't 
think is wanted by many people, so people can build them when needed.
2. The NMake Makefiles can also build against an older and existing GLib 
installation if so desired.


Let me know if this is a good direction to go though.

With blessings, thank you!

ps: There are some tests that don't build for MSVC, which for tests 
under glib/tests are as follows, for references:

gvariant.c does not compile on MSVC (use of empty structure)
mem-overflow.c  does not compile on MSVC (use of empty structure)
strfuncs.c does not compile on MSVC (line 986: C1064 
token overflow internal buffer)


[1]:https://git.gnome.org/browse/glib/commit/?id=76cecf061b377d30e5422cdddb1fb9d19c52421d
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Hicolor icon theme

[Fan Chun-wei]

Hi John,

Or, in a more detailed fashion, this is what you can do about this, it 
took me a while to figure this out:
(This assumes that your GTK+2/3 main DLLs are in c:\foo\bin, adjust to 
your paths accordingly)


-Get the latest release tarball from 
http://icon-theme.freedesktop.org/releases/, it is 0.12 at this time, 
and put the index.theme file somewhere from the archive into 
c:\foo\share\icons\hicolor
 (This will stop GTK+ from saying that it can't find the icon themes 
and crashing, but that does not provide the icon images, so you would 
see lots of missing images)
-Get the latest release stable (3.10.x at this time, except for 
gnome-icon-theme-extras which is at 3.6.x) tarballs of gnome-icon-theme, 
gnome-icon-theme-extras and gnome-icon-theme-symbolic from the GNOME 
FTP, look for those names there.
--Open the archives for the 3 gnome-icon-theme- tarballs and go to the 
gnome directory in each of them and copy everything in there to 
c:\foo\share\icons\hicolor
--Be aware that in order for the symbolic items to show in the GTK+ 
programs, you need to build and install LibRSVG with its GDK-Pixbuf 
loader and generate the loaders.cache file in 
c:\foo\lib\gdk-pixbuf-2.0\2.10.0 using 
c:\foo\bin\gdk-pixbuf-query-loaders.exe  
c:\foo\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache after you built LibRSVG*


*Your GDK-Pixbuf must have built with #define USE_GMODULE 1 in its 
config.h; LibRSVG depends on libcroco and libxml2 in addition to 
Pango/PangoCairo.


Hope this explains things a bit.

With blessings.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: flow box

[Fan Chun-wei]

Hi Matthias,

Minor problem picking: I thought it might be a good idea if we use 
g_return_val_if_fail(GTK_IS_FLOW_BOX_CHILD (child), FALSE) instead of 
g_return_if_fail(GTK_IS_FLOW_BOX_CHILD (child)) in 
gtk_flow_box_child_is_selected() when an invalid GtkFlowBoxChild* is 
passed in to that function, as compilers expect a gboolean to be 
returned to go without a warning/error for that.


Here's my simple fix for this, please let me know if this is OK to push.

With blessings, thank you!
From 284287fdf9df81c826fcb91e1fccd245d9e547fc Mon Sep 17 00:00:00 2001
From: Chun-wei Fan fanchun...@src.gnome.org
Date: Mon, 7 Oct 2013 12:00:30 +0800
Subject: [PATCH] gtk/gtkflowbox: Fix build warning/error

The newly-added gtk_flow_box_child_is_selected() needed to return a
gboolean, so use g_return_val_if_fail() to return FALSE when an invalid
GtkFlowBoxChild* is passed in.
---
 gtk/gtkflowbox.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gtk/gtkflowbox.c b/gtk/gtkflowbox.c
index 34a99a3..96d57f2 100644
--- a/gtk/gtkflowbox.c
+++ b/gtk/gtkflowbox.c
@@ -680,7 +680,7 @@ gtk_flow_box_child_get_index (GtkFlowBoxChild *child)
 gboolean
 gtk_flow_box_child_is_selected (GtkFlowBoxChild *child)
 {
-  g_return_if_fail (GTK_IS_FLOW_BOX_CHILD (child));
+  g_return_val_if_fail (GTK_IS_FLOW_BOX_CHILD (child), FALSE);
 
   return CHILD_PRIV (child)-selected;
 }
-- 
1.8.3.msysgit.0

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+3 Win32 Bundles : RFC

[Fan Chun-wei]

Hello Tarnyko,

I build the latest GIT master (3.11.0) (up to and including Matthias' 
commits for GtkFlowBox) with Visual Studio 2008 and 2010 in both 
Win32/x86 and x64 configs, and the print demo didn't crash on either of 
my Windows 7 (a pretty clean installation) and my Windows 8 systems in 
any of my Visual Studio build configs.  I did try to run your October 6 
build (from your site) on my Windows 8 system and it did run OK but 
crashed on my Windows 7 system, just to let you know.


With blessings.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: 'glib/gio/glocalfile.c' no longer compiles with MSVC

[Fan Chun-wei]

Hi John,

It is indeed a very recent update to glocalfile.c, due to the use of 
dirent.  I have opened a bug for it few days ago at 
https://bugzilla.gnome.org/show_bug.cgi?id=707787, so if someone can 
take a look at it as a stable release is around the corner it would be 
great.


With blessings.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Regarding gdbus-codegen (was: Re: glib-mkenums in glib 2)

[Fan Chun-wei]

Hi John,

(list people: I understand this is a rather old topic that was brought
up few months ago:) ).

I was poking around with the Python scripts for gdbus-codegen lately,
and I thought it might be good to let you know a few things about its
use on Windows, especially under Visual Studio builds of GLib
It appears that one wouldn't have to change anything in those Python
scripts (at least from the release stable/unstable tarballs) so that
they can be ran on Windows.

What I found is that for it to work installed on Windows (suppose your
GLib installation is in c:\foo):
-From $(srcroot)\gio\gdbus-2.0\codegen, copy the gdbus-codegen.in file
as-is to c:\foo\bin, and renaming it as gdbus-codegen. (This files has
support for Windows regarding path issues without needing to process the
file with autotools)
-Copy all the .py files in $(srcroot)\gio\gdbus-2.0\codegen to
c:\foo\lib\gdbus-2.0\codegen as is.

So this will basically work when you have the following layout
c:\
foo\
bin\
gdbus-codegen (renamed from gdbus-codegen.in)
lib\
gdbus-2.0\
codegen\
codegen.py
codegen_docbook.py
codegen_main.py
config.py
dbustypes.py
parser.py
utils.py
__init__.py

Hope this may be of help. Unfortunately I can't run the
gdbus-test-codegen test program as it uses items from GIO-UNIX, but it
does seem to me that generating the test sources in-tree (with
UNINSTALLED_GLIB_SRCDIR set) and using the script in the layout I just
mentioned (without UNINSTALLED_GLIB_SRCDIR set, obviously) produce
identical results.

With blessings.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Regarding gdbus-codegen

[Fan Chun-wei]

Hi John,


[Tarnyko wrote: ]
Hmmm, that's strange, works here.
- in gdbus-codegen, we have :
path=$PATH:/lib/gdbus-2.0
from codegen import codegen_main
- and in /lib/gdbus-2.0/codegen/codegen_main.py we have :
from . import config
where config.py is in the same directory.
Using Windows (not MSYS) Python 2.5, and GTK+3.6.4 from :
http://www.tarnyko.net/repo/gtk3_build_system
gtk+-bundle_3.6.4-20130513_win32.zip
Running :
python gdbus-codegen


I also ran Python 2.7 in both x86 and x64 flavors in the same way 
Tarnyko ran the script (which I built myself using Visual Studio, so 
this is a native Windows build/version of Python, running under 
cmd.exe), and this worked for me too.

---

Hi Tarnyko,

[Tarnyko wrote:]
Thanks for sharing. FYI, MinGW makefiles from latest master generate 
and install gdbus-codegen correctly. You may want to take 
inspiration from them if you plan to add gdbus-codegen generation 
for MSVC (don't know this toolchain enough to do it myself).

I just suggested a little path change  :
https://bugzilla.gnome.org/show_bug.cgi?id=702862
Thanks for the notes regarding this.  By looking at Makefile.am in 
$(srcroot)/gio/gdbus-2.0/codegen, I agree with you regarding this 
change.  Just wondering whether there are other people that might be 
looking at this though so that we can be more consistent across the 
various platforms that GLib supports.
BTW, I have updated the Visual Studio build files for gdbus-codegen in 
commit 95f7dc94 
https://git.gnome.org/browse/glib/commit/?id=95f7dc949135181dcefd69e6773f1488c02a79a9 
on master-I will update it accordingly when your updates go in.


With blessings.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Asking for review for patch for GDK (Win32 backend)

[Fan Chun-wei]

Hi,

Can I ask someone to review my patches in bug 701121 (and/or LRN's 
patches in bug 700444-they address the same issue) so that GTK+ master 
can work again on Win32, as the GDK Win32 backend needs to be updated 
due to the recent changes in the display code of GDK.  I (and presumely 
LRN) would like to get the Win32 backend of GDK fixed in master asap as 
in its current state all the GTK+ programs would fail to run on Windows 
(please see the bug reports for more info).


Thanks a whole lot.

With blessings!
___
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

[Fan Chun-wei]

於 2013/4/16 下午 03:53, John Emmas 提到:
snip So if you're building your app with VS2008 you should link 
against GTK's supplied VS2008 modules (or if you've got the time and 
confidence, build the GTK+ stack yourself, using the supplied VS2008 
projects). 
Yes, so this is the main reason why building the GTK+ stack is also 
supported for Visual Studio 2008/2010.

But therein lies the problem...  the VS projects aren't maintained any more 
AFAIK.  :-(
The projects for GLib, ATK, GDK-Pixbuf, Pango and GTK+ are kept 
up-to-date for Visual Studio 2008 and 2010, at least for the library 
DLLs, as I happen to be the one that maintains them. The latest stable 
release tarballs of GLib, Pango, ATK, GDK-Pixbuf and GTK+ (2 and 3) 
should be building as long as the dependencies outlined in 
https://live.gnome.org/GTK%2B/Win32/MSVCCompilationOfGTKStack are met. 
Please let us know via Bugzilla if there is something that's not kept 
up-to-date for those. The gdbus-codegen and gio-querymodules GLib tools 
are not yet built via the project files, though, which is something I 
hope to do soon.



And on the subject of time...  let's not forget that there's a much bigger 
problem where GTK/Windows is concerned - a now enormous backlog of patches 
which nobody ever seems to have the time to apply or test.  I can't see the 
point in creating sophisticated build methodologies if the end product is still 
riddled with bugs that were theoretically fixed years ago.

Having a choice of build methodologies will encourage more devs to build GTK+ 
themselves - and that's a good thing because it helps them to eliminate 
multiple heap managers etc, which is always a boost to reliability.  But along 
the way, somebody at the GTK end needs to be applying those patches and finally 
making a dent in that bug list.  That's a big part of the equation that's been 
missing since Tor left..
I agree with you here. I think it might be a good idea to eventually put 
together lists of items on GNOME Live! that aren't working for the GTK+ 
stack on Windows so people can see and try to conquer those issues (some 
might be even CRT-specific[1])


[1]: for example, https://bugzilla.gnome.org/show_bug.cgi?id=693646

With blessings.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Glib on Windows for Windows Stroe apps

[Fan Chun-wei]

Hi Arnaud,

This is the correct list to ask questions like the one you mentioned.

In the current state, GLib cannot be used in Windows Store (aka Metro) 
apps, as it uses a number of Win32 API/CRT API calls that aren't allowed 
in the Windows Store apps, notably calls that use ws2_32.lib (Winsock2), 
as many portable libraries that involve the use of networking uses BSD 
sockets for ease of portability AFAIK, which was why Windows used 
Winsock.  The Metro apps, unfortunately, disallows the use of Winsock2 
APIs, and things like GSpawn won't be able to work in its current form 
as you aren't allowed to spawn processes directly from a Metro apps.  
There could be a number of other things that need to be ported, and one 
that might disappoint some is the use of TimeGetTime() (for precision 
timing, which uses winmm.lib), which is disallowed in Metro apps.


IMHO it is my hope that GLib (and possibly GTK+/Clutter) can be 
eventually ported to work with the Metro APIs, but there will be lots of 
work involved.   Perhaps if there are some people out there who can help 
out (and/or if you are willing), that would be excellent.  Note that it 
is possible to build and use GLib with Visual Studio 2012 at the time of 
writing, albeit only with the Desktop apps settings.


With blessings, thank you!

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Is GTK+ a cross-platform toolkit ? (fwd)

[Fan Chun-wei]

Hi Tarnyko,

I'm quite glad to hear about the broadway progress on Windows, as that 
had been brought up on this list some time ago.  Is there any chance 
whether you could post a bug report on your changes (or a link to them) 
to the GDK/broadway sources so that they will build and run on 
Windows-it could be something of significant interest here.  For my 
part, for example, would be to try to build that with Visual Studio and 
see how it goes with that.


I have to agree what other people say about installers for the GTK+ 
stack though, so I would agree a packaged .zip file would be a more 
ideal choice in terms of distribution-it is a frequent issue that's 
brought up from time to time.  The main issue is, having multiple GTK+ 
versions on a system (with one installation that is in the system's 
PATH) can be a source of pain as applications might not find the GTK+ 
(and related) DLLs that it needs, or it may find older versions of the 
DLLs, to name some examples.  And then, if people are planning to use 
the MinGW-compiled binaries of GTK+ with applications they write with 
Visual Studio, they also have to be aware of subtle issues caused by 
using different versions of the Microsoft CRTs (i.e. msvcrt.dll vs 
msvcr90.dll, for example).


Just some of my take on this issue, but your willingness to contribute 
is something that's great to hear, at least on my part. :)


With blessings, and thank you!

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Asking a favor to review a patch

[Fan Chun-wei]

Hi,

I have filed bug 693646 about two weeks ago regarding 
gspawn-win32-helper.c which fixes the Win32 spawn helper programs when 
they are linked with msvcr80.dll or later.  As msvcr80.dll (and later) 
are much more picky on the validity of the fd (file descriptor) passed 
into close(), the current code in gspawn-win32-helper.c will assert 
(aborted by the CRT) when it is linked against msvcr80.dll or later 
(please see the bug report for more details).  As the helper program 
will be used by programs using the gspawn APIs on Windows, this problem 
will cause programs and tools, more notably glib-compile-resources to 
fail to run on Windows when it is built with msvcr80.dll or later.  I am 
asking people, especially that build and use GLib on Windows, to see


-Whether this bug causes any problems for those building and using GLib 
with MinGW (as they would most probably use MSVCRT.dll)
-Whether this bug affects those building and linking GLib with 
msvcr80.dll or later, and whether the proposed fix fixes the problem.

-Whether the patch is good to land.

Sorry for the noise, but this is a bug I would definitely like to fix 
and close ASAP (it's a pain if unfixed :)


With blessings, thank you!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Proposed fixes to gspawn-win32-helper.c for newer Microsoft CRTs (was: glib-mkenums in glib 2)

[Fan Chun-wei]

Hi John,

I'm sorry if this sounds a bit off-topic, but can you check your Visual 
Studio 2005 build (if I recalled correctly, that's the version of Visual 
Studio you are using) of 
gspawn-win32-helper.exe/gspawn-win32-helper-console.exe whether programs 
using them are able to complete successfully without being 
terminated/aborted by Windows.  One good example to check here is using 
the glib-compile-resources utility program in gio/, the other ones would 
be the spawn-singlethread* and spawn-multithreaded* in 
$(srcroot)/glib/tests.


With blessings, thank you!
-Fan, Chun-wei

---
Hi list,

I have posted a bug report with a proposed patch at 
https://bugzilla.gnome.org/show_bug.cgi?id=693646, as newer Microsoft 
CRTs are much more picky on the parameters passed into close() and 
_get_osfhandle(), so it would be greatly appreciated on my side if 
people building and using GLib on Windows can check that for me (so far, 
no feedback yet), especially whether:
-People using Visual Studio 2005 or later to build and use GLib using 
msvcr80.dll or later does not run into the bug
-This does not break GLib builds of people using MinGW to build and use 
GLib (or those using MSVCRT.dll)


With blessings, thank you!
-Fan, Chun-wei
---
*You will need to edit the spawn-singlethread.c and 
spawn-multithreaded.c and append .exe to the various parts referring 
to test-spawn-echo, and you will need to build test-spawn-echo.exe 
before running the spawn tests


You can comment out this line:g_test_add_func (/gthread/spawn-script, 
test_spawn_script);

as that test involves running the test scripts in a shell.


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Re: glib-mkenums in glib 2

[Fan Chun-wei]

於 2012/12/27 下午 05:15, John Emmas 提到:
 Thanks for the reply, Fen.

 As it happens, it is VS2005 that I'm using but I'm pretty sure that
 the other VS projects are out of date too. I'm using the versions that
 are here:-
Hello John,

Ah, the VS 2005 projects are the reason why it seemed to you the VS
projects are out of date. The issue here is that since they are not
maintained (remember I mentioned I didn't have VS 2005, so I can't test
the VS 2005 projects), they are not distributed in a GLib source tarball.

I'm not sure whether VS 2005 supports the use of property sheets, but
this is what you can try to do (from a release tarball), using the VS
2008 projects (which are kept up-to-date as far as possible :) ):
-Go to $(srcroot)\build\win32\vs9

-Use a text editor (or some script) to open the .sln files and change
Format Version 10.00 to Format Version 9.00 and Visual Studio 2008
to Visual Studio 2005, without the quotes.

-Use a text editor (or some script) to open the .vcproj files and change
Version=9.00 to Version=8.00, *with* the quotes.

-Use a text editor (or some script) to open the .vsprops file and change
vs9 to vs8 and VS9 to VS8.

Try opening the project files using Visual C++ 2005 and build the
solution. This should apply for all the GNOME projects up to GTK+2.x/3.x

Note that some GIO headers that are needed might not be copied during
the install stage, so you might want to manually copy them
accordingly. I have submitted a patch so that the manifest of headers to
copy during the install stage can be constantly up-to-date by
completing the property sheets during 'make dist'[1].

[1]: https://bugzilla.gnome.org/show_bug.cgi?id=678334

p.s. for the glib-mkenums issue, you might want to download a Cogl 1.12
release tarball and look in gen-enums.bat to see how glib-mkenums is
called-I used a plain native Win32/Win64 PERL that I built from source
using the standard Visual C++ Makefiles given in the PERL source archive
since 5.12.1, which worked for me for quite a while.

Hope this helps, with blessings.

Merry (late) Christmas and a Happy New Year

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: glib-mkenums in glib 2

[Fan Chun-wei]

Hello John,

[snip]At least it seems so, if this web page is to be believed:-

http://www.gtk.org/download/win32.php
You might want to look at this page instead: 
http://www.gtk.org/download/linux.php, as the win32 page you have 
mentioned is unfortunately out of date.  The latest stable tarball is 
glib-2.34.3, which was released about a month ago, and that does include 
up-to-date VS 2008/2010 project files.  Beware, however, you need libffi 
in order to build GObject and ZLib to build GIO (parts of the GLib 
package), and that was since 2.29.x-you can take a look at 
https://live.gnome.org/GTK%2B/Win32/MSVCCompilationOfGTKStack#libffi on 
how to build libffi for Visual Studio (it is also recommended to build 
ZLib using the VS version you are using to build GLib, instructions for 
that can be found in 
https://live.gnome.org/GTK%2B/Win32/MSVCCompilationOfGTKStack#ZLib-building 
ZLib is actually quite simple on Visual C++).


[snip] But given that a list of header files is needed, wouldn't it be 
more logical for that list to be included in glib-mkenums (as opposed 
to being in makefile.msc)? Or am i looking at this from the wrong 
perspective?
The thing is, that PERL script is to be used for many GLib-using 
libraries (and perhaps programs), so it is meant to be general-purpose.  
The Cogl gen-enums.bat refers to an example how glib-mkenums is called 
(for Cogl, specifically), so the headers list would be different for 
each library that would call it.


Hope this helps.

With blessings.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Regarding resurrecting distutils support in PyGObject

[Fan Chun-wei]

Hello,

Merry Christmas and Happy New Year!

I am currently looking at trying to resurrect the distutils support for 
building PyGObject, as the build of G-I using Visual C++ has now landed 
in its master branch, and I am starting from the setup.py/dsextras.py 
files that are supplied in PyGObject-2.28.6, so that one can develop 
using Python and PyGObject easier on the Windows/MSVC side, and AFAICT 
it would be a good test bed of G-I functionality on that platform.


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?
-Any other things that might be pointers or items of interest in the 
process?


With blessings, thank you!
___
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

[Fan Chun-wei]

Hello Dieter,

Thanks for the pointers, hopefully I could get some of these things 
going soon.  Might need to put more things in this thread as it churns 
along.
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.
Hmm, that's interesting to hear... apparently I did manage to build 
PyGObject-2.28.6 and PYGTK-2.24.0 with MSVC 2008 as the code was C89 
compatible as far as I could recall... and managed to run the examples 
and even CherryTree in both win32 and x86-64 modes, but apparently a few 
minor hacks were needed, such as adding --msvc-syntax for pkg-config.


Since this is most probably only going to support MSVC, as you've 
mentioned-it may be so that I might do it in a way without pkg-config or 
force the use of the --msvc-syntax flag.


Thanks again, and Merry Christmas and Happy New Year.

With blessings.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Glib question: Is PCRE in some intermediate state?

[Fan Chun-wei]

Hi John,

It shouldn't require pthreads at all.  Please make sure that 
gthread-posix.c is not among the files you build, as it is not a source 
meant for native Windows builds.  As you noted, the correct sources to 
build for threading support in GLib are glib/gthread.c and 
glib/gthread-win32.c.


With blessings.

I stand corrected  for the x86 platform, timeGetTime() is available from 
winmm.lib.

So I can now build Glib successfully - albeit with an irritating dependency on 
libpthread.snip  Couldn't these have been implemented some other way??

John



___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Glib question: Is PCRE in some intermediate state?

[Fan Chun-wei]

Hi John,

The gatomic.c file contains a native Windows implementation of the 
atomic ops.  There were some pretty significant changes in GLib in terms 
of the implementation of threading and atomic operations throughout the 
last 2-3 stable release cycles.


Can you check the glibconfig.h that you are using?  As you are using 
Visual C++, it needs to match the contents in glibconfig.h.win32 in 
glib\.  If not, copy glib\glibconfig.h.win32 and overwrite 
glib\glibconfig.h.  Note that the currently correct place where 
glibconfig.h is to be found should now be in glib\, not srcroot (this 
changed from 2.24 probably-so it is possible that the Visual C++ 2005 
project files did not reflect on that).


With blessings.

Thanks Fan,

I just checked that I wasn't accidentally including gthread-posix.c.  
Fortunately I wasn't but along the way, I noticed that pthread_mutex_lock() and 
pthread_mutex_unlock() are getting called in numerous places from the module 
glib/gatomic.c.  That wasn't the case when I first built glib (circa version 
2.24). So it looks like this dependency has crept in unintentionally somewhere.




___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: unable to build static glib in mingw since 2.31

[Fan Chun-wei]

Hi Roy,

It seems that we aren't supporting static GLib builds, at least on 
Windows, as a big rewrite of the threading support in GLib took place 
back then.


It might make sense for you to try to use a shared build.  If it is 
still problematic, you might want to file a bug report for that.


With blessings.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Glib question: Is PCRE in some intermediate state?

[Fan Chun-wei]

Hi John,

Unfortunately the Visual C++ 2005 files aren't maintained anymore (hence 
they are not distributed with the newer GLib releases), since I am not 
able to test them as I do not have Visual C++ 2005.


The Visual C++ 2008/2010 projects do support the bundled PCRE sources 
and are kept up-to-date as far as possible-so if you run them, they 
would work fine.


Another alternative, though possibly not highly recommended, is to build 
the latest version of PCRE with CMake+Visual C++ 2005, remove the PCRE 
sources from the GLib project, and make GLib link to your PCRE build.  
Beware that during linking stage you will most probably see the linker 
complain as new source files for various libraries are added for GLib, 
GObject and (especially) GIO, and you will also need to add libFFI (for 
GObject) and zlib (for GIO) to the dependent libraries.


With blessings.

Are those modules still needed for building PCRE and if so, is there anywhere 
where I can obtain the full (current) set of source files?  Or is it just a 
matter of modifying the VS8 project to remove those particular entries as those 
modules aren't needed any more?


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: glib(win32) without libffi

[Fan Chun-wei]

I'm not sure if this was mentioned before but I'm pretty sure Mozilla
builds libffi using MSVC, so if you need reference project files, might
be worth looking there?  Or, looking at git, they may somehow cause the
autotools to run msvcc?  There's a msvcc.sh file in
js/src/ctypes/libffi/msvcc.sh.
Yup, Mozilla builds libffi using Visual C++, and they are in fact the 
contributors to libffi so that it runs optimally when built with Visual C++.


The msvcc.sh file is used by the autotools, where the official way to 
build libffi with Visual C++ is via mozilla-build where one would set 
CC=msvcc.sh

for this purpose.

With blessings.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: glib(win32) without libffi

[Fan Chun-wei]

於 2012/7/29 下午 09:57, Colin Walters 提到:

On Sun, 2012-07-29 at 15:24 +0200, Hans Breuer wrote:
I didn't say no; we're having a discussion. Realistically, so while 
I personally *do* care about Windows builds, I find cross-building 
with mingw a much saner approach to making Free Software available for 
Windows users, though it does obviously hamper our accessibility to 
Windows developers.
Well, I guess I have to have a say on this, IMHO... Please bear with me 
for this.


Not to take sides, but I guess Hans did make really valid points 
especially as a long time contributor to GTK+/GNOME on Windows.


The other big factor that is involved in keeping the Visual C++ build 
files up to date is due to the debugging features that are provided by 
Visual Studio,
as MinGW's gdb isn't as effective in Windows, AFAIK. It's true you can 
use the MinGW-produced libraries/DLL in Visual Studio development, but 
since the layout
of debugging info is quite different, it makes it more challenging to 
debug programs that use such DLLs. For me, I think it is the way to help 
people get involved
in the use and development of the platform, as it isn't an option (or 
people are unwilling to) for many people to develop using MinGW, 
especially at their
workplaces. For example (not to compare toolkits), the OpenSource 
edition of QT-4.x initially only supported MinGW officially on Windows, 
but due to
developer demand, they started official support for it on Visual Studio 
as well since 4.3.2 or so, which brought many positive responses for 
this move.


Anyways, I still do want to say thank you to all the people that are 
bringing the GNOME platform forward, as it did come a long way, and 
especially for Hans

and tml who made the GTK+ stack available and well-usable on Windows.

p.s. For LibFFI, I can't say much about building it with mozilla-build 
and Visual C++ 6.0, since I don't run it, but it seems from Hans comments
that it uses features provided by later Visual C++ versions, such as 
2005+, which I have managed to do and outlined in 
https://live.gnome.org/GTK+/Win32/MSVCCompilationOfGTKStack


With blessings.



___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Some questions regarding GObject-Introspection

[Fan Chun-wei]

Hi,

I was trying to build G-I on Windows using MSVC, and managed to get the 
GLib-2.0.gir file to be built by g-ir-scanner (used the gcc preprocessor 
as MSVC does not accept input from stdin[1], then run the MSVC compiler 
on the
resulting temporary GLib.c), using the command like what is found in the 
attached glib_gir.txt.  (please use an editor that has line wrap 
enabled, sorry about the one-line command, but this is what was needed!).


The built GLib-2.0.gir can be found at 
https://dl.dropbox.com/u/30316581/GLib-2.0.gir, as it is a bit too large 
to be included here.


I then built the GLib-2.0.typelib by using this command: g-ir-compiler 
-o GLib-2.0.typelib GLib-2.0.gir, where the typelib does get built


After figuring out where I should place the .typelib/.gir files, I 
proceeded to to run the glib-print example, but I get:

**
domain:ERROR:glib-print.c:1057148:main: hello world

This application has requested the Runtime to terminate it in an unusual 
way.

Please contact the application's support team for more information.

What I would like to know:
1. Does my GLib-2.0.gir seem ok?
2. Did I miss any stepts or make any mistakes generating the 
GLib-2.0.typelib file.

3. Any other thing that I might have missed?

With blessings, and thanks for your time!

[1]: https://bugzilla.gnome.org/show_bug.cgi?id=620566#c35
python tools/g-ir-scanner --verbose -I../ --add-include-path=../ 
--add-include-path=../gir --add-include-path=. --namespace=GLib --nsversion=2.0 
--no-libtool --pkg=glib-2.0 --library=glib-2.0 --library=gobject-2.0 
--external-library --reparse-validate --identifier-prefix=G --symbol-prefix=g 
--symbol-prefix=glib --c-include=glib.h -I%GNOMEBASE%/include/glib-2.0 
-I%GNOMEBASE%/lib/glib-2.0/include -I%GNOMEBASE%/include 
-DGETTEXT_PACKAGE=Dummy -DGLIB_COMPILATION -D__G_I18N_LIB_H__ 
%GNOMEBASE%/lib/glib-2.0/include/glibconfig.h 
%GNOMEBASE%/include/glib-2.0/glib/galloca.h 
%GNOMEBASE%/include/glib-2.0/glib/garray.h 
%GNOMEBASE%/include/glib-2.0/glib/gasyncqueue.h 
%GNOMEBASE%/include/glib-2.0/glib/gatomic.h 
%GNOMEBASE%/include/glib-2.0/glib/gbacktrace.h 
%GNOMEBASE%/include/glib-2.0/glib/gbase64.h 
%GNOMEBASE%/include/glib-2.0/glib/gbitlock.h 
%GNOMEBASE%/include/glib-2.0/glib/gbookmarkfile.h 
%GNOMEBASE%/include/glib-2.0/glib/gbytes.h 
%GNOMEBASE%/include/glib-2.0/glib/gcharset.h 
%GNOMEBASE%/include/glib-2.0/glib/gchecksum.h 
%GNOMEBASE%/include/glib-2.0/glib/gconvert.h 
%GNOMEBASE%/include/glib-2.0/glib/gdataset.h 
%GNOMEBASE%/include/glib-2.0/glib/gdate.h 
%GNOMEBASE%/include/glib-2.0/glib/gdatetime.h 
%GNOMEBASE%/include/glib-2.0/glib/gdir.h 
%GNOMEBASE%/include/glib-2.0/glib/genviron.h 
%GNOMEBASE%/include/glib-2.0/glib/gerror.h 
%GNOMEBASE%/include/glib-2.0/glib/gfileutils.h 
%GNOMEBASE%/include/glib-2.0/glib/ggettext.h 
%GNOMEBASE%/include/glib-2.0/glib/ghash.h 
%GNOMEBASE%/include/glib-2.0/glib/ghmac.h 
%GNOMEBASE%/include/glib-2.0/glib/ghook.h 
%GNOMEBASE%/include/glib-2.0/glib/ghostutils.h 
%GNOMEBASE%/include/glib-2.0/glib/gi18n-lib.h 
%GNOMEBASE%/include/glib-2.0/glib/gi18n.h 
%GNOMEBASE%/include/glib-2.0/glib/giochannel.h 
%GNOMEBASE%/include/glib-2.0/glib/gkeyfile.h 
%GNOMEBASE%/include/glib-2.0/glib/glist.h 
%GNOMEBASE%/include/glib-2.0/glib/gmacros.h 
%GNOMEBASE%/include/glib-2.0/glib/gmain.h 
%GNOMEBASE%/include/glib-2.0/glib/gmappedfile.h 
%GNOMEBASE%/include/glib-2.0/glib/gmarkup.h 
%GNOMEBASE%/include/glib-2.0/glib/gmem.h 
%GNOMEBASE%/include/glib-2.0/glib/gmessages.h 
%GNOMEBASE%/include/glib-2.0/glib/gnode.h 
%GNOMEBASE%/include/glib-2.0/glib/goption.h 
%GNOMEBASE%/include/glib-2.0/glib/gpattern.h 
%GNOMEBASE%/include/glib-2.0/glib/gpoll.h 
%GNOMEBASE%/include/glib-2.0/glib/gprimes.h 
%GNOMEBASE%/include/glib-2.0/glib/gprintf.h 
%GNOMEBASE%/include/glib-2.0/glib/gqsort.h 
%GNOMEBASE%/include/glib-2.0/glib/gquark.h 
%GNOMEBASE%/include/glib-2.0/glib/gqueue.h 
%GNOMEBASE%/include/glib-2.0/glib/grand.h 
%GNOMEBASE%/include/glib-2.0/glib/gregex.h  
%GNOMEBASE%/include/glib-2.0/glib/gscanner.h 
%GNOMEBASE%/include/glib-2.0/glib/gsequence.h 
%GNOMEBASE%/include/glib-2.0/glib/gshell.h 
%GNOMEBASE%/include/glib-2.0/glib/gslice.h 
%GNOMEBASE%/include/glib-2.0/glib/gslist.h 
%GNOMEBASE%/include/glib-2.0/glib/gspawn.h 
%GNOMEBASE%/include/glib-2.0/glib/gstdio.h 
%GNOMEBASE%/include/glib-2.0/glib/gstrfuncs.h 
%GNOMEBASE%/include/glib-2.0/glib/gstring.h 
%GNOMEBASE%/include/glib-2.0/glib/gstringchunk.h 
%GNOMEBASE%/include/glib-2.0/glib/gtestutils.h 
%GNOMEBASE%/include/glib-2.0/glib/gthread.h 
%GNOMEBASE%/include/glib-2.0/glib/gthreadpool.h 
%GNOMEBASE%/include/glib-2.0/glib/gtimer.h 
%GNOMEBASE%/include/glib-2.0/glib/gtimezone.h 
%GNOMEBASE%/include/glib-2.0/glib/gtrashstack.h 
%GNOMEBASE%/include/glib-2.0/glib/gtree.h 
%GNOMEBASE%/include/glib-2.0/glib/gtypes.h 
%GNOMEBASE%/include/glib-2.0/glib/gunicode.h 
%GNOMEBASE%/include/glib-2.0/glib/gurifuncs.h 
%GNOMEBASE%/include/glib-2.0/glib/gutils.h 
%GNOMEBASE%/include/glib-2.0/glib/gvariant.h 

Question about the state of development of GTK+ 3.5/3.6+

[Fan Chun-wei]

Hi,

I was wondering about the recent works on accessibility, in particular 
the part regarding the new hard
dependency on atk-bridge-2.0, which I presume to be a new library if I 
read correctly from

https://bugzilla.gnome.org/show_bug.cgi?id=677491.

It seems to me that it is something that depends on AT-SPI (please 
correct me if I am mistaken here
at any point), which is something that seems to be Linux/*nix only.  
What I would like to know-is there a change on the
multi-platform (Windows/Mac/*nix) support for GTK+, or it is something 
that is new for the development
of the toolkit on *nix only?  By no means of disrespect, and I do not 
mean to over-exaggerate here,
I think it would be a pity if GTK+ becomes *nix only, especially after 
it had come a long, long way to work
well on various non-*nix platforms by the hard work of many people in 
the past-especially when GTK+-3.4.x would be

the first GTK+-3.x stable release that works well on Windows, for example.

p.s. I do understand that there is an initiative [1] to support UIA for 
GNOME/GTK+ on Windows, but most probably
it would take time to do even when one is able to build that without 
legal concerns using Visual C++ in conjunction
with the Windows SDK, in which I try my best to ensure that the GTK+ 
stack can be built with Visual C++ entirely on Windows.


[1]: https://mail.gnome.org/archives/gtk-devel-list/2012-April/msg00032.html

Thank you-I wanted to say thank you for the hard work into this great 
toolkit anyways, with blessings!


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building gtk for Win32/gdk-pixbuf problem

[Fan Chun-wei]

Hi Damon,

Some things I think I would let you know to try to help you in the 
process of using the GTK+ stack on Windows...


During the make
process gdk-pixbuf-query-loaders.exe crashes.  From what I could 
determine so

far, the problem seems to be within query_module() in queryloaders.c when
resources are freed.

You might need to ensure that you used the same CRT for your build of 
the GTK+ stack, including dependencies that you built, as
far as possible.  The crash problem you mentioned seemed like it stemmed 
from this-if this is the problem, it's not likely that it

will be fixed, to let you know.

Please note that MinGW builds use msvcrt.dll (from Visual C++ 6.0), and 
it is not really ABI compatible with the CRT that you
have from Visual C++ 2005/2008/2010, which use msvcrt80.dll, 
msvcrt90.dll and msvcrt100.dll respectively, unless you have a
special setup to link to the Visual C++ 6.0 CRT (such as using the 
Windows Driver Kit).


If I am understanding
these posts correctly, it looks like there has been some success with
mingw and MSVC.  Now I have a few questions for those who have had 
success

in this area.

I can't help you very much with MinGW builds, sorry, since I don't use it...

However, this is what you can do for Visual C++ 2010.  In the source 
packages of GLib, ATK, Pango, GDK-Pixbuf and
GTK+ (2.24.10 and 3.4.x), there is a build folder is the root 
directory of these source packages.  Look into that folder,
and navigate to $(srcroot)\build\win32\vs10, and there are working .sln 
files to build these packages with the Visual C++

2010 IDE, which works for Express editions as well.

For a more detailed walkthrough on building these and their 
dependencies, please refer to

https://live.gnome.org/GTK+/Win32/MSVCCompilationOfGTKStack.

Hope this helps.

With blessings,
Fan, Chun-wei

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

FW: Tree structure for a win32 application deployment

[Fan Chun-wei]

Sorry, I am resending this as I missed the mail list when I sent this last 
night from my phone :)

 Setting PATH would work, or (assuming your app isn't intended to be run
 from the command line) you could use AppPaths:
 
 http://msdn.microsoft.com/en-us/library/windows/desktop/ee872121%28v=vs.85%29.aspx

I don' twant to  with the system environment PATH variable because I learned 
that's not the right way to work with GTK.
I tried AppPath
I think what was meant is to start a cmd prompt and use the command set 
PATH=some_path_seperated_by_; in it prior to running your program in it, 
which means the set path is only valid for this cmd prompt.

Another alternative is to use a simple .bat file containing the set 
PATH=some_path_seperated_by_; followed by the call to your program's .exe

Hope this helps.

With blessings

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

RE: gir stability

[Fan Chun-wei]

Hi,

I will take a look at the nmake Makefiles in the coming week (sorry I am on 
vacation now and due to lack of time during the past month or so I was not able 
to update the Visual C++ support stuff very much lately)-but most probably they 
will need some other updates before they can become usable anyways.

Will look at the other comments regarding this issue ASAP on my part.

With blessings.
-Fan, Chun-wei (fanc999)



- Original Message 
- nmake build: probably wouldn't pose big problems as it relies
  on the .def file to be in the source tarball. I wish somebody could
  apply the same msvc magic as described above so we could get rid of
  the .def file needs to live in $(srcdir) abomination, though...

mvg,
Dieter

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

___
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 update

[Fan Chun-wei]

 2011/11/2 Alexander Larsson al...@redhat.com:
 The gtk-2-24-win32 branch is now in a pretty good state. I fixed a lot
 of bugs from bugzilla and stuff from dieters testing
 (https://live.gnome.org/GTK%2B/Win32/test-gtk-2-24-win32). I think this
 is in a state where we might want to merge it into master. I fixed most
 core issues, although I didn't fix the MS-Windows misrendering bugs that
 dieter pointed out.
Thank you! +1 :)

 So, could everyone interested in the windows support test this please.
 I'd like to make a 2.24 release with this stuff in it so that we have a
 final Gtk2 with good win32 support. Obviously we don't want to have any
 bad regressions for existing Gtk win32 apps in this release, so *please*
 test stuff.

I think things basically went alright with the Visual C++ builds-but I have not 
yet integrated the ms-windows theme portion into the project files, which
I would most likely build it right into the main GTK+ DLL if that is desired.  
Please let me know if integrating the ms-windows theme bits is the ideal way 
here, so I could
update the items here.

Thank you, and God bless!
___
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

[Fan Chun-wei]

Hi Alexander/Dieter,

I will also test the builds on Visual C++ 2008/2010 in these 2 days to poke out 
possible issues there in these 2 days or so, and will keep people informed here.

Perhaps we might want to post this on the Win32 list too?


Thanks for the update, and thanks to Alexander for squishing out those bugs.

Best regards, and God bless!

-Fan, Chun-wei



寄件日期： 2011/10/20 (四) 7:49 AM
主旨： 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.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

RE﹕ A few small patches

[Fan Chun-wei]

Hi Kean,

I understand this kind of situation of yours-probably the best way is to ping 
nicely on IRC (#gtk) in addition to (i.e after) filing the bug reports.

BTW, I committed your patches for bug 660730 and closed it as Matthias 
mentioned that it was ok for commit.

God Bless.

-Fan, Chun-wei



- 原始信件 
寄件者： Kean Johnston
副本： 
寄件日期： 2011/10/3 (一) 7:33 PM
主旨： A few small patches

Not sure if we're supposed to announce patches or just file bugs with patches 
and wait (please educate me) but in case we are, please consider the following 
small patches:

https://bugzilla.gnome.org/show_bug.cgi?id=660730
https://bugzilla.gnome.org/show_bug.cgi?id=660095
https://bugzilla.gnome.org/show_bug.cgi?id=660731
https://bugzilla.gnome.org/show_bug.cgi?id=660761

Thanks in advance.
Kean

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

回覆﹕ Fwd: Plans for GTK+ Bundles for win32 and win64?

[Fan Chun-wei]

 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 :)

 Dieter Verfaillie wrote
- I want or have to use Visual Studio on Windows:
     Sure, here's how to build GTK+ with Visual Studio
      Solution files.

For a start on my side, I wrote a GNOME Live! page in this URL regarding 
compiling the GTK+ stack from scratch with Visual Studio 2008/2010: 
https://live.gnome.org/GTK%2B/Win32/MSVCCompilationOfGTKStack, which I also 
linked to the Discussion page (please see Sam's lines for the link to that page)

God Bless,
Fan, Chun-wei

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Compilation of the GTK+ stack on Windows using Visual C++

[Fan Chun-wei]

Hi List,

I have (finally) managed to write up some instructions[1] to build the GTK+ 
stack with a stock installation of Visual C++ 2008/2010 from scratch.  
The instructions can be found at [1].  Check it out, and please let me know 
if  some needed info is missing from there, or maybe any pointers for 
improvement-I will update it soon regarding Clutter.

p.s. I understand that the VS projects are not available in the stable 
 versions of Pango, GDK-Pixbuf and JSON-GLib-let me know if that is 
 needed that I should post VS project files for them in [1] for the time
 being.

[1]: https://live.gnome.org/MSVCCompilationOfGTKStack

Thank you, and God bless!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Compilation of the GTK+ stack on Windows using Visual C++

[Fan Chun-wei]

Hi list,

The GNOME Live! page containing info for compiling the GTK+ stack with
Visual Studio has been moved to 
https://live.gnome.org/GTK%2B/Win32/MSVCCompilationOfGTKStack, and it also can 
be accessed via https://live.gnome.org/GTK%2B/Win32/.

Thanks for staying in tune.

God bless!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLIB, libffi and Windows

[Fan Chun-wei]

Hi Kean (and list),

I have asked on IRC few weeks ago regarding the inclusion of libFFI in the 
GLib sources, but the response that I receive is that there is no plans 
(at least at that time) to include the libFFI sources in the GLib sources,
and that was from one of the core devs, AFAICT.

So it seems like that one needs to compile libFFI on Windows beforehand
using MinGW/MSYS(for GCC users) or mozilla-build (for MSVC users, libFFI
3.0.10rcx+).  Let me know if one needs help building it with MSVC though-
the 2.29.x GObject VS project has a build-time dependency on libFFI 
(libFFI is built as a static .lib on MSVC).

All the best, and God bless.

---Kean Johnston kean.johns...@gmail.com wrote--：
 On 8/7/2011 8:16 PM, Dieter
 Verfaillie wrote:
  On 07/08/2011 19:33, Kean Johnston wrote:
 Given that, I strong suggest that ffi is built as part of
 GLib like PCRE is for GRegex.
___
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)

[Fan Chun-wei]

(Sorry this may appear off-topic here...)

For those that may be interested in some ways...

I have committed about a day ago or so VS 2010 project files to compile 
GTK+-2.24.6+ in both 32-bit and x64 configs-it was posted in BugZilla for 
quite some time (bug 643164, and it seems to me that there could be enough 
interest for those items).  

So those files will be in the next release of GTK+-2.24.x.

Thanks for reading!
___
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)

[Fan Chun-wei]

 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

I believe that would be very helpful too.  Thanks Sam and Dieter.

By the way, I am also in the process of writing up a live.gnome.org
page regarding compiling the GTK+ stack from a stock Visual C++ 2008/2010
installation-the page is https://live.gnome.org/MSVCCompilationOfGTKStack.
It is not complete yet, and I know I am slow in getting it done, but 
anyways to let people know.

Beware though, on the MSVC aspect, compiling the latest stable GLib (and 
possibly some or all of the GTK+ stack) out of the box is only possible
on Visual C++ 2005 or later due to Windows API/CRT functions usage-and I
can't say much about Visual C++ 2005 as I do not have that to test that
VS version.

 
 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!
I fully agree with this-though I wonder I have the chance to get him the
beer face-to-face (I'm in another part of the world)-but anyways he does
deserve *lots* of credit! :)

 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.

Thank you for you work! (Even though I am not going by the MinGW/GCC path!)
Might want to ask the others on this list about the status (or situation 
about how to provide) binaries of GTK+-3.x on Windows-please be aware that 
GTK+-3.x is less stable than GTK+-2.x on Windows at the moment though.

 
 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?

My guess is yes...

Also I'd like to know whether there will be interest to add VS2010 project
files to build GTK+-2.24.x-please let me know too! (Note: the VS2008 files 
cannot be upgraded to be used on VS2010 directly as there are a few items
in there that must be edited beforehand)

Thank you, and God bless
-Chun-wei


___
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)

[Fan Chun-wei]

I don't know whether this might be helpful with this part and regard, but I
am posting my point of view here anyways for references...

Currently I am maintaining the Visual C++ build files for the GTK+ stack
(GLib, ATK, GDK-Pixbuf, Pango, GTK+-2.x/3.x), and these files are kept 
up-to-date as far as possible in the master branch-and there are at least
Visual C++ 2008 build files for these packages in their latest unstable
tarball releases (in fact Visual C++ 2010 build files are also in every
one of these except for Pango and GTK+-2.x, as they are under review for 
Pango and I am seeing whether people are interested for them for GTK+-2.x),
and even (Visual C++ 2008/2010) in the stable releases of GLib, ATK and 
GTK+-2.x/3.x.  These files will help to enable building the GTK+ stack
on Windows (for those who will use the Microsoft toolchain) much easier
and faster on Windows (I think MinGW is a formidable project, but I don't
think it suits my purposes well, AFAICT).

I would also like to be able to help in getting GOBject-Introspection (GI)
being buildable/workable for Visual C++, especially as the official Python 
builds are built with Visual C++ 2008.  I might need help though on the
python scripts as they call GCC directly... byt anyways for now

By hacking the pkg-config .pc files and purging C99isms from the various 
code, it is possible for one to build pycairo[1], pygobject (sans GI 
support), pygtk2 and pygtksourceview2 entirely with the MSVC 2008 
toolchain, for example using distutils.

All the best.
[1]: Yeah I know pycairo uses WAF, and it does take a bit of hackery to 
 make it work correctly on MSVC build, but anyways...

Thank you!

God bless.


___
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)

[Fan Chun-wei]

I don't know whether this might be helpful with this part and regard, but I
am posting my point of view here anyways for references...
 
Currently I am maintaining the Visual C++ build files for the GTK+ stack
(GLib, ATK, GDK-Pixbuf, Pango, GTK+-2.x/3.x), and these files are kept 
up-to-date as far as possible in the master branch-and there are at least 
Visual C++ 2008 build files for these packages in their latest unstable 
tarball releases (in fact Visual C++ 2010 build files are also in every
one of these except for Pango and GTK+-2.x, as they are under review for 
Pango and I am seeing whether people are interested for them for GTK+-2.x),
and even (Visual C++ 2008/2010) in the stable releases of GLib, ATK and 
GTK+-2.x/3.x.  These files will help to enable building the GTK+ stack
on Windows (for those who will use the Microsoft toolchain) much easier
and faster on Windows (I think MinGW is a formidable project, but I don't
think it suits my purposes well, AFAICT).
 
I would also like to be able to help in getting GOBject-Introspection (GI)
being buildable/workable for Visual C++, especially as the official Python 
builds are built with Visual C++ 2008.  I might need help though on the
python scripts as they call GCC directly... but anyways for now
 
By hacking the pkg-config .pc files and purging C99isms
from the various code, it is possible for one to build pycairo[1], 
pygobject (sans GI support), pygtk2 and pygtksourceview2 entirely with the
MSVC 2008 toolchain, for example using distutils.


[1]: Yeah I know pycairo uses WAF, and it does take a bit of hackery to 
     make it work correctly on MSVC build, but anyways...

All the best, and thank you!

God bless.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list