стинг.БГ!
>
> https://www.superhosting.bg/?utm_source=mail.bg&utm_medium=cpm&utm_content=mail_header&utm_campaign=campaign2018
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-de
--
Dr. Edscott Wilson Garcia
Reservoir Engineering
Mexican Petroleum Institute
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
ch is quite a lot). Only
if that fails I'll go back to Msys-Mingw64.
--
--------
Dr. Edscott Wilson Garcia
Reservoir Engineering
Mexican Petroleum Institute
___
gtk-app
This is a follow up on
http://comments.gmane.org/gmane.comp.gnome.lib.gtk%2B.devel.apps/31337
I've kept investigating the bug and found that it occurs on any processor,
but only when fvwm2 is the WM and the desktop is located beyond the fourth
desktop. It does not occur in gtk-2.24, but invariable
2013/3/26 Allin Cottrell
> On Tue, 26 Mar 2013, Edscott Wilson wrote:
>
> It would be nice know that >=pango1.32.4 means that systems with
>> fontconfig, freetype and xft if and only if harfbuzz >= 0.9.9.
>>
>> Seems like the pango 1.32.4 configure.ac test
It would be nice know that >=pango1.32.4 means that systems with
fontconfig, freetype and xft if and only if harfbuzz >= 0.9.9.
Seems like the pango 1.32.4 configure.ac tests in things in the wrong order.
2013/3/25 Matthias Clasen
> GTK+ 3.8.0 is now available for download at:
>
> http://dow
2013/2/18 Colomban Wendling
>
> Or maybe I got you wrong and you'd like to *draw* on your GdkPixbuf?
> I'm afraid this just isn't possible directly. If you really want to do
> that, you'll probably have to manually do some pixel conversion. You
> can create a Cairo surface of the pixbuf's size,
Any other hypothesis?
2013/2/12 Edscott Wilson
>
> I'm battling with a race condition for several week now, and have not been
> able to determine anything incorrect in my development code (http:/
> xffm.org). The situation is as follows: If I compile with gtk+2,
> everything i
I'm battling with a race condition for several week now, and have not been
able to determine anything incorrect in my development code (http:/xffm.org).
The situation is as follows: If I compile with gtk+2, everything is fine.
Compilation with gtk+3 produces a race condition on mapping the popup me
,
put in a g_idle function.
2013/1/30 Edscott Wilson
> The current method for calling gtk_xx instructions is from the main thread
> only (i.e., that which owns the main loop context). You can do this by
> means of g_main_context_invoke(). Otherwise you must use the deprecated
> gdk_t
The current method for calling gtk_xx instructions is from the main thread
only (i.e., that which owns the main loop context). You can do this by
means of g_main_context_invoke(). Otherwise you must use the deprecated
gdk_threads_enter/gdk_threads_leave mutex method. The deprecated method is
slower
very helpful.
Issue solved.
Thanks.
2013/1/23 Andrew Potter
> On Wed, Jan 23, 2013 at 1:38 PM, Edscott Wilson <
> edscott.wilson.gar...@gmail.com> wrote:
>
> > Maybe it's just a bug in Valgrind... I'm finding that a threaded
> > environment may co
2013/1/23 David Nečas
>
> Whether gtk_combo_box_get_path_for_child() can be called with a visible
> child different from those enumerated there (the only way a leak can
> occur) I cannot tell.
>
> In any case, any suspected leak that goes through GSlice should be first
> reproduced with G_SLICE=a
:gtk_widget_get_path
fun:reset_style_recurse
fun:gtk_widget_set_parent
fun:gtk_combo_box_add
fun:g_closure_invoke
}
2013/1/22 Edscott Wilson
>
> Would the following be a leak in the gtk library (which I should not worry
> about), or a leak in my program ( http://xffm.org )?
&
Would the following be a leak in the gtk library (which I should not worry
about), or a leak in my program ( http://xffm.org )?
==19528==
==19528== 24 bytes in 1 blocks are definitely lost in loss record 2,773 of
9,919
==19528==at 0x4C2AABB: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-a
15 matches
Mail list logo
