headers
Andrew Plotkin | 4 Dec 17:39

UI API changes

Been slow on the devel list recently. This is not because we've slowed 
down; it's because Andy Turner and I have been working on Volity code in 
Jmac's dining room.

Here are the things I am wanting to throw in:

1:

A new "ui" namespace for translation tokens. We currently have "volity.*" 
tokens, which are sent by generic referee code, and are built into the 
client -- see wiki [[RPC_Replies]]. And we have "game.* tokens, which are 
sent by game-specific ref code and are built into the UI package.

While working on a UI, I realized that I also wanted some tokens that were 
defined in the UI package and only used *by* the UI code. (UI code can 
translate a token to a string with the localize() API, and then stick the 
string into a <text> element or whatever.) My current implementation uses 
"game.*" tokens for this purpose, but I have to be careful to avoid 
colliding with the tokens defined in the ruleset. And hey -- that is 
exactly what namespaces are for, right?

I could use the XML entity localization system for this, but that turns 
out to be a bit of a nuisance to use inside ECMAScript code. Because you 
generally want to wrap your script code in a CDATA[[]], so that you can 
use literal < and > signs. But then XML entities aren't translated. It's 
possible to work around this, but it's more lines of code.

Also, the XML entities don't do interpolation, which is handy for what I 
want. (I'm generating strings like "What do you want your \1 to attack?" 
Where the \1 is filled in with another token that translates to a card
(Continue reading)

Permalink | Reply | 8 comments |
headers
katre | 4 Dec 22:10

Re: UI API changes

Andrew Plotkin wrote:
> 2:
> 
> I've been thinking for a while about a way for the UI to mark the seat 
> whose turn it currently is -- in Javolin's seat display panel, not just 
> the UI pane. I'd like to nail down the API for this, even if I don't 
> implement it for a while. (That way I can put the API in as a no-op, and 
> write UI code that prospectively calls it, without hitting errors.)

This sounds like a useful idea, but I'm not sure the UI should control
it.  Is there any way for the referee to handle sending this message to
the client, which handles the seat display? Or am I confused and the
seat display is already handled by the UI, so there's no point in
keeping this separate?

katre

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
Permalink | Reply | 1 comment |
headers
Mike Sugarbaker | 5 Dec 03:24
Picon

Re: UI API changes

On 12/4/05, Andrew Plotkin <erkyrath <at> eblong.com> wrote:
> I could use the XML entity localization system for this, but that turns
> out to be a bit of a nuisance to use inside ECMAScript code. Because you
> generally want to wrap your script code in a CDATA[[]], so that you can
> use literal < and > signs. But then XML entities aren't translated. It's
> possible to work around this, but it's more lines of code.

E4X has something on this. Sadly I can't find the link that says what.
But I know I've seen the CDATA problem addressed. *sigh*

--
______________
Mike Sugarbaker
Super Geiniuis

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
Permalink | Reply | 0 comments |
headers
Andrew Plotkin | 5 Dec 17:22

Re: UI API changes

On Sun, 4 Dec 2005, katre wrote:

> Andrew Plotkin wrote:
>> 2:
>>
>> I've been thinking for a while about a way for the UI to mark the seat
>> whose turn it currently is -- in Javolin's seat display panel, not just
>> the UI pane. I'd like to nail down the API for this, even if I don't
>> implement it for a while. (That way I can put the API in as a no-op, and
>> write UI code that prospectively calls it, without hitting errors.)
>
> This sounds like a useful idea, but I'm not sure the UI should control
> it.  Is there any way for the referee to handle sending this message to
> the client, which handles the seat display? Or am I confused and the
> seat display is already handled by the UI, so there's no point in
> keeping this separate?

The seat display is handled by the client, it's true. I just figured that 
the UI already *knows* whose turn it is -- because you need to know that 
to parse user input and draw highlights and stuff. And this information 
arrives in game-specific RPCs. I don't want to add a parallel, generic RPC 
to transfer the same information directly to the client.

On Sun, 4 Dec 2005, Mike Sugarbaker wrote:

> On 12/4/05, Andrew Plotkin <erkyrath <at> eblong.com> wrote:
>> You generally
>> want to wrap your script code in a CDATA[[]], so that you can
>> use literal < and > signs. But then XML entities aren't translated. 
>> It's possible to work around this, but it's more lines of code.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Plotkin | 6 Dec 07:41

Re: UI API changes

Discussion around the office is leaning towards:

> A new "ui" namespace for translation tokens.

"yes" on that.

> - Being able to mark more than one seat at a time
> - Multiple kinds of marks (e.g., "attacker" and "defender" in a Cosmic 
> Encounter turn. Or "winner" at the end of a game.)

"yes" on both of those too. However, not an unlimited number of kinds of 
marks. While infinite flexibility would be cool, we're thinking of having 
just a small handful of marks -- types 1, 2, 3, and 4 -- also to be known 
as "the arrow", "the pointy arrow", "the wide arrow", and "the other 
arrow". Or something like that.

Maybe they should be named by strings rather than integers, to provide 
some feeble semantics for their use, but then they'd have to be "turn", 
"win", "steve", and "herman". Since your-turn and you-won are the only two 
semantic roles generalizable across a majority of games. (That I can think 
of.)

(There will be a separate indicator which marks the seat you're sitting 
in. Since that ought to be obvious at a glance. This will be handled by 
the client, not the UI code.)

For the actual API, I expect to use a single polymorphic function:

seatmark()
     all marks off
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jason McIntosh | 6 Dec 19:17
Picon

sXBL and Batik

Working on a UI for Fluxx, I thought I'd see how Batik's coming along
with support for sXBL, W3's binding language for SVG and XForms. This
is the path to widgetry, my friends.

When I last peeked at it last year, it was just a twinkle in the eye.
So I was delighted to discover that sXBL enjoys substantial (if not
quite spec-complete, yet) support with the latest Subversion/nightly
builds of Batik. Indeed, the version that our most recent Javolin
requires supports it at least well enough to run W3's sXBL Hello
World.

Here is the relevant W3 page:
http://www.w3.org/TR/2004/WD-SVG12-20041027/binding.html I am
investigating this presently.

And the page on the Batik Wiki about their support for SVG 1.2 (of
which sXBL is part). It's actually rather far along.
http://wiki.apache.org/xmlgraphics-batik/SupportedSVG12Features

--
Jason McIntosh
zendonut <at> gmail.com
Jabber: jmac <at> volity.net
AIM: zendonut
http://jmac.org

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Plotkin | 6 Dec 19:16

Player resource handling

(That's the "JID resource" I'm talking about -- the tail part of 
a JID like "zarf <at> volity.net/javolin".)

The current player JID rules are designed to make sure that if you get 
disconnected from a game, you can rejoin and keep your place. (This is a 
must-have goal, of course.) The rules are, more or less:

- A given client always uses the same resource. (Javolin always uses 
"Javolin".)

- Players are identified by full JID. (So zarf <at> volity.net/Javolin is 
considered a different player from zarf <at> volity.net/friv. If
zarf <at> volity.net/Javolin is disconnected from the game and then 
zarf <at> volity.net/Javolin joins the game, the referee accepts him as the 
same person and considers him to have retaken his position. If 
zarf <at> volity.net/Javolin is disconnected and then zarf <at> volity.net/friv 
joins, the referee says "Welcome new observer!")

- In the bookkeeper (and nowhere else), players are identified by bare 
JID (excluding the resource). Your player reputation is accumulated from 
all your connections, regardless of what resource strings you used.

These rules are simple and easy to use. However, they disallow the case of 
quitting one client, starting a different client, and rejoining the game. 
(We currently expect to have only one client in common use among players, 
but that could change.)

These rules also grind against some of Jabber's rules:

- When you log into Jabber, you are not guaranteed to get the resource you
(Continue reading)

Permalink | Reply | 3 comments |
headers
Doug Orleans | 6 Dec 21:26
X-Face

Re: Player resource handling

Andrew Plotkin writes:
 > The obvious fix is for the client to use unique resources. (So you join as 
 > "zarf <at> volity.net/jav0175" one time, and "zarf <at> volity.net/jav9742" next 
 > time. The player would never see the resource string, of course -- it's 
 > randomly generated.)

I would like the option of being able to choose a resource, rather
than it always being determined randomly.  Currently, I use different
resources per computer (home, laptop, work) even though all three use
Gaim; this makes it easier to keep track of where each connection is
coming from.  Having these be random numbers out of my control would
be frustrating.  (Not to mention that four random digits probably
isn't enough; there's a 1/10000 chance of collision, which seems
pretty high.)

By the way, can we use priorities here?  E.g. regard priorities lower
than, say, 3 as always being observers?  I haven't thought this
through, just throwing it out there.

--dougo <at> place.org

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
Permalink | Reply | 2 comments |
headers
Andrew Plotkin | 6 Dec 23:05

Re: Player resource handling

On Tue, 6 Dec 2005, Doug Orleans wrote:

> Andrew Plotkin writes:
> > The obvious fix is for the client to use unique resources. (So you join as
> > "zarf <at> volity.net/jav0175" one time, and "zarf <at> volity.net/jav9742" next
> > time. The player would never see the resource string, of course -- it's
> > randomly generated.)
>
> I would like the option of being able to choose a resource, rather
> than it always being determined randomly.

I have no problem with that, if you're the sort of user who knows what a 
resource is.

How would that look in the current UI? Adding a "resource" field in the 
login dialog is a mistake, IMHO. But we could accept a username of 
"zarf/resource".

(Should we change the login dialog to have a single JID field, as opposed 
to "host" and "username"? Someone must have asked this before.)

>  (Not to mention that four random digits probably isn't enough; there's 
> a 1/10000 chance of collision, which seems pretty high.)

I wasn't actually going to use four decimal digits.

> By the way, can we use priorities here?  E.g. regard priorities lower 
> than, say, 3 as always being observers?

Priorities don't work on delivery of <iq> packets the same way they do on
(Continue reading)

Permalink | Reply | 1 comment |
headers
Karl von Laudermann | 7 Dec 00:58
Favicon

Re: Player resource handling

On Dec 6, 2005, at 5:05 PM, Andrew Plotkin wrote:

> (Should we change the login dialog to have a single JID field, as  
> opposed to "host" and "username"? Someone must have asked this  
> before.)

Yes, this should probably be changed. I decided a long time ago that,  
in retrospect, it was silly to have done it the way that I did, but  
there was always higher priority work to be done.

--

-- 
                 Karl von Laudermann
                 karlvonl <at> rcn.com
                 http://www.geocities.com/~karlvonl/
                 Richard's PBeM Server ID: karlvonl

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
Permalink | Reply | 0 comments |

Gmane