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
3076
Features / Re: New revs
« on May 4th, 2013, 10:19 AM »
rev 2087 -- a few things before the oncoming storm...
(4 files, 3kb)
! Fixed JS not correctly updating the number of notifications in the header, when marking an item as read or receiving new notifications. (script.js)
! Fixed thought reply process hiding the parent thought, instead of showing the form next to it. (script.js)
! Fixed this annoying bug I used to get in the error log, with popups not showing up despite the screen being dimmed. This was apparently due to $(window).height() returning a huge value, probably the equivalent of the body height, and thus showing the popup below the visible viewport. I fixed this by using window.innerHeight instead, but it's less precise because it includes horizontal scrollbars (if there are any, which is unlikely, but meh.) Used screen.height as a limiter instead, so it should at least make the popup accessible, at worst by maximizing your window if it's not already maximized. Feedback welcome... (script.js)
* Only show Mark Read buttons on unread notifications, duh... (Notifications.template.php)
* French translation. (ManageBans, ManageBoards)
Note to Pete: perhaps you never noticed (it took me a while to see it, as it was a new TortoiseSVN feature in 1.7 or something), but you *can* edit your SVN changelogs now, even the old ones... :)
(4 files, 3kb)
! Fixed JS not correctly updating the number of notifications in the header, when marking an item as read or receiving new notifications. (script.js)
! Fixed thought reply process hiding the parent thought, instead of showing the form next to it. (script.js)
! Fixed this annoying bug I used to get in the error log, with popups not showing up despite the screen being dimmed. This was apparently due to $(window).height() returning a huge value, probably the equivalent of the body height, and thus showing the popup below the visible viewport. I fixed this by using window.innerHeight instead, but it's less precise because it includes horizontal scrollbars (if there are any, which is unlikely, but meh.) Used screen.height as a limiter instead, so it should at least make the popup accessible, at worst by maximizing your window if it's not already maximized. Feedback welcome... (script.js)
* Only show Mark Read buttons on unread notifications, duh... (Notifications.template.php)
* French translation. (ManageBans, ManageBoards)
Note to Pete: perhaps you never noticed (it took me a while to see it, as it was a new TortoiseSVN feature in 1.7 or something), but you *can* edit your SVN changelogs now, even the old ones... :)
3077
Features: Theming / Re: CSS caching
« on May 4th, 2013, 12:24 AM »
Found bug over bug while documenting for the changelog... Impressive.
In the end, the current rewrite is very different from the one I originally planned to commit today... Uh.
And it's still buggy. >_<
For instance, a negative test currently returns an incorrect value, and I don't even know how to deal with that... (I understand the logic of what I was trying to do; I understand the logic of where it fails; I just don't understand how to do it in a way that it doesn't fail.)
Note for later: if it seems like an easy change in Wess, DON'T DO IT. Even if the current product is buggy, as long as you don't see it, it's alright! :P
Well, at least now I've got 'b1' properly working inside CSS files, as I was trying to do...
In the end, the current rewrite is very different from the one I originally planned to commit today... Uh.
And it's still buggy. >_<
For instance, a negative test currently returns an incorrect value, and I don't even know how to deal with that... (I understand the logic of what I was trying to do; I understand the logic of where it fails; I just don't understand how to do it in a way that it doesn't fail.)
Note for later: if it seems like an easy change in Wess, DON'T DO IT. Even if the current product is buggy, as long as you don't see it, it's alright! :P
Well, at least now I've got 'b1' properly working inside CSS files, as I was trying to do...
3078
Features: Theming / Re: CSS caching
« on May 3rd, 2013, 06:08 PM »
I'll commit as is, then, and re-think about it later...
3079
Features: Theming / Re: CSS caching
« on May 3rd, 2013, 04:33 PM »At least, not intentionally ;)
That's why the infractions system has been driving me mad, because it's not like I can deploy any of it and leave here without a functional warning system. Though, fortunately, we haven't had to use it much anyway (but you just know that if I broke it here, we'd end up having to warn people and stuff)
Oh... And now for a bug I just found out... The local keyword. :-/
skins/index.local.css
skins/sub-skin/index.local.css
When compiling the default skin, the first file will be added to it. When compiling the sub-skin, the first file will be ignored, and the second one will be added to it. In short: 'local' means that the code should only be included in we're in the right folder; it's important for sub-skins of the 'replace' type.
Now, if I use "@if local" inside a CSS file, I would expect it to do the same: ignore the block if it's within a CSS file that's not part of the sub-skin's folder...
And 'oops': CSS file contents is only analyzed after loading them back to back, in hierarchy order. There's no way, currently, to know 'where' we are... The only keyword that supports is is $here, and it's only because I've added some special code for it...
So, how do I keep track of where @if local is called from...?
- Just like $here, I could do a test on the contents of the current file, and turn all 'local' keywords to 'global' if we're within the right folder, or to '!global' if we're not... That seems like the best solution, but I'm wary of changing anything that can affect regular CSS... For instead, "background-attachment: local", while not used in Wedge, would get broken. Then, err... Does that mean changing '!global' or whatever back to 'local' once all variables are tested against...?
- Just tell people not to use the local keyword inside CSS files..?! But part of my rewrite, was specifically to merge suffixes and keywords together, so... :-/
- Add some keywords at the beginning and end of each file, something like <file="..."> </file>, indicating where we're in; this can also be used by $here to determine the folder, instead of using our special code. However, that one might be slower to parse, I guess..?
- Something else..?
3080
Features: Theming / Re: CSS caching
« on May 3rd, 2013, 04:15 PM »Course you can, how often do I do that, after all? ;)Quote Can I commit "as is", and deal with plugins later..?
3081
Off-topic / Re: The sites looking
« on May 3rd, 2013, 03:41 PM »
I didn't read it like that, but whatever... Probably because I'm in the eye of the storm... :lol:
3082
The Pub / Re: Alphas Publicly Accessible
« on May 3rd, 2013, 03:39 PM »
Yeah, it's not a problem that other sites are using Wedge, for testing purposes...
The only thing I'm not comfortable with, is seeing it used in production environments; mostly because it always makes it a bit harder to update, and I wouldn't like to see outdated versions around too much, eh...!
The only thing I'm not comfortable with, is seeing it used in production environments; mostly because it always makes it a bit harder to update, and I wouldn't like to see outdated versions around too much, eh...!
3083
Features: Theming / Re: CSS caching
« on May 3rd, 2013, 03:37 PM »
Okay, I'm pretty done with the caching rewrite, but I'm not even started with the plugin caching rewrite. It will still work *if you don't use tests or suffixes in their CSS files*, so I've just got a question... Can I commit "as is", and deal with plugins later..?
Also, I'm seriously considering removing the 'replace' suffix entirely, for at least two reasons: it doesn't make sense at all inside an @if test (although it's the same for the 'global' keyword, but I can always remove that one later as it really is the equivalent of 'true' and should only be used for clarity reasons...), and even as a suffix, it's still handled separately from the other suffixes, which I'm not too thrilled about...
I'm not going to ask for opinions on this one, though, as it's likely that it's all about difficulty of implementation, for me, rather than whether or not it's a welcome/useful keyword...
Also, I'm seriously considering removing the 'replace' suffix entirely, for at least two reasons: it doesn't make sense at all inside an @if test (although it's the same for the 'global' keyword, but I can always remove that one later as it really is the equivalent of 'true' and should only be used for clarity reasons...), and even as a suffix, it's still handled separately from the other suffixes, which I'm not too thrilled about...
I'm not going to ask for opinions on this one, though, as it's likely that it's all about difficulty of implementation, for me, rather than whether or not it's a welcome/useful keyword...
3084
Features: Theming / Re: CSS caching
« on May 3rd, 2013, 08:08 AM »
If you ate using we::is for browser testing, there are no changes involved.
Also, we::$user['is_mod'] becomes we::$is['mod'] or of course we::is('mod').
Also, we::$user['is_mod'] becomes we::$is['mod'] or of course we::is('mod').
3085
Features: Theming / Re: CSS caching
« on May 3rd, 2013, 12:05 AM »
My semi-final code, as surprising as it is to me, IS actually less complex than the original one...!
Class-CSS: 10 more bytes... Not much!
Class-System: 10 more bytes, too...!
Subs-Cache: 600+ bytes LESS!
Load: 2000+ bytes LESS!
Yay... :) Just need to rewrite the plugin-related code though, I'll probably have to 'forbid' use of file suffixes for them, and only allow for @if tests, which I'm assuming to be just fine! All right..?
Plus, I'm finished with Fringe. Nice final episodes! Was a pretty good show, in the end...
Class-CSS: 10 more bytes... Not much!
Class-System: 10 more bytes, too...!
Subs-Cache: 600+ bytes LESS!
Load: 2000+ bytes LESS!
Yay... :) Just need to rewrite the plugin-related code though, I'll probably have to 'forbid' use of file suffixes for them, and only allow for @if tests, which I'm assuming to be just fine! All right..?
Plus, I'm finished with Fringe. Nice final episodes! Was a pretty good show, in the end...
3086
Features: Theming / Re: CSS caching
« on May 2nd, 2013, 08:28 PM »
And... All working :)
Not only that, but it seems that up until now, the b1 keyword never worked to target a board, because the keyword wasn't generated in the first place, ah ah... Needed to be done in loadBoard(), which is executed AFTER the 'we' object is created. (Well, AFAIK..?)
So, I did that 'final' test: added an "@if b1" test to my test CSS, then went to the homepage, filename was member-chrome26-ID.css.gz, then clicked on board #1, filename was member-chrome26-b1-ID.css.gz
Epic! :D
Of course, the final code is something like a kilobyte larger than it used to be... Next time I plan to rewrite something to 'simplify it' and 'remove some of the fat', I should get stuffed myself or something... :lol:
Not only that, but it seems that up until now, the b1 keyword never worked to target a board, because the keyword wasn't generated in the first place, ah ah... Needed to be done in loadBoard(), which is executed AFTER the 'we' object is created. (Well, AFAIK..?)
So, I did that 'final' test: added an "@if b1" test to my test CSS, then went to the homepage, filename was member-chrome26-ID.css.gz, then clicked on board #1, filename was member-chrome26-b1-ID.css.gz
Epic! :D
Of course, the final code is something like a kilobyte larger than it used to be... Next time I plan to rewrite something to 'simplify it' and 'remove some of the fat', I should get stuffed myself or something... :lol:
3087
Features: Theming / Re: CSS caching
« on May 2nd, 2013, 07:54 PM »
Hmm, so... Sooooo..... Okay....
I finally pulled my finger out, and wrote some code to automatically store all tests in CSS files... The main index files have something like 20 tests, and executing them on every single page load is a total disaster. Indeed, I'm just pulling something else this time (your leg), and it all executes in less than a millisecond...
Considering that a millisecond is precisely my 'psychological barrier' when it comes to execution times of features I'm not excited to add, I'd say it's all good then! ;)
Now I just need to fix another 27 bugs, and I'll be done with it.......
I finally pulled my finger out, and wrote some code to automatically store all tests in CSS files... The main index files have something like 20 tests, and executing them on every single page load is a total disaster. Indeed, I'm just pulling something else this time (your leg), and it all executes in less than a millisecond...
Considering that a millisecond is precisely my 'psychological barrier' when it comes to execution times of features I'm not excited to add, I'd say it's all good then! ;)
Now I just need to fix another 27 bugs, and I'll be done with it.......
3088
Features / Re: Post Deletion
« on May 2nd, 2013, 12:29 PM »
This technique has been used on Noisen.com for about 6 years, the only reason it isn't in Wedge yet is that Pete is concerned with performance issues on larger boards. (Also, we need to determine that if soft deletion is enabled, then 'post moderation' mode is also active, as for now it only becomes active if a moderation filter has been set.)
3089
Archived fixes / Re: Board 'Last Post' Bug
« on May 2nd, 2013, 12:27 PM »
Dunno, all I know is that the Test board isn't included in that box...
3090
Features: Theming / Re: Wess: the Wedge preprocessor for CSS
« on May 2nd, 2013, 10:09 AM »
Actually, Wess is a behemoth that deals both with CSS and JavaScript, but it does far more work on CSS than JS. The JS jobs consists in minifying the files, as well as transforming $txt strings and doing @if tests (albeit a very limited set of our usual keywords... IIRC, it only supports 'member' and 'guest', at this point, because there's not much need for anything else...?)