Life tag testing

[Nathaniel]

Currently testing a new life tag, for displaying patterns in-line in the forums. Most of you guys can just ignore this thread -- it's here so that Chris and I can discuss how the tag should work.

Right now, typing

Code: Select all

[viewer ]bo$2bo$2o![/liferle][/viewer ]

produces the following (the textbox will be hidden when this goes live; it's just displayed for debugging purposes right now):

[viewer]bo$2bo$2o![/viewer]

The location of the plugin on Chris' server is: [url]http://lazyslug.no-ip.biz/lifeview/plugin/js/lv-plugin.js[/url]  (this is just for my own reference, since I keep losing the link)

The URL to update LV on the ConwayLife.com server: [url]http://www.conwaylife.com/mod_lv_update.php[/url]

[rowett]

Hi Nathan,
I think the end state should be:

1. Host the "lv-plugin.js" locally and include it at the top of the page where you include the "forum_fn.js". This way you won't need to create an IFRAME for each viewer. If it's not possible to adjust the include statements I guess you could add the contents to the "forum_fn.js" file.

2. Wherever you encounter the "liferle" tag output:

Code: Select all

<rle>
  <textarea>bo$2bo$2o!</textarea>
  <canvas width="480" height="480"></canvas>
</rle>

3. I've updated the "lv-plugin.js" so that it will automatically start all viewers on the page when the page loads. You'll notice the updated test.html no longer contains any Javascript. It just includes the lv-plugin.js at the top and the rest happens automatically.

Basically in the "lv-plugin.js" file it creates an event that fires when the page is loaded. That event callback then searches the page for <rle> tags and assumes each one contains a <textarea> with the life script and a <canvas> to display it on. It then initialises the Viewer over each canvas.

[Nathaniel]

Hi Chris,

Thanks. I've included lv-plugin.js locally and included it on the forum. I've also changed the phpBB tag to work as you suggested. However, one problem has come up that I hadn't anticipated: phpBB automatically HTML-ifies any text that the user inputs, which causes problems. For example, if the user enters a line break, phpBB turns that line break into a <br /> tag. For example, typing:

Code: Select all

[liferle]#C RLE: Acorn
#C [[ THEME 7 LAYERS 5 DEPTH 0.25 ZOOM 10 X 20 XSIZE 1024 YSIZE 512 ]]
x = 7, y = 3, rule = B3/S23
bo5b$3bo3b$2o2b3o![/liferle]

Produces:

[liferle]#C RLE: Acorn
#C [[ THEME 7 LAYERS 5 DEPTH 0.25 ZOOM 10 X 20 XSIZE 1024 YSIZE 512 ]]
x = 7, y = 3, rule = B3/S23
bo5b$3bo3b$2o2b3o![/liferle]

Could you have your JS library convert <br /> tags back into simple newlines? After that, I think that things should work properly.

[rowett]

Hi Nathaniel,
I've posted a new version of lv-plugin.js with a number of fixes and improvements including converting the <br /> elements to newlines. This now appears to be working on Chrome, Firefox and Opera. However I've identified a problem with Internet Explorer which will need some more investigation.

[rowett]

Hi Nathaniel,
It turns out that there were (at least) two issues with Internet Explorer support.

1) IE is not good at handling elements in the document that are not HTML elements. The fix for this is to replace the generated <rle> and </rle> tags with <div class="rle"> and </div>. The new version of the plugin requires this.

2) In the Conwaylife.com forum header there is the following meta element:

Code: Select all

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

This is causing Internet Explorer to switch off support for the Canvas element which is needed by the Viewer. I don't have a workaround for this other than to remove the meta tag (or perhaps set it to a later IE mode). I don't know what other effects that might have on the site.

Other changes in this build:

• The Viewer automatically stops when there are no cells alive.
• The Viewer gives notifications about focus. If you mouseover and the Viewer doesn't have focus it will tell you that you need to click. If you have focus and you move off the Viewer it will tell you that focus is lost. If the messages are annoying I can remove them.
• I did a little work to make the Viewer behave better on startup for browsers that don't support HTML5 (for example IE8).

[Nathaniel]

Hi Chris,

