[xwt-discuss] A few ideas

[xwt-discuss] Correction

Re: [xwt-discuss] A few ideas

Charles Goodwin <charles.goodwin <at> credit1.co.uk> writes:
> spacing - the amount of pixel space between relatively placed boxes

Just put empty boxes between them.

> *text_halign, text_valign - vertical / horizontal alignment of a box's text
> (left right center, top bottom center)

Just set shrink="true" on the box, wrap another box around the outside
of it, and set the align property on the inner box.

> The way the border is worked out doesn't *quite* make sense.  The border
> should have to be an odd number of pixels wide / high and should take
> (w-1)/2, (h-1)/2 pixels for each corner and the single (the -1) pixel
> 'cross' in the middle to be stretched as the edges.

That's how it works.

> wide and H pixels tall, then the W/2 x H/2 pixels in each corner of the PNG

In C and Java, 5/2 == 2. I should probably clarify this.

> *Is there already a way to layout the text within the box?

No; all layout is done at the box level.

> If so, I can't locate it in the reference.  Instead, for the moment,
> I'm using 2 boxes where 1 would suffice for an image / text to
> represent an icon.

Nothing wrong with that. Boxes are cheap. Basically, there is a design
tradeoff between:

  1) A complex API (lots of special properties) which requires very
     few boxes to accomplish any given task

  2) A simple API which requires more boxes to accomplish the same task

I chose (2) when designing XWT. IMHO, CSS/HTML chose (1). As a result,
I spent a *lot* of time optimizing the engine for UIs with upwards of
1,000 boxes. I think the Mail demo is well into that range.

Contrast that with 1,000 nested tables in Internet Explorer -- it'll
crash in an instant.

I think vertical text will show up when I implement SVG support.

  - a

--

-- 
Sick of HTML user interfaces?
www.xwt.org

Re: [xwt-discuss] Re: one comment

At 2002/06/28 13:28 -0700, Adam Megacz wrote:
>I don't know if this is inherently good or bad... I can't see why
>you'd need to create *additional* properties on a box after it has
>been instantiated. I only do this in one place in all of my code -- in
>the mail demo, each mail message is a box, and each header (From:
>Adam) gets set as a property (box.From = "Adam") so that the box which
>visually represents the message can trap on that property (box._From =
>function() { ... set from field in visual representation ... }). But I
>guess I could just create a "setHeader()" method instead.
>
>Thoughts? I need some input on this one.

Generally I'm a big fan of programming environments that force developers 
to declare everything they use, preferably in a nice hierarchy. I don't see 
XWT as a scriptkiddie development environment, so I'd have no problem with 
forcing declarations of everything. However, this more or less flies in the 
face of ECMA script and it might be a bit of a shock to people who are used 
to dynamic attribute creation. My suggestions:

1) Have a compiler pragma that forces declarations (ideally, default it 
enabled but that might be going too far).
2) Provide a method for runtime attribute creation so that your example 
would fail, but this would succeed:

     var foo = { };
     foo.DeclareNewAttribute("bar");
     foo.bar = 5;

That way when I type "foo.bat" later on, I at least get a runtime error.

Re: [xwt-discuss] Re: one comment

Lennon Day-Reynolds <lennon <at> day-reynolds.com> writes:
> Strong typing is a big win in certain domains, where the safety and
> reliability of the finished code are more important than maximum
> productivity or flexibility for the developer. ... In the case of a
> lightweight, thin client UI toolkit, though, the advantages of
> strict typing are less clear, and the disadvantages even more
> noticeable.

Well said.

Let there be no doubt, XWT will remain dynamically typed/bound rather
than strongly typed/bound; the advantages are clear.

However, I am tempted to introduce a small hack in the case of boxes
-- strictly because they are the "root scope" of your script (the
scope within which undeclared variables get created), so all the typos
tend to filter down to them. The hack I'm tempted to introduce is a
simple one: you must "declare" a property on a box before you can use
it. If you don't, an exception is thrown.

