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
2236
The Pub / Is the admin area in urgent need of an overhaul?
« on November 20th, 2013, 11:21 PM »
This was Pete's domain. I barely ever touched it in the 3 years I worked on Wedge.
Ever since I decided to remove theme support, I've had to cope with admin. It's just horrible.
Perhaps the worst offender is the 'general settings' page, which uses a completely different format for option lists. As far as I can tell, the ONLY reason for this difference is that these settings can either be saved to the database (as usual), or to a 'file' (i.e. Settings.php), but I don't really see why this can't be put into a special setting in prepareDBSettingContext, e.g. array('check', 'my_variable', 'where' => 'file'),... And voilà, the setting is going to be saved to the file instead.
What do you think? Can anyone think of a reason why it would fail?
Also, this special list has up to FIVE different non-keyed items. That's madness. name, label, target (file/db), type, size and help. It also accepts a keyed item, 'subtext'. It really, really doesn't make sense. The regular system has type, name/label/help (they're all linked together), and size/select-box content (depending on whether it's an int or an array.) It's much simpler to me, because usually all of these variables use the same $txt, $helptxt etc. for their descriptions.
Pages that use the 'weird' system:
- General settings
- Mail settings (webmaster e-mail goes to file)
- Server settings (maintenance status goes to file)
- Database settings (obviously)
- Cookie settings (cookie name goes to file)
- Debug settings (db_show_debug goes to file)
Apart from these, the rest uses prepareDBSettingContext, which is simpler.
Example:
array('autoFixDatabase', $txt['autoFixDatabase'], 'db', 'check', false, 'autoFixDatabase'),
Would become:
array('check', 'autoFixDatabase'),
Well, sure. That's a bit better...
Also, on another note. I'm currently in the mood for getting rid of 'small' admin pages with a reduced number of settings. The 'thing' with SMF 2.0 was to split long pages of settings to multiple pages. As a result, I tend to take some time looking for an option, when I could just hit the general settings page and hope that the option is in there (ctrl+F on the page). I've never been into the custom search engine for the admin area.
One thing that I like about FluxBB is that its entire admin area is split over a limited number of pages; it doesn't have a LOT of options of course, but I appreciated that my test setup of FluxBB was done by simply going to the admin area, looking at the general settings page, going through each option, and selecting what I wanted. In SMF 2.0/Wedge, I have to specifically click to multiple pages just to get the thing started (e.g. instead of general settings > minify JS/CSS, I have to also go to server settings...)
I took the Likes page (2 settings!) and moved it to general settings. I also took general member settings (enable contact lists, etc.), and moved them to the general settings as well.
I'm aware that it's a question of method. There are people who'll prefer the SMF 2 way, and others who'll prefer to have a long page with everything in it, as long as sections are clearly separated (in Wedge, I'm adding headers and big icons next to these headers, that should be more than enough.)
I'm interested in seeing who are the most vocal, though. Personally, I'll be vocal about avoiding multiple pages when they could be merged together. ;)
Ever since I decided to remove theme support, I've had to cope with admin. It's just horrible.
Perhaps the worst offender is the 'general settings' page, which uses a completely different format for option lists. As far as I can tell, the ONLY reason for this difference is that these settings can either be saved to the database (as usual), or to a 'file' (i.e. Settings.php), but I don't really see why this can't be put into a special setting in prepareDBSettingContext, e.g. array('check', 'my_variable', 'where' => 'file'),... And voilà, the setting is going to be saved to the file instead.
What do you think? Can anyone think of a reason why it would fail?
Also, this special list has up to FIVE different non-keyed items. That's madness. name, label, target (file/db), type, size and help. It also accepts a keyed item, 'subtext'. It really, really doesn't make sense. The regular system has type, name/label/help (they're all linked together), and size/select-box content (depending on whether it's an int or an array.) It's much simpler to me, because usually all of these variables use the same $txt, $helptxt etc. for their descriptions.
Pages that use the 'weird' system:
- General settings
- Mail settings (webmaster e-mail goes to file)
- Server settings (maintenance status goes to file)
- Database settings (obviously)
- Cookie settings (cookie name goes to file)
- Debug settings (db_show_debug goes to file)
Apart from these, the rest uses prepareDBSettingContext, which is simpler.
Example:
array('autoFixDatabase', $txt['autoFixDatabase'], 'db', 'check', false, 'autoFixDatabase'),
Would become:
array('check', 'autoFixDatabase'),
Well, sure. That's a bit better...
Also, on another note. I'm currently in the mood for getting rid of 'small' admin pages with a reduced number of settings. The 'thing' with SMF 2.0 was to split long pages of settings to multiple pages. As a result, I tend to take some time looking for an option, when I could just hit the general settings page and hope that the option is in there (ctrl+F on the page). I've never been into the custom search engine for the admin area.
One thing that I like about FluxBB is that its entire admin area is split over a limited number of pages; it doesn't have a LOT of options of course, but I appreciated that my test setup of FluxBB was done by simply going to the admin area, looking at the general settings page, going through each option, and selecting what I wanted. In SMF 2.0/Wedge, I have to specifically click to multiple pages just to get the thing started (e.g. instead of general settings > minify JS/CSS, I have to also go to server settings...)
I took the Likes page (2 settings!) and moved it to general settings. I also took general member settings (enable contact lists, etc.), and moved them to the general settings as well.
I'm aware that it's a question of method. There are people who'll prefer the SMF 2 way, and others who'll prefer to have a long page with everything in it, as long as sections are clearly separated (in Wedge, I'm adding headers and big icons next to these headers, that should be more than enough.)
I'm interested in seeing who are the most vocal, though. Personally, I'll be vocal about avoiding multiple pages when they could be merged together. ;)
2237
Off-topic / Re: A short script to remove unused, useless globals in PHP.
« on November 20th, 2013, 10:55 PM »
Right now, the only false positives that can be found are:
Code: [Select]
As well as, hmm...
Code: [Select]
There may be other situations where it'll find false positives, but they'll probably be variations on the ones above.
Basically, I could try and remove comments, I'm doing it on Wess after all, but I'll have to restore them before fixing the files, and I can't bother for now. As for quotes, since there are single quotes and double quotes and heredoc and nowdoc, and... I don't know if I'll ever bother about that, unless I can find a script that removes these easily for me. (Keeping in mind they must also be restored.)
function foobar() {
/* This is a comment.
global $something;
*/
return;
}As well as, hmm...
function foobar() {
echo '
global $something;';
}There may be other situations where it'll find false positives, but they'll probably be variations on the ones above.
Basically, I could try and remove comments, I'm doing it on Wess after all, but I'll have to restore them before fixing the files, and I can't bother for now. As for quotes, since there are single quotes and double quotes and heredoc and nowdoc, and... I don't know if I'll ever bother about that, unless I can find a script that removes these easily for me. (Keeping in mind they must also be restored.)
2238
Off-topic / Re: A short script to remove unused, useless globals in PHP.
« on November 20th, 2013, 05:29 PM »
(Yay, first Google result on selected keywords from the post title. SEO isn't as bad as I thought :D)
Current script size is 120 lines, lol.
The next update will be MIT licensed, then. I'm still waiting for github to answer my e-mail, or anyone really.
SMF people will love it[1], because of the auto-fixer, and it had 100% accuracy on the Wedge codebase, I didn't have to do any last-minute fixes apart from one in ManagePlugins which helped strengthen the script even further.
Heck, I could even run the thing myself on SMF 2.1, and push that...
Current script size is 120 lines, lol.
The next update will be MIT licensed, then. I'm still waiting for github to answer my e-mail, or anyone really.
SMF people will love it[1], because of the auto-fixer, and it had 100% accuracy on the Wedge codebase, I didn't have to do any last-minute fixes apart from one in ManagePlugins which helped strengthen the script even further.
Heck, I could even run the thing myself on SMF 2.1, and push that...
| 1. | Well, everyone but Arantor, of course. |
2239
Archived fixes / Re: FF messing things up?
« on November 20th, 2013, 05:09 PM »
Interestingly (it's rare enough to mention it :P), the latest Firefox has a new CSS feature that's been in Chrome for eons, only it's buggy in Chrome, and it's not in Firefox -- for that reason, I'm currently implementing it in Firefox, but not so sure for Chrome.
2240
Features / Re: New revs
« on November 20th, 2013, 01:23 PM »
rev 2329 -- I would like to thank my humble unused-globals.php, and its newest feature, 'fix all files for me, duh.' Didn't save me the hassle of a manual check (in order to remove the couple of false positives I *did* find), but I still saved several hours overall.
62 files changed, 162 insertions(+), 197 deletions(-), 12.90 KiB
- Last, and biggest, batch of unneeded globals. There are some that are going to stay in for now, because they're in files I'm not ready to commit yet. (62 files, not listing them all!)
62 files changed, 162 insertions(+), 197 deletions(-), 12.90 KiB
- Last, and biggest, batch of unneeded globals. There are some that are going to stay in for now, because they're in files I'm not ready to commit yet. (62 files, not listing them all!)
2241
Archived fixes / Re: FF messing things up?
« on November 20th, 2013, 10:55 AM »
That's because I fixed it, as I said above. ;)
2242
Off-topic / Re: A short script to remove unused, useless globals in PHP.
« on November 20th, 2013, 10:54 AM »
It's all turned into a really, really nice little script by now. It does all the changes for me, too, if I ask nicely. I'm currently in the process of checking all files manually, it's all good. Only one single false-positive so far, and that's because the global keyword was in comments, so I added an extra check for that (it won't work in multi-line comments, though.)
And I really should commit it! But I have yet to receive an answer from github, re: my account/e-mail problems. I don't want to have to re-create my repo later, so... Waiting for now.
And I really should commit it! But I have yet to receive an answer from github, re: my account/e-mail problems. I don't want to have to re-create my repo later, so... Waiting for now.
2243
Features / Re: New revs
« on November 19th, 2013, 08:04 PM »
rev 2328
7 files changed, 48 insertions(+), 70 deletions(-), 10.47 KiB (definitely doesn't represent the real patch size; it's not that big.)
* Harmonized template_button_strip calls to always use the return value. (index.template.php, Media.template.php, Recent.template.php, Reports.template.php)
* Turns out that wesql::insert CAN return a success value, it was just a matter of checking out the PHP documentation, not MySQL's. (Class-DB.php, Load.php)
* Cleaned up installer code: removed unused globals, harmonized all required-version variables into constants, and all constants are defined at startup. (install.php)
7 files changed, 48 insertions(+), 70 deletions(-), 10.47 KiB (definitely doesn't represent the real patch size; it's not that big.)
* Harmonized template_button_strip calls to always use the return value. (index.template.php, Media.template.php, Recent.template.php, Reports.template.php)
* Turns out that wesql::insert CAN return a success value, it was just a matter of checking out the PHP documentation, not MySQL's. (Class-DB.php, Load.php)
* Cleaned up installer code: removed unused globals, harmonized all required-version variables into constants, and all constants are defined at startup. (install.php)
2244
Features / Re: New revs
« on November 19th, 2013, 08:03 PM »
rev 2327
21 files changed, 50 insertions(+), 62 deletions(-), 2.47 KiB
- More unused globals. Since I just spent an hour manually checking these and fixing them (about 70 entries), and had no false positives at all, it's awfully tempting to write some code to remove these automatically before a manual check at commit time... (SOURCES: Like, ManageSmileys, Merge, Modlog, MoveTopic, PersonalMessage, Poll, Post, Post2, PrettyUrls-Filters, PrintPage, Profile-Actions, Profile-View, Profile, Subs, Suggest, ViewQuery, ViewRemote, Welcome, Aeva-Embed, Aeva-Foxy)
21 files changed, 50 insertions(+), 62 deletions(-), 2.47 KiB
- More unused globals. Since I just spent an hour manually checking these and fixing them (about 70 entries), and had no false positives at all, it's awfully tempting to write some code to remove these automatically before a manual check at commit time... (SOURCES: Like, ManageSmileys, Merge, Modlog, MoveTopic, PersonalMessage, Poll, Post, Post2, PrettyUrls-Filters, PrintPage, Profile-Actions, Profile-View, Profile, Subs, Suggest, ViewQuery, ViewRemote, Welcome, Aeva-Embed, Aeva-Foxy)
2245
Off-topic / Re: A short script to remove unused, useless globals in PHP.
« on November 19th, 2013, 05:19 PM »
I made some improvements to the script (it will now find more unused vars than before), so I guess it makes sense to use git for that; I'll be moving to a github repo so that I can commit if I have other things to update.
This will be my first 'real' use of github though, and I'm wondering if it's worth hiding my e-mail address over there. Also, using the antispam feature, my e-mail address starts with "Naowe@" (my old user-name), when it's been renamed for quite a long time to "Nao@"... Dunno why it's still using that old name. Anyone knows how to fix, maybe..?
PS: let's just say it's going to be... well, my very own github tutorial.
This will be my first 'real' use of github though, and I'm wondering if it's worth hiding my e-mail address over there. Also, using the antispam feature, my e-mail address starts with "Naowe@" (my old user-name), when it's been renamed for quite a long time to "Nao@"... Dunno why it's still using that old name. Anyone knows how to fix, maybe..?
PS: let's just say it's going to be... well, my very own github tutorial.
2246
The Pub / Re: git problems for non-gits.
« on November 19th, 2013, 12:25 PM »
I think the merge workflow won't work for Wedge. See latest commit. I do appreciate having graphs with branches etc, but (1) I'm not sure I like the extra commit for branch merges, and (2) I have this feeling that merging requires doing serious branching work, and I'm... really, really not that much into branching for everyday work. Or even for any kind of work. I just systematically work on multiple features at the time in one file, and am used to simply committing partial versions of these files, then restoring them, etc. It's my workflow. It looks like it's closer to what a rebase workflow would work with.
Am I wrong to assume that?
And, how would I 'efficiently' go for a rebase workflow (now that I *know* that rebasing is pretty much okay), while still keeping the pull request system? Is it even possible?
PS: the TortoiseGitBlame bug was fixed. :) Can't wait for the next preview release, yay!
Am I wrong to assume that?
And, how would I 'efficiently' go for a rebase workflow (now that I *know* that rebasing is pretty much okay), while still keeping the pull request system? Is it even possible?
PS: the TortoiseGitBlame bug was fixed. :) Can't wait for the next preview release, yay!
2247
Features / Re: New revs
« on November 19th, 2013, 12:20 PM »
rev 2326 -- note: I had to do a push --force to prevent a dirty repo. This is because I made an --amend on the latest pull request merge, and forgot to immediately push force it, so... Apologies if you end up with a broken repo when you pull.
11 files changed, 46 insertions(+), 213 deletions(-), 3.33 KiB
* Previous/next topic links will now jump to the latest post, rather than the latest post in their first page (what the..?!) (Display.php)
* Simplified or improved some Unread code. If topic has no replies, don't bother with the #new anchor or a msg variable. Got rid of msg anchors as much as possible. Removed href and link variables, as they're unused duplicates. (Unread.php, UnreadReplies.php)
* Merged Unread/UnreadReplies templates back together, with a template param to differentiate them. This also gives me an opportunity to show that it's easy to set a template param through wetem::load(). Note, though, that specifying 'unread:false' wouldn't work, as 'false' is a non-false string value. I know, it's kind of counter-productive, but you can still use 'unread:true' for readability, and fall back to 'unread' (if the param has a false default) or 'unread:0' to specify false. (Recent.template.php)
* Again, don't link to a #new anchor if topic has no replies. (MessageIndex.php)
- Unneeded globals. (Boards.php, Home.php, Welcome.php, Subs-Media.php)
- Unneeded $custom_table parameters in addData() and addSeparator(). They were never used, and I have no plans to extend reports any further. (Reports.php)
- Unneeded $context['topics'][$id]['newtime']. (MessageIndex.php)
- $theme['show_member_bar'] was never used. (Boards.php, Home.php, Welcome.php)
* Micro-optimizations. Don't bother. (Errors.php)
11 files changed, 46 insertions(+), 213 deletions(-), 3.33 KiB
* Previous/next topic links will now jump to the latest post, rather than the latest post in their first page (what the..?!) (Display.php)
* Simplified or improved some Unread code. If topic has no replies, don't bother with the #new anchor or a msg variable. Got rid of msg anchors as much as possible. Removed href and link variables, as they're unused duplicates. (Unread.php, UnreadReplies.php)
* Merged Unread/UnreadReplies templates back together, with a template param to differentiate them. This also gives me an opportunity to show that it's easy to set a template param through wetem::load(). Note, though, that specifying 'unread:false' wouldn't work, as 'false' is a non-false string value. I know, it's kind of counter-productive, but you can still use 'unread:true' for readability, and fall back to 'unread' (if the param has a false default) or 'unread:0' to specify false. (Recent.template.php)
* Again, don't link to a #new anchor if topic has no replies. (MessageIndex.php)
- Unneeded globals. (Boards.php, Home.php, Welcome.php, Subs-Media.php)
- Unneeded $custom_table parameters in addData() and addSeparator(). They were never used, and I have no plans to extend reports any further. (Reports.php)
- Unneeded $context['topics'][$id]['newtime']. (MessageIndex.php)
- $theme['show_member_bar'] was never used. (Boards.php, Home.php, Welcome.php)
* Micro-optimizations. Don't bother. (Errors.php)
2248
Off-topic / Re: A short script to remove unused, useless globals in PHP.
« on November 19th, 2013, 09:33 AM »
Oh my, I forgot you liked complex interfaces for small operations... Cf. your analyzer :lol:
So, should I expect you to come by, fork my code and turn it into a giga-script? Then you can do that right now, since it's a WTF file... You don't even have to credit me for the original code, although it'd be nice if you did.
If not, then I'll create my repo all right, but I just don't expect to modify the code any more.
Well, maybe I should also move the 'attic', or even the entire 'other' folder, to another repo. But I've never done that, and don't know if it's easy to do. (Again-- filter-branch. Ouch...)
PS: considering that Wedge will soon modify a few fundamentals of SMF such as folder structure and $theme stuff, are you willing to look into the importer when I do, and make sure it doesn't break..?
So, should I expect you to come by, fork my code and turn it into a giga-script? Then you can do that right now, since it's a WTF file... You don't even have to credit me for the original code, although it'd be nice if you did.
If not, then I'll create my repo all right, but I just don't expect to modify the code any more.
Well, maybe I should also move the 'attic', or even the entire 'other' folder, to another repo. But I've never done that, and don't know if it's easy to do. (Again-- filter-branch. Ouch...)
PS: considering that Wedge will soon modify a few fundamentals of SMF such as folder structure and $theme stuff, are you willing to look into the importer when I do, and make sure it doesn't break..?
2249
Off-topic / Re: Doctor Who
« on November 19th, 2013, 09:24 AM »Yes, but the material have been re-digitized because the quality IS better, judging from some illegal copies I found on the net(..). At least to 720p, I don't think its possible to do proper 1080p, you start seeing the tweening pixels then. But then again, resizing techniques have come a long way since..well, forever.
As for upscaling, all of the BluRay upscales I've seen in my life were horrible. Oh, my, my eyes still ache at the thought of Blue Submarine 6... Was such a great show, and so proud of its tech advancements at the time (it was one of the first anime to (clumsily) integrate 3D), and the BluRay release is just a resized 480p. Really, I have yet to see a proper upscale that 'guesses' intermediate pixels instead of interpolating them. Any examples..?
Thankfully, not all re-releases are badly done. For instance, one of my favorite movies -- "Waga seishun no Arcadia" (I'm sure you saw it as a kid) is absolutely stunning in its 720p remastered edition.
An example, the future episodes in almost every seasons 2005 onwards..always something about society that is brought up, often common themes in serious sci-fi literature/films(NOT the Star Wars/Star Trek stuff).
I don't mean to say Doctor Who is not, or was never relevant societally. But Star Trek, while it came later, pioneered the whole concept of using alien civilizations to represent human dystopias.
And the brits do have advantage in this area, they can really combine that seriousness with goofy/dark humour. And if done good, even frightening so. A fav of mine in that respect is the movie "Children of Men".
2250
Archived fixes / Re: FF messing things up?
« on November 19th, 2013, 09:10 AM »
It only works in Chrome because as there's a *vertical* scrollbar. If there's an *horizontal* scrollbar bar but NO vertical scrollbar, it starts behaving exactly the same as Firefox here, unless you do that: $('.post code').css('flex', 'none'); (This hack is signed yours truly. Of course, don't execute it if there's a vertical scrollbar or no horizontal scrollbar on that element. As a result, the code in Wedge is more complicated than that.)
I still don't know why both browsers fail at that, really. Flexbox is supposed to be the next big thing.
As a reminder, iOS 7 also supports flexbox, and also fails with it, this time with suggested flex widths.
I still don't know why both browsers fail at that, really. Flexbox is supposed to be the next big thing.
As a reminder, iOS 7 also supports flexbox, and also fails with it, this time with suggested flex widths.