Re: Is GTK+ a cross-platform toolkit ?
On Tue, 5 Mar 2013 09:45:40 -0300, Marcelo Caetano wrote: I always worked with gtk2+ bundles in win32, yes, it was a big mess. but I always shipped the dlls into my application directory instead system32 directory. System32 is never the right place for GTK+ DLLs. -- Jernej Simončič http://eternallybored.org/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
glib/gatomic.c
Hello guys,
This morning I updated from git and found a minor problem in
glib/gatomic.c. At around line 530 there's a section of code that looks
like this:-
/* mingw32 does not have MemoryBarrier.
* MemoryBarrier may be defined as a macro or a function.
* Just make a failsafe version for ourselves. */
#ifdef MemoryBarrier
#define _GMemoryBarrier MemoryBarrier
#else
static inline void _GMemoryBarrier (void) {
long dummy = 0;
InterlockedExchange (dummy, 1);
}
#endif
Unfortunately, for MSVC, the 'inline' keyword is only available when
building as C++. For standard 'C' we need to use '__inline'. I solved
the problem by adding #include gutils.h, just after #include
config.h at the top of the file. That has the effect of converting
'inline' to '__inline'. If that's not an appropriate solution can
someone please let me know?
Incidentally, a couple of months ago I need to make a small number of
changes to that file in order to be able to build using VC8.0. Mostly it
just involved adding a few lines like this:-
#pragma intrinsic (_InterlockedAnd)
I've attached a full diff for that file in case it's helpful.
John
diff --git
a/C:\\DOCUME~1\\JOHNEM~1\\LOCALS~1\\Temp\\gatB0.tmp\\gatomic-e1ccae-left.c
b/F:\\+GTK-SOURCES\\gnu-win32\\src\\glib\\glib\\gatomic.c
index 461a8e6..dd84753 100644
--- a/C:\\DOCUME~1\\JOHNEM~1\\LOCALS~1\\Temp\\gatB0.tmp\\gatomic-e1ccae-left.c
+++ b/F:\\+GTK-SOURCES\\gnu-win32\\src\\glib\\glib\\gatomic.c
@@ -20,6 +20,7 @@
*/
#include config.h
+#include gutils.h /* Added by JE - 07-03-2013 (needed for '__inline')
#include gatomic.h
@@ -468,9 +469,16 @@ gsize
#include windows.h
#if !defined(_M_AMD64) !defined (_M_IA64) !defined(_M_X64) !(defined
_MSC_VER _MSC_VER = 1200)
+#include intrin.h /* Added by JE - 02-12-2012 */
+
+#pragma intrinsic (_InterlockedAnd) /* Added by JE - 02-12-2012 */
+#pragma intrinsic (_InterlockedOr)/* Added by JE - 02-12-2012 */
+#pragma intrinsic (_InterlockedXor) /* Added by JE - 02-12-2012 */
+
#define InterlockedAnd _InterlockedAnd
#define InterlockedOr _InterlockedOr
#define InterlockedXor _InterlockedXor
+
#endif
#if !defined (_MSC_VER) || _MSC_VER = 1200
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
[GObject-Introspection] Doubt about GIR files generation
Hi everyone, I'm wrinting a library and I generate some gir files for the parts of it that need to be used from outside, as the library is written in C but is being used from Vala throught some vapi files. All the bindings are made and working, but I have a doubt about GObject Introspection. This doubt comes from a problem I'm having while generating the .gir files and a previous version of the library is installed in the system: if any symbol name has been added or modified in the version being build, libtool complains about undefined references to these symbols while linking. It happens only during the g-ir-scanner execution and doesn't in the regular linking of the library. May it be something about g-ir-scanner looking for the libraries in the system first and then in the build tree? If so, how can I avoid this behavior? If not, does anyone know what's happening? As I use Debian, installing and removing the library as a package is a clean operation and doesn't break anything in the system. Thanks for any help, Alex ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib/gatomic.c
On 13-03-07 07:26 AM, John Emmas wrote:
Hello guys,
This morning I updated from git and found a minor problem in glib/gatomic.c.
At around line 530 there's a section of code that looks like this:-
Oops. My bad.
/* mingw32 does not have MemoryBarrier.
* MemoryBarrier may be defined as a macro or a function.
* Just make a failsafe version for ourselves. */
#ifdef MemoryBarrier
#define _GMemoryBarrier MemoryBarrier
#else
static inline void _GMemoryBarrier (void) {
long dummy = 0;
InterlockedExchange (dummy, 1);
}
#endif
Unfortunately, for MSVC, the 'inline' keyword is only available when building
as C++. For standard 'C' we need to use '__inline'. I solved the problem by
adding #include gutils.h, just after #include config.h at the top of the
file. That has the effect of converting 'inline' to '__inline'. If that's
not an appropriate solution can someone please let me know?
Do all versions of MSVC have MemoryBarrier? In that case, we should make sure
we never try the function path for MSVC. Perhaps I should just do that for
mingw32?
Incidentally, a couple of months ago I need to make a small number of changes
to that file in order to be able to build using VC8.0. Mostly it just involved
adding a few lines like this:-
#pragma intrinsic (_InterlockedAnd)
I've attached a full diff for that file in case it's helpful.
Interesting. I'll push. Just curious: can you also try building HarfBuzz and
see if we need those there too?
Thanks,
behdad
John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
--
behdad
http://behdad.org/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib/gatomic.c
Would copying what's here in case MemoryBarrier macros is defined work for you:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684208(v=vs.85).aspx
On 13-03-07 07:26 AM, John Emmas wrote:
Hello guys,
This morning I updated from git and found a minor problem in glib/gatomic.c.
At around line 530 there's a section of code that looks like this:-
/* mingw32 does not have MemoryBarrier.
* MemoryBarrier may be defined as a macro or a function.
* Just make a failsafe version for ourselves. */
#ifdef MemoryBarrier
#define _GMemoryBarrier MemoryBarrier
#else
static inline void _GMemoryBarrier (void) {
long dummy = 0;
InterlockedExchange (dummy, 1);
}
#endif
Unfortunately, for MSVC, the 'inline' keyword is only available when building
as C++. For standard 'C' we need to use '__inline'. I solved the problem by
adding #include gutils.h, just after #include config.h at the top of the
file. That has the effect of converting 'inline' to '__inline'. If that's
not an appropriate solution can someone please let me know?
Incidentally, a couple of months ago I need to make a small number of changes
to that file in order to be able to build using VC8.0. Mostly it just involved
adding a few lines like this:-
#pragma intrinsic (_InterlockedAnd)
I've attached a full diff for that file in case it's helpful.
John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
--
behdad
http://behdad.org/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib/gatomic.c
On 13-03-07 07:26 AM, John Emmas wrote: +#include intrin.h /* Added by JE - 02-12-2012 */ + +#pragma intrinsic (_InterlockedAnd) /* Added by JE - 02-12-2012 */ +#pragma intrinsic (_InterlockedOr)/* Added by JE - 02-12-2012 */ +#pragma intrinsic (_InterlockedXor) /* Added by JE - 02-12-2012 */ + #define InterlockedAnd _InterlockedAnd #define InterlockedOr _InterlockedOr #define InterlockedXor _InterlockedXor + #endif Humm. Does removing the defines do the trick? I can't find any references to the difference between the underscored and plain versions of these :(. -- behdad http://behdad.org/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Baseline alignment WIP
I just pushed the wip/baseline branch to git. It contains the initial steps towards adding baseline alignment in gtk+, by extending the size request and size allocation framework with: * A way to report a baselines corresponding to the minimum and natural heights * A way to allocate the baseline of a child widget in a baseline aware container * A way to flag widgets that they want to be baseline aligned It also contains baseline support for label, button, alignment and horizontal boxes which works well enough for this test: http://people.gnome.org/~alexl/baseline.png I started working on the vertical box implementation, where we would align the baseline to the baseline of the first child that had GTK_ALIGN_BASELINE valign. This is useful for e.g. layouts like this: +---+--+ | | [IMG] | | | [IMG] | | Label|...[Entry] [IMG] | | | | | +--+ | | | . Where we want the label in the left to align with the first text in the vbox on the right side. Conceptually this doesn't seem very hard, and i got the size request part done easily. However, the size_allocate() implementation for the case where a particular child widget is supposed to be on a specific position is very complicated due to all the complexity of boxes (pack start/end, homogenous, natural distribution of height, etc) so I gave up for now. However, I think implementing baseline support for things like entries, rows-in-GtkGrid, GtkButtonBox, etc should be pretty easy and might be an interesting excercise for other people who try out this branch. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