Thanks, I've uploaded the up-to-date script, and updated the BBcode to use DIVs. Looks nice now!

Just to be clear -- regarding your point (2), does your script automatically remove that meta tag now, or is that something you need me to do? Either way, I doubt it will affect this site much, and it should be fine to remove it.

Cheers!

[rowett]

Hi Nathaniel,
On point 2 you will need to remove the tag.

[rowett]

Hi Nathaniel,
In the next version I've implemented the script commands that let you size the Viewer. They were called XSIZE and YSIZE (in the Acorn example above). I've renamed the script commands to WIDTH and HEIGHT so please can you do the same in your example post.

We should decide:
1) Whether we want users able to set the size of the Viewers?
2) If so then what are sensible upper and lower limits for the size?
The lower limit should be 480x480 pixels since below this the menus become too cramped.
The upper limit on width will be constrained by the style of the forum page itself. At the moment it looks like the main content area for a post (<div class="postbody">) is about 667 pixels wide.
The upper limit on height should be anything that fits on the display, perhaps 800 or 900 pixels?

Let me know your thoughts.

[rowett]

Hi Nathaniel,
I posted a new build containing:
1) The WIDTH and HEIGHT script commands.
2) Quietly ignores IE9 since it doesn't have adequate support for the Viewer (rather than throwing an error).
3) Computes the Life population when playback paused and you switch the statistics on.

I've tested on:
Chrome 40
Firefox 35
Opera 27 (good) and 12.17 (slow!)
Internet Explorer 10 and 11
Safari 5.1 (slow!)

[dvgrn]

Other changes in this build:

• The Viewer automatically stops when there are no cells alive.

Is it possible to let it run a little longer, until all 'envelope' cells have faded all the way to black? Or maybe stop the generation count but still let everything fade to black? Not sure which is better, but in the current test pattern in the first post, it's a little odd ending up with a blue hexomino, and not being able to advance the generation count with the space bar.

Maybe it would be good to be able to advance the generation count with the space bar, even when it's useless to do so. Otherwise there's this strange sense that the system has suddenly stopped working: the count used to go up when I hit Space, and now it doesn't, and there's this mysterious blue blob sitting there that ought to be fading away.

The Viewer gives notifications about focus. If you mouseover and the Viewer doesn't have focus it will tell you that you need to click. If you have focus and you move off the Viewer it will tell you that focus is lost. If the messages are annoying I can remove them.

Not sure yet whether I like the messages or not. It may turn out that the only clue that a user will really need will be something relatively subtle -- a change to the frame border, let's say, which I see you're already doing. My first reaction is that the font could safely be a lot smaller, at least...! My first reaction is that "Click to Control" is useful, but that "Control On" / "Control Off" are distracting.

Maybe the YSIZE could safely be dropped a bit more than the XSIZE? There's an advantage when you're doing a posting with what amounts to illustrated text, if you can keep the illustrations more compact. Maybe even the viewer more "locked down" at smaller sizes, so that you can still show small images and copy out the RLE, but can't get to all the rotate/speed/etc. options? In cases where the point is just to have a series of small illustrations explaining something, it might be overkill to have each pattern take up half of the screen.

In general I'd just like to say:

Code: Select all

#C [[ THEME 9 LAYERS 4 DEPTH 2 ANGLE 5 ZOOM 10 ]]
#C [[ AUTOSTART LOOP 5 GPS 5 ]]
x = 48, y = 30, rule = B8/S678
48A$48A$48A$48A$48A$48A$6A36.6A$6A36.6A$6A36.6A$6A36.6A$6A4.A5.A4.2A
4.A5.A3.A4.6A$6A4.A5.A3.A2.A3.A5.A3.A4.6A$6A4.A5.A2.A4.A2.A5.A3.A4.6A
$6A4.A5.A2.A4.A2.A5.A3.A4.6A$6A4.A5.A2.A4.A2.A5.A3.A4.6A$6A4.A5.A2.A
4.A2.A5.A3.A4.6A$6A4.A2.A2.A2.A4.A2.A2.A2.A3.A4.6A$6A4.A.A.A.A2.A4.A
2.A.A.A.A3.A4.6A$6A4.2A3.2A3.A2.A3.2A3.2A8.6A$6A4.A5.A4.2A4.A5.A3.A4.
6A$6A36.6A$6A36.6A$6A36.6A$6A36.6A$48A$48A$48A$48A$48A$48A!

