At 27.12.2012 11:56, John Emmas wrote:
[...]
Knowing that I'd at least managed to get _something_ working, I then tried
running 'glib-mkenums' again - this time using Perl from MinGW/MSYS.
However, that essentially gave me the same error that I reported in the
first place:-
/* Generated data (b
At 30.07.2012 04:55, Fan Chun-wei wrote:
於 2012/7/29 下午 09:57, Colin Walters 提到:
On Sun, 2012-07-29 at 15:24 +0200, Hans Breuer wrote:
I didn't say "no"; we're having a discussion. Realistically, so while I
personally *do* care about Windows builds, I find cross-building wit
[
Apparently my last mail from yesterday was scatched by an overly zealous
virus scanner, now the original attachment is manually inlined
]
At 29.07.2012 15:57, Colin Walters wrote:
On Sun, 2012-07-29 at 15:24 +0200, Hans Breuer wrote:
Given that fixing the showstopper is not deemed to be
At 29.07.2012 13:38, Colin Walters wrote:
On Sat, 2012-07-28 at 11:55 +0200, Hans Breuer wrote:
One of the showstoppers for the win32/msvc build of GLib since 2.29 is the
dependency to libffi, which barely builds with msvc. In fact I was not able
to produce any working version with/for msvc6
One of the showstoppers for the win32/msvc build of GLib since 2.29 is the
dependency to libffi, which barely builds with msvc. In fact I was not able
to produce any working version with/for msvc6 (finally clashing runtime
versions).
But the current usage of libffi is limited to just two funct
At 03.02.2012 23:14, Karl Kleinpaste wrote:
[...]
Right: http://karl.kleinpaste.org/xiphos/xiphos-linux-farsi-right.png
Wrong: http://karl.kleinpaste.org/xiphos/xiphos-win32-farsi-wrong.png
We invoke with LC_ALL=fa_IR (Farsi/Iraq) and the Linux build is happy as
can be. The problem with the Win
At 15.04.2011 12:02, Alexander Larsson wrote:
On Sun, 2011-04-10 at 12:46 +0200, Hans Breuer wrote:
The first thing that should change is making g_malloc and
friends use the HeapAlloc function, and ensure that
g_mem_is_system_malloc() always returns false. This is really easy to do
and
At 07.04.2011 09:29, Kean Johnston wrote:
i think that this message was too long and contained too many issues.
i believe you'll get more traction if you:
(a) divide the issues
I wanted to do that but they are all pretty inter-related. I guess the
discussion on gstdio could be separate.
The i
At 10.04.2011 17:06, Kean Johnston wrote:
But the dependency to the CRT is not the problem, if there is only one of
them in process.
Agreed, but that is becoming almost impossible to guarantee. If we go to
any lengths to ensure a binary-compiled Glib is linked against
msvcrt.dll, and an average
The Gtk+ html backend might be the killer feature motivating me to put more
effort in Dia's gtk3 porting. Getting it to compile on win32 was easy and I
could commit the initial bits soon.
Unfortunately the implementation appears to be relying on a Unix paradigm
(everything is a file) , which i
At 07.04.2011 05:09, Krzysztof Kosiński wrote:
2011/4/6 Kean Johnston:
Everyone,
WARNING: long, detailed message. If you don't care about Win32, move on.
Other annoying Windows issues specific to glib:
I seriously doubt this win32 specific. It's a question of default encoding
of the termina
At 07.04.2011 02:26, Paul Davis wrote:
On Wed, Apr 6, 2011 at 5:34 PM, Kean Johnston wrote:
Last, but by no means least, is the reliance on "compiled" files, like
compiled schemas (or in the case of Gtk, icon caches). On UNIX systems where
things are installed in a universally-accessible locat
Hi Kean et al.,
At 06.04.2011 23:34, Kean Johnston wrote:
Everyone,
WARNING: long, detailed message. If you don't care about Win32, move on.
I would like to start a discussion on making changes to Glib for
improved Win32 support. These changes will eliminate many of the
pitfalls that usually ac
Current master - when build on windoze - gives:
gtkstatusicon.c
gtktrayicon.h(40) : error C2061: syntax error : identifier 'GtkPlug'
gtktrayicon.h(43) : error C2059: syntax error : '}'
gtktrayicon.h(47) : error C2061: syntax error : identifier 'GtkPlugClass'
gtktrayicon.h(54) : error C2059: synta
At 26.01.2011 23:36, Matthias Clasen wrote:
On Wed, Jan 26, 2011 at 5:32 PM, Hans Breuer wrote:
[...]
Correct, I've overlooked the suggested loss of GdkNativeWindow during the
creation of backend specific foreign_new_for_display(), but I think using a
gpointer and e.g. have the ba
At 26.01.2011 17:33, Benjamin Otte wrote:
> Hans Breuer breuer.org> writes:
>
>>
>> Current master has three occurences of
>>
>> #ifdef GDK_WINDOWING_X11
>> if (GDK_IS_X11_DISPLAY (display))
>>
>> followed by some
>>
https://bugzilla.gnome.org/show_bug.cgi?id=599401
is blocking two bugs reported against Dia and it has patches against
gtk-2-24 as well as master for some weeks, which solve the problems and
seem not to introduce any new issues.
Are there any objections to apply these patches?
Thanks,
Current master has three occurences of
#ifdef GDK_WINDOWING_X11
if (GDK_IS_X11_DISPLAY (display))
followed by some
window = gdk_x11_window_lookup_for_display (display, ...);
Only one was ported to win32 and currently none for OSX, leading
to e.g. a crash during clipboard copy.
Wouldn't i
At 27.08.2010 22:41, Hans Breuer wrote:
At 24.08.2010 10:14, Alexander Larsson wrote:
On Sat, 2010-08-21 at 14:09 +0200, Hans Breuer wrote:
[...]
- if the information given to _gdk_window_impl_new() is redundant,
as with GDK_WA_VISUAL set and visual given by parameter, which one
has
At 24.08.2010 10:14, Alexander Larsson wrote:
On Sat, 2010-08-21 at 14:09 +0200, Hans Breuer wrote:
while trying to fix _gdk_window_impl_new() for win32 some more,
quite some questions arose around that (apparently undocumented;)) API:
- if the information given to _gdk_window_impl_new() is
At 24.08.2010 20:31, Matthias Clasen wrote:
On Tue, Aug 24, 2010 at 1:42 PM, Tristan Van Berkom
wrote:
Hi developers,
Last week I was busy writing up a new container
widget for GTK+ and would like to propose it for
inclusion in 3.0.
Hey, sounds like a useful addition. I've actually had it
while trying to fix _gdk_window_impl_new() for win32 some more,
quite some questions arose around that (apparently undocumented;)) API:
- if the information given to _gdk_window_impl_new() is redundant,
as with GDK_WA_VISUAL set and visual given by parameter, which one
has precedence?
- w
Two translation files are recently causing some grief when working with
GLib and Gtk+ master. Before a "git pull --rebase" I need to commit the
changes I doidn't do. And afterwards I have to "git rebase --abort" because
these changes can not be merged.
The problem are wrong line-endings and I'
At 01.07.2009 16:34, Alexander Larsson wrote:
The client-side-windows branch has now been merged into master.
The current state of this code is pretty good. There are two known
regressions on X11 (see http://live.gnome.org/GTK%2B/ClientSideWindows),
but both are corner cases. The quartz backend
While trying to update the GLib build with msvc I sumbled over
the conditional define of G_SOCKET_FAMILY_UNIX.
But later the value is used unconditionally in gsocket.c
which breaks my build.
The whole introduction of defining the GSocketFamily values through
GLIB_SYSDEF_AF_* defines looks a bit
At 01.05.2009 20:10, Behdad Esfahbod wrote:
On 05/01/2009 04:18 AM, Davyd Madeley wrote:
.gitignore files, to improve switching between branches easily.
I'd rather add my git.mk. Matthias, want me to go ahead and do that?
How is it supposed to work for people building with a different
shell
Am 18.07.2008 15:32, Owen Taylor schrieb:
On Thu, 2008-07-17 at 13:15 +0200, Colin Leroy wrote:
[...]
The 1.x -> 2.0 change was painful for everyone who had an app that
needed porting, however I find it pretty irrelevant in comparison to
2.x -> 3.0.
Well, if no libgtk-compat is planned, it
Am 20.06.2008 14:44, Tim Janik schrieb:
Hey All.
As discussed during previous IRC meetings:
http://mail.gnome.org/archives/gtk-devel-list/2008-June/msg00194.html
The GSEAL branch has been merged into upstream today.
With the patch attached (and some minor things already commited) it does
com
On 04.12.2007 09:30, Alexander Larsson wrote:
> On Tue, 2007-12-04 at 00:15 +0100, Hans Breuer wrote:
>
[...]
>> I've started something of this, but not commited yet. (I'm getting too old
>> for all these ifdefs ;)) See attahed patch.
>
> Looks good to me.
&g
On 05.12.2007 12:19, Alexander Larsson wrote:
> On Tue, 2007-12-04 at 00:15 +0100, Hans Breuer wrote:
>> On 03.12.2007 10:07, Alexander Larsson wrote:
>
>>> Thats a way it can be made to work with the current use in libgio, but
>>> it makes the API sort of weird
On 03.12.2007 10:07, Alexander Larsson wrote:
> On Fri, 2007-11-30 at 15:01 +0100, Hans Breuer wrote:
[...]
>>>> g_io_modules_ensure_loaded (GIO_MODULE_DIR);
>>>> It would be nice if this function would take no parameter to allow
>>>> implementation of d
On 28.11.2007 09:24, Alexander Larsson wrote:
> On Tue, 2007-11-27 at 22:34 +0100, Hans Breuer wrote:
>> On 26.11.2007 17:25, Alexander Larsson wrote:
>>> I just commited gio to the glib svn module. As this is a sort of large
>>> chunk of work I expect there to be some t
On 26.11.2007 17:25, Alexander Larsson wrote:
> I just commited gio to the glib svn module. As this is a sort of large
> chunk of work I expect there to be some temporary issues to work out.
>
> For instance, its likely that there are some build issues for platforms
> I haven't tested. I got a bun
On 24.04.2007 18:31, Jake Goulding wrote:
> Brandon Casey wrote:
>> It's hard for me to think of unicode as
>> being low-level when it adds so much overhead to string handling.
>
> Isn't (a part of) the unicode handling needed for correctly processing
> paths under Windows? As I remember it, Win
iled (unexpected match) 'a#\rb' against 'a'
But after NEWLINE=-1 it does not fail anymore.
Thanks,
Hans
> Hans Breuer wrote:
>> with only small modifications I was able to compile GRegex with msvc,
>> thanks for providing an almost working makefile.msc ;-)
with only small modifications I was able to compile GRegex with msvc,
thanks for providing an almost working makefile.msc ;-)
The first attempt to run
regex-test.exe --noisy
did crash due to gnulib not liking
g_strdup_vprintf ("matching \"%s\" against \"%s\" \t", "%", "\p{Common}")
The
On 02.03.2007 22:49, Jake Goulding wrote:
>On 02.03.2007 22:29, Tor Lillqvist wrote:
>> The tests don't necessarily test everything, but this does indeed
>> sound promising.
>>
> Well, I didn't say that I *did* run them and get good outputs, I just
> wanted to make sure that was what the expect
On 01.03.2007 21:40, Jake Goulding wrote:
> Hey all, i am trying to compile glib-2.8.6 (an older version, I know...)
> under Windows Server 2003 64-bit.
>
> I hit the following issues:
> gbacktrace.c(192) : error C2065: 'SIGTRAP' : undeclared identifier
>
> This is caused by an if/else fallthrou
On 20.07.2006 02:09, Carl Worth wrote:
> I'm personally interested in hearing more details about what your
> motivation for sticking with 2.6 is. If it's performance concerns, (as
> is the case with others I've talked to), then I should point out that
> I'm personally very interested, and planning
Visual Studio projects),
I should mention that there are makefiles for the 32-bit MSVC compiler
in GLib and GTK. (At least in CVS, don't recall whether they are
included in the tarballs.) According to Hans Breuer who maintains them
they should be ready to use with relatively minimal effort.
On 17.03.2006 22:40, Jake Goulding wrote:
Hey all:
I've had some trouble in compiling and subsequently using glib (2.8.6)
on a Windows machine.
I am building using nmake and the MSVC toolset. My procedure is such:
unpack glib into a directory containing gettext and libiconv.
cd build/win32/d
On 09.01.2006 07:27, Harsha Joshi wrote:
Folks,
I am struggling hard to get hold of a document which explains me the
steps to build the GTK and Dependent library sources locally on windows
Machine using Visual Studio (MSVC) compiler.
http://cvs.gnome.org/viewcvs/*checkout*/glib/README.win32
On 06.01.2006 09:24, muppet wrote:
On Jan 5, 2006, at 9:52 PM, Owen Taylor wrote:
The main reason requiring C99 might be that most or all of
the developers are now using C99 compilers and aren't able to catch
slip-ups. It's hard to support something that we don't test with.
Add "--std=c89"
On 05.01.2006 22:15, Xavier Bestel wrote:
Le jeudi 05 janvier 2006 à 20:37 +0100, Hans Breuer a écrit :
As long as GLib/Gtk depends on msvcrt.dll on win32 VC6 is the *last*
official version spporting it. With VC7 (2000) VC7.1 (2003) there
where specific runtime versions (msvcr70.dll and
On 05.01.2006 20:58, Roger Leigh wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Breuer <[EMAIL PROTECTED]> writes:
>>
Have you used any of the MS compilers to compile at least Glib?
The last free (as in in beer) version did not support linking with
the C-runtine a
On 05.01.2006 17:26, Roger Leigh wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthias Clasen <[EMAIL PROTECTED]> writes:
Visual C++ 6.0 doesn't support C99 variadic macros.
It's over eight years old. The last time I checked, anyone could
download the latest MS compiler from the M
On 05.01.2006 17:14, Tim Janik wrote:
On Thu, 5 Jan 2006, Matthias Clasen wrote:
On Thu, 2006-01-05 at 15:37 +0200, Tor Lillqvist wrote:
Matthias Clasen writes:
> That doesn't mean that we can't declare gcc 2.95 unsupported at some
> point,
We might also want to declare what versions of MSVC
On 05.01.2006 12:01, Tim Janik wrote:
[...]
could people please speak up if they think depending on C99 would
be a bad idea for glib & gtk+
I do think this is a bad idea. See below and other mails.
(e.g. with the next major release) and
why this would be a problem for them?
To me this chang
On 03.10.2005 22:44, Adib Taraben wrote:
Hello gtk-team,
Inkscape is a SVG vector graphics editor that uses gtk and gtkmm.
Currently with the 2.8 libs there is a problem starting on win98.
http://bugzilla.gnome.org/show_bug.cgi?id=316878
Is it possible from you guys to investigate in this bug a
On 19.09.2005 00:38, Tor Lillqvist wrote:
Hans Breuer writes:
> BTW: I'd appreciate if somebody with a deeper understanding of gtk internals
> could do a review of gtktrayicon-win32.c. Maybe what I've done is considered
> too much of a hack ;-)
I appreciate your wor
On 18.09.2005 14:27, Hans Breuer wrote:
[...]
Before diving too deep into the code of (now) gtkstatusicon.c I've tried
it on Linux - but it does not work there, too. What am I supposed to
update so see any effect of ./teststatusicon ? (I'm running gnome-2.10.2
on gentoo with xorg
On 06.09.2005 15:08, Matthias Clasen wrote:
On Mon, 2005-09-05 at 23:25 +0200, Hans Breuer wrote:
[...]
Also gtkstatusicon-x11.c not only implements the fdo spec but it also
defines a bunch of status icon api. Not only 21 functions but additionally
quite some properties. Should all this be
On 04.09.2005 22:59, Matthias Clasen wrote:
On Sun, 2005-09-04 at 15:27 +0200, Hans Breuer wrote:
On 30.08.2005 00:37, Matthias Clasen wrote:
[...]
cvs as of today has
Trying to make it compile on win32 implies that two files
should be renamed :
gtkstatusicon-x11.c has nothing X11
On 30.08.2005 00:37, Matthias Clasen wrote:
[...]
cvs as of today has
Trying to make it compile on win32 implies that two files
should be renamed :
gtkstatusicon-x11.c has nothing X11 specific in it. At least
it compiles on win32 without any change. So it probably should
be named gtkstatusicon
On 30.04.2005 06:30, Jack Moffitt wrote:
Hello All,
I'm having trouble building glib 2.6.4 on win32. I've had glib 2.4.7
building great after just modifying a few paths in the makefiles, but
this version is broken with respect to io watches (as discussed on the
mailing list recently). Tor has a n
Am 19.04.2005 um 00:17 schrieb Gowri Sharmi Kandasamy:
Currently JPEG, PNG, and TIFF are required for compiling GTK+2.6 .
This is not true. Every single image format loader can be deselected
at compile time. Try ./configure --help or look at
gdk-pixbuf/makefile.msc
Do we need those libraries for
Following Owen's nice mingw build descriptions [1] everything went smooth
until atk which gives:
../../glib/build/win32/lt-compile-resource atk.rc atk-win32res.lo
Using zero as build number
/bin/sh ../libtool --mode=link gcc -g -O2 -Wall -L/gtk/lib -o libatk-1.0.la
-rpath /gtk/lib -version-inf
On 25.02.2005 00:57, Owen Taylor wrote:
On Mon, 2005-02-07 at 23:55 -0500, Owen Taylor wrote:
The GTK+ code currently is organized around one DC per
GC. My thought is that we should be moving more towards
one-DC-per-GdkDrawable. If we have a DC associated with
the GdkPixmap, then we can use that D
On 04.02.2005 00:31, Owen Taylor wrote:
Just committed a change to make GTK+ HEAD depend on Cairo.
Below you'll find my first attempt on integrating Cairo
rendering with gdk/win32. I've tried to put descriptive
comments in the code, here a short summary of the problem:
cairo_win32(set_target|create
59 matches
Mail list logo
