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
5101
The Pub / Re: The Cookie Law (in the UK at least)
« on May 25th, 2012, 01:12 PM »
Probably the case yeah.
But then again -- my latest Opera (a relatively fresh install) has the umtc stuff in my cookie list for wedge.org, even though, well, you can't say it's an old install of Opera... Right?
But then again -- my latest Opera (a relatively fresh install) has the umtc stuff in my cookie list for wedge.org, even though, well, you can't say it's an old install of Opera... Right?
5102
Features / Re: New revs
« on May 25th, 2012, 11:35 AM »
rev 1595
(12 files, 8kb)
* Rewrote some parts of the quick edit JS and HTML to simplify and shorten them. The HTML no longer needs to specify fallback templates. Error CSS is no longer hardcoded. Topic pages no longer need to specify the topic ID when calling a function -- the index template automatically specifies a we_topic variable when current_topic is set. Error message XML now specifies the target ID directly instead of asking JS to second-guess it. Etc. Overall, saved over 110 bytes in topic.js alone. (Display.template.php, index.template.php, topic.js, index.member.css)
* SMF bug: the topic ID is specified in both GET and POST when submitting a quick edit through Ajax. I can only confirm that it's fine not specifying the topic ID into the HTML form at all... (Display.template.php, topic.js)
* SMF bug: $context['message']['error_in_body'] was sent through cleanXml() even though it was just a boolean test... (Xml.template.php)
* SMF bug: modifytopicdone is never called when errors are found (it redirects to modifydone instead), so it doesn't need to test for errors. (Xml.template.php)
* Simplified various Aeva embedding methods. Flash will no longer show a codebase (it was the old Macromedia URL, and Adobe themselves don't seem to advocate for a codebase in the HTML), as well as WMP -- because it actually points to a 404! Well done, Microsoft... (Aeva-Embed.php)
* Renamed admin.css (admin area's CSS file) to mana.css, to avoid confusion with the 'admin' suffix for CSS files (used to keep a CSS file to administrators). 'Mana' is short for 'Manage', and it also justifies its use in the Moderation center, but it really is the RPG fan trying to justify the name change, ah ah. (Admin.php, ModerationCenter.php, admin.css, Packages.template.php -- when are we removing that file already, Pete? :P)
(12 files, 8kb)
* Rewrote some parts of the quick edit JS and HTML to simplify and shorten them. The HTML no longer needs to specify fallback templates. Error CSS is no longer hardcoded. Topic pages no longer need to specify the topic ID when calling a function -- the index template automatically specifies a we_topic variable when current_topic is set. Error message XML now specifies the target ID directly instead of asking JS to second-guess it. Etc. Overall, saved over 110 bytes in topic.js alone. (Display.template.php, index.template.php, topic.js, index.member.css)
* SMF bug: the topic ID is specified in both GET and POST when submitting a quick edit through Ajax. I can only confirm that it's fine not specifying the topic ID into the HTML form at all... (Display.template.php, topic.js)
* SMF bug: $context['message']['error_in_body'] was sent through cleanXml() even though it was just a boolean test... (Xml.template.php)
* SMF bug: modifytopicdone is never called when errors are found (it redirects to modifydone instead), so it doesn't need to test for errors. (Xml.template.php)
* Simplified various Aeva embedding methods. Flash will no longer show a codebase (it was the old Macromedia URL, and Adobe themselves don't seem to advocate for a codebase in the HTML), as well as WMP -- because it actually points to a 404! Well done, Microsoft... (Aeva-Embed.php)
* Renamed admin.css (admin area's CSS file) to mana.css, to avoid confusion with the 'admin' suffix for CSS files (used to keep a CSS file to administrators). 'Mana' is short for 'Manage', and it also justifies its use in the Moderation center, but it really is the RPG fan trying to justify the name change, ah ah. (Admin.php, ModerationCenter.php, admin.css, Packages.template.php -- when are we removing that file already, Pete? :P)
5103
The Pub / Re: The Cookie Law (in the UK at least)
« on May 25th, 2012, 08:22 AM »
Err... Since when do we have GA code in Wedge anyway? :lol:
The only thing I don't understand is that I regularly get GA cookies in Opera on my Wedge.org tabs, and I don't have GA anywhere on Wedge.org, so where does that come from..?!
The only thing I don't understand is that I regularly get GA cookies in Opera on my Wedge.org tabs, and I don't have GA anywhere on Wedge.org, so where does that come from..?!
5104
Features / Re: Thought system
« on May 24th, 2012, 11:32 PM »
Okay, so it's not ready for use on Wedge.org but I decided to throw away the thought list on profile pages -- never intended to keep this because it created huge pages and was a bit buggy.
So, here's how it'll be done now:
- The homepage lists the latest thoughts, like now.
- The author link will point to their actual profile, not their profile page's thought list
- There's a new mini-icon next to the thought date. Follow it to reach the thought thread page.
The thought thread is basically all thoughts gathered under the same id_master, i.e. any thought that sprang as a reply to a single thought.
It can create a page with one thought, or a page with several dozens -- although it's very unlikely.
The profile pages will now list only the author's thoughts -- without any contextual thoughts around them, split by pages, and accompanied by a link to the corresponding thought thread.
Although it makes it a bit 'harder' to follow someone's thoughts in context, I think it's definitely the better way to show thought lists. Really... (Plus, it makes the code a bit simpler.)
PS: I also fixed several minor bugs today, in case you didn't notice on wedge.org, eheh...
PPS: that quick edit animation looks really neat... I think it'll take more than a week for me to get bored of it :P
So, here's how it'll be done now:
- The homepage lists the latest thoughts, like now.
- The author link will point to their actual profile, not their profile page's thought list
- There's a new mini-icon next to the thought date. Follow it to reach the thought thread page.
The thought thread is basically all thoughts gathered under the same id_master, i.e. any thought that sprang as a reply to a single thought.
It can create a page with one thought, or a page with several dozens -- although it's very unlikely.
The profile pages will now list only the author's thoughts -- without any contextual thoughts around them, split by pages, and accompanied by a link to the corresponding thought thread.
Although it makes it a bit 'harder' to follow someone's thoughts in context, I think it's definitely the better way to show thought lists. Really... (Plus, it makes the code a bit simpler.)
PS: I also fixed several minor bugs today, in case you didn't notice on wedge.org, eheh...
PPS: that quick edit animation looks really neat... I think it'll take more than a week for me to get bored of it :P
5105
Features / Re: New revs
« on May 24th, 2012, 06:35 PM »
rev 1594
(5 files, 4kb)
! Partly reverted my latest optimization, because it sucked and was buggy. Well, so what? I still saved a few bytes. (script.js)
* Added a 'Thought deleted' mention in case a thought was in reply to a... well, a thought that was deleted. (Home.php, Welcome.php, Post.language.php)
@ The profile version needs a rewrite. I'm currently putting it into its own page, where a thread will have a specify ID not linked to the owner. Heck, much better that way...
(5 files, 4kb)
! Partly reverted my latest optimization, because it sucked and was buggy. Well, so what? I still saved a few bytes. (script.js)
* Added a 'Thought deleted' mention in case a thought was in reply to a... well, a thought that was deleted. (Home.php, Welcome.php, Post.language.php)
@ The profile version needs a rewrite. I'm currently putting it into its own page, where a thread will have a specify ID not linked to the owner. Heck, much better that way...
5106
Features / Re: New revs
« on May 24th, 2012, 05:05 PM »
rev 1593
(9 files, 3kb)
* Simplified and shortened HTML for main and mini menus by moving the top arrow to a pseudo class, and doing some internal data analysis to avoid using an HTML id on mini-menus. Renamed .mimenuitem to .mimeitem for consistency. (Display.template.php, script.js, index.css, index.ie6.css, index.ie7.css, sections.css, Warm/index.css, Wireless/sections.iphone.css)
* Optimized a dozen more bytes out of the thought function... Oh well, you know how I am. (script.js)
(9 files, 3kb)
* Simplified and shortened HTML for main and mini menus by moving the top arrow to a pseudo class, and doing some internal data analysis to avoid using an HTML id on mini-menus. Renamed .mimenuitem to .mimeitem for consistency. (Display.template.php, script.js, index.css, index.ie6.css, index.ie7.css, sections.css, Warm/index.css, Wireless/sections.iphone.css)
* Optimized a dozen more bytes out of the thought function... Oh well, you know how I am. (script.js)
5107
Features / Re: New revs
« on May 24th, 2012, 04:44 PM »
rev 1592
(7 files, 8kb)
+ Thought replies finally get to be shown without this dreaded 'Reload to interact' warning. Need to apply this to the Welcome template, uh... (Ajax.php, Home.template.php, Post.language.php, script.js)
* Sort selector lists before generating the CSS files. This helps a bit with overall gzip compression rates. (Class-CSS.php)
! Member-only thoughts weren't shown to anyone in profile pages. (Profile-View.php)
(7 files, 8kb)
+ Thought replies finally get to be shown without this dreaded 'Reload to interact' warning. Need to apply this to the Welcome template, uh... (Ajax.php, Home.template.php, Post.language.php, script.js)
* Sort selector lists before generating the CSS files. This helps a bit with overall gzip compression rates. (Class-CSS.php)
! Member-only thoughts weren't shown to anyone in profile pages. (Profile-View.php)
5108
Features / Re: Rewriting the skin file parser...
« on May 24th, 2012, 02:41 PM »mana.css is absolutely fine,
and I love the idea of board and category CSS - not quite so keen on m1.css, but I'm sure it'll have use.
I really like the idea of using the replace.css and I can see the benefits of it simplifying add vs replace skins. Would it be faster to drop add/replace skin types and rely on the keyword?
skin.xml has many options, but the skin type is the option regarding CSS files and their ordering. It feels more natural to have this put into the file names themselves.
However, people may get confused with where to put the replace suffix... And even I don't know to which extent they should be applied. For instance, should they put it into every available file? index.replace.css + index.replace,ie6.css -- currently, Wedge doesn't need that because it will delete any index.*.css file if a replace suffix is found on any index.*.css file. But what if they only provide an index.replace,ie6.css file into their skin folder? Now that's an issue... It'd logically mean, "keep the parent index.css and everything, but replace the index.ie6.css with mine". I guess if I had to implement this, I'd need to add even more extra code to Wedge so that it goes through the parent list and removes only those files with suffixes found in our list (in this case, ie6). Meh. OTOH it also gives more flexibility than replace-type skins. But it also introduces a potential complexity that could scare themers away.
All in all, for now I'll be keeping the replace type, but I'd like more opinions on this.
5109
Features / Re: New WYSIWYG editor..?
« on May 24th, 2012, 02:32 PM »Is BBcode support a priority?
People may be coming from SMF or other forum backgrounds -- having to use HTML, even if simple stuff, could be a no-no to them. For instance, one of the most popular tags, 'quote'... How do you write it in HTML? If you want to use proper HTML, then it's going to be fun... Multiple divs and all. If you want to be able to switch between HTML and Wysiwyg without conversions, it's necessary to use the exact same HTML code, which would end up being too detrimental to Wedge I'd say. Of course, we could also simplify the HTML and use something like <q data-author="Nao" data-date="1234342457">, but it means we'd need to convert the data fields to HTML through JavaScript. I actually toyed with the idea some time ago, but I simply couldn't do with the delay before the author and date would show up, so I gave up on that. Maybe in a few years time, when everyone has a strong machine and powerful browser, I don't know... But I don't know that the world is ready for that (yet).
So, of course we could simply use these tags in HTML mode and convert them internally to the long-form HTML when switching to Wysiwyg, but then we could just as well support the same in BBCode...!
I'd be happy without it at all. It seems like the modern way forward would be to have afull WYSIWYG editor that fell back to simple HTML. WSYIWG editing would be the default with a fall back to "view/edit" the source as HTML. Not only would the content be richer, but it would make it easier to cut and paste web clips or content from a full HTML editing application into the editing window.
b.t.w. Off Topic: I'm floored by the work you're doing here. I can't wait until wedge is ready for general use!
5110
Features / Re: Rewriting the skin file parser...
« on May 24th, 2012, 10:34 AM »
I think it's a bit too long for my taste...
What about mana.css? :P
It's like 'manage', but it pleases my RPG-addicted mischievous mind :lol:
Oh, also... Today I added support for:
- *.b1.css -> custom css for board #1
- *.c1.css -> category #1
- *.m1.css -> member #1 (no more annoying you with my tests :P)
- *.replace.css -> a new idea of mine... It basically acts like a local replace-type skin, for one radix type.
e.g. Wine was broken because it included custom.css from its parent skin, which was geared towards modifying Weaving, not Wine. So I added an empty custom.replace.css file in the Wine folder and voilà -- all custom.*.css files from Weaving are subsequently ignored.
What I like about my skin system is that I actually use it. Thus, when I meet a new problem, I try to find an innovative solution to it.
Heck, I could even get away with removing skin types entirely, and relying on the 'replace' keyword everytime it's needed... What do you think? I can't think of a situation where a global replace type would be better.
What about mana.css? :P
It's like 'manage', but it pleases my RPG-addicted mischievous mind :lol:
Oh, also... Today I added support for:
- *.b1.css -> custom css for board #1
- *.c1.css -> category #1
- *.m1.css -> member #1 (no more annoying you with my tests :P)
- *.replace.css -> a new idea of mine... It basically acts like a local replace-type skin, for one radix type.
e.g. Wine was broken because it included custom.css from its parent skin, which was geared towards modifying Weaving, not Wine. So I added an empty custom.replace.css file in the Wine folder and voilà -- all custom.*.css files from Weaving are subsequently ignored.
What I like about my skin system is that I actually use it. Thus, when I meet a new problem, I try to find an innovative solution to it.
Heck, I could even get away with removing skin types entirely, and relying on the 'replace' keyword everytime it's needed... What do you think? I can't think of a situation where a global replace type would be better.
5111
Features / Re: Rewriting the skin file parser...
« on May 23rd, 2012, 09:51 PM »
I did... Although I thought it was another parser bug, which turned out to be working fine...
(Except that Wine is seriously broken right now. Hmm, when did that start...? I'll have to fix it again. Maybe I'll use the opportunity to rewrite the sidebar to behave like in Weaving, because I've really grown tired of that nice little animation -- it doesn't work on touch devices, for starters...)
I think I've fixed everything...
Changed a lot of things internally, really.
I have no idea whether it's for the better. It's certainly a bit slower, whether it be the per-page file check, or the actual parsing (I now do some extra sorting on selector lists), but I did notice a minor improvement in CSS file size reduction, plus there's the added flexibility of using multiple suffixes...
Now I shouldn't forget about implementing per-member suffixes, and maybe other things... What about per-board and per-category suffixes, for instance? (A different skin can be chosen for another board, but this would allow having custom CSS in a single board across *all* possible skins for it...)
One thing I don't know about, though, is the 'admin' suffix (i.e. custom CSS for admins). That's because there's also an 'admin' radix (base?), which is used in the admin area... (the classic admin.css file.)
I'd like to change that, but I don't know what to, and I don't know if I should rename the radix or the suffix.
(Except that Wine is seriously broken right now. Hmm, when did that start...? I'll have to fix it again. Maybe I'll use the opportunity to rewrite the sidebar to behave like in Weaving, because I've really grown tired of that nice little animation -- it doesn't work on touch devices, for starters...)
Posted: May 23rd, 2012, 08:34 PM
I think I've fixed everything...
Changed a lot of things internally, really.
I have no idea whether it's for the better. It's certainly a bit slower, whether it be the per-page file check, or the actual parsing (I now do some extra sorting on selector lists), but I did notice a minor improvement in CSS file size reduction, plus there's the added flexibility of using multiple suffixes...
Now I shouldn't forget about implementing per-member suffixes, and maybe other things... What about per-board and per-category suffixes, for instance? (A different skin can be chosen for another board, but this would allow having custom CSS in a single board across *all* possible skins for it...)
One thing I don't know about, though, is the 'admin' suffix (i.e. custom CSS for admins). That's because there's also an 'admin' radix (base?), which is used in the admin area... (the classic admin.css file.)
I'd like to change that, but I don't know what to, and I don't know if I should rename the radix or the suffix.
5112
Features / Re: Rewriting the skin file parser...
« on May 23rd, 2012, 07:16 PM »
Oh, the Wireless skin was broken because of a test file I'd uploaded to stress-test the inheritance mechanism and forgot to remove when I was done... Sorry about that.
Will no one report that kind of issue when it's been going on for at least a few hours? :P
Will no one report that kind of issue when it's been going on for at least a few hours? :P
5113
Features / Re: Disable animation on mobile devices
« on May 23rd, 2012, 12:37 PM »
Ah, at last I'm back up...
Lasted for a little over an hour. :(
Lasted for a little over an hour. :(
5114
Features / Re: Disable animation on mobile devices
« on May 23rd, 2012, 11:46 AM »
And in chrome?
WTF electrical power is down in my neighborhood and it looks like it's gonna last got a while... Right when I was back in business after a hectic morning outside.... >_<
WTF electrical power is down in my neighborhood and it looks like it's gonna last got a while... Right when I was back in business after a hectic morning outside.... >_<
5115
Features / Re: Rewriting the skin file parser...
« on May 22nd, 2012, 07:09 PM »
Seems to be working, now :)