- From: Mark Martin <markm flash net>
- To: "gtk-devel-list redhat com" <gtk-devel-list redhat com>
- Subject: intro
- Date: Tue, 25 Aug 1998 09:25:15 +0000
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
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
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
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
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..."
] [Thread Prev