Eiffel Wrapper Libraries Collection

Status

GTK+ is fairly complete and usable.
Glib and Gobject are partially wrapped.
The rest of wrappers are either in developmente in the SVN repository or they are still not wrapped.

Todo:

• Add to each class indexing clauses that says the wrapped version and the completeness of the wrapper.
• Eiffelize the examples found in GTK+ documentation
• Add precondition to external classes. The most obvious are not null pointers precondition; for example:
     gtk_entry_set_text (an_entry, a_text: POINTER) is
        require valid_entry: an_entry.is_not_null
  
• Wrap many missing GTK+ properties.
• In any effective class heir of G_OBJECT (i.e. GTK_FOO) there should be an invariant is_gtk_foo to be sure that handle actually points to a real GtkFoo C structure. is_gtk_foo should be a wrapper of the macro usually provided for such a task.
• Implement a common way to handle GError. Currently wrapper classes  ignores it (i.e. GDK_PIXBUF)
• Implement strongly typed version of G_OBJECT property setters and
    getters. Ideally those Eiffels version should not rely on
    g_object_set and g_object_get C functions that hide the GValue
    handling and do many tests and checks that are automatically
    enforced by static typing or that are handled by Eiffel
    preconditions.
• G_VALUE should be expanded. Currently all the classes in EWLC are not expanded - even when they should be - because SmartEiffel does not handle disposing of expanded classes
• Turn G_PARAM_SPEC into a deferred class and provide strongly-typed heirs, such as G_PARAM_SPEC_BOOLEAN.
• Many GTK classes has many properties with the same name and the same type. As far as I know an efficient, smart and correct Eiffel implementation of those should be to create deferred XXX_PROPERTY classes with xxx and set_xxx features. Ideally those classes could also use some cached G_PARAM_SPECs objects that could be stored into GTK singleton as hidden features.
  
• Many object properties has direct getter setter. Wrapping this provide a faster way to access those properties. It should be clearly stated.
• Benchmark the performance of CONST_STRING. While wrapping C libraries I keep encountering constant C strings in function calls like:
  
  const char *get_foo (GObject an_object);
  
  One way to wrap it is to write:
   foo: STRING is
   do
      create Result.from_external_copy (external_get_foo (a_pointer))
   end
  While this is correct it could be not the most efficient approach since it create a new object every time foo is accessed and this could induce unnecessary memory allocation. Usually such strings are almost always used read-only. CONST_STRING has been created to address this need. Its pattern usage is:
   foo: STRING is
   do
      create {CONST_STRING} Result.from_external_copy (external_get_foo (a_pointer))
   end