CVS improvements

Okay, I'm finally making good on my promise... whenever anybody checks
into the 'widgets' repository, it will rebuild demo.xwar, mail.xwar,
and chess.xwar automatically.

Also, there's a new mailing list (cvs) that gets a diff mailed to it
every time anybody checks anything into any of the repositories.

  - a

Re: Segfault

Yes, right now there's some problem with GCJ-compiled programs running
on Debian unstable's glibc.  We're trying to figure out if it's gcj's
fault or the unstable glibc's fault.

For now, you'll have to use a more stable glibc in order to use XWT.

  - a

"Spy Hunter" <Spy_Hunter <at> myrealbox.com> writes:
> The latest linux native client (xwt-0268.linux) segfaults immediately on startup on my Debian sid box. 
The shoehorn applet gives no indication that this has happened, so visiting launch.xwt.org just fails to
open XWT after it says "XWT Loaded".  Any ideas what could be causing this?  Some weird binary compatibility
issue with GCJ perhaps?
> for(int r=-1,c=0;r!=38;c++){if(c>r){r++;printf("\n"); for(c=38;c!=r;c--)printf("
");c=0;}printf(~r&c?" `":" #");}
> 
> _______________________________________________
> http://lists.xwt.org/listinfo/dev
> 

--

-- 

Re: XWT vs DOM

Andrew Kohlsmith <akohlsmith-xwt <at> benshaw.com> writes:
> Whoa, down boy...

Sorry, guess I got a bit defensive there... =)

> Interesting..  I wonder if a (toned down, perhaps with a couple of examples?) 
> version of this might be a good idea for a FAQ entry... 

Probably.

  - a

Re: XWT vs DOM

Tim Fries <timf <at> dicecorp.com> writes:
> With IE I could recompletely clone the XWT Sampler application

Actually, Tim, if you're right, then we could write an XWT-to-DHTML
translator... now *that* would be interesting...

  - a

Bricolage + XWT

Hmm...

test

--

-- 

Re: Hmm...

You probably set root.width="100" somewhere...

  - a

Charles Goodwin <charles.goodwin <at> credit1.co.uk> writes:
> Any idea why I can't resize this:
> 
> http://launch.xwt.org/stable/www.credit1.co.uk/table2.xwar
> 
> There's no errors in the log file.

--

-- 

(no subject)

test

Re: prohibited traps

Jayson Vantuyl <kagato <at> chaosium.net> writes:
> On Tue, Oct 22, 2002 at 12:02:49PM -0700, Adam Megacz wrote:
> > Yep.  The main reason is that we don't want people doing stuff like this:

> >    __invisible = function(i) { return false; }

> I've always wondered why you just didn't honor read traps (but write
> traps were okay)?

The same reason that Object.wait() and Object.notify() are declared
"final" in Java.  Those are well-known, public methods that every
object must export.  Changing the behavior of those methods would make
the Object no longer "really an Object".

I think of properties as split into two categories: external
properties (properties that your parent boxen will manipulate, like
invisible, align, width, etc) and internal properties (properties that
only you should manipulate, like orient, color, image, and border).

I'd like the external properties to work the same way on every bos.

> Also, can anyone explain to me what it means when I return from a write
> trap?  In other words, does this do something?

The return value is ignored -- it serves no useful purpose.

> How do I determine the order in which traps cascade?

In general you should really try not to depend on the trap invocation
order, but the _last_ trap to be added gets executed _first_.  So
traps cascade in the reverse order in which they were added.  Sorta
like Java methods that cascade with super.foo().

  - a

--

-- 
"Through your rags I see your vanity"  -- Socrates

_______________________________________________
http://lists.xwt.org/listinfo/dev