Re: Is this a memory leak?

[David Nečas]

On Wed, Nov 09, 2011 at 02:38:44PM +0100, Traktor Toni wrote:
> Hi, I'm using librsvg-2. Just calling rsvg_init() rsvg_term() tells  
> "bytes possibly lost" in valgrind at line "g_type_init_with_debug_flags"  
> inside rsvg_init().

Do you use nip2.supp?

> Also, why is it still calling g_type_init_with_debug_flags even though  
> I'm not compiling with any -g flag?

g_type_init() is just an alias for g_type_init_with_debug_flags() with
zero debug flags.  So type initialisation always goes through
g_type_init_with_debug_flags().  And the flags are GObject debugging
flags they have nothing to do with the debugging info put into binaries
by the C compiler.

Yeti

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Is this a memory leak?

[Emmanuele Bassi]

no, a one-off memory allocation is not a memory leak.

there have been multiple threads regarding using Valgrind with Glib and
Gtk+; I suggest you look at the Gnome wiki and the archives of this list.

ciao,
Emmanuele.

sent from my phone, sorry for the formatting.

On 14 Nov 2011 19:03, "Traktor Toni"  wrote:

Hi, I'm using librsvg-2. Just calling rsvg_init() rsvg_term() tells "bytes
possibly lost" in valgrind at line "g_type_init_with_debug_flags" inside
rsvg_init().


Also, why is it still calling g_type_init_with_debug_flags even though I'm
not compiling with any -g flag?

Thanks guys, this is making me nervous :(
__**_
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/**listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Is this a memory leak?

[Traktor Toni]

Hi, I'm using librsvg-2. Just calling rsvg_init() rsvg_term() tells 
"bytes possibly lost" in valgrind at line "g_type_init_with_debug_flags" 
inside rsvg_init().



Also, why is it still calling g_type_init_with_debug_flags even though 
I'm not compiling with any -g flag?


Thanks guys, this is making me nervous :(
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk-2-24-win32 branch update

[Martin Renold]

On Wed, Nov 02, 2011 at 04:59:17PM +0100, Alexander Larsson wrote:
> The gtk-2-24-win32 branch is now in a pretty good state. I fixed a lot
> of bugs from bugzilla and stuff from dieters testing
> (https://live.gnome.org/GTK%2B/Win32/test-gtk-2-24-win32).

Thanks a lot! Especially for fixing tablet support. It has seen a bit of
user testing with MyPaint already.  Early conclusion: win32 tablet support
(and the win32 port in general) finally just works as it should again.  No
need to use ancient gtk+ versions any more.

If you are looking for more bugs to fix, there seems to be one that is
specific to Hanvon graphic tablets. It might be a regression:
https://gna.org/bugs/?18944

Cheers!
Martin Renold
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [g-a-devel] Coming to grips with the state of a11y in GNOME

[Mario Lang]

Matthias Clasen  writes:

> The screen reader, orca, clearly is our 'flagship' AT. In my recent
> experience with orca, it worked surprisingly well and spoke to me for
> hours. The impression I got was much better than I had expected. In
> earlier attempts (sometime during 3.1.x), it randomly stopped speaking
> to me and I was unable to make it speak again.
>
> Problems I've seen today include
>
> - gnome-shell crashes when orca is restarted
>
> - interacting with treeviews while orca is running easily crashes
> (just select a file in the file chooser in any app...)
>
> - people have also seen gnome-terminal crash with orca
>
> - Insufficient labelling in new UIs, e.g gnome-shell is largely just
> 'panel' to orca...
>
> - Lack of a11y support in 3rd party widgets (stock widgetry in
> evolution is read just fine to me, but I don't hear any of the
> 'interesting' things: subjects, senders, email bodies...)
>
> - I couldn't get a word out of firefox - I thought maybe my gtk2 a11y
> stack was misconfigured, but openoffice did speak...
>
> What are the problems ?
> ---
>
> Toolkit accessibility (ie the loading of atk-bridge into GTK+ and
> Clutter applications, as controlled by the toolkit-a11y gsetting) is
> too broken. We cannot turn something on by default that lets you crash
> any application in the file chooser.

I think the current crashes are a logical consequence of ripping out
CORBA and reimplementing the complete AT backend anew.
These bugs have been present in early CORBA-ATSPI days as well,
and have been fixed over time.

I think the new D-Bus AT-SPI layer needs a bit more time to stabilize.

Its current problems should definitely not be taken as an argument to
trash the wonderful GNOME accessibility support now.
It would be a shame in my opition.

> What are our options ?
> 
>
> Possible remedies include:
>
> - Change approach
>
> Instead of 'special interface for the 1% of users that really need
> it', go for something that is useful for everybody, then add the few
> a11y extras that get you from 'can be used by 80%' to 90%, then 95%,
> ...
>
> - Reduce scope
>
> Look at what concrete ATs actually use, instead of clinging to some
> overly broad inherited 'standard' interface.
> My guess is that this will boil down to mainly text + focus.

I would find it extremely sad if these options were persued.

GNOME is really the only desktop on Linux so far that has done
accessibility right from the start.  Other desktops
have demonstrated that you can get some percentages of users covered
with "cheap tricks", but you end up excluding a few people in general.

I've always loved GNOME for not doing this and going "the hard way" to
actually achieve relatively good, and especially full-featured,
accessibility support for users like me (100% blind).

I dont think it is a good idea to cripple toolkit accessibility.
Yes, the interfaces are complex, but that is because they are solving a
relatively complex problem.  If you reduce the functionality, you
deliberately exclude a certain class of users.  I know the arguments
that this is a small percentage, but you should realize that for these
users, GNOME is currently the only option for an up-to-date program
stack.

-- 
CYa,
  ⡍⠁⠗⠊⠕
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list