Wedge

[master 1ed8455]
 14 files changed, 43 insertions(+), 26 deletions(-)

! Why doesn't the board manager allow you to open multiple boards at once anyway..?! (ManageBans.template.php)

* Using this opportunity to remove specificity on input classes. This might cause new issues with other elements using the same generic class names, but so far I only found a use of the .delete class that's unrelated to buttons, and fortunately it doesn't conflict in a visible way. Still, I'll probably have to rethink this. (common.css, index.css, well, basically most files in skins/*)

! My definition lists don't work so well in medium-sized desktop windows. A shame. Making the trigger stricter, then. (sections.css)

! Forgot to commit the lang cache folder. (gz/lang/*)

It's always back to this for me: simplicity vs beauty...
Beauty works best on huge logos, such as on the homepage, or the github account.
Simplicity is better most everywhere else.
But I've never been able to find a logo that works in both large and small sizes. Not fun... ;)

Anyway, logo choice isn't gonna delay anything else, it's just the kind of thing I like coming back to, from time to time.

[master d917d5b]
 2 files changed, 7 insertions(+), 3 deletions(-)

! Marking a topic as unread if it had no replies would mark it as read instead. (Subs-Boards.php)

! If a JS file to be cached isn't found, abort the process instead of creating an empty JS file with a silly name. (Subs-Cache.php)

@Farjo> That would imply me going to bed right after releasing it. I need to be around to fix any problems in the first few hours... (Assuming more than a couple of people are going to download it. Ah, ah.)
Anyway, I already said last week that my target date was Jan 20, and that's the day it will be out. Probably. :P
The whole 'laugh at me' thing is if I fail to release it on the 20th, not Sunday. I just thought that Sunday was the 20th.

@Suki> I thought you'd say Wedge/Wedge, given that all of your repos are ucfirst'ed... ;)
And again, the account is Wedge, but it can still be renamed to wedge. All it changes is that the few people (I think, two!) who forked the languages repo will need to update their remotes IF they ever get writing rights on it in the future (which is not very git-like.)
I guess I'm worried about nothing. It's just a symbol of my fear of releasing, as mentioned above.

Oh, you have no idea...
Just this topic: I'm learning towards NOT using the lowercase 'wedge' as account name, but the majority voted for it, and I don't like being unpleasant... :^^;:

As for the rest...

Well, the problem with going public is not that people will be exposed to my code and thus able to criticize it. Not only am I ready for that, but I'm confident that everyone skilled enough to understand what's under the hood will be thrilled by what they'll see.
However, because git allows rewriting history, but makes one's life miserable if you attempt to force push a rewritten history to a repo that's already public[1], once the source code is public, I won't be able to rewrite history, and believe me, rewriting is REALLY cool if you're looking into having a clean repo with easy and fast blames. (Blame is a VERY useful tool which lets you find a line in a specific file, and gives you a full history of that line, i.e. the dates and contents of each successive modification to that line.)

I'm also still not sure about the new folder structure. While /app and /html are acceptable folder names because they're noob-friendly and match all of my demands, I have to say that I have to look twice for the /templates folder, before I remember it's now called /html. Oddly, it didn't take long for me to assimilate that /Sources is now /app, so I just need some time. The main problem is that /core (their parent folder) is still kind mixed up with two other sibling folders starting in 'c', i.e. 'cache' and 'css'. I'm considering renaming 'cache' to 'files', and move 'css' and 'js' inside it, which would make for a cleaner folder list, at the cost of 6 more bytes per filename in the HTML source code. Perhaps if I could find another name like 'files', but a bit shorter... ('bits'??) Or maybe I just shouldn't bother. The reason why /css and /js were made into root folders in the first place was not that it made for shorter URLs (it was a reason, but not my first), it was that it made it easier for me to clear the CSS and JS caches manually. But since I added a menu command to clear all cache, there's no reason for that any longer, eh...

These are the last few hiccups I'm having. The rest, I guess I can live with.

Also, I'm not releasing anything tomorrow, because it's the 19th, and '9' in Japanese means 'pain'. I'm a bit superstitious about Japanese numbers, to each their own. I thought today was the 19th, so I was planning to postpone to tomorrow, but right now I'm torn between releasing *now*, or postponing for another two days (and thus getting laughed at.)

First-world problems™, I know...!

1.	Basically, it just forces everyone else to delete their local repo, re-download the remote repo, and not kill the one who rewrote history. Additionally, github or git never really tell the user about that rewrite. Nuff said, it's a recipe for disaster.

[master 90e14f9]
 5 files changed, 20 insertions(+), 20 deletions(-)

+ Added support for skin templates. Just add a 'html' folder in your skin folder, and every file you'll put there will replace the default template, just like themes do in SMF. I only added this feature to ensure that theme functionality is 100% emulated in Wedge, but honestly I don't think it's a very good thing to do. I'd strongly recommend using function overriding inside your skin.xml files, or at least waiting until I decide whether both template files (default and skin's) should be loaded, in which case of course your template files will need to exclusively use overriders.

* Renamed $settings['template_dirs'] to $context['template_folders'], because it makes more sense to store in $context anything that's NOT stored in the database in the first place.

* Variablenamenazi. (Display.php)

@ Taking a huge leap of faith; am now parsing skin options before loading templates at all.

Anyway, it's up ;)

[master d50d2fa]
 11 files changed, 60 insertions(+), 35 deletions(-)

+ Added support for skin_mobile definition in boards. (Half a dozen files.)

* Renamed boards.override_theme to boards.override_skin, obviously. (Half a dozen files.)

! Fixed the last wesql::insert. Was too glad to be finished with it, I forgot to add the table name, ah ah... (Subs-Template.php)

! If a board was using the default skin, it would reset to something else in the board management page. (Themes.php, ManageBoards.template.php)