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
5131
Features / Re: New revs
« on May 21st, 2012, 06:46 PM »
rev 1587
(11 files, 19kb) -- hopefully didn't break anything, bit in a hurry... wedge.org is a bit broken though, will fix later.
* Rewrote and optimized the Display template (more precisely, per-post template) to remove duplicate message id's, and rewrote everything to instead request the post root's message ID and work with that. Seriously, with the machines we use today, jQuery can perfectly handle these. On a full sample page, I started with 65KB and ended up saving 1.5KB, or 300 gzipped bytes. It doesn't seem like much, but topic pages are the most visited (and most demanding) pages on any given forum, and with any byte saved, your server will thank you in the end. (Display.template.php, Post.template.php, post.js, topic.js)
* Quick editing a post will now sport a small sliding animation. (topic.js)
* Did some severe size optimizations for topic.js and (to a lesser extent) post.js while I was rewriting them -- saved about 100 gzipped bytes in topic.js, even after the extra features were added. About half of that in post.js. Also saved a few bytes off the Ajax data sent back to the client. Eh, a byte saved is a byte saved... (topic.js, post.js, Xml.template.php)
* Moved some inline styles to their proper CSS files. (Display.template.php, index.ie8.css, index.member.css)
* Renamed modifybutton to quick_edit, because that's what it is... A quick edit button. (Display.template.php, index.member.css, index.rtl.css)
+ Added a hardcoded copyright for Wireless. Oops. (Wireless/sections.css)
! Forgot to filter out editor-func and post from editor filenames, as well as 'index' for the main CSS filename. (Class-Editor.php, Load.php)
(11 files, 19kb) -- hopefully didn't break anything, bit in a hurry... wedge.org is a bit broken though, will fix later.
* Rewrote and optimized the Display template (more precisely, per-post template) to remove duplicate message id's, and rewrote everything to instead request the post root's message ID and work with that. Seriously, with the machines we use today, jQuery can perfectly handle these. On a full sample page, I started with 65KB and ended up saving 1.5KB, or 300 gzipped bytes. It doesn't seem like much, but topic pages are the most visited (and most demanding) pages on any given forum, and with any byte saved, your server will thank you in the end. (Display.template.php, Post.template.php, post.js, topic.js)
* Quick editing a post will now sport a small sliding animation. (topic.js)
* Did some severe size optimizations for topic.js and (to a lesser extent) post.js while I was rewriting them -- saved about 100 gzipped bytes in topic.js, even after the extra features were added. About half of that in post.js. Also saved a few bytes off the Ajax data sent back to the client. Eh, a byte saved is a byte saved... (topic.js, post.js, Xml.template.php)
* Moved some inline styles to their proper CSS files. (Display.template.php, index.ie8.css, index.member.css)
* Renamed modifybutton to quick_edit, because that's what it is... A quick edit button. (Display.template.php, index.member.css, index.rtl.css)
+ Added a hardcoded copyright for Wireless. Oops. (Wireless/sections.css)
! Forgot to filter out editor-func and post from editor filenames, as well as 'index' for the main CSS filename. (Class-Editor.php, Load.php)
5132
Features / Re: Disable animation on mobile devices
« on May 21st, 2012, 04:43 PM »
Meh... Didn't know that.
I never looked into CSS3 animations much, because they're not very fast in Opera, from what I could see.
I never looked into CSS3 animations much, because they're not very fast in Opera, from what I could see.
5133
The Pub / Re: One more stupid animation...
« on May 21st, 2012, 04:42 PM »
(Eh...?!)
Anyway, in my latest version I've given up on the idea of starting the fadeOut animation before the post text is retrieved -- I don't like relying on client/server efficiency when doing animations. So it's doing a simple slideUp while the textarea is in a slideDown. A kind of animation I already implemented in the past, because, well, it's relatively easy to do... :)
It doesn't look bad, at this point. I just don't know how it'll work in the long run.
Anyway, in my latest version I've given up on the idea of starting the fadeOut animation before the post text is retrieved -- I don't like relying on client/server efficiency when doing animations. So it's doing a simple slideUp while the textarea is in a slideDown. A kind of animation I already implemented in the past, because, well, it's relatively easy to do... :)
It doesn't look bad, at this point. I just don't know how it'll work in the long run.
5134
Features / Re: Disable animation on mobile devices
« on May 21st, 2012, 04:39 PM »
I thought jQuery used CSS3 animations when available..?
5135
Features: Posts & Topics / Re: Likes
« on May 21st, 2012, 04:39 PM »
No, it doesn't hide everything. The code has to specify which divs will be hidden. actionbar is not hidden, but locally I've hidden actions (the right side of actionbar), which works well, but removing the Like button would defeat any reason to actually unhide a post. (In many cases.)
5136
Features / Re: Disable animation on mobile devices
« on May 21st, 2012, 04:37 PM »
Yep, yep, and it pisses me off all the time... :lol:
I'm just waiting for the day I'll update to iOS5. Their Safari is supposedly faster, and I wouldn't like to disable animations if it can handle them...
But right now, iPod Touch 4 + iOS 4.1 (or 4.2 or whatever) = shows 2 or 3 frames of any given animation.
BTW, to disable animations globally: $.fx.off = true;
I'm just waiting for the day I'll update to iOS5. Their Safari is supposedly faster, and I wouldn't like to disable animations if it can handle them...
But right now, iPod Touch 4 + iOS 4.1 (or 4.2 or whatever) = shows 2 or 3 frames of any given animation.
BTW, to disable animations globally: $.fx.off = true;
5137
The Pub / Re: One more stupid animation...
« on May 21st, 2012, 04:23 PM »
The problem is that the textarea has a pretty much consistent height, while posts can be of any height...
I actually introduced the animation to allow users to 'follow' the Quick Edit button they just clicked, while the post is being resized.
Unfortunately, on my computer it's quite jerky, and I'm not sure it's for the best.
I'm still working on it...
I actually introduced the animation to allow users to 'follow' the Quick Edit button they just clicked, while the post is being resized.
Unfortunately, on my computer it's quite jerky, and I'm not sure it's for the best.
I'm still working on it...
5138
The Pub / One more stupid animation...
« on May 21st, 2012, 04:16 PM »
So, I couldn't be arsed to keep working on the tons of features I'm supposed to finish, so I just made a new animation...
Just press the Quick Edit button to see a (probably weird) transition between the post and the textarea.
I tried many variations to get the most 'natural' feeling, but I don't know if it adds anything to the feature, or actually distracts from it, I don't know...
Hence this new topic to post about new animations, and your opinions on them :P
Just press the Quick Edit button to see a (probably weird) transition between the post and the textarea.
I tried many variations to get the most 'natural' feeling, but I don't know if it adds anything to the feature, or actually distracts from it, I don't know...
Hence this new topic to post about new animations, and your opinions on them :P
5139
Features: Posts & Topics / Re: Likes
« on May 21st, 2012, 10:26 AM »
Should we hide the Like button for ignored posts...?
Pros:
- It takes less room. Even if hiding the action bar, the Like button is still on the same row, meaning I have to show said row... And I can't really move the Like button elsewhere...
Cons:
- If a post is really liked, this may be an incentive to actually unhide it. For instance, you may want to ignore a post spammer who often says interesting things but tends to pollute topics... (People like Pete and I :lol:)
Pros:
- It takes less room. Even if hiding the action bar, the Like button is still on the same row, meaning I have to show said row... And I can't really move the Like button elsewhere...
Cons:
- If a post is really liked, this may be an incentive to actually unhide it. For instance, you may want to ignore a post spammer who often says interesting things but tends to pollute topics... (People like Pete and I :lol:)
5140
Features / Re : Rewriting the skin file parser...
« on May 21st, 2012, 09:16 AM »Just wanted to say — going to bed with a half done function. CSS may fail here and there.
Posted: May 21st, 2012, 09:13 AM
Agreed.
But:
/editor.css
/Foobar/editor.firefox.css
If only these files are there -- I can see the intent as "use the top-level editor.css, and modify it with my custom firefox file..."
Also:
/editor.css
/editor.firefox.css
/Foobar/(nothing)
Should firefox* be loaded in Foobar...?
5141
Features / Re : Rewriting the skin file parser...
« on May 20th, 2012, 11:44 PM »
Just wanted to say — going to bed with a half done function. CSS may fail here and there.
Heck. The new function adds something like 60 lines.... Adding support for comma separated suffixes is definitely more complicated than I originally thought ;)
Heck. The new function adds something like 60 lines.... Adding support for comma separated suffixes is definitely more complicated than I originally thought ;)
5142
Features / Re : Rewriting the skin file parser...
« on May 20th, 2012, 07:59 PM »
I really only want for this all to just... make sense ;)
Intuition is what you rely on when you're too lazy to read a documentation. So everything I do, I try to make intuitive :P
Intuition is what you rely on when you're too lazy to read a documentation. So everything I do, I try to make intuitive :P
5143
Features / Re : Rewriting the skin file parser...
« on May 20th, 2012, 07:41 PM »
Agreed.
But:
/editor.css
/Foobar/editor.firefox.css
If only these files are there -- I can see the intent as "use the top-level editor.css, and modify it with my custom firefox file..."
Hmm, the change to glob() unfortunately makes it a tad harder to sort these files correctly.
But:
/editor.css
/Foobar/editor.firefox.css
If only these files are there -- I can see the intent as "use the top-level editor.css, and modify it with my custom firefox file..."
Hmm, the change to glob() unfortunately makes it a tad harder to sort these files correctly.
5144
Features / Re : Rewriting the skin file parser...
« on May 20th, 2012, 07:11 PM »
"State both"?
But if my sub-skin's editor.css has no need for Firefox hacks, why should I add an empty editor.firefox.css file then...?
As a reminder, I'm talking about a replace-type skin, not an inherit-type (add-type) skin.
Which means that the only reason we should look into the default skin is if we can't find a *main* file such as editor.css or index.css...
But then it gets funny when you specify an editor.firefox.css file in your sub-skin, but no editor.css file... Probably meaning you want to include the top-level's editor.css, but modify it for Firefox in your sub-skin.
Lots of fun :)
Posted: May 20th, 2012, 07:09 PM
But if my sub-skin's editor.css has no need for Firefox hacks, why should I add an empty editor.firefox.css file then...?
Posted: May 20th, 2012, 07:10 PM
As a reminder, I'm talking about a replace-type skin, not an inherit-type (add-type) skin.
Which means that the only reason we should look into the default skin is if we can't find a *main* file such as editor.css or index.css...
But then it gets funny when you specify an editor.firefox.css file in your sub-skin, but no editor.css file... Probably meaning you want to include the top-level's editor.css, but modify it for Firefox in your sub-skin.
Lots of fun :)
5145
Features / Re : Rewriting the skin file parser...
« on May 20th, 2012, 07:05 PM »
Okay, I'm having a logic problem here...
Let's say I have this main skin:
/skins/index.css
/skins/editor.css
/skins/editor.firefox.css
And a replace-type skin:
/skins/Foobar/index.css
Now, let's say that I don't have an editor.css file in the sub-skin, because I want to re-use the default one.
This was possible (and supported) in Wedge up until now.
Now, with the glob() rewrite, I have to make some adjustments, but I'm not even SURE I can remember how I dealt with it...
Basically: should I use the top-level editor.css? Yes. Should I use the top-level editor.firefox.css if I'm on Firefox? I have no idea... How do I determine that it's a generic fix file and not something related to the default skin...? What if I have an editor.css in my sub-skin, but not editor.firefox.css --- should I use the top-level's editor.firefox.css file? It's a lot of fun...
Let's say I have this main skin:
/skins/index.css
/skins/editor.css
/skins/editor.firefox.css
And a replace-type skin:
/skins/Foobar/index.css
Now, let's say that I don't have an editor.css file in the sub-skin, because I want to re-use the default one.
This was possible (and supported) in Wedge up until now.
Now, with the glob() rewrite, I have to make some adjustments, but I'm not even SURE I can remember how I dealt with it...
Basically: should I use the top-level editor.css? Yes. Should I use the top-level editor.firefox.css if I'm on Firefox? I have no idea... How do I determine that it's a generic fix file and not something related to the default skin...? What if I have an editor.css in my sub-skin, but not editor.firefox.css --- should I use the top-level's editor.firefox.css file? It's a lot of fun...