Re: Gtk::Widget::is_mapped ()

[John Emmas]

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 'PluginDspLoadWindow' which is getting 
displayed by Ardour but not by Mixbus for some reason.  What's failing 
is those visibility_tracker calls to 'Gtk::Widget::is_mapped()' (and 
that's why I was asking what the call does...)


Anyway, this is off-topic now for the gtk-devel list.  If I make any 
progress with it, I'll either file a bug report or maybe join you on IRC 
sometime.  Best regards,


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

Re: Gtk::Widget::is_mapped ()

[John Emmas]

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 realized
 - all its ancestors up to the top level window are mapped

Thanks Emmanuele - can I just check 'is_visible()'?  Does it mean 
'literally visible' or 'capable of being visible'?


For example... let's say the widget is a top-level window.  If it's 
currently displayed on screen but there's some other window hiding it 
(maybe from a totally different app) would 'is_visible()' return true or 
false?


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

Gtk::Widget::is_mapped ()

[John Emmas]

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

[John Emmas]

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 accesses the variable sees a distinct 
or "thread-local" version of it.

.


Thanks Paul - so would a typical use case be for static members of a 
class? In normal circumstances, a static class member has the same value 
for all instances of the class. But maybe (in this case) 2 objects 
running in different threads could each have different values?


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

Glib::Threads:Private

[John Emmas]

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 thread was 
running when Glib::Threads:Private got called?  Hope that makes sense


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

Re: What (or where) is LSTATUS ?

[John Emmas]

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 !


If it's absolutely essential, just let me know what an 'MR' is and where 
I'll need to create it (I'm just an ordinary user BTW - not one of the 
developers).  Many thanks,


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

What (or where) is LSTATUS ?

[John Emmas]

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 find out 
from MSDN where exactly LSTATUS is defined (and #including windows.h 
didn't seem to help either).  Anyone know what I need to do to get LSTATUS ?


I assume it's defined as LONG somewhere...

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

Re: An alternative to gdk-pixbuf

[John Emmas]

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
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: An alternative to gdk-pixbuf

[John Emmas]

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


Do you happen to know if the tiff library has its own mailing list? I 
haven't had much success in finding one




In fact I'll need the mailing list for gdk-pixbuf now - except that I 
can't find that one either!! (or is this the correct place for reporting 
gdk-pixbuf issues?)


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

Re: An alternative to gdk-pixbuf

[John Emmas]

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 
struct alignment.  Although I'm building on Windows, I currently compile 
both tiff and gdk-pixbuf with 1-byte struct alignment which seems to 
work for png / jpeg etc.  But maybe tiff expects 8-byte alignment?


Do you happen to know if the tiff library has its own mailing list? I 
haven't had much success in finding one


John

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

Re: An alternative to gdk-pixbuf

[John Emmas]

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 morning.


If someone's got a few spare minutes, could they try loading the 
attached image using 'gdk_pixbuf_new_from_file()' and just let me know 
if it works?  I'm sure this always worked for me in the past... :-(


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

Re: Problems with git.gnome.org

[John Emmas]

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: 
unable to connect to gitlab.gnome.org"


Is the remote at 'git://gitlab.gnome.org' or somewhere else (https:// 
maybe) ?


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

Problems with git.gnome.org

[John Emmas]

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). 
Here's what I see...


Looking up git.gnome.org ... done.
Connecting to git.gnome.org (port 9418) ... fatal: unable to 
connect to git.gnome.org

git.gnome.org[0: 209.132.180.168]: errno=No error
git.gnome.org[1: 209.132.180.180]: errno=No error

At first I assumed the repos were down temporarily but it's not getting 
any better so I'm guessing the libraries have been moved somewhere 
else?  So do I maybe need to change something at my end?


It doesn't seem to be affecting all my gtk support libs BTW - just some 
of them... Thanks,


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

Re: Problem accessing gtk-2-24

[John Emmas]

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/gtk



