Re: GtkEventBox & button_release_event
On Wed, 16 May 2007 04:13:18 +0200 Salvatore De Paolis <[EMAIL PROTECTED]> wrote: > Hi all > > I'm trying to catch the release button event from a widget using a > GtkEventBox. After i create the GtkEventBox i use gtk_widget_set_events to > set masks in this way: > gtk_widget_set_events(viewer->scrollwin_ebox, GDK_BUTTON_PRESS_MASK | > GDK_BUTTON_RELEASE_MASK); > > and i connect both signals to callback's functions but i'm not able to catch > the release event while the press event works good. i reply to myself: was a problem of nested widgets, didn't add the eventbox to the correct widget. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkEventBox & button_release_event
Hi all I'm trying to catch the release button event from a widget using a GtkEventBox. After i create the GtkEventBox i use gtk_widget_set_events to set masks in this way: gtk_widget_set_events(viewer->scrollwin_ebox, GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK); and i connect both signals to callback's functions but i'm not able to catch the release event while the press event works good. regards Salvatore ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ maintenance
Hi, Vincent Untz wrote: > For example, a lot of companies do have an interest in GTK+ but are not > actively participating upstream. I've been in contact with some of them > to see if they could get some of their developers to freely work on > upstream as part of their job. People have been open about this idea, > but I'm sure we could come with better arguments to really convince > them. > Two good angles might be: - bugzilla stats (number of bugs, response time to new bugs, etc.) - details on specific great new features / enhancements a maintainer could implement (and point out how these benefit the company in question's products, as well as the whole ecosystem) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ maintenance
Hi, Le mardi 15 mai 2007, à 16:53 -0400, Tristan Van Berkom a écrit : > Its been clearly stated that core maintainers are whats lacking, people > that can be trusted to review large patches, do refactoring work and > call shots so to speak, in my own personal opinion I think gtk+ could do > fine with 2 extra Mattias Clasens or 2 more Tim Janiks, the question is; > where are these experienced people to be found ? Well, if they don't exist, we can try to grow some of them :-) > Will the foundation be considering hiring people from the gnome > community ? (I would suppose so...) will there be location constraints > (will developers have to move) ? will developers have to well known > and trusted or will they have to be highly decorated ? (a healty mix > of either/or/both I suppose...) So, right now, the Board is not considering the option of hiring people to hack/do technical things. I'm not saying "we'll never do this", but doing this has a lot of implications (managing the employees wouldn't be easy, people could start thinking that there's no need to contribute to GTK+ since the GNOME Foundation has developers for this, etc.), and we'd prefer to explore other ways to fix the issue first. For example, a lot of companies do have an interest in GTK+ but are not actively participating upstream. I've been in contact with some of them to see if they could get some of their developers to freely work on upstream as part of their job. People have been open about this idea, but I'm sure we could come with better arguments to really convince them. Vincent -- Les gens heureux ne sont pas pressés. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ maintenance
On Tue, 2007-05-15 at 22:29 +0200, Olav Vitters wrote: > On Thu, Apr 26, 2007 at 01:08:10AM +0200, Vincent Untz wrote: [...] > > Some comparison... > > http://www.trolltech.com/company > "Trolltech is a software company with two product lines: Qt and Qtopia. > We currently have 200 employees working at offices worldwide." > > This includes a lot of other things (you only want Qt devs), but > still... 200 vs 2 / 8? > This is not representative of anything. Before I go running my trap I'll note that I am not a gtk+ maintainer so I am not qualified to answer Vincent's query, but it should be noted that people writing patches for gtk+ are in no way lacking - this is a very popular project and has attracted alot of attention. Its been clearly stated that core maintainers are whats lacking, people that can be trusted to review large patches, do refactoring work and call shots so to speak, in my own personal opinion I think gtk+ could do fine with 2 extra Mattias Clasens or 2 more Tim Janiks, the question is; where are these experienced people to be found ? Will the foundation be considering hiring people from the gnome community ? (I would suppose so...) will there be location constraints (will developers have to move) ? will developers have to well known and trusted or will they have to be highly decorated ? (a healty mix of either/or/both I suppose...) Those kind of answers will also narrow down the possibilities of finding qualified people to be core maintainers of gtk+. Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ maintenance
On Thu, Apr 26, 2007 at 01:08:10AM +0200, Vincent Untz wrote: > It'd be useful to know how many more people are needed to have things > working more smoothly. Let's talk about full-time people: would 2 people > be enough? Or do we need much more than 2, like 8 full-time developers? > This is the kind of information that will help us convince companies to > put more manpower into GTK+. Some comparison... http://www.trolltech.com/company "Trolltech is a software company with two product lines: Qt and Qtopia. We currently have 200 employees working at offices worldwide." This includes a lot of other things (you only want Qt devs), but still... 200 vs 2 / 8? -- Regards, Olav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib memory allocation problems
On Tue, 15 May 2007, Miklos Szeredi wrote: >>> And this is perfectly possible if program is using the pthread API, >>> while using glib for hash tables, etc. >> >> if you use the pthread API without calling g_thread_init(), you're getting >> yourself into trouble. don't do that, glib can't possibly work correctly >> in threaded scenarios without its threading system being initialized. > > I know that. Now. > > What I was suggesting is that glib should try to warn the user in such > a case. > > Possibly only if G_SLICE=debug-blocks is set or whatever. It doesn't > seem all that difficult: when accessing thread specific data, compare > with the last thread id. it *is* that difficult. there are a lot of things that will break if you expect glib to be thread safe without initializing threading. if you can come up with a patch that catches all cases (uses of mutexes, conditions, private data, thread methods, ...) without impacting (slowing down) the common uses, please file it in our bugzilla. > Miklos --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib memory allocation problems
Dimitrios Apostolou wrote: > I don't understand some things however, so here are some questions to glib > devs: > 1) Why the crash didn't occur when using G_SLICE=always-malloc? IANA glib dev. I believe when G_SLICE=always-malloc, the g_slice allocators are simplified to something like: g_slice_alloc(block_size) becomes malloc(block_size) g_slice_free(type, mem) becomes free(mem) and when -lpthread is used, thread-safe versions of malloc/free are linked in by the compiler. So, no crash since the memory allocators were thread safe. -brandon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib memory allocation problems
On Tue, 15 May 2007, Miklos Szeredi wrote: >> I don't understand some things however, so here are some questions to glib >> devs: >> 1) Why the crash didn't occur when using G_SLICE=always-malloc? > > Because only the gslice code used thread private data, the malloc() > code is thread safe without needing any initialization. inside glib, there are many more places besides gslice that rely on the program either being single threaded or calling g_thread_init. > Miklos --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib memory allocation problems
On Tue, 15 May 2007, Dimitrios Apostolou wrote:
> On Tue, 15 May 2007 16:14:26 +0200
> Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>> OK, found the problem: g_thread_init() wasn't called by sshfs, and
>> hence the thread private data used by gslice wasn't actually thread
>> private.
>>
>> Now I see that the mandatory use of g_thread_init() is documented, but
>> it's very non-obvious without reading the docs. And there are no
>> apparent problems if it's not called. Sshfs got away with it for a
>> long time even though people do stress it pretty heavily.
>>
>> So the question is, should glib not make some sanity checking for code
>> that is not actually thread related (like gslice).
>>
>> Dimitrios, there's a patch attached that should fix the crashes.
>>
>> Thanks,
>> Miklos
>
>
> Thank you Miklos, I am trying the patch now and I'll let you know how it
> goes. I really hope sshfs won't be crashing again.
>
> I don't understand some things however, so here are some questions to glib
> devs:
> 1) Why the crash didn't occur when using G_SLICE=always-malloc?
because you used glib invalidly when you used the pthread
API but didn't call g_thread_init. thus, you got crashes
in glib, but not in malloc/free (which is used in case of
G_SLICE=always-malloc).
> 2) I never got any warning when using G_SLICE=debug-blocks, although I
> reproduced the crash several times. Is it normal?
well, you screwed up glib structures with the threading already,
so you can crash *anywhere* in glib. G_SLICE=debug-blocks just
tells you if you used the g_slice_alloc/g_slice_free API correctly
which you aparently did if you didn't get any warnings.
> 3) What about the constantly increasing memory usage that I described in my
> first email, is it expected when using G_SLICE=always-malloc?
> I was certainly surprised to witness my system crawl down to a halt, because
> of swapping...
no, nothing in malloc/free (G_SLICE=always-malloc) or in glib
should constantly eat memory on its own. to have steadily
increasing memory, you need to do something like:
while (1)
{
GSList *slist = g_slist_alloc();
/* g_slist_free (slist); */
}
that'll eventually run out of mem.
i.e. what you describe is most probably something in your code/libs
not releasing memory or ref counts.
> Thanks in advance,
> Dimitris
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib memory allocation problems
On Tue, 15 May 2007, Miklos Szeredi wrote: >>> So the question is, should glib not make some sanity checking for code >>> that is not actually thread related (like gslice). >> >> it does do sanity checking, it throws a big bold warning if you call >> thread_init and gslice in the wrong order: >>http://blogs.gnome.org/view/timj/2007/01/02/0 >>http://bugzilla.gnome.org/show_bug.cgi?id=331853 > > But if g_thread_init() was not called _at all_, it just silently > corrupts the data structures. no, gslice works perfectly fine in a single threaded program. > And this is perfectly possible if program is using the pthread API, > while using glib for hash tables, etc. if you use the pthread API without calling g_thread_init(), you're getting yourself into trouble. don't do that, glib can't possibly work correctly in threaded scenarios without its threading system being initialized. > Probably this situation is not even so rare, and other programs may be > suffering from this same problem, without being aware of it. > > Miklos > --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib memory allocation problems
On Tue, 15 May 2007 16:14:26 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote: > OK, found the problem: g_thread_init() wasn't called by sshfs, and > hence the thread private data used by gslice wasn't actually thread > private. > > Now I see that the mandatory use of g_thread_init() is documented, but > it's very non-obvious without reading the docs. And there are no > apparent problems if it's not called. Sshfs got away with it for a > long time even though people do stress it pretty heavily. > > So the question is, should glib not make some sanity checking for code > that is not actually thread related (like gslice). > > Dimitrios, there's a patch attached that should fix the crashes. > > Thanks, > Miklos Thank you Miklos, I am trying the patch now and I'll let you know how it goes. I really hope sshfs won't be crashing again. I don't understand some things however, so here are some questions to glib devs: 1) Why the crash didn't occur when using G_SLICE=always-malloc? 2) I never got any warning when using G_SLICE=debug-blocks, although I reproduced the crash several times. Is it normal? 3) What about the constantly increasing memory usage that I described in my first email, is it expected when using G_SLICE=always-malloc? I was certainly surprised to witness my system crawl down to a halt, because of swapping... Thanks in advance, Dimitris ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib memory allocation problems
> > So the question is, should glib not make some sanity checking for code > > that is not actually thread related (like gslice). > > it does do sanity checking, it throws a big bold warning if you call > thread_init and gslice in the wrong order: >http://blogs.gnome.org/view/timj/2007/01/02/0 >http://bugzilla.gnome.org/show_bug.cgi?id=331853 But if g_thread_init() was not called _at all_, it just silently corrupts the data structures. And this is perfectly possible if program is using the pthread API, while using glib for hash tables, etc. Probably this situation is not even so rare, and other programs may be suffering from this same problem, without being aware of it. Miklos ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib memory allocation problems
> > On Fri, 11 May 2007 13:55:25 +0200 (CEST) > > Tim Janik <[EMAIL PROTECTED]> wrote: > >> it's likely that some code portions erroneously use GSlice and thus screw > >> up the memory handling at some point. G_SLICE=debug-blocks is really the > >> recommended way to find those errors and much faster than trying > >> valgrind (and definitely more accurate about slices). > > > > Hello, > > > > I reproduced the crash using G_SLICE=debug-blocks, this time using > > a different usage scenario (the one described at > > http://sourceforge.net/mailarchive/message.php?msg_name=E1Hjvl8-0006OR-00%40dorka.pomaz.szeredi.hu > > ). Unfortunately the program didn't output any debugging text like > > the one you describe in your blog. So I got another backtrace and > > kept that coredump too so that I can run any command you tell me. > > > > So does the attached backtrace means anything to you? > > seems you managed to crash around the slice debugger doing realloc(). > more interesting than the backtrace should actually be the > program output. > if you saw something like: >GSlice: MemChecker: attempt to release block with invalid size... > then you actually have something to fix. > if not, i suspect you have a bad memory corruption somewhere, e.g. > where you're writing into already released memory regoins. > that can cause crashes pretty much everywhere. OK, found the problem: g_thread_init() wasn't called by sshfs, and hence the thread private data used by gslice wasn't actually thread private. Now I see that the mandatory use of g_thread_init() is documented, but it's very non-obvious without reading the docs. And there are no apparent problems if it's not called. Sshfs got away with it for a long time even though people do stress it pretty heavily. So the question is, should glib not make some sanity checking for code that is not actually thread related (like gslice). Dimitrios, there's a patch attached that should fix the crashes. Thanks, Miklos Index: configure.ac === RCS file: /cvsroot/fuse/sshfs/configure.ac,v retrieving revision 1.17 diff -u -r1.17 configure.ac --- configure.ac19 Feb 2007 16:04:03 - 1.17 +++ configure.ac15 May 2007 14:11:10 - @@ -20,7 +20,7 @@ AM_CONDITIONAL(SSH_NODELAY_SO, test "$enable_sshnodelay" != "no") export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH -PKG_CHECK_MODULES(SSHFS, [fuse >= 2.2 glib-2.0]) +PKG_CHECK_MODULES(SSHFS, [fuse >= 2.2 glib-2.0 gthread-2.0]) have_fuse_opt_parse=no AC_CHECK_FUNC([fuse_opt_parse], [have_fuse_opt_parse=yes]) if test "$have_fuse_opt_parse" = no; then Index: sshfs.c === RCS file: /cvsroot/fuse/sshfs/sshfs.c,v retrieving revision 1.83 diff -u -r1.83 sshfs.c --- sshfs.c 18 Apr 2007 09:44:08 - 1.83 +++ sshfs.c 15 May 2007 14:11:12 - @@ -2605,6 +2608,8 @@ char *base_path; const char *sftp_server; +g_thread_init(NULL); + sshfs.blksize = 4096; sshfs.max_read = 65536; sshfs.nodelay_workaround = 1; ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib memory allocation problems
> > seems you managed to crash around the slice debugger doing realloc(). > > more interesting than the backtrace should actually be the > > program output. > > if you saw something like: > >GSlice: MemChecker: attempt to release block with invalid size... > > I saw no such output on the last ~100 lines before the crash, that's > why I took the backtrace... > > > then you actually have something to fix. > > if not, i suspect you have a bad memory corruption somewhere, e.g. > > where you're writing into already released memory regoins. > > that can cause crashes pretty much everywhere. Hmm. We did check for memory corruption with valgrind. Maybe valgrind didn't catch this one, because it's not aware of glib's allocator. Dimitrios, can you run your test with valgrind and with G_SLICE=always-malloc? Maybe that'll catch some corruption that valgrind didn't catch with the g_slice allocator. > the machine is memchecked/cpuchecked and no memory errors > occur. Miklos, perhaps you figured out an sshfs bug on the latest > backtraces? No, the backtraces just show that there's memory corruption in glib's allocator. But there's no indication where this corruption could be coming from. Thanks, Miklos ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib memory allocation problems
On Tue, 15 May 2007, Miklos Szeredi wrote: >>> On Fri, 11 May 2007 13:55:25 +0200 (CEST) >> seems you managed to crash around the slice debugger doing realloc(). >> more interesting than the backtrace should actually be the >> program output. >> if you saw something like: >>GSlice: MemChecker: attempt to release block with invalid size... >> then you actually have something to fix. >> if not, i suspect you have a bad memory corruption somewhere, e.g. >> where you're writing into already released memory regoins. >> that can cause crashes pretty much everywhere. > > OK, found the problem: g_thread_init() wasn't called by sshfs, and > hence the thread private data used by gslice wasn't actually thread > private. > > Now I see that the mandatory use of g_thread_init() is documented, but > it's very non-obvious without reading the docs. And there are no > apparent problems if it's not called. Sshfs got away with it for a > long time even though people do stress it pretty heavily. > > So the question is, should glib not make some sanity checking for code > that is not actually thread related (like gslice). it does do sanity checking, it throws a big bold warning if you call thread_init and gslice in the wrong order: http://blogs.gnome.org/view/timj/2007/01/02/0 http://bugzilla.gnome.org/show_bug.cgi?id=331853 > > Dimitrios, there's a patch attached that should fix the crashes. > > Thanks, > Miklos --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk+/glib versions for GNOME 2.20
Hi, In [1], Tim mentioned that the current plan was to release GTK+ 2.12 mid-June. Is this still the case or do you expect a delay? This would be useful to know, so we can tell people that it's okay to use the new GTK+ features. And any idea about glib 2.14? I guess if GTK+ 2.12 will be ready, the new glib will be ready too. (FWIW, Behdad told on IRC that he expects GNOME 2.20 to use pango 1.18) Thanks, [1] http://mail.gnome.org/archives/gtk-devel-list/2007-April/msg00175.html Vincent -- Les gens heureux ne sont pas pressés. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ maintenance
Le jeudi 26 avril 2007, à 01:08 +0200, Vincent Untz a écrit : > It'd be useful to know how many more people are needed to have things > working more smoothly. Let's talk about full-time people: would 2 people > be enough? Or do we need much more than 2, like 8 full-time developers? > This is the kind of information that will help us convince companies to > put more manpower into GTK+. Does anybody have an approximation for this? :-) Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk: hide window when minimized
On Tue, 2007-05-15 at 13:51 +0200, bronson wrote: > Hello, > > could anyone tell me how can I hide window, when user minimizes it? > I tried to handle signal 'window-state-event', but when in that method i > hide window, > strange things happen - window hides, and then shows up again and it > never ends. why would you want to hide a minimised window, which should already be hidden by your window manager? and, most of all, you should really ask on gtk-app-devel-list - this list is for developing gtk+, non *with* gtk+. ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk: hide window when minimized
Hello, could anyone tell me how can I hide window, when user minimizes it? I tried to handle signal 'window-state-event', but when in that method i hide window, strange things happen - window hides, and then shows up again and it never ends. Any help would be appretiated. Thanks in advance, Przemu ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fixing the GtkTreeModel::row-deleted inconsistency
On Fri, May 11, 2007 at 11:19:24AM +0200, Fontana Nicola wrote: > In gtk_list_store_remove() and gtk_tree_store_remove(), is it possible to: > > - remove the row from the model > - call gtk_tree_model_row_deleted(), leaving the row data accessible with > gtk_tree_model_get_iter() or with a new API method > - free the row data It depends what you mean with "remove the row from the model". If that means unlinking the row from the model's data structures, then there's not a nice way anymore to retrieve an iterator to access that row. And if _get_iter() is still supposed to be working, all other model methods should also work: you are much better off not removing the row in that case :) > I intent the row_deleted signal as "this row is really gone from the model", > not from the universe: I think having a signal that tell you something > happened without specifying the subject is quite useless. I think row-deleted does specifiy you the subject, one of its arguments is the path ... regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fixing the GtkTreeModel::row-deleted inconsistency
On Thu, May 10, 2007 at 07:05:05PM -0500, Federico Mena Quintero wrote: > So in general > > - A node is referenced if it is within the scrolled-in area of the view. No, these references have nothing to do with the scrolled-in area of the view... > - A node is referenced if it is expanded, even if it is not within the > scrolled-in area (i.e. everything which the rbtree mirrors is reffed). Yes, and the "invisible root node" is always expanded, so all toplevel nodes are always reffed. The toplevel nodes are all mirrored by the rbtree. > [Humm, toplevel nodes are always in the rbtree, I think. Does this mean > that all toplevel nodes are always reffed?] Yes. > I'd love to watch a little toy model that just keeps an int for each > node, and printf()s the references for each node as they change. Then > you could see if scrolling the view up and down indeed keeps only the > required nodes reffed --- this would be good evidence that you can > indeed implement a model which doesn't have all its data exploded in > memory all the time. I think it would be nice to have a mechanism for models to know which rows are currently visible, and which are not, in the future. (Maybe something like a "visible-window-of-rows-changed" signal with a new begin and end row... but just brainstorming here now.) regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
