> At 09:14 PM 5/31/01 +0200, Issac Goldstand wrote:
> > > At 12:31 PM 5/29/01 -0400, Stephen Adkins wrote:
> > > >At 09:53 PM 5/29/2001 +0800, Gunther Birznieks wrote:
> > > > >At 05:17 PM 5/28/01 -0400, Stephen Adkins wrote:
> > > >...
> >[...]
> >
> >Complex Widget:
> >
> ><Widget type="textbox" maxsize="50" length="25" X-Offset="40"
Y-Offset="20"
> >TabStop="True" TabIndex="3" name="text1" value="some sample text"
> >tooltip="Enter some text here"/>
> >
> >Now, let's say that the developer prints this with the HTML "Driver" -
this
> >could do something like:
> ><INPUT TYPE="TEXT" MAXLENGTH="50" SIZE="25" NAME="text1" VALUE="some
sample
> >text" onMouseOver="Window.status='Enter some text here'"
> >onMouseOut="Window.status=''"/>
> >
> >And in some other GTK-based environment, it could do something like:
> >
> >Label text1;
> >with (text1)
> >{
> > .Length=50;
> > .Width=25*XCharSize; // The *XCharSize would have to be defined by
the
> >driver or by the native interface
> > .Height=1*YCharSize; // This would be a default setting "plugged in"
by
> >the driver
> > .Value="some sample text";
> > .Left=40;
> > .Top=20;
> > .TabStop=1;
> > .TabIndex=2; // 3-1 for 0 based - also defined by the driver...
> >}
> >
> >Now, neither of these cases used _all_ of the widget parameters - a
simple
> >HTML designer could have produced an IDENTICAL widget by doing:
> >
> ><Widget type="textbox" maxsize="50" length="25" name="text1" value="some
> >sample text" tooltip="Enter some text here"/>
> >
> >This shows a few things, actaully. First of all, the widget can get as
many
> >or few parameters as the developer wants to supply it with - extra
> >parameters will be discarded by drivers who do not understand them, and
> >missing parameters will be supplied with "default" values wherever
possible.
> >Now, I would suggest designing this such that the developer only
interacts
> >with a Widget::textbox. Internally, there would have to be a
> >Widget::HTML::textbox and a Widget::GTK::textbox, each with the
UI-specific
> >rendering instructions...
> >
> >The only problem is making sure that the overhead is kept to a minimal -
in
> >that as few feautres that are not actually NEEDED for the specific
> >implementation are loaded as possible (eg, a user using only certain
> >elements in HTML will only load those elements, and only HTML, while if
he
> >wants WML, it will also incur WML generic overhead too). I think this
> >approach should satisfy both the wants to keep the widgets as generic as
> >possible, as well as Gunther's wanting to keep the widgets as simple and
> >easy-to-use/understand as possible (for beginners, at least).
>
> While adding parameters to the constructor is not a problem, I guess I
have
> a problem with adding behaviors. If you believe that simply adding more
> config hooks to allow XWindows to be supported is doable, then we should
> just leave it as mentioning this as a supposition and leave it to you or
> someone else to prove that the supposition works after v1.x of the widget
> set is released.
>
For arguments sake, I suppose it can be left as a supposition (OK, so I'm
too swamped just now to do a proof-of-concept [especially one that would
require me to learn GTK programming - something I've not yet touched]).
I still think that if a proper abstraction layer is implemented, then
parameters can either be "guessed" or silently discarded, thus enabling the
widgets to be rendered in anything - even XWindows (or Win32 using Vis
Basic, or a dialog resource file). Note that in these cases, only very
generic code can be generated, but it's still possible.
