GList strange behavior
Hi, list. I can't understand, why g_list_append return different values in my callback's(please read source). In first case i got same list, which was obtained from arguments. In second case g_list_append returns newly created list. Why result's is are not the same? In real program, i need to get newly created list pointer in function like button_cb(), but don't know how to do it. source: http://pastebin.com/4gMREKwd output on my laptop: INIT list prt: 0x830f080 Created: 0x830f080, arg: 0x830f080 Last list element: 0x832c610 Init list ptr: 0x832c5c0 Second list ptr: 0x830f120 End ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GList strange behavior
Hi, In button_cb()... Did you mean Last list element: 0x832c610 is differ from INIT list prt: 0x830f080? It's clear because 0x830f080 was the location of first list and 0x832c610 is the last appended list. g_list_prepend() return to the start of the list, g_list_last() return the last of the list (address). in test_glist() First you call temp = g_list_insert(test, ...), test = NULL, save the list to temp pointer to GList, second, you call temp = g_list_append(test, ...), nothing wrong with that code! BUT if you suppose to insert 2nd list here, then you are wrong. Because, test is STILL NULL. It returns the newly allocated list again, that's why it's differ. You should call call temp = g_list_append(temp,...) or to insert the next list. In real program, i need to get newly created list pointer in function like button_cb(), but don't know how to do it. Just pass it through callback's argument or declare it as global variable. On Wed, Aug 15, 2012 at 8:04 AM, Vlasov Vitaly vnig...@gmail.com wrote: Hi, list. I can't understand, why g_list_append return different values in my callback's(please read source). In first case i got same list, which was obtained from arguments. In second case g_list_append returns newly created list. Why result's is are not the same? In real program, i need to get newly created list pointer in function like button_cb(), but don't know how to do it. source: http://pastebin.com/4gMREKwd output on my laptop: INIT list prt: 0x830f080 Created: 0x830f080, arg: 0x830f080 Last list element: 0x832c610 Init list ptr: 0x832c5c0 Second list ptr: 0x830f120 End ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Thoughts on bug 679400
Hi Friends Anyone have any wisdom on bug 679400? https://bugzilla.gnome.org/show_bug.cgi?id=679400 The proposed patch does the job well on my system. Regards Karl ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
On 08/04/2012 07:41 AM, Emmanuele Bassi wrote: and yet another case of i'm so nervous and irritated by criticism of our design decisions that i'll resort to calling people stupid ... design has nothing to do with it, sorry to disappoint the conspiracy theorists. just another case of somebody is wrong on the Internet that I should know better not to reply to. Just recently there was a discussion on this list about ways to better communicate between GTK+ devs and others including GTK+ users in order to attract potential contributors and keep GTK+ users in the loop as to the future of GTK+. For this reason I'm gratified to see this thread hit the devel list. It's interesting to be updated on the direction GTK+ is heading. That said, if the GTK+ developers cannot accept criticism of design decisions (you don't have to explain every little thing of course), or at least tolerate them (not the same as ignoring btw), then I fear we have the same problem that we had before, which is the perception that GTK+ developers are doing their own thing and not listening to the users. Maybe the only GTK+ users that matter are the Gnome developers, I don't know. But certainly at least two GTK+ users on this list have expressed the legitimate concern that the GtkSwitch widget has usability issues, which seems fair. They are definitely not wrong on the Internet. Doesn't mean they are right and that GTK+ should change direction, but reacting the way you did doesn't reflect well on the GTK+ developers. A more proper way to react may have been I can see your point, but current UI direction and usability research disagrees with you or we've received very positive feedback regarding this widget from GTK+ users and feel like this is the right direction to go. Agree to disagree, etc. Instead we're left wondering if GTK+ is just doing things because they're cool (IE Apple does it). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
