Many thanks for those suggestions guys. It didn't quite fix the problem
but it did point me in the right direction. Here's what I've found so
far
The top of the (auto-generated) file 'atk-enum-types.c' currently looks
like this:-
/* Generated data (by glib-mkenums) */
Hi,
On 09/26/2014 11:42 AM, John Emmas wrote:
Many thanks for those suggestions guys. It didn't quite fix the
problem but it did point me in the right direction. Here's what I've
found so far
The top of the (auto-generated) file 'atk-enum-types.c' currently
looks like this:-
On 26/09/2014 11:03, Piñeiro wrote:
On 09/26/2014 11:42 AM, John Emmas wrote:
#include config.h // --- I needed to add this line !!
Well, this line is being included when I build atk. And looking at the
2.14.0 release
Oops, you're absolutely right. The version in 2.14.0 does
Hi,
Several months ago I started working on improving the word boundaries,
I've written some patches, written some comments on bugzilla in various
bugs. Here is a summary, I hope it'll get more attention than in
bugzilla.
I would like to improve the word boundaries for the text widgets:
On 26/09/2014 11:51, John Emmas wrote:
Also, since my last post I've discovered why atkmm was also failing
to build [...] Now that I'm managing to generate those files
correctly again, everything's now building fine.
Oh, one more thing, before I forget it
I think I'm right in saying
(I haven't looked at the headers in question myself).
If I'm understanding the situation correctly, you're building a binary
that includes an atk(mm) header that has some functions marked with
dllexport (from the POV of the compiler when it's compiling your
code).
Technically though, I don't
On 09/26/2014 06:13 AM, Sébastien Wilmet wrote:
I would like to improve the word boundaries for the text widgets:
GtkTextView, GtkEntry and GtkLabel (anything else?). More precisely the
word boundaries used for word movements (Ctrl+arrow) and word selection
(double click). Currently the
Hi,
This situation would have been hit by GLib and GTK+, if not done properly, as
they use things like _GLIB_EXTERN (for glib, gobject, gio) and _GDK_EXTERN (for
GDK, gtk) and they also export public variables (data)--but they build and link
just fine. In fact the work on using
On Sep 26, 2014, at 7:17 PM, Fan Chun-wei fanc...@yahoo.com.tw wrote:
Hi,
This situation would have been hit by GLib and GTK+, if not done properly, as
they use things like _GLIB_EXTERN (for glib, gobject, gio) and _GDK_EXTERN
(for GDK, gtk) and they also export public variables
