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
5161
Off-topic / Re: Album: Things and things.
« on May 19th, 2012, 07:27 AM »
(This is a feature that will HOPEFULLY go once I've fully implemented floating boards... :P)
5162
Features / Re: Action buttons: positioning
« on May 18th, 2012, 08:58 PM »
Bump... :whistle:Quote from Nao on May 18th, 2012, 07:21 PM
Okay, another set of questions...
I'd like to add mini-menus to more buttons.
Let's see if we can set something up that would make sense and improve usability?
- Like: I already mentioned it, there are several links that could be added to it...
- Quote: main link points to the default setup...? Opening it in a new tab points to full quote either way. Additional links: disambiguation -- Quick quote, Full quote.
- Modify: main link points to quick edit, but opening it in a new tab points to full edit. Additional links: disambiguation -- Quick edit, Full edit.
What do you think...?
Also, should the Modify button be placed where it is, and the Quick Edit button removed entirely? Or should the Modify button be placed to the right of More? (Renaming More to Actions...?) Or should both buttons stay?
5163
Features / Re: Action buttons: positioning
« on May 18th, 2012, 07:53 PM »
Plus, if instead of a quick edit button, you had a button that clearly said "full edit" or "quick edit", that's something that newbies will appreciate...
(Hmm, here's wondering if we should add some kind of warning that although edits are allowed, the threshold for 'last modified' has expired...)
(Hmm, here's wondering if we should add some kind of warning that although edits are allowed, the threshold for 'last modified' has expired...)
5164
Features / Re: Action buttons: positioning
« on May 18th, 2012, 07:45 PM »
Anything in the more menu should be things you don't use often. I don't want to discourage people from quick editing their posts to fix a typo they found while re-reading it...!
5165
Features: Upcoming / Re: Private tag
« on May 18th, 2012, 07:43 PM »
That's the idea -- we could use custom groups in the params.
However, I doubt this feature will make it into Wedge final... Maybe for 2.0, or maybe simply as a plugin. Heck, it's pretty good plugin material actually...
However, I doubt this feature will make it into Wedge final... Maybe for 2.0, or maybe simply as a plugin. Heck, it's pretty good plugin material actually...
5166
Features / Re: Action buttons: positioning
« on May 18th, 2012, 07:21 PM »
Okay, another set of questions...
I'd like to add mini-menus to more buttons.
Let's see if we can set something up that would make sense and improve usability?
- Like: I already mentioned it, there are several links that could be added to it...
- Quote: main link points to the default setup...? Opening it in a new tab points to full quote either way. Additional links: disambiguation -- Quick quote, Full quote.
- Modify: main link points to quick edit, but opening it in a new tab points to full edit. Additional links: disambiguation -- Quick edit, Full edit.
What do you think...?
Also, should the Modify button be placed where it is, and the Quick Edit button removed entirely? Or should the Modify button be placed to the right of More? (Renaming More to Actions...?) Or should both buttons stay?
I'd like to add mini-menus to more buttons.
Let's see if we can set something up that would make sense and improve usability?
- Like: I already mentioned it, there are several links that could be added to it...
- Quote: main link points to the default setup...? Opening it in a new tab points to full quote either way. Additional links: disambiguation -- Quick quote, Full quote.
- Modify: main link points to quick edit, but opening it in a new tab points to full edit. Additional links: disambiguation -- Quick edit, Full edit.
What do you think...?
Also, should the Modify button be placed where it is, and the Quick Edit button removed entirely? Or should the Modify button be placed to the right of More? (Renaming More to Actions...?) Or should both buttons stay?
5167
The Pub / Re: The Cookie Law (in the UK at least)
« on May 18th, 2012, 06:19 PM »
Lulz this last page... ;)
Problem fixed. As I predicted!
Problem fixed. As I predicted!
5168
Features / Re: New revs
« on May 18th, 2012, 04:08 PM »
rev 1585
(11 files +1, 13kb)
* Rewrote JS/CSS compilers to allow for plugins and themes to specify the list of filenames they'd like to ignore from the final filename. For instance, $context['javascript_files'][] = 'something' should now be $context['main_js_files']['something'] = true (or false to ignore). For consistency, renamed $context['javascript_files'] to 'main_js_files', 'remote_javascript_files' to 'remote_js_files' and 'css_main_files' to 'main_css_files'. (Load.php, Subs-Cache.php, Subs.php, index.template.php, Login.template.php)
+ Split we_avatarResize() into its own file, which is only loaded if the related feature is enabled. Which is unlikely, because it's not set by default, so why force everyone to load nearly 150 bytes for an unused function...? (avasize.js, script.js)
* Don't close the dropdown if a top-level menu item is clicked when it has no associated link, e.g. the profile menu. (script.js)
* A few size optimizations, and reorganized the thought object to allow for new thoughts to be associated with relevant action buttons. The rest will come later... (script.js)
* Renamed 'MiniMenu' plugin to 'mime', for consistency with .menu() and because everybody hates mimes and my number 2 goal in life is to annoy you. Also optimized both files for size. (Display.template.php, topic.js)
* Improved styling for the source code popup in the error log. (Errors.template.php)
* Moved the quick edit button by a few pixels to be on the same line as the rest as the action bar. (index.member.css)
- A leftover line of CSS... (sections.css)
(11 files +1, 13kb)
* Rewrote JS/CSS compilers to allow for plugins and themes to specify the list of filenames they'd like to ignore from the final filename. For instance, $context['javascript_files'][] = 'something' should now be $context['main_js_files']['something'] = true (or false to ignore). For consistency, renamed $context['javascript_files'] to 'main_js_files', 'remote_javascript_files' to 'remote_js_files' and 'css_main_files' to 'main_css_files'. (Load.php, Subs-Cache.php, Subs.php, index.template.php, Login.template.php)
+ Split we_avatarResize() into its own file, which is only loaded if the related feature is enabled. Which is unlikely, because it's not set by default, so why force everyone to load nearly 150 bytes for an unused function...? (avasize.js, script.js)
* Don't close the dropdown if a top-level menu item is clicked when it has no associated link, e.g. the profile menu. (script.js)
* A few size optimizations, and reorganized the thought object to allow for new thoughts to be associated with relevant action buttons. The rest will come later... (script.js)
* Renamed 'MiniMenu' plugin to 'mime', for consistency with .menu() and because everybody hates mimes and my number 2 goal in life is to annoy you. Also optimized both files for size. (Display.template.php, topic.js)
* Improved styling for the source code popup in the error log. (Errors.template.php)
* Moved the quick edit button by a few pixels to be on the same line as the rest as the action bar. (index.member.css)
- A leftover line of CSS... (sections.css)
5169
Bug reports / Re: SMF bug 4905 (signature length verified before preparsecode)
« on May 18th, 2012, 02:59 PM »
Funny? I'd rather you say stunning :P
5170
Features / Re: Action buttons: positioning
« on May 18th, 2012, 12:15 PM »
Decided to create all mini-menus at page load rather than on the fly. Saved over 30 gzipped bytes. Yay. Until I realized it added a whole second of load time to IE6... On my super-modern PC running XP in a box. Must be pretty close to regular numbers, especially since even Opera in my Win7 takes 0.15s to run it.
Back to square one...
Anyway, I've saved about 10 gzipped bytes by keeping to the on-the-fly creation thingy, which is better than nothing...
OTOH, I've added an extra 10 bytes to script.js just to filter correctly the click event on main menus.
Remember how someone complained that clicking the top-level item in the profile menu would close the menu and clicking it again would do nothing...? Well, the goal wasn't to close the menu, but to close any menu after a click was made, to give a feeling of responsiveness, i.e. "I've registered your call, I'm processing it." However, in the profile menu, there's no link in the top-level item, so it just closes it and does nothing... I had two solution: either I added a filter (for an extra ~10b) or removed the entire click event (to save a whopping ~20 bytes). In the end, I decided to use the filter (.filter(':has(>a,>h4>a)')), because I really like the responsiveness thing... But it also wastes 30 bytes in total, eh.
So, my solution to this...
Well, it's pretty elegant if you will... Although it's totally unrelated :lol:
I 'simply' moved we_avatarResize() to a new file. This function is ~150 bytes gzipped, and it's not used by default (one has to enable a feature in the admin area, "resize with JavaScript" or something.)
That's it... New script file is now 120 bytes smaller, ahah, I love my cache system.
Totally OT now...
A quick poll... I'm thinking of doing a small rewrite to $context['javascript_files']. Instead of adding strings to the array ( [] = 'script.js' ), you would add an indexed array ( ['script.js'] = true ), where 'true' means 'add the filename to the final filename' while false would ignore it.
While it isn't useful right now, I can imagine that some modders would like to be able to add their files to the main script, *and* not have them pollute the final filename. Right now, it's not possible to do it because the list of ignored filenames (custom, sbox, theme, and now avasize) is hardcoded into our source files...
Since it makes the javascript_files array a bit harder to understand than just using a simple list of files, I'd rather ask because there's always a fine line between customizability (English??) and complexity.
Quote from Nao on May 18th, 2012, 11:38 AM Implemented. I can always revert, but I'm pretty happy with it. :)
Except for the fact that the $ignore_files flag now acts differently in both add_js_file and add_css_file... Meh!
Back to square one...
Anyway, I've saved about 10 gzipped bytes by keeping to the on-the-fly creation thingy, which is better than nothing...
OTOH, I've added an extra 10 bytes to script.js just to filter correctly the click event on main menus.
Remember how someone complained that clicking the top-level item in the profile menu would close the menu and clicking it again would do nothing...? Well, the goal wasn't to close the menu, but to close any menu after a click was made, to give a feeling of responsiveness, i.e. "I've registered your call, I'm processing it." However, in the profile menu, there's no link in the top-level item, so it just closes it and does nothing... I had two solution: either I added a filter (for an extra ~10b) or removed the entire click event (to save a whopping ~20 bytes). In the end, I decided to use the filter (.filter(':has(>a,>h4>a)')), because I really like the responsiveness thing... But it also wastes 30 bytes in total, eh.
So, my solution to this...
Well, it's pretty elegant if you will... Although it's totally unrelated :lol:
I 'simply' moved we_avatarResize() to a new file. This function is ~150 bytes gzipped, and it's not used by default (one has to enable a feature in the admin area, "resize with JavaScript" or something.)
That's it... New script file is now 120 bytes smaller, ahah, I love my cache system.
Totally OT now...
A quick poll... I'm thinking of doing a small rewrite to $context['javascript_files']. Instead of adding strings to the array ( [] = 'script.js' ), you would add an indexed array ( ['script.js'] = true ), where 'true' means 'add the filename to the final filename' while false would ignore it.
While it isn't useful right now, I can imagine that some modders would like to be able to add their files to the main script, *and* not have them pollute the final filename. Right now, it's not possible to do it because the list of ignored filenames (custom, sbox, theme, and now avasize) is hardcoded into our source files...
Since it makes the javascript_files array a bit harder to understand than just using a simple list of files, I'd rather ask because there's always a fine line between customizability (English??) and complexity.
Posted: May 18th, 2012, 11:38 AM
A quick poll... I'm thinking of doing a small rewrite to $context['javascript_files']. Instead of adding strings to the array ( [] = 'script.js' ), you would add an indexed array ( ['script.js'] = true ), where 'true' means 'add the filename to the final filename' while false would ignore it.
Except for the fact that the $ignore_files flag now acts differently in both add_js_file and add_css_file... Meh!
5171
Features / Re: Action buttons: positioning
« on May 18th, 2012, 07:23 AM »But then what would happen if the browser default for a margin on a particular tag (<p>) isn't zero?
5172
Bug reports / Re: SMF bug 4905 (signature length verified before preparsecode)
« on May 18th, 2012, 07:20 AM »
Yup, touched nothing... ;)
However, Noisen and a few others (sm.org :P) allow you to define your scope manually with a select box. It's just something that's been in my to-do list for so long (and so easy to do!) that I'm wondering whether I'll actually THINK of implementing it here... :lol:
However, Noisen and a few others (sm.org :P) allow you to define your scope manually with a select box. It's just something that's been in my to-do list for so long (and so easy to do!) that I'm wondering whether I'll actually THINK of implementing it here... :lol:
5173
Other software / Re: Has SMF Gotten Slower?
« on May 18th, 2012, 07:18 AM »
Avatars are a way to identify a user without having to read their name (e.g. when you're quickly scanning a page looking for someone's comments.)
Random avatars would defeat that...
Random avatars would defeat that...
5174
Features / Re: Action buttons: positioning
« on May 17th, 2012, 11:00 PM »But for example in the context of margins, what does 'default' mean, exactly?
It feels like it's just a meaningless term.
Anyway. So, I did my commit...
You'll mainly notice two hacks that I couldn't get rid of -- namely for IE8 and iPhone, in their respective stylesheets.
I'd really like to know if anyone manages to remove these hacks without breaking anything. ESPECIALLY on the iPhone, because AFAIK, Safari Mobile is a decent browser, unlike IE, and I don't get why it's not following my queries regarding positioning... :-/
5175
Features / Re: New revs
« on May 17th, 2012, 10:56 PM »
rev 1584
(14 files +1-1, 12kb)
* Turned mini-menu code into a jQuery plugin, so that templates can create them more easily. Also fixed aligment in various browsers, and made JS code shorter (about 50 bytes saved, or so.) (Display.template.php, topic.js, sections.css)
! Fixed user menus in iOS... At least iOS 4... If someone can tell me why the hell I had to use 'position: absolute' on the parent span, instead of 'position: relative' which works on all other browsers and even in iOS on action menus, then... Well, I'd be glad to hear from you. (index.iphone.css)
! Fixed main menus in IE8. Another epic fight which I've only half-won... Many problems were due to specifically setting opacity to 1 (jQuery will add an alpha filter even though it's unneeded, and this will cause layout issues), as well as #navi using an overflow: hidden to ensure the left-floated #main_menu was shown... Heck, I don't remember why I did that in the first place, when I could have done a clearfix (which, whatever you say, is less likely to cause problems), or... hem... removed the float. Which I did. I still don't know why I had to add a strange hack for menu margins in IE8, but don't ask too much of me... It's only IE. (index.css, index.ie8.css)
! Fixed Wireless in IE6, in case users wanna test-drive it... (Even though, if they're using IE6, it's probably because they're utterly incapable of test-driving anything else...) (Wireless/sections.css)
- Don't bother showing minutes or, in the worst cases, hours, in 'total time spent on this forum' statistics, depending on the number of days spent online. If you have 100+ days and counting, do you really care about minutes online? (Stats.php)
- Don't show the action bar if it's going to be empty anyway... (Display.template.php)
- Removed an extra br from the admin login template. (I think it's another thing I forgot from my earlier commit.) (Login.template.php)
- Removed my latest animation for popups. Didn't look good enough. Will try and use an animation similar to what I now have in mini-menus. (script.js)
+ Added a $post_font_size variable to make post font size (what else?) easier to customize... Whatever. (index.css)
* quickbuttons.png renamed to actions.png, as forgotten in the previous commit. (actions.png, quickbuttons.png)
* Most of the h6 (mini-header) occurrences were at the beginning of a block, so I removed the need to add a 'top' class, and only showing a top-margin if the tag has another one before it in the block. (ManagePlugins.php, script.js, Stats.template.php, Who.template.php)
* Translation. (index.french.php)
(14 files +1-1, 12kb)
* Turned mini-menu code into a jQuery plugin, so that templates can create them more easily. Also fixed aligment in various browsers, and made JS code shorter (about 50 bytes saved, or so.) (Display.template.php, topic.js, sections.css)
! Fixed user menus in iOS... At least iOS 4... If someone can tell me why the hell I had to use 'position: absolute' on the parent span, instead of 'position: relative' which works on all other browsers and even in iOS on action menus, then... Well, I'd be glad to hear from you. (index.iphone.css)
! Fixed main menus in IE8. Another epic fight which I've only half-won... Many problems were due to specifically setting opacity to 1 (jQuery will add an alpha filter even though it's unneeded, and this will cause layout issues), as well as #navi using an overflow: hidden to ensure the left-floated #main_menu was shown... Heck, I don't remember why I did that in the first place, when I could have done a clearfix (which, whatever you say, is less likely to cause problems), or... hem... removed the float. Which I did. I still don't know why I had to add a strange hack for menu margins in IE8, but don't ask too much of me... It's only IE. (index.css, index.ie8.css)
! Fixed Wireless in IE6, in case users wanna test-drive it... (Even though, if they're using IE6, it's probably because they're utterly incapable of test-driving anything else...) (Wireless/sections.css)
- Don't bother showing minutes or, in the worst cases, hours, in 'total time spent on this forum' statistics, depending on the number of days spent online. If you have 100+ days and counting, do you really care about minutes online? (Stats.php)
- Don't show the action bar if it's going to be empty anyway... (Display.template.php)
- Removed an extra br from the admin login template. (I think it's another thing I forgot from my earlier commit.) (Login.template.php)
- Removed my latest animation for popups. Didn't look good enough. Will try and use an animation similar to what I now have in mini-menus. (script.js)
+ Added a $post_font_size variable to make post font size (what else?) easier to customize... Whatever. (index.css)
* quickbuttons.png renamed to actions.png, as forgotten in the previous commit. (actions.png, quickbuttons.png)
* Most of the h6 (mini-header) occurrences were at the beginning of a block, so I removed the need to add a 'top' class, and only showing a top-margin if the tag has another one before it in the block. (ManagePlugins.php, script.js, Stats.template.php, Who.template.php)
* Translation. (index.french.php)