[gtkada] Patch for String_List in Gtk.enums - Going in

[Jeff Creem]

I've taken a look at this again. The patch I submitted really contained two
things that upon reading
your concerns I believe should be treated differently.

It contained:

1) A Free_String_List_Element for allowing the data in a single element of a
string list to be freed.
  (Along the same lines as the existing Free_String_List routine which was
present but which is not
   really part of glib I might add).

and

2) A handy dandy find routine that must be used to do a find since I believe
the instance of glist for
strings falls into the case indicated by the glib-list.ads that find does
not work for some types.

   (comment snippet from existing glib-glist.ads code follows)

      --  Find a value in the list, and return the first item that contains
it.
      --  Note that this function will not work if the function Convert does
      --  not return the same value for two identical values.


Item 1 is critical any time you want to manage your own string lists (which
may need to be
done for instance to pass data into a Gtk-combo to set the pop-down
strings).

Without adding some way of freeing individual elements you must resort to
freeing the entire
list and rebuilding each time (using the existing procedure)

  procedure Free_String_List (List : in out String_List.Glist);
   --  Free the memory occupied by all the strings in the list, as well
   --  as the memory occupied by the list itself.

The glib-glist routines
remove and
remove_link
each only deal with the storage associate with the list node
data structures not the data in the list. (Remove removes the node from the
list
and frees the node memory. remove_link just removes the node from the list.
Neither routine
attempts to free the "data" field of the node)


My item 1 really can not be cleanly implemented from outside the gtk-enums
package since only
the body of this package knows that the returned address (from Convert) is
the address of a Interfaces.C.Strings.chars_ptr. This could be done outside
the package with some unchecked
conversions but it would be subject to breaking with changes inside of
gtk-enums and not
really an appropriate use of unchecked_conversion (since it would be an
unchecked_conversion
from a non-published representation)

Item 1 really feels like a case of encapsulation without representation (in
other words we have
hidden the implementation details but not provided a basic required
manipulation function - the
ability to free an element)

Item 2 is a different story. This clearly can be cleanly implemented outside
of the package
and could be added to a contrib type file (probably a few other routines for
this list would
then be nice to add too)

So, given  your previously stated goals about not extending glib capability
in gtkada proper,
I feel like he right approach is to add the free routine to gtk-enums but
not the find routine.

If this seems appropriate to the real developers I can put together a new
patch that does this and
perhaps even through together a useful separate contrib package that would
essentially mirror
the glist routines that indicate they do not work when "the function Convert
does not return the same value for two identical values".





----- Original Message -----
From: "Jeff Creem" <jeff at thecreems.com>
To: <gtkada at lists.act-europe.fr>
Sent: Friday, September 07, 2001 6:47 AM
Subject: Re: [gtkada] Patch for String_List in Gtk.enums - Going in


> Ok.. Thanks for the update. I'm headed for work right now so I can't go
into
> too many details but basically the issue is that this has to be in the
> gtk.enums package
> (or we could move some stuff from the body to the private part of the spec
> and
> extend that way).
>
> The problem is that the pre-instantiated list for string is used as
> parameters to other
> widgets (combo pops to mind). Due to the way this list is put together
right
> now one
> would have to re-create and then destroy a new list any time a single
> element wanted
> to be removed from the list (or face a memory leak).
>  I'll look to see if the delete link would help and if not try to write up
> something a little
> more clear about what I am asking for. I don't think it really is trying
to
> extend the glist
> as much as it is trying to make up for a lack of functionality in a
> particular instance of it
> that perhaps hides too many details (it either hides too much or is
missing
> this function....I think)
>
>
> ----- Original Message -----
> From: "Emmanuel Briot" <briot at ACT-Europe.FR>
> To: <gtkada at lists.act-europe.fr>
> Sent: Friday, September 07, 2001 5:33 AM
> Subject: Re: [gtkada] Patch for String_List in Gtk.enums - Going in
>
>
> > Jeff Creem writes:
> >  > On Mon, 20 Aug 2001 22:00:35 -0400 I sent a message with a patch for
> some
> >  > additional
> >  > features for the instance of glist for string types. No comments
gripes
> or
> >  > complaints
> >  > were posted in response.
> >  >
> >  > Any chance this is going to go in to the CVS tree or is it a bad
idea?
> >
> >
> > Jeff,
> >
> > I thought your mail had been answered already.
> > Anyway: we are not really interested in putting new Ada functions in
glib
> > itself. GtkAda is mostly a binding after all, and we have tried to use
> these
> > low-level lists only for the binding part (C functions returning such a
> list
> > for instance). All the new widgets that were written directly in Ada use
> their
> > own lists.
> >
> > It might be interesting to put your functions in a separate package, and
> maybe
> > this could go into the contrib/ directory of the GtkAda distribution.
I'll
> > discuss this with the other GtkAda developpers.
> >
> > However, one other thing that might be interesting to investigate: it
> seems
> > that the binding to glist.h is incomplete. In particular, a quick look
at
> it
> > shows that the C version has the following functions:
> >
> >  GList*   g_list_delete_link    (GList            *list,
> >                                  GList            *link);
> >
> > which might (or not :-) do what you want.
> >
> > I think it would be more interesting (and easier to maintain) to enhance
> the
> > binding itself rather than writing some Ada functions for that.
> >
> >
> > regards,
> > Emmanuel
> >
> > _______________________________________________
> > gtkada mailing list
> > gtkada at lists.act-europe.fr
> > http://lists.act-europe.fr/mailman/listinfo/gtkada
> >
>
>
> _______________________________________________
> gtkada mailing list
> gtkada at lists.act-europe.fr
> http://lists.act-europe.fr/mailman/listinfo/gtkada
>