Thanks LRN - are any other repos affected (glib etc?)  If this got 
announced somewhere, I must have missed it  :-(


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

Problem accessing gtk-2-24

[John Emmas]

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.
  fatal: Could not read from remote repository.

  Please make sure you have the correct access rights
  and the repository exists.

Is it no longer hosted at git.gnome.org maybe?

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

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

[John Emmas]

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, thanks.

I installed fribidi (from (git) and decided to use it as my first
foray into building with meson.


I haven't used meson, so someone else should jump in.


No problem - I've just posted the same question on the fribidi mailing 
list but if anyone here can help with msvc/meson builds, I'd appreciate 
any advice.  Thanks,


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

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

[John Emmas]

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


 meson builddir && cd builddir

According to the quick guide, meson will produce VC and XCode project 
files.  It did produce a "builddir" subdirectory but the builddir seems 
to be mostly empty.  It's built something called 'sanitycheck.exe' but 
I'm not seeing a built library, nor any project files for building one.  
This is my first attempt at meson so I'm probably doing something 
stupid.  Do I need to use a different command?


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

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

[John Emmas]

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 - such as 
'pango_log2vis_get_embedding_levels()'.  However, 'pango-bidi-type.c' 
#includes  which doesn't exist any more.


Or does mini-fribidi now need to get built as a separate library? Thanks,

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

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

[John Emmas]

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://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[John Emmas]

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 from Glib to 
generate some source files - notably, 'gtk/gtkmarshal.c'. That's the 
bit that's stopped working.




Should I file a bug report about this (or is there one already open?)

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

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

[John Emmas]

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 provided by GLib.



Hi Emmanuele,

That commit was already present when I tried this morning but to be 
absolutely certain, I just re-built Glib and Gtk-2 again Unfortunately 
though, the problem is still present... :-(


Just 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 from Glib to generate 
some source files - notably, 'gtk/gtkmarshal.c'.  That's the bit that's 
stopped working.


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

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

[John Emmas]

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 former .exe version of the 
tool




I went back to using glib-genmarshal.exe temporarily but strangely - 
AFAICT it never generated those missing functions 
(gtk_marshal_VOID__BOXED / gtk_marshal_VOID__ENUM etc. etc.)  However... 
by a fortunate coincidence back then, 'gtk.symbols' wasn't trying to 
export them either.  So the fact that they didn't exist just never got 
noticed.


So what about the Python build?  Did that one ever generate those 
functions?  Well, yes - it seems like it did generate them initially...


I still have an older version of glib-2-54 available, dating from the 
middle of November 2017 (note: Glib, not Gtk2).  If I restore my 
November 2017 version of Glib, the Gtk build (python version) suddenly 
starts working again (in other words, 'gtk_marshal_VOID__BOXED' and all 
those others functions do now get generated).  But if I update to my 
most recent version of Glib from a few days ago (regardless of whether I 
select glib-2-54 or glib master) 'glib-genmarshal' always generates its 
files with those particular functions missing.


In my November 2017 version, the most recent commit for 
'gobject/glib-genmarshal.in' is:- is #100b83a7fa ("genmarshal Only wrap 
body prototypes in C++ guards").  But a couple of further commits got 
added since then.  I'm pretty certain one of those new commits has 
introduced this problem.. :-(


Sorry about the long-winded explanation.!  If anyone thinks it seems 
plausible, I'll condense it down and file a proper bug report.


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

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

[John Emmas]

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

Will give this a try on Wednesday or Thursday...

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

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

[John Emmas]

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 version of the tool, and perhaps file a bug 
against the Python version of glib-genmarshal?




Hi fanc,

Currently, I do build gtk/gtkmarshalers.[c]h] using python   I can try 
going back to the exe builder but I'm about to go away for a couple of 
days.  It'll be Wednesday before I get a chance to try this.




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.  However...


I managed to find an older copy of 'gtk/gtkmarshal.c' (generated by the 
old perl script).  That one does contain a function called 
'gtk_marshal_VOID__ENUM' (as well as all the other missing ones, such as 
'gtk_marshal_VOID__BOXED').  However, they aren't contained in the newer 
(python generated) 'gtkmarshal.c' (not here, anyway). While I'm away, 
maybe you can check to see if they get included in your version?  Thanks,


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

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

[John Emmas]

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 bug against the Python version 
of glib-genmarshal?




Hi fanc,

Currently, I do build gtk/gtkmarshalers.[c]h] using python   I can try 
going back to the exe builder but I'm about to go away for a couple of 
days.  It'll be Wednesday before I get a chance to try this.


In the meantime, I noticed that the missing symbols are kinda #defined 
in gtkmarshalers.h (except using underscores).  So whereas I see errors 
like this:-


    gtk.def : error LNK2001: unresolved external symbol 
gtk_marshal_VOID__BOOLEAN
    gtk.def : error LNK2001: unresolved external symbol 
gtk_marshal_VOID__BOXED
    gtk.def : error LNK2001: unresolved external symbol 
gtk_marshal_VOID__ENUM


Those exact symbols aren't defined anywhere - but underscored versions 
are defined in 'gtkmarshalers.h':-


    #define _gtk_marshal_VOID__BOOLEAN g_cclosure_marshal_VOID__BOOLEAN
    #define _gtk_marshal_VOID__BOXED g_cclosure_marshal_VOID__BOXED
    #define _gtk_marshal_VOID__ENUM g_cclosure_marshal_VOID__ENUM

Does that help to explain anything ?

John

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

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

[John Emmas]

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 #331877fe36 (Fix abicheck):-


  gtk_marshal_VOID__BOOLEAN
  gtk_marshal_VOID__BOXED
  gtk_marshal_VOID__ENUM
  gtk_marshal_VOID__INT
  gtk_marshal_VOID__OBJECT
  gtk_marshal_VOID__POINTER
  gtk_marshal_VOID__STRING
  gtk_marshal_VOID__UINT
  gtk_marshal_VOID__VOID

Like I said, I'd always assumed that 'gtk.symbols' was needed for 
generating a module definition file ('gtk.def') as that's generally what 
a symbols file gets used for (with MSVC).


If the module definition file isn't needed any more, just ignore this 
(gtk-2-24 seems to link okay without it).  But if it _is_ still used, 
MSVC now produces the following linker errors:-


gtk.def : error LNK2001: unresolved external symbol 
gtk_marshal_VOID__BOOLEAN
gtk.def : error LNK2001: unresolved external symbol 
gtk_marshal_VOID__BOXED
gtk.def : error LNK2001: unresolved external symbol 
gtk_marshal_VOID__ENUM
gtk.def : error LNK2001: unresolved external symbol 
gtk_marshal_VOID__INT
gtk.def : error LNK2001: unresolved external symbol 
gtk_marshal_VOID__OBJECT
gtk.def : error LNK2001: unresolved external symbol 
gtk_marshal_VOID__POINTER
gtk.def : error LNK2001: unresolved external symbol 
gtk_marshal_VOID__STRING
gtk.def : error LNK2001: unresolved external symbol 
gtk_marshal_VOID__UINT
gtk.def : error LNK2001: unresolved external symbol 
gtk_marshal_VOID__VOID


Taking 'gtk_marshal_VOID__ENUM' as an example, 'gtk/gtkmarshalers.c' 
contains some variants - e.g.


gtk_marshal_VOID__ENUM_BOOLEAN
gtk_marshal_VOID__ENUM_ENUM
gtk_marshal_VOID__ENUM_FLOAT
gtk_marshal_VOID__ENUM_FLOAT_BOOLEAN

along with a few others- but I can't find one that's just called 
'gtk_marshal_VOID__ENUM' (hence the linker error if it it gets included 
in gtk.symbols).


Hope this all makes sense...

John

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

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

[John Emmas]

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, I always need to edit them to remove the period - i.e.

  from whatever import something

So typically, I can have 4 or 5 such conflicts in any given python 
script.  TortoiseGit has an option which effectively means "resolve all 
conflicted lines using my version".  But I've just realised that it 
doesn't confine itself to overwriting the conflicted lines - it actually 
substitutes my whole file (and therefore loses any non-conflicted changes!!)


Now I'm past that point I've encountered a new problem (when compiling 
the recently added 'gnetworkmonitorwindows.c').  On my system (MSVC) it 
seems to be #including the wrong version of "iphlpapi.h" and is 
consequently failing to pick up one of the symbols (IP_ADDRESS_PREFIX) 
which is needed by function 'win_network_monitor_get_ip_info()'.


That'll have to wait for another day though... :-(

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

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

[John Emmas]

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 that's because I push things to my own repo).

I'll look a bit further into this and see if I can figure out what's 
gone wrong. Thanks,


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

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

[John Emmas]

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 logging messages).


My last 'pull' did flag up some conflicts though - so maybe I didn't fix 
one of them correctly? (or did that change come after the above commit?)


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

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

[John Emmas]

I'm not yet building with meson so forgive me if this is just down to my 
build system being out-of-date !!


The problem happens when I try to build glib/gio from yesterday's git 
master.  More specifically it happens when building the 'gdbus-codegen' 
stuff.  'The file 'gdbus-2.0/codegen/codegen_docbook.py' contains this 
at line 33:-


  class DocbookCodeGenerator:
  def __init__(self, ifaces):  // <--- NOTE THIS CHANGE !!
  self.ifaces = ifaces

  // etc. . .

Previously it looked like this:-

  class DocbookCodeGenerator:
  def __init__(self, ifaces, docbook, outdir):  //<--- ORIGINAL 
LINE !!

  self.ifaces = ifaces

  // etc. . .

But in the file 'gdbus-2.0/codegen/codegen_main.py' it seems to be 
getting called like this, at line 186:-


  docbook_gen = 
codegen_docbook.DocbookCodeGenerator(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 mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Do I need to #define GLIB_CHARSETALIAS_DIR ?

[John Emmas]

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_CHARSETALIAS_DIR.  */
  #ifndef GLIB_CHARSETALIAS_DIR
  # include "configmake.h"
  # define GLIB_CHARSETALIAS_DIR LIBDIR
  #endif

My MSVC build is now failing because 'configmake.h' doesn't exist on my 
system.  Do I need to get it from somewhere?  Or do I need to #define 
GLIB_CHARSETALIAS_DIR to something?  Thanks,


John
(P.S. I'm not using 'make' BTW).
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

glib compilation problems when building from git master with MSVC

[John Emmas]

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 not in my version (VC8).


2) gstdio.c uses some other identifiers too - notably, 
'FILE_STANDARD_INFO' and 'FILE_NAME_NORMALIZED'.  These seem to be 
declared in winbase.h which should (in theory) be getting #included by 
windows.h.  However, MSVC reports them both as undeclared identifiers 
(even if I specifically #include winbase.h !!)


Is there some new #define needed which I maybe don''t know about ??

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

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

[John Emmas]

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 "Supported Compiler, Platform and related software".




Thanks Fanc (I'm never quite sure what to call you !)

For Windows programming, I've always been wary of trying to 
"mix-and-match" between different MSVC libraries (regardless of that 
Microsoft says!).  So how about this for a compromise...


If the idea is to drop support for Win-XP (and yet retain support for 
VS2005) we could achieve it with some quite simple changes. Only 2 or 3 
files would need to get changed and it's mostly just stuff like this...


wherever we currently use this:-

#if _WIN32_WINNT < 0x0600

we'd change it to this:-

#if (_WIN32_WINNT < 0x0600 || (defined(_MSC_VER) && _MSC_VER < 
1500))


I'd be happy to produce a full patch if you like.  I've already tried it 
here with VS2005 and glib is now building fine again.  Best regards,


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

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

[John Emmas]

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 the quick response.

It looks like I have VS2005 installed and also the corresponding DirectX 
SDK.  I can't see any other SDK's that are specific to VS2005.


I'm assuming you're referring to this SDK?

https://www.microsoft.com/en-us/download/details.aspx?id=11310

If so, it seems to depend on VS2008 SP1 so are you really sure those 
SDK's would be compatible with VS2005?  StackOverflow suggests they 
aren't...


https://stackoverflow.com/questions/171816/vc9-and-vc8-lib-compatibility

2005 and 2008 will use different CRT modules and you can't normally link 
stuff to two different CRT libraries.   I'd be a bit surprised if 
they're compatible... :-(


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

FILE_NAME_INFO struct in 'glib/gmessages.c'

[John Emmas]

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 referenced in the function 'win32_is_pipe_tty()'


Similarly... HAVE_IF_NAMETOINDEX is defined to '1' in a couple of places 
- which means that in 'gio/gsocket.c' the function 'if_nametoindex()' is 
NOT defined.  But again it gets called in a couple of places.  It looks 
like the Glib definition was maybe intended to support older versions of 
MSVC (I'm using VC-8).  So does this mean that VC-8 will be getting 
dropped soon?  Thanks,


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

Re: Generating glib-genmarshal

[John Emmas]

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 
(and glib-genmarshal is now a python script too). Gdk-pixbuf (and 
Gtk+2) are both on my radar for this afternoon so I'll let you know 
how I get on!




Hi Chun-wei,

gdk-pixbuf and gdk+2 both built fine for me.  The only odd thing I 
noticed was when building gtk (from gtk-2-24) I saw quite a few warning 
messages looking like this:-


  WARNING: The token "BOOL" is deprecated; use "BOOLEAN" instead
  WARNING: The token "NONE" is deprecated; use "VOID" instead

They're probably nothing to worry about (I think they might be coming 
from 'gtk/gtkmarshal.list').  In fact it's possible they've always been 
there but I don't remember noticing them before...


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

Re: Generating glib-genmarshal

[John Emmas]

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 now a python script too). Gdk-pixbuf (and Gtk+2) 
are both on my radar for this afternoon so I'll let you know how I get 
on! Regards,


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

Re: Generating glib-genmarshal

[John Emmas]

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


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

Generating glib-genmarshal

[John Emmas]

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' branch.  Is 
that to be expected?


In case it helps, the error message that I see is:-

File "win32/gen_util_scripts.py", line 30, in main
   raise ValueError('Type must be glib-mkenums or gdbus-codegen')

It's probably something that's been changed in 2-52 but not merged into 
master yet.  Anyway... just flagging it up,


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

Re: MSVC compilation problem in git master

[John Emmas]

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 to the existing build systems, rather than 
a replacement.


What will happen for those of us who need the MSVC debugger?  AFAIK it's 
only available if you build using Microsoft's VC project/sln files (or 
does Meson generate them maybe?


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

MSVC compilation problem in git master

[John Emmas]

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

  #include "gdk-pixbuf-marshal.h"

and the explanation given was "Do not include the source, otherwise 
we're going to compile symbols twice".  Unfortunately though, when 
building with MSVC, I now get unresolved symbols (due to the fact that 
gdk-pixbuf-marshal.c isn't getting compiled any more).  I'm probably 
missing something obvious but how does it get compiled now?  I can't see 
it in any of the Visual C++ projects...


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

Re: Building glib-genmarshal (while building glib)

[John Emmas]

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
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building glib-genmarshal (while building glib)

[John Emmas]

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 to be this..?

elif os.basename(filedir) != 'bin'
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building glib-genmarshal (while building glib)

[John Emmas]

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) == 'bin'

Changing that line back again fixes the problem for me.



Maybe this'll make sense to someone... just after the following line (in 
'gdbus-codegen.in'):-


  sys.path.insert(0, os.path.abspath(path))

