[Perl-widget-developer] Re: Real Widgets and Template Languages

[Gunther B. <gu...@ex...>]

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.