>True,
> except I really recommend you use jhbuild[0] to do this
>for you.
Yes, now i just installed and learning jhbuild.
>To build GTK+ master you're going to also need development
>(or at least up-to-date) versions of dependant libraries
>such as gobject-introspection, gdk-pixbuf, cairo, pan
On Thu, 2010-09-23 at 05:05 +, Alexander Kuleshov wrote:
> >You should file bugs in bugzilla and attach patches there
> >for review (or attach patches for existing bugs):
> >https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B
>
> Ok, i understand.
>
> >The current development focus is the
>You should file bugs in bugzilla and attach patches there
>for review (or attach patches for existing bugs):
>https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B
Ok, i understand.
>The current development focus is the master branch (future GTK+3)
I clone:
git clone git://git.gnome.org/gtk+
a
I've been trying to compile the current Gnome desktop on my AIX 6.1 system for
over a month now, but I keep getting stuck on gobject-introspection. I've
tried
everything I can think of (I've even blown away and rebuilt my entire build
environment twice), but I just can't get it to build.
I'm
On Wed, Sep 15, 2010 at 2:58 AM, Lubomir Rintel wrote:
> All GTK+ applications abort upon first key press in case XKB extension
> is not present.
>
> This is probably less optimal than it could be, because in case of lack
> of XKB extension, this causes a XkbGetMap() call on each key press as
> we
Le dimanche 05 septembre 2010 à 12:42 +0100, Andrew Wood a écrit :
> (process:2153): GLib-GObject-CRITICAL **:
> /build/buildd/glib2.0-2.24.0/gobject/gtype.c:2706: You forgot to call
> g_type_init()
What's you answer to GLib question (Did you forgot to call
g_type_init() ?) ?
signature.asc
D
All GTK+ applications abort upon first key press in case XKB extension
is not present.
This is probably less optimal than it could be, because in case of lack
of XKB extension, this causes a XkbGetMap() call on each key press as
well as ugly warning on error output. Maybe a better idea would be to
Did anyone contact the guys over at:
http://www.directfb.org/index.php?path=Main%2FContact
--
Without fear we must walk forward and without doubt we must not look back.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/m
Im getting errors when trying to create a GdkPixbuf using:
GdkPixbuf* unviewedicon =
gdk_pixbuf_new_from_file("/home/andrew/txe2mdr/unviewedicon.png", NULL);
When it runs it spews out:
(process:2153): GLib-GObject-CRITICAL **:
/build/buildd/glib2.0-2.24.0/gobject/gtype.c:2706: You forgot to
Im getting errors when trying to create a GdkPixbuf using:
GdkPixbuf* unviewedicon =
gdk_pixbuf_new_from_file("/home/andrew/txe2mdr/unviewedicon.png", NULL);
When it runs it spews out:
(process:2153): GLib-GObject-CRITICAL **:
/build/buildd/glib2.0-2.24.0/gobject/gtype.c:2706: You forgot to
Dear Mr Clasen,
I must say I was surprized to find that if I try to "reply" to somebody
with Redhat, my answer wil be directed to gnome.
I must also say that I oppose graphics since it uses most
computerfacilities undue. When I want to send a 40 chars long message
saying that I will be a little
Il giorno lun, 23/08/2010 alle 09.10 -0300, Johan Dahlin ha scritto:
> [not on gtk-devel, so CC me replies]
>
> On Fri, 20 Aug 2010 01:59:09 Giovanni Campagna com> wrote:
> > First of all, sorry if this is not the correct mailing list but I did
> > not find a more suited one (and Glib discussion
Il giorno lun, 23/08/2010 alle 11.54 -0400, Colin Walters ha scritto:
> On Thu, Aug 19, 2010 at 7:59 PM, Giovanni Campagna
> wrote:
> >
> > I started looking for GObjectIntrospection API recently and I've seen
> > a lot of overlap with the original GObject/GType system.
>
> Yes. The answer to mo
Hi Ilyes,
Last time I checked, the remaining issues where :
- drag&drop stuff,
- scrolling (leaves trash in moved areas)
- window resize
Regards,
--
Lionel
Le jeudi 26 août 2010 à 18:14 +0100, Ilyes Gouta a écrit :
> Hi Lionel,
>
> Can you tell us a bit more about the m
Hi Lionel,
Can you tell us a bit more about the missing features and the
unfinished bits of the back-end in order to get gtk2+-2.20/directfb
swinging again?
-Ilyes Gouta
On Wed, Aug 25, 2010 at 8:49 PM, Lionel Landwerlin
wrote:
> Hi,
>
> There is a bug report for this :
> https://bugzilla.gnome
I was trying out the latest GIT and putting it off in /var/opt/gnome to
avoid conflict with my stable libraries, but I noticed something about
g-object-introspection that messed that up. In /usr/share/gir-1.0 I have
for instance a file called "GModule-2.0.gir" and within it is the stable
version fo
Hi,
There is a bug report for this :
https://bugzilla.gnome.org/show_bug.cgi?id=619468
Don't blame the embedded world.
Regards,
--
Lionel Landwerlin
Le mercredi 25 août 2010 à 12:22 -0700, Mike Emmel a écrit :
> 2010/8/25 Javier Jardón :
> > 2010/8/25 John Stowers :
> >>
> >> For Google, and t
Hi,
Sorry to bother you.
I try to build the package gobject-introspection-0.6.14 for ARM
processor.
The build environment is x86 Ubuntu. The Python package is for x86.
From the error message (below), it seems that the x86 Python cannot
understand the ARM share library format.
Plea
Am 22.09.2010 22:21, schrieb Behdad Esfahbod:
> On 09/21/10 18:02, Emmanuele Bassi wrote:
>> - possibly deprecate ::destroy altogether: use weak-pointer/weak-ref
>
> Everyone knows that weak pointers as implemented currently are racy and
> unsafe, right?
this one:
https://bugzilla.gnome.org/sho
On 09/21/10 18:02, Emmanuele Bassi wrote:
> - possibly deprecate ::destroy altogether: use weak-pointer/weak-ref
Everyone knows that weak pointers as implemented currently are racy and
unsafe, right?
behdad
___
gtk-devel-list mailing list
gtk-devel-li
A couple other ideas, just to put more options in the pile.
Minor concern. gdk_event_set_coords() and set_source() could be
problematic in that GdkEvent would become a mutable non-GObject. This
is normally considered Bad language-binding-wise. Though in this case,
the implications are perhaps limi
Hi,
On Wed, Sep 22, 2010 at 10:28 AM, Matthias Clasen
wrote:
>
> Isn't that handled by containers simply not calling draw on covered up
> or hidden children ?
>
yeah, quite possibly. Especially if we move animations into a magic
master clock that would also be stopped.
Havoc
___
2010/9/22 Alexander Kuleshov :
> Hello list,
Hello Alexander,
> First of all let me introduce myself. My name is Alexander Kuleshov.
> Now I m student, programmer. I have some expirience in C/gtk+
> programming (i took part in Google summer of Code in this year) And I
> want to take part in gtk+/
On Wed, 2010-09-22 at 15:09 +, Alexander Kuleshov wrote:
> Hello list,
>
> First of all let me introduce myself. My name is Alexander Kuleshov.
> Now I m student, programmer. I have some expirience in C/gtk+
> programming (i took part in Google summer of Code in this year) And I
> want to take
Hello list,
First of all let me introduce myself. My name is Alexander Kuleshov.
Now I m student, programmer. I have some expirience in C/gtk+
programming (i took part in Google summer of Code in this year) And I
want to take part in gtk+/glib development. I have some question:
1) If i write patc
On Wed, Sep 22, 2010 at 9:14 AM, Havoc Pennington wrote:
> Hi,
>
>> (and possibly
>> VISIBILITY_NOTIFY too) as being in section A2. i know that as they
>> stand, these refer to GdkWindows, but by implication they also apply
>> to widgets within the window.
>
> Some kind of "are we covered up and
Hi,
On Wed, Sep 22, 2010 at 8:55 AM, Paul Davis wrote:
>
> i think you might want to consider MAP and UNMAP
I was thinking the vfuncs (already called on no-window) and map/unmap
signals would be fine. i.e. I agree map is interesting for no-window,
but I don't think ::map-event adds anything over
On Wed, Sep 22, 2010 at 2:11 AM, Havoc Pennington wrote:
> Hi,
>
> I've been exploring how widgets with no GdkWindow could receive
> events. Here are some notes so far in case people have thoughts.
>
> Event Types
> ===
>
> Events separate very cleanly into "weird lowlevel stuff only matters
> for
On Wed, 2010-09-22 at 02:11 -0400, Havoc Pennington wrote:
> During capture, a signal like ::event-captured seems logical.
>
> During bubble, a signal like ::event seems logical. Unfortunately that
> signal already exists but its GdkEvent is window-relative to the
> original event window, rather
29 matches
Mail list logo