The key questions, along with the answers I'm leaning towards are:

   1) How do you "declare" a property on a box?

      Right now I'm thinking that you have to include an attribute on
      the box to initialize the property. If there is no attribute
      foo="..." on a box, then you cannot later say "box.foo =
      5". Unfortunately I've already hijacked JavaScript's 'var'
      keyword for the public/private distinction.

      Obviously the standard box properties (x/y/width/height/etc) are
      automatically defined.

   2) Should this behavior be on-by-default, off-by-default, or
      always-on?

      I'm thinking that for the next few revisions it should be
      off-by-default and print a warning to the log letting you know
      that this behavior will not be supported in the future. A few
      generations later I'll make it always-on.

   3) Is this really useful?

      I don't know. =) Going all-static/strong is certainly
      overboard. Perhaps even this hack is too much. I'm not sure. I
      do know that debugging is a lot harder in XWT than in Java, so
      I'm trying to come up with ways to shrink that gap.

> Sorry about the rant; after working in a shop that was evenly divided 
> between Lisp and a very strongly-typed ML-like language, I've been over 
> this territory before, and just can't let blanket arguments about typing 
> and language design go unanswered.

Being surrounded by formal methods people can do that to ya =)

  - a

--

-- 
Sick of HTML user interfaces?
www.xwt.org

RE: [xwt-discuss] Re: one comment

Yahoo!

I'm glad to hear that. I think there was and still is confusion
about what I was proposing. Forcing box properties to be declared
is it.

As for how to do it ...

I will repeat my initial recommendation for the benefit of all.
Add a new child tag that belongs to box. Like this.

	<box id="foo" x="10" y="20">
	   <attribute name="bar"
			  value="10"
			  protection="private"
			  type="Array"
			  description="This is my bar"/>
	</box>

"attribute" is perhaps not the right name because it is hard to
then talk about the attributes of attribute.
"boxAttribute" seems like a helluva lot of typing, but is better.

The attributes of "attribute" or "boxAttribute" or whatever we
call it, should be a mix of required ones and optional ones.
The "name" attribute should be required. "value" could be an
optional initialization value defaulted to null or empty string
or whatever appropriate. Protection would be optional, default
set to private. Type would be optional with default of whatever
the JavaScript default type is called. And description would
be optional but would be picked up by the auto-documenation tool.

So generally, a few attributes could be defined quickly, a la.

	<box id="foo" x="10" y="20">
		<attribute name="bar" value="20/>
		<attribute name="baz" value="hello"/>
		<attribute name="message" value="Hello World"/>
	</box>

The alternative is much shorter, but doesn't offer as many options.

	<box id="foo" x="10" y="20" bar="20" baz="hello" message="Hello World"/>

Should it be optional?

What Adam proposes seems like a reasonable transition.

Is it useful.

Oh my goodness yes. Perhaps I'm the only sloppy typist, but I
make simple spelling mistakes all the time. My code validator
and I have a healthy mutal respect. :)

GENE

> Lennon Day-Reynolds <lennon <at> day-reynolds.com> writes:
> > Strong typing is a big win in certain domains, where the safety and
> > reliability of the finished code are more important than maximum
> > productivity or flexibility for the developer. ... In the case of a
> > lightweight, thin client UI toolkit, though, the advantages of
> > strict typing are less clear, and the disadvantages even more
> > noticeable.
>
> Well said.
>
> Let there be no doubt, XWT will remain dynamically typed/bound rather
> than strongly typed/bound; the advantages are clear.
>
> However, I am tempted to introduce a small hack in the case of boxes
> -- strictly because they are the "root scope" of your script (the
> scope within which undeclared variables get created), so all the typos
> tend to filter down to them. The hack I'm tempted to introduce is a
> simple one: you must "declare" a property on a box before you can use
> it. If you don't, an exception is thrown.
>
> The key questions, along with the answers I'm leaning towards are:
>
>    1) How do you "declare" a property on a box?
>
>       Right now I'm thinking that you have to include an attribute on
>       the box to initialize the property. If there is no attribute
>       foo="..." on a box, then you cannot later say "box.foo =
>       5". Unfortunately I've already hijacked JavaScript's 'var'
>       keyword for the public/private distinction.
>       Obviously the standard box properties (x/y/width/height/etc) are
>       automatically defined.
>
>    2) Should this behavior be on-by-default, off-by-default, or
>       always-on?
>
>       I'm thinking that for the next few revisions it should be
>       off-by-default and print a warning to the log letting you know
>       that this behavior will not be supported in the future. A few
>       generations later I'll make it always-on.
>
>    3) Is this really useful?
>
>       I don't know. =) Going all-static/strong is certainly
>       overboard. Perhaps even this hack is too much. I'm not sure. I
>       do know that debugging is a lot harder in XWT than in Java, so
>       I'm trying to come up with ways to shrink that gap.
>
>
> > Sorry about the rant; after working in a shop that was evenly divided
> > between Lisp and a very strongly-typed ML-like language, I've been over
> > this territory before, and just can't let blanket arguments
> about typing
> > and language design go unanswered.
>
> Being surrounded by formal methods people can do that to ya =)
>
>   - a
>
> --
> Sick of HTML user interfaces?
> www.xwt.org
>
> _______________________________________________
> http://lists.xwt.org/listinfo/discuss

