Re: Gtk::Widget::is_mapped ()

On 03/03/2019 16:10, Paul Davis wrote: John should really know that there's code to do this (to the best extent possible) within the Ardour source code at libs/gtkmm2ext/visibility_tracker.cc :))) Hi Paul - that's in fact what I'm investigating There's a new object called

Re: Gtk::Widget::is_mapped ()

On 03/03/2019 11:22, Emmanuele Bassi wrote: On Sun, 3 Mar 2019 at 11:09, John Emmas <mailto:j...@creativepost.co.uk>> wrote: Sorry to ask a dumb question... What does it mean if a widget is "mapped" ? It means that:  - the widget is visible  - the widget is

Gtk::Widget::is_mapped ()

Sorry to ask a dumb question... What does it mean if a widget is "mapped" ? Thanks, John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Glib::Threads:Private

On 20/02/2019 15:26, Paul Davis wrote: On Wed, Feb 20, 2019 at 1:17 AM John Emmas <mailto:j...@creativepost.co.uk>> wrote: I realise it's a deprecated interface but can anyone explain what Glib::Threads:Private does? [...] It means that each thread that

Glib::Threads:Private

I realise it's a deprecated interface but can anyone explain what Glib::Threads:Private does? Does it guarantee that 'SomeObject' can only be accessed by code running in a particular thread? And if so, does it do that by creating a specific thread for the object - or does it use whichever

Re: What (or where) is LSTATUS ?

On 16/12/2018 13:47, Luca Bacci wrote: Great! I think we should change LSTATUS to LONG then. Would you mind creating a MR for that in Pango? That would be really useful! Thanks for researching. Hmmm... it seems a lot of trouble to go to - just to change a single word in one source file !

What (or where) is LSTATUS ?

Commit #f523c25c12 (3rd Dec 2018) introduced this code at line 499 of 'pango/pangowin32-fontmap.c' LSTATUS status; I'm trying to build with MSVC which is giving me this error:- error C2065: 'LSTATUS' : undeclared identifier I'm guessing this is a missing #include although I couldn't

Re: An alternative to gdk-pixbuf

On 16/09/2018 11:18, Emmanuele Bassi wrote: The correct way to report issues for gdk-pixbuf: 1. use the issue tracker: https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/new Thanks Emmanuele - done! ___ gtk-devel-list mailing list

Re: An alternative to gdk-pixbuf

On 15/09/2018 18:48, John Emmas wrote: Thanks Magnus. I've a feeling that the problem might come down to struct alignment. No, I was wrong about that. I've tracked the problem to commit #ce52cefbbc in gdk-pixbuf (which brings me to the 2nd problem...) On 15/09/2018 18:48, John Emmas

Re: An alternative to gdk-pixbuf

On 15/09/2018 12:07, Magnus Bergman wrote: Some mismatch in versions of libtiff could for example be a reason. Otherwise you should probably file a bug report with more information (perhaps to your distribution firstly). Thanks Magnus.  I've a feeling that the problem might come down to

Re: An alternative to gdk-pixbuf

Sorry, I haven't been following this conversation but as a side-issue... I only noticed this morning that gdk-pixbuf doesn't seem to be able to load TIF images any more. I've attached a small file that won't load but I haven't managed to load any TIF image from the ones I've tested this

Re: Problems with git.gnome.org

