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
2206
The Pub / Re: Is the admin area in urgent need of an overhaul?
« on November 25th, 2013, 09:57 PM »
It's just that it's all related...
1- Settings all in one place: can easily mark a variable as 'overridable', meaning I can store everything in $settings and then have users override these settings with their own preference.
2- This allows me to remove $theme entirely, and thus makes it easier to remove theme support entirely.
3- Which then allows me to properly redo the file structure change...
4- And then it flags it as 'publicly viewable', since it's a pain for anyone who's installed a beta before, to see all files being moved, and having to reupload everything and clean up their unused folders.
2 can be done without 1, though. I could, for instance, keep using the theme table, and then when retrieving $themeData, instead of moving options to either $theme or $options[1], a first step could be to merge ALL three arrays together: $options overrides $theme, which overrides $settings. So, basically, $settings = array_merge($settings, $themeData[0], $themeData[$member]) should work just fine. I don't know exactly, since I haven't even tried it, but it should make all things simpler already.
With this half-arsed method, I still have to deal with that strange little 'theme' table that is separate from the 'settings' table, but it's only an internal problem. I also can't retrieve 'overridable' $settings and automatically build a list of them for users to modify in their profile. That's the big annoyance to me, but... Well, I don't know, maybe I'm just too anal about it.
What do you think..?
(I know I'm reaching for opinions a little too obviously, but the relative silence these days in this forum is deafening to me, because I really rely on 'regular user' opinions to determine whether I'm doing things right, or I'm doing changes that are useless to most people, and thus a waste of time that would better be spent elsewhere. But where, ah ah, don't ask me.)
1- Settings all in one place: can easily mark a variable as 'overridable', meaning I can store everything in $settings and then have users override these settings with their own preference.
2- This allows me to remove $theme entirely, and thus makes it easier to remove theme support entirely.
3- Which then allows me to properly redo the file structure change...
4- And then it flags it as 'publicly viewable', since it's a pain for anyone who's installed a beta before, to see all files being moved, and having to reupload everything and clean up their unused folders.
2 can be done without 1, though. I could, for instance, keep using the theme table, and then when retrieving $themeData, instead of moving options to either $theme or $options[1], a first step could be to merge ALL three arrays together: $options overrides $theme, which overrides $settings. So, basically, $settings = array_merge($settings, $themeData[0], $themeData[$member]) should work just fine. I don't know exactly, since I haven't even tried it, but it should make all things simpler already.
With this half-arsed method, I still have to deal with that strange little 'theme' table that is separate from the 'settings' table, but it's only an internal problem. I also can't retrieve 'overridable' $settings and automatically build a list of them for users to modify in their profile. That's the big annoyance to me, but... Well, I don't know, maybe I'm just too anal about it.
What do you think..?
(I know I'm reaching for opinions a little too obviously, but the relative silence these days in this forum is deafening to me, because I really rely on 'regular user' opinions to determine whether I'm doing things right, or I'm doing changes that are useless to most people, and thus a waste of time that would better be spent elsewhere. But where, ah ah, don't ask me.)
| 1. | To avoid confusion, Wedge has $settings, $theme and $options, where SMF has respectively $modSettings, $settings and $options, which is one of the strangest ways of doing things because $settings are 'higher up' than $modSettings, in all logic, but in SMF's logic, they aren't, so... |
2207
Off-topic / Re: Doctor Who
« on November 25th, 2013, 09:43 PM »
So, it's not even as good as the files you saw flying around earlier..?
2208
Off-topic / Re: Zend OPCache & APC
« on November 25th, 2013, 09:17 PM »
Lol I was googling "opcache vs APC" and this came up like in third position... ;)
2209
Off-topic / Re: Doctor Who
« on November 25th, 2013, 08:53 AM »http://www.doctorwho.tv/whats-new/article/doctor-who-complete-series-1-7-comes-to-blu-ray/
Heh, it seems 1080p is whats being offered, the one I found was "only" 720p. Me wants :D
It just looks like the print quality for the TV re-runs I've been seeing on France4 a few months ago for series 1. That is, "DVD quality, but a tad better."
Nothing to run home for...
2210
The Pub / Re: Is the admin area in urgent need of an overhaul?
« on November 25th, 2013, 08:27 AM »
I only got a 'like' on the post above, and I don't know if it's for the former part ('settings menu'), or latter ('time consuming, might be best to work on other things'), and no 'real words' comments, so it's hard to guess.
For now I guess I'll just focus on finishing what's on the grill right now, hmm.
For now I guess I'll just focus on finishing what's on the grill right now, hmm.
2211
Features / Re: New revs
« on November 25th, 2013, 12:04 AM »
rev 2335 -- sorry for this boring 'maintenance' commit, I'm trying to reduce my number of uncommitted files.
15 files changed, 22 insertions(+), 58 deletions(-), 2.33 KiB
* message_index_preview is a 'custom' setting set by themes, and as such, I think it should be in $context rather than $theme, which is 'automatically' built from the database. I also commented out that famous 'example' in the index template, because there's no need to grow internal arrays for nothing. (MessageIndex.php, Unread.php, UnreadReplies.php, index.template.php)
- Removed ability for 'themes' to set a default smiley set. Maybe I'll restore it later, but done differently. (JSOption.php, Load.php, Subs-Members.php, Themes.php, Profile.template.php, Admin.language.php)
- Some of the latest SQL changes were a bit too early in my workflow. I should probably postpone that until the code is actually ready... (install.sql)
15 files changed, 22 insertions(+), 58 deletions(-), 2.33 KiB
* message_index_preview is a 'custom' setting set by themes, and as such, I think it should be in $context rather than $theme, which is 'automatically' built from the database. I also commented out that famous 'example' in the index template, because there's no need to grow internal arrays for nothing. (MessageIndex.php, Unread.php, UnreadReplies.php, index.template.php)
- Removed ability for 'themes' to set a default smiley set. Maybe I'll restore it later, but done differently. (JSOption.php, Load.php, Subs-Members.php, Themes.php, Profile.template.php, Admin.language.php)
- Some of the latest SQL changes were a bit too early in my workflow. I should probably postpone that until the code is actually ready... (install.sql)
2212
The Pub / Re: Is the admin area in urgent need of an overhaul?
« on November 25th, 2013, 12:03 AM »
So... Would this layout make sense?
- A 'Settings' drop menu,
- And other drop menus similar to what we have now.
The 'Settings' menu would have ALL settings pages from all other features, allowing you to: (1) quickly find where to enable/disable a setting, (2) determine if a setting can be overridden by users, (3) maybe have 'quick links' (next to each setting section) pointing to other pages in the menu that deal with related items, e.g. the Aeva embedding setting section could have a link to the Site list.
All settings would be, if possible, in as few pages as possible. They'd all be abstracted, i.e. each section would be built the same war ($config_vars), but individual entries could also specify 'prepare' and 'process' (or 'save') array items, which would hold a function name. These would, of course, be callbacks, that tell Wedge to execute some extra code on page load, or when saving the item if it has changed.
This would require/allow merging $settings, $theme and $options together (mostly?), although I don't know if this has been that much of a problem to SMF users so far. It has been to me, but I'm not everyone.
Is it a bit too ambitious? Or uncalled for..? I have a feeling it might be. This rewrite could take weeks (at best days) to complete, maybe this time could be better used on finishing contact lists or privacy, I don't know. :-/
- A 'Settings' drop menu,
- And other drop menus similar to what we have now.
The 'Settings' menu would have ALL settings pages from all other features, allowing you to: (1) quickly find where to enable/disable a setting, (2) determine if a setting can be overridden by users, (3) maybe have 'quick links' (next to each setting section) pointing to other pages in the menu that deal with related items, e.g. the Aeva embedding setting section could have a link to the Site list.
All settings would be, if possible, in as few pages as possible. They'd all be abstracted, i.e. each section would be built the same war ($config_vars), but individual entries could also specify 'prepare' and 'process' (or 'save') array items, which would hold a function name. These would, of course, be callbacks, that tell Wedge to execute some extra code on page load, or when saving the item if it has changed.
This would require/allow merging $settings, $theme and $options together (mostly?), although I don't know if this has been that much of a problem to SMF users so far. It has been to me, but I'm not everyone.
Is it a bit too ambitious? Or uncalled for..? I have a feeling it might be. This rewrite could take weeks (at best days) to complete, maybe this time could be better used on finishing contact lists or privacy, I don't know. :-/
2213
Features / Re: New revs
« on November 24th, 2013, 06:37 PM »
rev 2334
8 files changed, 5 insertions(+), 20 deletions(-), 1.33 KiB
* Trying a universal border-box. We'll see how it fares. I'm a bit pessimistic, but I'd be glad if it works. (editor.css, index.css, index.member.css, mana.css, media.css, sections.css, zoom.css, Wireless/extra.css)
* A couple of other, minor fixes. Hmm, what's the point in committing border-box separately if I can't just mindlessly revert it because of that? Well? Well, I'm sure there's a point. (sections.css)
8 files changed, 5 insertions(+), 20 deletions(-), 1.33 KiB
* Trying a universal border-box. We'll see how it fares. I'm a bit pessimistic, but I'd be glad if it works. (editor.css, index.css, index.member.css, mana.css, media.css, sections.css, zoom.css, Wireless/extra.css)
* A couple of other, minor fixes. Hmm, what's the point in committing border-box separately if I can't just mindlessly revert it because of that? Well? Well, I'm sure there's a point. (sections.css)
2214
Features / Re: New revs
« on November 24th, 2013, 06:35 PM »
rev 2333
15 files changed, 76 insertions(+), 64 deletions(-), 11.41 KiB
+ A nice little rewrite of the language flags system. Mostly, they're now shown in a select box, so that you can add support for as many languages as you want, without disrupting the layout. Also, I've tweaked the sidebar to allow moving the language selector over there in case you're using a mobile skin. (Subs-Cache.php, Profile-Modify.php, Admin.template.php, index.template.php, skeleton.xml)
* A tweak to the .inline-block mixin allows you to directly remove vertical-align (or change its value from the default "middle") by specifying an empty parameter (mixes .inline-block(""), basically.) (Subs-Cache.php, common.css)
* Added a few separators in the admin menu. (Admin.php)
* Minor tweaks, spacinazi, globalnazi, thoughtihadcommittedthatnazi. (JSOption.php, Load.php, ManageLanguages.php, ManageModeration.php, Profile-Modify.php, Subs-Members.php, MessageIndex.template.php, detailed-version.php)
! Fixed another quick edit bug. (This was fixed on wedge.org some time ago, just forgot to commit it.) (QuoteFast.php)
15 files changed, 76 insertions(+), 64 deletions(-), 11.41 KiB
+ A nice little rewrite of the language flags system. Mostly, they're now shown in a select box, so that you can add support for as many languages as you want, without disrupting the layout. Also, I've tweaked the sidebar to allow moving the language selector over there in case you're using a mobile skin. (Subs-Cache.php, Profile-Modify.php, Admin.template.php, index.template.php, skeleton.xml)
* A tweak to the .inline-block mixin allows you to directly remove vertical-align (or change its value from the default "middle") by specifying an empty parameter (mixes .inline-block(""), basically.) (Subs-Cache.php, common.css)
* Added a few separators in the admin menu. (Admin.php)
* Minor tweaks, spacinazi, globalnazi, thoughtihadcommittedthatnazi. (JSOption.php, Load.php, ManageLanguages.php, ManageModeration.php, Profile-Modify.php, Subs-Members.php, MessageIndex.template.php, detailed-version.php)
! Fixed another quick edit bug. (This was fixed on wedge.org some time ago, just forgot to commit it.) (QuoteFast.php)
2215
Off-topic / Re: A short script to remove unused, useless globals in PHP.
« on November 24th, 2013, 06:09 PM »
Well, I would usually say that, but considering that the default URLs given out by GH are '/Wedge', and that to force it to use '/wedge' I have to change the project's name, and I don't want its name to be lowercased, I guess I'll have to settle on /Wedge, because I don't see myself changing that every single time I post a link to the repo... :lol:
2216
Off-topic / Re: Doctor Who
« on November 24th, 2013, 06:08 PM »
@forumsearch0r, you'll be hard pressed to avoid spoilers for this, as everyone who's interested in this has probably already watched it by now, since it was simulcast all over the world. ;)
@Aaron> I'm guessing, well... Maybe, just maybe, their planet wasn't destroyed in the time war in the end? (Assuming it was close to Gallifrey and was caught up in the explosion, or something?) I don't remember how it was told. Anyway, last we saw of them, they were 'negotiating' with the Humans, but I doubt this means they gave them land underground, because there are already lizards in there. :P
@Aaron> I'm guessing, well... Maybe, just maybe, their planet wasn't destroyed in the time war in the end? (Assuming it was close to Gallifrey and was caught up in the explosion, or something?) I don't remember how it was told. Anyway, last we saw of them, they were 'negotiating' with the Humans, but I doubt this means they gave them land underground, because there are already lizards in there. :P
2217
Off-topic / Re: Doctor Who
« on November 24th, 2013, 01:38 PM »
- I've taken the liberty to move the topic to the public area. There's nothing to hide in it, and I wanted to celebrate page 42 on a geeky topic. Whatever.[1]
- I rewatched bits of the episode. I have to say, the French translator of Doctor Who does a really bad job. And she's being paid for that, I guess. Yesterday I saw a Big Bang Theory episode on French TV where Raj was saying he'd always be known as the guy who got a girlfriend *after* Sheldon. The subtitles read, 'as the guy who got fooled by Sheldon'. Oh, my. Seriously, I'm appreciative that French TV is starting to show original language versions with subtitles everywhere, but sometimes, I can really do without subs of that 'quality'... As a result, I had to fetch the BBC subtitles, and that was better.
So, basically, the French translation made it very clear that the Curator wasn't the Doctor. What I heard, and it was confirmed by the English subtitles, is that he IS the Doctor, at a very old age, 'revisiting' his old favorite faces. Holy cow...
The whole 'sand shoes' thing was also translated as 'baskets', which is French for 'atheltic shoes'. It isn't the same at all, is it..?! In France, we'd just say Converses. Plus his shoes in the episode were definitely not what we'd call baskets in France. More like 'tennis' (I need to have a better look to confirm). Or again, Converses. That kind of approximative translation happened all the time during the episode, it was a bit frustrating.
- A short 18-second deleted scene was also released on YouTube, but I didn't get the 'not since Richmond' line, so I guess the joke fell flat to me.
- I read criticism about the fact that Moffat often offers a deus-ex-machina to resolve his stories. That's true. That was the case here. But how many times have you watched a procedural where we find out at the last minute that the killer was someone we could never have expected because of a clue that the writer never told us about..? That's exactly the same. As long as it's a fun ride, it doesn't matter how it ends.
- All in all, it was a great episode, possibly the best in years (mostly thanks to all of the great cameos.)
- I rewatched bits of the episode. I have to say, the French translator of Doctor Who does a really bad job. And she's being paid for that, I guess. Yesterday I saw a Big Bang Theory episode on French TV where Raj was saying he'd always be known as the guy who got a girlfriend *after* Sheldon. The subtitles read, 'as the guy who got fooled by Sheldon'. Oh, my. Seriously, I'm appreciative that French TV is starting to show original language versions with subtitles everywhere, but sometimes, I can really do without subs of that 'quality'... As a result, I had to fetch the BBC subtitles, and that was better.
So, basically, the French translation made it very clear that the Curator wasn't the Doctor. What I heard, and it was confirmed by the English subtitles, is that he IS the Doctor, at a very old age, 'revisiting' his old favorite faces. Holy cow...
The whole 'sand shoes' thing was also translated as 'baskets', which is French for 'atheltic shoes'. It isn't the same at all, is it..?! In France, we'd just say Converses. Plus his shoes in the episode were definitely not what we'd call baskets in France. More like 'tennis' (I need to have a better look to confirm). Or again, Converses. That kind of approximative translation happened all the time during the episode, it was a bit frustrating.
- A short 18-second deleted scene was also released on YouTube, but I didn't get the 'not since Richmond' line, so I guess the joke fell flat to me.
- I read criticism about the fact that Moffat often offers a deus-ex-machina to resolve his stories. That's true. That was the case here. But how many times have you watched a procedural where we find out at the last minute that the killer was someone we could never have expected because of a clue that the writer never told us about..? That's exactly the same. As long as it's a fun ride, it doesn't matter how it ends.
- All in all, it was a great episode, possibly the best in years (mostly thanks to all of the great cameos.)
| 1. | Heck, there's nothing to hide in 99% of the private area. It was only 'private' because Wedge was a private project at the time. I would move everything to public, but I don't think I can do that on a whim. Especially as it may put Pete in a bad position with SMF, considering all he said about them... :whistle: |
2218
Off-topic / Re: A short script to remove unused, useless globals in PHP.
« on November 24th, 2013, 12:12 PM »
And here we are... I made a changelog, so I might as well post it.
Note: I just made a push -f to overwrite my initial commit with a UTF-8 version of the file. If you downloaded the repo previously, please re-clone it from scratch. Future commits will avoid forced pushes, I just thought -- who cares, it's an initial commit.
https://github.com/Wedge/tools/ (<-- hmm, should I adopt 'wedge' or 'Wedge' in the URL..?)
Released under the MIT license.
85 insertions(+), 8 deletions(-)
Auto-fixing, cosmetic updates and improvements.
+ The script will now attempt to fix the files for you, at least if they seem safe to work on. Add the ?fixme parameter, but don't forget to do a dry-run before.
@ Known potential false positives that aren't detected yet: globals declared inside a string (sometimes it'll work, in create_function for instance), and inside multi-line comments (i.e. commented out code.) If you use this script, don't fixme blindly, and check all changes manually before committing your work.
@ Duplicate globals aren't auto-fixed. You'll have to do these manually, at least for now.
+ Proper HTML styling. You no longer have to view-source in order to make it usable.
+ Support for all line-ending types.
- Removed false positive: use of 'global $something' inside a line (e.g. a comment), with text preceding it that isn't a bracket.
+ Adding a warning (and not auto-fixing) in case an unused global was found in a function, but also the following: $$ (perhaps a variable variable has your global name in it?), ${$ (another syntax for variable variables), include(), require() and their _once() variations. The script will indicate which of these it found, and keep going its way.
Note: I just made a push -f to overwrite my initial commit with a UTF-8 version of the file. If you downloaded the repo previously, please re-clone it from scratch. Future commits will avoid forced pushes, I just thought -- who cares, it's an initial commit.
https://github.com/Wedge/tools/ (<-- hmm, should I adopt 'wedge' or 'Wedge' in the URL..?)
Released under the MIT license.
85 insertions(+), 8 deletions(-)
Auto-fixing, cosmetic updates and improvements.
+ The script will now attempt to fix the files for you, at least if they seem safe to work on. Add the ?fixme parameter, but don't forget to do a dry-run before.
@ Known potential false positives that aren't detected yet: globals declared inside a string (sometimes it'll work, in create_function for instance), and inside multi-line comments (i.e. commented out code.) If you use this script, don't fixme blindly, and check all changes manually before committing your work.
@ Duplicate globals aren't auto-fixed. You'll have to do these manually, at least for now.
+ Proper HTML styling. You no longer have to view-source in order to make it usable.
+ Support for all line-ending types.
- Removed false positive: use of 'global $something' inside a line (e.g. a comment), with text preceding it that isn't a bracket.
+ Adding a warning (and not auto-fixing) in case an unused global was found in a function, but also the following: $$ (perhaps a variable variable has your global name in it?), ${$ (another syntax for variable variables), include(), require() and their _once() variations. The script will indicate which of these it found, and keep going its way.
2219
Off-topic / Re: A short script to remove unused, useless globals in PHP.
« on November 24th, 2013, 11:26 AM »
So, I received an answer from GH shortly after my last post here. :)
- They fixed my username,
- They're working on a fix for everyone who changes their username,
- They're looking into whether it's possible to choose your commit name when doing web merges.
Good!
In the meantime, I made some tests on a GH repo, and have come to these conclusions:
- (This, I already knew but it's important to point out) You can set your commit e-mail per-repo ('local') or for all repos ('global'), so if you want to change e-mails between repos, it's easy as pie, and if they're all in your GH account, then GH will always show your commits as yours.
- Antispam e-mails used when web merging at GH are really, really noreply e-mails. That is, e-mails to these aren't redirected to your actual registered e-mail, so... Hmm, I don't know, it can be a good thing, or a bad thing.
- TortoiseGit statistics only care about the user name. If my user name is 'Nao', whatever the commit e-mail is, the stats page will merge everything together into the Nao entry. Good.
- My commit e-mail at GH is indeed fixed.
- You can 'force' GH to commit using your user name by simply removing your name. I've chosen to put it into my 'Work' box, it works very well, as it shows my name in small characters right below my user name, and right above my location. That's, really, the best place I could have put it into, eh. Of course I can't say 'Wedge' in my work box, but... Whatever. People who come to my account know what I'm working on, really. After all, Wedge will soon be on my repo list, so, whatever... :P
All in all, good news. I'll get started on this unused-globals.php repo, using my usual commit e-mail (nao@wedge --> and yes, you can add the obvious TLD to the domain, and it'll redirect to my e-mail address. For now, at least.)
- They fixed my username,
- They're working on a fix for everyone who changes their username,
- They're looking into whether it's possible to choose your commit name when doing web merges.
Good!
In the meantime, I made some tests on a GH repo, and have come to these conclusions:
- (This, I already knew but it's important to point out) You can set your commit e-mail per-repo ('local') or for all repos ('global'), so if you want to change e-mails between repos, it's easy as pie, and if they're all in your GH account, then GH will always show your commits as yours.
- Antispam e-mails used when web merging at GH are really, really noreply e-mails. That is, e-mails to these aren't redirected to your actual registered e-mail, so... Hmm, I don't know, it can be a good thing, or a bad thing.
- TortoiseGit statistics only care about the user name. If my user name is 'Nao', whatever the commit e-mail is, the stats page will merge everything together into the Nao entry. Good.
- My commit e-mail at GH is indeed fixed.
- You can 'force' GH to commit using your user name by simply removing your name. I've chosen to put it into my 'Work' box, it works very well, as it shows my name in small characters right below my user name, and right above my location. That's, really, the best place I could have put it into, eh. Of course I can't say 'Wedge' in my work box, but... Whatever. People who come to my account know what I'm working on, really. After all, Wedge will soon be on my repo list, so, whatever... :P
All in all, good news. I'll get started on this unused-globals.php repo, using my usual commit e-mail (nao@wedge --> and yes, you can add the obvious TLD to the domain, and it'll redirect to my e-mail address. For now, at least.)
2220
The Pub / Re: Is the admin area in urgent need of an overhaul?
« on November 24th, 2013, 01:37 AM »
I moved SE tracking to Maintenance because I feel that anything related to 'logs' should be around the 'log' area. It's not just spider logs, but to me it's where I would expect to find this kind of thing.
Plugins should stay keep their own menu entry because they can have individual menu items for each plugin.
Your Permissions area sounds, to me, a lot like the current Members area... ;)
I may still move data around, eventually. But the #1 problem is with how admin stuff is handled internally. Sometimes, you need to have stuff inside a submenu, other times inside a main menu entry. Just moving Add Plugins out of the submenu and into the main menu was a PITA to implement, and I'm actually thinking of, hmm... Rewriting that stuff, to ensure that one can do what they want and put it where they want, at least for 90% of the current admin data (and 100% of all $settings manipulations, which to me is more important and urgent to 'fix' than other areas, like plugins, maintenance etc.)
Probably not realistic, but I'll give it a try. I have a few ideas on how to do that, of course.
Plugins should stay keep their own menu entry because they can have individual menu items for each plugin.
Your Permissions area sounds, to me, a lot like the current Members area... ;)
I may still move data around, eventually. But the #1 problem is with how admin stuff is handled internally. Sometimes, you need to have stuff inside a submenu, other times inside a main menu entry. Just moving Add Plugins out of the submenu and into the main menu was a PITA to implement, and I'm actually thinking of, hmm... Rewriting that stuff, to ensure that one can do what they want and put it where they want, at least for 90% of the current admin data (and 100% of all $settings manipulations, which to me is more important and urgent to 'fix' than other areas, like plugins, maintenance etc.)
Probably not realistic, but I'll give it a try. I have a few ideas on how to do that, of course.