I inserted another line, like so:-

  print(sys.path)

On my system, this outputs a path string which happens to start with the 
following folder (notice the double backslashes):-


  F:\\GTK-SOURCES\\gnu-windows\\src\\MB3Glib\\gio\\gdbus-2.0

AFAICT the double-backslashes aren't contributing to the problem. The 
problem only occurs if that specific path is in my list of path strings 
(any other paths work fine).


I guess this could end up being a problem on my particular system - or 
maybe that specific path causes some build problem (an infinite loop maybe?)


Having said all that, 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?  John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building glib-genmarshal (while building glib)

[John Emmas]

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 
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) == 'bin'

Changing that line back again fixes the problem for me.  I haven't yet 
tried linking anything to the built libraries - but the build itself now 
completes successfully.  My guess is that whoever made that change is 
possibly cross-building (from Linux?) whereas a genuine Windows build 
won't work any more.


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

Re: Building glib-genmarshal (while building glib)

[John Emmas]

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 help, it seems to be bombing out at line 196 of 
'codegen_main.py' - where I get this output:-


  line 196, in codegen_main
gen = codegen.CodeGenerator(all_ifaces,
  AttributeError: 'module' object has no attribute 'CodeGenerator'



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


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

Re: Building glib-genmarshal (while building glib)

[John Emmas]

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 information about 
the errors I'm seeing.




Am I right in thinking that the gdbus-godegen stuff does still need to 
get built (i.e. generated)?  Here's the command that I'm using:-


  python "gdbus-2.0/codegen/gdbus-codegen" --interface-prefix org. \
 --generate-c-code gdbus-daemon-generated --c-namespace 
_G dbus-daemon.xml


Is there anyone building on Windows who could try that command for me? 
As long as the relevant paths are set up, it'll work from a Command 
Prompt (though you'd need to get rid of the backslash and put everything 
on the same line).


I run it from this folder:-

  \Glib\gio

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 help, it seems to be bombing out at line 196 of 
'codegen_main.py' - where I get this output:-


  line 196, in codegen_main
gen = codegen.CodeGenerator(all_ifaces,
  AttributeError: 'module' object has no attribute 'CodeGenerator'

Thanks...

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

Re: Building glib-genmarshal (while building glib)

[John Emmas]

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 "glib-genmarshal(.exe) arguments to it>", you do " glib-genmarshal> ", as you would running a 
Python script.  Note that I dropped the projects to build 
glib-genmarshal.exe from the Visual Studio projects.


You have to do likewise for glib-mkenums, by changing "interpretor>  ..." to " 
 ..."




Ah, I get it now!  Thanks guys.

Two of the three python scripts are working fine now but there's a 
problem with gdbus-codegen.  Here's the command I previously used with 
the older file (gdbus-codegen.in) :-


  python "gdbus-2.0/codegen/gdbus-codegen.in" --interface-prefix org. \
 --generate-c-code gdbus-daemon-generated --c-namespace 
_G dbus-daemon.xml


but 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 information about the 
errors I'm seeing.  Thanks again,


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

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

[John Emmas]

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)

[John Emmas]

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 glib-mkenums, the 'C' files are still getting generated, I think 
(gioenumtypes.c + gioenumtypes.h) ?.  Maybe I'm wrong about that...


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

Re: Building glib-genmarshal (while building glib)

[John Emmas]

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 release an 
"official" version of the GTK stack for Windows. Dunno whatever happened 
to it...


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

Re: Building glib-genmarshal (while building glib)

[John Emmas]

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 tools



Thanks Sebastien,

Although I'm building with MSVC I don't use the official MSVC projects 
(mostly because I need to build 3 x targets:- 1) Debug build, 2) Release 
build and 3) Debuggable Release build).  I've figured out how to 
generate the file called "glib-genmarshal" - namely,


python.exe  gen_util_scripts.py --type=glib-genmarshal 
--version=$(GlibVersion)


But I'm then stuck...  I can't figure out how to use that file to 
generate 'glib-genmarshal.c' (and/or any other files which need to get 
generated from it).  Can someone tell me the relevant command?  It isn't 
likely that this issue will affect anyone else.  Thanks,


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

Call not guarded properly

[John Emmas via gtk-devel-list]

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 maybe look 
like this:-


gboolean
g_app_info_launch_default_for_uri_finish (GAsyncResult *result,
GError   **error)
{
#ifdef G_OS_UNIX  // <--- This guard added by me 
  return g_openuri_portal_open_uri_finish (result, error);
#endif
  return FALSE;  // <--- and this added by me 
}

Should I flag this up in bugzilla or have I misunderstood something?

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

Re: Licensing

[John Emmas via gtk-devel-list]

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
   gmain.h
   gmain-internal.h
   gmessages-private.h
   goption.h
   gpoll.h

Just thought I'd flag it up in case it's unintentional,

I've checked the 3 first files that you list, and they are correctly
licensed under the LGPL (up until recently it was the "GNU Library
General Public License", it's now the "GNU Lesser General Public
License").

Please double check the list.



Hi Sebastien,

I updated from git master just now and the above files are all okay 
now.  However, in the latest stable branch (glib-2-52 ?) they're still 
showing the older licenses.


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

Licensing

[John Emmas via gtk-devel-list]

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 files stipulate GPL:-


  gbase64.h
  gbookmarkfile.h
  gchecksum.h
  ghmac.h
  glib-private.h
  glib-unix.h
  gmain.h
  gmain-internal.h
  gmessages-private.h
  goption.h
  gpoll.h

Just thought I'd flag it up in case it's unintentional,

John

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

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

[John Emmas via gtk-devel-list]

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

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

[John Emmas via gtk-devel-list]

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...


I'm building with VS8, using my own vcproj files.  Essentially they're 
the same as the official ones except that as well as building a Debug 
target and a Release target, I also build a "Debuggable Release" 
target.  Apart from that there are only minor differences - for example 
when I build the Debug modules I append a letter "D" to the target name 
(in line with what normally gets done when building with MSVC).


Here's where it gets interesting... 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!


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

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

[John Emmas via gtk-devel-list]

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 language such that 
they can be used by some different language.  If I use "dumpbin 
/EXPORTS" on my built DLL, I see these entries:-


755  2F2 2680 g_mkstemp = @ILT+5755(_g_mkstemp)
756  2F3 132A g_mkstemp_full = @ILT+805(_g_mkstemp_full)
757  2F4 1870 g_mkstemp_utf8 = @ILT+2155(_g_mkstemp_utf8)

so all three functions are getting exported - BUT - if I examine the 
corresponding link lib, I can see a reference to g_mkstemp_full(). I can 
also see a reference to g_mkstemp_utf8().  But there's no reference to 
g_mkstemp().  In other words, although that function does get exported 
from the DLL, the accompanying link lib doesn't seem to know about it.  
I've never seen anything like that before but I'm guessing (maybe 
wrongly) it wouldn't have anything to do with Introspection??


I've also discovered that if I revert the changes from commit 
#d1528402,it fixes the problem for g_mkstemp().  So I'm assuming that if 
I reverted Christoph's other changes from that time, it'd fix the other 
problems I'm seeing with g_getenv() etc.


Should I transfer this discussion to bugzilla here:-

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

Also - has anyone else managed to build this successfully with MSVC?  
Maybe there's a new #define somewhere that I need to know about?


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

What does "(skip)" mean ???

[John Emmas via gtk-devel-list]

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 
(in 'gfileutils.h'):-


#ifndef __GTK_DOC_IGNORE__
#ifdef G_OS_WIN32
#define g_file_test   g_file_test_utf8
#define g_file_get_contents g_file_get_contents_utf8
#define g_mkstemp  g_mkstemp_utf8

// and a few others

#endif /* G_OS_WIN32 */
#endif /* __GTK_DOC_IGNORE__ */

so in the past (when building for WIN32) calls to 'g_mkstemp()' got 
converted to use 'g_mkstemp_utf8()' instead.  But now that the above 
lines have been removed, 'g_mkstemp()' is coming up as an unresolved 
symbol when I try to link the glib-genmarshal DLL.  I'm a bit baffled 
about this because it does seem to be getting exported from libglib (so 
I don't understand why it can't be imported).  Maybe there's some 
confused linkage somewhere??


However... in gfileutils.c, I see a comment, looking like this:-

/**
 * g_mkstemp: (skip)
 * @tmpl: (type filename): template filename
 *
 * Opens a temporary file. See the mkstemp() documentation
 *
 *   // some other stuff
 *
 */

So I'm wondering - what's the significance of the word "skip" here??  I 
can't see any obvious reason why this isn't linking but maybe that'll 
give me a clue...


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

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

[John Emmas via gtk-devel-list]

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

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

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

[John Emmas via gtk-devel-list]

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
> approach in GTK+ 3.x, and it makes it easier to remove the code once
> we decide to bump the compiler requirements, like we did in GTK+
> master.
> 

Thanks Emmanuele - just filed bug #778181

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

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

[John Emmas via gtk-devel-list]

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 replace them with

   tmp_width = (int) (src_width * prescale_x + 0.5);
   tmp_height = (int) (src_height * prescale_y + 0.5);



Thanks Martin,

Are you able to make those changes upstream?  I can change the lines 
locally but I wouldn't be able to push to git master.  Thanks,


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

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

[John Emmas via gtk-devel-list]

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 only introduced lrint() in VS2015 - so for those 
of us building with an earlier version the above code won't link any 
more.  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,


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

gdkwin32.h / gdk_win32_drawable_get_handle()

[John Emmas via gtk-devel-list]

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 there's an accompanying macro called GDK_WINDOW_HWND.  A #ifdef test 
(called INSIDE_GDK_WIN32) makes the macro call that function if the 
build is _not_ INSIDE_GDK_WIN32.  So it looks like it's allowable to 
#include  from within client code.


HOWEVER... gdkwin32.h #includes gdk/gdkprivate.h (which I'd guess is NOT 
supposed to get #included in client code).


Just wanted to check if #including a private header is okay in client code.

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

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

[John Emmas]

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 it's technically a blocker but I marked it as a blocker 
because it prevents compilation. :-)


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

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