Re: [xwt-discuss] Re: one comment

On Tue, 2 Jul 2002 10:14, Gene McKenna wrote:
> I will repeat my initial recommendation for the benefit of all.
> Add a new child tag that belongs to box. Like this.
>
> 	<box id="foo" x="10" y="20">
> 	   <attribute name="bar"
> 			  value="10"
> 			  protection="private"
> 			  type="Array"
> 			  description="This is my bar"/>
> 	</box>

Hmm, at first it does seem like a lot of typing, but there are some 
advantages. One I see is documentation. At the moment, there doesn't seem any 
way to properly document attributes to a point where an xwt version of 
javadoc could pick them up and build documentation. Perhaps instead of a 
description parameter something like:

<attribute name="bar" value="10" access="private" type="Array">
    This is my bar. It's used for...
</attribute>

Perhaps both solutions could be used. An attribute could be defined this way, 
or you could use the short method of having it in the box tag.

<box bar="foo"/>

Either way, I like the idea of having box attributes defined.

d

RE: [xwt-discuss] A few ideas

Re: [xwt-discuss] Re: one comment

> However, I am tempted to introduce a small hack in the case of boxes
> -- strictly because they are the "root scope" of your script (the
> scope within which undeclared variables get created), so all the typos
> tend to filter down to them. The hack I'm tempted to introduce is a
> simple one: you must "declare" a property on a box before you can use
> it. If you don't, an exception is thrown.

Why only boxes?  Why not all objects?  Simply state that you cannot use an 
attribute for an object that hasn't been previously declared.  That's Perl's 
strict mode and a very good thing, IMO.

(confession: all my perl scripts start with #!/usr/bin/perl -wT and use 
strict;)

>       Right now I'm thinking that you have to include an attribute on
>       the box to initialize the property. If there is no attribute
>       foo="..." on a box, then you cannot later say "box.foo =
>       5". Unfortunately I've already hijacked JavaScript's 'var'
>       keyword for the public/private distinction.

>       Obviously the standard box properties (x/y/width/height/etc) are
>       automatically defined.

Good, but can you think of anything else that people would want auto-defined 
or would cause problems unless they were auto-defined?

>       I'm thinking that for the next few revisions it should be
>       off-by-default and print a warning to the log letting you know
>       that this behavior will not be supported in the future. A few
>       generations later I'll make it always-on.

I like..

>       I don't know. =) Going all-static/strong is certainly
>       overboard. Perhaps even this hack is too much. I'm not sure. I
>       do know that debugging is a lot harder in XWT than in Java, so
>       I'm trying to come up with ways to shrink that gap.

Real Programmers (I consider myself an embedded RP) would welcome this, I 
think.  It eliminates brain damage and also helps to eliminate unintended 
operation.

Regards,
Andrew

Re: [xwt-discuss] Re: one comment

> Should all boxes have predefined attributes?

I strongly agree with this.  a "use strict" is a good idea, too.  

Out of curiosity, how difficult or nasty would it be to do something like

<box width=x height=y id="mybox" type="static|dynamic">

?

Actually that kind of gives me the willies.  

Regards,
Andrew