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
4396
Features / Re: New revs
« on September 25th, 2012, 10:46 AM »
rev 1716
(2 files, 2kb)
! Fixed Wess functions width() and height(), and dynamic admin menu icons, to all accept direct URLs. (Class-CSS.php, Subs-Cache.php)
@ Tested on the Topic Solved plugin only... Hopefully works everywhere. Hey Pete, did you empty the error log recently here..? I thought it had 17 errors last I'd seen...
(2 files, 2kb)
! Fixed Wess functions width() and height(), and dynamic admin menu icons, to all accept direct URLs. (Class-CSS.php, Subs-Cache.php)
@ Tested on the Topic Solved plugin only... Hopefully works everywhere. Hey Pete, did you empty the error log recently here..? I thought it had 17 errors last I'd seen...
4397
Features / Re: New revs
« on September 25th, 2012, 10:27 AM »
rev 1715 -- variable tests!!
(5 files, 8kb)
+ Added support for variable tests. Surprisingly, I managed to implement variable tests into @is (inline ifs), in addition to my original target, @if. (Class-CSS.php, Subs-Cache.php)
@ Anyway -- this feature was a bit tricky to implement, and I'm not sure of its solidity although I spent many hours testing it. Don't try funny things with it, it just allows for basic boolean tests mostly for mixin use, so don't use quotes where not needed, and stick to ==, !=, <, >, and $var (true) and !$var (false) tests.
+ Allow for mixins to provide parameters without a default. It's the equivalent of setting it to '' (empty), really. (Class-CSS.php)
! Fixed multi-line mixins that were incorrectly indented when added through the 'mixes' keyword. (Class-CSS.php)
! Fixed passing parameters through the 'mixes' keyword, e.g. #id mixes mymixin ('hello, world!'). (Class-CSS.php)
* Updated the mixin sample to showcase the latest changes. (index.css)
* Minor CSS fixes/optimizations. (sections.css, Wuthering/extra.css)
(5 files, 8kb)
+ Added support for variable tests. Surprisingly, I managed to implement variable tests into @is (inline ifs), in addition to my original target, @if. (Class-CSS.php, Subs-Cache.php)
@ Anyway -- this feature was a bit tricky to implement, and I'm not sure of its solidity although I spent many hours testing it. Don't try funny things with it, it just allows for basic boolean tests mostly for mixin use, so don't use quotes where not needed, and stick to ==, !=, <, >, and $var (true) and !$var (false) tests.
+ Allow for mixins to provide parameters without a default. It's the equivalent of setting it to '' (empty), really. (Class-CSS.php)
! Fixed multi-line mixins that were incorrectly indented when added through the 'mixes' keyword. (Class-CSS.php)
! Fixed passing parameters through the 'mixes' keyword, e.g. #id mixes mymixin ('hello, world!'). (Class-CSS.php)
* Updated the mixin sample to showcase the latest changes. (index.css)
* Minor CSS fixes/optimizations. (sections.css, Wuthering/extra.css)
4398
Features / Re: New revs
« on September 24th, 2012, 06:24 PM »
rev 1714
(2 files, 3kb)
+ Added support for @elseif in @if/@else/@endif statements in Wess. Basically, just like in any other high-level language, you can add any number of @elseif on the same tab level, but only one @else, and it has to be at the end (or not there at all). (Class-CSS.php)
! Because of the way 'content: "string"' was handled, having one inside an @if block could screw up the final outputted content. I'm afraid the fix is a bit slower than before, but I'd rather not take my chances. The same problem exists for protected comments, but there's absolutely no reason to have them inside @if blocks, so no time to waste on that. (Class-CSS.php)
(2 files, 3kb)
+ Added support for @elseif in @if/@else/@endif statements in Wess. Basically, just like in any other high-level language, you can add any number of @elseif on the same tab level, but only one @else, and it has to be at the end (or not there at all). (Class-CSS.php)
! Because of the way 'content: "string"' was handled, having one inside an @if block could screw up the final outputted content. I'm afraid the fix is a bit slower than before, but I'd rather not take my chances. The same problem exists for protected comments, but there's absolutely no reason to have them inside @if blocks, so no time to waste on that. (Class-CSS.php)
4399
Features / Re: New revs
« on September 24th, 2012, 06:23 PM »
rev 1713
(2 files, 1kb)
+ Added $head_font_style variable to enable skins to easily change the font style (or weight...) without changing anything else. Maybe I should do that everywhere uh...? (index.css)
* Minor improvements to Wuthering. (Wuthering/extra.css)
(2 files, 1kb)
+ Added $head_font_style variable to enable skins to easily change the font style (or weight...) without changing anything else. Maybe I should do that everywhere uh...? (index.css)
* Minor improvements to Wuthering. (Wuthering/extra.css)
4400
Features / Re: New revs - Public comments
« on September 24th, 2012, 02:43 PM »
It feels overwhelming, which is way better than feeling bored :P
4401
Archived fixes / Re: SMF bug 4913 (convert fopen/fwrite to file_put_contents)
« on September 24th, 2012, 02:41 PM »
Hey, a good opportunity to try that Topic Solved plugin... :lol:
4402
Features / Re: New revs - Public comments
« on September 24th, 2012, 12:14 PM »
Oh, yes I see... So just forget about what I said :) I just did a quick search in case you'd forgotten something etc, like I enjoy doing... It's like a morning walk you know. Getting back into the game with checking out your commits, things like that, ain't done this in a few months, a pleasure to do :eheh:
4403
Features / Re: New revs
« on September 24th, 2012, 10:12 AM »
rev 1711 -- because I really should be committing smaller updates instead of mindlessly packing everything together...
(2 files, 1kb)
* id_post_group is always going to be unsigned... Make it clear in the DB. (install.sql)
* Added a comment for help icons. Just saying how to replace them with a clean HTML entity... Not that I'm going to ship it by default. By I'll consider it for my own sites. (sections.css)
(2 files, 1kb)
* id_post_group is always going to be unsigned... Make it clear in the DB. (install.sql)
* Added a comment for help icons. Just saying how to replace them with a clean HTML entity... Not that I'm going to ship it by default. By I'll consider it for my own sites. (sections.css)
4404
Features / Re: New revs
« on September 24th, 2012, 10:05 AM »
rev 1710
(1 file, forgot to see the size)
* Reverted id_group database size to smallint(5) signed instead of mediumint(8) unsigned. This is mainly because I've decided to use contact lists for privacy, instead of custom membergroups, so in the end we should have no need for high IDs for membergroups. Probably to keep it in style with the SMF changelogs. (install.sql)
! Fixed member blurbs holding broken HTML by at least temporarily setting them to a size of 500 instead of 255. I know, it takes an extra byte in the database... But hey, I just saved one by reverting the id_group size, so don't complain too much! (install.sql)
* Renamed the (unused) thought_privacy table to privacy_thought, and added privacy_boards and privacy_topics tables as well. Their structure is only temporary -- privacy_id should probably be signed, and boards don't need a 'group' privacy type, but whatever... At least it's committed somewhere and it can be changed as long as it's not implemented, can't it..? (install.sql)
@ Starting from now, I'll be adding more whitespace to SVN logs, just like in the wedge.org topic... I'm not exactly sure why I kept it tight for so long.
(1 file, forgot to see the size)
* Reverted id_group database size to smallint(5) signed instead of mediumint(8) unsigned. This is mainly because I've decided to use contact lists for privacy, instead of custom membergroups, so in the end we should have no need for high IDs for membergroups. Probably to keep it in style with the SMF changelogs. (install.sql)
! Fixed member blurbs holding broken HTML by at least temporarily setting them to a size of 500 instead of 255. I know, it takes an extra byte in the database... But hey, I just saved one by reverting the id_group size, so don't complain too much! (install.sql)
* Renamed the (unused) thought_privacy table to privacy_thought, and added privacy_boards and privacy_topics tables as well. Their structure is only temporary -- privacy_id should probably be signed, and boards don't need a 'group' privacy type, but whatever... At least it's committed somewhere and it can be changed as long as it's not implemented, can't it..? (install.sql)
@ Starting from now, I'll be adding more whitespace to SVN logs, just like in the wedge.org topic... I'm not exactly sure why I kept it tight for so long.
4405
Features / Re: New revs
« on September 24th, 2012, 09:48 AM »
rev 1709 -- easy to revert in case I change my mind for common.css... :)
(8 files, 2kb)
- Stopped including automatically common.css to all CSS cached files, just in case one would include a file in regular CSS format. (I'm committed to keep supporting these for plugins and custom themes, although I haven't tested this format in a long while...) You will now have to explicitly add 'common' to the array of files you're loading in case you want to use one of its virtuals (.inline-block, .clearfix etc.) Or just copy the virtuals into your own file, it's exactly the same to me... (Admin.php, Class-Editor.php, Packages.template.php -- yes, I know this one will end up being deleted...)
* Spacinazi. Thanks Pete for that reminder... (index.css)
* Translation. (ManagePlugins.french.php)
(8 files, 2kb)
- Stopped including automatically common.css to all CSS cached files, just in case one would include a file in regular CSS format. (I'm committed to keep supporting these for plugins and custom themes, although I haven't tested this format in a long while...) You will now have to explicitly add 'common' to the array of files you're loading in case you want to use one of its virtuals (.inline-block, .clearfix etc.) Or just copy the virtuals into your own file, it's exactly the same to me... (Admin.php, Class-Editor.php, Packages.template.php -- yes, I know this one will end up being deleted...)
* Spacinazi. Thanks Pete for that reminder... (index.css)
* Translation. (ManagePlugins.french.php)
4406
Features / Re: New revs - Public comments
« on September 24th, 2012, 09:37 AM »
Duplicate removal in language files: awesome :) Something I couldn't be arsed to start doing...
I think it's a good idea to turn pseudo-buttons into proper buttons, I think the point of pseudo-buttons is that people can open them in new windows or something, but really it's not that interesting and it's best to have a coherent interface.
If you look for this string in the Sources and Themes folder, you'll find more buttons that can (should?) be converted: "[<a "
I think it's a good idea to turn pseudo-buttons into proper buttons, I think the point of pseudo-buttons is that people can open them in new windows or something, but really it's not that interesting and it's best to have a coherent interface.
If you look for this string in the Sources and Themes folder, you'll find more buttons that can (should?) be converted: "[<a "
4407
The Pub / Re: Language editing inside Wedge
« on September 24th, 2012, 09:31 AM »No, this was more of a 'this is what I think we could do' and wanting comments before I wrote it.
Oh..... so you load the index file, pull the $txt entries out and inject that into the result file that then gets cached. Now it makes sense to me.
And now I understand the concern about language files and caching. There's one entire class of cases that's screwed up in passing - plugins. While we could check the core files for updates, and force those ones to be updated from the ACP, we can't do the same with plugins. There are no requirements about where plugins must keep their files, so unless we were to go through every folder of every active plugin, looking for .js files, just to look for @language directives, we can't do that.
If we see a plugin language file as updated, we empty the JS cache folder... (clean_cache('js'), once again.)
The alternative is to simply nuke the cache when doing such an update and immediately rebuilding the most common (script, editor, topic) if affected and let the others rebuild on demand.
That's the beauty of it. It always does a file_exists before including the file. And it's fast enough that we don't have to worry about it. (CSS caching might be more of a problem, with the number of files, even though I've deleted a lot recently. It's still worth considering caching the filedates for a couple of minutes each time.)
Oh, slightly unrelated: I've decided to stop including common.css in all files. The only reason is that I forgot how Wess still supposedly supports the { } syntax, but not in mixed situations, so there's no point in adding a tabbed file to a bracketed file.
The alternative would be to do the bracket conversion on every file each at a time, rather than everything together, but back then I'd calculated it would be noticeably slower, or maybe not but I decided against it, I don't remember if it was a technical issue though...
Would you like me to look into it and maybe add supporting for mixing different CSS file types..? I don't think it's that necessary.
I'm a stuck in the mud who uses one at a time mode, so it's very clear. I can post a screenshot if that'd help?
4408
Features / Re: Things to do before the Mayan apocalypse: membergroups
« on September 24th, 2012, 12:22 AM »
Okay, looks like a 'go ahead' sign for me :P
(Plus, we get to reset id_group back to a smallint(5)!)
Posted: September 24th, 2012, 12:20 AM
(Plus, we get to reset id_group back to a smallint(5)!)
4409
Off-topic / Re: Doctor Who
« on September 24th, 2012, 12:19 AM »
Hmm, but the 'hologram' is still a potential threat... The Doctor didn't seem to convince him otherwise ;)
Ah, time for bed...
Ah, time for bed...
4410
The Pub / Re: Language editing inside Wedge
« on September 24th, 2012, 12:18 AM »You're not too thorough with the three states. The reason I don't use notenice in the menu is simply because the green doesn't sit well in the menu when it's the active menu item. To replicate, make sure you have an unread PM that won't be marked read when you're on action=pm, then go to action=pm, so there's at least a (1) still present, and you'll see that green just doesn't sit nicely because of a lack of contrast. But it's more prominent on the menu.
Then you started talking about @language also referring to multiple language files... which seems unnecessary to me.
No, we don't. That's the underlying point of what I've been saying. If you have the files as-is and the database containing deltas, you do not need to worry about file dates, because you just cache it whenever the database changes.
Is it already written? I suppose not? What do we do in the meantime? (Because the code is already written, I'd simply postponed the language caching test code...)
And if you know what files are changed you can safely just regenerate only the file that's changed, just when it's changed, job done.
I'm thoroughly confused. Are you saying that you want to push the entirety of a language file into a JS construct so they can be used client side?Quote - Imagine that script.js uses @language ManageTopics, and the admin never actually visits the admin area... It means the script file never gets updated, even if the corresponding language file is updated. It's unlikely, but still...?
Okay, here's the beginning of the script.js file:
@language index;
var
oThought,
weEditors = [],
_formSubmitted = false,
we_loading = $txt['ajax_in_progress'],
we_cancel = $txt['form_cancel'],
we_delete = $txt['delete'],
we_submit = $txt['form_submit'],
we_ok = $txt['ok'],See what I mean..?
I'm simply going to go through all $txt insertions in HTML files, and move them to the scripts themselves. It'll be mostly helpful in editor.js, because it's on many pages... Heck, maybe we could even cache stuff like the button list etc :P
Better would simply be to find all the strings that are actually needed from JS and make a single file out of those which can be included as standard along with script.js. Then you get to simplify a lot of the architecture.