[rowett]

Hi Dave,
Firstly, nice use of the script commands

Based on your feedback I've modified the plugin as follows:
1) The Viewer no longer automatically stops when no cells are alive (actually it does but you can't tell since it keeps fading and the counter continues). The reason I did this in the first place was to save CPU cycles if there was no work to do. Now I get the best of both worlds: I save the cycles and it looks like it keeps going.

2) I removed the "Control On" and "Control Off" messages. I haven't changed the font size (yet) for "Click to control" since it uses the standard font size that all notifications use ("Play", "Pause", etc.). Let me know if you think they are all too big.

3) I'll investigate a "locked down" view for a future build...

Note that when Nathaniel uploads the next build you'll need to change the XSIZE and YSIZE commands to WIDTH and HEIGHT (or you'll get a nice complaint from the Viewer). The next build is 117 and you can tell which build is installed by typing H a few times on an active Viewer to get to the 4th help page.

[dvgrn]

1) The Viewer no longer automatically stops when no cells are alive (actually it does but you can't tell since it keeps fading and the counter continues). The reason I did this in the first place was to save CPU cycles if there was no work to do. Now I get the best of both worlds: I save the cycles and it looks like it keeps going.

Sounds good! Does the new build play nicer with Autostart loops, then? For example, in build 116, if you changed my WOW! pattern script to [[ AUTOSTART LOOP 6 GPS 5 ]], the display would get stuck, because all cells are off as of T=5. I originally wanted to run to T=25 or so, to let the message fade to black, but had to settle for a short loop.

Another nice feature might be [[ AUTOSTART DELAY N ]], to show the starting pattern for N seconds before the action begins.

2) I removed the "Control On" and "Control Off" messages. I haven't changed the font size (yet) for "Click to control" since it uses the standard font size that all notifications use ("Play", "Pause", etc.). Let me know if you think they are all too big.

Well, if it were up to me, I'd probably drop the Play/Pause/Click font size down to the size of the text at the bottom of the screen. The animated appearance and disappearance of the text will make sure it doesn't get missed. Seems as if the large text could easily become annoying, by covering up some of the early action of a pattern that you're trying to see. (But most likely it won't really be a big deal.)

Note that when Nathaniel uploads the next build you'll need to change the XSIZE and YSIZE commands to WIDTH and HEIGHT.

Okay, I've pre-emptively fixed my last posting, and tried out a few more script commands along the way. Thanks again for all the work on this! This will make a really nice addition to the forums. Hope you won't mind a deluge of feature requests when it starts getting used by more people...

[rowett]

Nathaniel / Dave,
I've released build 117. New in this build:

• Reduced the font size for notifications ("Play", "Pause", etc.)
• Reduced the minimum Viewer height to 240 pixels (use the HEIGHT script command)
  • Heights smaller than 480 pixels do not show the navigation menu
• Improved the help text system
  • The help text display now fits the height of the Viewer
  • Page Up and Page Down keys are used to scroll through the help text
  • Home and End keys to go the top and bottom of the help text
  • Help text for the X and Y script commands now shows correct range
• If the Viewer is not supported by the browser the canvas will be automatically hidden on the page and then textarea will be shown (with the code converted to remove <br /> elements)
  • In the future my assumption is that the textarea will be hidden by default
  • It might be worth making the textarea similar in visual style to the current code block in this case, and also need to think about ability to select the code for cut and paste, thoughts?
• Added hotkey I to toggle information display about the current pattern and the Viewer

Nathaniel when you install this build could you please also remove the meta tag discussed earlier so I can test in IE10 and 11?

Does the new build play nicer with Autostart loops, then?

Yes, it should do.

Another nice feature might be [[ AUTOSTART DELAY N ]], to show the starting pattern for N seconds before the action begins.

Nice idea, though I'm probably going to hold on this until I implement the waypoint script commands since I think they will allow you to do the same in a more flexible way.

Well, if it were up to me, I'd probably drop the Play/Pause/Click font size down to the size of the text at the bottom of the screen.

I reduced the font size for the notifications in this build. It certainly looks better.

Hope you won't mind a deluge of feature requests when it starts getting used by more people...

Not at all. As long as they don't mind waiting for me to implement them...

[rowett]

Hi Nathaniel,
Could we replace the <textarea> tag with the output from the "code" directive? That would give us a consistent way of selecting code regardless of whether it is in a displayed code block or a Viewer. When outputting for the "lifearea" directive set "style=display:none" on the <code> element.

For example:

Code: Select all

<div class="rle">
    <textarea>bo$2bo$2o!</textarea>
    <canvas width="480" height="480"></canvas>
</div>

Would become:

Code: Select all

<div class="rle">
    <div class="codebox">
        <div class="selall">Code:
            <a href="http://www.conwaylife.com/forums/..." onclick="selectCode(this); return false;">Select all</a>
        </div>
        <div>
            <code style="display:none">bo$2bo$2o!</code>
        </div>
    </div>
    <canvas width="480" height="480"></canvas>
</div>

If that makes sense then I'll modify the plugin accordingly. I could have it hide the Viewer and show the <code> element if there's insufficient support for the Viewer in the browser. That way if you use the "liferle" directive and people don't have browser support they'll see a standard "code" block.

Thanks,
Chris

[Nathaniel]

Hey Chris,

Sorry for the delay -- I finally got around to the following:

(1) Removing the meta tag we discussed.

(2) Updating the BBcode as you suggested in the previous code (it now output a code block instead of a textarea). This was a great idea.

(3) The forums now load the javascript directly from your website, rather than from the conwaylife.com servers. This is so that you can continue to update and tweak your plugin and see the results here, without having to wait for me to re-upload it every time. I will change this back to the old behavior (loading the JS file locally) when this feature goes live.

Cheers!

[dvgrn]

Hmm. So how do I adjust [liferle] blocks now so that the pattern shows up again? Right now I'm seeing an empty code block in my previous posting, and a big blank space where the LifeViewer used to be.

[Nathaniel]

Hmm. So how do I adjust [liferle] blocks now so that the pattern shows up again? Right now I'm seeing an empty code block in my previous posting, and a big blank space where the LifeViewer used to be.

You don't yet Once Chris updates the script to work with the new BBcode (i.e., using the code tags rather than <textarea>s), it'll work again.

[rowett]

Hi Nathaniel,
I can see the new liferle output correctly in the page. However I can't yet see the removal of the meta tag or the reference to my site for the plugin. Perhaps it hasn't refreshed properly yet?

Also please can you remove the "style=display:none" from the "code" element, just revert to <code>. If the element is not displayed then the browser refuses to select it when you click on the SELECT ALL button. I've worked round this by setting the "code" element height to 1 pixel in the plugin.

Thanks,
Chris

[Nathaniel]

Hi Nathaniel,
I can see the new liferle output correctly in the page. However I can't yet see the removal of the meta tag or the reference to my site for the plugin. Perhaps it hasn't refreshed properly yet?

Eeep, sorry about that. I forgot that phpBB does some heavy-duty caching on the backend that I have to manually flush. Done now, so the updates should show up now.

I've also removed the "style=display:none".

[rowett]

Hi Nathaniel,
Perfect, looks good.

Tested on Windows 8.1 on:
Chrome 40
Firefox 35
Opera 27
Opera 12.17 (slow!)
IE 11
Safari 5.1 (slow!)

Tested on Windows 7 on IE8 and since there's no support for the Viewer in IE8 all the Viewers magically became standard code blocks

[Nathaniel]

Looks good Chris, thanks! A couple thoughts:

1) I didn't like how the code element was the full post width while the canvas element wasn't, so I've made the canvas element the full post width by default now. Honestly, I like it much better this way, and I don't see much of a reason to let a user specify a different width. Thoughts?

2) Something about the Code tag above the canvas bugs me. I feel like it will be confusing to users -- there's a "Select All" button that allows you to copy the code, but there is no visual cue when that button is pressed, or even what it's selecting. With that in mind, I suggest one of two things (feel free to object to both of them):

• We make the code section actually display the code (but perhaps only the first line or two of it); or
• We hide the code section *completely* and instead incorporate the copy functionality directly into your plugin> Honestly, I don't even know if this is possible -- is it possible to detect when the user presses Ctrl+C and copy the text to clipboard when they do so?

[rowett]

Hi Nathaniel,
I agree with your sentiment on both points. It looked odd to me also, especially since there was no visual cue that you'd made a selection. I investigated getting the browser to also do the copy but it's very unpleasant (mostly for security reasons but also cross-browser). Plus I like the consistency we get between the "code" block and the "liferle" block. Additionally when the browser doesn't support the Viewer we get a standard "code" block so I'd rather not build something different.

Build 118 now will display the first two lines of the "code" block above the Viewer. This, I believe, looks better and it also gives you the visual cue when you select the code. Let me know if you prefer it.

In terms of the width I'm happy with the full width being the default. Also now a couple of lines of the code block are displayed it doesn't look so bad when there is a less than full width viewer. I do believe there will be instances where someone might want a smaller Viewer, however happy to be guided by other opinion on this topic.

[dvgrn]

A minor detail I just noticed on Build 118: when you're using the mousewheel to zoom in and out, it's fairly standard practice (in mapping software, image editors, and Golly) to keep the pixel under the mouse cursor fixed, rather than the center of the image. Otherwise, if you have something off-center that you're interested in getting a closer look at, you have to keep re-centering it as you zoom in.

Build 118 now will display the first two lines of the "code" block above the Viewer. This, I believe, looks better and it also gives you the visual cue when you select the code.

It's definitely much nicer to be able to see a few lines of the RLE. A minor point from experience elsewhere: it sometimes works better to make the height a non-integer number of lines (2.5?) as a visual cue that there's more there to be selected than what you can see.

In terms of the width I'm happy with the full width being the default. I do believe there will be instances where someone might want a smaller Viewer, however happy to be guided by other opinion on this topic.

I think the current setup is great as a default, and maybe there's no need to worry about giving people more control than that. If someone really wants a lot of small images, they can perfectly well attach small images and put them inline in the text. There's not a lot of flow control available in standard BBcode anyway, so nobody will be posting messages with multiple small Viewers on the same line, or text to the left or right of a Viewer.

The use case I was thinking of for a reduced-size "locked down" viewer comes from many years of people trying various tricks to visually quote Life patterns in articles or other explanatory text:

Paul Callahan -- now limited due to Java security issues
Nicolay Beluchenko -- same Java problems as above
Adam P. Goucher (Internet Archive) -- 1-pixel-per-bit images are gone, but links to the RLE still work.

I'd like to rebuild Adam's stable-technology article at some point, as an HTML page not a forum message -- have to add Snarks and semi-Snarks, among other new developments! Something like LifeViewer still seems like an obvious candidate, maybe a locked-down (but unlockable?) version -- the

Code: Select all

 section at the top wouldn't be needed in that form, but an option to specify a caption might be good.

Come to think of it, Build 118 allows for a pretty good two-line caption right now, if the RLE includes two lines of comments at the top.

[rowett]

Hi Dave,
Build 119 includes the two requirements below:

When you're using the mousewheel to zoom in and out, it's fairly standard practice (in mapping software, image editors, and Golly) to keep the pixel under the mouse cursor fixed, rather than the center of the image.

A minor point from experience elsewhere: it sometimes works better to make the height a non-integer number of lines (2.5?) as a visual cue that there's more there to be selected than what you can see.

[dvgrn]

Build 119 includes the two requirements below:

When you're using the mousewheel to zoom in and out, it's fairly standard practice (in mapping software, image editors, and Golly) to keep the pixel under the mouse cursor fixed, rather than the center of the image.

This works perfectly at 100% zoom in Google Chrome.

When I try Ctrl+mousewheel outside of the Viewer, and thus change the text size to 150% or 75% or whatever, the Viewer scales appropriately and everything still seems to work very well -- except for the new zoom-around-mouse-cursor functionality, which appears to get a little bit confused by the scale change.

I like the 2.5-row code block -- hope everyone else does too... So what else is on the list to be updated before this is ready for prime time?