I keep getting this with my svn checkout of gtk+ glib etc succeed
[EMAIL PROTECTED] gtk+]$ svn up
At revision 17394.
Killed by signal 15.
[EMAIL PROTECTED] gtk+]$
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/li
Hi Xan,
> Great, thanks for helping! While this gtk-love effort does not get any
> "official" support I'd recommend that you just assign any of the bugs
> to yourself, send the patch, add any bug you think might be addecuate
> to the wiki... etc.
>
> Would you like to set up a meeting on IRC some
On Mar 5, 2007, at 4:37 AM, Murray Cumming wrote:
> On Sat, 2007-03-03 at 00:49 -0800, Bob Murphy wrote:
> [snip]
>> This all sounds like a great idea. I work for a company that's
>> actively using and modifying various open-source components,
>> including GTK+, and this would be a good way to ge
On Fri, 2007-03-02 at 08:49 -0500, Xan Lopez wrote:
>
> - The first one is to implement the well known gnome-love strategy
> done by GNOME in gtk+. Basically we'd have a maintained list of "easy"
> gtk+ bugs suitable for starting hackers to get involved into the
> project.
What's wrong with just
Tor Lillqvist wrote:
> I'm not sure. This can be considered as an API change even if the type
> is the same size and signedness as the old one on the existing
> plaforms. intprt_t and uintprt_t also don't exist on all
> platforms. Maybe preprocessor macros is the only way out, i.e. having
> a macro
On Mon, 2007-03-05 at 12:21 -0500, Jake Goulding wrote:
> Sure. Please excuse the following formatting...
>
> gbookmarkfile.c(1838) : warning C4267: 'function' : conversion from
> 'size_t' to 'gulong', possible loss of data
> all_data_dirs = g_new0 (gchar *, g_strv_length ((gchar
> **)system_dat
> > intptr_t and uintptr_t? Does the current MS compiler have ?
> Between stdio.h, stdlib.h, assert.h, and windows.h it exists and is 64-bit.
> Would the appropriate thing to be to change the glib code where the
> aforementioned assumptions occur to use these types?
You mean for instance for the
Between stdio.h, stdlib.h, assert.h, and windows.h it exists and is 64-bit.
Would the appropriate thing to be to change the glib code where the
aforementioned assumptions occur to use these types?
Tor Lillqvist wrote:
> > It's almost like there should be a full-width type, one that is 32 bits
Are you sure?
$ cat intptr.c
#include
#include
#include
#include
#define SIZE(x) printf(#x ": %d\n", sizeof(x))
int
main(int argc, char **argv)
{
SIZE(intptr_t);
SIZE(uintptr_t);
return 0;
}
$ ./intptr.exe
intptr_t: 8
uintptr_t: 8
Jonathan Chambers wrote:
> Very unfortunately
Sure. Please excuse the following formatting...
gbookmarkfile.c(1838) : warning C4267: 'function' : conversion from
'size_t' to 'gulong', possible loss of data
all_data_dirs = g_new0 (gchar *, g_strv_length ((gchar
**)system_data_dirs) + 2);
gfileutils.c(565) : warning C4267: 'function' : conve
Very unfortunately no. You can use the capital case windows defines,
INT_PTR, etc, or ship a version of to use in VS (
http://www.azillionmonkeys.com/qed/pstdint.h).
- Jonathan
On 3/5/07, Tor Lillqvist <[EMAIL PROTECTED]> wrote:
> It's almost like there should be a full-width type, one that i
On Mon, 2007-03-05 at 11:06 -0500, Jake Goulding wrote:
> Jonathan:
>
> I'd definitely like to see the list of issues that you have dealt with
> previously. Anything to minimize work is welcome in my book! :-)
>
> Based on the various (well-argued) dissent shown to making a glong 64
> bit, I un
> It's almost like there should be a full-width type, one that is 32 bits
> on a 32-bit platform, and 64 bits on 64-bit.
intptr_t and uintptr_t? Does the current MS compiler have ?
--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http:/
Also, I ran into a similar problem with some date functions (gmtime
expects a 64-bit number as time_t is 64-bit)...
It's almost like there should be a full-width type, one that is 32 bits
on a 32-bit platform, and 64 bits on 64-bit.
Thoughts?
Jake Goulding wrote:
> That does leave me with the
Jonathan:
I'd definitely like to see the list of issues that you have dealt with
previously. Anything to minimize work is welcome in my book! :-)
Based on the various (well-argued) dissent shown to making a glong 64
bit, I undid my change. That does leave me with the issue that there are
a bun
Just wanted to note that I am interested in this topic as well, as I am
trying to port mono (which depends on glib) to Win64. I just contacted Tor
about this a week ago offline. I saw this thread searching the web, and just
joined the list.
Jake, if you want/need any help with anything let me kno
Hi,
In what free time I have, I do experiments with Gtk+.
I tried adding a custom event for academic purpose only in the
gtk_widget.
To add the event handling for the additional event in the widget, I
followed the following steps. (Hope this might be of some help).
1) Add a function pointer in _G
On Sat, 2007-03-03 at 00:49 -0800, Bob Murphy wrote:
[snip]
> This all sounds like a great idea. I work for a company that's
> actively using and modifying various open-source components,
> including GTK+, and this would be a good way to get involved with the
> community and learn how to subm
On Thu, Mar 01, 2007 at 07:19:08PM +0100, Murray Cumming wrote:
> On Thu, 2007-03-01 at 13:13 +0100, Kristian Rietveld wrote:
> > better support for devices with a restricted set of keys
>
> This sounds interesting. What new API or what ChangeLog entry is
> relevant?
See revision 16733 in SVN:
ht
Hi!
On 3/3/07, Bob Murphy <[EMAIL PROTECTED]> wrote:
> This all sounds like a great idea. I work for a company that's
> actively using and modifying various open-source components,
> including GTK+, and this would be a good way to get involved with the
> community and learn how to submit changes b
20 matches
Mail list logo
