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
3466
Features / Re: New revs
« on March 7th, 2013, 01:32 PM »3467
Features / Re: New revs
« on March 7th, 2013, 12:35 PM »
rev 1980 - Me r'connaissez-vous ? C'est moi, le crisse de fou, qui marche au-d'sus d'la ville...[1] / Hire ttipitasun hortan, baretu ditzakek soslai itsuak hegalak, baina ura nahi badun draia, hobe duzu merengeetan gastatu, Altxor Altxor Ene altxor.[2]
(21 files, 5kb)
- Removed type="text" from input tags. It's the default type. Has been in both HTML 4 and HTML 5... D'you have a problem with that? It saves tons of bytes... More files coming, it's literally hundreds of replacements. Also, replaced a few of these with type="email", as needed. (install.php, Profile.php, SSI.php, TEMPLATES: Admin, Display, GenericControls, index, Login, Mailer, ManageBans, ManageMail, ManageMaintenance, ManageMembers, Poll, Post, Profile)
- Removed CDATA and HTML comments out of script tags. CDATA tags are only useful when the page is sent with a XML header, which never happens in HTML mode (or could happen in the case of a SSI call, but let's hold our horses shall we?), and HTML comments haven't been useful for the last 15 years or so. I think it's fair to remove them, ah ah. (Subs-Cache.php, Subs-Template.php, index.template.php)
- Removed method="get" from form tags, as it's the default method anyway. And it's not used in a lot of situations... (install.php, Admin.template.php)
! Stupid laptop keyboard... (index.english.php)
* French grammar. (Search.french.php)
! Fixed number input width in search popup. (sections.css)
(21 files, 5kb)
- Removed type="text" from input tags. It's the default type. Has been in both HTML 4 and HTML 5... D'you have a problem with that? It saves tons of bytes... More files coming, it's literally hundreds of replacements. Also, replaced a few of these with type="email", as needed. (install.php, Profile.php, SSI.php, TEMPLATES: Admin, Display, GenericControls, index, Login, Mailer, ManageBans, ManageMail, ManageMaintenance, ManageMembers, Poll, Post, Profile)
- Removed CDATA and HTML comments out of script tags. CDATA tags are only useful when the page is sent with a XML header, which never happens in HTML mode (or could happen in the case of a SSI call, but let's hold our horses shall we?), and HTML comments haven't been useful for the last 15 years or so. I think it's fair to remove them, ah ah. (Subs-Cache.php, Subs-Template.php, index.template.php)
- Removed method="get" from form tags, as it's the default method anyway. And it's not used in a lot of situations... (install.php, Admin.template.php)
! Stupid laptop keyboard... (index.english.php)
* French grammar. (Search.french.php)
! Fixed number input width in search popup. (sections.css)
| 1. | http://fox.noisen.com/4800/harmonium/ |
| 2. | http://fox.noisen.com/4845/itoiz/ These are two of my favorite songs, so bugger off :P I can't believe I managed to go through the 70's without referencing more than a couple of prog albums! |
3468
The Pub / Re: Spell checker
« on March 7th, 2013, 10:23 AM »
Well, or you could move the dictionary info to the Search language files... ;)
I really like the 'did you mean' bit, but it's true that it's not exactly realistic to fill a DB table with thousands of words just to build a dictionary that's suitable to the forum. However, I think it might be a reasonable plugin to build, in case the admin really, really wants to have their own custom suggestion code.
The reality, I'd say, is that the 'did you mean' system could be improved, and linked with a tag system of sorts.
Also, I'd like to point that in the time since I reawakened this topic, we got two extra votes for the 'don't remove' side, namely from kimikelku and Maxx, but it's too late to remove the spellcheck button portion, anyway.
I really like the 'did you mean' bit, but it's true that it's not exactly realistic to fill a DB table with thousands of words just to build a dictionary that's suitable to the forum. However, I think it might be a reasonable plugin to build, in case the admin really, really wants to have their own custom suggestion code.
The reality, I'd say, is that the 'did you mean' system could be improved, and linked with a tag system of sorts.
Posted: March 7th, 2013, 10:22 AM
Also, I'd like to point that in the time since I reawakened this topic, we got two extra votes for the 'don't remove' side, namely from kimikelku and Maxx, but it's too late to remove the spellcheck button portion, anyway.
3469
Features / Re: Mini-skeletons
« on March 7th, 2013, 10:18 AM »
I'm afraid, there's no magic in this... ;)
Just look at the Msg template file: every little function has a $msg global in it. You'll need to use that.
Of course, there's always a possibility we could do away with a global and either use a function parameter or something else entirely, but... There's no really much point in that, is it..? If you need $msg, you're probably in a more complex function that also needs some other global. Otherwise, you're in a 'presentation' layer that just adds a div or something, so you don't need any globals.
Themers can also pass a variable to any block with the block params system (see bottom linktree in main skeleton, really.)
Just look at the Msg template file: every little function has a $msg global in it. You'll need to use that.
Of course, there's always a possibility we could do away with a global and either use a function parameter or something else entirely, but... There's no really much point in that, is it..? If you need $msg, you're probably in a more complex function that also needs some other global. Otherwise, you're in a 'presentation' layer that just adds a div or something, so you don't need any globals.
Themers can also pass a variable to any block with the block params system (see bottom linktree in main skeleton, really.)
3470
Features / Re: Mini-skeletons
« on March 7th, 2013, 10:12 AM »
- Well, I split it off from another topic, and thought your post was the sanest to start it with... ;)
- I really don't think any solution has a notable performance advantage against the others. It's really down to what you prefer. Anything that takes less than 10 milliseconds to execute is not worth optimizing against. And the skeleton system parsing and executing, by itself, is fast enough. (The template blocks themselves can take time to execute, of course -- that's why I did my basic benchmarks against a copy of Wedge with the older skeleton system, and a copy of it with the newer mini-skeletons.)
- What do you mean by context bit..? I don't see a lot of variables available to test against. Mobile and Sidebar are two skin variables that can be overridden by a sub-skin, and thus the skeleton can be modified without touching the skeleton code in the sub-skin (although, as it happens, Wedge also supports some instructions such as <move>, which make it possible to fine-tune the skeleton even more.) Also, member and guest are two 'classic' pseudo-variables that should be of use here and there. Other than that, hmm... Maybe a browser variable. That should probably be accepted, too, although I think browser hacks should be generally done at CSS level, rather than HTML level, but if the template block uses a flexbox or display:table model and doesn't provide for an easy way to rewrite the block (e.g. <we:my_block>), it could always be overridden with a browser test, I guess... (Damn IE!!)
- I really don't think any solution has a notable performance advantage against the others. It's really down to what you prefer. Anything that takes less than 10 milliseconds to execute is not worth optimizing against. And the skeleton system parsing and executing, by itself, is fast enough. (The template blocks themselves can take time to execute, of course -- that's why I did my basic benchmarks against a copy of Wedge with the older skeleton system, and a copy of it with the newer mini-skeletons.)
- What do you mean by context bit..? I don't see a lot of variables available to test against. Mobile and Sidebar are two skin variables that can be overridden by a sub-skin, and thus the skeleton can be modified without touching the skeleton code in the sub-skin (although, as it happens, Wedge also supports some instructions such as <move>, which make it possible to fine-tune the skeleton even more.) Also, member and guest are two 'classic' pseudo-variables that should be of use here and there. Other than that, hmm... Maybe a browser variable. That should probably be accepted, too, although I think browser hacks should be generally done at CSS level, rather than HTML level, but if the template block uses a flexbox or display:table model and doesn't provide for an easy way to rewrite the block (e.g. <we:my_block>), it could always be overridden with a browser test, I guess... (Damn IE!!)
3471
Features / Re: Mini-skeletons
« on March 7th, 2013, 09:44 AM »
Technically speaking, an if() test is always going to be so fast, that any alternative would be a waste of time. I was wary of doing mini-skeletons, precisely because of the growing number of tests and function calls, but in the end, it was really nothing to be scared of. The entire rendering of topic mini-skeletons added something like, a millisecond or two to the overall execution time... So, really, splitting the current Msg mini-skeleton into ten times more functions wouldn't kill performance either, after all the most time spent when rendering a page is on the client side, not server side. Always has been... Always will be.
I can't see many alternatives either, anyway.
- Removing skeleton entries at Sources time: implies calling wetem::remove or weSkeleton->remove, it's not particularly much faster... And not as flexible, either.
- Adding the tests directly into the skeleton tree: I guess we could do it in several possible ways...
<if member>
<this_skeleton />
</if>
or
<member@this_skeleton />
or
<SKIN_MOBILE@this_skeleton />
or
<mobile@this_skeleton />
or
<SKIN_SIDEBAR==left@this_skeleton />
or
<this_skeleton:params:SKIN_MOBILE />
<this_skeleton::SKIN_mobile />
<this_skeleton:params@SKIN_MOBILE />
or
<this_skeleton:SKIN_MOBILE:params />
<this_skeleton::params />
<this_skeleton@SKIN_MOBILE:params />
None of these really strike me as 'nice-looking', except possibly the last one (we don't use params THAT much... Only in linktrees, I think, for now.)
I'm absolutely willing to implement one of these, of course, if it gives themers and plugin authors even more flexibility. And we all hate doing tests at the beginning of each function, of course... I just don't know which way to go.
Of course, '@' is a temp separator I came up with to say, "this template block is intended for (directed @) members", etc. It probably isn't XML-compatible, but as everyone probably knows, the skeleton isn't parsed by a XML library, it's only written that way to help with readability. (Heck, I could very well switch to a JSON-like structure, and then actually parse it with json_decode()... Hmm, idea to explore...??!!)
I can't see many alternatives either, anyway.
- Removing skeleton entries at Sources time: implies calling wetem::remove or weSkeleton->remove, it's not particularly much faster... And not as flexible, either.
- Adding the tests directly into the skeleton tree: I guess we could do it in several possible ways...
<if member>
<this_skeleton />
</if>
or
<member@this_skeleton />
or
<SKIN_MOBILE@this_skeleton />
or
<mobile@this_skeleton />
or
<SKIN_SIDEBAR==left@this_skeleton />
or
<this_skeleton:params:SKIN_MOBILE />
<this_skeleton::SKIN_mobile />
<this_skeleton:params@SKIN_MOBILE />
or
<this_skeleton:SKIN_MOBILE:params />
<this_skeleton::params />
<this_skeleton@SKIN_MOBILE:params />
None of these really strike me as 'nice-looking', except possibly the last one (we don't use params THAT much... Only in linktrees, I think, for now.)
I'm absolutely willing to implement one of these, of course, if it gives themers and plugin authors even more flexibility. And we all hate doing tests at the beginning of each function, of course... I just don't know which way to go.
Of course, '@' is a temp separator I came up with to say, "this template block is intended for (directed @) members", etc. It probably isn't XML-compatible, but as everyone probably knows, the skeleton isn't parsed by a XML library, it's only written that way to help with readability. (Heck, I could very well switch to a JSON-like structure, and then actually parse it with json_decode()... Hmm, idea to explore...??!!)
3472
Features / Re: New revs
« on March 6th, 2013, 07:23 PM »
rev 1978 - With a smile of joy and gladness, with a look of exultation, as of one who in a vision sees what is to be, but is not, stood and waited Hiawatha.
(5 files, 4kb)
! A couple of fixes for quick search in Wuthering. (Wuthering/extra.css)
* Replaced the last remaining window.location with just 'location'... Well, there's another in the Media template, but I've made too many changes to it and can't commit that file yet, so it'll wait for another day. (PersonalMessage.template.php)
* Translation. (Login.french.php, ManageMaintenance.french.php, Profile.french.php)
(5 files, 4kb)
! A couple of fixes for quick search in Wuthering. (Wuthering/extra.css)
* Replaced the last remaining window.location with just 'location'... Well, there's another in the Media template, but I've made too many changes to it and can't commit that file yet, so it'll wait for another day. (PersonalMessage.template.php)
* Translation. (Login.french.php, ManageMaintenance.french.php, Profile.french.php)
3473
Features / Re: New revs
« on March 6th, 2013, 07:11 PM »
rev 1977 - Nothing ever grows in this rotting old hole, Everything is stunted and lost, And nothing really rocks, And nothing really rolls, And nothing's ever worth the cost[1]
(8 files, 22kb)
+ Added mini-menus to All Thoughts page. Finally... Refactored some of the code, was hoping to be able to add them to thought contexts as well, but it'll be for another day. Hoping to harmonize it all some more, too. (Home.php, Thoughts.php, Home.template.php, Thoughts.template.php)
+ Added a 'Posterity' option to the thought mini-menu. This solves a problem of mine with thought privacy and personal texts. Originally, I made it so that any new public thought would become your personal text; however, I found myself posting private thoughts then changing them to public to circumvent this, in order to keep an older thought as my personal text. From now on, Wedge won't update automatically your personal text; you can set any thought of yours to be your personal text simply by selecting the Posterity option in its mini-menu. Of course, anyone feel free to rename the option and add an icon, such as a star or something... (Ajax.php, Thoughts.php, index.language.php, script.js)
* Translation. (index.french.php)
(8 files, 22kb)
+ Added mini-menus to All Thoughts page. Finally... Refactored some of the code, was hoping to be able to add them to thought contexts as well, but it'll be for another day. Hoping to harmonize it all some more, too. (Home.php, Thoughts.php, Home.template.php, Thoughts.template.php)
+ Added a 'Posterity' option to the thought mini-menu. This solves a problem of mine with thought privacy and personal texts. Originally, I made it so that any new public thought would become your personal text; however, I found myself posting private thoughts then changing them to public to circumvent this, in order to keep an older thought as my personal text. From now on, Wedge won't update automatically your personal text; you can set any thought of yours to be your personal text simply by selecting the Posterity option in its mini-menu. Of course, anyone feel free to rename the option and add an icon, such as a star or something... (Ajax.php, Thoughts.php, index.language.php, script.js)
* Translation. (index.french.php)
| 1. | This one's for Pete... After he suggested We will rock you and We are the champions, and then this, I thought it'd be funnier to say oldSMF's anthem rather than ours :niark:) |
3474
Features / Re: Saving Bytes Every Page - Or, How I Learned To Stop Worrying And Enhance Search
« on March 6th, 2013, 04:32 PM »Been busy, sorry, I'll look at it shortly.
Also, I think you missed my bit about thematic groupings of htmlspecialchar & derivates. Although I'm pretty sure you'll disagre... (If only because it requires refactoring everything...)
Users actually press the button? I thought they just pressed enter for simple searching?
Anyway, if there's no button, and no JS thus no popup, you still have to rely on JS (AFAIK) to automatically submit the input box when pressing Enter...
Sounds like a plan.Quote - Add 'containing all these words..' etc select box to the popup
Dislike this idea for the same reason as I said about the notifications - if the sidebar is collapsed, it's not accessible easily.
Also, as a heads-up, there is going to be a selector growing on there for what should be searched (whole forum, current board, current topic, thoughts, calendar, other items yet to be determined), haven't decided exactly how to handle that yet.
I'd already busy trying to get my thoughts rewrite to a commitable state.
3475
The Pub / Re: Remove \
« on March 6th, 2013, 12:07 PM »
I don't know. I was very happy with default mode until I discovered convo mode.
Oh, and one thing to take care of... If you click 'Mark unread' on your latest PM (convo or whatever), you're sent back to the PM page, meaning it's never marked unread...
We could either have a convo homepage without any PMs below it, or redirect to the forum homepage after marking the latest PM as unread.
Oh, and one thing to take care of... If you click 'Mark unread' on your latest PM (convo or whatever), you're sent back to the PM page, meaning it's never marked unread...
We could either have a convo homepage without any PMs below it, or redirect to the forum homepage after marking the latest PM as unread.
3476
The Pub / Re: Spell checker
« on March 6th, 2013, 11:28 AM »
I didn't forget about that feature :)
And I like it, although it has a very high failure rate at offering 'sensible' words to search for.
My view of it is that we could keep this specific feature, because it's only used in Search2.php anyway, and get rid of the rest. Maybe also implement support for enchant for that one, too..?
And I like it, although it has a very high failure rate at offering 'sensible' words to search for.
My view of it is that we could keep this specific feature, because it's only used in Search2.php anyway, and get rid of the rest. Maybe also implement support for enchant for that one, too..?
3477
Features / Re: Saving Bytes Every Page - Or, How I Learned To Stop Worrying And Enhance Search
« on March 6th, 2013, 11:26 AM »
So... Those with SVN access...? What do you think about the 'final popup'...?
I'll do a site update this weekend, with all the new changes. It's already late by nearly 20 revs.... :-/
Some ideas for the future of quick search...
- Get rid of the Search button in HTML. Pro: there's already a search button in the popup. Con: if JS is disabled, it won't work.
- Add 'containing all these words..' etc select box to the popup
- Use a magnifier icon on the Search button in the popup..???
- Move search box by default to the sidebar, since it will be narrow enough to accommodate any sidebar width.
Opinions..?
I'll do a site update this weekend, with all the new changes. It's already late by nearly 20 revs.... :-/
Posted: March 6th, 2013, 08:31 AM
Some ideas for the future of quick search...
- Get rid of the Search button in HTML. Pro: there's already a search button in the popup. Con: if JS is disabled, it won't work.
- Add 'containing all these words..' etc select box to the popup
- Use a magnifier icon on the Search button in the popup..???
- Move search box by default to the sidebar, since it will be narrow enough to accommodate any sidebar width.
Opinions..?
3478
Features / Re: New revs
« on March 6th, 2013, 11:18 AM »
rev 1976 - Tê Tê Tê, Têtêretê. Tê Tê, Têtêretê. Tê Tê, Têtêretê. Tê Tê
(7 files, 3kb)
* Simplified JumpTo function to avoid a test in all index template executions. (Ajax.php, index.template.php, script.js)
* More $scripturl killings. (Split.php, Stats.php, Subs-Menu.php)
- Unneeded global. (Display.template.php)
(7 files, 3kb)
* Simplified JumpTo function to avoid a test in all index template executions. (Ajax.php, index.template.php, script.js)
* More $scripturl killings. (Split.php, Stats.php, Subs-Menu.php)
- Unneeded global. (Display.template.php)
3479
The Pub / Re: Remove \
« on March 6th, 2013, 07:41 AM »
hmmm..
This is something I'd only be willing to do if we had a 'backup all of my PMs in a HTML file' option like the one I remember from IPB 1.x.
Not saying what you're saying isn't sane... It's just that I tend to miss that one!
Also, known bug... I'll just say: I'm very wary of touching htmlspecialchars & co. code. I think maybe we should make several versions (just like we have westr::safe), and sort them by 'role', rather than something else. For instance: a function to sanitize stuff that's being used with MySQL or whatever... Another one to sanitize JavaScript stuff, another to sanitize HTML entries that need to have double quotes removed (i.e. used inside a tag param), etc...
This is something I'd only be willing to do if we had a 'backup all of my PMs in a HTML file' option like the one I remember from IPB 1.x.
Not saying what you're saying isn't sane... It's just that I tend to miss that one!
Also, known bug... I'll just say: I'm very wary of touching htmlspecialchars & co. code. I think maybe we should make several versions (just like we have westr::safe), and sort them by 'role', rather than something else. For instance: a function to sanitize stuff that's being used with MySQL or whatever... Another one to sanitize JavaScript stuff, another to sanitize HTML entries that need to have double quotes removed (i.e. used inside a tag param), etc...