[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: yap - Gtk2::FileSelector



On 18 Apr 2003, muppet wrote:

> On Thu, 2003-04-17 at 18:24, Chas Owens wrote:
> > Again, a little thievery and cleaning up.
>
> also applied, with minor changes.  (my mailer converted tabs to space
> and the patchs were rejected, so i did it by hand.)

Probably my copy and pasting was responsible for it.

>
> for the heavily aliased functions used to fetch structure members, i've
> been trying to use a descriptive name, like "member_widgets" or the like
> instead of one of the aliased names --- the actual function name is
> ignored anyway when you use an ALIAS section.  mostly aesthetic for
> developers.

Makes sense, I just stole most of the code from the original Gtk-Perl
and left those parts that didn't need to be change alone.  I will
pretty up an further changes in this manor.  Are there any other style
issues you want me to be concerned with?  I have noticed you use four
spaces for sections, but tabs for code indents and have tried to keep
that style.

>
> also, instead of using malloc and free i've been using either g_new and
> g_free or putting strings into SVs.  use the glib allocators because,
> well, we're working with glib and it's a little more consistent.  use
> SVs when you are going to croak and need to free a string -- the SVs are
> garbage collected and can survive a croak, malloc'd strings will be
> leaked by a croak (croak doesn't return, but doesn't necessarily kill
> the program either).

Thanks, I will include this in my list of things to change (like
"pointer = 0" to "pointer = NULL" and "char* var" to "const gchar*
var").

>
>
>
>
> > BTW: should it be considered a bug that $fs->complete doesn't actually
> > cause the file list to be filtered (you have to hit tab)?  The same thing
> > happens in Gtk#, so I know it isn't a Gtk-Perl-XS problem.
>
> we added a workaround for the GtkGammaCurve bug, because the Gtk team
> said they wouldn't fix it.  is there a workaround we could use for this
> one, and if so, would it be wise to do so if everybody else doesn't?  (i
> think that behavior is intentional, actually)

I have played with it a little more, it does do a complete on the filename,
but does not restrict the file list like tab does.  I think we should
leave it like it is, but report it as a bug.

<snip href="http://developer.gnome.org/doc/API/2.0/gtk/GtkFileSelection.html#gtk-file-selection-complete";>
Will attempt to match pattern to a valid filenames or subdirectories in the current directory. If a match can be made, the matched filename will appear in the text entry field of the file selection dialog. If a partial match can be made, the "Files" list will contain those file names which have been partially matched, and the "Folders" list those directories which have been partially matched.
</snip>

>
>
> --
> muppet <scott asofyet org>
>
>




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]