[John Emmas]

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 commit
introduced the use you see failing.



That's what confused me.  The last commit date for gobject.c seems to be 
25th May 2014 and yet the same code section looked like this only a 
fortnight ago:-


#ifdef  G_ENABLE_DEBUG
IF_DEBUG (OBJECTS)
  {
debug_objects_ht = g_hash_table_new (g_direct_hash, NULL);
#ifndef G_HAS_CONSTRUCTORS
g_atexit (debug_objects_atexit);
#endif /* G_HAS_CONSTRUCTORS */
  }
#endif/* G_ENABLE_DEBUG */

The above code compiles okay (or at least, it did a fortnight ago) and 
VC8 is supposedly a supported compiler, so will a fix be possible?


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

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

[John Emmas]

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 these lines at the end of function 'void 
g_object_type_init (void) (approximately line 400):-


  GOBJECT_IF_DEBUG (OBJECTS,
  {
  debug_objects_ht = g_hash_table_new (g_direct_hash, NULL);
#ifndef G_HAS_CONSTRUCTORS
  g_atexit (debug_objects_atexit);
#endif /* G_HAS_CONSTRUCTORS */
  });

The error I see is:-

  gobject\gobject.c(403) : error C2121: '#' : invalid character : 
possibly the result of a macro expansion


