INTRO

[Mark Martin <markm flash net>]

 Greetings,
   I would like to join in on this discussion about the entry widget.  I

sent mail to Tim to
   see if I could get touch with the right people working on this
widget, last week (pending
   a mail bucket cleanup - had a mess).

   I have been working on a project that is using GTK resently, and have

become aware of some
   possible improvements, I would like to potentially contribute
(influence mebbe) the construction
   of this widget.  I am an old curses programmer, however, on interface

design whether in graphics,
   or text, some principles are the same.  I.e. using an entry widget
for data entry, just about cannot
   go without validation.   I played with and searched for the right
place to put this in the source,
   and found it, only to pull the most recent sources and find out the
editable widget is being worked on.
   I will be glad to implement (or describe the implementation) I am
using.

   The modification I am using and would like to see implemented has to
do with similar functionality
   in curses, i.e. curses (and others) usually have a function/or set of

functions that can be run both
   before and after a character is entered.  These will need a different

signal marshaller than standard.
   This is the prototype of how the callback is used:

   gboolean my_callback(GtkWidget *widget,gchar *text,gint len,gpointer
data)

   gtk_signal_connect(GTK_OBJECT(obj),
"char_validate",GTK_SIGNAL_FUNC(my_callback),(void *)0);
   ...

   I am leaving in the gpointer data just for flexibility.

   I have appropriate marshallers written for this interface.

   I purpose the following additional signals added to editable:

   CHAR_CONVERSION  (upper to lower, etc. acsii to ebcdic - whatever)
    CHAR_VALIDATE (validates the input character)
    FIELD_VALIDATE  - this may be the 'ACTIVATE'

   The field validation function may be the same as 'ACTIVATE', however,

my focus was to expand the
    functionality of the current editable while not breaking any
currently used implementations.  I looked at
   some old gtkinput code and realized there was an attempt at this,
however, by utilizing the above, it leaves
   the implementation up to the programmer as to what the extent of the
validation is up to the programmer,
   or not at all.  All of these signals either pass or fail, and it
would be up to the programmer whether or
   not to leave the use at the current field for correct data, or move
on or not accept the character as input.
   These functions should be open ended enough to provide for
internationalization (I am not educated in
    this area).

    I noticed a discussion in the font area (this widget 'entry' needs
help).  I have studied the problem, whereas
    I don't have years of experiance with fonts, I do know (regardless
of ascent and descent). there are fixed
    and proportional fonts.   Fixed fonts should be the easiest to deal
with with all attributes, i.e. justification,
    etc.  Proportional fonts seem to be more tricky and the exact field
width can never be totally computed
    until the entire input is complete, fixed fonts can be known before
hand, which is beneficial for data entry
   and validation.  Proportional fonts may be excellent for editors,
word processors, but for data entry, they
   are more of a pain than they are worth,  my thoughts on this are as
follows:

   KISS - Keep it simple stupid, code maintenance is low and usability
and integration into screens are
   easy (read fast development).

   If the proportional fonts are deemed to be a necessity, possibilty a
hybrid, 'gtk_data_entry' could be created.

   Long intros, oops, was listening to the radio this A.M. going to
work, the person they were interviewing
   was from L.A. , he commented:
   "I don't know what colors to wear, all the gangs have used them up,
so I just get in my car naked and wear
   a pink cap and nobody pays any attention..."