Menu
▾
▴
gtk2-perl-bugs — Bug reports and mail from bugzilla
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: <bug...@bu...> - 2005-04-19 10:14:32
|
Please DO NOT reply to this by email. All additional comments should be m= ade in the comments box of this bug report. http://bugzilla.gnome.org/show_bug.cgi?id=3D301171 gnome-perl | Glib | Ver: unspecified ------- Additional Comments From Emmanuele Bassi 2005-04-19 06:14 ------= - Created an attachment (id=3D45436) --> (http://bugzilla.gnome.org/attachment.cgi?id=3D45436&action=3Dview) Glib::KeyFile XS code Glib::KeyFile XS, with *_list variants implemented, and muppet's remarks = on string freeing ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@bu...> - 2005-04-19 10:12:58
|
Please DO NOT reply to this by email. All additional comments should be m= ade in the comments box of this bug report. http://bugzilla.gnome.org/show_bug.cgi?id=3D301171 gnome-perl | Glib | Ver: unspecified ------- Additional Comments From Emmanuele Bassi 2005-04-19 06:12 ------= - Created an attachment (id=3D45435) --> (http://bugzilla.gnome.org/attachment.cgi?id=3D45435&action=3Dview) Glib::KeyFile glue code The glue code for Glib::KeyFile, with the remarks from Torsten fro condit= ional compilation. ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@bu...> - 2005-04-19 10:09:32
|
Please DO NOT reply to this by email. All additional comments should be m= ade in the comments box of this bug report. http://bugzilla.gnome.org/show_bug.cgi?id=3D301171 gnome-perl | Glib | Ver: unspecified Summary: Adding Glib::KeyFile Product: gnome-perl Version: unspecified Platform: Other OS/Version: All Status: UNCONFIRMED Severity: enhancement Priority: Normal Component: Glib AssignedTo: gtk...@li... ReportedBy: emm...@em... CC: all...@bu... Perl bindings for the GKeyFile object ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <ro...@ww...> - 2005-03-04 13:33:49
|
<html> <head> <title>Untitled Document</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </head> <body bgcolor="#00CCFF" text="#000000"> <p align="center"><b><i><font size="7" color="#000000"><u><font color="#FFFFFF">HELP ROMANIAN CHILDRENS </font></u></font></i></b></p> <p align="center"> </p> <p align="center"><i><font face="Arial, Helvetica, sans-serif"><b>A LOT OF YOU MAYBE NEVER HEARED ABOUT ROMANIA, WE TELL YOU:</b></font></i></p> <p align="center"><font face="Arial, Helvetica, sans-serif"><b><i>IT'S A POOR COUNTRY SITUATED IN EASTERN EUROPE NEAR THE BLACK </i></b></font></p> <p align="center"><font face="Arial, Helvetica, sans-serif"><b><i>SEA HERE ROMANIAN STREETCHILDRENS ARE NOW MORE THAN 6000 </i></b></font></p> <p align="center"><font face="Arial, Helvetica, sans-serif"><b><i>AND THE ROMANIAN GOVERNMENT DON'T HAVE ENOUGH MONEY TO SUPORT THEM</i></b></font></p> <p align="center"><font face="Arial, Helvetica, sans-serif"><b><i>FOR THAT REASON WE THE G.O.R.S. (GROUP OF ROMANIAN STUDENTS) ASK YOU</i></b></font></p> <p align="center"><font face="Arial, Helvetica, sans-serif"><b><i>KINDLY TO HELP US ...TO HELP THEM ... TO GIVE THEM HOPE AND A BETTER LIFE </i></b></font></p> <p align="center"><font face="Arial, Helvetica, sans-serif"><b><i>LET'S JUST A MINUTE SEE THE LIFE TROUGH THEY'RE EYES , THEY ARE JUST </i></b></font></p> <p align="center"><font face="Arial, Helvetica, sans-serif"><b><i>KIDS LIKE YOUR SON AND DAUGHTER THEY AREN'T GUILTY FOR NOTHING</i></b></font></p> <p align="center"><font face="Arial, Helvetica, sans-serif"><b><i>FOR THAT WE MUST GIVE A HELPING HAND AND MAKE THEM REALIZE THAT THEY</i></b></font></p> <p align="center"><font face="Arial, Helvetica, sans-serif"><b><i>ARE NOT ALONE AND SOMEBODY CARE </i></b></font></p> <p align="center"> </p> <p align="center"><b><font color="#FFFFFF">THANKS IN ADVANCE AND HOPE YOU WILL VISIT OUR WEB SITE AT : </font></b></p> <p align="center"><b><font size="5">http://streetchildren.f2g.net</font></b></p> <p align="center"><b> FOR DETAILS CONTACT US BY E-MAIL : </b></p> <p align="center"><b><font size="3">str...@gm...</font> </b></p> <p align="center"> </p> <p align="center"> </p> <p align="center"> </p> <p align="center"><b><i></i></b></p> </body> </html> |
|
From: <bug...@bu...> - 2005-02-20 20:31:43
|
Please DO NOT reply to this by email. All additional comments should be made in the comments box of this bug report. http://bugzilla.gnome.org/show_bug.cgi?id=161012 gnome-perl | Gtk2 | Ver: unspecified Torsten Schoenfeld changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution| |WONTFIX Status|UNCONFIRMED |RESOLVED ------- Additional Comments From Torsten Schoenfeld 2005-02-20 15:31 ------- Closing and marking as WONTFIX as there really seems to nothing we can do about this. ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@bu...> - 2005-02-10 21:05:04
|
Please DO NOT reply to this by email. All additional comments should be made in the comments box of this bug report. http://bugzilla.gnome.org/show_bug.cgi?id=145110 gnome-perl | Gtk2 | Ver: unspecified Torsten Schoenfeld changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution| |FIXED Status|UNCONFIRMED |RESOLVED ------- Additional Comments From Torsten Schoenfeld 2005-02-10 16:04 ------- Tree paths are now explained in the POD for Gtk2::TreeModel. Closing. ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@bu...> - 2004-12-16 13:12:34
|
http://bugzilla.gnome.org/show_bug.cgi?id=161012 gnome-perl | Gtk2 | Ver: unspecified ------- Additional Comments From sc...@as... 2004-12-16 08:12 ------- While GObject is reference-counted and therefore can be better managed for lifetime, passing a GObject pointer where a GtkTreeIter pointer is wanted is pretty dangerous. I would imagine that the only reason you got away with it is that since GtkTreeIter is just a plain struct, gtk+ can't do sanity checks on it and so doesn't (it contains no type id). Even though you created a GObject with stamp and user_data fields, the compiler will not find them at the safe struct offset, so code compiled to work with a real GtkTreeIter will fail mysteriously with a GObject --- it will think that the GObject's type id is the stamp, for example. Furthermore, while gtk+ does no type checks on GtkTreeIters, the bindings expect that they are plain structs to be treated as GBoxed types, and will do the exactly wrong thing to a GObject pointer. Let's track a call to gtk_tree_model_get_value() through both C and perl to see what i mean: C: you've passed a GObject * to gtk_tree_model_get_value() for the iter. gtk_tree_model_get_value() checks that iter != NULL. This is true. gtk_tree_model_get_value() calls get_value() vfunc from your model's iface. This actually calls a function in your custom model, which expects a GObject, so things mostly work. If you passed it to a built-in model, however, it would eventually cause a segfault when gtk+ tried to use the bogus data. Perl: you attempt to pass a Glib::Object reference to Gtk2::TreeModel::get() Gtk2::TreeModel::get() calls SvGtkTreeIter() to fetch the pointer from the reference in ST(1). SvGtkTreeIter() is a macro (defined in gperl-autogen.h) that evaluates to gperl_get_boxed_check((sv), GTK_TYPE_TREE_ITER)). GTK_TYPE_TREE_ITER is a boxed type id, and gperl_get_boxed_check() will look up the registered boxed wrapper (the default, in this case), which assumes that the SV points to a wrapper struct containing the type id, a boolean saying whether the wrapper owns the struct, and a pointer to the struct; however, you've actually passed a magical GObject reference. The wrapper class's unwrap vfunc, in this case default_boxed_unwrap() in in Glib/GBoxed.xs, calls sv_derived_from() to verify that the reference is blessed into the package associated with GTK_TYPE_TREE_ITER, "Gtk2:: TreeIter". However, your type is derived from Glib::Object, so this check will fail with the message "MyFoo is not of type Gtk2::TreeIter". That is, you can't even get through the bindings to pass the wrong thing. So, i don't think using a GObject for the iter will help. ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@bu...> - 2004-12-16 08:31:37
|
http://bugzilla.gnome.org/show_bug.cgi?id=161012 gnome-perl | Gtk2 | Ver: unspecified ------- Additional Comments From zb...@fo... 2004-12-16 03:31 ------- It looks like the answer to my last question (can I make a "custom" TreeIter) is "yes". I made a subclass of GObject in C, with members called stamp and user_data, and I was successful in passing it into some GtkListStore functions by casting it to a (GtkTreeIter *). Does being a GObject provide enough lifetime management to allow "better" handling of TreeIters in Perl? If not, what other functionality should I try to add? ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@bu...> - 2004-12-11 18:29:24
|
http://bugzilla.gnome.org/show_bug.cgi?id=161012 gnome-perl | Gtk2 | Ver: unspecified ------- Additional Comments From zb...@fo... 2004-12-11 13:29 ------- To answer your question, Torsten, putting something into the array reference doesn't help me very much because I have to keep a copy of it around at least until the iter is no longer valid. Generally speaking, if I have that, then there's not much point putting it into the iter, too. Let's say I have a unique id number in the first usable element of the iter array, and some other piece of data I'd like to put in the second. In order to do that, I'm going to need to create Perl variables to store that data for each valid iter until it isn't valid anymore. To keep them organized, I'd probably use an array, with the unique ID as an index. I could then put a reference to the right element into the TreeIter. But that doesn't help much, because the array must persist as long as the TreeIter is valid, so why not just store only the index in the Iter, and get the data back out of the array when you need it? My problem is, I don't want to have to have that array in the first place. In some cases, when you're implementing a custom TreeModel, you want to be able to display data that's already stored in a Perl data structure, so there's no problem; you can just put references from there into the TreeIter. It has to persist anyway, because it's the actual data. But other times (like the one's I'm working with :o) you want to display data that's stored somewhere else, like a SQL database. If I have to take data out of the DB and put it into an array to be able to refer to it from an Iter, then I'm duplicating my data, which I don't want to do :o) This doesn't really become an issue until you need more than just one integer to uniquely identify a particular data point. Sometimes it would be nice, or maybe lead to performance enhancements, but as long as one integer is unique enough, then the Model can still be made to work. I think, though, that the C implementation of a GtkTreeIter (which I didn't know about before) means what I want can't work unless Gtk itself is changed, since there's no way to manage lifetime. I don't suppose there's any way to sort of make a "custom" TreeIter? Since it isn't a GObject (or a GInterface), I guess probably not. If I could do that in either Perl or C, I'd be all set, I think. This probably isn't the right place, but I'm going to mention what I'm thinking about so I don't lose it :o) As long as it's designed to behave like a real GtkTreeIter, that is, as long as it has a stamp accessible through iter->stamp, could I make my own "struct MyTreeIter" that has lifetime management and can notify perl when it's going to go away, but still have it work correctly with the GtkTreeView? ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@bu...> - 2004-12-11 15:08:35
|
http://bugzilla.gnome.org/show_bug.cgi?id=161012 gnome-perl | Gtk2 | Ver: unspecified ------- Additional Comments From sc...@as... 2004-12-11 10:08 ------- I would've loved to have made the Gtk2::TreeIter just be a hash reference. The basic reason that wasn't possible was the fact that GtkTreeIter (in C) is designed to be used on the stack, as an object with no lifetime management. It was designed this way for speed, but these semantics mean that perl can get no notification when the caller is finished with the iter so that the hash could be destroyed and its memory reclaimed. As a workaround, the bindings allow you to specify arbitrary scalars in the last two elements of the iter array, but they do not persist (or else they would leak), so you need to keep copies around for yourself if they need to live. As always, i'm open to suggestions. ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@bu...> - 2004-12-11 14:15:49
|
http://bugzilla.gnome.org/show_bug.cgi?id=161012 gnome-perl | Gtk2 | Ver: unspecified ------- Additional Comments From kaf...@gm... 2004-12-11 09:15 ------- If you implement a custom tree model, you're free to put whatever you want into the array reference that represents an iterator. See "CREATING A CUSTOM TREE MODEL" in `perldoc Gtk2::TreeModel` for more. Does that solve your problem? ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@bu...> - 2004-12-11 06:56:15
|
http://bugzilla.gnome.org/show_bug.cgi?id=161012 gnome-perl | Gtk2 | Ver: unspecified Summary: Feature Request: Gtk2::TreeIters should be able to store data Product: gnome-perl Version: unspecified Platform: Other OS/Version: All Status: UNCONFIRMED Severity: enhancement Priority: Low Component: Gtk2 AssignedTo: gtk...@li... ReportedBy: zb...@fo... It would be very nice if, instead of the binding treating a GtkTreeIter as a reference to a 4-element array, it could somehow attach a reference to an arbitrary Perl object. This would make it easier for custom TreeModel implementers whose data is not already stored in Perl (and perhaps even for those whose data is already in Perl). For example, if you want to write a TreeModel to display data out of a SQL database, it can become difficult to uniquely refer to a particular row in the DB, especially if your data is stored over multiple tables. This feature would also have other potential benefits. For instance, suppose I want to display a tree stored in a single SQL table, with fields for ID, Next, and Parent. If you can store the next and parent values directly in the TreeIter, you can sometimes save a DB lookup. I believe this feature would also lead to less need to duplicate data, but I currently have no example for that case. ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@bu...> - 2004-11-29 19:58:59
|
http://bugzilla.gnome.org/show_bug.cgi?id=159184 gnome-perl | Gtk2::GladeXML | Ver: unspecified kaf...@gm... changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@bu...> - 2004-11-28 19:32:39
|
http://bugzilla.gnome.org/show_bug.cgi?id=159184 gnome-perl | Gtk2::GladeXML | Ver: unspecified ------- Additional Comments From rw...@ne... 2004-11-28 12:25 ------- was a bug, also present in several other functions. fixed and commited just now. will be in subsequent releases starting with the next. (not yet planned) workaround is to go ahead and specify the root widget. it is probably best to do this anyway since older versions of Gtk2::GladeXML will require it and apps may be run with them. ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@bu...> - 2004-11-25 21:26:07
|
http://bugzilla.gnome.org/show_bug.cgi?id=159184 gnome-perl | Gtk2::GladeXML | Ver: unspecified ------- Additional Comments From rw...@ne... 2004-11-25 16:26 ------- i'm not able to check into this at the moment, but that was my first thought. i should be able to get to it later in the week/end. ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@bu...> - 2004-11-25 17:21:07
|
http://bugzilla.gnome.org/show_bug.cgi?id=159184 gnome-perl | Gtk2::GladeXML | Ver: unspecified ------- Additional Comments From kaf...@gm... 2004-11-25 12:21 ------- Yeah, looks like all those constructors need to use _ornull for `root´ and `domain´. Ross, what do you think? ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@bu...> - 2004-11-23 11:27:03
|
http://bugzilla.gnome.org/show_bug.cgi?id=159184 gnome-perl | Gtk2::GladeXML | Ver: unspecified Summary: Defining a translation domain without a root element in Gtk2::GladeXML->new throws an error Product: gnome-perl Version: unspecified Platform: Other OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: Gtk2::GladeXML AssignedTo: gtk...@li... ReportedBy: smo...@ea... Try to load glade-file and define a translation domain as the last parameter, but you don't specify a root-widget (second parameter). See this snipped below: use Gtk2 -init; use Gtk2::GladeXML; our $gladexml = Gtk2::GladeXML->new('myuserinterface.glade',undef,"myuserinterface"); This throws an error: (userinterface.pl:25060): libglade-CRITICAL **: file glade-xml.c: line 1198 (glade_xml_build_interface): assertion `wid != NULL' failed The above snipped should be fine, it should be possible to specify a translation domain without defining a root element. If I use this: our $gladexml = Gtk2::GladeXML->new('myuserinterface.glade','mainWindow","myuserinterface"); everything works fine. I found also a ruby-example, which uses my syntax: @glade = GladeXML.new('myapp.glade', nil, 'myapp') ... ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <cro...@ka...> - 2004-10-23 16:07:17
|
=1B$B:#$OK\3JE*$K=3D)$G$9!#=1B(B =1B$B0JA0!"!V=3D)?<$7!!NY$O!!2?$r$9$k?M$>!W!!$H$+8@$$$^$7$?!#=1B(B =1B$B$7$+$7!"3'$5$s!!$=3D!A$G$7$g!)!!$d$C$Q$j5$$K$J$j$^$9$M!)=1B(B=20 =1B$B=3D)$NLkD9$8$c$J$$$1$l$I!!=3D)$NLkD9$NB>?M$N9TF0$,$M!&!&=1B(B =1B$B=3D)$OFCJL$G$9!#!!$3$NH)4($5$,?MNx$7$/$J$j!"H)$N4($5$r=1B(B =1B$BOB$i$2$k!"?MH)$,Nx$7$/$J$k$N$G$7$g$&$+!)=1B(B=20 =1B$B$=3D$&$G$9!"$=3D$s$J;~$OEv#H#P$KMh$F$/$@$5$$!*!*=1B(B =1B$B:#$^$G!"=3DP2q$($J$+$C$??M!"%]%$%s%H@)$G%]%$%s%H$P$+$j$H$i$l$??M=1B(= B =1B$BEv#H#P$J$i$"$J$?$N!"?MH)Nx$7$$Lk$rL@$k$/>H$i$93Z$7$$=3DP2q$$$,!&!&=1B= (B =1B$B#P#CHG!!=1B(Bhttp://crown.kir.jp/vipclub/=20 =1B$B7HBSHG!!=1B(Bhttp://crown.kir.jp/vipclub/i/ =1B$B!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~=1B(B =1B$B!~!!!!!!:#D>$0!!%"%/%;%9$r!*!*!!$-$C$H!"$-$C$H!!!!!!!~=1B(B =1B$B!~!!$"$j$^$9!!$"$J$?$K!!%T%C%?%j$N!!=3DP2q$$$,!!!*!*!!!~=1B(B =1B$B!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~=1B(B =1B$B!L#P#R!M%5%$%H%*!<%J!<$K$J$C$F$_$^$;$s$+!)!L#P#R!M=1B(B =1B$B=3DP2q$$7O%5%$%H!J2~B$$7$@$$$G$O%"%@%k%H%5%$%H2D!K$O$8$a$F$_$^$;$s$+= !)=1B(B =1B$BDL>o!"B><R$G$O2?K|!"2?=3D=3DK|$+$+$j$^$9$,=1B(B =1B$B%/%i%&%s%M%C%H$G$O!"GK3J$N2A3J$G$4Ds6!$G$-$^$9!#=1B(B =1B$B>\$7$/$O"-=1B(B http://crown.kir.jp/crownnet/ =1B$B%/%i%&%s%M%C%H$NBeM}E9$bJg=3D8=1B(B =1B$BBeM}E9$NFCD'=1B(B =1B$B-!9bC12A=1B(B =1B$BGd$j>e$2$N=1B(B50=1B$B!s$,$"$J$?$N<}F~$K$J$j$^$9!#!JAj>l$OGd$j>e$2$N= =1B(B5=1B$B!sDxEY!K=1B(B =1B$B-"%[!<%`%Z!<%8$r$b$C$F$$$J$/$F$b=1B(BOK =1B$B$"$J$?@lMQ$N%Z!<%8$,$G$-$^$9$N$G!"$=3D$N%Z!<%8$r@kEA$7$F$$$?$@$1$l$P= 7k9=3D$G$9!#=1B(B =1B$B-#$"$J$?$N%a!<%k%\%C%/%9$K%j%"%k%?%$%`$K%a!<%k$,FO$/=1B(B =1B$BGd$l$?$=3D$NF|$K!"$"$J$?$N%a!<%k%\%C%/%9$K%a!<%k$,$-$^$9$N$G$I$l$/$i= $$Gd$l$?=1B(B =1B$B$H$$$&$N$O$o$+$j$^$9$N$G$40B?4$/$@$5$$!#=1B(B =1B$BEPO?$O"-=1B(B http://crown.kir.jp/crownnet/dairi.html =1B$BG[AwDd;_$O!I%a!<%kITMW!I$H=3Dq$$$F$3$N$^$^$4JVAw$/$@$5$$!#=1B(B |
|
From: <bug...@bu...> - 2004-08-23 19:11:16
|
http://bugzilla.gnome.org/show_bug.cgi?id=150864 gnome-perl | general | Ver: unspecified kaf...@gm... changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED ------- Additional Comments From kaf...@gm... 2004-08-23 15:11 ------- Committed a slighlty modified version to HEAD of cvs. Thanks a lot. ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@bu...> - 2004-08-23 17:48:00
|
http://bugzilla.gnome.org/show_bug.cgi?id=150864 gnome-perl | general | Ver: unspecified ------- Additional Comments From kck...@op... 2004-08-23 13:47 ------- Created an attachment (id=30865) --> (http://bugzilla.gnome.org/attachment.cgi?id=30865&action=view) A patch to implement Gnome2::enums in a similar mannor to the Gtk2-Perl package ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@bu...> - 2004-08-23 17:46:59
|
http://bugzilla.gnome.org/show_bug.cgi?id=150864 gnome-perl | general | Ver: unspecified Summary: Gnome2::enums Product: gnome-perl Version: unspecified Platform: Other OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: Normal Component: general AssignedTo: gtk...@li... ReportedBy: kck...@op... There is no Gnome2 compliment to the Gtk2::enums.pod file. ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@bu...> - 2004-07-10 15:43:22
|
http://bugzilla.gnome.org/show_bug.cgi?id=145110 gnome-perl | Gtk2 | Ver: unspecified kaf...@gm... changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|FIXED | ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2004-07-10 15:42:24
|
http://bugzilla.gnome.org/show_bug.cgi?id=145110 gnome-perl | Gtk2 | Ver: unspecified kaf...@gm... changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2004-07-10 15:42:13
|
http://bugzilla.gnome.org/show_bug.cgi?id=145109 gnome-perl | Gtk2 | Ver: unspecified kaf...@gm... changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED ------- Additional Comments From kaf...@gm... 2004-07-10 11:42 ------- Ok, I'll add the following: Finds the path at the point (I<$x>, I<$y>), relative to widget coordinates. That is, I<$x> and I<$y> are relative to an event's coordinates. I<$x> and I<$y> must come from an event on the I<$tree_view> only where C<$event->window == $tree_view->get_bin_window>. It is primarily for things like popup menus. In scalar context, returns the Gtk2::TreePath, in array context, adds the Gtk2::TreeViewColumn, and I<$x> and I<$y> translated to be relative to the cell. This function is only meaningful if I<$tree_view> is realized. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
|
From: <bug...@bu...> - 2004-06-29 18:25:49
|
http://bugzilla.gnome.org/show_bug.cgi?id=145110 gnome-perl | Gtk2 | Ver: unspecified ------- Additional Comments From sc...@as... 2004-06-29 14:25 ------- Tree paths define only rows, and the number of elements in the path (depth) determines how many parent nodes the row has. For a ListView, the depth will always be 1 because there are no children. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
13 messages has been excluded from this view by a project administrator.