AFAICT gobject.c itself hasn't changed recently so is it possible that 
GOBJECT_IF_DEBUG has changed somehow?  The Release build compiles okay 
so I guess that seems plausible.  Thanks,


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

[John Emmas]

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
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

libgio (recently added source files)

[John Emmas]

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 not sure 
about 'gnetworkmonitorportal.c' and 'gproxyresolverportal.c'. Are they 
needed when building with MSVC?  I use my own MSVC projects, rather than 
the official ones so I need to know whether or not to add them.  Thanks,


John
___
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'

[John Emmas]

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
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[John Emmas]

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
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Unknown symbol in 'gio/gresource.c'

[John Emmas]

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 
use S_ISDIR we usually have something like this near the top of the file:-


  #ifdef G_OS_WIN32
  #include 
  #ifndef S_ISDIR
  #define S_ISDIR(m) (((m) & _S_IFMT) == _S_IFDIR)
  #endif
  #endif

and if I add that near the top of 'gio/gresource.c' it fixes the 
problem.  Just passing it upstream.  Regards,


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

Error due to #including FT_ERRORS_H

[John Emmas]

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 
'pango/pangoft2.c':-


  static const ft_error_description ft_errors[] =
#include FT_ERRORS_H

#undef FT_ERRORDEF
#undef FT_ERROR_START_LIST
#undef FT_ERROR_END_LIST

  ft_error_description *found = /* <-- ERROR HERE !!! */
bsearch (, ft_errors, G_N_ELEMENTS (ft_errors),
 sizeof (ft_errors[0]), ft_error_compare);

MSVC gives me:-  'error C2275: 'ft_error_description' : illegal use of 
this type as an expression'.  To be honest, I suspect that the actual 
error might be a few lines earlier - i.e.


  static const ft_error_description ft_errors[] =
#include FT_ERRORS_H

My best guess is that something got changed somewhere in 
'freetype/fterrors.h'.  It does look like something got done (about a 
week ago) to remove underscores from some macro names but I'm not sure 
why that would cause this problem.  Can anyone hazard a guess at what 
might be wrong?  Thanks,


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

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

[John Emmas]

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 newly added 
>> functions).  As far as MSVC was concerned it was perfectly happy - no other 
>> changes were needed.  [...]  I can produce a patch if anyone wants to test 
>> it with gcc etc.
> 
> Could you please leave a comment on the bug I linked to earlier in the
> thread, detailing what you found?
> 

Hi Emmanuele,

I just added a comment as well as attaching a patch in case anyone wants to 
test the non-msvc compilation.  Thanks.

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

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

[John Emmas]

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) Firstly, it needs to get #included quite a long way down (around line 95 of 
gtypes.h).  The reason for this is that the two headers have mutual 
dependencies - i.e. gutils.h needs some types which are defined in gtypes.h and 
vice versa.

2) Because of the above, some other source files are now fussy about which 
order we #include gtypes.h versus gutils.h

I think I'm reaching the conclusion that these new functions 
(_GLIB_CHECKED_ADD_U32 etc) have simply been placed in the wrong header file.  
Maybe they need to be in gutils.h rather than gtypes.h?  I don't mind 
experimenting and moving them somewhere else temporarily if anyone can suggest 
a better location.  Thanks,

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

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

[John Emmas]

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 newly added functions).  
As far as MSVC was concerned it was perfectly happy - no other changes were 
needed.  But I guess there could (potentially) be knock-on effects for other 
compilers (unlikely perhaps - but non-msvc builds would definitely need to get 
tested).  Hopefully though, there wouldn't be any issues for user apps because 
the very first thing gutils.h does is to #include gtypes.h !!

This idea does seem like a good compromise to me and it does work for MSVC.  
It'll get my vote if the other compilers are happy too.  I can produce a patch 
if anyone wants to test it with gcc etc.

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

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

[John Emmas]

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 wrote:
> you should try the patch attached to this bug:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=503096#c26
> 
> and see if it fixes the issue for you.
> 

Thanks for the quick reply Emmanuele.

If you're referring to the problem with G_STATIC_ASSERT it's not relevant in my 
case because _GLIB_HAVE_BUILTIN_OVERFLOW_CHECKS doesn't seem to be defined 
anywhere.  However, if I explicitly #define it (and then apply the patch) that 
doesn't help.  I then just see the same error occur at line 417 instead of 427.

I've a strange feeling that we might need underscores here with MSVC 'C'.  The 
compiler seems happy with "_inline" and "__inline" - but "inline" is only 
accepted when building as C++.  I must admit, that comes as a bit of a 
surprise!!

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

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

[John Emmas]

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.




Just bumping this in case Victor didn't see it.

Chun-wei - if you add a #include for winternl.h I don't think you'll 
need it in master as well.  It only seems to be needed in the 
'glib-2-44' branch AFAICT.  Hope I haven't missed something!


I can just add it locally if it causes any problems.  Thanks again.

John


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

[John Emmas]

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

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

[John Emmas]

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

Problems when building the latest git master with MSVC

[John Emmas]

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 
undefined struct/union 'msghdr'


That function - 'input_message_from_msghdr()' - looks similar 
(conceptually) to 'input_message_to_msghdr()' and also to 
'output_message_to_msghdr()'.  But one crucial difference is that those 
latter two are getting implemented as #defines (whereas the first one is 
getting implemented as an actual function).  AFAICT none of them 
actually gets used if G_OS_WIN32 is defined (although the function 
itself does get included in a compilation).


So should the first one be getting implemented like the other two? Or 
should it be getting guarded with #ifndef G_OS_WIN32?  Or should we be 
declaring a 'msghdr' struct somewhere?  Whatever's wrong, it looks like 
this must have happened very recently.


Problem #2:-  Line 4469 (of the same file) calls 
'g_socket_send_message_with_timeout()' which my linker reports as an 
unresolved symbol.  Where does that function come from?  Thanks.


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

Re: Problems when building the latest git master with MSVC

[John Emmas]

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 broadly similar and take
the following form:-

..\gio\gsocket.c (line 3961) : error C2037: left of 'msg_name' specifies
undefined struct/union 'msghdr'

Please, file a bug on:

   https://bugzilla.gnome.org/enter_bug.cgi?product=glib=network



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

Re: Problem with 'gio/gwin32appinfo.c'

[John Emmas]

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 or two so it'd be helpful if I can then build
them successfully again.  Thanks.

Nothing happened.



Thanks LRN - it's a pity, considering the other functions got 
re-instated so easily.


Is there some kind of problem to put that one back again?  If so, I'll 
see if I can find it in an old backup and just restore it locally.  Thanks.


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

Re: Outdated win32 bundle

[John Emmas]

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* *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.



As an aside...  whatever happened to Microsoft's interest in all this??

Around 2 years ago a guy from MS visited this list to let us know about 
their CoApp project.  From what I can remember, they were getting 
worried about the number of people building the GTK stack for Windows.  
They didn't have anything against GTK.  What worried them was that all 
these competing builds would end up bringing back DLL Hell which MS 
itself has worked very hard to get rid of!  The proposal was to have one 
official source for Gtk-Win which would be hosted by MS (and delivered 
by some kind of app that would be similar to apt-get).  They were 
planning to use a distribution based on the existing HexChat repos.  The 
initial conversations involved me, Arnavion, Tarnyko and a few others - 
but it soon went very quiet.


Anyone know if it's still ongoing?

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

Re: Problem with 'gio/gwin32appinfo.c'

[John Emmas]

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.  Thanks.


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

Positioning a gdkmm window (in screen co-ordinates)

[John Emmas]

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 call Gdk::Window::get_origin().


I'm sure I'm just not seeing something - but what's the complementary 
function to Gdk::Window::get_origin()?  How can I position a gdkmm 
window using screen co-ordinates, rather than parent window 
co-ordinates?  Thanks.


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

Re: Problem with 'gio/gwin32appinfo.c'

[John Emmas]

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 
'glibmm/gio/src/appinfo.hg' might still be trying to wrap some of them 
- in particular:-


g_app_info_get_all_for_type()
g_app_info_reset_type_associations()



After applying your patch just now (and rebuilding both glib and glibmm) 
'g_app_info_get_all_for_type()' is now getting found again but 
'g_app_info_reset_type_associations()' is still missing.  Thanks for 
dealing with this so promptly.


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

Re: Problem with 'gio/gwin32appinfo.c'

[John Emmas]

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()
g_app_info_get_fallback_for_type()
g_app_info_get_recommended_for_type()
g_app_info_reset_type_associations()

After today's update they all seem to be missing now

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.



Hi LRN,

Just flagging up that after updating today from glibmm master, some of 
those functions are now coming up as missing symbols (when I try to 
re-build glibmm with MSVC).  It looks like 'glibmm/gio/src/appinfo.hg' 
might still be trying to wrap some of them - in particular:-


g_app_info_get_all_for_type()
g_app_info_reset_type_associations()

Just flagging this up in case you need to liaise with the glibmm devs.

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

Re: Outdated win32 bundle

[John Emmas]

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* *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.



As an aside...  whatever happened to Microsoft's interest in all this??

Around 2 years ago a guy from MS visited this list to let us know about 
their CoApp project.  From what I can remember, they were getting 
worried about the number of people building the GTK stack for Windows.  
They didn't have anything against GTK.  What worried them was that all 
these competing builds would end up bringing back DLL Hell which MS 
itself has worked very hard to get rid of!  The proposal was to have one 
official source for Gtk-Win which would be hosted by MS (and delivered 
by some kind of app that would be similar to apt-get).  They were 
planning to use a distribution based on the existing HexChat repos.  The 
initial conversations involved me, Arnavion, Tarnyko and a few others - 
but it soon went very quiet.


Anyone know if it's still ongoing?

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

Newly added 'read_resource_string()' function (glib)

[John Emmas]

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,
LOAD_LIBRARY_AS_DATAFILE |
LOAD_LIBRARY_AS_IMAGE_RESOURCE);

We need to build libglib with MSVC 8.0 but unfortunately, it doesn't 
contain the symbol 'LOAD_LIBRARY_AS_IMAGE_RESOURCE'.  In any case, MSDN 
states that LOAD_LIBRARY_AS_IMAGE_RESOURCE isn't supported in anything 
earlier than Vista (and our app needs to run on XP or higher).


Will it be possible to address these problems in the near future? Thanks.

John


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

Re: Problem with 'gio/gwin32appinfo.c'

[John Emmas]

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 
complained after they got removed.  However...  I think it's turned out 
to be a problem at my end.  Sorry for the noise!


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

Problem with 'gio/gwin32appinfo.c'

[John Emmas]

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()
  g_app_info_get_fallback_for_type()
  g_app_info_get_recommended_for_type()
  g_app_info_reset_type_associations()

After today's update they all seem to be missing now (and as such, the 
linker reports them as unresolved symbols).  However, I can't see 
anything in the git log to suggest when (or why) they got removed.  Have 
they been moved somewhere else or has something gone wrong with my 
update today??


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

Re: Using Python v3.3 while building Glib

[John Emmas]

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 we have two slightly unusual requirements:-


  1)  For historical reasons we need to build with VC8.  That's 
rarely supported now in gtk+ libs.


  2)  We build 3 targets, namely:-

a)  Full Debug version
b)  Full Release version
c)  Debuggable Release version

It might seem like a luxury to have a debuggable Release build - but in 
fact it can be immensely useful.


Are the nice-software libs synced to their official libraries (i.e. if 
there's a change upstream, does it get imported into the nice-software 
version?)


My repos get updated weekly and are also on github:-

https://github.com/johne53?tab=repositories

Looks like we're basically doing the same thing !!

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

Re: Using Python v3.3 while building Glib

[John Emmas]

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 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.


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

Re: Using Python v3.3 while building Glib

[John Emmas]

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 list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[John Emmas]

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 api-ms-win-whatever DLLs are effectively empty 
DLLs which act as an interface to various kernel DLL functions.  So if 
they were missing, you'd expect huge swathes of stuff to stop working.


Perhaps your app doesn't need those DLLs directly - but maybe you've 
linked to some 3rd party library which does need them (but the specific 
version that's needed isn't available on the relevant PC)?


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

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

[John Emmas]

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/desktop/dn505783(v=vs.85).aspx

Apparently, the api-ms-win-whatever DLLs form part of something called 
API Sets which were introduced in Windows 8.  Applications can make 
use of the new API Sets by either linking to a library called 
MinCore.lib or to MinCore_DownLevel.lib.  Note however that MSDN 
states the following:-  Binaries that link to MinCore.lib or 
MinCore_Downlevel.lib are not designed to work on Windows 7, Windows 
Server 2008 R2 or earlier. Binaries that need to run on earlier versions 
of Windows or Windows Server must not use either MinCore.lib or 
MinCore_Downlevel.lib.


I've searched quite extensively through the GTK stuff but I can't find 
anything that links to either of those .lib files.


So my best guess is the same as before...  i.e. your app uses some 3rd 
party component which was built against MinCore.lib or 
MinCore_DownLevel.lib.


That's the only thing I can think of which would explain what you're 
seeing.  Hope that helps.


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

Using Python v3.3 while building Glib

[John Emmas]

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 AFAICR.  For example, there's a python source called 
codegen_main.py which gets converted to codegen_main.pyc.  The build 
procedure has been working perfectly for many years.


For reasons unconnected with Glib I needed to upgrade python yesterday 
to ver 3.3.5.  Since the upgrade, my python binaries now have different 
names.  For example, the above binary now gets called:-


codegen_main.cpython-33.pyc

I don't know enough about the build process to know whether there might 
be any ramifications caused by the name changes.  Are the .pyc files 
just used internally by python itself (in other words, the name isn't 
important)?  Or could there be other ramifications for my build?  I 
realise I should be contacting the python team - but I wanted to ask 
some advice first to find out if anyone can anticipate any potential 
problems from this change?  Thanks.


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

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

[John Emmas]

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 be installed on somebody else's system.  
This is especially true if you gave them a Debug build of your app.


Windows Vista seems to date back to around 2006.  So (by default) it 
probably won't come with any runtimes newer than maybe VS2005.  Even 
Windows 7 doesn't (by default) install any runtimes newer than about VS2008.


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

Re: GDK_KP_Decimal (on Windows)

[John Emmas]

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+ version 3) it doesn't match the style 
that was being used in version 2.  In version 2, the other entries in 
'gdkkeys-win32.c' all seem to use this style:-


GDK_KP_WHATEVER

as opposed to this:-

GDK_KEY_KP_WHATEVER

I'm not criticising...  just pointing out that the two versions are 
different.  Thanks.


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