travissu/opt/autoconf/automake-1.7/bin/automake-1.7 line 7648
I think only the last line is relevant to gtk-doc. It is such a drag
when documentation holds up a build.
This is on a Sparc Solaris 9 machine w/ gcc 3.4 in case it helps.
Also, I am using autoconf 2.59, automake 1.8, and libtool 1.5.10
tarted?
In the post reference above and elsewhere [3], Owen suggested porting
gdkasync.c to XCB without changing any of the other code in GTK+. Is
this still a good place to start? What is so significant about
gdkasync.c?
Thanks in advance for any help or suggestions
--
Regards,
Trav
; > could be used to do this in a much cleaner way.
> >
> > Another nice thing about gdkasync.c is that it would be easy to have
> > a conditionally compiled gdkasync-xcb.c that was used only when
> > GTK+ was compiled against an Xlib with XCB internals.
Thanks for the info. I thi
ls point me
in the right direction?
TIA.
--
Regards,
Travis Spencer
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
ted after the first compilation point to the
x11 directory (and not my x11-xcb dir).
I suspect that there is something in these Makefile.am files or
perhaps configure.in that I need to change.
--
Regards,
Travis Spencer
___
gtk-devel-list mailing list
isplay-x11.h), but the Plo is still getting the gdk/x11 headers.
Any other ideas?
--
Regards,
Travis Spencer
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
e subversion repo. As
I'm developing, I can then run a `cvs up' and get the latest
modifications (because I added all of cvs's meta files also).
Consequently, when my patch is done, it will by in sync with the
latest work found in the GTK+ cvs repo
On 8/12/05, Travis Spencer <[EMAIL PROTECTED]> wrote:
> My problem is that the Plo files in `gdk/x11-xcb/.deps' still point to
> the files in `gdk/x11'.
This was happening because in gdkpixmap-x11.h, gdkprivate-x11.h, and
gdkwindow-x11.h, there are these includes:
#inclu
that accepts an XEvent[1]?
--
Regards,
Travis Spencer
[1] An application that uses the XCL can't use both XCB's and Xlib's
event queue simultaneously, so I have to port all of GDK event
handling at once. This necessitated the function signature change.
__
and running again! Thanks :-)
--
Regards,
Travis Spencer
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
10 matches
Mail list logo