You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(3) |
Aug
(3) |
Sep
|
Oct
(1) |
Nov
(5) |
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
(12) |
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
(15) |
Nov
(8) |
Dec
(4) |
2006 |
Jan
|
Feb
|
Mar
(11) |
Apr
(10) |
May
(105) |
Jun
(12) |
Jul
(42) |
Aug
(54) |
Sep
(15) |
Oct
(14) |
Nov
(27) |
Dec
(3) |
2007 |
Jan
(1) |
Feb
(6) |
Mar
(26) |
Apr
(11) |
May
(28) |
Jun
(5) |
Jul
(9) |
Aug
|
Sep
|
Oct
(4) |
Nov
(8) |
Dec
(7) |
2008 |
Jan
(4) |
Feb
(1) |
Mar
|
Apr
|
May
(6) |
Jun
(7) |
Jul
|
Aug
(16) |
Sep
(1) |
Oct
(4) |
Nov
(3) |
Dec
(1) |
2009 |
Jan
(37) |
Feb
(19) |
Mar
(32) |
Apr
(7) |
May
(2) |
Jun
(15) |
Jul
(8) |
Aug
(12) |
Sep
(2) |
Oct
(1) |
Nov
(6) |
Dec
(11) |
2010 |
Jan
(11) |
Feb
(5) |
Mar
(56) |
Apr
(75) |
May
(28) |
Jun
(10) |
Jul
(6) |
Aug
(1) |
Sep
(26) |
Oct
(23) |
Nov
(92) |
Dec
(41) |
2011 |
Jan
(6) |
Feb
(2) |
Mar
(2) |
Apr
(8) |
May
(20) |
Jun
(3) |
Jul
(1) |
Aug
(32) |
Sep
(6) |
Oct
(9) |
Nov
(3) |
Dec
(15) |
2012 |
Jan
(6) |
Feb
(13) |
Mar
|
Apr
(1) |
May
|
Jun
(2) |
Jul
(4) |
Aug
(7) |
Sep
|
Oct
(2) |
Nov
|
Dec
(4) |
2013 |
Jan
(9) |
Feb
(15) |
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
(9) |
Aug
|
Sep
(5) |
Oct
(4) |
Nov
(4) |
Dec
(11) |
2014 |
Jan
|
Feb
(3) |
Mar
(8) |
Apr
|
May
(4) |
Jun
(2) |
Jul
(2) |
Aug
(9) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
(3) |
May
(7) |
Jun
(3) |
Jul
(5) |
Aug
(15) |
Sep
|
Oct
(1) |
Nov
|
Dec
(6) |
2016 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(6) |
Oct
(6) |
Nov
(7) |
Dec
(8) |
2017 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(8) |
2018 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
(10) |
Jun
|
Jul
|
Aug
(5) |
Sep
(4) |
Oct
(3) |
Nov
(3) |
Dec
(4) |
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(40) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-27 23:56:22
|
https://bugzilla.gnome.org/show_bug.cgi?id=614137 gnome-perl | Gtk2 | unspecified muppet <scott> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #157293|none |accepted-commit_now status| | --- Comment #3 from muppet <sc...@as...> 2010-03-27 23:56:13 UTC --- Review of attachment 157293: --> (https://bugzilla.gnome.org/review?bug=614137&attachment=157293) Also good. This patch review interface needs a "Ship It!" button like review board. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-27 23:56:13
|
https://bugzilla.gnome.org/show_bug.cgi?id=614137 gnome-perl | Gtk2 | unspecified muppet <scott> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #157292|none |accepted-commit_now status| | --- Comment #2 from muppet <sc...@as...> 2010-03-27 23:56:01 UTC --- Review of attachment 157292: --> (https://bugzilla.gnome.org/review?bug=614137&attachment=157292) Looks good to me. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-27 23:07:20
|
https://bugzilla.gnome.org/show_bug.cgi?id=614137 gnome-perl | Gtk2 | unspecified --- Comment #1 from Kevin Ryde <us...@zi...> 2010-03-27 23:07:04 UTC --- Created an attachment (id=157293) View: https://bugzilla.gnome.org/attachment.cgi?id=157293 Review: https://bugzilla.gnome.org/review?bug=614137&attachment=157293 GtkMenu.t test case forget the test to exercise it -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-27 23:05:04
|
https://bugzilla.gnome.org/show_bug.cgi?id=614137 gnome-perl | Gtk2 | unspecified Summary: Menu set_screen() allow NULL Classification: Bindings Product: gnome-perl Version: unspecified OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: Gtk2 AssignedTo: gtk...@li... ReportedBy: us...@zi... QAContact: gtk...@li... GNOME target: --- GNOME version: --- Created an attachment (id=157292) View: https://bugzilla.gnome.org/attachment.cgi?id=157292 Review: https://bugzilla.gnome.org/review?bug=614137&attachment=157292 GdkScreen_ornull for gtk_menu_set_screen() I believe gtk_menu_set_screen() accepts NULL, but the wrapper doesn't allow that. Have I whinged about the tedium of manually wrapped set funcs lately :-) -- "Is it about the hedge?" -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-26 00:48:54
|
https://bugzilla.gnome.org/show_bug.cgi?id=613973 gnome-perl | Gtk2 | unspecified --- Comment #2 from Kevin Ryde <us...@zi...> 2010-03-26 00:48:42 UTC --- Is it permitted to die in a log handler? There'd have to be quite a few places that'd be a bad thing wouldn't there? The gperl_log_func() callback invocation may even be another of the various GPerlCallbacks which would benefit from eval protection. For the popup I'm open to ideas for the right log level and domain. "Error" may be better than warning, but non-fatal, still continuing with the code, not jumping out. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-26 00:35:59
|
https://bugzilla.gnome.org/show_bug.cgi?id=613972 gnome-perl | Gtk2 | unspecified --- Comment #2 from Kevin Ryde <us...@zi...> 2010-03-26 00:35:50 UTC --- Ah, I see, copied because it's hard to call a varargs. Is there a reason it's Gtk2->show_about_dialog and not Gtk2::AboutDialog->show_about_dialog? If the latter I wondered if called on a subclass like MyAboutDialogSubclass->show_about_dialog it could create an instance of the subclass, instead of always gtk_about_dialog_new(). -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-26 00:27:54
|
https://bugzilla.gnome.org/show_bug.cgi?id=613970 gnome-perl | Gtk2 | unspecified --- Comment #2 from Kevin Ryde <us...@zi...> 2010-03-26 00:27:44 UTC --- Ah, oops, I see gtk_tree_store_init() avoids stamp==0, so it's only ListStore to worry about -- its gtk_list_store_init() doesn't avoid stamp==0. The user_data coming in shouldn't be NULL, it's the G_SLIST() thingie of the row being removed. But in any case in last bit of gtk_list_store_remove() if there's a next row then it's changed and if not then it's unchanged. Of course this is not general, it only has to be enough for the 2.0.x sources and that particular remove func. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-25 23:59:58
|
https://bugzilla.gnome.org/show_bug.cgi?id=613970 gnome-perl | Gtk2 | unspecified muppet <scott> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sc...@as... --- Comment #1 from muppet <sc...@as...> 2010-03-25 23:59:44 UTC --- This isn't really that reliable, either. If the user_data pointer is NULL, then you're stuck. In GtkTreeModel.xs, it looks like NULL is a perfectly valid value for user_data. The code in gtkliststore.c in gtk+ will explicitly set the stamp to 0 to indicate removal, so i'm inclined to say that 0 is not a valid value for a user's stamp. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-25 23:42:51
|
https://bugzilla.gnome.org/show_bug.cgi?id=613972 gnome-perl | Gtk2 | unspecified muppet <scott> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #157124|none |rejected status| | --- Comment #1 from muppet <sc...@as...> 2010-03-25 23:42:42 UTC --- Review of attachment 157124: --> (https://bugzilla.gnome.org/review?bug=613972&attachment=157124) This xs convenience impl was originally a copy of the C function from gtk+/gtk/gtkabout.c. If you look in there, they actually call gtk_window_set_transient_for() if you give a parent pointer. Just do what gtk+ does. :-) http://git.gnome.org/browse/gtk+/tree/gtk/gtkaboutdialog.c -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-25 23:37:10
|
https://bugzilla.gnome.org/show_bug.cgi?id=613973 gnome-perl | Gtk2 | unspecified muppet <scott> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #157125|none |accepted-commit_now status| | --- Comment #1 from muppet <sc...@as...> 2010-03-25 23:37:00 UTC --- Review of attachment 157125: --> (https://bugzilla.gnome.org/review?bug=613973&attachment=157125) I heartily condone this change. My one reservation was about eating errors, but you've addressed that with the g_warning(). Now, if you have a g_log handler installed, and it decides to die on that warning, you have the same issue, right? -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-25 23:19:31
|
https://bugzilla.gnome.org/show_bug.cgi?id=613973 gnome-perl | Gtk2 | unspecified Summary: Menu popup() protect against die Classification: Bindings Product: gnome-perl Version: unspecified OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: Gtk2 AssignedTo: gtk...@li... ReportedBy: us...@zi... QAContact: gtk...@li... GNOME target: --- GNOME version: --- Created an attachment (id=157125) View: https://bugzilla.gnome.org/attachment.cgi?id=157125 Review: https://bugzilla.gnome.org/review?bug=613973&attachment=157125 G_EVAL around the positioning func for Menu popup() I wonder if $menu->popup() could have an eval to protect against die() in the positioning function. In some of my code an error caused a persistent X grab, locking the screen until the client program is killed. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-25 23:14:02
|
https://bugzilla.gnome.org/show_bug.cgi?id=613972 gnome-perl | Gtk2 | unspecified Summary: AboutDialog show_about_dialog() same screen as parent Classification: Bindings Product: gnome-perl Version: unspecified OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: Normal Component: Gtk2 AssignedTo: gtk...@li... ReportedBy: us...@zi... QAContact: gtk...@li... GNOME target: --- GNOME version: --- Created an attachment (id=157124) View: https://bugzilla.gnome.org/attachment.cgi?id=157124 Review: https://bugzilla.gnome.org/review?bug=613972&attachment=157124 make show_about_dialog() default to the screen of the parent I wonder if Gtk2->show_about_dialog might popup the new AboutDialog on the same screen as the $parent it's given. In a multi-screen/multi-display program I think that might make most sense. If $parent is a main window running a Help/About then that screen is almost certainly where you're looking. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-25 23:09:59
|
https://bugzilla.gnome.org/show_bug.cgi?id=613970 gnome-perl | Gtk2 | unspecified Summary: ListStore/TreeStore 2.0.x remove() again Classification: Bindings Product: gnome-perl Version: unspecified OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: Gtk2 AssignedTo: gtk...@li... ReportedBy: us...@zi... QAContact: gtk...@li... GNOME target: --- GNOME version: --- Created an attachment (id=157122) View: https://bugzilla.gnome.org/attachment.cgi?id=157122 Review: https://bugzilla.gnome.org/review?bug=613970&attachment=157122 second attempt ListStore/TreeStore remove() on gtk 2.0.x I realized what I posted before for ListStore and TreeStore remove() for gtk 2.0.x is not right in the rare case that the Store's normal stamp is 0 and thus doesn't indicate a zapping. New attempt below, looking at a "user_data" change. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-19 21:42:00
|
https://bugzilla.gnome.org/show_bug.cgi?id=613369 gnome-perl | Gtk2 | unspecified Summary: Menu popup() release position func on call with undef Classification: Bindings Product: gnome-perl Version: unspecified OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: Normal Component: Gtk2 AssignedTo: gtk...@li... ReportedBy: us...@zi... QAContact: gtk...@li... GNOME target: --- GNOME version: --- Created an attachment (id=156589) View: https://bugzilla.gnome.org/attachment.cgi?id=156589 Review: https://bugzilla.gnome.org/review?bug=613369&attachment=156589 release previous position func on popup(undef) If $menu->popup() is called with undef for its position function I wonder if it can release any previous position function it's holding onto, the same as when a new (not undef) position func is passed in, per attached diff? -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-19 21:02:09
|
https://bugzilla.gnome.org/show_bug.cgi?id=613363 gnome-perl | Gtk2 | unspecified Summary: Menu popup() key "_menu_pos_callback" Classification: Bindings Product: gnome-perl Version: unspecified OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: Normal Component: Gtk2 AssignedTo: gtk...@li... ReportedBy: us...@zi... QAContact: gtk...@li... GNOME target: --- GNOME version: --- While nosing around Gtk2::Menu::popup() I wondered if the object data key "_menu_pos_callback" might want to be a prefixed name like "_gtk2perl_menu_pos_callback" or similar, as protection against clashing with an application's data names (unlikely though that may be). -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-19 19:39:15
|
https://bugzilla.gnome.org/show_bug.cgi?id=592391 gnome-perl | Gtk2 | unspecified --- Comment #3 from Kevin Ryde <us...@zi...> 2010-03-19 19:39:00 UTC --- Created an attachment (id=156579) View: https://bugzilla.gnome.org/attachment.cgi?id=156579 Review: https://bugzilla.gnome.org/review?bug=592391&attachment=156579 docs of MenuItem circular ref I got to these few words, plus test cases exercising the truth of the words :-). -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-19 18:51:36
|
https://bugzilla.gnome.org/show_bug.cgi?id=613353 gnome-perl | Gtk2 | unspecified Summary: AccelLabel set_accel_widget() allow NULL Classification: Bindings Product: gnome-perl Version: unspecified OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: Gtk2 AssignedTo: gtk...@li... ReportedBy: us...@zi... QAContact: gtk...@li... GNOME target: --- GNOME version: --- Created an attachment (id=156576) View: https://bugzilla.gnome.org/attachment.cgi?id=156576 Review: https://bugzilla.gnome.org/review?bug=613353&attachment=156576 accept undef in set_accel_widget() I believe $accel_label->set_accel_widget can accept NULL for when there's no target widget. (Which is its default setting too I think.) Perhaps an _ornull per below. Should get_accel_widget have an _ornull on its return similarly? Or plain GtkWidget typemap already allows NULL in a return, so it doesn't matter ... The tedium of individually wrapped get/set_foo funcs, eh :-) -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-18 22:53:02
|
https://bugzilla.gnome.org/show_bug.cgi?id=592391 gnome-perl | Gtk2 | unspecified --- Comment #2 from Kevin Ryde <us...@zi...> 2010-03-18 22:52:50 UTC --- Created an attachment (id=156519) --> (https://bugzilla.gnome.org/attachment.cgi?id=156519) sample circular ref between MenuItem and AccelLabel -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-18 22:50:49
|
https://bugzilla.gnome.org/show_bug.cgi?id=592391 gnome-perl | Gtk2 | unspecified Kevin Ryde <user42> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |us...@zi... --- Comment #1 from Kevin Ryde <us...@zi...> 2010-03-18 22:50:37 UTC --- I think this is dodginess in Gtk itself. A new_with_label makes an GtkAccelLabel with its "accel-widget" set to the item, which is a circular reference between the item and label. Sample accel.pl attached. I suppose the circularity is normally undone by a destroy() on the top GtkMenu calling destroy on all its children and sub-children. Needing to call $item->destroy from perl is unpleasant, but I suppose it's not a bug strictly speaking. We've got notes in Gtk2::Window on the need for explicit destroy() there. Perhaps a similar bit in Gtk2::MenuItem, and a cross reference in Gtk2::AccelLabel. I might have a go at a few words if no-one beats me to it. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-18 22:04:11
|
https://bugzilla.gnome.org/show_bug.cgi?id=613279 gnome-perl | Gtk2 | unspecified Summary: Gtk2::Menu docs of popup() Classification: Bindings Product: gnome-perl Version: unspecified OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: Normal Component: Gtk2 AssignedTo: gtk...@li... ReportedBy: us...@zi... QAContact: gtk...@li... GNOME target: --- GNOME version: --- Created an attachment (id=156517) View: https://bugzilla.gnome.org/attachment.cgi?id=156517 Review: https://bugzilla.gnome.org/review?bug=613279&attachment=156517 docs of Gtk2::Menu::popup() The docs for Gtk2::Menu could show how the popup() callback works, per attachment. In particular I think it should note how the func and data are stored in the menu as that's a bit subtle and affects circular references. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-09 00:33:05
|
https://bugzilla.gnome.org/show_bug.cgi?id=612247 gnome-perl | Gtk2 | unspecified Summary: Gtk2::Editable docs of insert-text signal Classification: Bindings Product: gnome-perl Version: unspecified OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: Gtk2 AssignedTo: gtk...@li... ReportedBy: us...@zi... QAContact: gtk...@li... GNOME target: --- GNOME version: --- Created an attachment (id=155599) View: https://bugzilla.gnome.org/attachment.cgi?id=155599 Review: https://bugzilla.gnome.org/review?bug=612247&attachment=155599 docs of insert-text signal The pod for Gtk2::Editable could describe how to use the insert-text signal to modify the inserted text, perhaps per diff below. I tried to use it through a class closure and was confused for a while about what the parameters were, hence the bit about the class closure unmarshalled at the moment, if I'm not mistaken. (I accidentally mangled the pos "pointer" argument when chaining up with signal_chain_from_overridden() and got a segv.) -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-07 04:43:52
|
https://bugzilla.gnome.org/show_bug.cgi?id=610022 gnome-perl | Gnome2::PanelApplet | unspecified Torsten Schoenfeld <kaffeetisch> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |kaf...@gm... Resolution| |FIXED --- Comment #1 from Torsten Schoenfeld <kaf...@gm...> 2010-03-07 01:26:50 UTC --- Done in the just-released version 0.03. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-07 04:36:34
|
https://bugzilla.gnome.org/show_bug.cgi?id=585215 gnome-perl | Glib | unspecified Torsten Schoenfeld <kaffeetisch> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEEDINFO CC| |kaf...@gm... -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-07 04:16:43
|
https://bugzilla.gnome.org/show_bug.cgi?id=612006 gnome-perl | Pango | unspecified Summary: Add PangoGlyph support Classification: Bindings Product: gnome-perl Version: unspecified OS/Version: Linux Status: NEW Severity: normal Priority: Normal Component: Pango AssignedTo: gtk...@li... ReportedBy: kaf...@gm... QAContact: gtk...@li... GNOME target: --- GNOME version: --- Created an attachment (id=155420) View: https://bugzilla.gnome.org/attachment.cgi?id=155420 Review: https://bugzilla.gnome.org/review?bug=612006&attachment=155420 Initial stab If and when it becomes useful, add support for the PangoGlyph stuff. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2010-03-07 04:15:11
|
https://bugzilla.gnome.org/show_bug.cgi?id=591070 gnome-perl | Glib | unspecified Torsten Schoenfeld <kaffeetisch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kaf...@gm... --- Comment #2 from Torsten Schoenfeld <kaf...@gm...> 2010-03-06 14:57:45 UTC --- muppet created a similar patch many moons ago, and I recently committed it (without remembering this bug entry): <http://git.gnome.org/browse/perl-Glib/commit/?id=2b1a35b9d>. This old patch called the is_a_type accessor simply is_a_type(), which is inconsistent, so I just fixed that: <http://git.gnome.org/browse/perl-Glib/commit/?id=78696b6f8>. As far as I can see, the only remaining substantial difference between your patch and the committed version is this: --- a/GType.xs +++ b/GType.xs @@ -2018,6 +2018,7 @@ BOOT: gperl_register_fundamental (G_TYPE_FLOAT, "Glib::Float"); gperl_register_fundamental (G_TYPE_DOUBLE, "Glib::Double"); gperl_register_fundamental (G_TYPE_BOOLEAN, "Glib::Boolean"); + gperl_register_fundamental (G_TYPE_GTYPE, "Glib::GType"); gperl_register_boxed (GPERL_TYPE_SV, "Glib::Scalar", NULL); /* i love nasty ugly hacks for backwards compat... Glib::UInt used I'm not entirely sure what this achieves. Does it allow me to have, say, Glib::TreeView columns of type "Glib::GType"? If so, do we want to allow that? (We used to completely hide the existence of GType from the Perl programmer.) What else does this do? -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |