Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
7936
Features / Re: Template skeleton!
« on September 6th, 2011, 05:30 PM »Yes... but it absolutely does not require eval at all ;)
I thought the whole point was that the skeleton would dictate which parts to call and in what order, nor intermixing the order with the content therein...
So, as an example, here's the code from the body layer's 'above' section...
function template_body_above()
{
global $settings;
if ($settings['sidebar_position'] === 'left_page')
template_sidebar();
echo '
<div id="wedge">', !empty($settings['forum_width']) ? '<div id="wrapper" style="width: ' . $settings['forum_width'] . '">' : '';
// Show the header area.
template_header();
// Show the menu here, according to the menu sub-template.
template_menu();
// Show the navigation tree.
theme_linktree();
// The main content should go here.
echo '
<div id="content"><div class="frame">';
if ($settings['sidebar_position'] === 'left_content')
template_sidebar();
}Please look at <div id=content>... Where exactly would you put that in a skeleton situation? In what function, exactly? If we can get rid of it, does it mean we're getting rid of the body layer as well? What of the wedge div, do we have to create a new template_* function just for this call...?
7937
Features / Re: Template skeleton!
« on September 6th, 2011, 05:12 PM »Variable functions are a truly wonderful thing. :P
"extract the following string, make sure it's a valid function, and we call it."
:whistle:
$skeleton = "header, sidebar, content, footer";
The only 'trick' is that it couldn't have any PHP in it, really. We're only talking about the main structure, not overriding anything else...
The one thing that seems critical to me is that the list of items can be manipulated, and ideally more easily than fudging around with a string; that's one thing I like about the current setup is that you can add new items cleanly to an existing content area.
<layer:header>
<menu>
<linktree>
<layer:main>
<layer:sidebar>
<footer>
I don't know... Something that basically tells Wedge whether to start a layer or a sub-template at that point. Or it could simply recognize whether <footer> is stand-alone function, or a layer... Etc.
7938
Features / Re: Template skeleton!
« on September 6th, 2011, 05:00 PM »
Changing the layout should only be useful for the sidebar, I suppose. I mean, I don't see any possible reasons for someone wanting to show the footer at the beginning or the header at the right of the page... :P
Although I suppose one could want to make a three-column layout where the header or footer is the third column. That doesn't make much sense to me, but never underestimate the power of craziness, sometimes it leads to innovation... :P
Doing a skeleton really is something I'd like to do at this point. I considered it for the first time a few months ago when I built upon the layer system. I just found it... A bit too complicated for my taste, and at the time I didn't even consider some alternative solutions for the implementation that make sense to me only after working through the mess that is the template layer system. (Although it has to be said that when used correctly, layers do things that a skeleton could hardly do.)
For instance... Imagine a skeleton saying basically, "header, sidebar, content, footer". If I want to add data to the footer through the skeleton, I can't. I'll have to do it above it or below it, considering that 'footer' includes its own wrap code (<div></div>). With a layer system, we "only" need to do something like "header_above header_content header_below sidebar_above sidebar_content sidebar_below content_above content_content content_below footer_above footer_content footer_below". Now I can easily add my code in "footer_content" without fear of breaking it.
Of course, a logical solution is to make way for template hooks in strategic positions like these, so I'm not too worried, and would actually, at this point, be more interesting in getting rid of layers and manually adding hooks in the skeleton, or rather in the related functions (content, sidebar, etc.)
If anything, it's probably easier to understand for anyone having a first look at index.template.php... A function called skeleton(), with some HTML and some {calls} like this, followed with a series of functions sharing the same name, really makes a lot of sense...
Then again, how do we do that without eval()?
We can't do echo '...' because then we'll need to capture the buffer at ob_sessrewrite time and call the functions one at a time there -- and I'm pretty sure it'd break many things because some items expect to be called before ob_sessrewrite is done, eh.
We can do return '...' then, and analyze the code. We echo the thing as it goes, but we stop on each {, extract the following string, make sure it's a valid function, and we call it. Then we discard the following } and we resume the templating process...
I like that idea. What do you think of it?
Plus, it makes it much easier to change the template layout in skins, really. We can very simply put that code into a <skeleton><![CDATA[<html>]]></skeleton> and replace the code we got from skeleton()...
We can do something like this to begin with, and then determine whether we need to keep the template layer code around.
Oh, in other news (© Pete), I renamed template_header() and template_footer() to start_output() and finish_output()... I don't know about you, but I always found these two functions to have VERY misleading names. Especially when you consider that template_footer() never was there to show a footer at all... Just to finish the layers in reverse order. :^^;:
Although I suppose one could want to make a three-column layout where the header or footer is the third column. That doesn't make much sense to me, but never underestimate the power of craziness, sometimes it leads to innovation... :P
Doing a skeleton really is something I'd like to do at this point. I considered it for the first time a few months ago when I built upon the layer system. I just found it... A bit too complicated for my taste, and at the time I didn't even consider some alternative solutions for the implementation that make sense to me only after working through the mess that is the template layer system. (Although it has to be said that when used correctly, layers do things that a skeleton could hardly do.)
For instance... Imagine a skeleton saying basically, "header, sidebar, content, footer". If I want to add data to the footer through the skeleton, I can't. I'll have to do it above it or below it, considering that 'footer' includes its own wrap code (<div></div>). With a layer system, we "only" need to do something like "header_above header_content header_below sidebar_above sidebar_content sidebar_below content_above content_content content_below footer_above footer_content footer_below". Now I can easily add my code in "footer_content" without fear of breaking it.
Of course, a logical solution is to make way for template hooks in strategic positions like these, so I'm not too worried, and would actually, at this point, be more interesting in getting rid of layers and manually adding hooks in the skeleton, or rather in the related functions (content, sidebar, etc.)
If anything, it's probably easier to understand for anyone having a first look at index.template.php... A function called skeleton(), with some HTML and some {calls} like this, followed with a series of functions sharing the same name, really makes a lot of sense...
Then again, how do we do that without eval()?
We can't do echo '...' because then we'll need to capture the buffer at ob_sessrewrite time and call the functions one at a time there -- and I'm pretty sure it'd break many things because some items expect to be called before ob_sessrewrite is done, eh.
We can do return '...' then, and analyze the code. We echo the thing as it goes, but we stop on each {, extract the following string, make sure it's a valid function, and we call it. Then we discard the following } and we resume the templating process...
I like that idea. What do you think of it?
Plus, it makes it much easier to change the template layout in skins, really. We can very simply put that code into a <skeleton><![CDATA[<html>]]></skeleton> and replace the code we got from skeleton()...
We can do something like this to begin with, and then determine whether we need to keep the template layer code around.
Posted: September 6th, 2011, 04:58 PM
Oh, in other news (© Pete), I renamed template_header() and template_footer() to start_output() and finish_output()... I don't know about you, but I always found these two functions to have VERY misleading names. Especially when you consider that template_footer() never was there to show a footer at all... Just to finish the layers in reverse order. :^^;:
7939
Features / Re: Template skeleton!
« on September 6th, 2011, 03:55 PM »
Okay... The "too long, didn't read" version then:
Is anyone interested in having themes where the sidebar is to the left of the page and the header, rather than to the left of the content (and thus below the header and above the footer)?
If yes, would you be willing to have a 'hackish' (and a bit ugly) way of doing that in the default theme (i.e. within a new skin, which is much easier to maintain in the long run), or would you rather create a new theme for this kind of detail?
Is anyone interested in having themes where the sidebar is to the left of the page and the header, rather than to the left of the content (and thus below the header and above the footer)?
If yes, would you be willing to have a 'hackish' (and a bit ugly) way of doing that in the default theme (i.e. within a new skin, which is much easier to maintain in the long run), or would you rather create a new theme for this kind of detail?
7940
Plugins / Re: Converting WedgeDesk
« on September 6th, 2011, 12:28 PM »
I've always been wondering... Are you working on WedgeDesk because you can't get rid of it in your head, even though you stopped working on SimpleDesk to... focus on Wedge? :whistle:
Also, can you actually pronounce "WedgeDesk" 10 times without stuttering? I can't even do it twice. "WeDesk", maybe...? "weDesk"? "DeskWedge"?
My sympathies for your sidebar issues... :P
Also, can you actually pronounce "WedgeDesk" 10 times without stuttering? I can't even do it twice. "WeDesk", maybe...? "weDesk"? "DeskWedge"?
My sympathies for your sidebar issues... :P
7941
Features / Re: New revs
« on September 6th, 2011, 12:24 PM »
rev 983
(7 files, 12kb)
* Given that it makes more sense (to me) to use the Go Up and Go Down button to go to the actual beginning and end of a page, rewrote these links to actually do it, with a nice little animation. Thank you jQuery. (Display.template.php)
* Rewrote topic index and unread posts to link topics to the new posts, just like the New icon does. Of course, if a topic has no new posts, it'll link to its start page as usual. (MessageIndex.template.php, Recent.template.php)
* Renamed css_generic_files to css_suffixes for logical reasons. (install.php, Class-CSS.php, Load.php, Subs-Cache.php)
@ Note: re: up/down, I've read that doing an animation on $('html, body') wasn't a good idea because it did it twice in Opera. It works perfectly in Opera 12 so I decided not to bother... Opera users are early adopters so even if earlier versions had a problem, I'd rather not complicate the code. I've also read that animating $(window) would work, but not for me when I tested.
(7 files, 12kb)
* Given that it makes more sense (to me) to use the Go Up and Go Down button to go to the actual beginning and end of a page, rewrote these links to actually do it, with a nice little animation. Thank you jQuery. (Display.template.php)
* Rewrote topic index and unread posts to link topics to the new posts, just like the New icon does. Of course, if a topic has no new posts, it'll link to its start page as usual. (MessageIndex.template.php, Recent.template.php)
* Renamed css_generic_files to css_suffixes for logical reasons. (install.php, Class-CSS.php, Load.php, Subs-Cache.php)
@ Note: re: up/down, I've read that doing an animation on $('html, body') wasn't a good idea because it did it twice in Opera. It works perfectly in Opera 12 so I decided not to bother... Opera users are early adopters so even if earlier versions had a problem, I'd rather not complicate the code. I've also read that animating $(window) would work, but not for me when I tested.
7942
Features / Template skeleton!
« on September 6th, 2011, 12:08 PM »
I'd like a few opinions on the sidebar thingy... I'm posting in the public topic willingly, BTW.
Here's a small screenshot of the Warm skin. I've modified it to put the sidebar on the left of the *page*, as opposed to the left of the *content area* (i.e. surrounded by footer, header and nav.)
I just figured that forcing a sidebar onto users wasn't too big a deal (as it helps separate the main content from the asides, really, that's what it's all about), but forcing a sidebar layout onto themers wasn't as cool. It's not too hard to force the sidebar to show on the *right*, but then I thought, what if the themer wants a layout where the sidebar is outside of the header area? I think it's doable but it's hard. And most likely will require creating a new theme just for that aspect. Themes are harder to maintain than skins, so I tried to figure out a solution and it struck me that the layer system is either too simple, or too complicated.
The current layer structure makes the order of calling templates functions as such:
- template_html_above
- template_body_above
- template_header
- template_menu
- template_linktree
- template_sidebar_above
- "sidebar" sub-templates
- template_sidebar_below
- template_main_above
- "top" sub-templates
- "main" sub-templates (i.e. main content)
- template_main_below
- template_footer
- template_body_below
- template_html_below
In order to have the sidebar shown next to the rest of the page, I'd have to move the sidebar layer out of this loop. Although I'm not too scared at the idea of 'hacking' into the system for the good cause, I'm just wondering if there isn't a smooth way to do it.
Could we consider doing something like a 'skeleton' for the template functions...?
For instance, a $context['skeleton'] array of arrays, that pretty much holds the template structure. We already have similar things with the $context['sub_template'] variable, but it only holds the main content area structure.
I added a skin variable called <sidebar> and a theme variable called $settings['sidebar_position'], they both do the same thing: tell Wedge whether the skin wants the sidebar to be outside the flow, or next to the content. By default it's next to the content. So, right now, in template_body_above(), I just have two occurrences of this:
Code: [Select]
(The other being 'left_content', of course, and positioned in the correct place. And template_sidebar is a function defined in Subs.php that basically calls sidebar_above, the sidebar sub-templates, and sidebar_below.)
Although it works, I can't help feeling this is 'wrong'. Plus, it will force the skin to redefine the 'sidebar' and 'content' blocks, because in the default skin, they're linked together. Not a big deal of course, but what I probably don't like here, is that a themer can't simply switch between two sidebar positions through a single variable being set -- they'll also need to redefine the actual HTML content to match it... Not only that, but I'm not even sure it's not going to break stuff. I have the sidebar + content stuck inside an 'edge' div that serves as display:table and is also used by the onresize sidebar toggler. If I remove it, the toggler will stop working, but the 'edge' div is closed at the end of the 'content' block... And there's no 'block' for the entire page that shows on the right of the sidebar when in left_page mode. Meaning, the 'edge' div never gets closed properly just by redefining the blocks.
I can't really think of a way to get out of this loop of complicated crap. And I definitely don't want to live another week like last week, where a simple remark ("allow embedding in sentences doesn't work") led into a nightmare with a complete overhaul of the auto-embedding code. In the end I'm happy with it (the feature finally works as expected and the actual logic of the embedding process is a bit better), but... I'm just not ready to jump straight back into another nightmare, see.
Update -- I thought it didn't validate, but it does. The magic of nesting sort of fixed itself actually: the edge div closer is still in the same place (after the main content block), but this time it's seen as a closer for the wedge id, not edge. It should be totally broken because the wedge div is not even behaving like a table cell, but... bah. I guess these can be fixed in Warm/index.css anyway.
Still, I don't like hacks... :^^;:
I could actually allow skin.xml files to hold PHP code -- such as a template_body_above_override() function allowing for new sidebar layouts -- but it also mean eval. And, uhh... Let's just say I'd rather do without evals.
Lol... A modified sidebar location will freeze IE9 (100% CPU). But not IE7 or IE8, mind you! :lol:
Nice bug. Sasuga Maikurosofuto da na...
Here's a small screenshot of the Warm skin. I've modified it to put the sidebar on the left of the *page*, as opposed to the left of the *content area* (i.e. surrounded by footer, header and nav.)
I just figured that forcing a sidebar onto users wasn't too big a deal (as it helps separate the main content from the asides, really, that's what it's all about), but forcing a sidebar layout onto themers wasn't as cool. It's not too hard to force the sidebar to show on the *right*, but then I thought, what if the themer wants a layout where the sidebar is outside of the header area? I think it's doable but it's hard. And most likely will require creating a new theme just for that aspect. Themes are harder to maintain than skins, so I tried to figure out a solution and it struck me that the layer system is either too simple, or too complicated.
The current layer structure makes the order of calling templates functions as such:
- template_html_above
- template_body_above
- template_header
- template_menu
- template_linktree
- template_sidebar_above
- "sidebar" sub-templates
- template_sidebar_below
- template_main_above
- "top" sub-templates
- "main" sub-templates (i.e. main content)
- template_main_below
- template_footer
- template_body_below
- template_html_below
In order to have the sidebar shown next to the rest of the page, I'd have to move the sidebar layer out of this loop. Although I'm not too scared at the idea of 'hacking' into the system for the good cause, I'm just wondering if there isn't a smooth way to do it.
Could we consider doing something like a 'skeleton' for the template functions...?
For instance, a $context['skeleton'] array of arrays, that pretty much holds the template structure. We already have similar things with the $context['sub_template'] variable, but it only holds the main content area structure.
I added a skin variable called <sidebar> and a theme variable called $settings['sidebar_position'], they both do the same thing: tell Wedge whether the skin wants the sidebar to be outside the flow, or next to the content. By default it's next to the content. So, right now, in template_body_above(), I just have two occurrences of this:
if ($settings['sidebar_position'] === 'left_page')
template_sidebar();(The other being 'left_content', of course, and positioned in the correct place. And template_sidebar is a function defined in Subs.php that basically calls sidebar_above, the sidebar sub-templates, and sidebar_below.)
Although it works, I can't help feeling this is 'wrong'. Plus, it will force the skin to redefine the 'sidebar' and 'content' blocks, because in the default skin, they're linked together. Not a big deal of course, but what I probably don't like here, is that a themer can't simply switch between two sidebar positions through a single variable being set -- they'll also need to redefine the actual HTML content to match it... Not only that, but I'm not even sure it's not going to break stuff. I have the sidebar + content stuck inside an 'edge' div that serves as display:table and is also used by the onresize sidebar toggler. If I remove it, the toggler will stop working, but the 'edge' div is closed at the end of the 'content' block... And there's no 'block' for the entire page that shows on the right of the sidebar when in left_page mode. Meaning, the 'edge' div never gets closed properly just by redefining the blocks.
I can't really think of a way to get out of this loop of complicated crap. And I definitely don't want to live another week like last week, where a simple remark ("allow embedding in sentences doesn't work") led into a nightmare with a complete overhaul of the auto-embedding code. In the end I'm happy with it (the feature finally works as expected and the actual logic of the embedding process is a bit better), but... I'm just not ready to jump straight back into another nightmare, see.
Posted: September 6th, 2011, 11:15 AM
Update -- I thought it didn't validate, but it does. The magic of nesting sort of fixed itself actually: the edge div closer is still in the same place (after the main content block), but this time it's seen as a closer for the wedge id, not edge. It should be totally broken because the wedge div is not even behaving like a table cell, but... bah. I guess these can be fixed in Warm/index.css anyway.
Still, I don't like hacks... :^^;:
I could actually allow skin.xml files to hold PHP code -- such as a template_body_above_override() function allowing for new sidebar layouts -- but it also mean eval. And, uhh... Let's just say I'd rather do without evals.
Posted: September 6th, 2011, 11:45 AM
Lol... A modified sidebar location will freeze IE9 (100% CPU). But not IE7 or IE8, mind you! :lol:
Nice bug. Sasuga Maikurosofuto da na...
7943
Plugins / Re: Mods, support and so on
« on September 6th, 2011, 12:28 AM »
I believe I already shared my opinion around here...
- Mod site on wedge.org (based on Aeva Media. So that'd pretty much be like aeva.noisen.com's)
- No pre-moderation/vetting.
- A 'Recommended by the Wedge team' badge or something for the mods we like.
- Ability for modders to give Wedge the authorization to update the mods on their behalf if this or that happens. We'd then add a 'Maintained by the Wedge team' badge or something if user goes on hiatus.
- Paid mods should be allowed but with clear mentions. I don't know about downloading them from here, though... (payment gateway issues.)Quote Well, that's what you think... :lol:
I'm still the webmaster here :P
- Mod site on wedge.org (based on Aeva Media. So that'd pretty much be like aeva.noisen.com's)
- No pre-moderation/vetting.
- A 'Recommended by the Wedge team' badge or something for the mods we like.
- Ability for modders to give Wedge the authorization to update the mods on their behalf if this or that happens. We'd then add a 'Maintained by the Wedge team' badge or something if user goes on hiatus.
- Paid mods should be allowed but with clear mentions. I don't know about downloading them from here, though... (payment gateway issues.)
ultimately, I'm going to be the one writing the mod site,
I'm still the webmaster here :P
7944
Features / Re: New revs
« on September 5th, 2011, 09:40 PM »
rev 982
(7 files, 17kb)
* Updated copyright header. (Aeva-Sites-Custom-Example.php)
* Simplified dozens of Aeva site list entries, mostly removed unused non-capturing groups. Gosh, I'm sure 90% of these sites are dead or changed their embed code, or are just completely ignored anyway... (Subs-Aeva-Sites.php)
! Streetfire embedding was broken. Well, maybe it still is, I haven't tested. But at least the regex is no longer broken. (Subs-Aeva-Sites.php)
* It's site list, not sitelist. (Admin.english.php)
! SMF bug? In the error log, sessions were output as such, without any 'Session' text. Even I wasn't sure what these characters were about... (Errors.template.php)
- Too much styling is too much. Removed dotted line between options in admin media settings. (Media.template.php)
- Too much styling is me going crazy. Got rid of button list's custom font. Ever since mini-menus were introduced, post button font became a moot point anyway. (sections.css)
- Removed today (US Labor day) from calendar_holidays. (install.sql)
(7 files, 17kb)
* Updated copyright header. (Aeva-Sites-Custom-Example.php)
* Simplified dozens of Aeva site list entries, mostly removed unused non-capturing groups. Gosh, I'm sure 90% of these sites are dead or changed their embed code, or are just completely ignored anyway... (Subs-Aeva-Sites.php)
! Streetfire embedding was broken. Well, maybe it still is, I haven't tested. But at least the regex is no longer broken. (Subs-Aeva-Sites.php)
* It's site list, not sitelist. (Admin.english.php)
! SMF bug? In the error log, sessions were output as such, without any 'Session' text. Even I wasn't sure what these characters were about... (Errors.template.php)
- Too much styling is too much. Removed dotted line between options in admin media settings. (Media.template.php)
- Too much styling is me going crazy. Got rid of button list's custom font. Ever since mini-menus were introduced, post button font became a moot point anyway. (sections.css)
- Removed today (US Labor day) from calendar_holidays. (install.sql)
7945
Features / Re: New revs - Public comments
« on September 5th, 2011, 09:32 PM »
Keep up the good work :)
I saw where I made a mistake-- I'd simply looked at the previous post with rev 976, and posted the new one as 977... When I'd actually posted a 977 immediately after 976 and merged the two posts for good measure.
I saw where I made a mistake-- I'd simply looked at the previous post with rev 976, and posted the new one as 977... When I'd actually posted a 977 immediately after 976 and merged the two posts for good measure.
7946
Features / Re: New revs - Public comments
« on September 5th, 2011, 09:19 PM »
Oh. Sorry then. I'm not on my pc so I can't check whatever I screwed up. Plus I have another big commit coming up... Oh what a week.
7947
Features / Re: New revs
« on September 5th, 2011, 08:33 PM »
rev 981 -- this freaking commit took me a week of work!! Just for one feature nobody uses :(
(2 files, 20kb)
* Rewrote the 'Enable embedding in sentences' feature for Aeva, because it really wasn't solid enough. Since the new method is a tad slower, I've optimized the embedding process to compensate. See below. (Aeva-Embed.php)
! Local site checks were being done for all sites, and on each parse_bbc() call. Waste of time...
! A lot of code was being tested regardless of case. URLs should be case-sensitive, including the protocol, so don't bother with it. Come to me if you're experiencing trouble with special URLs. Also, parsed links should be on a single line, no need for the 's' modifier. Note for later: add support for local embedding on the https protocol...?
* Updated SWFObject version to 2.2... Yes, I know, if it ain't broke don't fix it. Also converted the JS embed code to postponed jQyery, saving us an extra buffer replacement operation (these are really expensive.)
! The express installer setting was inverted from the start. No one ever complained about it though, so it's probably not even worth using that...
! Don't force a font family on titles below videos. Only a font size.
! Oops, a count() was used in a for() loop...
- Removed an extra strlen() test that was already pretty much done, and a http:// conversion that probably shouldn't even happen in the first place...
* Merged the two aeva_protect_recursive*() functions together.
* Don't call aeva_parse_bbc2() if no link was found. (also Subs-BBC.php)
PS: I re-numbered the 3 previous revisions. I had an extra 977 which was really 978 :P Sorry Pete!
(2 files, 20kb)
* Rewrote the 'Enable embedding in sentences' feature for Aeva, because it really wasn't solid enough. Since the new method is a tad slower, I've optimized the embedding process to compensate. See below. (Aeva-Embed.php)
! Local site checks were being done for all sites, and on each parse_bbc() call. Waste of time...
! A lot of code was being tested regardless of case. URLs should be case-sensitive, including the protocol, so don't bother with it. Come to me if you're experiencing trouble with special URLs. Also, parsed links should be on a single line, no need for the 's' modifier. Note for later: add support for local embedding on the https protocol...?
* Updated SWFObject version to 2.2... Yes, I know, if it ain't broke don't fix it. Also converted the JS embed code to postponed jQyery, saving us an extra buffer replacement operation (these are really expensive.)
! The express installer setting was inverted from the start. No one ever complained about it though, so it's probably not even worth using that...
! Don't force a font family on titles below videos. Only a font size.
! Oops, a count() was used in a for() loop...
- Removed an extra strlen() test that was already pretty much done, and a http:// conversion that probably shouldn't even happen in the first place...
* Merged the two aeva_protect_recursive*() functions together.
* Don't call aeva_parse_bbc2() if no link was found. (also Subs-BBC.php)
PS: I re-numbered the 3 previous revisions. I had an extra 977 which was really 978 :P Sorry Pete!
7948
Off-topic / Re: Doctor Who
« on September 5th, 2011, 12:44 PM »
I've caught up on TW... Last 3 episodes were pretty watchable all in all. But it sounds more and more like the show was written as it went, instead of planned ahead. Several characters seem to have been introduced for nothing...
(click to show/hide)
Oh, my... Thankfully, the actors do their best to at least not make it boring. Plus, my girlfriend started watching at episode 8. I filled her in and told her, "good for you, you didn't have to go through so many episodes of bullshit :P"
As for this week's Doctor Who... Boring. The big twist was nice (well, the scene with the photo album -- it almost seemed like a reversal of roles for Daniel Mays who did a similar trick in Ashes to Ashes...), but the rest just wasn't very interesting. Frankly, if I hadn't been interested in Mays, I would have written off the episode as just on par with Victory of the Daleks or The Idiot's Lantern, i.e. Mark Gattis's other excruciating contributions to Doctor Who. As it stands now, it's... well, probably his best, because it had a bit of heart. But that's all.
Now for the final thought. After watching the two shows in a row...
The female sidekick in TW is married. To a geeky guy who doesn't look great but whom viewers love enough that he got a bigger part in the show.
The female sidekick in DW is married. To a geeky guy who doesn't look great but whom viewers love enough that he got a bigger part in the show.
The TW guy is called Rhys Williams.
The DW guy is called Rory Williams.
Is it me or... IS THERE A PATTERN?? :lol:
An entire episode was spent on saving Gwen's father, when she did nothing for him in episode 9... Several episodes were spent on Bill Pullman's character who, one episode shy from the end, is still exactly the same uninteresting character who has basically absolutely nothing to do except give a name (Pullman fans will have to go back to Zero Effect, I guess.)
Similarly, it seemed like the sole purpose of Angelo (nice story ep) was to introduce the characters to Nana "I'm going to die in a few minutes, don't bother with me" Visitor, who herself doesn't even seem to know whether she's a good or a bad girl... And who, just like her grandfather, had only one purpose, wait for it: giving names. From then on, it became even more ridiculous with the hacking and stuff.
Oh, my... Thankfully, the actors do their best to at least not make it boring. Plus, my girlfriend started watching at episode 8. I filled her in and told her, "good for you, you didn't have to go through so many episodes of bullshit :P"
As for this week's Doctor Who... Boring. The big twist was nice (well, the scene with the photo album -- it almost seemed like a reversal of roles for Daniel Mays who did a similar trick in Ashes to Ashes...), but the rest just wasn't very interesting. Frankly, if I hadn't been interested in Mays, I would have written off the episode as just on par with Victory of the Daleks or The Idiot's Lantern, i.e. Mark Gattis's other excruciating contributions to Doctor Who. As it stands now, it's... well, probably his best, because it had a bit of heart. But that's all.
Now for the final thought. After watching the two shows in a row...
The female sidekick in TW is married. To a geeky guy who doesn't look great but whom viewers love enough that he got a bigger part in the show.
The female sidekick in DW is married. To a geeky guy who doesn't look great but whom viewers love enough that he got a bigger part in the show.
The TW guy is called Rhys Williams.
The DW guy is called Rory Williams.
Is it me or... IS THERE A PATTERN?? :lol:
7949
Features / Re: New revs
« on September 4th, 2011, 08:22 PM »
rev 979
(15 files, 20kb)
* Rewrote the skin selector to move it from an obscure profile page to the main menu's profile area. Introduced a 'skin' action in the process, and defaulted to the current user if no 'u' variable is set. (index.php, Profile-Modify.php, Profile.php, Subs.php, Themes.php, Profile.language.php, Themes.language.php, Profile.template.php, Themes.template.php)
* Renamed the 'theme' profile page to 'options', which probably makes more sense. Added a couple of workarounds for custom fields that were set to be in 'theme'. I'd rather we deal with these in the import tool, though... (ManageMemberOptions.php, Profile-Modify.php, Profile.php, Admin.template.php)
+ Added commented out language strings for Ignore Topics in the English version. Yes, I know it's not implemented yet... But it was already in the French version and I'd rather we implement that before 1.0 Gold... (Profile.language.php)
rev 980
(5 files, 8kb)
! Fixed a minor bug with profile user IDs, introduced over 500 commits ago... Oops? Also avoided setting $_REQUEST early on, when it's going to be set in a batch a few lines later... (QueryString.php)
* Shortened declarations for the mandatory JS variables (we_default_theme_url, ajax_notification_*), because we can. Also optimized parent.clientWidth (called 3 times in the menu code) into a local var. (index.template.php, script.js)
! Safari Mobile for iOS didn't correctly position smileys. (index.iphone.css)
! Menu positioning issue in Wuthering skin. (Wuthering/index.css)
(15 files, 20kb)
* Rewrote the skin selector to move it from an obscure profile page to the main menu's profile area. Introduced a 'skin' action in the process, and defaulted to the current user if no 'u' variable is set. (index.php, Profile-Modify.php, Profile.php, Subs.php, Themes.php, Profile.language.php, Themes.language.php, Profile.template.php, Themes.template.php)
* Renamed the 'theme' profile page to 'options', which probably makes more sense. Added a couple of workarounds for custom fields that were set to be in 'theme'. I'd rather we deal with these in the import tool, though... (ManageMemberOptions.php, Profile-Modify.php, Profile.php, Admin.template.php)
+ Added commented out language strings for Ignore Topics in the English version. Yes, I know it's not implemented yet... But it was already in the French version and I'd rather we implement that before 1.0 Gold... (Profile.language.php)
Posted: September 4th, 2011, 08:21 PM
rev 980
(5 files, 8kb)
! Fixed a minor bug with profile user IDs, introduced over 500 commits ago... Oops? Also avoided setting $_REQUEST early on, when it's going to be set in a batch a few lines later... (QueryString.php)
* Shortened declarations for the mandatory JS variables (we_default_theme_url, ajax_notification_*), because we can. Also optimized parent.clientWidth (called 3 times in the menu code) into a local var. (index.template.php, script.js)
! Safari Mobile for iOS didn't correctly position smileys. (index.iphone.css)
! Menu positioning issue in Wuthering skin. (Wuthering/index.css)
7950
Archived fixes / Re: Remove nested quotes is broken
« on September 4th, 2011, 12:15 PM »
I didn't even know it didn't work in the first place... :^^;:
Interestingly, since you have SVN read access, go to /other/wip/Post-alt-quotes.php and have a look at my code... The code that will turn quotes into ">" prefixed lines uses that:
Code: [Select]
Code means (for the non-regex-experts): match a string starting with [ quote] or [ quote something], then anything that isn't "[/quote]" (that's the complicated code in the middle!), and then[/quote].
Which is pretty much what (?R) (aka recursive regex) will do (except that (?R) doesn't require removing the quote tags later to avoid matching them again, obviously...)
I try to avoid using (?R) these days because of the difficulties I had fixing the server crashes that Karl experienced on AEVAC... (Heck, I don't even know if recursive regex won't start failing if we end up removing the size limit on posts like Pete suggested this week...)
Anyway. I don't really know what's best...?
Try adding (?>...) in your recursive regex, BTW. You can find examples in Aeva-Embed.php...
Interestingly, since you have SVN read access, go to /other/wip/Post-alt-quotes.php and have a look at my code... The code that will turn quotes into ">" prefixed lines uses that:
while (preg_match_all('~\[quote(.*?)]((?:[^[]|\[(?!/?quote))+)\[/quote]~', $form_message, $matches))Code means (for the non-regex-experts): match a string starting with [ quote] or [ quote something], then anything that isn't "[/quote]" (that's the complicated code in the middle!), and then[/quote].
Which is pretty much what (?R) (aka recursive regex) will do (except that (?R) doesn't require removing the quote tags later to avoid matching them again, obviously...)
I try to avoid using (?R) these days because of the difficulties I had fixing the server crashes that Karl experienced on AEVAC... (Heck, I don't even know if recursive regex won't start failing if we end up removing the size limit on posts like Pete suggested this week...)
Anyway. I don't really know what's best...?
Try adding (?>...) in your recursive regex, BTW. You can find examples in Aeva-Embed.php...