On 06/09/2018 14:11, Bastien Nocera wrote: It's gitlab.gnome.org, not git.gnome.org anymore. Thanks Bastien - but that doesn't seem to help... :-( I see exactly the same error except that whereas it previously said "fatal: unable to connect to git.gnome.org" it now tells me:- "fatal:

Problems with git.gnome.org

Hi guys - sorry for posting this here but I've tried gnome's 'gitlab-issues' mailing list and couldn't get any response. Maybe someone here can help..? For the past few weeks I've been seeing errors if I try to update (i.e. pull) certain libraries from git (e.g. pango / pangomm / gtkmm etc).

Re: Problem accessing gtk-2-24

On 23/03/2018 08:53, LRN wrote: On 23.03.2018 11:08, John Emmas wrote: has the gtk repo moved recently (or has the gtk-2-24 branch been deleted somehow?) [...] Is it no longer hosted at git.gnome.org maybe? Correct, it's on gnome gitlab instance[0] now. [0] https://gitlab.gnome.org/GNOME

Problem accessing gtk-2-24

Hi guys - has the gtk repo moved recently (or has the gtk-2-24 branch been deleted somehow?) I still need gtk-2-24 for a project but all of a sudden if I try to 'pull' (using TortoiseGit, on Windows) I see this error:- Connecting to git.gnome.org (port 9418) ... 209.132.180.184 done.

Re: What's the deal with 'pango-bidi-type.c' ?

On 08/03/2018 10:03, Behdad Esfahbod wrote: On Thu, Mar 8, 2018 at 1:36 AM, John Emmas <j...@creativepost.co.uk <mailto:j...@creativepost.co.uk>> wrote: On 07/03/2018 22:05, Behdad Esfahbod wrote: Yes. You need the external fribidi library now. Okay Behdad, th

Re: What's the deal with 'pango-bidi-type.c' ?

On 07/03/2018 22:05, Behdad Esfahbod wrote: Yes. You need the external fribidi library now. Okay Behdad, thanks. I installed fribidi (from (git) and decided to use it as my first foray into building with meson. I installed meson and ran this command after reading the "quick start" guide:-

What's the deal with 'pango-bidi-type.c' ?

I just updated pango from git master and noticed commit #0a71013dfc (13th Nov 2017) which reads "Drop now unused mini-fribidi". Maybe I'm confused about something but pango itself looks like "pango-bidi-type.c" is still included in the build. In fact, it's needed for a couple of functions -

Re: Is a Module Definition File needed when building with MSVC (gtk-2-24)?

On 30/01/2018 08:28, John Emmas wrote: Should I file a bug report about this (or is there one already open?) Bug #793057 submitted:- https://bugzilla.gnome.org/show_bug.cgi?id=793057 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https

Re: Is a Module Definition File needed when building with MSVC (gtk-2-24)?

On 24/01/2018 15:27, John Emmas wrote: to be absolutely clear... there's no problem when I try to build Glib. Glib itself builds fine. The linker problem arises when I subsequently try to build Gtk-2 (specifically, the 'gtk-2-24' branch). Gtk-2 uses the glib-genmarshal (python) script

Re: Is a Module Definition File needed when building with MSVC (gtk-2-24)?

On 24/01/2018 13:26, Emmanuele Bassi wrote: This is possibly a case that was solved with this commit: https://git.gnome.org/browse/glib/commit/?id=bf0be21208800d7976b5a660287e1e487f8a57d3 i.e. the older version of the Python port you used generated too many symbols that aliased the ones

Re: Is a Module Definition File needed when building with MSVC (gtk-2-24)?

I've made some good progress on this today and believe it or not, it's looking like a problem with Glib - but first, the older (exe) build:- On 22/01/2018 04:12, ?,?? wrote: test using the Python version of glib-genmarshal and see whether the linking z works properly? If not, use the

Re: Is a Module Definition File needed when building with MSVC (gtk-2-24)?

On 22/01/2018 14:47, John Emmas wrote: BTW - IIRC the previous version of glib-genmarshal was a perl script (rather than an exe). I'd need to get a copy of that old perl script somehow as I won't have it backed up anywhere. Apologies... I just found a copy of glib-genmarshal.exe

Re: Is a Module Definition File needed when building with MSVC (gtk-2-24)?

On 22/01/2018 08:27, John Emmas wrote: On 22/01/2018 04:12, 范，君維 wrote: Hi John, Can you try generating gtk/gtkmarshalers.[c|h] using glib-genmarshal? Can you also test using the Python version of glib-genmarshal and see whether the linking z works properly? If not, use the former .exe

Re: Is a Module Definition File needed when building with MSVC (gtk-2-24)?

On 22/01/2018 04:12, 范，君維 wrote: Hi John, Can you try generating gtk/gtkmarshalers.[c|h] using glib-genmarshal?  Can you also test using the Python version of glib-genmarshal and see whether the linking z   works properly?  If not, use the former .exe version of the tool, and perhaps file a

Is a Module Definition File needed when building with MSVC (gtk-2-24) ?

Perhaps wrongly I've been using a module definition file when building gtk-2-24 with MSVC (I'm saying "perhaps" because it used to be needed at one time but maybe that eventually got superseded and I didn't notice...) On 8th Jan, the following symbols got added to 'gtk/gtk.symbols' by commit

Re: Python error when building gdbus-codegen stuff (in glib / gio)

On 17/01/2018 11:04, John Emmas wrote: I'll look a bit further into this and see if I can figure out what's gone wrong. This turned out to be a problem with TortoiseGit. Some of glib's python files contain lines looking like this:- from .whatever import something For some reason

Re: Python error when building gdbus-codegen stuff (in glib / gio)

On 17/01/2018 10:38, Philip Withnall wrote: What’s the output of `git status`? For both 'codegen_main.py' and 'codegen_docbook.py' I see this output:- # On branch master # Your branch is ahead of 'upstream/master' by 260 commits. # nothing to commit (working directory clean) (I think

Re: Python error when building gdbus-codegen stuff (in glib / gio)

On 17/01/2018 09:51, Philip Withnall wrote: Exactly what commit are you building? [...] That’s not what the code currently looks like: Thanks for the quick response Philip. The latest commit here is #5fba62ade by Benjamin Berg on 15 Jan 2018 (gmessages: Flush output stream after

Python error when building gdbus-codegen stuff (in glib / gio)

erator(all_ifaces, docbook, outdir); (which hasn't changed AFAICT). Python is complaining that too many parameters are getting passed here. Once again - apologies if this is all due to my build system being out-of-date... John Emmas ___ gtk-devel-list m

Do I need to #define GLIB_CHARSETALIAS_DIR ?

I'm building glib (from git master) using MSVC (using my own VC projects). This morning I noticed a change at line 68 in 'glib/libcharset/localcharset.c' Previous code:- /* Get LIBDIR. */ #ifndef LIBDIR # include "configmake.h" #endif New code:- /* Get

glib compilation problems when building from git master with MSVC

When trying to build glib (git master) I've hit a few compilation snags arising from commit #53bd6a359f (29th Sept 2017) 1) Firstly (in gstdio.c) the function:- '_g_win32_readlink_utf16_raw()' uses a value called "IO_REPARSE_TAG_SYMLINK". This doesn't seem to be defined for MSVC - at least

Re: FILE_NAME_INFO struct in 'glib/gmessages.c'

On 16/09/2017 02:41, Chun-wei Fan (范君維) wrote: John Emmas 於 2017/9/16 上午 03:00 寫道: I'm assuming you're referring to this SDK? Yes, this is the SDK I was mentioning. It does work for Visual Studio 2005, see https://msdn.microsoft.com/en-us/windowsserver/bb986638.aspx under "Supp

Re: FILE_NAME_INFO struct in 'glib/gmessages.c'

On 15/09/2017 17:25, Chun-wei Fan (范君維) wrote: Are you using the Windows SDK that came with your Visual Studio 2005?  These items that you mentioned are in the Server 2008 (7.0) SDKs, which work with Visual Studio 2005 (and the Windows 7 (7.1) SDKs does work with 2005 as well) Thanks for

FILE_NAME_INFO struct in 'glib/gmessages.c'

I just tried building Glib from git master (non-meson build at the moment). In 'config.h.win32.in' it looks like the value of _WIN32_WINNT got increased to 0x601. This means that when building 'glib/gmessages.c' the struct _FILE_NAME_INFO is no longer defined. However... it's still getting

Re: Generating glib-genmarshal

On 07/09/2017 08:44, John Emmas wrote: On 07/09/2017 03:59, Chun-wei Fan (范君維) via gtk-devel-list wrote: p.s. Were you able to build GDK-Pixbuf succesfully? I'm going through the process of adapting my MSVC projects to accommodate the fact that some old perl scripts are now python scripts

Re: Generating glib-genmarshal

On 07/09/2017 03:59, Chun-wei Fan (范君維) via gtk-devel-list wrote: p.s. Were you able to build GDK-Pixbuf succesfully? Hi Chun-wei, I'm going through the process of adapting my MSVC projects to accommodate the fact that some old perl scripts are now python scripts (and glib-genmarshal is

Re: Generating glib-genmarshal

On 06/09/2017 17:37, Emmanuele Bassi wrote: In GLib 2.52, glib-genmarshal is a C program. In GLib master, which will become GLib 2.54 soon, glib-genmarshal is a Python program. Ah... possibly the error message needs to change then at line 35 of 'win32/gen_util_scripts.py' (in master) ?

Generating glib-genmarshal

Hi guys... python win32/gen_util_scripts.py --type=glib-genmarshal --version= If I'm building glib from git master, the above command works fine (if I issue it from a DOS window or from my MSVC project file). However... it produces an error if I try to build from the 'glib-2-52'

Re: MSVC compilation problem in git master

On 25/08/2017 10:17, Emmanuele Bassi wrote: The Visual Studio project files are not up to date, and since we're switching the build to Meson, I don't think they'll stay in tree much longer. Ooer... are you saying that Meson will be compulsory for future builds? I assumed it was an addition

MSVC compilation problem in git master

Please point me to the right place (if this isn't the correct mailing list...) I've just updated gdk-pixbuf from git master. 'gdk-pixbuf.c' used to contain this #include at line 38:- #include "gdk-pixbuf-marshal.c" However... in commit #591f959adb that got changed to this:-

Re: Building glib-genmarshal (while building glib)

On 24/08/2017 18:46, Emmanuele Bassi wrote: Could you please open a bug? Thanks Emmanuele. *Bug 786785* submitted this morning. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org

Re: Building glib-genmarshal (while building glib)

On 19/08/2017 12:16, John Emmas wrote: I still don't understand why this line (in commit #fe2a9887a8):- elif os.name == 'nt' got changed to this:- elif os.basename(filedir) == 'bin' They clearly don't do the same thing... Any thoughts anyone? Was it maybe intended

Re: Building glib-genmarshal (while building glib)

On 18/08/2017 08:38, John Emmas wrote: AFAICT this problem got introduced by commit #fe2a9887a8 - in particular the change to 'gdbus-codegen.in' (line 30) which previously looked like this:- elif os.name == 'nt': but it got changed to this:- elif os.basename(filedir

Re: Building glib-genmarshal (while building glib)

On 17/08/2017 16:48, John Emmas wrote: Any other Windows devs able to reproduce this or is it just me..? I've tried with python2.7, python3.1 and python3.3 and I see the same problem with all of them :-( AFAICT this problem got introduced by commit #fe2a9887a8 - in particular

Re: Building glib-genmarshal (while building glib)

On 16/08/2017 09:11, John Emmas wrote: Am I right in thinking that the gdbus-godegen stuff does still need to get built (i.e. generated)? [...]. The script ran fine with my older version of gdbus-codegen (and still does) But it won't work with the latest version :-( In case it's any

Re: Building glib-genmarshal (while building glib)

On 15/08/2017 11:56, John Emmas wrote: if I modify that command to substitute the new 'gdbus-codegen' (rather than the older 'gdbus-codegen.in') I get build errors. I'm guessing that maybe the command itself needs to be modified now? Or if it looks okay to you guys, I'll supply some more

Re: Building glib-genmarshal (while building glib)

On 14/08/2017 16:47, Chun-wei Fan (范君維) wrote: Take a look at this commit in GLib[1] for glib-genmarshal. So, for Windows, after running the script to generate glib-genmarshal, assuming that you are running it in cmd.exe or your Visual Studio projects, instead of running it as

Re: Building the enum-types (with or without pango-ot.h)

On 14/08/2017 18:10, Behdad Esfahbod wrote: You can ignore pango-ot.h for now. Thanks Behdad, John ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Building glib-genmarshal (while building glib)

On 12/08/2017 17:51, Bastien Nocera wrote: There's no C to generate, it's been ported to Python. So 'glib-genmarshal.exe' doesn't need to get generated any more? When I read about the port to python, I assumed it was just that the original perl scripts had been ported to python. For

Re: Building glib-genmarshal (while building glib)

On 12/08/2017 17:42, Ignacio Casal Quinteiro wrote: Hey John, Have u thought about using gvsbuild so we unite efforts building stuff with msvc? Hi Ignacio, At the moment I'm still building GTK+2 so it might not be relevant? Maybe a year or two ago, Microsoft itself was planning to

Re: Building glib-genmarshal (while building glib)

On 12/08/2017 14:04, Sébastien Wilmet wrote: >From the news file for version 2.53.4: https://git.gnome.org/browse/glib/tree/NEWS * glib-genmarshal and glib-mkenums have been rewritten in python. Every effort has been made to keep compatibility. Please report problems related to these

Call not guarded properly

After updating glib from git master today I can no longer build with MSVC. The build now fails to link because gio makes a call to 'g_openuri_portal_open_uri_finish()' (in function 'g_app_info_launch_default_for_uri_finish()') Looking around at similar calls, I reckon the function should

Re: Licensing

On 28/05/2017 14:41, Sébastien Wilmet wrote: On Wed, Apr 19, 2017 at 09:02:21AM +0100, John Emmas via gtk-devel-list wrote: the following 11 header files stipulate GPL:- gbase64.h gbookmarkfile.h gchecksum.h ghmac.h glib-private.h glib-unix.h

Licensing

Hi guys - whilst checking something else this morning I came across an anomaly in the licensing mechanism for glib / gtk+ etc. The vast majority of the header files state that it's LGPL. But occasionally there are GPL headers here and there. For example in glib-2, the following 11 header

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 usin

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

On 17/04/2017 11:25, Emmanuele Bassi wrote: Should I transfer this discussion to bugzilla here:- https://bugzilla.gnome.org/show_bug.cgi?id=780634 Please, do, detailing how you build GLib. Okay - just before I do that though, a bit more investigation might have revealed the problem...

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

On 16/04/2017 19:25, Sébastien Wilmet wrote: It's a GObject Introspection annotation !!! https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations Thanks Sébastien, I can't claim to understand it all but it seems like GObject Introspection is a way of compiling modules with one

What does "(skip)" mean ???

All of a sudden I've hit a problem when building glib with MSVC. It seems to be affecting calls to g_mkstemp() / g_getenv() and various others. Let's take g_mkstemp() as an example. It gets called in glib-genmarshal.c Prior to commit #d1528402, git master had some lines looking like this

Re: Use of lrint() in 'gdk-pixbuf/pixops/pixops.c'

On 05/02/2017 03:59, Yale Zhang wrote: I suggest adding a lrintf() fallback to fallback-c89.c too. Currently, there are 2 rounding functions in the fall backs, round() and rint() Where does fallback-c89.c come from? Some auto-generated file maybe? I can't seem to find it on my system :-(

Re: Use of lrint() in 'gdk-pixbuf/pixops/pixops.c'

On 4 Feb 2017, at 19:44, Emmanuele Bassi wrote: > > Please, file a bug against gdk-pixbuf: > > https://bugzilla.gnome.org/enter_bug.cgi?product=gdk-pixbuf > > I'd rather have a check at configure-time that looks if we have > lrint() available, and if not, provides a fallback. We used this >

Re: Use of lrint() in 'gdk-pixbuf/pixops/pixops.c'

On 04/02/2017 16:07, Martin Guy wrote: On 04/02/2017, John Emmas via gtk-devel-list <gtk-devel-list@gnome.org> wrote: I took a quick look through glib, gtk+ (v2) and gdk-pixbuf but I can't see lrint getting used anywhere else. Any chance of a fix? Thanks. The quick fix is to replac

Use of lrint() in 'gdk-pixbuf/pixops/pixops.c'

Is this the right mailing list for gdk-pixbuf issues? Commit #61e3edeb79 (6th Jan 2017) introduced these 2 calls in 'gdk-pixbuf/pixops/pixops.c' (at lines 1847 and 1848):- tmp_width = lrint (src_width * prescale_x); tmp_height = lrint (src_height * prescale_y); AFAIK Microsoft's MSVC

gdkwin32.h / gdk_win32_drawable_get_handle()

Is it permissiable to #include in client code? Here's the scenario (I discovered this in gtk-2-24 so apologies if it's been fixed in a more recent version...) 'gdk/gdkwin32.h' declares some functions, including gdk_win32_drawable_get_handle(). It isn't declared anywhere else AFAICT and

Re: Debug build compile error in 'gobject/gobject.c'

On 03/08/2016 23:07, Emmanuele Bassi wrote: Care to file a bug with a link to this thread? I'll try to come up with a patch for all the cases of this macro exploiting undefined behaviour. Thanks, I just filed bug #769504:- https://bugzilla.gnome.org/show_bug.cgi?id=769504 I'm not sure if

Re: Debug build compile error in 'gobject/gobject.c'

On 03/08/2016 18:46, Emmanuele Bassi wrote: This is likely a MSVC 8 issue. The GOBJECT_IF_DEBUG macro expands the second argument to a code block, and it seems MSVC 8 has issues when that includes a conditional pre-processor directive. GOBJECT_IF_DEBUG hasn't changed since 2014, and the same

Debug build compile error in 'gobject/gobject.c'

Hi there - I just came across a problem after updating libglib to the latest git master (my last update was about a fortnight ago). I'm building with MSVC 8 and when I try to compile 'gobject/gobject.c' the Release version compiles fine but compiling in Debug mode gives me an error around

Re: libgio (recently added source files)

On 17/07/2016 09:44, Fan, Chun-wei wrote: Hi John, Short answer is no. These are for flatpak/portal, which is for *NIX only. Hi Chun-wei. Thanks. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org

libgio (recently added source files)

I just updated from glib git master and noticed some new source files:- gio/gdocumentportal.c gio/gnetworkmonitorportal.c gio/gportalnotificationbackend.c gio/gportalsupport.c gio/gproxyresolverportal.c AFAICT they're (mostly) needed when building with Unix but I'm

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

On 04/05/2016 16:54, fanc...@yahoo.com.tw wrote: Hi John, The patch went upstream, so you should be able to build normally after you sync. With blessings! Yes, that's all building again now. Thanks. ___ gtk-devel-list mailing list

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

On 04/05/2016 16:05, fanc...@yahoo.com.tw wrote: Hi John/LRN, I opened a bug to fix the issue: https://bugzilla.gnome.org/show_bug.cgi?id=765991 That's great news. Thanks. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org

Unknown symbol in 'gio/gresource.c'

I just hit a problem when building from git master with MSVC (32-bit build). It's in 'gio/gresource.c' at line 254 in the function 'enumerate_overlay_dir()':- if (g_stat (fullname, ) == 0 && S_ISDIR (buf.st_mode)) 'S_ISDIR' is coming up as an unknown symbol. In other places where we

Error due to #including FT_ERRORS_H

Is this the right list for reporting pango development issues? Assuming it is... I updated freetype2 a few days ago (i.e. I pulled the latest source code from git) and I've just realised that pango fails to build now (with MSVC). The problem is at these lines, round about line 540 of

Re: Broken 'C' compilation when building from Master with MSVC

On 5 Nov 2015, at 11:35, Emmanuele Bassi wrote: > > On 3 November 2015 at 16:19, John Emmas <john...@tiscali.co.uk> wrote: >> As an experiment, I tried moving the inline stuff out of gutils.h and >> straight into gtypes.h (at line 391 - immediately before those n

Re: Broken 'C' compilation when building from Master with MSVC

2nd attempt - sorry if this comes through twice... On 02/11/2015 22:50, Arnavion wrote: > https://github.com/GNOME/glib/blob/236e804/glib/gutils.h#L69 > Presumably this is not being included by gtypes.h > Yeah, that's true - and fixing it kinda works but it leaves a couple of problems... 1)

Re: Broken 'C' compilation when building from Master with MSVC

On 3 Nov 2015, at 11:50, Simon McVittie wrote: > > Perhaps the "inline" stuff should move to gtypes.h, or somewhere even > lower-level, like glibconfig.h? > As an experiment, I tried moving the inline stuff out of gutils.h and straight into gtypes.h (at line 391 - immediately before those

Re: Broken 'C' compilation when building from Master with MSVC

This is my third attempt to reply to Emmanuele so apologies if this comes through in duplicate (or even triplicate!!) My posts to this list seem to frequently get lost somewhere (for some reason I've never understood). Anyway, here's what I wrote... On 02/11/2015 16:56, Emmanuele Bassi

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

Apologies if this comes through twice. The original was sent around 30 hours ago and seems to have gotten lost somewhere... On 18/10/2015 10:31, John Emmas wrote: On 16/10/2015 16:07, Fan, Chun-wei wrote: Hi Victor, Can you see whether winternl.h works for you? --- With blessings, thank you

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

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

Problems when building the latest git master with MSVC

Problem #1:- When building today's git master of 'gio/gsocket.c' (with MSVC) I'm seeing compiler errors in the function 'input_message_from_msghdr()'. The errors are all broadly similar and take the following form:- ..\gio\gsocket.c (line 3961) : error C2037: left of 'msg_name' specifies

Re: Problems when building the latest git master with MSVC

On 04/10/2015 16:29, Emmanuele Bassi wrote: On 4 October 2015 at 16:03, John Emmas <john...@tiscali.co.uk> wrote: Problem #1:- When building today's git master of 'gio/gsocket.c' (with MSVC) I'm seeing compiler errors in the function 'input_message_from_msghdr()'. The errors are all b

Re: Problem with 'gio/gwin32appinfo.c'

On 01/07/2015 16:41, LRN wrote: On 01.07.2015 17:53, John Emmas wrote: On 24/06/2015 14:52, John Emmas wrote: one way or another, 'g_app_info_reset_type_associations()' needs to get back into glib. Did that ever happen just out of interest? I'll be updating glib and glibmm in the next day

Re: Outdated win32 bundle

On 19/06/2015 00:24, Emmanuele Bassi wrote: 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*

Re: Problem with 'gio/gwin32appinfo.c'

On 24/06/2015 14:52, John Emmas wrote: one way or another, 'g_app_info_reset_type_associations()' needs to get back into glib. Did that ever happen just out of interest? I'll be updating glib and glibmm in the next day or two so it'd be helpful if I can then build them successfully again

Positioning a gdkmm window (in screen co-ordinates)

Hi guys - for getting and setting the position of a gdkmm window we have Gdk::Window::get_position() and Gdk::Window::move(). However, if I'm reading the documentation correctly, these use co-ordinates that are relative to its parent window. For getting a window's screen co-ordinates we can

Re: Problem with 'gio/gwin32appinfo.c'

On 24/06/2015 11:09, LRN wrote: Try this, please. Hi LRN and thanks for the patch. Just going back to my original email:- On 22/06/2015 16:29, John Emmas wrote: some of those functions are now coming up as missing symbols (when I try to re-build glibmm with MSVC). It looks like

Re: Problem with 'gio/gwin32appinfo.c'

On 15/06/2015 18:34, LRN wrote: On 15.06.2015 19:57, John Emmas wrote: Just querying a new MSVC build problem after updating today from git master. 'gio/gwin32appinfo.c' used to contain the following 4 x functions:- g_app_info_get_all_for_type

Re: Outdated win32 bundle

On 19/06/2015 00:24, Emmanuele Bassi wrote: 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*

Newly added 'read_resource_string()' function (glib)

I just updated from git master and noticed a newly added function (in 'gio/gwin32appinfo.c') called read_resource_string(). The section around line 516 looks like this:- resource_module = LoadLibraryExW (filename_str, 0,

Re: Problem with 'gio/gwin32appinfo.c'

On 15/06/2015 18:34, LRN wrote: These functions were not implemented during the w32 appinfo rewrite. IIRC, i haven't tried to implement them because it was not immediately clear how they should be implemented. Thanks LRN, Yeah, I think they were mostly just dummy functions but my linker

Problem with 'gio/gwin32appinfo.c'

Just querying a new MSVC build problem after updating today from git master. This is a different issue from the one I reported earlier with 'read_resource_string()' 'gio/gwin32appinfo.c' used to contain the following 4 x functions:- g_app_info_get_all_for_type()

Re: Using Python v3.3 while building Glib

On 13/05/2015 09:02, Ignacio Casal Quinteiro wrote: Hi John, are you using https://github.com/nice-software/gtk-win32/ ? If not, any reason to not use it and improve it for your use case? Thanks Ignacio. That looks like a useful resource and I should maybe consider it. For our purposes

Re: Using Python v3.3 while building Glib

On 13/05/2015 09:38, Ignacio Casal Quinteiro wrote: Hi John, basically the nice-software one is fork of the hexchat one which also adds vc 2010 projects and gtk 3. When they update the repo we rebase and we also try to keep the gtk3 ones updated. Hi Ignacio, Just out of interest - what

Re: Using Python v3.3 while building Glib

On 13/05/2015 11:16, Simon McVittie wrote: Yes. For instance http://raulcd.com/how-python-caches-compiled-bytecode.html looks like a reasonable summary. That's an excellent link Simon. Thanks for digging it out. John ___ gtk-devel-list mailing

Re: gtk-list Digest, Vol 133, Issue 13

On 13/05/2015 14:59, Bernard CANTALOUBE wrote: The application was build with mingw/gcc. Something's very wrong somewhere. Maybe this article might give you some clues:- http://www.nirsoft.net/articles/windows_7_kernel_architecture_changes.html AFAICT all the various

Re: gtk-list Digest, Vol 133, Issue 13

On 13/05/2015 16:16, John Emmas wrote: Perhaps your app doesn't need those DLLs directly - but maybe you've linked to some 3rd party library which does need them Hi Bernard, I just found another useful article about those mysterious DLLs:- https://msdn.microsoft.com/en-us/library/windows

Using Python v3.3 while building Glib

I'm building Glib (from Git) using MSVC. FWIW I use my own MSVC projects (rather than the supplied ones) although that isn't relevant here. What's relevant is that, while building libgio, a bunch of python files get converted to binary equivalents. This is all connected with gdbus-codegen

Re: gtk-list Digest, Vol 133, Issue 10

On 12/05/2015 14:00, Bernard CANTALOUBE wrote: Thanks for your answer. I did a stand alone gtk application build on an OS window7. What compiler are you building with? If it's Visual Studio (particularly one of the recent versions) it's very likely that the relevant runtime modules won't

Re: GDK_KP_Decimal (on Windows)

On 04/05/2015 16:49, LRN wrote: - *ksymp - GDK_KP_DECIMAL; break; + *ksymp = GDK_KEY_KP_Decimal; break; I just updated from gtk-2-24 git which pulled in the above change (commit #1f74f12d). Whilst the change might be technically more correct (and it matches the style for GTK+

  1   2   3   4   5   >