At 03:50 AM 6/1/01 +0200, Issac Goldstand wrote:
> > 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.
I would agree that the current widget set can be used to create a
displayable component for Xwindows instead of a string of HTML.
But it's all the event stuff and callbacks and the like that seem like
extending the widget abstraction to GUIs is dangerous when the widgets I
want only require the capability of being delivered based on a simple
request/response protocol of HTTP so that a request comes in, the
script/controller processes it and then static text or components are
delivered down the wire that is HTML or WML or whatever but it's still
request/response.
Anyway, I don't mean to force anything down specifically. But I do know
that making things complex also leads to a lack of adaptation and a lack of
time for developing components. What I would like to see happen is that a
simple API is discussed and agreed and the basic objects are created.
Then given the assumption that those objects are simple, many more people
can implement them. If I have to be concerned about a lot of stuff
everytime I make a widget like multilingual support hooks and event hooks
then I will never write a widget because I don't have time.
This is why I want widgets to be tiny and atomic. Let's make it simple. If
you want multilingual can there be some way of making the multilingual
features a wrapper around existing atomic widgets? Same for events and
other such expert features.
